AWS Control Tower 導入のために取り組んだこと

こんにちは!

アンドパッド SREチームの宜野座です。

今回はアンドパッドにてAWS Control Towerを導入した経緯や導入のために取り組んだことをまとめてみました。

AWS Control Tower自体は2021年4月に東京リージョンで使えるようになったばかりの新しいサービスです。

aws.amazon.com

そのため東京リージョンで導入したという事例も多くなく、AWS Control Towerを有効化して実際どういう影響があるのか読めない部分が多くありました。

導入するために悩んだ部分などを可能な範囲でまとめておりますので、ご参考になれば幸いです。

※ AWS Control Tower の導入の取り組みを中心として行ったことも評価され、社内にてMVPを受賞することにも繋がりました。 関わってくださった皆さまありがとうございます!

※ AWS Organizationsの有効化に関しては、本記事のスコープ外になります。 ※ 本記事内で紹介している手順、金額などは2022年11月時点での情報です。

AWS Control Towerとは?

AWS Control Tower は、マルチアカウントAWS 環境を統一したガバナンス体制でセットアップおよび管理するために利用できるサービスです。

AWSアカウントが複数あり、それぞれのアカウントの管理を整え、維持したいというケースには非常に有用なサービスかと思います。 また、新規アカウントセットアップ時の作業にかかる手間を軽減できる機能も備えています。

AWS Control Towerの解説はわかりやすい記事がいくつかあるため、詳しくは以下の記事もご参照ください。

tech.nri-net.com

dev.classmethod.jp

アンドパッドでAWS Control Towerを導入した経緯

今回AWS Control Towerの導入を検討したのは、新たな役割のAWSアカウントが増えるタイミングでした。

アンドパッドではアカウントの数が必要以上に増えて、SREの対応が追いつかない事態に陥らないように少数のアカウントを運用しています。

しかし、今後も既存のアカウントとは別の利用目的でAWSアカウントが増える可能性はゼロではありません。

AWSアカウントを新たに作成する際には

  • アカウントの権限設計
  • 禁止事項の検討
  • コストの管理
  • AWSにて最低限行いたい設定(CloudTrailやConfigの有効化、セキュリティ周りの設定(Guard Duty, SecurityHub, etc…))

など考慮しなければならないことがたくさんあります。

またそのAWSアカウントが適切に管理されていることを日々確認する必要がありますが、現在のアンドパッドではAWSアカウント管理を専門にしている部署はなくSREが中心として取り組んでいます。

今後もしアカウントが増えることになった場合、アカウントのセットアップ、セキュリティの整備、管理状況を確認、という作業をこれまで通り毎回行なっているとチームリソースが足りなくなり、他の重要なタスクの進捗などにも影響が出る可能性がありました。

そこでSREの課題を改善できるものとして、以下のような目的を持ってAWS Control Tower の導入の調査を開始しました。

目的

  • アカウントの新規開設を安全にスムーズにできるようにしたい
  • 現行の運用よりも高レイヤーのルールを適用・管理できるようにして、低レイヤーのルールの管理負荷を下げたい
  • 既にAWSによって組み込まれているガバナンスやベストプラクティスを簡単に把握・適用できるようにしたい
  • AWS環境に適用されたポリシーの概要およびアカウントのステータスを、統合的に確認できるようにしたい
  • AWSアカウントを安全に使用できるように全アカウントに共通のガードレールを整備していきたい
    • 使用リージョンの制限、ロギングの有効化、ルートユーザーの使用制限など

→ 上記の達成によって、いまSREが割いている労力や時間を、より肝心な生産活動・価値提供に割けるようにしたい

AWS Control Tower の導入のために調査したこと

1. AWS Control Towerの有効化の影響

