セクション 02 · タスク 1.2 · SAP-C02-013

エンタープライズIDとアクセス制御の全体像

認証 / 認可 / AWS Identity and Access Management（IAM） / IAMロール / IAMポリシー / 最小特権 / エンタープライズアクセス

このページのゴール

アクセス主体を人間・ワークロード・例外用途に分け、適切なアイデンティティと認証情報を選び、IAMポリシーで最小特権の認可へ落とし込めることをゴールにします。

1. エンタープライズアクセスは「誰・どう認証・何を許可」で考える

AWSへのアクセスを設計するとき、最初からIAMユーザーやIAMロールを選びません。まず次の3つを分けます。

① 誰がアクセスする？
        ↓
   人 / ワークロード

② どう本人・主体を確認する？
        ↓
   認証

③ 何を実行させる？
        ↓
   認可

この3つを混ぜると、ログインできた = AWS内で何でもできるという誤った理解につながります。

2. 認証と認可

認証は「誰なのか」を確認する処理です。

認可は、認証された主体が「何を実行してよいか」を決める処理です。

ユーザー / ワークロード
       │
       ▼
認証
誰なのか？
       │
       ▼
認証済みプリンシパル
       │
       ▼
認可
何を許可？
       │
       ▼
AWSリソース

したがって、認証に成功していても、必要なアクセス許可がなければAPIリクエストは拒否されます。AWSはリクエストを受信すると、必要に応じてプリンシパルを認証し、リクエストコンテキストと適用されるポリシーを評価して最終的な許可 / 拒否を判断します。

3. 最初に「誰がアクセスするか」を分類する

エンタープライズ環境ではアクセス主体を大きく分けます。

主体	基本設計
社員・管理者・開発者	フェデレーション / AWS IAM Identity Center + 一時的認証情報
EC2 / Lambda / ECS / EKSなどのワークロード	IAMロール + 一時的認証情報
一時的認証情報を利用できない特殊なツール	IAMユーザーを限定的に検討
AWSアカウントのルートアクセス	Organizationsのメンバーアカウントでは一元管理を優先し、不要な長期ルート認証情報を削減する

AWS Organizationsで管理するメンバーアカウントでは、IAMのルートアクセスの一元管理を利用できます。不要なメンバーアカウントの長期ルート認証情報を削除し、対応する特権操作は管理アカウントまたはIAMの委任管理者から短期の特権ルートセッションで実行できます。ルートユーザーでのサインイン自体が必要な例外操作では、必要な期間だけ認証情報の復旧を許可し、完了後は再び削除する設計を検討します。

この分類が、後続のアイデンティティ設計の起点です。

4. 人間のアクセスはフェデレーションを基本にする

大企業に社員が3,000人いる場合、各AWSアカウントへ社員ごとのIAMユーザーを大量作成する設計を標準にはしません。

従業員
   │
   ▼
企業アイデンティティ
   │
   ▼
フェデレーション
   │
   ▼
一時的な認証情報
   │
   ▼
AWS

企業がすでに持っているアイデンティティ提供側やAWS IAM Identity Centerを利用し、AWSアカウントごとに大量の長期認証情報を管理する必要を減らします。

AWS IAM Identity Centerや外部IdPとの具体的な連携方式は、後で詳しく扱います。

5. ワークロードにはIAMロール

EC2上のアプリケーションからS3へアクセスするとします。避けたいのは、アプリケーションコードへ長期アクセスキーを保存して利用する設計です。

EC2 / Lambda / ECS / EKS
        │
        ▼
     IAMロール
        │
        ▼
一時的な認証情報
        │
        ▼
    AWSサービス

IAMロールには通常の長期パスワードやアクセスキーが関連付けられず、ロールセッションでは一時的なセキュリティ認証情報を利用します。

AWSワークロード
+
AWS APIへアクセス
↓
IAMユーザーのアクセスキーを埋め込まない
↓
IAMロールを評価

6. IAMユーザーは「例外」として判断する

IAMユーザーそのものが禁止されているわけではありません。IAMユーザーはパスワードやアクセスキーなどの長期認証情報を持つことができます。

レガシー外部ツール
↓
一時的な認証情報非対応
↓
ロール / フェデレーションも利用不可
↓
固定アクセスキーが必須

このような制約が本当にある場合は、必要最小限の権限を持つIAMユーザーを限定的に検討します。

人間だからIAMユーザー、アプリケーションだからIAMユーザーとは判断しません。

7. IAMユーザーとIAMロールを比較する

項目	IAMユーザー	IAMロール
IAM アイデンティティ	○	○
権限ポリシー	○	○
コンソールパスワード	設定可能	持たない
長期アクセスキー	設定可能	持たない
一時的な認証情報	主目的ではない	基本
人の標準エンタープライズアクセス	原則選ばない	フェデレーション等から利用
AWSワークロード	例外	基本

重要なのは、ユーザーかロールかを名前で覚えるのではなく、長期認証情報が本当に必要かで判断することです。

8. IAMポリシーが認可を定義する

