2021 年 1 月~ 12 月 - AWS Control Tower

2021 年 1 月~ 12 月

2021 年 1 月以降、AWS Control Tower は次の更新をリリースしました。

リージョン拒否機能

2021 年 11 月 30 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

AWS Control Tower は、AWS Control Tower 環境で登録済みアカウントの AWS のサービスおよびオペレーションへのアクセスを制限するのに役立つリージョン拒否機能を提供するようになりました。リージョン拒否機能は、AWS Control Tower の既存のリージョン選択およびリージョン選択解除機能を補完します。これらの機能を組み合わせて、追加のリージョンへの拡大に伴うコストのバランスをとり、コンプライアンスや規制上の懸念に対処するのに役立ちます。

たとえば、ドイツの AWS のお客様は、フランクフルトリージョン外のリージョンの AWS サービスへのアクセスを拒否できます。制限付きリージョンは、AWS Control Tower の設定プロセス中に、または [Landing zone settings] (ランディングゾーンの設定) ページで選択することができます。リージョン拒否機能は、AWS Control Tower ランディングゾーンのバージョンを更新するときに使用できます。選択した AWS のサービスは、リージョン拒否機能から除外されます。詳細については、「リージョン拒否ガードレールの設定」を参照してください。

データ所在地機能

2021 年 11 月 30 日

(AWS Control Tower ランディングゾーンの更新は不要です)

AWS Control Tower では、AWS のサービスにアップロードする顧客データが、指定した AWS リージョンにのみ配置されるように、特定用途向けのガードレールが提供されるようになりました。顧客データが保存および処理される AWS リージョンを選択できます。AWS Control Tower を使用できる AWS リージョンの全リストについては、「AWS リージョン別のサービス表」を参照してください。

きめ細かく制御するには、[Disallow Amazon Virtual Private Network (VPN) connections] (Amazon Virtual Private Network (VPN) 接続を許可しない) や [Disallow internet access for an Amazon VPC instance] (Amazon VPC インスタンスのインターネットアクセスを許可しない) などの追加のガードレールを適用できます。AWS Control Tower コンソールでガードレールのコンプライアンスステータスを表示できます。使用可能なガードレールの完全なリストについては、「ガードレールリファレンス」を参照してください。

AWS Control Tower で、Terraform アカウントのプロビジョニングとカスタマイズが導入されました

2021 年 11 月 29 日

(AWS Control Tower ランディングゾーンのオプションの更新)

AWS Control Tower Account Factory for Terraform (AFT) により、AWS Control Tower を通じて、Terraform を使用し、カスタマイズされたアカウントをプロビジョニングおよび更新できるようになりました。

AFT は、単一の Terraform Infrastructure as Code (IaC) パイプラインを提供し、AWS Control Tower が管理するアカウントをプロビジョニングします。プロビジョニング中のカスタマイズは、アカウントをエンドユーザーに提供する前に、ビジネスポリシーとセキュリティポリシーを満たすのに役立ちます。

AFT 自動アカウント作成パイプラインは、アカウントのプロビジョニングが完了するまで監視し、引き続き、必要なカスタマイズでアカウントを強化する追加の Terraform モジュールをトリガーします。カスタマイズプロセスの追加部分として、独自のカスタム Terraform モジュールをインストールするようにパイプラインを設定したり、AWS によって一般的なカスタマイズ用に提供される AFT 機能オプションを追加するように選択することもできます。

AWS Control Tower Account Factory for Terraform の使用を開始するには、「AWS Control Tower ユーザーガイド」の「AWS Control Tower Account Factory for Terraform (AFT) のデプロイ」に記載されているステップに従い、Terraform インスタンスの AFT をダウンロードします。AFT は、Terraform Cloud、Terraform Enterprise、および Terraform Open Source のディストリビューションをサポートしています。

新しいライフサイクルイベントが利用可能に

2021 年 11 月 18 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

PrecheckOrganizationalUnit イベントは、ネストされた OU のリソースを含め、[Extend governance] (ガバナンスを拡張) タスクが成功しないようリソースがブロックしているかどうかを記録します。詳細については、「PrecheckOrganizationalUnit」を参照してください。

AWS Control Tower でネストされた OU が有効になりました

2021 年 11 月 16 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

AWS Control Tower では、ランディングゾーンの一部として、ネストされた OU を含めることができるようになりました。

AWS Control Tower は、ネストされた組織単位 (OU、Organizational Unit) のサポートを提供して、アカウントを複数の階層レベルに編成し、予防ガードレールを階層的に実施できるようにします。深さに関係なく、ネストされた OU を含む OU を登録し、親 OU の下に OU を作成して登録し、登録された OU でガードレールを有効にすることができます。この機能をサポートするために、管理されているアカウントと OU の数がコンソールに表示されます。

