AWS IAMによるアクセス管理

AWS Identity and Access Management（IAM）は、AWSアカウント内のユーザーやワークロードが、どのAWSサービス・リソースに対して、どの操作を実行できるかを制御する仕組みです。誰がリクエストを行うかという主体（プリンシパル）と、その主体に許可する操作を記したポリシーを組み合わせます。

IAMはセキュリティとガバナンスの基盤です。開発者がAWS APIを呼び出す場合も、アプリケーションに必要な権限を過不足なく与え、認証情報を安全に扱う必要があります。AWSの認証・認可を整理すると、次のようになります。

認証と認可を区別する

• **認証（Authentication）**は、リクエストを行う主体が何者かを確認することです。コンソールのサインインではパスワードや多要素認証（MFA）、APIリクエストでは署名に使う認証情報などが関係します。
• **認可（Authorization）**は、認証された主体が要求した操作を対象リソースに対して実行できるかを判定することです。サインインできることは、すべてのAWSサービスを操作できることを意味しません。

たとえば、デプロイ担当者がコンソールにサインインできても、指定されたアプリケーション設定の読み取りだけを許可されていれば、データベースの削除や他の設定の変更は認可されません。認証情報の有効性と、ポリシーによる操作権限は別々に評価されます。

IAMの主体と権限付与の単位

プリンシパル

プリンシパルはAWS APIなどのリクエストを行う主体です。IAMユーザーやIAMロールを引き受けたセッション、AWSサービスなどが該当します。人が操作する場合だけでなく、Lambda関数やデプロイ処理といったワークロードも、権限を持つアイデンティティを通じてAWSにアクセスします。

IAMユーザー

IAMユーザーはAWSアカウント内のアイデンティティで、個人やシステムを表せます。ユーザーには、AWSマネジメントコンソールへのサインイン用パスワードや、プログラムからAWS APIを呼び出すためのアクセスキーIDとシークレットアクセスキーなど、用途に応じた認証情報を設定できます。

認証情報の扱いはアクセス経路により異なります。

アクセス経路	代表的な認証情報	用途と注意点
マネジメントコンソール	パスワード。必要に応じてMFAを併用	ブラウザーでの対話的なサインインに使う。パスワードだけに依存せずMFAを有効にする
AWS CLI・SDK・API	アクセスキーIDとシークレットアクセスキー、または一時認証情報	APIリクエストの署名などに使う。アクセスキーは秘密情報として保護し、コードやリポジトリに埋め込まない

IAMユーザーのアクセスキーは長期認証情報です。キーが漏えいすると第三者に悪用される可能性があるため、通常のワークロード認証に恒久的なキーを使う設計は避けます。現在の推奨では、人のAWSアクセスには外部IdPなどを用いたフェデレーションと一時認証情報を、AWS上のワークロードにはIAMロールによる一時認証情報を優先します。

長期アクセスキーを必要とする限定的な用途がある場合は、少なくとも次を徹底します。

1. 必要な操作・リソースに絞った最小権限を与える。
2. ソースコード、設定ファイル、コンテナイメージ、公開リポジトリなどへキーを直接書き込まない。環境変数はソースへの直書きより望ましい場合がありますが、それだけで秘密情報管理が完了するわけではありません。可能なら専用のシークレット管理機能や一時認証情報を使う。
3. 利用者・保管場所・利用経路を明確にし、アクセスを必要なネットワークや条件に制限できる場合はポリシー条件を検討する。IPアドレス条件は固定された送信元など要件に合う場合に限り、認証情報保護の代替にはしない。
4. 利用状況と最終使用を定期的に確認し、不要なキーを無効化・削除する。
5. 長期キーを継続使用する場合は、手順を整えて定期的にローテーションし、旧キーの無効化・削除まで確認する。

IAMグループ

IAMグループは、IAMユーザーをまとめて権限を管理するための単位です。グループにアイデンティティベースのポリシーを付け、そのグループへユーザーを追加すると、所属するユーザーにその権限が適用されます。担当業務や役割に応じたグループにユーザーを割り当てれば、ユーザーごとに同じポリシーを重複して付与する作業を減らし、権限のばらつきも抑えられます。

組織の規模が大きくなりユーザー数が増えるほど、個々のユーザーを直接管理するより、役割に合ったグループを設計して所属を管理する方が変更に対応しやすくなります。異動時は不要になったグループから外し、新しい担当に必要なグループへ追加することで、権限を見直せます。

