クラウドセキュリティのグレーゾーン：マネージド ID のリスクは誰の責任か？
MFA の適用や権限の制限に何時間も費やすことができます。しかし、自分で管理していない ID のことはどうでしょうか？クラウドプロバイダーが作成・管理しているIDのことです。
これらの「CSP管理の非人間 ID」は、バックグラウンドでサービスを実行する自動化されたロボットです。これらは不可欠な存在ですが、AWS、Google Cloud、Microsoft がそれぞれ異なるアーキテクチャを採用しており、独自かつ目立たないセキュリティリスクを生んでいます。たとえば、AWS で安全に構成されているからといって、Azure でも同じように安全とは限りません。
それぞれのクラウドにおけるリスクの違いを整理してみましょう。
AWS：「混乱した代理人（Confused Deputy）」の問題（責任はユーザーにある）
AWS では、サービスはグローバルで全員に共有されています。これにより、古典的なマルチテナント型の「Confused Deputy（混乱した代理人）」リスクが生じます。攻撃者は自分のアカウントから あなたのアカウントのリソースにアクセスさせるよう、AWS サービスを騙すことができる可能性があります。
- 注意点：これを唯一阻止できるのは、IAMリソース・ポリシーで条件キー（aws:SourceArn）と呼ばれる特別な設定だ。
- 現実：コンディション・キーを正しく使うのは非常に難しく、多くの場合見落とされがちな巨大なセキュリティホールを残すことになります。防御の責任は完全にユーザーであるあなた側にあります。
Google Cloud：「ブラックボックス」の問題（責任はGoogle Cloudにある）
Google はまったく逆のアプローチを取っています。CSP 管理の非人間 ID（Service Agents）はシングルテナントで、Google 管理のプロジェクトにロックされています。ユーザー側で触れることはできないため、他のクラウドに見られる資格情報の悪用を防げます。
- 注意点：ただし、これが別の問題を引き起こします。それは「推移的アクセスの悪用」です。サービス自体が強力すぎると、攻撃者にとって格好の標的となり、攻撃者が自分の権限チェックを回避しながら、サービスに代理実行させることが可能です。
- 現実：実際に Document AI サービスでこの問題が発生しました。Google はこれを修正しましたが、ユーザー側では直接コントロールできません。サービスが安全に設計されていることを Google を信頼するしかないのです。
Microsoft Entra ID：「サービスプリンシパルのハイジャック」（現在進行中のリスク）
Microsoft はハイブリッドモデルを採用しており、Microsoft が所有するファーストパーティアプリケーションのローカルプリンシパルがテナント内に存在します。この設計には重大な欠陥がありました。管理者（例：Application Admin）が、自分の資格情報をサービスプリンシパルに追加して権限をエスカレートできてしまうのです。
- 注意点：Microsoft はこれに対し、appInstancePropertyLockという対策を導入しました。 これを有効化することで、ハイジャックを防止できます。
- 現実：ただし、この修正は遡及的ではありません。Microsoft は顧客テナントにデフォルトでインストールされている 300以上のアプリケーションを手動で更新する必要があります。多くはすでに修正済みですが、最近の研究によると、Office 365 Exchange Online などの重要アプリは依然として保護されておらず、この 3 つの中で最も即時性と影響が大きいリスクとなっています。
まとめ
クラウドにおけるセキュリティに「万能な解決策」はありません。AWS で深刻な脅威が、Google では問題にならない場合も、Entra ID のリスクは原因がまったく異なることもあります。
- AWS を使っているなら？IAM ポリシーを監査して、条件キーが欠けていないか確認を。Confused Deputy 問題はあなたの責任です。
- Google Cloud を使っているなら？Service Agent のセキュリティは Google頼りです。脆弱性情報をチェックし、必要最小限のサービスのみを有効化し、不審な動作を監視してください。
- Microsoft Entra ID を使っているなら？ローカルサービスプリンシパルに資格情報が追加されていないか監視してください。また、ハイジャックに関する報告がないか最新情報を追ってください。
脅威はクラウドによって異なります。あるクラウドでは深刻な脅威が、別のクラウドでは問題にならない場合もあります。防御者や研究者はこの前提を理解し、マルチクラウド環境においては「1対1対応」のセキュリティ戦略は通用しないと認識すべきです。
これらの各脅威モデルや様々なアーキテクチャの背後にある研究については、付属のホワイトペーパー「A Comparative Threat Model of CSP-Managed Machine Identities（CSPが管理するマシン・アイデンティティの比較脅威モデル）」をご参照ください。