ネストされた OU を使用すると、AWS Control Tower の OU を AWS マルチアカウント戦略に合わせることができます。また、親 OU レベルでガードレールを適用することで、複数の OU でガードレールを有効にするために必要な時間を短縮できます。

主な考慮事項

  1. AWS Control Tower に既存のマルチレベル OU を登録するときは、OU を 1 つずつ登録します。最上位の OU から開始し、ツリーの下の方へと進めます。詳細については、「フラットな OU 構造からネストされた OU 構造への拡張」を参照してください。

  2. 登録された OU の直下のアカウントは自動的に登録されます。ツリーの下の方にあるアカウントは、直接の親 OU を登録することで登録できます。

  3. 予防ガードレール (SCP) は自動的に階層の下の方に継承されます。親に適用された SCP は、すべてのネストされた OU に継承されます。

  4. 検出ガードレール (AWS Config ルール) は自動的に継承されません。

  5. 検出ガードレールのコンプライアンスは、各 OU によって報告されます。

  6. OU の SCP ドリフトは、その下にあるすべてのアカウントと OU に影響します。

  7. セキュリティ OU (コア OU) の下に新しいネストされた OU を作成することはできません。

検出ガードレールの同時実行性

2021 年 11 月 5 日

(AWS Control Tower ランディングゾーンのオプションの更新)

AWS Control Tower 検出ガードレールは、検出ガードレールの同時オペレーションをサポートするようになり、使いやすさとパフォーマンスが向上しました。個々のガードレールオペレーションが完了するのを待たずに、複数の検出ガードレールを有効にできます。

サポートされている機能:

  • 同じ OU で異なる検出ガードレールを有効にします (例えば、[Detect Whether MFA for the Root User is Enabled] (ルートユーザーに対して MFA が有効になっているかどうかを検出する) と [Detect Whether Public Write Access to Amazon S3 Buckets is Allowed] (Simple Storage Service (Amazon S3) バケットへのパブリック書き込みアクセスが許可されているかどうかを検出する))。

  • 異なる OU で異なる検出ガードレールを同時に有効にします。

  • ガードレールのエラーメッセージングが改善され、サポートされているガードレールの同時実行オペレーションに関する追加のガイダンスが提供されるようになりました。

このリリースではサポートされない機能:

  • 同じ検出ガードレールを複数の OU で同時に有効にすることはサポートされていません。

  • 予防ガードレールの同時実行はサポートされていません。

AWS Control Tower のすべてのバージョンで、検出ガードレールの同時実行性の改善を体験できます。現在バージョン 2.7 を使用していないお客様は、最新バージョンで利用できるリージョンの選択や選択解除などの機能を利用できるように、ランディングゾーンの更新を実行することをお勧めします。

2 つの新しいリージョンが利用可能に

2021 年 7 月 29 日

(AWS Control Tower ランディングゾーンは更新が必要です。)

AWS Control Tower が 2 つの追加 AWS リージョン、すなわち南米 (サンパウロ) と欧州 (パリ) で利用可能になりました。この更新により、AWS Control Tower の可用性が 15 の AWS リージョンに拡張されます。

AWS Control Tower を初めて使用する場合も、サポートされている任意のリージョンですぐに起動できます。起動時に、AWS Control Tower でマルチアカウント環境を構築および管理するリージョンを選択できます。

AWS Control Tower 環境が既にあり、サポートされている 1 つ以上のリージョンの AWS Control Tower ガバナンス機能を拡張または削除する場合は、AWS Control Tower ダッシュボードの [Landing Zone Settings] (ランディングゾーンの設定) ページに移動し、[Regions] (リージョン) を選択します。ランディングゾーンを更新したら、AWS Control Tower によって管理されているすべてのアカウントを更新する必要があります。

リージョンの選択解除

2021 年 7 月 29 日

(AWS Control Tower ランディングゾーンのオプションの更新)

AWS Control Tower リージョンの選択解除により、AWS Control Tower リソースの地理的フットプリントを管理する機能が強化されます。AWS Control Tower の管理を望まないリージョンの選択を解除できます。この機能により、追加のリージョンへの拡大に伴うコストのバランスをとりながら、コンプライアンスや規制に関する懸念に対処できます。

リージョンの選択解除は、AWS Control Tower ランディングゾーンのバージョンを更新するときに使用できます。

