IAM（AWS Identity and Access Management）

IAM リソース

• ユーザー
  • ルートユーザー（アカウント毎に1つ発行）
  • IAM ユーザー
• グループ
• ロール

ユーザー、グループ、ロールを IAM アイデンティティと呼びます。

IAM ポリシー

• AWS 管理ポリシー（ AWS managed policies ）
  • AWS ビルトインのスタンドアロンポリシー
• カスタマー管理ポリシー（ Customer managed policies ）
  • カスタムのスタンドアロンポリシー
• インラインポリシー（ Inline policies ）

  • IAM アイデンティティ (ユーザー、グループ、またはロール) に埋め込まれたポリシーです。つまり、ポリシーは本質的にアイデンティティの一部です。

※ ARN を持つポリシーを スタンドアロンポリシー と呼びます。
ref. https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html

許可 ポリシー

<img width="939" alt="IAM_Management_Console" src="https://user-images.githubusercontent.com/1384665/175669257-e2fff1c6-36c2-44d0-b31a-1e6c65a12581.png)

信頼関係（信頼ポリシー）

信頼関係の詳細

信頼関係（信頼ポリシー）はロールを利用できる対象を表します。

AssumeRolePolicyDocument The trust policy that is associated with this role. Trust policies define which entities can assume the role. You can associate only one trust policy with a role. For an example of a policy that can be used to assume a role, see Template Examples. For more information about the elements that you can use in an IAM policy, see IAM Policy Elements Reference in the IAM User Guide.

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#cfn-iam-role-assumerolepolicydocument

IAM ロール

STS で一時的に発行した認証情報を使ってロールの引き受け手にリソースの操作権限を付与する仕組みです。

IAMロールは、AWSのサービスやアプリケーションに対して、一時的なAWSリソースの操作権限を与える仕組みです。
この操作権限はAWS Security Token System（AWS STS）を利用し、一時的認証情報（Temporary Security Credential）を発行するこにより実現しています。
一時的認証情報の実態は、有効期限が短いアクセスキーとシークレットキー、セッショントークンです。
AWSサービスやアプリケーションは、受け取った一時的認証情報を使いS3やKMSといった対象のAWSリソースを利用します。

-- 要点整理から攻略する AWS認定セキュリティ・専門知識

ロールの引き受け

AWS IAM のロールを引受ける（AssumeRole）仕組みを整理します。

• IAM ロールを使用する
• ロールの切り替え (コンソール)

IAM ロールの 2 つのポリシー

IAM ロールには 2 種類のポリシーが存在します。

ポリシー	役割
アクセス権限ポリシー	どのリソースに対して何ができるか IAM Action List
信頼ポリシー（ AssumeRolePolicyDocument ）	誰がそのロールを引き受けられるか

アクセス権限ポリシー

• Action：何ができるか（例：s3:GetObject）
• Resource：どのリソースに対して許可するか（例：arn:aws:s3:::my-bucket）

信頼ポリシー

CloudFormation では AssumeRolePolicyDocument に Principal（引受を許可するエンティティ）を記載します。

ロール引受の条件:プリンシパルの種類による違い

AWS サービス（ codepipeline.amazonaws.com 等）と IAM ユーザー / ロールで必要な設定が異なります。

AWS サービスがプリンシパルの場合（ロール側のみで完結）

AWS が管理するサービスは sts:AssumeRole を呼び出す能力を AWS が内部的に持っているため、ロール側の信頼ポリシー1つで完結します。
※ STS：AWS Security Token Service 。

IAM ユーザー/ロールがプリンシパルの場合（両側の設定が必要）

IAM ユーザーは自動的に AssumeRole の権限を持たないため、プリンシパル側にも明示的なポリシーが必要です。

まとめ

プリンシパルの種類	ロール側の信頼ポリシー	プリンシパル側のポリシー
AWS サービス（CodePipeline 等）	必要	不要
IAM ユーザー	必要	必要
IAM ロール（クロスアカウント等）	必要	必要

具体例 1. IAM ユーザーのスイッチロール

ロール側

• AWS アカウント：12345678901
• ロール： OrganizationAccountAccessRole
• 許可：AdministratorAccess
• 信頼関係； AWS アカウント 98765432109 の foo ユーザー

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::98765432109:foo"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

プリンシパル側（　IAM ユーザーが別ロールを引き受ける場合）

• AWS アカウント 98765432109
• ユーザー：foo

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::12345678901:role/OrganizationAccountAccessRole"
    }
  ]
}

IAM ユーザー（ foo ）に上記インラインポリシーを付与することで、OrganizationAccountAccessRole（　AdministratorAccess　）を引き受けて S3 を操作できるようになります。

具体例 2. AWS サービスが引き受ける場合

ロール側（　CloudFormation　）

