AWS Control Tower の前提条件の事前チェックでアカウント個別で設定済みの AWS Config を検出できるのか確認してみた

大村保貴

2022.10.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Control Tower を登録するための前提条件に既存アカウントの AWS Config を変更するか、削除する必要があると説明されています。

If you have an existing AWS Config recorder, delivery channel, or aggregation setup in any existing accounts that you plan to enroll in AWS Control Tower, you must modify or remove these configurations before you start enrolling the accounts, after your landing zone is set up. This pre-check doesn't apply to the AWS Control Tower management account during landing zone launch. For more information, see Enroll accounts that have existing AWS Config resources.

Prerequisite: Automated pre-launch checks for your management account - AWS Control Tower

ランディングゾーンをセットアップ中のマネジメントアカウントには前提条件の事前チェックが適用されないようなのですが、いまいち意味がわからなかったので前提条件の事前チェックで Config の設定のどこをみているのか試してみた記録です。

確認結果

Organizaiotns から Config を有効化しているときは、「ランディングゾーンの設定」の前提条件の事前チェックで検出される
各アカウントで Config 設定を有効化していても、「ランディングゾーンの設定」の前提条件の事前チェックで検出されない
Control Tower 有効化と同時に既存の監査・ログアーカイブアカウントを取り込むとき、既存アカウントに Config 設定があるとランディングゾーンのセットアップに失敗する

検証環境

検証時のランディングゾーンのバージョンは 3.0です。

OU 構成は以下の状態です。Control Tower で作成される Securit OU 以前に、Organizations 環境で Security OU 配下に Audit アカウント、LogArchive アカウントを作成し運用している環境です。

前提条件

Control Tower 有効化するためには前提条件を満たさないことには始まりません。本記事では Config の前提条件を確認します。

前提条件を満たせていないとき

AWS Organizationsを使用して監査や証跡確認のために、Config や CloudTrail を有効化している環境です。

ドキュメントを確認すると Organizaiotns から有効化している Config と CloudTrail の無効化が必要となっています

The AWS account cannot have trusted access enabled in the organization management account for AWS Config or CloudTrail.

Prerequisite: Automated pre-launch checks for your management account - AWS Control Tower

この状態で「ランディングゾーンの設定」から前提条件の事前チェックを行います。

「AWS Config から組織のサブスクリプションを解除する必要があります。」想定どおり前提条件をパスできなく弾かれました。

Organizations で設定している Config を無効化します。

Config は無効化、CloudTrail は有効化された状態になりました。通常であれば CloudTrail も無効化するところですが CloudTrail は有効化のまま進めます。

再度「ランディングゾーンの設定」から前提条件の事前チェックを行います。思いの外パスしたのでランディングゾーンの設定値を入力する画面が表示されました。

CloudTrail は無効化しなくてよいのか？という新たな疑問が生まれましたが Config の確認が目的なのでおいておきます。CloudTrail が有効化されていると事前チェックで弾かれた例は以下のブログから確認できます。ランディングゾーンのバージョンによるものか、検証条件が異なったのか、なにかしらの違いはありそうです。

各アカウントの Config を有効化した場合

Config については想定どおり、ドキュメントから読み取れる内容でした。個人的に検証したかったのはOrganizaiotns で有効化した Config ではなく、各アカウントで Config を有効化していた場合、前提条件の事前チェックで検出されるのか？です。

マネジメントアカウントの Config を有効化していた場合

Organizations で有効化していた Config は無効化し、マネジメントは単独で Config を有効化している状態です。

Organizaiotns の Config は無効化している。

マネジメントアカウントの Config は有効化している。

この状態で「ランディングゾーンの設定」から前提条件の事前チェックを行います。パスしたのでランディングゾーンの設定値を入力する画面が表示されました。

メンバーアカウントの Config を有効化していた場合

