2022年10月28日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの山根です。今回のブログでは、ローコード/ノーコード開発におけるセキュリティの検討ポイントについてご紹介します。

1. はじめに

最近では、ローコード/ノーコード開発に関する注目度が高まっており、実際に開発に取り入れられることが増えてきました。ローコード/ノーコード開発が注目される背景については、過去のセキュリティブログでもご紹介しています。[1]
（※ ローコード、ノーコードは厳密には異なりますが、本ブログでは以降「ローコード」とまとめて記述します。）

弊社のセキュリティ技術センターでは、社内で利用するセキュリティ関連のWebシステムを開発しています。この度、従来のWebシステムを置き換えるプロジェクトがあり、それにローコード開発を取り入れることにしました。従来のWebシステムは稼働から長期間経過しており、必要な機能は備えているものの必ずしも社内ユーザーの使いやすいものとは言えなくなってきていました。今後素早く継続的にユーザビリティを向上していくために、ローコード開発を採用することにメリットがあると考えたのです。

表1: 従来システムの問題とローコード開発によるメリット

2. ローコード開発におけるセキュリティ

ローコード開発を採り入れると決めたものの、それだけでWebシステムが完成できるわけではありません。Webシステムの開発にあたっては、当然ながらセキュリティについても考慮する必要があります。

ローコードにおけるセキュリティリスクについては、先のセキュリティブログの記事でローコード版のOWASP Top10をご紹介しています。[1][2] ローコードでは、ベンダーが提供するプラットフォームについてはベンダー側でセキュリティ対策がされていますが、その上に実装するアプリケーションや利用するデータについてはユーザーの責任範囲になります。情報資産の機密性、完全性および可用性を維持するという基本的なセキュリティの考え方は同じですが、ローコード開発の特性を加味した検討が必要です。

私たちのチームが検討した内容は以下です。

それぞれについて、どのように検討を進めたかをご説明します。

2-1. 取り扱う情報の特定とプラットフォームの認証の確認

まず、アプリケーション上で取り扱う情報を洗い出し、分類しました。情報の分類の観点については以下が挙げられます。

続いて、特定した情報ついてセキュリティリスクの対策をどこまで講じるかを考えます。すべての分類に対して一律完全なセキュリティ対策をおこなうというのは現実的ではありませんので、通常、情報の重要度に応じて対策を整理することになります。以下は一例です。

表2: 機密区分とセキュリティ対策の例

会社で規定や管理方針が定められている場合は、そちらに従います。NECグループでは、取り扱う企業秘密を秘密区分によって分類しており、重要な情報に対してその重要度に応じた取り扱い・保管管理を定めています。[4]

セキュリティの対応方針が決定したら、次は利用するローコードプラットフォームのセキュリティについて確認します。スクラッチ開発と異なり、ローコード開発ではプラットフォーム側で用意された部品や機能を組み合わせて開発します。そのため、プラットフォームが情報を保護するのに必要なセキュリティ機能を有していて利用できることを確認します。例えば、アクセス制御が適切な粒度でできるか、通信経路やリポジトリのデータが暗号化できるかなどです。

ただし、ローコード開発では、プラットフォームの部品の内部まで、すなわち部品がセキュリティ要件を満たしたソースコードとして実装されているかまでは確認できません。また、プラットフォームがaPaaS（Application Platform as a Service）[5][6]として提供されている場合は、サービス全体に対してセキュリティが担保されているかまで考慮する必要があります。

そこで役立つのがセキュリティに関する第三者機関による認証です。ベンダーの開示している情報を確認し、プラットフォームが信頼性の高い認証を受けていれば、安心して利用することができます。先のブログ記事[1]でも取り上げられていますが、有名なローコードプラットフォームが取得している認証には、例えば以下があります。

2-2. ローコード開発の支援体制

ローコードプラットフォームが認証を取得していたとしても、その上で開発するアプリケーションのセキュリティが必ずしも担保されるというわけではありません。

ソースコードレベルでのセキュリティについては考慮する必要はありませんが、セキュリティ機能を正しく利用して開発をおこなわないと、セキュリティリスクを埋め込んでしまうことも考えられます。例えば、情報の開示範囲に応じたアクセス制御を正しくおこなわないと情報漏えいに繋がります。ローコードプラットフォーム毎に開発のプラクティスがあるので、そのプラットフォームでの開発に慣れていない場合はベンダーやコミュニティなどのサポートを受けられると安心です。

NECグループでは、実装時に考慮すべきセキュリティ要件のベースラインとして、「サイバーセキュリティ実施基準」を定義しています。[4] これは、ISO/IEC15408やISO/IEC27001などのセキュリティ国際標準、政府機関が定めるセキュリティ基準、業界ガイドラインなどの各種要件を考慮したものになっています。ローコード開発においても、開発や運用の各フェーズでこの基準を満たすかをチェックします。ただ、ローコードプラットフォームがセキュリティを担保する部分については、チェックを省略できる場合があります。

私たちのチームのケースでは、社内に該当のローコードプラットフォームの利用を推進する部隊がありましたので、その部隊に開発やセキュリティチェックのプラクティスを教えてもらいながら開発していくことを考えています。社内で支援する体制があれば、こういったセキュリティ実装の効率化が図れ、ローコード開発によってより早くより安全なアプリケーションの開発が可能になります。

2-3. カスタマイズを抑えて開発できるか

ローコードプラットフォームに対する脆弱性やセキュリティ上の問題が見つかった場合、ベンダーによるセキュリティ対策の追加・アップグレードを受ける必要があります。プラットフォームの各部品の内部についてはブラックボックスであり、さらにaPaaSとして提供されることも多いため、ユーザー側で独自に対策を実施することは難しいと考えられます。

アップグレードを速やかに適用していくことが好ましいですが、その際に注意が必要なのがカスタマイズです。ローコードプラットフォームで開発する際、標準の部品や機能の組み合わせだけで実装できない場合は、カスタマイズをおこなうことがあります。例えば、自身で開発したソースコードを埋め込んで呼び出したり、特殊な設定を入れ込んだりといったことです。ただ、カスタマイズをおこなった場合は、将来的にプラットフォームのアップグレードが公開された場合に、そのアップグレードをすぐに適用できなかったり内部の仕様変更により意図しない動作となったりすることで、セキュリティリスクとなってしまうことが考えられます。

そのため、リスクとのトレードオフを考慮して、カスタマイズの多用は避けるべきと考えています。カスタマイズが非常に多くなる場合は、ローコードを選択しないことも視野に入れます。私たちのチームでは、まず前述の支援部隊が提供している開発トレーニングを受けて基本的なローコード開発のスキルを身に付け、その後プロトタイプを作るということを実施しました。その結果、多くの部分は標準部品で実装できる見込みが立ったため、該当のローコードプラットフォームでの開発を採用しました。

3. まとめ

ローコード開発を始めるにあたって、私たちのチームがどのようにセキュリティについて検討したかをご紹介しました。まだ開発は道半ばですので、この内容だけで全てをカバーできているとは限りません。新たに問題が見つかる場合も考えられますが、その場合もセキュリティを第一に取り組んでいきます。

ローコードは今後ますます活用がすすんでいくと考えられます。その中で、本ブログが少しでもみなさんの役に立てば幸いです。

参考:

執筆者の他の記事を読む