AWS Control Towerを有効化した際に起きる主要な影響は、以下のようなものになります。

  • AWS Organizations 組織単位 (OU) が 2 つ作成される
    • Security OU とSandbox OU(任意)が新たに作成される
  • AWS Control Towerを有効化すると以下の2つのAWSアカウントがSecurity OUに新たに誕生する
    • 監査アカウント
      • 全AWSアカウントからGuardDutyやSecurity Hubの集約できたり(集約は自前で設定が必要)、セキュリティの問題を検知した時の修復を行うために各AWSアカウントへの特権を有している
      • 将来的にはアカウントセキュリティを担当する人がこちらから一元的に複数アカウントの状態を確認できる
    • ログアーカイブアカウント
      • 主に保全用で全AWSアカウントからCloudTrailやAWS Configなどのログが集約されてS3に保存される
  • 20 個の必須の予防ガードレールを適用する。2 つの必須の検出ガードレールを適用して設定違反を検出する
    • 必須の予防・検出ガードレールが新規作成される2つのアカウントに適応される
      • ConfigやCloudTrailの有効化や設定変更禁止など、既存の運用システムに影響を与えるものは含まれていない
      • 参照記事
  • AWS IAM Identity Center (AWS SSO)のグループが作成される
    • 外部IDプロバイダー x AWS SSOの設定など既存の設定があれば維持される
    • Control Towerのホームリージョンと AWS IAM Identity Center のリージョンと同じである必要がある
    • 参照記事

その他の影響については以下リンクも合わせてご覧ください。

docs.aws.amazon.com

2. AWS Control Towerへの既存のOU・アカウントの登録方法

AWS Organizationsはすでに有効化済みだったため、どのように既存のOU・アカウントを登録できるのかを調査しました。

OUの登録

OUの登録に関しては、こちらに記載のあるようにAWS Control Towerを有効化した時点では勝手にOUの登録は行われませんでした。

登録作業はAWS公式ドキュメントが詳しいため、必要に応じてこちらのドキュメントの下の階層にある「既存のOUの登録」、「新しいOUの作成」をご参照ください。

docs.aws.amazon.com

アカウントの登録

すでにAWS Configの設定がアカウントに存在している場合は、AWS Control Towerへの登録が失敗します。

docs.aws.amazon.com

AWS Configを各アカウントで有効化済みの場合は、以下のリンクの対応が必要になります。 ステップ1でAWSサポートへの依頼が必要になりますが、より安全にAWS Control Towerに既存のAWSアカウントを登録することができます。

docs.aws.amazon.com

3. AWS Control Tower 導入のための検討事項

既存のアカウントにどのように反映していくと良いのか、誰がAWS Control Towerの設定を変更できるのか、ガードレール設定変更の影響を事前に確認できるのかなどを検討しました。

既存のAWS OrganizationsにAWS Control Towerを適用していくための作業フロー例

本番環境への影響を抑えた上で導入するための作業フローの一例になります。 各企業によって適切な導入の流れは変わると思いますので、参考までに記載しております。

1.AWS Organizationsのマネージメントアカウントにて、AWS Control Towerを有効化する

  • Security OU配下に、監査アカウントとログアーカイブアカウントが作成される

2.本番稼働中ではなく、開発にも影響の出ないアカウントをAWS Control Towerに登録する

  • 必須ガードレールが本当に影響のないものかを再確認する
  • 任意のガードレールに関しても導入して効果の高いと思われるものを適応していく

3.必須のガードレールおよび任意のガードレールの設定が問題ないことが確認できたタイミングで随時開発環境として利用しているアカウントを登録していく

4.開発環境として利用しているアカウントで問題起きないことを確認後、本番環境として利用しているアカウントに適応していく

Control Tower(ガードレール)の設定変更者

AWS Organizations のマネジメントアカウントに入れる人が元々絞られているため、最小限の人のみが設定変更をできる状態で管理する想定です。

もしマネジメントアカウントで、IAMユーザーの整理や権限管理が行われていない場合はそちらを整える作業も必要になるかと思います。

