カバー株式会社におけるAWS Control Towerの導入

この記事はカバー株式会社 Advent Calendar 2023 14日目の記事になります。
カバー株式会社でSREをしているSです。よろしくお願いします。

前回の記事は @kura_cvr によるGitHub ActionsでUnityのお手軽CIでした。こちらの記事もぜひご覧ください。

この記事について

これからAWS Control Towerを導入される方に向けて、カバー株式会社においてAWS Control Towerを導入した流れについてご説明します。
導入方法については公式のドキュメント等があるため、この記事では管理者としての導入の進め方について着目します。

AWS Control Towerの導入前の課題

AWS Control Towerの導入前はAWS Organizationsで手動でアカウントやユーザの管理がされていました。そのため以下のような課題がありました。

• マルチアカウントに対して統一されたセキュリティやガバナンスを効かせられていない
• それゆえベストプラクティスに違反するリソースがある
• リソース操作について証跡が保全されていない

これらの課題を解決するためにAWS Control Towerを導入することにしました。

AWS Control Towerについて

AWS Control Towerは複数アカウント環境を設定して管理するためのサービスです。コントロールによってAWS環境全体にベストプラクティス、標準、規制要件を適用します。その他にもAccount Factoryによるアカウント作成の自動化や、ダッシュボードによってプロビジョニングされているアカウントを監視でき、コントロールに非準拠のリソースを確認できます。
また、AWS Control Towerに登録されたメンバーアカウントはCloudTrailによる証跡の保全が行われます。

AWS Control Towerの導入

AWS Control Towerの導入について管理者として行ったことを説明します。

メンバーアカウント管理者への説明

まずAWS Control Tower管理者向けのベストプラクティスにそってメンバーアカウント管理者に説明をする必要があります。

予防コントロール

AWS Control Towerは予防コントロールによってリソースへの操作が妨げられ生産性に影響する可能性があります。よって、適用される予防コントロールを挙げてこれらが運用に影響しないかをメンバーアカウント管理者に確認する必要があります。

導入の方針として、それぞれのアカウントで生産性を落とさないことを目指しました。よって、予防コントロールについて最初は必須コントロール以外は設定してません。

これらの必須コントロールはAWS Control Towerのリソースに対するものがほとんどです。なのでセキュリティを強化するためにコントロールでガイダンスが「強く推奨」とされるものと、Service-Managed Standard: Control Towerで重大度が重大のものを検出コントロールとして有効にしています。

Service-Managed Standard: Control Towerを設定することで各アカウントでSecurity Hubを有効にしつつ、コントロールの有効/無効をAWS Control Tower側でコントロールできます。

AWS Control Towerに登録する上での前提条件

他にもAWS Control Towerにメンバーアカウントを登録する上で以下の前提条件を満たす必要があり、対応を依頼する必要があります。

これらの予防コントロールとAWS Control Towerへの登録の前提条件を、メンバーアカウントの管理者に説明して確認が完了することで導入を進められます。

組織単位の設計

AWS Control Towerに登録された組織単位(OU)にメンバーアカウントを追加することで、AWS Control Towerにメンバーアカウントを登録することができます。組織単位においてもベストプラクティスが公開されているので、そちらを参考に組織単位を設計します。

カバーでは以下のように組織単位を作成しています。本番環境と開発環境でそれぞれ組織単位で別のコントロールを適用できるようにProd OU、SDLC OUに分けています。

Root
└── Workloads
　　   ├── Prod
　　   │   └── ServiceAProd
　　   └── SDLC
　　       └── ServiceADev

通知

AWS Control Towerで適用されたコントロールについて非準拠リソースの通知を行い、素早く改善を行う必要があります。こちらの実装は下記の記事で説明いたしました。

他にもGuardDutyの管理をAWS Control Towerが作成する監査アカウントに委譲し、全てのメンバーアカウントでGuardDutyを有効にします。

その上でGuardDutyのアラートを通知する必要があります。そちらはChatbotを組み合わせてSlackに通知します。以下の記事を参考にさせていただきました。

ChatbotのIaCについてはterraform-provider-awsccで実装することができます。

resource "awscc_chatbot_slack_channel_configuration" "guardduty" {
  configuration_name = "guardduty-slack-channel-config"
  iam_role_arn       = aws_iam_role.chatbot_notification_only.arn
  slack_channel_id   = var.channel_id
  slack_workspace_id = var.workspace_id
}

AWS Control Towerの導入後

AWS Control Towerの導入後についてはコントロールに対する非準拠リソースをリストアップして、メンバーアカウントの管理者に通知し改善を促しています。
また、今後非準拠リソースが生まれないようにガイドラインの策定やcdk-nag, Trivyといったコードスキャナーの導入を進めています。

まとめ

カバー株式会社におけるAWS Control Towerの導入について書きました。これからAWS Control Towerを導入される皆さんの参考になれば幸いです。

次回は@sf-coverによる「OpenAPI 定義ファイルから自動生成された Flutter (Dart) の API クライアントの便利な機能群」です。こちらも是非ご覧ください。