ControlTowerランディングゾーンのバージョンアップを実施しました

AWS

情報システム部でAWS周りの運用保守をしている「ねぎ」です、こんにちは！

弥生のAWS環境を支えてくれているControlTowerについて、ランディングゾーンという各AWSアカウントのベースライン設定に関するバージョンアップを実施してみました。

docs.aws.amazon.com

今回はバージョンアップを実施した際に、つまずいた点やポイントなどを紹介していきたいと思います。

私と同じくAWS周りの運用保守を担当している「いまいずみ」さんに詳細を説明していただこうと思います。

まえがき

弥生のランディングゾーンは「2.9」のバージョンで利用を行っていました。
（2.9は2022年4月22日リリースされています）

ランディングゾーンの最新版は「3.1」で、2023年2月9日にリリースされていますので、今回のバージョンアップは約1年ぶりとなります。

docs.aws.amazon.com

2.9から3.1へバージョンアップする際の大まかな変更点は以下となり、それぞれ影響有無などを確認する必要がありました。
（早めに最新化しないとどんどん調査工数が膨らみますよね。。。）

  • Configでグローバルサービスの履歴を残すオプションがControlTowerのホームリージョンのみで有効になる

  • CloudWatch Logsの証跡が無くなる

  • ControlTower管理外のアカウントも証跡が取られる

  • リージョン拒否ガードレール（SCP）の設定

  • アクセスログ用S3バケットのサーバーアクセスログ記録の無効化

上記の各アップデート内容に追加して、中々手を出せてなかったCloudTrailの暗号化もアップデートにあわせて実施することにしました。

それでは以降、バージョンアップに関する苦労（？）話を「いまいずみ」さんからしていただこうと思います。

アップデート前影響範囲調査

  • 各アップデートでは以下のような変更点があり、弊社で変更点とその影響範囲を洗い出しました。

バージョン3.0 変更点

  • 証跡出力のS3パス変更
    • version 3.0 以前はメンバーアカウントにアカウントレベルでの証跡として作成されていたが、version 3.0 から組織レベルの証跡として管理されます。
      アカウントレベルの証跡のパス : `/organization id/...`
      組織レベルの証跡のパス : `/<organization id>/AWSLogs/<organization id>/...`
    • 証跡パスの変更に伴い、弊社のAWS環境で利用しているSIEM on Amazon OpenSearch Serviceに影響は特にありませんでした。
      • 設定変更は必要ありませんでした。（AWSのサポートから回答いただきました。）
    • アップデートを実施した日からS3のパスが変わるので、もし他に利用する場合は注意が必要と考えられます。
  • AWS ControlTowerのログ保存期間(最大15年)
    • ControlTowerアップデートの際に新しく設定できます。（オプション機能）
    • 弊社セキュリティポリシーに合わせ変更いたしました。
  • Security Hub Config.1の違反（既知のバグ）
    • グローバルリソースの記録がホームコントロールタワーリージョンでのみ行われるConfigの変更が原因で発生します。
    • 対応が難しいので、アップデートで改善を期待。
  • 現状、弊社環境に影響のないアップデートは以下となります。
    • 各アカウントにあったCloudWatch Logsの証跡が無くなりました。
    • ControlTower管理外のアカウントも証跡が取られるようになります。
    • リージョン拒否ガードレールの設定（こちらについては今後検討予定です。）

バージョン3.1 変更点

  • ログ記録アカウントの Access Logging バケットにおけるサーバーアクセスログ記録を非アクティブ化するように更新
    • SecurityHubのAWS 基礎セキュリティのベストプラクティス v1.0.0のS3.9が失敗となります。

    AWS ControlTower アクセスログバケットのサーバーアクセスログを無効にすると、Security Hub は Log Archive アカウントのアクセスログバケットの結果を作成します。これは、[S3.9] S3 バケットのサーバーアクセスログを有効にする必要があるという AWS Security Hub ルールによるものです。Security Hub に従い、このルールの Security Hub の説明に記載されているように、この特定の結果を非表示にすることをお勧めします。追加情報については、「非表示の結果に関する情報」を参照してください。 （AWS公式docsから抜粋）

    • 抑制済みとすることを推奨しているが、100アカウントもあると途方もないので断念。。。。
    • 今後のアップデートで改善を期待。

CloudTrailログKMS暗号化による変更点

  • 事前に作業が必要になるのは暗号化による変更が大半でした。
  • S3暗号化により以下のサービスに影響が出ることが予想されました。
    • レプリケーションバケット
    • SIEM on Amazon OpenSearch Service
    • Quick Sight + Athena

弊社の環境

  • CloudTrailの分析ツールとして以下を利用しています。
  • CloudTrailログを保存しているS3をデータソースとして指定しており、暗号化の影響があるリソースとなります。

    • SIEM on Amazon OpenSearch Service

      SIEM on Amazon OpenSearch Serviceの構成図

    • Quick Sight + Athena

      Quick Sight + Athenaを使った弥生の環境

