エンタープライズ企業にAWS Control Towerを導入してみた
この記事はPioneer Advent Calendar 2022の9日目の記事です。
みなさん、AWS アカウントの管理はどうされていますか！？
アカウントが少ないうちは管理が容易だと思いますが、増えてくると管理が大変になっていないでしょうか。
今回は、AWS アカウント等の管理や運用の手間を軽減できるサービス、AWS Control Towerをパイオニアで導入した事例を紹介したいと思います！
自己紹介
2021年 10月入社のSaaS Technology Center SaaSテクノロジー統括グループ 技術推進室の平井です。
普段はバックエンドの開発やSRE業務を行っています。
過去には以下の記事も書いているので、ご興味があれば読んで頂ければと思います！
AWS Control Towerとは?
AWS Control Tower (以下略称:Control Tower)は、AWSの公式ページ上では、「安全なマルチアカウント AWS 環境のセットアップと管理」 と記載されています。
もう少し機能を補足すると、
マルチアカウント環境の初期構成を提供
セキュリティ統制(ログ・監査)のためのアカウント分離
AWSが管理する「SCPとAWS Config」を用いた予防/発見的ガードレールのOU適用
アカウントのベースライン構成を提供
CloudTrail証跡、AWSConfig検知データの収集(ログ・監査アカウントへの連携設定)
新規アカウントのVPC構成
アカウントの払い出し機能を提供
AWS Service Catalogを用いたアカウントの作成
ガードレールとベースライン構成に基づく初期設定を実行(CloudFormation StackSets)
要は、AWS のマルチアカウントを運用する環境において、セキュリティや監査、運用の手間などを減らすことができるサービスです。
※ 利用は、AWS OrganizationsやAWS IAM アイデンティティセンター(旧AWS Single Sign-On)などとの連携を前提としています。
導入の背景
新規のプロジェクトが始まるたびに、AWSアカウントを準備する必要があり、以下の点を課題として感じていました。
AWSアカウントの管理方法が統一されていない
アカウント毎にセキュリティ基準などが統一されていない
新規プロダクト開発において、複数のAWSアカウントが必要になることが想定された
これらの課題を AWSJとの定例会で相談したところ、Control Tower を紹介され、導入することにしました。
導入編 Step 1
導入については以下のようなStepで進めました。
基本運用期間:2021/11〜2022/05
適用拡大/ブラッシュアップ期間:2022/06〜2022/09
基本運用期間では、大きく以下のような内容の検討や作業を行い、一部のアカウントで運用を開始しました。
AWSアカウント分割の方針検討
基本ルール検討
ログイン方法検討
既存AWSアカウントをControl Tower配下に入れてみる
AWSアカウント分割の方針検討
厳密にはControl Tower導入とは異なるのですが、AWSアカウントをどのような形で分割するかを検討しました。
原則は、プロダクト毎に開発や検証、本番を分けて作成する大方針を決めました。
＜理由＞
今後開発するプロダクトの正確な数が分からないため、プロダクト間や環境毎の依存関係が少ない方法を選択することにしました。アカウントの数が増えると運用の手間が増えるのですが、自動化をする(一例としてのコスト計算を後述に記載)等をして、手間を減らすことにしました。
基本のルール検討
以下のルールをSREメンバーを中心に決めていきました。
IAM運用ルール
ガードレール設定
CloudTrail運用ルール
AWS Config運用ルール
複数アカウントログイン方法の検討
AWSには、複数アカウントにログインする際の代表的な方法として、
スイッチロールを利用してログインする
AWS IAM アイデンティティセンターを利用してログインする
などがありますが、今回は2を選択しました。
<理由>
AWS IAM アイデンティティセンターには、Active Directoryや外部IDプロバイダーなどと連携する仕組みが標準として用意されているので、将来的に会社側が用意しているユーザー管理方法と連携することを視野に入れて選定しました。
既存AWSアカウントをControl Tower配下に入れてみる
試しに、元々持っていたサンドボックス環境をControl Tower配下に移行してみました。
そのおかげで、移行時に気を付ける点や作業ボリュームを事前にざっくりと把握することができました。皆さんも利用する際は、失敗しても大丈夫なAWSアカウントで試してみることをオススメします。
導入編 Step 2
適用拡大/ブラッシュアップ期間では、大きく以下のような内容の検討や作業を行い、運用の範囲を広げていきました。
OUの整理
ルールのブラッシュアップ
ユーザー作成やアクセス権限セットのルール作成
AWS Security Hubのルール作成
ISMS監査用のログダッシュボード作成
AWSアカウント作成時の初期設定の自動化
AWS支払いルールの整備
OUの整理
AWS Organizationsには、AWSアカウントを組織単位 (OU) でまとめられる機能があります。
AWSアカウント増加に備えて、構造を整理し運用しやすい方法を検討しました。
ルールのブラッシュアップ
ユーザー作成やアクセス権限セットのルール作成
AWSアカウントを利用するユーザーは、数百人規模に渡ります。数人の担当者で全てのユーザーのアカウントや権限を管理するのは不可能なので、権限移譲できる仕組みやルールを策定しました。
一部ではアクセス権限セットの使い回しができるようにCloudFormationの雛形を作成しました。
AWS Security Hubのルール作成
セキュリティを向上するために、AWS Security Hubを利用することにしました。しかし、検知するアラートを全て対応すると運用工数が上がってしまうため、対応優先度のルール決めをしました。
形骸化しないように定期的に運営側が確認するルールを設けました。
ISMS監査用のログダッシュボード作成
パイオニアではISMSを取得しており、運用ルールとして定期的に不正な操作がないか等を確認する必要があります。一元的に確認できるダッシュボードをOpenSearch(Kibana)で構築し、確認する際に利用できるようにしました。
AWSアカウント作成時の初期設定の自動化
AWSアカウント作成時の初期設定時に複数リソース(AWS Security Hubなど)の設定や作成を自動化する仕組みを構築しました。
AWS支払いルールの整備
AWS Organizationsにアカウントを集約すると、支払いが共通化されます。今までプロダクトによってバラバラだった支払いについて担当部門と相談・調整し、一元的に処理できるように社内フローを調整してもらいました。
また、上述したログダッシュボード等の共通費を各AWSアカウントで按分するルールも決めました。
ただ、そのルールをそのまま運用すると、支払い担当者の負荷が大きくなるため、共通費を含めた最終的なAWS費用を計算するバッチ(AWS Lambdaを利用)をメンバーに開発してもらい、支払担当者の運用の手間を減らしています。
最後に
全て紹介できなかったのですが、Control Tower導入時に行った主な作業は上述の通りです。
関係者が多く、メンバーや上長の協力が無ければここまではできなかったと思います。
私は、途中からインフラ構築をメンバーにお任せし、推進といろいろな調整に専念していた気がします。笑
特に費用の支払いについては、各事業の損益計算に関わってくるため細心の注意を払って調整しました。
まだまだ改善する点はありますが、今後AWSアカウントが増えても拡張できる土台はできたと思っています！
パイオニアでは一緒に働く仲間を募集しています。
Pioneer Advent Calendar 2022 の10日目は、添田裕雅さんの「キャリア採用社員が川越事業所見学に行ってきた！」です。
是非お楽しみに！