IAM グループを使うべき理由：ユーザーへの直接ポリシーアタッチとの比較

新しい開発者が入社するたびに、IAM ユーザーを作成してポリシーを一枚一枚アタッチしていた運用が、ある日突然破綻する。10人のユーザーに同じポリシーを直接アタッチしていた環境で権限変更が必要になったとき、10回の手作業が発生する。IAM グループはこの問題を構造的に解決するための仕組みだ。

TL;DR：IAM グループ vs. ユーザーへの直接アタッチ

観点ユーザーへの直接アタッチIAM グループ経由
権限変更のコスト対象ユーザー数分の操作が必要グループポリシーを1回変更するだけ
新規ユーザーへの権限付与毎回ポリシーを手動アタッチグループに追加するだけ
権限の一貫性ユーザーごとにズレが生じやすいグループ単位で統一される
監査・レビューのしやすさユーザーごとに確認が必要グループのポリシーを見れば全体像が分かる
IAM ポリシー上限への影響ユーザーあたりのアタッチ上限を消費グループ側で集約できる

IAM グループの仕組みを理解する

IAM グループはユーザーの集合体であり、それ自体がプリンシパルとして AWS リソースにアクセスするわけではない。グループにアタッチされたポリシーは、そのグループに所属するすべての IAM ユーザーに対して有効になる。ユーザーが複数のグループに所属している場合、各グループのポリシーはすべて評価される。

重要な点として、IAM グループは IAM ロールとは異なり、フェデレーションユーザーや AWS サービスに対してアタッチすることはできない。また、グループをネストする（グループの中にグループを入れる）ことも IAM ではサポートされていない。

graph TD GroupDev["IAM グループ: Developers"] GroupOps["IAM グループ: Operators"] PolicyS3["ポリシー: S3ReadOnly"] PolicyEC2["ポリシー: EC2FullAccess"] UserAlice["IAM ユーザー: alice"] UserBob["IAM ユーザー: bob"] UserCarol["IAM ユーザー: carol"] PolicyS3 -->|アタッチ| GroupDev PolicyEC2 -->|アタッチ| GroupOps GroupDev -->|所属| UserAlice GroupDev -->|所属| UserBob GroupOps -->|所属| UserBob GroupOps -->|所属| UserCarol
  1. IAM ユーザーが複数のグループに所属できる。
  2. IAM グループにポリシーをアタッチすると、所属する全ユーザーに権限が伝播する。
  3. ユーザーには直接ポリシーをアタッチすることも可能だが、グループ経由との組み合わせで権限が累積される。
  4. IAM ポリシー評価では、明示的な Deny が Allow より優先される。

IAM グループを使うべき具体的な理由

権限管理のスケーラビリティ

直接アタッチ方式の本質的な問題は、ユーザー数に比例して管理コストが増加することだ。'Developers' グループに AmazonS3ReadOnlyAccess をアタッチしておけば、新しい開発者をグループに追加するだけで権限が付与される。逆に権限を剥奪したい場合も、グループからユーザーを外すか、グループのポリシーを変更するだけで済む。

権限の一貫性と監査容易性

直接アタッチ方式では、同じ役割のユーザーでも付与されているポリシーがバラバラになりやすい。誰かが追加でポリシーをアタッチしたり、古いポリシーが残り続けたりする。グループ経由であれば、'Developers' グループのポリシーを確認するだけで、その役割に付与されている権限の全体像が把握できる。

グループは権限の設計図だ。ユーザーはその設計図を実体化するインスタンスに過ぎない。設計図を変えれば、すべてのインスタンスに変更が反映される。

IAM ポリシーのアタッチ上限を効率的に使う

IAM ユーザーに直接アタッチできるマネージドポリシーの数には上限がある。グループ経由でポリシーを付与することで、ユーザー直接アタッチ枠を節約できる。上限の具体的な数値はサービスクォータとして変動する可能性があるため、常に AWS 公式ドキュメントのクォータページで確認すること。

IAM グループの作成とポリシーアタッチ：実際の操作

グループの作成