一方、グループ自体は認証される主体ではありません。ポリシーでプリンシパルとして指定できず、グループにサインインさせることもできません。また、グループに別のグループやロールを入れ子にすることはできず、ユーザーを一つのグループに限定する必要もありません。ユーザーは複数のグループに所属できます。アカウント内の全ユーザーを自動的に含む既定グループもありません。

ポリシーで権限を定義する

IAMポリシーはJSON形式のドキュメントで、許可または拒否する操作と対象、必要に応じて追加条件を記述します。アイデンティティにポリシーを付ける場合と、AWSリソースにポリシーを付ける場合とで、ポリシーが結び付く対象やPrincipalの扱いが異なります。

ポリシー文書の主な要素

要素	役割
Version	ポリシー言語のバージョンを示す。通常は現行のポリシー言語バージョン 2012-10-17 を指定する
Statement	権限ルールの集合。複数のステートメントを記述できる
Sid	ステートメントを識別する任意の名前
Effect	操作を許可する Allow または拒否する Deny
Action	対象サービスで許可または拒否するAPIアクション
Resource	アクションの対象となるAWSリソース
Principal	リソースベースのポリシーなどで、リクエストを許可・拒否する主体を指定する
Condition	IPアドレス、タグ、時間、MFAの有無など、評価に加える条件を指定する

Principalはすべてのポリシーに書く共通の必須項目ではありません。アイデンティティベースのポリシーはユーザー・グループ・ロールに付けて権限を定義するため、通常その文書内でPrincipalを指定しません。対してリソースベースのポリシーはリソース側に付け、誰にアクセスを認めるかをPrincipalで表します。

アイデンティティベースのポリシー

アイデンティティベースのポリシーはIAMユーザー、グループ、ロールなどに付け、そのアイデンティティがどの操作をどのリソースに対して行えるかを定義します。代表的な管理方法は次の3つです。

• AWS管理ポリシー：AWSが作成・管理する再利用可能なポリシーです。一般的な用途から始める際に利用できますが、広範な権限を持つものもあるため、名前だけでなく付与内容が要件に合っているかを確認します。
• カスタマー管理ポリシー：利用者が作成・管理し、複数のアイデンティティに再利用できます。必要な操作、リソース、条件に合わせて調整しやすく、権限設計を集中管理できます。
• インラインポリシー：特定のユーザー、グループ、ロールに直接埋め込むポリシーです。アイデンティティと一対一で管理され、そのアイデンティティを削除するとポリシーも削除されます。共有・再利用する権限には管理ポリシーを検討します。

リソースベースのポリシー

リソースベースのポリシーは、対応するAWSリソースに付け、そのリソースへのアクセスを誰に認めるか、どの操作を許すかを定義します。たとえば、データ保管先のリソース側で、別のAWSアカウントにある特定のロールからのアクセスを許可する、といったクロスアカウントの設計に使えます。どのサービス・リソースがこの方式をサポートするかはサービスごとに異なります。

IAMのアクセス判定と最小権限

アクセス判定では、ポリシーが許可するアクションだけでなく、明示的な拒否や適用される上限も考慮します。基本として、明示的なDenyはAllowより優先されます。また、明示的な許可が得られないアクセスは許可されません。したがって、あるポリシーにAllowがあることだけを確認しても、最終的な許可を保証できません。

権限設計では、業務を遂行するために必要な操作だけを、必要なリソースと条件に限定して許可します。これが最小権限の原則です。開発時に広い権限を一時的に与えたまま本番運用へ持ち込まず、実際のアクセスを確認しながら不要なアクションや対象を削っていきます。AWS管理ポリシーを出発点にする場合も、用途に合うかを見直し、必要に応じてカスタマー管理ポリシーで絞り込みます。

IAMポリシーに条件を設けることで、許可をさらに限定できます。たとえば特定のタグが付いたリソースに対象を絞る、許可されたネットワーク経由に限定する、といった方法があります。ただし、条件が要件を満たすかを確認し、意図しないアクセスや正規アクセスの遮断につながらないよう検証が必要です。

ルートユーザーを保護する

ルートユーザーはAWSアカウント作成時に用意されるアカウント所有者のアイデンティティです。サインインにはアカウントに関連付けられたメールアドレスとパスワードを使用し、アカウント内で非常に強い権限を持ちます。日常運用をルートユーザーに依存せず、必要な作業は権限を適切に委譲したIAMロールや、組織で管理するアクセス手段を使って行います。

