ノーコード開発のセキュリティリスクと野良アプリ対策ノーコード開発で生じるセキュリティリスクと野良アプリ防止のガバナンスルールを解説

ノーコード推進の「光」と「影」——セキュリティリスクは後から顕在化する

ノーコード開発は、IT人材不足の解消と業務効率化を同時に実現できる手段として、多くの中堅企業で導入が進んでいます。しかし、「誰でもアプリが作れる」という利点は、裏を返せば「セキュリティの知識がない人もアプリを作れてしまう」というリスクと表裏一体です。ノーコード開発プラットフォームのBubbleで構築された18,000以上のアプリを対象とした監査では、11.2%のアプリが「公開エディター」という重大な脆弱性を抱えており、誰でもアプリのデータにアクセス・操作できる状態にあったことが報告されています。

本記事では、ノーコード開発で見落とされがちな5つのセキュリティリスクと、「野良アプリ」の乱立を防ぐためのガバナンスルールの作り方を解説します。ノーコード推進を加速している企業こそ、この記事の内容を確認してください。

ノーコード開発で見落とされる5つのセキュリティリスク

ノーコード開発プラットフォーム自体のセキュリティは、PaaS（Platform as a Service）として提供元のベンダーが担保しています。しかし、プラットフォーム上で構築されるアプリケーションのセキュリティは、開発者（＝現場の業務担当者）の責任範囲です。IPAのICSCoE（産業サイバーセキュリティセンター）が公表した「ローコード・ノーコードツール セキュリティビギナーズガイド」でも、この責任分界点の理解が不十分なまま開発が進むことへの注意が喚起されています。

第一のリスクは「アクセス権限の設定ミス」です。ノーコード開発では、データベースへのアクセス権限をGUIで設定しますが、この設定を誤ると、本来アクセスできるべきでないユーザーがデータを閲覧・操作できてしまいます。たとえば、全社員が閲覧できる設定にしたつもりが、社外の第三者にもデータが公開されていた——という事故は、アクセス権限の初期設定を確認せずにアプリを公開した場合に起こり得ます。NRIセキュアの分析でも、データベースへのアクセス権限の設定ミスは重大なインシデントにつながると指摘されています。

第二のリスクは「認証・認可の不備」です。ノーコードで作成したアプリに適切な認証（ログイン）と認可（権限制御）が実装されていないと、URLを知っている人なら誰でもアプリにアクセスできる状態になります。プラットフォームによっては、認証機能がデフォルトで無効になっているものもあり、開発者が意識的に有効化しない限り、認証なしでアプリが公開されるケースがあります。

第三のリスクは「データの意図しない外部送信」です。ノーコードプラットフォームでは、外部サービスとの連携（API連携やWebhook）を簡単に設定できます。この利便性は裏を返すと、悪意のある、あるいは不注意な設定によって、社内データが外部に送信される経路を簡単に作れてしまうことを意味します。NRIセキュアの分析では、アウトバウンド通信の制御がプラットフォーム側で実装されていない場合、不正なモジュールの組み込みによる情報持ち出しのリスクが指摘されています。

第四のリスクは「サードパーティプラグインの脆弱性」です。Bubbleのようなプラットフォームでは、5,200以上のプラグインが利用可能ですが、これらのプラグインはすべてがベンダーによって品質保証されているわけではありません。セキュリティレビューが不十分なプラグインを組み込むと、アプリ全体の脆弱性につながります。プラグインの選定時には、最終更新日、レビュー数、提供元の信頼性を確認する必要があります。

第五のリスクは「開発者アカウントの管理不備」です。ノーコード開発の管理者アカウントが共有されていたり、退職者のアカウントが削除されずに残っていたりすると、不正アクセスの入口になります。IPAのガイドでも、管理者アカウントのログイン情報の厳重な管理が強調されており、共有アカウントの使用は避けるべきとされています。

「野良アプリ」はなぜ危険なのか

ノーコード開発が社内に浸透すると、次に直面するのが「野良アプリ」の問題です。野良アプリとは、IT部門の管理下にないまま、現場の担当者が独自に作成・運用しているアプリケーションのことです。