Account Factory を使用して新しいアカウントを作成するか、既存のメンバーアカウントを登録する場合、または [Extend Governance] (ガバナンスを拡張) を選択して既存の組織単位にアカウントを登録する場合、AWS Control Tower は、アカウントの選択したリージョンにガバナンス機能 (一元化されたロギング、モニタリング、ガードレールなど) をデプロイします。リージョンの選択を解除し、そのリージョンから AWS Control Tower ガバナンスを削除すると、そのガバナンス機能は削除されますが、それらのリージョンに AWS リソースまたはワークロードをデプロイするユーザーの機能が阻止されることはありません。

AWS Control Tower が AWS キー管理システムに対応するようになりました

2021 年 7 月 28 日

(AWS Control Tower ランディングゾーンのオプションの更新)

AWS Control Tower では、AWS キー管理サービス (AWS KMS) キーを使用するオプションが提供されるようになりました。AWS Control Tower がデプロイするサービス (AWS CloudTrail、AWS Config、関連する Amazon S3 データなど) をセキュリティで保護するために、お客様によるキーの提供と管理が行われます。AWSKMS 暗号化は、AWS Control Tower がデフォルトで使用する SSE-S3 暗号化に対する強化された暗号化レベルです。

AWS Control Tower への AWS KMS サポートの統合は、機密ログファイルにセキュリティレイヤーを追加することを推奨する、AWS 基礎セキュリティのベストプラクティスに合致しています。保管時の暗号化には AWS KMS マネージドキー (SSE-KMS) を使用する必要があります。AWSKMS 暗号化のサポートは、新しいランディングゾーンを設定するとき、または既存の AWS Control Tower ランディングゾーンを更新するときに使用できます。

この機能を設定するには、ランディングゾーンの初期設定時に [KMS Key Configuration] (KMS キー設定) を選択します。既存の KMS キーを選択できます。新しいキーを作成する場合は、AWS KMS コンソールに移動するボタンを選択します。また、デフォルトの暗号化から SSE-KMS、または別の SSE-KMS キーに変更できる柔軟性があります。

既存の AWS Control Tower ランディングゾーンでは、更新を実行して AWS KMS キーの使用を開始できます。

ガードレールの名前変更、機能は変更なし

2021 年 7 月 26 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

AWS Control Tower は、ガードレールのポリシー意図をよりよく反映するように、特定のガードレールの名前と説明を改訂しています。改訂された名前と説明は、ガードレールがアカウントの制御を強化する方法をより直感的に理解するのに役立ちます。例えば、検出ガードレール自体が特定のアクションを停止せず、ポリシー違反を検出し、ダッシュボードを介してアラートを提供するだけなので、検出ガードレールの名前の一部を「許可しない」から「検出」に変更しました。

ガードレールの機能、ガイダンス、および実装は変更ありません。ガードレールの名前と説明のみ改訂されています。

AWS Control Tower は SCP を毎日スキャンしてドリフトをチェックするようになりました

2021 年 5 月 11 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

AWS Control Tower は、管理対象の SCP を毎日自動スキャンして、対応するガードレールが正しく適用され、ドリフトが発生していないことを確認するようになりました。スキャンでドリフトが検出されると、通知が届きます。AWS Control Tower は、ドリフトの問題ごとに通知を 1 つだけ送信するため、ランディングゾーンが既にドリフト状態にある場合、新しいドリフトアイテムが見つからない限り、追加の通知が送信されることはありません。

OU とアカウントのカスタマイズされた名前

2021 年 4 月 16 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

AWS Control Tower で、ランディングゾーンの名前付けをカスタマイズできるようになりました。AWS Control Tower が組織単位 (OU、Organizational Unit) およびコアアカウントに推奨する名前を保持するか、ランディングゾーン初期設定プロセス中にこれらの名前を変更することができます。

AWS Control Tower が OU およびコアアカウントに提供するデフォルトの名前は、AWS マルチアカウントのベストプラクティスのガイダンスに合致しています。ただし、会社に特定の命名ポリシーがある場合、あるいは同じ推奨名を持つ既存の OU またはアカウントが既に存在する場合は、この新しい OU およびアカウント命名機能によって、これらの制約に柔軟に対応できます。

設定時のこのワークフローの変更とは別に、以前はコア OU と呼ばれていた OU はセキュリティ OU と呼ばれ、以前はカスタム OU と呼ばれていた OU はサンドボックス OU と呼ばれるようになりました。命名に関する全体的な AWS ベストプラクティスのガイダンスとの連携を改善するために、この変更を加えました。