aws iam create-group \
  --group-name Developers

グループへのマネージドポリシーアタッチ

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

ユーザーをグループに追加

aws iam add-user-to-group \
  --group-name Developers \
  --user-name alice

グループにアタッチされているポリシーの確認

グループの権限を棚卸しするとき、まずここを見る。

aws iam list-attached-group-policies \
  --group-name Developers

グループに所属するユーザーの確認

aws iam get-group \
  --group-name Developers

カスタムポリシーをグループにアタッチする例

AWS マネージドポリシーではなく、自前で作成したカスタムポリシーをグループにアタッチする場合は以下のようになる。

🔽 カスタムポリシーの作成とアタッチ（クリックして展開） 
# カスタムポリシードキュメントの作成
cat > developer-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-dev-bucket",
        "arn:aws:s3:::my-dev-bucket/*"
      ]
    }
  ]
}
EOF

# ポリシーの作成
aws iam create-policy \
  --policy-name DeveloperS3Access \
  --policy-document file://developer-policy.json

# グループへのアタッチ
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::123456789012:policy/DeveloperS3Access

現場でよくある誤解と実際の失敗パターン

あるチームで、IAM ユーザー全員に直接 AdministratorAccess をアタッチしていた運用があった。退職者が出たときにユーザーを削除したが、残留していた別のユーザーに同じポリシーが直接アタッチされたままになっていることに気づいたのは、数ヶ月後の監査のときだった。

最初の誤解は「ユーザーを削除すれば権限は消える」というものだった。確かに削除されたユーザーの権限は消える。しかし問題は、直接アタッチ方式では各ユーザーの権限状態を個別に追跡しなければならないことだ。グループ経由であれば、グループのポリシーと所属ユーザーの2点だけを管理すれば済む。

実際の原因は、オンボーディング手順書に「ユーザーを作成してポリシーをアタッチする」と書かれていたことだった。グループへの追加という手順がなく、担当者が変わるたびに手順の解釈がブレていた。グループを使う運用に切り替えた後は、新規ユーザーの権限付与手順が「グループに追加する」の1ステップになり、手順書の解釈ブレも解消された。

