
## 自分の考える IAM ユーザーの最小権限 (MFA 必須) を考えてみた背景

AWS Organizations を利用した複数アカウント運用のベストプラクティスとして IAM ユーザーは基本権限を全く持たず権限のあるアカウントに切り替える(スイッチロール)のが紹介されていました。
この、「基本権限を全く持たない IAM ユーザー」について自分なりの最小権限を考えてみました。

## 自分の考える IAM ユーザーの最小権限 (MFA 必須) の IAM ポリシー

AWS のドキュメントで紹介されているポリシーから色々省いたり追加したものです。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:GetAccountSummary",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnPasswords",
      "Effect": "Allow",
      "Action": [
        "iam:ChangePassword",
        "iam:GetUser",
        "iam:CreateLoginProfile",
        "iam:DeleteLoginProfile",
        "iam:GetLoginProfile",
        "iam:UpdateLoginProfile"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "AllowManageOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": ["iam:CreateVirtualMFADevice", "iam:DeleteVirtualMFADevice"],
      "Resource": "arn:aws:iam::*:mfa/${aws:username}"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice",
        "iam:EnableMFADevice",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}
```

## 自分の考える IAM ユーザーの最小権限 (MFA 必須) のポイント

- できることは「マイセキュリティ資格情報」ページで自分の認証情報のパスワードと MFA の管理ができるくらいです。
- MFA なしでもサインインはできますが、その場合 `DenyAllExceptListedIfNoMFA` で定義したアクション以外はできません。ただこれは AWS CLI に影響しないため、AWS CLI などを利用する際に MFA を使わないといけないということはないです。
- IAM ユーザー作成時に初回サインイン時にパスワードリセットを強制できますが、:span[このポリシーではパスワードリセットはできません。]{style="color:red"} AWS のドキュメントで言及されている通りセキュリティ的にしないほうがいいとのことなので許可はしてません。
- MFA を使用したサインインを行った後にユーザーが自分でパスワードを変更できるようにしてます。

## 自分の考える IAM ユーザーの最小権限 (MFA 必須) の運用

このポリシーをベースにグループを作ってそこに所属させて運用するのでも楽でいいかなと思ってます。
例えばこのポリシーにアクセスキーを作成、更新、削除を付与して「IAMEngineer」というグループを作ったりいった感じです。
以前いた会社は複数アカウント管理じゃなくて単一のアカウントで運用していたのですが、
このポリシーに S3 の権限を付与して「IAMVideoCreator」というグループを作って映像クリエイターの方に動画をアップしてもらったりするなど、このポリシーをベースにした運用をやっていれば色々トラブらなくてよかったなぁと思ってます。

## 参考文献

<https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage.html>


自分の考える IAM ユーザーの最小権限 (MFA 必須)


Terraform コマンド実行時に、AssumeRole でデプロイに必要な権限をもつ IAM ロールにスイッチロールして `Terraform init`から`Terraform deploy/apply/destroy`までを実行してみた

## 背景

- Terraform でデプロイするユーザのアクセスキーが万が一漏れても被害が最小限になるようにしたい
- 一々 AWS Cli で AssumeRole コマンド実行してアクセスキーを切り替える（上書きする）のがめんどくさいのでそうしなくていいようにしたい
- 誰がリソースをいじったかわかるようにしたい

## 流れ

- `terraform init` 実行時
  - IAM ユーザー → S3 用 IAM ロールにスイッチ
- `terraform plan/deploy/destroy` 実行時
  - IAM ユーザー → S3 用 IAM ロールにスイッチ → デプロイ用 IAM ロールにスイッチ

## IAM ユーザー・ロール・ポリシーの作成

下記を作成していきます

IAM ユーザーは社員毎に用意されているものとします

| AWS アカウント(アカウント ID) | IAM          | 名前                                    | 役割                                                     |
| ----------------------------- | ------------ | --------------------------------------- | -------------------------------------------------------- |
| Employee(111111111111)        | IAM ユーザー | sample                                  | IAM ユーザ (AssumeRole しかできない ユーザー が望ましい) |
| Employee(111111111111)        | IAM ポリシー | sample-service-assume-policy            | IAM ユーザに AssumeRole 権限を持つ                       |
| ServiceA(999999999999)        | IAM ポリシー | sample-service-terraform-backend-policy | S3 に対する権限を持つ                                    |
| ServiceA(999999999999)        | IAM ロール   | sample-service-terraform-backend-role   | S3 に対する権限を持つ                                    |
| ServiceA(999999999999)        | IAM ロール   | sample-service-terraform-deploy-role    | AWS の各サービスに対する権限を持つ                       |

## Terraform の backend ( S3 ) 用の IAM ポリシーと IAM ロールの作成

`sample-service-terraform-backend-policy` を作成します。

この IAM ポリシーは Terraform が使用する state ファイルを管理する先として S3 を利用するための権限を与えるためのものになります。
その為、以下のようなポリシーを定義します。

- S3 オブジェクトの読み込みと書き込み権限
- `Resource` に state ファイルを管理する S3 バケットを指定

```json fn=ポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::sample-service-terraform-tfstate/*",
        "arn:aws:s3:::sample-service-terraform-tfstate"
      ]
    }
  ]
}
```

`sample-service-terraform-backend-role` を作成します。

この IAM ロールは `sample-service-terraform-backend-policy` がアタッチされます。
Terraform には Backend 周りはこのロールに AssumeRole してもらい処理を行ってもらいます。

以下のように IAM ロールを定義します。

- `sample-service-terraform-backend-policy` をアタッチします
- 信頼する相手として「対象となる IAM ユーザの AWS アカウント」を指定します
- よりセキュリティを強くするため条件を指定します
  - `sts:RoleSessionName` で `SessionName` として実行する IAM ユーザーの名前を指定するようにします
  - `sts:ExternalId` (外部 ID) を指定します

```json fn=信頼関係
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:RoleSessionName": "${aws:username}",
          "sts:ExternalId": "sample-service-backend"
        }
      }
    }
  ]
}
```

## AssumeRole によるスイッチロール先であるデプロイ用の IAM ロールの作成

`sample-service-terraform-backend-role` を作成します。

この IAM ロールは Terraform にデプロイ時に AWS の各サービスに対する権限を与えるためのものになります。
Terraform には Deploy 周りはこのロールに AssumeRole してもらい処理を行ってもらいます。

以下のように Role を定義します。

- 付与するアクセス権限を必要に応じて付与してください
- 信頼する相手として `sample-service-terraform-backend-role` を指定します
  - こうすることで `sample-service-terraform-backend-role` にスイッチしてる IAM ユーザーのみがスイッチできます
- よりセキュリティを強くするため条件を指定します
  - `sts:ExternalId` (外部 ID) を指定します

```json fn=信頼関係
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999999:role/sample-service-terraform-backend-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "sample-service-deploy"
        }
      }
    }
  ]
}
```

## IAM ユーザーに AssumeRole でデプロイ用の IAM ロールにスイッチロールできるようにする

`sample-service-assume-policy` を作成します。

この IAM ポリシーは `sample-service-terraform-backend-role` に Assume Role できるようにする為のものです。
その為、以下のようなポリシーを定義します。

```json fn=ポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [
        "arn:aws:iam::999999999999:role/sample-service-terraform-backend-role"
      ]
    }
  ]
}
```

## AWS CLI の認証情報の設定と動作確認

- aws profile の編集
  - `sample-service-terraform-backend-role` に IAM ユーザーの profile 経由でスイッチする profile を追加します。
  - `sample-service-terraform-deploy-role` に `sample-service-terraform-backend-role` 経由でスイッチする profile を追加します。

```ini fn=~/.aws/config
[default]
output = json
region = ap-northeast-1

[profile sample-service-terraform-backend]
region = ap-northeast-1
output = json

[profile sample-service-terraform-deploy]
region = ap-northeast-1
output = json
```

```ini fn=~/.aws/credentials
[default]
aws_access_key_id = IAM ユーザーのアクセスキー
aws_secret_access_key = IAM ユーザーのシークレットキー

[sample-service-terraform-backend]
role_arn = arn:aws:iam::999999999999:role/sample-service-terraform-backend-role
role_session_name = sample(IAM ユーザー名前)
external_id = sample-service-backend
source_profile = default

[sample-service-terraform-deploy]
role_arn = arn:aws:iam::999999999999:role/sample-service-terraform-deploy-role
external_id = sample-service-deploy
source_profile = sample-service-terraform-backend
```

- terraform の修正
  - `provider` の `profile` に `sample-service-terraform-deploy-role` にスイッチする profile 名を指定します。
  - `backend "s3"` の `profile` に `sample-service-terraform-backend-role` にスイッチする profile 名を指定します。

```hcl fn=main.tf
terraform {
  required_version = "= 0.14.7"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "= 3.9.0"
    }
  }
  backend "s3" {
    bucket = "sample-service-terraform-tfstate"
    key    = "cloudfront/terraform.tfstate"
    region = "ap-northeast-1"
    profile = "sample-service-terraform-backend"
  }
}

provider "aws" {
  profile = "sample-service-terraform-deploy"
  region = "ap-northeast-1"
}
```

- `terraform init`, `terraform plan/deploy/destroy`を実行してみて正常に終了すれば成功です。

## Terraform 実行時に AssumeRole で IAM ロールにスイッチロールする方法おまけ

`sample-service-terraform-backend-role` のスイッチに session_name の指定を強制しましたが、これをすることで Cloudtrail に以下のように出力されます。

```json fn=ログの一部(cognito作成時)
{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AAAAAAAAAAAAAAAAAAAAA:sample",
        "arn": "arn:aws:sts::999999999999:assumed-role/sample-service-terraform-deploy/sample",
        "accountId": "999999999999",
        "accessKeyId": "BBBBBBBBBBBBBBBBBBBB",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "AAAAAAAAAAAAAAAAAAAAA:sample",
                "arn": "arn:aws:iam::999999999999:role/sample-service-terraform-deploy",
                "accountId": "999999999999",
                "userName": "sample-service-terraform-deploy"
            },
            "webIdFederationData": {},
            "attributes": {
                "mfaAuthenticated": "false",
                "creationDate": "2021-03-07T14:48:29Z"
            }
        }
    },
    "eventTime": "2021-03-07T14:48:32Z",
    "eventSource": "cognito-idp.amazonaws.com",
    "eventName": "CreateUserPool",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "2409:10:9780:c00:f09d:5f83:7147:9b65",
    "userAgent": "aws-sdk-go/1.34.26 (go1.14.5; darwin; amd64) APN/1.0 HashiCorp/1.0 Terraform/0.14.7 (+https://www.terraform.io)",
    "requestParameters": {
        "poolName": "Samplece_Service_Dev",
        "autoVerifiedAttributes": [
            "email"
        ],
        "usernameAttributes": [
            "email"
        ],
```

`principalId` に IAM ユーザーの名前が入るようになり、誰がリソースにどういった変更を加えたかなどがわかるようになります。

## Terraform 実行時に AssumeRole で IAM ロールにスイッチロールする方法まとめ

アクセスキーが流出した際のことを考慮に入れたデプロイ手法は色々あり、それを試してるうちにこんな感じになりました。
profile の設定を半ば強制してる感じで設定も共有する必要がありますがアクセスキーと profile の設定さえ教えればアクセスキーの上書きなど細々としたことやらずに済むので楽かなということでこれで運用してみようかなと思ってます。


Terraform 実行時に AssumeRole で IAM ロールにスイッチロールする方法


## クロスアカウントの CloudTrail ログを特定のアカウントの S3 バケットに保存する理由

AWS ブログでは AWS Organizations における組織単位のベストプラクティスについて以下のように記載しています。

[AWS Organizations における組織単位のベストプラクティス \| Amazon Web Services ブログ](https://aws.amazon.com/jp/blogs/news/best-practices-for-organizational-units-with-aws-organizations/)

> 推奨アカウント
> ログアーカイブ (Log Archive) : このアカウントは環境内のすべてのアカウントから収集されたセキュリティに関連する AWS アクセスログおよび監査ログを統合します。

上記の記述のように、クロスのアカウントのアクセスログおよび監査ログを一つのアカウント下に一元保存するのが推奨されているようです。

自分の個人アカウントで作成した AWS Organizations 環境下でもログアーカイブアカウントを作成し、そのアカウント下の S3 に全ての他のアカウントの CloudTrail のログを保存しています。

今回は、クロスアカウントの環境下で特定の一つのアカウントの S3 に収集対象のアカウントの Cloudtrail のログを集約する設定をやっていきます。
ついでにログの暗号に使用する CMK もアカウント間共有してみます。
因みにここで紹介する方法は、別に AWS Organizations を利用していなくても大丈夫です。

## 前提条件

- 保存する S3 バケット名は `aws-cloudtrail-logs` とします。
- CloudTrail ログが保存されるパスは `aws-cloudtrail-logs/AWSLogs/AWSアカウントID` とします。
  - アカウント ID が `111111111111` の場合は、`aws-cloudtrail-logs/AWSLogs/111111111111`
- 以下のようなアカウントをが作成されている想定です。
  |アカウント ID | アカウント名 | 備考 |
  | ------------- | ------------------- | -------------------------------- |
  | 999999999999 | LogArchive | CloudTrail ログを保管するアカウント |
  | 111111111111 | サービス A 開発環境 | CloudTrail ログを保管したいアカウントその 1 |
  | 222222222222 | サービス A 検証環境 | CloudTrail ログを保管したいアカウントその 2 |

## CloudTrail ログを保管するアカウント(LogArchive)側の設定

### CloudTrail 証跡の作成その 1

- CloudTrail → ダッシュボード → 証跡の作成
  - 証跡名は適当
  - 新しい S3 バケットを作成するを選択
    - [証跡ログバケット名] に適当なバケット名を入力
      - 本記事では `aws-cloudtrail-logs` とします。
  - AWS KMS カスタマー管理の CMK
    - 新規で作成を選択し、[AWS KMS エイリアス] を入力
      - 本記事では `aws-cloudtrail-logs-key` とします。
  - 残りの入力項目は適宜目的に応じたものを入力していき証跡を作成します。

### S3 バケットに「CloudTrail ログを保管したいアカウント」からのアクセスを許可する

S3 のコンソールに行くと CloudTrail 作成時に指定した S3 バケット (`aws-cloudtrail-logs`) が作成されているので、そのバケットの [アクセス許可] から [バケットポリシー] の編集を行います。

**バケットポリシー設定**
・ CloudTrail ログは収集対象のアカウント ID 毎のディレクトリに保存することとします。
・ `s3:PutObject` のアクションに対する `Resource` にログを保管するディレクトリを追加します。

```json fn=バケットポリシー設定
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSCloudTrailAclCheck20150319",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::aws-cloudtrail-logs"
    },
    {
      "Sid": "AWSCloudTrailWrite20150319",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": [
        "arn:aws:s3:::aws-cloudtrail-logs/AWSLogs/111111111111/*",
        "arn:aws:s3:::aws-cloudtrail-logs/AWSLogs/222222222222/*"
      ],
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    }
  ]
}
```

### CloudTrail ログを暗号化するための CMK を「CloudTrail ログを保管したいアカウント」が利用できるようにする

- [Key Management Service (KMS)] → [カスタマー管理型のキー] で証跡の作成時に [AWS KMS エイリアス] に入力したエイリアス名 (`aws-cloudtrail-logs-key`)
  - キーポリシーの編集から、`kms:GenerateDataKey*` アクションの `Condition` に「CloudTrail ログを保管したいアカウント」の CloudTrailService の `arn` を追記します。

```json fn=キーポリシー(一部抜粋))
{
  "Sid": "Allow CloudTrail to encrypt logs",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudtrail.amazonaws.com"
  },
  "Action": "kms:GenerateDataKey*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "kms:EncryptionContext:aws:cloudtrail:arn": [
        "arn:aws:cloudtrail:*:111111111111:trail/*",
        "arn:aws:cloudtrail:*:222222222222:trail/*"
      ]
    }
  }
}
```

## CloudTrail ログを保管したいアカウント(サービス A 開発環境、サービス A 検証環境)側の設定

### CloudTrail 証跡の作成その ２

- CloudTrail → ダッシュボード → 証跡の作成
  - 証跡名は適当
  - 既存の S3 バケットを使用するを選択します。
    - [証跡ログバケット名] に CloudTrail ログを保管するアカウント (LogArchive) の CloudTrail で作成した S3 バケット名 (`aws-cloudtrail-logs`) を直接入力する。([参照] を押しても S3 バケット名は表示されません)
      - [プレフィックス - オプション] は未入力で大丈夫です。もし、プレフィックスを利用する場合は、S3 のバケットポリシーを編集して、CloudTrail にプレフィックスを含めたディレクトリにアクセスする許可を与えてください。
  - AWS KMS カスタマー管理の CMK
    - 既存を選択し、[AWS KMS エイリアス] にログを保管するアカウント (LogArchive) の CloudTrail で [AWS KMS エイリアス] に入力した CMK (`aws-cloudtrail-logs-key`) の `arn` を直接入力します。(:span[オートコンプリートで表示されたりしません]{style="color:red"})
  - 残りの入力項目は適宜目的に応じたものを入力していき証跡を作成します。

## 動作確認

- CloudTrail ログを保管するアカウント (LogArchive) アカウントで S3 バケットにアクセスし、アカウント毎のディレクトリに CloudTrail のログが出力されていれば OK です。

## まとめ

- 今回 AWS Organizations のクロスアカウント管理のベストプラクティスとして CloudTrail などのセキュリティーログを集約/保存するアカウントに保存するのをやってみましたが、CMK 含めいい勉強になりました。
- 本記事では開発・検証と行った本番系以外のアカウントの CloudTrail をそれ専用アカウントに集約した形ですが、本番系だと当然、サービス A 本番アカウントと本番系の CloudTrail を集約/保存するアカウントを作成する必要があるので、AWS Organizations のアカウント作成上限に到達してしまう点は注意が必要です。事前に AWS Organizations に登録可能なアカウントの上限緩和申請しておくことをお勧めします。

## 参考文献

<https://aws.amazon.com/jp/builders-flash/202009/multi-accounts-best-practice-2/>