新しいお客様には、これらの新しい OU 名が表示されます。既存のお客様には、これらの OU の元の名前が引き続き表示されます。ドキュメントを新しい名前に更新している間、OU の命名に不一致が生じることがあります。

AWS マネジメントコンソールから AWS Control Tower の使用を開始するには、AWS Control Tower コンソールに移動し、右上の [Set up landing zone] (ランディングゾーンの設定) を選択します。詳細については、「AWS Control Tower ランディングゾーンの計画」を参照してください。

AWS Control Tower ランディングゾーンバージョン 2.7

2021 年 4 月 8 日

(AWS Control Tower のランディングゾーンをバージョン 2.7 に更新する必要があります。詳細については、「ランディングゾーンを更新する」を参照してください。)

AWS Control Tower バージョン 2.7 では、AWS Control Tower のリソースにのみポリシーを実装する 4 つの新しい必須予防的ログアーカイブガードレールが導入されました。AWS Control Tower の外にあるリソースのポリシーを設定するため、4 つの既存のログアーカイブガードレールのガイダンスを必須から選択的に調整しました。このガードレールの変更と拡張により、AWS Control Tower 内のリソースのログアーカイブガバナンスと AWS Control Tower 外のリソースのガバナンスを分離できます。

4 つの変更されたガードレールは、新しい必須ガードレールと組み合わせて使用して、より広範な AWS ログアーカイブセットにガバナンスを提供できます。既存の AWS Control Tower 環境では、環境の一貫性を保つため、これらの 4 つの変更されたガードレールが自動的に有効になります。ただし、これらの選択的ガードレールは無効にできるようになりました。新しい AWS Control Tower 環境では、すべての選択的ガードレールを有効にする必要があります。既存の環境では、AWS Control Tower によってデプロイされていない Amazon S3 バケットに暗号化を追加する前に、以前は必須のガードレールを無効にする必要があります。

新しい必須ガードレール:

  • Disallow Changes to Encryption Configuration for AWS Control Tower Created Amazon S3 Buckets in Log Archive (AWS Control Tower がログアーカイブに作成した Simple Storage Service (Amazon S3) バケットの暗号化設定の変更を許可しない)

  • Disallow Changes to Logging Configuration for AWS Control Tower Created Amazon S3 Buckets in Log Archive (AWS Control Tower がログアーカイブに作成した Simple Storage Service (Amazon S3) バケットのログ設定の変更を許可しない)

  • Disallow Changes to Bucket Policy for AWS Control Tower Created Amazon S3 Buckets in Log Archive (AWS Control Tower がログアーカイブに作成した Simple Storage Service (Amazon S3) バケットのバケットポリシーの変更を許可しない)

  • Disallow Changes to Lifecycle Configuration for AWS Control Tower Created Amazon S3 Buckets in Log Archive (AWS Control Tower がログアーカイブに作成した Simple Storage Service (Amazon S3) バケットのライフサイクル設定の変更を許可しない)

必須から選択的に変更されたガイダンス:

  • Disallow Changes to Encryption Configuration for all Amazon S3 Buckets (すべての Simple Storage Service (Amazon S3) バケットの暗号化設定の変更を許可しない) [Previously: Enable Encryption at Rest for Log Archive (以前: ログアーカイブの保管時に暗号化を有効にする)]

  • Disallow Changes to Logging Configuration for all Amazon S3 Buckets (すべての Simple Storage Service (Amazon S3) バケットのログ設定の変更を許可しない) [Previously: Enable Access Logging for Log Archive (以前: ログアーカイブのアクセスログを有効にする)]

  • Disallow Changes to Bucket Policy for all Amazon S3 Buckets (すべての Amazon S3 バケットのバケットポリシーの変更を不許可にする) [Previously: Disallow Policy Changes to Log Archive (以前: ログアーカイブのポリシー変更を禁止する)]

  • Disallow Changes to Lifecycle Configuration for all Amazon S3 Buckets (すべての Simple Storage Service (Amazon S3) バケットのライフサイクル設定の変更を許可しない) [Previously: Set a Retention Policy for Log Archive (以前: ログアーカイブの保持ポリシーを設定する)]