graph LR subgraph 直接アタッチ方式 U1["alice"] -->|個別ポリシー A| R1["S3"] U2["bob"] -->|個別ポリシー B| R1 U3["carol"] -->|個別ポリシー A+C| R1 end subgraph グループ経由方式 G1["Developers グループ
ポリシー: S3ReadOnly"] U4["alice"] -->|所属| G1 U5["bob"] -->|所属| G1 U6["carol"] -->|所属| G1 G1 -->|統一された権限| R2["S3"] end
  1. 直接アタッチ方式では、ユーザーごとにポリシーの状態が異なる可能性がある。
  2. グループ経由では、グループのポリシーが単一の真実の情報源となる。
  3. 退職者対応はグループからの削除またはユーザー無効化で完結する。

IAM グループ設計のベストプラクティス

役割ベースでグループを設計する

グループは組織の役割（Developers、Operators、ReadOnly、Billing など）に対応させるのが基本だ。プロジェクト単位でグループを作ることもあるが、役割ベースとプロジェクトベースを混在させると権限の見通しが悪くなる。

ユーザーへの直接アタッチを例外的な用途に限定する

特定のユーザーだけに一時的に追加権限を付与したい場合など、例外的なケースでは直接アタッチが有効な場面もある。ただし、その場合も付与した理由と期限をタグや運用ドキュメントに記録しておくこと。恒久的な権限はグループで管理し、例外的・一時的な権限のみ直接アタッチという使い分けが現実的だ。

最小権限の原則を守る

グループにポリシーをアタッチする際も、最小権限の原則は変わらない。'Developers' グループだからといって AdministratorAccess をアタッチするのではなく、実際に必要なアクションとリソースに絞ったカスタムポリシーを作成してアタッチすること。

既存ユーザーの直接アタッチ状況を棚卸しする

既存環境でユーザーへの直接アタッチがどれだけあるかを確認するには以下のコマンドが使える。

aws iam list-users --query 'Users[*].UserName' --output text | \
  tr '\t' '\n' | \
  while read username; do
    policies=$(aws iam list-attached-user-policies \
      --user-name "$username" \
      --query 'AttachedPolicies[*].PolicyName' \
      --output text)
    if [ -n "$policies" ]; then
      echo "$username: $policies"
    fi
  done

このスクリプトは直接アタッチされたマネージドポリシーを持つユーザーを列挙する。インラインポリシーを確認したい場合は list-user-policies コマンドを別途実行すること。

IAM グループ活用のまとめと次のステップ

IAM グループを使う理由は単純だ。ユーザーへの直接アタッチは、ユーザー数が増えるにつれて管理コストと権限の不整合リスクが線形に増加する。グループ経由にすることで、権限の変更・付与・剥奪がグループ単位で完結し、監査時の確認コストも大幅に下がる。

次のステップとして、より大規模な組織や複数 AWS アカウントを管理する場合は、AWS IAM Identity Center（旧 AWS SSO）を使ったフェデレーション認証と権限セットの管理を検討すること。IAM ユーザーとグループの運用は単一アカウントの小規模環境には適しているが、マルチアカウント環境では IAM Identity Center が推奨される。

用語集

用語説明
IAM グループIAM ユーザーの集合体。グループにアタッチしたポリシーは所属する全ユーザーに適用される。グループ自体はプリンシパルではない。
マネージドポリシーAWS が管理する AWS マネージドポリシーと、ユーザーが作成するカスタマーマネージドポリシーの2種類がある。複数のエンティティにアタッチ可能。
インラインポリシー特定の IAM エンティティ（ユーザー・グループ・ロール）に直接埋め込まれたポリシー。エンティティを削除すると一緒に削除される。
最小権限の原則タスクを実行するために必要な最小限の権限のみを付与するセキュリティ原則。
明示的な DenyIAM ポリシー評価において、明示的な Deny は Allow より必ず優先される。SCP による Deny も同様に機能する。

Related Posts

コメント

コメントを投稿

このブログの人気の投稿

SQS Visibility Timeoutの完全解説：メッセージ二重処理の原因と対策

SQSキューから取得したメッセージが複数のコンシューマーに重複処理される——この問題はVisibility Timeoutの設定ミスが原因であることがほとんどだ。処理時間がタイムアウト値を超えた瞬間、SQSはそのメッセージを「未処理」と判断して再度可視化し、別のワーカーが同じメッセージを拾ってしまう。 TL;DR：Visibility Timeoutとは何か 項目 内容 定義 コンシューマーがメッセージを受信してから、他のコンシューマーに見えなくなる時間 デフォルト値 30秒 設定範囲 0秒〜43,200秒（12時間） 二重処理の原因 処理時間がVisibility Timeoutを超えるとメッセージが再可視化される 対策 処理時間に余裕を持たせた値を設定、または処理中に延長APIを呼ぶ 削除タイミング 処理完了後に明示的に DeleteMessage を呼ぶ必要がある Visibility Timeoutの仕組みを理解する SQSはメッセージを受信した時点でそのメッセージを一時的に「不可視」にする。これはキューからメッセージを削除するわけではなく、他のコンシューマーから見えなくするだけだ。コンシューマーが処理を完了して DeleteMessage を呼べばメッセージは消える。しかしVisibility Timeoutが切れる前に削除されなければ、メッセージはキューに戻り、再度取得可能になる。 この設計は意図的なものだ。コンシューマーがクラッシュしたり応答しなくなった場合に、メッセージが失われないようにするためのフェイルセーフとして機能している。問題は、正常に動作しているコンシューマーの処理時間がタイムアウトを超えたときに、同じフェイルセーフが誤発動することだ。 sequenceDiagram participant CA as コンシューマーA participant SQS as SQS キュー participant CB as コンシューマーB CA->>SQS: ReceiveMessage SQS...
続きを読む

EC2 SSH接続タイムアウトの原因と修正方法 — セキュリティグループのインバウンドルール完全ガイド

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...
続きを読む

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...
続きを読む