Least Privilege Identity設計

1. アイデンティティの候補は既習パターンから選ぶ

人によるアクセス、ワークロードアクセスでは一時的な認証情報を基本候補とし、ロール / フェデレーションで満たせない明確な理由がある場合だけ長期認証情報を持つアイデンティティを限定評価します。

アイデンティティの基本パターンを前提に、選んだアイデンティティからどのアクセス経路が成立するかを監査します。

2. IAMユーザーは「例外的に長期認証情報が必要か」で判断する

例えば外部レガシーツールがSTS / フェデレーション / ロールに対応せず、AWS APIへ固定認証情報で接続することが避けられない場合は、専用IAMユーザーを候補として評価できます。

ロール / フェデレーションで代替できない
        ↓
長期認証情報が必須
        ↓
専用IAM ユーザー
        ↓
最小権限+ 認証情報保護 / ローテーション/ 失効

「IAMユーザーは常に誤り」ではなく、一時的な認証情報へ置き換えられない要件があるかを判断します。

3. 最小権限はアクションだけでなく範囲全体で確認する

必要権限は次の観点で絞ります。

誰が
+
どのアクション
+
どのリソース
+
どの条件で

例えばアプリケーションが特定S3 プレフィックスだけを読むなら、s3:GetObjectだけでなく対象リソース範囲まで要件に合わせます。

4. 共有ロールが不要な権限を横流ししていないか確認する

権限要件が異なるワークロードを同じロールへまとめると、各ワークロードが本来不要なアクションまで取得する可能性があります。

ワークロードA → S3 読み取りワークロードB → DynamoDB 書き込み共有ロール
→ S3 読み取り + DynamoDB 書き込み

A / B双方へ不要権限が生じ得る

ロール数を増やすこと自体が目的ではなく、異なる信頼 / 権限要件を不必要に共有しないことが目的です。

5. アイデンティティベースのポリシーだけでアクセスレビューを終えない

プリンシパル側のポリシーを狭めても、リソースベースのポリシーなど別の権限経路が残っている場合があります。

アイデンティティベースのポリシー
        ↓
権限を削除しかしリソースベースのポリシー
        ↓
同じリクエストを別経路から許可？

最小権限レビューでは、リクエストへ適用されるポリシーを横断して確認します。リソースベースのポリシーの基本的なクロスアカウント方式は既習とし、ここでは別アクセス経路として見落とさないことに焦点を当てます。

6. アクセス許可境界はアイデンティティベースの権限の最大を決める

委任管理者へロール作成を許可しつつ、作成ロールがセキュリティベースラインを越えないようにしたい場合、アクセス許可境界を利用できます。

アイデンティティベースのポリシー
        ∩
アクセス許可の境界
        ↓
境界で制限されたアイデンティティベースの権限

ここで得られるのはプリンシパルの最終実効アクセスそのものではありません。リソースベースのポリシー、セッションポリシー、SCP、明示的な拒否など、リクエストへ適用される他のポリシーも別途評価します。

7. アクセス許可境界は権限を付与しない

境界にS3 読み取りが含まれていても、アイデンティティベースのポリシー側でS3 読み取りを付与していなければ、それだけでアクセスできるわけではありません。

アイデンティティポリシー→ EC2だけ許可
境界       → EC2 + S3まで許可可能境界で制限されたアイデンティティ権限
→ EC2

境界は「許可を追加するポリシー」ではなく、アイデンティティベースのポリシーが付与できる上限です。

8. アクセス境界は範囲ごとに使い分ける

「特定ロールをどこまで作成可能にするか」と「OU全体で何を禁止するか」は別範囲です。

9. リソースベースのポリシーと境界はプリンシパルの指定方法まで確認する

同一アカウントのリソースベースのポリシーでは、誰へ直接付与しているかによってアクセス許可境界などの暗黙的な拒否との関係が変わります。

明示的な拒否や適用対象のSCP等は別です。「リソースベースのポリシーなら境界を必ず迂回する」と一般化せず、プリンシパル ARNと適用対象ポリシーを確認します。

10. 一時セッションは必要ならさらに狭める

ロール自体は複数用途を持つ一方、今回のセッションでは一部権限だけ必要という場合、セッションポリシーなどで利用可能範囲をさらに制限できます。

ロール権限
        ↓
セッション範囲でさらに制限
        ↓
今回のタスクに必要な権限だけ

セッションポリシーも権限を増やすためではなく、セッションのアクセス範囲を狭める方向で使います。

11. アプリケーションのエンドユーザーに長期AWS認証情報を配布しない

ウェブ / モバイルユーザーがAWSリソースへ直接アクセスする要件がある場合、ユーザーごとのIAMユーザーとアクセスキーをアプリケーションへ配布する設計は避けます。

アプリケーションユーザー
        ↓ 認証
ユーザープール / 外部 IdP等
        ↓
Cognito アイデンティティプール
        ↓
IAMロール
        ↓
一時的 AWS 認証情報
        ↓
AWSリソース

アイデンティティプールはアプリケーションユーザーへIAMロールに基づく一時的 AWS 認証情報を提供する候補です。

12. ユーザープールとアイデンティティプールの責任を分ける

アプリケーションAPIをトークンで認証するだけならアイデンティティプールが必須とは限りません。ユーザー自身がAWS APIを直接呼ぶ必要があるときにアイデンティティプールを評価します。

13. 認証済み / ゲストでも認可は別に設計する

アイデンティティプールは認証済みユーザーだけでなくゲストへ一時的な認証情報を提供する構成も可能ですが、ゲストロールは特に狭くします。

ゲスト
→ パブリック資産読み取りのみ認証済みユーザー
→ ユーザー固有プレフィックスへのアップロード

認証できたことと、AWSリソースへ何を許可するかは別です。一時的な認証情報でもロール権限が広ければ最小権限にはなりません。

14. 委任管理では「作成権限」と「作られるアイデンティティの上限」を分ける

開発者へロール作成を委任する場合、開発者自身のiam:CreateRole等だけでなく、作成されるロールへ必須のアクセス許可境界を適用する設計を検討します。

開発者
→ ロール作成を許可作成されるロール
→ 必要なアクセス許可の境界結果
→ 委任を維持しつつ最大権限を制御

15. 実効アクセスレビュー

アクセスを削減するときは、どのポリシーを1枚変更したかではなく、最終リクエストがまだ成立する経路を確認します。

プリンシパル
        ↓
アイデンティティベースのポリシー
リソースベースのポリシー
アクセス許可の境界セッションポリシー
SCP
明示的な拒否
        ↓
適用対象ポリシーを評価
        ↓
実効アクセス
        ↓
要件以上のアクセスが残る？

16. 判断フロー

アクセス要件
        ↓
プリンシパルは誰？
        ↓
既習アイデンティティパターンを選択
        ↓
アクション / リソース/ 条件を限定
        ↓
リソースベースのアクセス経路がある？
        ↓
最大をどの範囲で制限する？
├─ IAMエンティティ → アクセス許可の境界
├─ セッション → セッションポリシー
└─ 組織 → SCP
        ↓
アプリケーションユーザーがAWSへ直接アクセス？
└─ はい → アイデンティティプール + 範囲を限定したロールを評価
        ↓
適用対象ポリシー全体で実効アクセス確認
        ↓
要件以上の権限を除去

17. 混同ポイント

18. 主要AWS公式資料

• IAM セキュリティベストプラクティス
• IAMエンティティのアクセス許可境界
• Amazon Cognito アイデンティティプール