MyBucketRole:
  Type: "AWS::IAM::Role"
  Properties:
    RoleName: MySampleBucketRole
    AssumeRolePolicyDocument:
      Version: "2012-10-17"
      Statement:
        - Effect: "Allow"
          Principal:
            Service:
              - "codepipeline.amazonaws.com"   # AWS サービスを信頼
          Action:
            - "sts:AssumeRole"
    Policies:
      - PolicyName: "CodePipelineS3AccessPolicy"
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
            - Action:
                - s3:ListAllMyBuckets
              Resource: "arn:aws:s3:::*"
            - Action:
                - s3:GetObject
                - s3:PutObject
                - s3:DeleteObject
              Resource: "arn:aws:s3:::my-sample-bucket-unique-name"

この設定では codepipeline.amazonaws.com のみを信頼しています。 codepipeline.amazonaws.com は前述のように AWS 管理サービスなので sts:AssumeRole を呼び出す能力を AWS が内部的に持っているため、ロール側の信頼ポリシー1つで完結します。 また IAM ユーザーがアクセスキーで直接 my-sample-bucket-unique-name を直接操作することはできません。

具体例 3. クロスアカウントロールのスイッチ

信頼関係（信頼ポリシー）についてクロスアカウントロール（ユーザーからのみスイッチできるIAMロール）を例に説明する。 AWSの薄い本 IAMのマニアックな話 p39

クロスアカウントロールのスイッチ元の制限は Condition（条件） ではなく Principal（信頼関係） を利用する。 アカウントAAAAAAAAAAAのfooロールからアカウントBBBBBBBBBBBのbarロールにスイッチロールする例。

アカウントAAAAAAAAAAA側のfooロール

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::BBBBBBBBBBB:role/bar"
            ],
            "Effect": "Allow"
        }
    ]
}

アカウントBBBBBBBBBBBのbarロール

信頼関係の例（JSON）

{
  "Version": "2012-10-17",
  "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:iam::AAAAAAAAAAA:role/foo"
        },
        "Action": "sts:AssumeRole",
      }
  ]
}

アクセス権限AdministratorAccessの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

具体例 4. 信頼関係にサービス（例 ecs-tasks.amazonaws.com）を設定

ECSアプリケーションの信頼関係の例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "ecs-tasks.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

上記の信頼関係をCloudFormationdeで定義すると以下のようになります。 参考に許可も設定しています（anagedPolicyArns）。

AppRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service:
              - "ecs-tasks.amazonaws.com"
            Action:
            - "sts:AssumeRole"
      Path: "/"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSQSFullAccess
        - arn:aws:iam::aws:policy/CloudWatchLogsFullAccess

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_principal.html

パーミッションバウンダリー

バウンダリーは、IAMユーザーまたはIAMロールに対するアクセス制限として動作します。 付与した権限とBoundaryで許可した権限と重なる部分のみ有効な権限として動作します。

STS AWS Security Token Service

AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。一時的セキュリティ認証情報の機能は、IAM ユーザーが使用できる長期的なアクセスキー認証情報とほとんど同じですが、次の相違点があります。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp.html

ユースケース

ECSコンテナ内のアプリケーションがSQSにアクセスする場合を考える。

Bad

• コンテナ内のアプリケーション用にユーザーを作成してSQSのアクセス件を付与
• ↑のユーザーのキー、シークレットキーでSQSにアクセス

Good

• ロールを使用してタスク（コンテナ）にタスクロールに付与
• コンテナアプリSTSを使用してSQSにアクセス

  TaskRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service:
              - "ecs-tasks.amazonaws.com"
            Action:
            - "sts:AssumeRole"
      Path: "/"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSQSFullAccess
        - arn:aws:iam::aws:policy/CloudWatchLogsFullAccess

CloudFormation

AWS::IAM::Role

CloudFormationのAWS::IAM:RoleはJSONポリシーを使って記載される。

• JSON ポリシー
• https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements.html

備考

• principal：主要な、認証の対象、当事者
• assume：引き受ける
• sts:AWS Security Token Service (AWS STS)
• 認証（Authentication）：本人確認
• 認可（Authorization）：リソースに対する使用権限付与

Ref.

• IAM JSON ポリシーの要素のリファレンス
  CloudFormationのポリシーの書き方
• IAM でのポリシーとアクセス許可
• AWS Identity and Access Management テンプレートスニペット
• [https://devlog.arksystems.co.jp/2020/03/12/9338/](AWSのポリシーを使いこなそう　ポリシー設計につまづかないためのポイントを整理)
• IAM と連携する AWS のサービス
  リソースベースポリシー一覧
• 意外と盲点？Lambda関数にトリガーを追加するときはリソースベースポリシーを意識しよう
  • リソースベースポリシーについてわかりやすいガイド
• AWS 認定 Security - Specialty から学んだことをまとめてみた