クラウドセキュリティ

IAMポリシーあいえーえむぽりしー

IAMアクセス制御AWS権限管理ロール最小権限の原則

IAMポリシーについて教えて

簡単に言うとこんな感じ！

クラウド上の「誰が・何に・何をしていいか」を書いた許可証みたいなものだよ。社員証に「この人は倉庫に入れるけど金庫はダメ」って書いてある感じで、サービスやユーザーごとに細かく操作範囲を決められるんだ！

IAMポリシーとは

IAM（Identity and Access Management）ポリシーとは、クラウド環境においてユーザー・グループ・サービスがどのリソースに対してどんな操作を実行できるかを定義したルール文書のことです。AWSをはじめとする主要クラウドサービスで採用されており、JSON形式で記述されるのが一般的です。

IAMポリシーの最大の目的は最小権限の原則（Principle of Least Privilege）を実現することです。「必要最低限の権限しか与えない」という考え方で、万が一アカウントが乗っ取られたり、設定ミスがあったりしたときでも、被害の範囲を最小限に抑えられます。たとえば、請求情報を確認するだけの担当者に、サーバーを削除する権限まで与える必要はないですよね。

ビジネス上の判断としては、「クラウドの権限管理が雑だと情報漏えいや意図しない課金の原因になる」という点が重要です。IAMポリシーはその防衛線であり、システム発注時にベンダーへ「IAMの設計方針はどうなっていますか？」と問うことが、セキュリティ品質を見極めるひとつの指標になります。

IAMポリシーの構造と仕組み

IAMポリシーはいくつかの要素で構成されます。AWSを例にすると、JSON形式で以下のように書かれます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

各キーの意味は次の通りです。

キー	意味	例
`Effect`	許可か拒否か	`Allow` / `Deny`
`Action`	実行できる操作	`s3:GetObject`（ファイル取得）
`Resource`	対象のリソース	特定のS3バケット
`Condition`	条件（任意）	IPアドレス制限など
`Principal`	誰に適用するか	ユーザー・ロール・サービス

覚え方：「誰が・何を・どこに・どうする」

IAMポリシーの読み方は「誰が（Principal）・何を（Action）・どこに（Resource）・許可/拒否（Effect）」と整理すると迷いません。「社員証（誰が）・倉庫の扉（どこに）・開ける操作（何を）・OK（許可）」と置き換えると、非エンジニアの方にも説明しやすいです。

ポリシーの種類と使い分け

種類	説明	典型的な使い方
管理ポリシー（AWS管理）	AWSが事前に用意した汎用ポリシー	読み取り専用など定番の権限
管理ポリシー（カスタマー管理）	自社で作成・管理するポリシー	業務に合わせた独自ルール
インラインポリシー	ユーザーやロールに直接埋め込むポリシー	例外的な個別設定
リソースベースポリシー	リソース側に付けるポリシー	S3バケットへのクロスアカウントアクセス
SCPサービスコントロールポリシー	組織全体に適用する上位制約	全社でのリージョン制限など

歴史と背景

2006年 AWSがサービス開始。当初は権限管理が大まかで、ルートアカウント（全権限）を共有するケースも多かった
2010年 AWSがIAMを正式リリース。ユーザー・グループ・ポリシーという現在の基本構造が確立
2012年 ポリシーのバージョン管理機能（Version: 2012-10-17）が追加。現在も標準として使われる
2015年頃〜 マイクロサービスやサーバーレス（Lambda等）の普及で、「サービスがサービスを呼ぶ」構造が増え、ロール（Role）への権限付与がより重要に
2019年 AWSがIAM Access Analyzerを提供開始。意図しない公開設定や過剰な権限を自動検出できるように
現在 AzureのRBAC・Google CloudのIAMなど、他クラウドも類似の仕組みを持ち、マルチクラウド環境での権限設計が課題になっている

IAMポリシーが関わる主要コンポーネント

IAMポリシーは単独ではなく、IAMの各要素と組み合わせて機能します。

IAMロールとIAMユーザーの違い

	IAMユーザー	IAMロール
用途	人間が使うアカウント	サービスやシステムが引き受ける
認証情報	固定のパスワード・アクセスキー	一時的なトークンを自動発行
セキュリティ	キー漏えいリスクあり	漏えいリスクが低い
推奨場面	管理者・開発者	Lambda・EC2・外部連携

💡 発注時のチェックポイント： 「アクセスキーを使い回していないか」「ロールで権限を管理しているか」をベンダーに確認しましょう。アクセスキーの放置はセキュリティインシデントの定番原因です。

規格・RFC番号	内容
RFC 7519	JWT（JSON Web Token）— IAMの一時認証トークンの基盤技術
RFC 6749	OAuth 2.0 — IAMロールの委任認可フローに使われる標準
RFC 7642	SCIM — ユーザーのプロビジョニング（IAMユーザー自動作成）に関連