バージョンアップ前の準備

  • 前提条件
    • 弊社ControlTowerではCloudTrailのログはLog Archiveアカウントに保存され、SIEMやOpenSearchで利用するS3へレプリケーションを取っているような構成となります。

  • 暗号化の際の考慮事項
    • KMS暗号化をする際の各ポリシーの関係は以下の図のようになっております。
      各ポリシーの関係図
    • KMS
      • キーポリシーにLog ArchiveアカウントとAuditアカウントに対する権限付与が必要となります。
    • IAM
      • KMSを利用する必要のあるサービスへIAMポリシーでKMSの暗号化復号化権限が必要になります。
      • 今回利用しているサービスでKMSの権限を追加したサービスは以下となります。
        • ログ集約用S3からSIEM取り込み用S3へのレプリケーションで利用しているIAMロール
        • SIEM取り込み用S3からOpenSearchへ取り込むためのLambdaのIAMロール
        • QuickSightに付与されているIAMロール
    • S3
      • 今回KMSの権限を追加したIAMロールはすでにバケットポリシーを追加しているため、特に変更は実施いたしませんでした。
  • 準備手順
    1. 親アカウントでKMSを発行
      • kmsはキータイプを対称、キーの使用を暗号化および復号化で作成
        暗号化キーの指定
      • キーポリシーではCloudTrail, Config, LogArchiveアカウントとAuditアカウントの利用を許可するポリシーを記載
        {
      "Version": "2012-10-17",
      "Statement": [
          {
          "Sid": "Allow CloudTrail and AWS Config to encrypt/decrypt logs",
          "Effect": "Allow",
          "Principal": {
              "Service": [
                  "config.amazonaws.com",
                  "cloudtrail.amazonaws.com"
              ]
          },
          "Action": [
              "kms:GenerateDataKey",
              "kms:Decrypt"
          ],
          "Resource": "*"
          },
          {
              "Sid": "Enable IAM User Permissions",
              "Effect": "Allow",
              "Principal": {
                  "AWS": "arn:aws:iam::[親アカウントID]:root"
              },
              "Action": "kms:*",
              "Resource": "*"
          },
          {
              "Sid": "Allow use of the key",
              "Effect": "Allow",
              "Principal": {
                  "AWS": [
                      "arn:aws:iam::[Log ArchiveアカウントID]:root",
                      "arn:aws:iam::[AuditアカウントID]:root"
                  ]
              },
              "Action": [
                  "kms:Encrypt",
                  "kms:Decrypt",
                  "kms:ReEncrypt*",
                  "kms:GenerateDataKey*",
                  "kms:DescribeKey"
              ],
              "Resource": "*"
          },
          {
              "Sid": "Allow attachment of persistent resources",
              "Effect": "Allow",
              "Principal": {
                  "AWS": [
                      "arn:aws:iam::[Log ArchiveアカウントID]:root",
                      "arn:aws:iam::[AuditアカウントID]:root"
                  ]
              },
              "Action": [
                  "kms:CreateGrant",
                  "kms:ListGrants",
                  "kms:RevokeGrant"
              ],
              "Resource": "*",
              "Condition": {
                  "Bool": {
                      "kms:GrantIsForAWSResource": "true"
                  }
              }
          }
      ]
  }
    2. Log ArchiveアカウントとAuditアカウントへKMSのアクセス権限を追加
    3. Log ArchiveのCloudTrailログ用S3バケットからSIEM用S3バケットへのレプリケーションを実施しているため、該当のIAMロールへKMSのdecrypt/encrypt権限を追加
    4. SIEM on OpenSearchで利用しているLambdaのIAMロールへ作成したKMSの権限を付与

バージョンアップ実施

バージョンアップ後に発覚した内容

  • S3レプリケーションの設定で暗号化されているオブジェクトをレプリケーションしない設定となっていました。(恥ずかしながら設定あることも知りませんでした。。。)

    • 以下設定を変更すれば問題ありません。
    • 暗号化するためのKMSキーは親アカウントで作成したキーのarnを指定しています。
      暗号化されたオブジェクトをレプリケートする設定前
      暗号化されたオブジェクトをレプリケートする設定後

  • QuickSightでもCloudTrailを利用していることがエラーから発覚いたしました。

    • QuickSightでは作成時にIAMロールが自動的に作成されることもあり、権限については意識することは少ない。
    • 切り戻しとしてはIAMロールにKMSの復号化権限を付与して完了です。

あとがき

「いまいずみ」さんのバージョンアップ体験談、いかがでしたでしょうか。

バージョンアップをしたくても中々踏み出せない方がいらっしゃるのではないかと思います。

ControlTowerのランディングゾーンバージョンアップに向けて、本ブログが一助になれば幸いです。

引き続きAWS関連の情報を発信していけるよう、がんばっていきます。

一緒に働く仲間を募集しています

herp.careers

2023/07/13（木）開催の もくテク でインフラのお話しをしますので、こちらもぜひ。 mokuteku.connpass.com