aws-cloudformation-iam

AWS CloudFormation IAM セキュリティ

概要

このスキルでは、安全性、監査可能性、保守性を維持しながら、CloudFormation で IAM をモデル化します。

設計で特に重要な点は次のとおりです。

• 信頼ポリシーと権限ポリシーを分離する
• 可能な限り、有効期間の長いユーザーではなくロールを優先する
• 最小権限の境界を読みやすく、再利用可能な形に保つ

SKILL.md を IAM の百科事典として扱わないでください。大規模なポリシーの例やサービス固有のバリエーションについては、同梱のリファレンスを使用してください。

使用する場面

• Lambda、ECS、EC2、Step Functions、その他の AWS サービス用に IAM ロールを作成する
• CloudFormation でインラインポリシー、管理ポリシー、アクセス許可境界を定義する
• 制約付きの信頼ポリシーを使用して、クロスアカウントのロール引き受けアクセスをモデル化する
• IAM ロール ARN や管理ポリシー ARN を後続のスタックにエクスポートする
• ワイルドカード権限、境界のドリフト、ロール置換のリスクをレビューする
• プラットフォームチームやアプリケーションチーム向けに再利用可能な IAM スタックを作成する

手順

1. まず信頼境界を定義する

誰または何がロールを引き受けるのか（サービスプリンシパル、クロスアカウントのプリンシパル、フェデレーション ID）を特定し、権限を追加する前に、明示的なプリンシパルと条件を含む信頼ポリシーを記述します。

2. 必要最小限の権限セットを付与する

ロール固有のアクセスにはインラインポリシーを使用し、複数のプリンシパルで共有するパターンには管理ポリシーを使用します。アクションとリソースを厳密に制限し、可能な場合は条件を使用します。

3. ロール作成を委任する際にアクセス許可境界を適用する

チームが独自のスタックでロールを作成または拡張する場合、特権サービス（IAM、KMS、Organizations）に対するガードレールが必要な場合、または許可される最大権限とアプリケーション固有のポリシーを分離する場合は、アクセス許可境界を使用します。

スタックの出力や監査で追跡しやすいよう、ロールとポリシーに一貫性のある名前を付けます。

4. クロスアカウントアクセスをモデル化する

クロスアカウントロールでは、正確な送信元アカウントまたはプリンシパルのみを信頼し、適切な場合は sts:ExternalId 条件を追加します。権限ポリシーと信頼ポリシーを分離し、利用するアカウントが必要とする ARN のみをエクスポートします。

5. テンプレートとポリシーの動作を検証する

デプロイ前に、次のコマンドを使用してテンプレートと IAM の動作を検証します。

# Validate CloudFormation template syntax
aws cloudformation validate-template --template-body file://template.yaml

# Preview changes before applying
aws cloudformation create-change-set \
  --stack-name <stack-name> \
  --template-body file://template.yaml \
  --change-set-type CREATE

# Simulate whether a principal can perform specific actions
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/LambdaExecutionRole \
  --action-names dynamodb:GetItem dynamodb:PutItem

# Check for wildcards in IAM policies within the template
aws cloudformation list-stack-resources --stack-name <stack-name>

デプロイ後、ポリシーのアタッチメントとスタックの出力が、意図したセキュリティモデルと一致することを確認します。

例

例 1：権限を厳密に制限した Lambda 用サービスロール

Resources:
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: DynamoDbWritePolicy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - dynamodb:GetItem
                  - dynamodb:PutItem
                Resource: !GetAtt OrdersTable.Arn

例 2：外部 ID 条件を設定したクロスアカウントロール

Resources:
  PartnerReadRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              AWS: arn:aws:iam::123456789012:role/partner-reader
            Action: sts:AssumeRole
            Condition:
              StringEquals:
                sts:ExternalId: partner-contract-001

信頼関係を狭く保ち、読み取り専用の権限ポリシーを別途組み合わせます。

ベストプラクティス

• アプリケーションや自動化のアクセスには、有効期間の長い IAM ユーザーよりも IAM ロールを優先します。
• テンプレートをレビューまたはリファクタリングする際は、信頼ポリシーと権限ポリシーを分離します。
• 他のチームにロール作成を委任する場合は、アクセス許可境界を使用します。
• ワークロードで許容される範囲内で、リソース、アクション、条件をできる限り厳密に制限します。
• 他のスタックで実際に使用される場合に限り、安定した ARN と名前をエクスポートします。
• 展開したポリシーライブラリや特殊なケースはルートスキルに詰め込まず、references/ に置きます。

制約と警告

• IAM で過度に広範なワイルドカードを使うと、簡単にデプロイできる一方、後から気づきにくくなります。
• 他のシステムが依存している場合、名前付き IAM リソースを安全に置き換えるのは困難です。
• AWS サービス全体で結果整合性が確立する前に、CloudFormation では IAM の変更が成功したように見える場合があります。
• Identity Center や組織全体に関わるアクセスパターンの中には、単一の CloudFormation スタック以外の補完的なツールが必要なものがあります。
• 信頼ポリシーの設定ミスは、権限の不足よりも大きなリスクになることがよくあります。

リファレンス

• references/examples.md
• references/reference.md

関連スキル

• aws-cloudformation-security
• aws-cloudformation-ec2
• aws-cloudformation-ecs
• aws-cloudformation-lambda