AWS Control Tower バージョン 2.7 には、2.7 にアップグレードした後に以前のバージョンとの互換性がなくなる可能性がある AWS Control Tower ランディングゾーンのブループリントに対する変更が含まれています。

  • 特に、AWS Control Tower バージョン 2.7 では、AWS Control Tower によってデプロイされた S3 バケットで自動的に BlockPublicAccess が有効になります。ワークロードでアカウント全体のアクセスが必要な場合は、このデフォルトをオフにすることができます。BlockPublicaccess を有効にした場合の動作については、「Amazon S3 ストレージへのパブリックアクセスのブロック」を参照してください。

  • AWS Control Tower バージョン 2.7 には HTTPS の要件が含まれています。AWS Control Tower によってデプロイされた S3 バケットに送信されるすべてのリクエストは、Secure Sockets Layer (SSL) を使用する必要があります。HTTPS リクエストのみ渡すことができます。HTTP (SSL なし) をエンドポイントとして使用してリクエストを送信すると、この変更によってアクセス拒否エラーが発生し、ワークフローが中断する可能性があります。ランディングゾーンを 2.7 に更新した後で、この変更を元に戻すことはできません。

    HTTP の代わりに TLS を使用するようにリクエストを変更することをお勧めします。

3 つの新しい AWS リージョンが利用可能に

2021 年 4 月 8 日

(AWS Control Tower ランディングゾーンは更新が必要です。)

AWS Control Tower が、アジアパシフィック (東京) リージョン、アジアパシフィック (ソウル) リージョン、アジアパシフィック (ムンバイ) リージョンの 3 つの追加 AWS リージョンで利用可能になりました。これらのリージョンにガバナンスを拡大するには、ランディングゾーンをバージョン 2.7 に更新する必要があります。

バージョン 2.7 への更新を実行しても、ランディングゾーンがこれらのリージョンに自動的に展開されることはありません。含まれるようにするには、リージョン表でそれらを表示して選択する必要があります。

選択したリージョンのみを管理

2021 年 2 月 19 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

AWS Control Tower リージョンを選択すると、AWS Control Tower リソースの地理的フットプリントをより適切に管理できます。コンプライアンス、規制、コスト、その他の理由から、AWS リソースまたはワークロードをホストするリージョンの数を増やすために、管理するリージョンを追加で選択できるようになりました。

リージョン選択は、新しいランディングゾーンを設定するか、AWS Control Tower ランディングゾーンのバージョンを更新するときに利用できます。Account Factory を使用して新しいアカウントを作成するか、既存のメンバーアカウントを登録する場合、または [Extend Governance] (ガバナンスを拡張) を使用して既存の組織単位にアカウントを登録する場合、AWS Control Tower は、アカウントの選択したリージョンにガバナンス機能 (一元化されたロギング、モニタリング、ガードレール) をデプロイします。リージョンの選択の詳細については、「AWS Control Tower リージョンの設定」を参照してください。

AWS Control Tower は AWS 組織の既存の OU にガバナンスを拡張するようになりました

2021 年 1 月 28 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

AWS Control Tower コンソール内から既存の組織単位 (OU、Organizational Unit) (AWS Control Tower にない OU) にガバナンスを拡張します。この機能を使用すると、最上位の OU と含まれるアカウントを AWS Control Tower ガバナンス下に置くことができます。OU 全体へのガバナンスの拡張については、「AWS Control Tower への既存の組織単位の登録」を参照してください。

OU を登録すると、AWS Control Tower は一連のチェックを実行して、ガバナンスの拡張と OU 内のアカウントの登録が正常に行われていることを確認します。OU の初期登録に関連する一般的な問題の詳細については、「登録時または再登録時に発生する障害のよくある原因」を参照してください。

また、AWS Control Tower 製品ウェブページにアクセスしたり、YouTube にアクセスして AWS Organizations 向け AWS Control Tower の開始方法に関する動画を視聴することもできます。

AWS Control Tower でアカウントの一括更新が可能になりました

2021 年 1 月 28 日

(AWS Control Tower ランディングゾーンに更新は必要ありません。)

一括更新機能により、最大 300 個のアカウントを含む登録済みの AWS Organizations 組織単位 (OU、Organizational Unit) のすべてのアカウントを、AWS Control Tower ダッシュボードから、1 回のクリックで更新できるようになりました。これは、AWS Control Tower ランディングゾーンを更新し、現行のランディングゾーンのバージョンに合うように登録済みアカウントも更新する必要がある場合に特に便利です。

また、この機能は、AWS Control Tower ランディングゾーンを更新して新しいリージョンに拡張する場合や、OU を再登録して OU のすべてのアカウントに最新のガードレールが適用されるようにする場合に、アカウントを最新状態に保つのに役立ちます。アカウントの一括更新により、アカウントを 1 つずつ更新したり、外部スクリプトを使用して複数のアカウントに対して更新を実行したりする必要がなくなります。

ランディングゾーンの更新の詳細については、「ランディングゾーンを更新する」を参照してください。

OU の登録または再登録の詳細については、「AWS Control Tower への既存の組織単位の登録」を参照してください。