オピニオン
ある大企業のセキュリティアナリストが最近、機密性の高い人事文書が数百人の従業員がアクセスできるMicrosoft Teamsチャンネルにコピーされていることを発見しました。その原因は悪意ある内部者でも、侵害された管理者アカウントでも、高度な攻撃者でもありませんでした。原因はPower Automateのワークフローでした。
そのワークフローは、SharePointとTeams間のドキュメント承認を自動化しようとした開発者が作成したものです。作業を速めるため、開発者はAIアシスタントを使って自動化ロジックを生成しました。機能的には問題なく動作していました。文書は一か所から別の場所へ移動し、通知も送られ、承認プロセスも速くなりました。
問題は、この自動化の背後にある権限設定、データフロー、セキュリティ上の影響を誰もレビューしていなかったことです。これが、多くの企業が今まさに踏み込もうとしているリスクです。
AIコーディングアシスタントは今や、スクリプト、ワークフロー、クエリ、インテグレーションを高速で生成するために活用されています。一方、Microsoft 365はほとんどの企業環境の中核を担っており、メール、文書、Teamsの会話、SharePointサイト、OneDriveファイル、ID情報、コンプライアンス記録、業務プロセスを一手に管理しています。
AIコーディングツールとMicrosoft 365の自動化プラットフォームは、それぞれ単独では確かな生産性向上をもたらします。しかし組み合わさると、目に見えにくいが深刻なセキュリティ問題が生じます。それは「動いてはいるが、誰も完全には理解していない自動化」という問題です。
AIが生成するワークフローが異なるリスクをはらむ理由
多くの組織は、従来のソフトウェア開発においてある程度の管理体制を持っています。コードは通常、ピアレビュー、テスト、デプロイパイプライン、セキュリティチェックを経ます。しかしMicrosoft 365の自動化は、多くの場合そうなっていません。
Power Automateフロー、Graph APIスクリプト、SharePoint自動化、eDiscoveryクエリ、Teams連携、PowerShellスクリプトは、管理者、ビジネスアナリスト、開発者、パワーユーザーによって頻繁に構築されています。その主な目的はたいてい単純で、プロセスを速くしたいというものです。
そこにAIが加わると、自動化を作成するハードルはさらに下がります。Microsoft Graphの権限設定、コネクタの挙動、SharePointの継承、DLPポリシー、監査ログについての深い知識がなくても、やりたいことを平易な英語で説明するだけで、数分以内に動作するスクリプトやワークフローが手に入ります。効率的に聞こえますが、同時に危険でもあります。
問題は、AIが意図的に悪意ある自動化を生成するということではありません。AIが生成するコードは「動くから正しい」と見なされやすい点が問題です。しかし「動く」ことと「安全である」ことは同じではありません。多くのユーザーは自動化がタスクを完了するかどうかをテストしますが、最小権限の原則、データ分類、アクセス境界、保持ルール、監査要件を満たしているかどうかをテストする人はほとんどいません。
その結果、Microsoft 365の内部に「シャドー自動化」が生まれます。機密性の高い企業データへのアクセス権を持ちながら、静かに動き続けるワークフローやスクリプトです。
問題が発生する場面
1. 過剰な権限が当たり前になる
AIが生成するMicrosoft GraphスクリプトはしばしばAI側の判断で広範な権限を要求します。広いアクセス権があるほどコードが動作しやすいためです。
例えば、開発者がSharePointからファイルを読み取りTeamsに更新を投稿するスクリプトを依頼したとします。生成されたコードは、特定のサイト、ライブラリ、チャンネルへの限定的なアクセスではなく、テナント全体の広範な権限を要求するかもしれません。
ビジネス側は「自動化が成功した」と受け取ります。一方セキュリティ部門には、新たな特権的アクセス経路が残されます。
その後、サービスアカウント、アプリ登録、または自動化IDが侵害された場合、攻撃者は本来の用途をはるかに超えたアクセス権を手にする可能性があります。
2. ワークフローが静かなデータ漏洩経路になる
Power Automateは、SharePoint、Teams、Outlook、OneDrive、Excel、サードパーティのSaaSツール、外部受信者の間で情報を簡単にやり取りできます。
その利便性こそがリスクの源です。
月次レポートを配布するために設計されたフローが、誤って給与データ、顧客情報、法的文書、社外秘のビジネスファイルを誤ったTeamsチャンネルや外部メールボックスに送信してしまう可能性があります。これらのワークフローは自動で動作するため、誰かが気づくまでに何週間、場合によっては何カ月もデータの流出が続くことがあります。
これは劇的な侵害シナリオとは言えませんが、ある意味ではより深刻です。通常の業務活動と見分けがつかないからです。
3. コンプライアンス自動化が法的リスクを生む
セキュリティおよびコンプライアンスチームも、eDiscoveryの検索、監査クエリ、インサイダーリスクスクリプト、保持に関するワークフローの生成にAIを活用しています。
不適切に作成されたeDiscoveryクエリは、必要以上のデータを収集したり、重要な証拠を見落としたり、特権通信を露出させたり、保全要件を誤って処理したりする可能性があります。
規制対象業界では、これは単なる技術的なミスにとどまりません。監査での指摘、法的紛争、プライバシー問題、規制上のリスクへと発展する可能性があります。
スピードが変わりました。以前は、エンタープライズ向けの自動化を構築するには時間と専門知識が必要でした。今日では、ユーザーがPowerShellスクリプト、Graph APIインテグレーション、Power Automateワークフローを数分で生成できます。つまり、セキュリティチームが自動化を審査する速度は、自動化が生み出される速度にもはや追いついていません。
経験豊富な開発者だけが本番ワークフローを構築するという従来の前提は、もはや成立しません。AIによって、より多くの従業員が強力な自動化を作れるようになりました。中には、自分が展開しているものの背後にあるセキュリティモデルを理解していない人も含まれます。
これが、多くの組織が見落としている盲点です。アプリケーション、クラウドインフラ、エンドポイント、IDは管理していても、それらすべてをつなぐ自動化レイヤーへの可視性は往々にして不十分です。
AIアシスタントの禁止は現実的な答えではありません。自動化のブロックも同様です。どちらも今や現代のビジネス運営に欠かせない要素です。
より良い答えは「管理」です。
セキュリティチームは、AIが生成する自動化をコードと同様に扱うべきです。Power Automateフロー、Graphスクリプト、アプリ登録、サービスアカウント、eDiscoveryクエリ、PowerShell自動化は、本番環境への導入前にレビューを行うべきです。
また、Microsoft 365の自動化全体に最小権限の原則を徹底すべきです。広範なGraph権限、常設の管理者アクセス、過剰に許可されたコネクタ、共有サービスアカウントは、高リスクな問題として扱うべきです。
組織はMicrosoft 365全体で動作しているワークフローとスクリプトのインベントリを把握する必要があります。セキュリティチームがワークフローの存在を知らなければ、そのリスクを評価することはできません。
モニタリングも重要です。新しいフローの作成、コネクタの変更、権限の付与、外部共有のアクティビティ、異常なファイル移動、アプリの同意イベントは、継続的にレビューする必要があります。
最後に、開発者やシチズンデベロッパーには明確なガイダンスが必要です。AIが生成したコードは承認済みのコードではありません。人間によるレビューが依然として必要な「草稿」に過ぎないのです。
次のエンタープライズセキュリティの大きな盲点は、AIが生成したマルウェアではないかもしれません。
それは、無害に見え、機能テストも通過し、過剰な権限、データの露出、コンプライアンス違反をMicrosoft 365に静かに持ち込む、AIが生成した業務自動化かもしれません。そのワークフローは不審には見えません。アラームを鳴らすこともありません。ただ指示された通りに動き続けるだけです。そして、だからこそ危険なのです。
最新のDark Reading Confidentialポッドキャスト、「CISOには倫理規定が必要か？」をお聴き逃しなく。キックバック、幽霊社員、「いかがわしい」VC、シェルフウェアなど、業界の専門家Robert「RSnake」Hansenが、CISOの倫理規定が必要だと考える理由を語ります。企業や国家のセキュリティをリスクにさらしかねない利益相反をサイバーセキュリティの責任者が行わないよう、倫理規定が機能し得るというのです。今すぐ聴く！
翻訳元: https://www.darkreading.com/cyber-risk/ai-generated-workflows-silent-security-disaster