ルートユーザーには、通常の管理用アイデンティティだけでは実行できない、ルート認証情報を必要とする一部のタスクがあります。請求・アカウント管理関連も設定や操作の内容に応じて必要権限が異なり、「あらゆる請求・アカウント設定は常にルートだけ」と一括りにはできません。AWS Organizationsの管理アカウントや委任管理者からメンバーアカウントに対して実施できるアカウント管理操作もあります。アカウントの閉鎖についても、単独アカウントとOrganizations配下のメンバーアカウントで実行経路が異なる場合があります。必要なタスクの最新要件を確認してください。

ルートユーザーの保護では、次の対策が重要です。

1. MFAを有効にする。ルートユーザーは強い保護対象であり、パスワードだけで守らない。
2. ルートユーザーのアクセスキーを作成しない。プログラムによるアクセスをルート認証情報に結び付けず、必要な権限を持つロールなどを使用する。
3. 日常業務に使わない。ルートでしか実行できない操作に限定し、普段の管理作業は別のアイデンティティへ委譲する。
4. 認証情報を安全に保管し、利用を監視する。ルートのメールアドレスやパスワードを共有・放置せず、使用履歴を確認する。

Organizationsを使う環境では、メンバーアカウントのルートアクセスを組織として集中管理できる機能があります。これを用いると、メンバーアカウントのルート認証情報を削除して、管理アカウントなどから特権タスクを実行できる構成も取れます。組織設定とタスク要件に依存するため、単独アカウントのルートユーザー運用と混同しないようにします。

OrganizationsのSCPは権限を付与しない

AWS Organizationsのサービスコントロールポリシー（SCP）は、組織・組織単位（OU）・アカウントに対して、メンバーアカウント内のIAMユーザーやロールが利用できる権限の上限を定めるガードレールです。たとえば組織のポリシーで特定のサービス操作を禁止すれば、アカウント内のIAMポリシーで許可していても、その操作を制限できます。

SCP自体は、IAMユーザーやロールに権限を付与しません。実際に操作を許可するには、IAMのアイデンティティベースまたはリソースベースのポリシーによる許可が別途必要です。したがって、SCPをアタッチしただけでAPIを呼べるようになるわけではなく、SCPは許可範囲の上限を管理するものとして理解します。Organizationsの設定・ポリシー種別・アカウント種別によって適用関係に差があるため、対象アカウントへの作用範囲も確認が必要です。

DVAでの判断ポイント

• 人がコンソールやCLIから作業する：フェデレーションとロールの引き受けによる一時認証情報を優先します。IAMユーザーのパスワードや長期アクセスキーを人数分配布する設計と比較します。
• AWS上のアプリケーションが別サービスを呼ぶ：実行環境にIAMロールを関連付け、必要なサービスとリソースだけを許可します。キーをソースコードやデプロイ設定に固定して持たせません。
• 複数人に同じ権限が必要：IAMグループへポリシーを付け、個人にはグループ所属を通じて権限を適用します。ただしグループ自身はPrincipalではありません。
• 特定リソースへの別アカウントからのアクセスが必要：対象サービスがサポートする場合は、リソースベースポリシーでPrincipalを指定する方式を検討します。
• ポリシーで許可したはずの操作が失敗する：明示的Deny、適用中の条件、ポリシーの対象リソース、OrganizationsのSCPなど、許可を制限する要素を調べます。
• 権限が広すぎる：ActionとResourceを具体化し、条件も含めて必要範囲に絞ります。明示的Denyがある状況では、別のAllowを足すだけでは解決しません。
• ルートでしか行えない作業がある：必要タスクを確認したうえで限定的に使用し、作業後は通常の権限委譲に戻します。ルートアクセスキーを作ってアプリケーションへ渡す方法は選びません。

IAMの要点は、主体を適切に認証すること、ポリシーで必要な操作だけを認可すること、認証情報を必要最小限かつ安全に扱うことの三つです。ユーザー・グループ・ロールの役割とポリシー評価の違いを押さえ、DVAのシナリオでは長期キーより一時認証情報、個別の広い権限より最小権限を優先して判断します。

公式ドキュメント

• IAM のセキュリティベストプラクティス
• IAM ユーザーグループ
• AWS アカウントのルートユーザー
• IAM ポリシーとアクセス許可
• AWS Organizations の SCP