セキュリティチームが抱えているのは検知の問題ではない。修復の問題とコミュニケーションの問題であり、セキュリティにおけるAIが実際に元を取れるのはこの2か所だ。最近のスキャナーは、コンプライアンスベンチマークに対して800件の検出結果を平気で突きつけてくる。難しいのは検出結果そのものではない。難しいのは、その大半が結局修正されないこと、そして修正されたものも予算を承認する人たちからは見えないことだ。この記事は、その問題に直接効くと私が考える2つのAI機能、承認ゲート付きの自動修復と、非技術者向けのAI生成レポートについての101だ。Microsoft 365セキュリティプラットフォームであるAether365を通しの例として使う。最初に明かしておくと、Aether365は私のプロダクトだ。議論は中身で判断してほしい。

始める前にひとつの原則: read-onlyがデフォルトである。個別の明示的な同意なしに、テナントへの書き込み権限が付与されることはない。

すべてのセキュリティスキャナーが残す2つのギャップ

実際のMicrosoft 365テナントに対してポスチャスキャンを走らせると、CISベンチマークでもEIDSCAでもCISA ScuBAでも、出力の形は同じになる。重大度が付いた、失敗したチェックの長いリストだ。その次に起きることは2つあり、どちらも予測どおりだ。

まず、検出結果のキューは全員の集中力より長生きする。1件の修正ごとに、正しい管理センター、正しいPowerShellコマンドレット、正しいMicrosoft Graph呼び出しを調べたうえで、本番のIDシステムに変更を加えることになる。ミスをすれば実際の人間がロックアウトされるシステムだ。これを数百件分掛け算するとキューはバックログになり、バックログは検出結果が古びていく場所だ。

次に、スキャンレポートはセキュリティチームの外に出ていかない。コントロールIDと設定パスで書かれているからだ。人員と予算を決める人たちはそれをまったく見ないか、文脈のないコンプライアンススコアだけを見る。テナントが1年間60パーセント準拠のまま放置され、それが何を意味していたかを経営層が知るのはインシデントの振り返りの場になってからだ。

どちらのギャップも検知の品質の話ではない点に注目してほしい。検知が良くなるほど、最初のギャップはむしろ広がる。これが重要なのは、「セキュリティにおけるAI」のマーケティングの大半が、より多く検知することを謳っているからだ。面白い仕事は検知の下流にある。

AI Pilot: 人間の承認ゲート付きの修復

AI Pilotは最初のギャップに対するAether365の答えであり、その設計は、誰が作るにせよエージェント型の修復がどうあるべきかを考えるうえで有用なケーススタディだ。ループは4段階からなる。スキャン、提案、承認、そして適用と検証だ。

スキャンが検出結果を出す。各検出結果に対して、システムは実行するMicrosoft Graphの変更に正確にマッピングされた具体的な修正を生成する。散文の提案ではなく、実際のミューテーションそのものだ。あなたは提案された変更を1件ずつレビューし、項目ごとに承認または却下する。承認された変更だけが適用され、適用された各変更は検証されて監査証跡に記録される。

ここでの101の教訓は権限モデルだ。本番環境のエージェント型システムが信頼を勝ち取るか失うかは、まさにここで決まる。読み取り専用アクセスがデフォルトであり、デフォルトのままであり続ける。AI Pilotを使うには、明示的にオプトインする別個のMicrosoft書き込み同意接続が必要になる。有効にしない限り、プラットフォームは物理的にテナントを変更できない。読み取り専用を維持しなければならないEUや規制対象のテナントでもこのツールが使えるのはこのためだ。書き込み経路はアプリ内のトグルではなく、Microsoft自身の認可レイヤーが強制する同意境界なのだ。

失敗モードと比較してみよう。常時書き込みアクセスを持ち、見つけたそばから修正していく完全自律のエージェントだ。効率的に聞こえるが、それは午前2時にConditional Accessポリシーを「修正」して、オンコールのエンジニアが原因を確認するためのサインインすらできなくなるまでの話だ。変更ごとの承認ゲートを持たない自律性は、修復ツールを、無限の忍耐力を備えた監査されない管理者に変えてしまう。ゲートはAIの制約ではない。ゲートこそが機能だ。

Business Impact Reports: 翻訳レイヤー

2つ目のギャップはコミュニケーションであり、これは今日のセキュリティにおけるLLMの、最も地味で最も擁護しやすい使い方だ。言語モデルは、セキュリティツールが昔から苦手としてきた1つのことが本当に得意だ。技術的な状態を、非技術者の読者が行動に移せる物語に翻訳することだ。

Business Impact Reportsは、生のスキャン結果から役員会にそのまま出せるドキュメントを生成する。平易な言葉のエグゼクティブサマリー、コンプライアンススコアがビジネスにとって何を意味するか、どの事業部門が最も多くのリスクを抱えているか、優先順位付きの「まずこれから」ロードマップ、そして検出結果とGDPR、NIS2、ISO 27001の義務とのマッピングだ。24言語のいずれでも生成でき、これは聞こえる以上に重要だ。ミュンヘンのCFOはドイツ語でレポートを受け取り、セキュリティチームは英語で作業する。同じスキャンデータから、だ。

誠実な101なら2つの注意点を添えるべきだ。レポートの品質は土台のスキャンの品質を超えられない。悪いデータを語るLLMは、ページ番号付きの自信満々なナンセンスを生み出す。そしてAI生成レポートには明確なデータ取り扱い方針が必要だ。Aether365の方針はこうだ。スキャンデータがモデルの学習やファインチューニングに使われることは決してなく、AIはその場でレポートを生成するためだけに動き、全体が人間の監督下に置かれ、EU AI Actに整合している。どのツールを選ぶにせよ、これらの回答を書面で要求してほしい。

あらゆるAIセキュリティ機能に使える101チェックリスト

ブランドを剥がして、どんな「AI+セキュリティ」機能も次の5つの質問で評価してほしい。

  • 書き込みアクセスはオプトインで、別個に同意するものか? デフォルト読み取り専用は最低条件だ。本当のテストは、書き込み同意の経路が分離されているかどうかにある。
  • すべての変更を個別に承認できるか? 300件の変更の一括承認はゲートではなく、ただのゴム印だ。
  • 検証済みの監査証跡はあるか? 適用済みと検証済みは同じではない。変更ごとに両方が欲しい。
  • AIがするのは意思決定か、それとも提示か? 人間の承認を前提に修正案とレポートを起草するAIはローリスクだ。IDインフラ上で無人のまま行動するAIはそうではない。
  • 自分のデータは学習に使われるか? 回答が1文で終わらないなら、答えはイエスだ。

AI PilotとBusiness Impact Reportsは、私にとってセキュリティにおけるAIの誠実なかたちだ。モデルが退屈なマッピングと翻訳をこなし、権限は人間が握り続ける。ボトルネックは検知だったことなど一度もない。修正することと説明することがボトルネックであり、この世代のツールが狙うべき場所はまさにそこだ。

次に読む

この話のインフラ側、つまりMicrosoft 365テナントを他のクラウド資産と同じように扱うべき理由については、ercan.cloudのChecking Cloud with Cloud: M365 Security Posture Scanning 101を読んでほしい。AI、クラウド、プラットフォーム業務のコンサルティング、あるいは挨拶だけでも、ercanermis.comからどうぞ。

参考資料