NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

AWS Control Tower Landing Zone3.0の変更内容と詳細解説

こんにちは、上野です。

AWS Control TowerのLanding Zone 3.0がリリースされました。

変更内容が多いですが、ざっくりまとめると以下のとおりです。

  • 組織レベルのAWS CloudTrail証跡が設定可能になった
  • CloudTrailの設定をControl Towerからオプトアウト可能になった(オプトアウトした場合は独自で設定する必要あり)
  • CloudTrailで各アカウントに出力されていたCloudWatch logsは、マネジメントアカウントに集約される
  • CloudTrailアップデートに伴い、Control Towerが管理するIAMポリシーAWSControlTowerServiceRolePolicyの内容変更
  • AWS Config のグローバルリソースの記録がホームリージョンのみに変更
  • リージョン拒否ガードレールの変更(許可対象グローバルサービスの追加)

サービス単位で分けると、CloudTrail、Config、リージョン拒否ガードレール(SCP)の3点になるので、その3点に分けて解説していきます。

CloudTrailの変更内容

CloudTrailの基本おさらい

CloudTrailの変更内容については、まずCloudTrailの基本設定を理解していないと、変更内容の理解も難しいかと思います。ということでまずはCloudTrail基本の復習です。

CloudTrailはAWS上のAPI実行履歴(操作履歴)を保存、確認できるサービスです。特に追加の設定はしなくとも、過去90日分はAWSマネジメントコンソールからイベント履歴として確認できます。

通常、この90日間では要件として短い場合も多く、証跡という形でS3バケットまたはCloudWatch Logs(両方の設定も可能)に残すことになります。証跡として残した履歴は、S3やCloudWatch Logsの設定した保持期間分保存されるので、さまざまな要件に対応できます。

S3バケットについては、別アカウントのS3バケットも指定可能というのがポイントです。(別アカウントの場合はバケットポリシーによる書き込み許可設定が必要になります。)CloudWatch Logsは、証跡設定と同アカウントになります。

また、Organizationsのマネジメントアカウントで証跡を設定する場合は、組織内すべてのアカウントを対象とした証跡作成が可能です。 設定は一か所で、全アカウントの証跡が自動取得されるので便利です。

Control Tower Landing Zone 3.0 のCloudTrail変更内容

Control Towerでは、CloudTrailの証跡が自動設定されます。Landing Zone 2.9以前は、組織レベルの証跡は使用されず、アカウントごとに証跡が設定され、S3の保存先としてログアーカイブアカウントのバケットが設定されています。CloudWatch Logsは各アカウント上のロググループが指定されています。

以下のようなイメージです。Control Tower登録済みのアカウントにCloudFormation StackSetsで展開しているため、登録外の組織内アカウントは証跡が設定されていません。

Landing Zoneが3.0になると、以下のように変わります。

設定が少しスッキリしました。以下が2.9と比べて変更になります。

  • 各アカウントにあったCloudWatch Logsの証跡が無くなる
  • Control Tower管理外のアカウントも証跡が取られるようになる
  • 証跡出力のS3パス変更
  • CloudTrail用のIAMポリシー変更

アップデート手順は後述しますが、先にアップデート後の設定状況を紹介します。

3.0にした後の、マネジメントアカウントの証跡設定は以下のとおりです。

各アカウントの証跡は、以下のとおり組織レベルで設定された証跡が閲覧のみ可能な状態となります。

アップデート後24時間は、新旧両方の証跡が表示され、24時間経過後、旧の証跡設定が削除されます。

CloudWatch Logsは、マネジメントアカウントのロググループに複数アカウントのログが出力されるようになっています。

なお、証跡の保存期間は以下のとおり2.9以前と同じままです。

  • S3⇒1年(非現行バージョンも含めると2年)
  • CloudWatch logs⇒2週間

正直ここのアップデート(変更できるようになる)を期待しているのですが、まだのようです。

実体はCloudFormation StackSetsでパラメータ指定されている値なので、ここを変更することも仕組み上は可能なのですが、Control Tower外でControl Tower管理の設定を変更することは非推奨となっています。アップデートを待ちましょう。

⇒ログの保存期間が変更できるようになりました!詳細はコチラ  CloudWatch Logsの期間は2週間のままです。

Configの変更内容

ConfigはAWSの設定履歴を残すサービスですが、設定有効時に、グローバルサービスの履歴を残すオプションがあります。

Landing Zone 2.9以前では、Control Towerで対象としたリージョンすべてについて、このオプションが有効になります。Configは設定履歴の量で課金されるため、同じ設定履歴が複数のリージョンで残ることになり、主に費用面で損をする状態でした。AWSで紹介されているConfigのベストプラクティスにも、グローバルリソースは1つのリージョンにすべきと記載されています。

Landing Zoneを3.0にすることで、このオプションがControl Towerのホームリージョンのみで有効になります。

