EN

NRIセキュア ブログ

ローコード/ノーコード開発基盤のセキュリティの落とし穴|留意するべき4つのポイントを解説

目次

     

    blogtop

    当社では、ローコード/ノーコード開発基盤のセキュリティ設定や利用環境の安全性を評価する、「ローコード/ノーコード開発基盤セキュリティ評価サービス」を2023年711日に提供開始しました。そこで、本ブログでは、以下の2点を中心に解説していきます。

    • ローコード/ノーコード開発基盤とは何か
    • ローコード/ノーコード開発基盤を自社で活用する際に、セキュリティ観点で特に留意すべきこと

    ▶「経営層を納得させるセキュリティ予算獲得術」を読む

    ローコード/ノーコード開発基盤とは

    ローコード/ノーコード開発基盤普及の背景

    企業のDXを推進するため、アプリケーションやシステムの新規開発や頻繁なアップデートの需要が高まっています。一方で、開発スキルを有するITエンジニア人材が各企業において不足している状況です。弊社が毎年実施している数千社を対象とした企業における情報セキュリティ実態調査2022­」では、国内企業の60%強がDXの取り組み課題として人員不足を挙げています。

     

    そうした中で、ソースコードの記述が不要、あるいはソースコードの記述が最小限でアプリケーションの開発が可能な「ローコード/ノーコード開発基盤」を導入する企業が増えてきています。このツールを活用することで、内製でのアプリケーション開発をより効率的かつ生産性高く行えるようになるため、近年の需要が高まってきており、2025年には1500億円以上の市場規模、また市場成長率も24.4%となると予測されています*1

     

    *1  参考)ITR:ローコード/ノーコード開発市場規模推移および予測(2019~2025年度予測)https://www.itr.co.jp/company/press/220217pr.html

    ローコード/ノーコード開発基盤の利用におけるユーザの課題認識

    導入する企業が増えてきている一方で、下記の様な課題を持たれている企業も多いのではないかと思います。
    1. 先進的なツールであり、セキュリティ対策の指標がないため対策が十分か分からない
    2. 開発現場では開発スピードが優先され、セキュリティ対策が後回しにされている

    スピード感をもってアプリ開発したいという思惑のもと、導入したローコード/ノーコード開発基盤のセキュリティ対策をしっかりしようとして、アプリ開発のスピード感や利便性が落ちてしまっては本末転倒です。

     

    そういった導入の背景を考慮し、ツールのセキュリティ関連の機能や運用実態等を把握した上で、構築されたアプリケーションのセキュリティ対策を検討していく必要があります。その上で、極力運用に負荷をかけない様な代替統制を含めた対策案を検討することが必要となってきます。

    ローコード/ノーコード開発基盤を使う上でのセキュリティの落とし穴(留意点)

    ここでは、ローコード/ノーコード開発基盤のどのような部分に気を付けるべきか紹介していきます。

    落とし穴1:責任範囲を見極める必要がある

    ローコード/ノーコード開発基盤は、オンプレミス版およびクラウドサービス版(aPaaS:Application Platform as a Service)の両方が提供されているのが一般的ですが、少しでも利便性を向上させる、また開発者側の運用負荷を下げるという観点でクラウドサービス版を利用するケースが多いのではないでしょうか。

     

    クラウドサービス版は、運用負荷が下がり開発に注力できる点から利便性は向上しますが、セキュリティ対策の観点では留意しなければいけない点もあります。クラウドサービス版の場合、ネットワーク管理は原則サービスプロバイダー側の責任になるため、プロバイダーによってはネットワークレイヤーでのセキュリティ対策が不十分になる可能性があります。

     

    もしアウトバウンドの通信制御が機能として実装されていない場合において、内部の悪意を持った人物等がアプリケーションに外部とやりとりできる機能を持ったモジュールやパーツを組み込んでしまえば、いくらでも内部から好きなところに情報を持ち出せてしまいます。

     

    そのため、ネットワークレイヤーでのアウトバウンドでの通信制御の機能が実装されていない場合は、ローコード/ノーコード開発基盤上で開発するアプリケーションに不正なモジュールやパーツをデプロイさせないような統制や権限管理の徹底といった代替統制が必要になってきます。

     

    ユーザがセキュリティ管理対象として意識しておくべき範囲の違い

    ユーザがセキュリティ管理対象として意識しておくべき範囲の違い

     

    落とし穴2:きめ細かな権限管理やアクセス制御の限界

    システムユーザのアクセス制御には、ユーザID/パスワードによる記憶要素での認証が一般的ですが、事前に登録された端末による所持要素での認証や生体認証など、複数の要素を併用した多要素認証を導入するケースも増えています。特に重要な情報を扱うようなシステムにログインするような場合は、多要素認証がデファクトスタンダードになりつつあります。

     

    また、接続元IPアドレス制限によって、社内のネットワークからのみアクセスできるようにすることも有効なアクセス制御になります。

     

    一方で、ローコード/ノーコード開発基盤には、本番環境にアクセスする際に多要素認証には対応していないケースも存在します。そういったケースには、多要素認証の代替統制として、どのように「正規の権限者の認証を強化するか」という観点での対策が必要となってきます。

     

    更に、開発環境→検証環境→本番環境へのデプロイ手順についても第三者承認が不要でデプロイできてしまうようなケースもあるため、事前に社内で環境間をまたがるデプロイ時にはデプロイ専用のユーザを新規作成して第三者承認を得てからユーザを払い出す等のプロセスを整備し、社内にしっかり周知しておく等の対応が必要となります。ツールの機能に頼り切ることをせずに、運用で統制を利かせるということも重要になってきます。

     

    テレワークでの業務が浸透している中で、開発者が好き勝手に自宅やカフェ等から、不用意に本番環境に手を加えられることが無いようにセキュリティ統制をかけていく必要があります。ローコード/ノーコード開発基盤

    落とし穴3:迅速な脆弱性対応/セキュリティインシデント対応への弊害

    セキュリティインシデントが発生した時や、脆弱性が発見された時にいかに迅速に対応できるかが、インシデントの被害を最小限にとどめたり、サイバー攻撃を未然に防ぐための鍵となってきます。

     

    一方で、クラウドサービス版のローコード/ノーコード開発基盤を利用すると、一部のログはプロバイダー側で管理されているため、何のログが自分たちで管理/モニタリングできていて、何のログはプロバイダー側で管理されているのか、事前に把握し、インシデント発生時にどういったプロセスでインシデントの被害範囲を特定するべきなのか等定めておく必要があります。

     

    また、ツールの機能やプランによっては、ユーザによる不審な行動や重要な変更を検知するためのアラートをあげる機能や、アラートをあげるための閾値を設定する機能がないこともあります。そういった場合には他の外部システムと連携させてアラートをあげるといったことも検討していく必要があります。

     

    加えて、ログの保管期間についてもSLAで定められているため、自社のシステム運用規程や業界標準で求められている要件と合致しないケースがあります。そういった場合には、ログを外部保管するためのストレージ等を別途契約することも検討する必要があります。

     

    更に、アプリケーション脆弱性への外部からの攻撃対策についても、プロバイダー側の共通基盤としてWAF が導入されているものの、各契約者への不正アクセス検知連絡や、契約者ごとの個別のワークアラウンドには対応していないケースもあります。そのため、外部から不特定多数のアクセスが頻繁に見込まれるようなアプリケーションを開発/運用する場合は、個別にWAFを導入する、それが難しい場合にはローコード/ノーコード開発基盤の利用自体を控えるといったこともシステム特性に応じて検討が必要となります。

    落とし穴4:高い可用性が求められるシステムには不向き

    高い可用性が求められ、24時間365日稼働している必要がある、いわゆるミッションクリティカルなシステムやアプリケーションが世の中には存在しますが、高い可用性を維持するためには、複数の地域間(東日本、西日本など)でシステムを分散して運用することやバックアップサイトを用意しておくことが必要です。こうすることで、ディザスタリカバリ(DR)やBCP対策として有効となります。

     

    一方で、ローコード/ノーコード開発基盤によっては、アプリケーションサーバの同一リージョン内での冗長性は確保できるものの、複数のリージョン間で冗長構成をとることができない場合があります。そういった場合には、大規模な自然災害が起きた時の耐障害性という観点で対策が不十分となってしまいます。

     

    また、障害発生時にバックアップサイトからデータをリストアしようとしたときに、特定のデータベースのみをリストアすることができずに環境全体での一斉リストアしかできないようなローコード/ノーコード開発基盤もあるため、リストアが不要なデータベースがデグレードを起こしてしまうケースも出てきます。

     

    そのため重要なデータは外部のデータベースに保存するような構成も検討する必要が出てきますが、この時にも安全な経路で外部のデータベースと連携できているのか等、セキュリティを考慮した構成にしないと更なるリスクにつながってしまいます。

    まとめ

    今回は、「ローコード/ノーコード開発基盤とは何か」「ローコード/ノーコード開発基盤を使う上で、セキュリティ観点で留意すべきこと」について解説してきました。

     

    ローコード/ノーコード開発基盤がセキュリティ的に劣っているということではなく、むしろエンジニアで開発するよりヒューマンエラーによるバグや、よく知られた脆弱性の混入を防ぐという観点では優れている一面もあるかと思います。一方で、ローコード/ノーコード開発基盤が提供するセキュリティ機能だけでなく、運用プロセスや周辺環境までしっかり考慮しないとセキュリティの欠陥になりうる可能性もあるといった内容をご紹介しました。

     

    セキュリティの欠陥を無くしていくためには、システムの特性に応じたセキュリティ対策案の検討および導入を行う必要があり、対策案の導入にあたっては、運用形態(オンプレミスかクラウドか)や、契約プラン、オプション等を使うという選択肢も視野に入れる必要があると思います。そういったことも踏まえて、自社で検討するか、外部の専門家に相談するか判断するのがよいのではないかと思います。

     

    もし、「ローコード/ノーコード開発基盤セキュリティ評価サービス」にご興味がある方は下記リンクからお問い合わせください。

     

    アーカイブ動画配信:DevSecOps実現と成功ウェビナー