ガードレールの設定変更の影響

ガードレールをOUに適応すると配下のアカウントのリソースに影響を及ぼすため、事前に別の本番アカウントが含まれないOUで動作を確認する必要があります。

  • リージョン制限
  • S3の設定変更禁止
  • etc...

docs.aws.amazon.com

4. ログアーカイブおよび監査アカウントの検討事項

AWS Control Towerと共に作成されてしまう2つのアカウント(ログアーカイブ、監査)の利用用途、利用者、コストの試算を行いました。

ログアーカイブおよび監査アカウントの利用用途

  • ログアーカイブアカウント
    • CloudTrailやConfigのログを確認したい時など、全アカウントのAWS関連のログを確認するために使う想定
  • 監査アカウント
    • SecurityHubとGuardDutyを一元管理する
    • 各アカウントでセキュリティの問題を検知した時の修復に使う想定

ログアーカイブおよび監査アカウントの利用者

最小限の人だけがログインできるように運用する ※ ログインはSSOで行われる想定

  • ログアーカイブアカウント
    • SRE + 最小ユーザー
  • 監査アカウント
    • SRE + 最小ユーザー

ログアーカイブおよび監査アカウントのコスト試算

  • ログアーカイブアカウント
    • S3のログ料金: 0.023USD/GB
      • CloudTrail: 1ヶ月のデータ量(GB) x 0.023USD x 12ヶ月 (1年分の料金)
      • Config: 1年のデータ量(GB) x 0.023USD
    • Athenaなどでログを調査する料金
    • AWS Control Towerの機能で作成されるリソースへの料金
      • AWS Service Catalog, AWS CloudTrail, AWS Config, Amazon CloudWatch, Amazon SNS...
  • 監査アカウント
    • Lambdaなどで各アカウントへのセキュリティ修復を実施するとした分だけコストがかかる

5. AWS Control Tower をやめるには

もし導入した後にやめたい場合はやめれるのか、どういった影響があるのかを調査しました。

主に以下の作業が必要になりますが、AWS Control Towerを廃止することはできます。

1. AWS Control Towerの追加要素の無効化・削除
2. 子アカウントへの一時的なIAM作成
3. 子アカウントのService Catalog製品削除
4. AWS Control Tower廃止
5. AWS Control Tower IAM Role/Policy削除
6. CloudWatch Logsグループ削除
7. AWS SSOの削除
8. OrganizationsでのAWS Control Tower統合の無効化

引用元: https://dev.classmethod.jp/articles/decommission-control-tower/

AWS Control Towerを廃止すること自体はアカウントやログも保持された状態で行われるため、サービスに何か直接影響を与えることはないようです。

そんな中でも以下のようなリスクは考えられました。

  • 削除の順番を間違えると、サポートに問い合わせをしないと消せないリソースが発生する
  • 最低限のリソースしか削除されないため、今後使用しない場合しっかり削除リソースを洗い出さないと不要なお金がかかる
  • 各アカウントでガードレールで防げていたはずのものが防げなくなるので、アカウントのガードレールの見直しが必要になる

またAWS Control Towerを丸ごと廃止にするのではなく、一部のアカウントをAWS Control Tower管理から除外することももちろんでき、こちらもControl Towerが作成したリソースを削除するのみなので既存リソースには直接影響なく行えます。

手順は以下のAWS公式ドキュメントに記載があります。

docs.aws.amazon.com

他の検討事案とAWS Control Towerのメリット・デメリット

他の検討事案

AWSアカウントの一元管理を他に行う方法がないかを検討しましたが、以下の点を考慮して AWS Control Towerを選択しました。

AWSアカウント管理の専任担当者(社内外の方)を配置する

  • 社内には専任でAWSアカウント管理の担当者をできるリソースがない
  • 社外に求める場合アカウント管理専任の人材を雇う or お金を支払い外部に依頼することになると思うが、大きくメリットを感じるほどアカウントはまだ多くない

