見出し画像

IAMロール過剰権限『クラウド（AWS / Azure / GCP）の話②』

nobu.ai.design

API は普通に呼べる。
エラーも出ない。
運用も楽。
──その代わり、事故が起きたら被害は最大化する。
原因は IAMロールに権限を与えすぎていること。
クラウド初学者が「とりあえず動かすため」にやりがちな、静かで危険な設計ミスだ。

冒頭の一言要約

IAM は“許可の集合”。
広く与えた分だけ、壊せる範囲も広がる。

症状（あるある）

  • AdministratorAccess が普通に付いている

  • EC2 から全サービス操作可能

  • 使っていない権限が大量にある

  • どの権限が必要か誰も説明できない

  • インシデント時に影響範囲が読めない

  • ロールを使い回している

原因と仕組み（なぜ起きるか）

  • ポリシー設計が面倒でフル権限を付与

  • 権限不足エラー → 全許可で回避

  • マネージドポリシーを深く見ていない

  • 最小権限（Least Privilege）を知らない

  • 検証用ロールを本番に流用

  • 権限の棚卸しをしていない

IAMロールは
「できることの上限」を決める仕組み。
過剰権限は、
侵入・誤操作・バグの被害を一気に広げる。

図：IAM過剰権限の影響

[アプリ / EC2]
     │
     ├─ 本来必要：S3 read
     │
     └─ 実際付与：*
            ↓
   削除・作成・権限変更まで可能

切り分け（最短コース）

  1. IAMロールの付与ポリシー確認

    • AWS / Azure / GCP 管理画面

  2. Administrator系権限の有無確認

  3. 実際に使っている操作の洗い出し

    • API

    • サービス

  4. CloudTrail / Activity Log の確認

    • 使われていない権限がないか

  5. ロールの利用範囲確認

    • どのリソースから使われているか

今すぐ効く対処（テンプレ）

◆ まずやるべきこと

  • フル権限ポリシーを外す

  • 必要なサービスだけに絞る

  • Read / Write を分離する

◆ 最小権限の考え方（例）

  • S3 読み込みだけ必要
    → s3:GetObject のみ

  • ログ出力だけ必要
    → logs:PutLogEvents のみ

※ 「動いたからOK」は設計ミス。

恒久対策／再発防止チェックリスト

  • Administrator権限を原則禁止

  • 最小権限ポリシーを設計

  • マネージドポリシーを精査

  • 検証用と本番用ロールを分離

  • 利用実績ベースで権限を削減

  • 定期的に権限棚卸し

  • ロール用途をドキュメント化

  • 「とりあえず付与」を禁止

落とし穴（やりがちミス）

  • エラーが出たら権限を足す

  • 使ってない権限を放置

  • 1ロールを全用途で使う

  • マネージド＝安全と思う

  • 権限削減を怖がる

まとめ（行動指針）

IAMロールは、
「便利さ」と「被害範囲」を交換している。

必要な操作を洗う → 最小限で許可 → 定期的に削る。
この3点を回すだけで、
クラウド事故の“爆発力”は確実に下げられる。

いいなと思ったら応援しよう！