リージョン拒否ガードレール(SCP)

Control Towerでは、ワンクリックで管理外リージョンの操作を拒否するガードレールを設定できます。

この設定はService Control Policy(SCP)で実装されています。管理外リージョンの全AWSサービスを拒否してしまうと、IAMやRoute 53といったリージョンに属さないグローバルサービスが使用できなくなるため、NotActionで拒否しないサービスとして設定されています。

グローバルサービスは、画面上でリージョンは表示されませんが、コントロールプレーンと呼ばれる操作を司る機能はリージョンで稼働します。たとえばIAMはバージニア北部(us-east-1)リージョンにコントロールプレーンがあります。全グローバルサービスのコントロールプレーンがバージニア北部(us-east-1)にある訳ではありません。たとえばAWS Chatbotはオレゴン(us-west1)になります。

コントロールプレーンのあるリージョンでポリシー許可がないとグローバルサービスは使用できないため、SCPではグローバルサービスは拒否の例外として設定されています。東京リージョンとバージニア北部を許可した場合の、LandingZone3.0におけるSCPは以下のとおりです。対象サービス(NotAction内)がいくつか追加になりました。※長いです

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "us-east-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/AWSControlTowerExecution"
          ]
        }
      },
      "Resource": "*",
      "Effect": "Deny",
      "NotAction": [
        "a4b:*",
        "acm:*",
        "aws-marketplace-management:*",
        "aws-marketplace:*",
        "aws-portal:*",
        "budgets:*",
        "ce:*",
        "chime:*",
        "cloudfront:*",
        "config:*",
        "cur:*",
        "directconnect:*",
        "ec2:DescribeRegions",
        "ec2:DescribeTransitGateways",
        "ec2:DescribeVpnGateways",
        "fms:*",
        "globalaccelerator:*",
        "health:*",
        "iam:*",
        "importexport:*",
        "kms:*",
        "mobileanalytics:*",
        "networkmanager:*",
        "organizations:*",
        "chatbot:*",
        "pricing:*",
        "route53-recovery-control-config:*",
        "route53-recovery-readiness:*",
        "route53-recovery-cluster:*",
        "route53:*",
        "route53domains:*",
        "s3:GetBucketPublicAccessBlock",
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation",
        "s3:GetAccountPublic",
        "s3:DeleteMultiRegionAccessPoint",
        "s3:DescribeMultiRegionAccessPointOperation",
        "s3:GetMultiRegionAccessPoint",
        "s3:GetMultiRegionAccessPointPolicy",
        "s3:GetMultiRegionAccessPointPolicyStatus",
        "s3:ListMultiRegionAccessPoints",
        "s3:GetStorageLensConfiguration",
        "s3:GetStorageLensDashboard",
        "s3:ListStorageLensConfigurations",
        "s3:GetAccountPublicAccessBlock",
        "s3:PutAccountPublic",
        "s3:PutAccountPublicAccessBlock",
        "shield:*",
        "sts:*",
        "support:*",
        "trustedadvisor:*",
        "waf-regional:*",
        "waf:*",
        "wafv2:*",
        "access-analyzer:*"
      ],
      "Sid": "HOGEHOGE"
    }
  ]
}

なお、Control Towerは現時点で大阪リージョンをサポートしていないため、本機能を使う場合は大阪リージョンが使えなくなるので注意が必要です。上記のSCPを参考して個別にSCP作成、適用も可能なので、Control Tower管理リージョンと拒否リージョンを分けて設定する場合は、個別に適用が良いでしょう。

Landing Zoneのアップデート(2.9→3.0)手順

細かな手順は、以前の記事で紹介していますので、ここでは3.0の内容を中心に手順を書いておきます。

ランディングゾーン設定のページから、3.0を指定し更新を押します。

組織レベルの証跡は「有効にする」にしておきます。有効にしない場合はユーザーが独自にCloudTrailの証跡を設定する必要があります。

変更の概要が表示されるので確認し、

ランディングゾーンの更新を押します。

私の環境では全6アカウントで、30分ほどでアップデートが完了しました。

Landing Zoneの更新後は、各アカウントの更新も個別に行います。(Security OU(旧Core OU)は不要)

まとめ

3.0は変更内容も多く、中身を元々わからないと変更内容も理解が難しいなと思い、基本機能の内容も含めまとめてみました。 Control Towerはリリースされた当初からどんどん良い方向にアップデートされているので、今後のアップデートにも期待しています。

特に大阪リージョン対応とCloudTrail証跡の保存期間変更対応には期待しています・・! ⇒ログの保存期間が変更できるようになりました!詳細はコチラ  CloudWatch Logsの期間は2週間のままです。

執筆者上野史瑛

Japan APN Ambassador
AWSを中心としたクラウドの導入、最適化を専門に行っています。