外部のマルチアカウント管理ソリューションにコストを支払い課題解決を試みる

デメリット

  • 外部のサービスに依頼する場合も、窓口としてSREが行う場合コミュニケーションコストが発生する
  • 柔軟に既存のリソースに影響なく対応できるかは未知数で、AWSアカウントとは別でコストが発生する

AWS Control Towerのメリット・デメリット

SREチームでAWS Control Towerを導入し、マルチアカウントガバナンス対応をすることには以下のようなメリット・デメリットがあるように思いました。

メリット

  • 複数アカウントを管理するナレッジがアンドパッドに蓄積される
  • これまでの運用に合った方法で適切なガードレールを設定できる
  • AWSの推奨するマルチアカウント管理を実現できる
  • 比較的簡単に利用できるので、SREの工数も節約しながらより安全に管理できるようになる
  • AWS Control Tower自体のコストは無料なので、追加の課金は発生しない

デメリット

  • 比較的新しいサービスのため導入事例が少ない
  • 導入して何が起きるのかはっきりわからない部分が多い
  • 初回導入時に検討することが多い

Q&A

その他いくつか疑問に思ったことの調査結果をまとめて記載します。

Q. AWS Control Towerによって作成される二つのアカウントにルートユーザーとしてログインすることは可能か。

監査アカウントとログアーカイブアカウントには作成時点でSSOによってログインすることができますが、ルートユーザーのログイン情報を設定する流れはAWS Control Tower有効化時にはありません。

ルートユーザーへはMFAの登録が推奨されているため設定できるのかを調査していました。

A.

AWSナレッジセンターに回答がありました。

ルートユーザーとしてログインしたい場合は、以下の手順でログインでき、MFAの設定などを行えました。

aws.amazon.com

Q. AWS Configをもし一度無効化した場合、過去のデータはどうなるのか。S3にデータが残っているため、有効化後再度トレースが可能となるのか。

現在はAWS Configを無効化せずに行う方法が整備されていますが、過去の事例を調査しているとAWS Configを一度無効化してAWS Control Towerに登録するという手順が主だったように思います。

もしAWS Configを無効化せずに登録する作業がうまくいかなかった場合に備えて調査していました。

A.

無効化中も AWS Config 側のデータの保持期間の設定に基づきデータが保持され、再度有効化すれば過去のデータの確認が可能とのことでした。 (サポートに確認)

Q. SecurityHubやGuardDutyの集約をした場合に、コストは両方のアカウントで発生してしまうのか。

A.

どちらもサービスを利用している各アカウントで料金が発生し、集約されたアカウントで追加の料金は発生しないとのことでした。 (サポートに確認)

Q. Control Towerによって保存されるCloudTrailのログは1年間しか残らないのか。

A.

最近のアップデートで最大15年に変更できるようになりました。

tech.nri-net.com

Q. Control Tower の管理下に登録されたアカウントのAWS Configのデータはこれまで通り各アカウントで確認できるのか。

A.

アグリゲータにより監査アカウント内にデータが集約されますが、今まで通り各メンバーアカウント側でも確認が可能とのことでした。 (サポートに確認)

まとめ

今回はAWS Control Towerについて、導入するために取り組んだことについてご紹介させていただきました。

AWS Control Tower の導入はAWSアカウントがすでにたくさんある企業ではなくても、今後のチームの負担を権限させたいなど将来を見据えて検討してみるのも良いかもしれません。

長くなりましたが、一つの事例としてどなたかのお役に立てれば何よりです!

終わりに

アンドパッド SRE ではアカウント運用の改善以外にも、様々なことに取り組んでいます。

興味を持たれた方は、求人情報をご覧ください! hrmos.co

SREはもちろん大募集中ですが、さまざまなポジションで仲間を募集しています!

詳しくは下記サイトをご覧ください。

engineer.andpad.co.jp

hrmos.co