メンバーアカウントでも同様のことを試してみました。同様に前提条件のチェックはパスできました。こちらはマネジメントアカウントとは異なり、Control Tower の管理下にアカウントを取り込むまでは Config 既存の設定があっても影響はないし、存在する全メンバーアカウントを事前に前提条件の事前チェックする必要性は感じられないため、検出されないのも当然かもしれません。

Config が有効だった場合の問題とは？

各アカウントの Config 設定を個別に事前チェックしていないことがわかりました。

そもそも Config が有効化されているなにが問題なのか？という点ではレコーダーの設定がひとつしか作成できないため、既存のレコーダー設定があると、Control Tower から作成する設定とバッティングしてしまうためでしょう。そのため、Config の設定が削除されていることが前提とされているのではないかと思います。

CT 有効化時と同時に既存アカウントを取り込む場合は？

Control Tower 有効化時にデフォルトは新規に監査アカウントと、ログアーカイブアカウントを作成します。既存の監査アカウント、ログアーカイブアカウントを指定して Control Tower に取り込むこともできます。詳しくは以下のリンクで解説されています。

Control Tower 有効化と同時に個別に Config を有効化している既存の監査アカウントと、ログアーカイブアカウントを取り込むとどうなるのか？これも検証してみたかったのでやってみます。

このアカウント指定は「ランディングゾーンの設定」をクリックして進んだ後の画面です。つまり、前提条件の事前チェックはパス状態でアカウントを指定することなります。

マネジメントアカウントの Config は削除済みで、監査アカウントには個別で Config 設定を有効化してある状態で、既存の監査アカウントと、ログアーカイブアカウントを指定して Control Tower を有効化したところ、ランディングゾーンのセットアップ待ちまで進行しました。とくに事前チェックが走っている様子もありませんでした。

しばらく経つと Config 設定がすでにあるとエラーを吐いてランディングゾーンのセットアップは失敗しました。

Config 設定の削除は Control Tower 有効化の前提条件ですから当然の結果ですが「ランディングゾーンの設定」をクリックしたときの前提条件の事前チェックや、既存アカウントを指定して Control Tower 有効化処理を開始するまでの間に既存のアカウントに個別に設定された Config の設定有無のチェックが入らないということが確認できました。

実行時エラーになって Control Tower のセットアップに失敗するため、余計に手間にかかると思いますので事前に Config 設定は削除しておきましょう。

Control Tower を有効化したときの Config 設定

Controrol Tower を有効化したあとに Control Tower から自動で設定される Config 設定を確認しておきます。検証のため発生した Conig のエラーを解消し再びランディングゾーンのセットアップを再開させ、セットアップを完了させました。

マネジメントアカウント

マネジメントアカウントには Control Tower から Config 設定が入りませんでした。「ランディングゾーンの設定」からの前提条件の事前チェックされなかったのもどのみち設定が入らないからでしょうか。今回は一般的なお作法でマネジメントアカウントに個別に Config 設定は入れずにランディングゾーンのセットアップをしてしまったのでそこまで確認できていません。

[cloudshell-user@ip-10-0-108-28 ~]$ aws configservice describe-configuration-recorders
{
    "ConfigurationRecorders": []
}
[cloudshell-user@ip-10-0-108-28 ~]$ aws configservice describe-delivery-channels
{
    "DeliveryChannels": []
}

メンバーアカウント

Control Tower 管理下のメンバーアカウントには Config 設定が入りました。前提条件どおり Config は事前に削除しておく必要がありますね。現にランディングゾーンのセットアップ中に一度失敗していますし。

確認できたこと

Organizaiotns から Config を有効化しているときは、「ランディングゾーンの設定」の前提条件の事前チェックで検出される
各アカウントで Config 設定を有効化していても、「ランディングゾーンの設定」の前提条件の事前チェックで検出されない
Control Tower 有効化と同時に既存の監査・ログアーカイブアカウントを取り込むとき、既存アカウントに Config 設定があるとランディングゾーンのセットアップに失敗する