野良アプリが危険な理由は3つあります。第一に「セキュリティレビューが行われていない」ことです。IT部門を介さずに作成されたアプリは、前述の5つのセキュリティリスクがすべて未対策のまま放置されている可能性があります。第二に「作成者の異動・退職後に管理者不在になる」ことです。作成者がいなくなった後も、アプリが動き続け、データが蓄積され続けるものの、誰も中身を把握していない——という状態はセキュリティインシデントの温床です。第三に「データの重複・不整合が発生する」ことです。同じ業務データを扱うアプリが複数存在すると、どのデータが正しいのかが分からなくなり、業務判断の誤りにつながります。

Gartnerは、2025年までにアプリケーションの70%がノーコード・ローコード技術を用いて開発されると予測しています。アプリの数が爆発的に増える中で、野良アプリの管理はすべての企業にとって避けて通れない課題です。

野良アプリを防ぐガバナンスルール5つ

野良アプリの発生を防ぎつつ、ノーコード開発の利便性を損なわないためには、「禁止」ではなく「ルールの下での自由」を実現するガバナンスの仕組みが必要です。以下の5つのルールを最低限整備してください。

ルール1は「アプリ台帳の作成と維持」です。社内で作成されたすべてのノーコードアプリを一覧化した台帳を作成し、アプリ名、作成者、作成日、対象業務、使用しているデータソース、利用者の範囲、最終更新日を記録します。この台帳は四半期に一度、棚卸しを行い、使われていないアプリの削除または継続判断を行います。

ルール2は「開発者の登録制と最低限のセキュリティ教育」です。ノーコードでアプリを作成できる人を登録制にし、登録前にアクセス権限の設定方法、認証の有効化、データの取り扱い注意点に関する最低限のセキュリティ教育（30分〜1時間程度のeラーニングで十分）を受講させます。「誰でも作れる」の「誰でも」を「基本的なセキュリティを理解した人」に引き上げることが目的です。

ルール3は「データソースの利用ルール」です。ノーコードアプリが接続できるデータソースを明確に定義します。たとえば「社内のSharePointリストとExcel（OneDrive上）は利用可。外部APIへの接続はIT部門の事前承認が必要」というルールを設けることで、データの外部漏洩リスクを制御できます。特に個人情報や機密情報を含むデータソースへの接続は、IT部門の承認を必須とすべきです。

ルール4は「公開前のセキュリティチェックリスト」です。アプリを社内に公開する前に、開発者自身がチェックリストで確認するプロセスを設けます。チェック項目は、認証が有効になっているか、アクセス権限が最小権限の原則に沿っているか、外部への通信設定がないか（または承認済みか）、テストデータが残っていないか、の4項目を最低限含めてください。このチェックリストは完璧なセキュリティ監査ではありませんが、「最低限の確認を必ず行う」という文化を作ることに意味があります。

ルール5は「管理者不在アプリの自動検知と対応」です。アプリの作成者が異動・退職した際に、自動的にIT部門に通知される仕組みを構築します。通知を受けたIT部門は、アプリの後任管理者の指定、または利用停止の判断を30日以内に行います。管理者が不在のまま放置されるアプリをゼロにすることが、野良アプリ対策の最終防衛線です。

GXOのガバナンス設計支援

ノーコード開発のセキュリティとガバナンスは、技術的な対策だけでなく、組織のルール設計、教育体制の構築、運用プロセスの整備を含む包括的な取り組みです。GXOは180社以上の支援実績と92%の成功率を持つDX・システム開発のパートナーとして、ノーコード開発のセキュリティリスク評価、ガバナンスルールの策定、開発者向けセキュリティ教育の設計、野良アプリの棚卸しと管理体制の構築まで、一貫して支援しています。

「ノーコード開発を推進しているが、セキュリティ面が不安」「現場でアプリが乱立し始めて管理が追いつかない」「ガバナンスルールを作りたいが何から手をつければよいか分からない」という方は、お気軽にご相談ください。

お問い合わせはこちら

まとめ

ノーコード開発は業務効率化の強力な手段ですが、「誰でも作れる」利便性の裏に、アクセス権限の設定ミス、認証の不備、意図しないデータ外部送信、プラグインの脆弱性、アカウント管理の不備という5つのセキュリティリスクが潜んでいます。さらに、IT部門の管理下にない「野良アプリ」の乱立は、セキュリティインシデントの温床となります。アプリ台帳の作成、開発者の登録制とセキュリティ教育、データソースの利用ルール、公開前チェックリスト、管理者不在アプリの検知——この5つのガバナンスルールを整備することで、ノーコード開発の利便性を損なわずにリスクを制御できます。