クラウドのIAM（Identity and Access Management、アクセス権限管理）では、権限は「この主体が」「この対象に」「何をしてよいか」という3つの要素の組み合わせで定義されます。権限レビューや診断の現場では、この組み合わせを1件ずつ見れば「過剰な権限」には見えないものが大半です。しかし複数の権限を掛け合わせたときに初めて、「自分の権限を自分で書き換えられる」という構造的な抜け穴が生まれることがあります。これは特定の製品の欠陥ではなく、権限管理という仕組みそのものに内在するリスクです。

実際のクラウド事業者のセキュリティ研究チームや、専門のペネトレーションテスト企業は、こうした「個別には正当な権限の組み合わせ」によって権限昇格が可能になるパターンを継続的に調査・公開しています。代表的なものとして、「自分が管理する許可文書の新しいバージョンを作成し、それを有効化できる」権限の組み合わせや、「自分の認証情報を新規発行できる」権限、「より強い権限を持つ役割を一時的に引き渡せる」権限などが知られています。本話では、これらの構造を架空のクラウドサービスで安全に再現します。

IAM（Identity and Access Management）の基本は驚くほど単純です。「誰が（主体／アイデンティティ）」「何に対して（対象／スコープ）」「何をしてよいか（操作／ケーパビリティ）」という3つを組み合わせて許可を定義します。本話では、架空のクラウドサービス「Vela Cloud」を舞台にします。Vela Cloudでは、この3点セットを次のような形式で表現します。

{
  "identity": "user:u-2291",
  "grants": [
    { "capability": "object:Read", "scope": "bucket:reports/*" },
    { "capability": "grant:CreateVersion", "scope": "grant:self" },
    { "capability": "grant:ActivateVersion", "scope": "grant:self" }
  ]
}

権限が10個あるとき、それを2つずつ組み合わせて確認しようとすると45通りの組み合わせが生まれます（10個から2個を選ぶ組み合わせの数）。実際の組織では1人の担当者が数十から数百の権限を持つことも珍しくなく、組み合わせの数は数千通りに膨れ上がります。「権限Aは単体で安全か」を1件ずつ確認するレビューでは、この組み合わせのリスクを発見することはほぼ不可能です。

多くの組織がこの問題に対処するため、権限の自動分析ツールを使い、「この主体が持つ権限を組み合わせると最終的にどこまで到達できるか」をグラフとして可視化する手法を取り入れています。次の実践チャレンジでは、まさにこの「組み合わせの発見」を体験します。

以下は、あなた（user:u-2291）がVela Cloud上で実際に持っている権限一覧です。一見、どれも「自分の持ち物」に対する操作ばかりで、過剰な権限には見えません。この中から、組み合わせることで自分自身に管理者権限を追加できる2つの権限を見つけてください。

• 最小権限の原則の徹底：必要な権限だけを必要な期間だけ付与し、定期的に未使用の権限を回収する
• 危険な権限の組み合わせの自動検出：個別の権限だけでなく、組み合わせによる到達可能性をグラフ解析するツールを使う（権限昇格パスの可視化）
• 自分自身の許可文書を変更できる権限を一般利用者に与えない：grant:CreateVersion・grant:ActivateVersionのような「許可そのものを書き換える」権限は、専用の管理ロールに限定する
• 変更の監査ログ：誰が・いつ・どの許可文書を書き換えたかを必ず記録し、異常な変更（特に自分自身への権限追加）を検知する
• 一時的な強い権限はその場で失効させる：作業が終わったら強い権限を自動的に剥奪する仕組み（一時昇格・Just-In-Timeアクセス）を使う

個々の許可は正しくレビューされていても、その組み合わせまでは見ていない——これが今回の脆弱性クラスの本質です。次のセクションでは今回の学びをまとめます。

第6話では、個別には無害な権限同士が組み合わさることで特権昇格に至る、クラウドIAM特有の脆弱性クラスを体験しました。CTFの「フラグ探し」ではなく、実際の権限レビューで起きている死角そのものです。