アイデンティティを決めただけでは、AWSリソースを操作できません。何を許可するかはIAMポリシーで定義します。

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::company-reports/*"
}

設計判断では次の要素を読みます。

Effect
→ 許可 / 拒否

アクション
→ 何を実行？

リソース
→ 何に対して？

Condition
→ どんな条件なら？

9. アクションだけで最小権限を考えない

Action: s3:GetObjectまで絞っていても、Resource: *なら対象範囲が広すぎる可能性があります。

必要なのがcompany-reportsだけなら、次のように必要な範囲へ絞ります。

アクション
→ s3:GetObject

リソース
→ company-reports配下

Condition
→ 必要なら追加制約

最小特権は、アクション + リソース + 条件で考えます。

10. 条件で利用条件も制限できる

アクションとリソースだけでは表現できない要件もあります。例えば「S3 GetObjectは許可するが、指定したVPCエンドポイントを経由するリクエストだけに制限する」といった要件です。

何を？
→ アクション

何に？
→ リソース

どんな条件で？
→ Condition

条件を使うことで、追加の利用条件をポリシー評価へ組み込めます。

11. AWSは拒否を前提に評価する

認可の基本は次の流れです。

最初
↓
暗黙的な拒否

適用される許可あり
↓
許可候補

明示的な拒否あり
↓
拒否

適用される許可がなければ暗黙的な拒否になります。また、許可と拒否の両方が適用される場合、明示的な拒否が許可より優先します。

したがって、許可ポリシーがある = 必ず実行可能ではありません。

12. 最小権限は「必要な範囲だけ許可する」

最小権限（最小特権）は、業務を実行するために必要な権限だけを付与するという原則です。

開発アプリケーションが必要なのがcompany-reports/*へのs3:GetObjectだけなら、無関係なec2:*やrds:*まで恒久的に許可する理由はありません。

AWSのIAMベストプラクティスでも最小特権を適用することが推奨されています。

13. エンタープライズアクセスはアイデンティティと権限を分離して設計する

人とワークロードではアイデンティティを得る方法が異なりますが、最終的には「そのセッションで何を許可するか」という認可が必要です。

人
↓
企業アイデンティティ
↓
フェデレーション
↓
一時的な認証情報
↓
権限
↓
AWS リソース

ワークロード
↓
IAMロール
↓
一時的な認証情報
↓
権限
↓
AWS リソース

14. 要件からアイデンティティを選ぶ

要件	基本判断
多数の社員が複数AWSアカウントへアクセス	フェデレーション / AWS IAM Identity Center
EC2からS3へアクセス	IAMロール
LambdaからDynamoDBへアクセス	IAMロール
ECS / EKS ワークロードからAWS APIへアクセス	IAMロール
レガシーツールが固定アクセスキーしか利用できない	IAMユーザーを限定検討
Organizationsメンバーアカウントの特権操作	一元化したルートアクセスと短期の特権ルートセッションを優先し、ルートサインインが必要な操作だけ認証情報を復旧する
`s3:*`を特定操作へ縮小したい	IAMポリシーを最小権限化

プリンシパルの種類
↓
認証情報方式
↓
権限

を一体で判断します。

15. 混同ポイント

認証成功 = 認可成功：本人確認が成功しても、必要な権限がなければAPIは拒否されます。
IAMロール = EC2専用：ワークロード、人間のフェデレーション、AWSサービスなど複数の用途で使われます。
IAMユーザー = 常に禁止：一時的な認証情報へ移行できない例外用途では検討できます。
IAMロール = 長期アクセスキー：ロールセッションでは一時的な認証情報を使います。
許可が1つある = 必ず許可：明示的な拒否が適用されれば拒否されます。
最小権限 = アクションだけ絞る：リソースと条件も判断します。

16. SAP-C02判断フロー

誰がAWSへアクセス？
        │
        ├─ 人
        │    ↓
        │  フェデレーション /
        │  IAM Identity Center
        │
        ├─ ワークロード
        │    ↓
        │  IAMロール
        │
        └─ 一時的な認証情報非対応
             ↓
           IAM ユーザーを限定検討

        ↓

認証
誰なのか？

        ↓

認可
何を許可？

        ↓

IAM ポリシー

        ↓

アクション
リソース
Condition

        ↓

最小権限

17. まとめ

エンタープライズアクセス
↓
まずプリンシパルを分類

人
→ フェデレーション + 一時的な認証情報

ワークロード
→ IAMロール + 一時的な認証情報

固定認証情報必須の例外
→ IAM ユーザーを限定検討

認証
→ 誰なのか

認可
→ 何を許可するか

IAM ポリシー
→ Effect / アクション / リソース / Condition

権限なし
→ 暗黙的な拒否

明示的な拒否
→ 許可より優先

最小権限
→ 必要なアクション / リソース / Conditionだけ

最重要ポイント：「IAMユーザーかIAMロールか」から考え始めず、誰がアクセスするのか、どうアイデンティティを得るのか、何を許可するのかを順に分けます。

18. 主要AWS公式資料

理解確認

このページの内容を12問で確認します。

理解確認12問へ →