はじめに
先日、ひょんなことから「AWSのマルチアカウント環境をいい感じに構築する」という案件対応をする機会がありました。これにあたりマルチアカウントの考え方を色々調査＆検討したので、備忘録がてら記載しておきたいと思います。
マルチアカウントについて
その昔まだマルチアカウントという考え方が浸透していなかった頃は、どんな用途でも１つのアカウントで対応するのが一般的だったと思います。例えば開発／検証／本番の各ワークロードを作りたい場合、１つのアカウント内に各環境用のVPCやセグメントを作成して管理していたりしました。
こういった方法でもやりたいことを実現できると言えばできるのですが、全てを１アカウントに集約していることによる弊害はあり、例えば開発者が誤って本番環境へ設定変更を行ってしまい障害につながってしまうなど色々不都合もありました。
これに対し、今ではマルチアカウントという考え方が一般的になっていると思います。マルチアカウントは用途によりAWSアカウント自体を分割してしまおうという考え方で、例えば先程の例でいくと、開発用／検証用／本番用に個別にアカウントを作成することになります。AWSアカウントがワークロード毎に異なるので、開発者が本番環境を触ってしまうという危険性を大幅に減らすことができ、またコスト管理がしやすい（アカウント単位の課金）、システム構成をシンプルに保てるなどのメリットもあります。
とはいえマルチアカウントも万能ではなく、アカウントが多くなるぶん管理が煩雑になり、考えなしにアカウントを発行していくと収集がつかなくなってしまう恐れもあります。このため運用担当者の頭を悩ませることも多いかと思いますが、AWSは日々進化しており、現在ではこういったデメリットを軽減するための考え方やサービスが提供されています。今のところでは具体的には以下の３つとなります。
- Landing Zone
- Landing Zone（実装）
- Control Towe
それぞれざっくりと解説していきます。
Landing Zone
Landing ZoneはAWSでのマルチアカウント管理におけるベストプラクティスを整理したものです。Landing Zone自体はあくまで考え方なので、利用する際にはこの仕組みを理解し、自らAWSの各種サービスを使用して実装する必要があります。
またLanding Zoneにはガードレールという考え方があります。道路の脇にあるガードレールと同じで、はみ出してはいけない範囲を決めてその中では何をしてもOKというもので、OrganizationsのSCPやAWS Configルールなどで実現します。ガードレールの一例ですが、たとえば特定のAWSアカウントに対してインターネットへのアクセスを禁止＆それ以外は好きに使わせる、といったことが可能です。
Landing Zoneの考え方については以下のブログに詳しく書かれていますので、興味のある方はご覧ください。これからマルチアカウントを実装しようとしている人にはもの凄く役に立つ情報が満載です。
ちなみにマルチアカウントの考え方についてもこちらに詳細に書かれてます。（上の記事は第二回、こちらは第一回なので、こっちから先に見た方が分かりやすいかもしれません）
Landing Zone（実装）
先ほどLanding Zoneは考え方だと書きましたが、この概念をAWSが具体化して一般公開したものをLanding Zone（実装）と言うそうです。名前が同じような感じなので何だか分かり辛いですね。。
私も使用したことはないですがNode.jsやCloudFormationで実装されているようで、このスクリプトを各自のAWSアカウント上で実行することでLanding Zoneに則ったマルチアカウント環境を構築することができるとのことです。こちらは現在長期サポート中の扱いで機能追加はストップされているようなので、これからマルチアカウントを構築したいと考えている人は使わない方がよさそうです。もし興味のある方は以下AWSのページを参照ください。
AWS Control Tower
上記Landing Zone（実装）の後継？となるサービスです。どこかでそういう記述を見たわけではないですが、そんな考え方でたぶん合ってると思います。こちらはNode.jsスクリプトではなく純粋なAWSサービスとして提供されており、当然のごとくLanding Zoneに準拠しています。
対象のAWSアカウントで有効化するだけでOKなので今後のマルチアカウント管理のド本命と思いますが、残念ながらまだ東京リージョンに対応しておりません。また現時点では色々制約も多いようなので、東京リージョン対応と今後の機能拡張が待たれるところです。
こちらもAWSのサービスページを張り付けておきますので、興味のある方はご覧ください。
（2021/4/28追記）
Control Towerが東京リージョンに対応しました！！詳細はこちらのAWSブログを参照ください。
今回の案件ではどのように対応したか？
Control Towerというサービスに興味はあるものの、やはり東京リージョンに対応していないのは大きなネックでした。またControl Towerは内部的にCloudFormationやAWS SSOなど各種サービスを活用しているようで、全ての構成要素をちゃんと理解して使わないとブラックボックス化してしまい運用に入ってから困る、なんてことにならないかなあという心配もありました。
なので今回はLanding Zoneの考え方をベースとして、今回案件用に色々と取捨選択した上で自分でサービスを組み上げることにしました。
全体構成
今回の構成図はこのような感じです。Landing Zoneの考え方を取り入れながらも、できる限り複雑にしすぎずシンプルにすることを意識しました。
基本的な考え方は以下の通りです。
- AWS Organizations を使用してマルチアカウント環境を作成する
- AWS Config Rule と SCP（サービスコントロールポリシー）によりガードレールを実装する
- CloudTrail、AWS Config、GuardDutyにより組織内のアカウントの監査を可能とする
- セキュリティ用のアカウントを用意し、AWS CloudTrail や AWS Config のログはここで集中管理する
- ネットワーク用のアカウントを用意し、Transit Gateway等の共有サービスはここで集中管理する
- AWS SSOを使用し、コンソールへのログインなど認証を集中管理する（シングルサインオン）
利用したサービス
今回利用したサービスとその概要を以下に列記します。
AWS Organization
AWSでマルチアカウントを実現する際に必須となるサービスです。
親となるアカウントを管理アカウントとし、その配下にメンバーアカウントがぶら下がるようなイメージでマルチアカウント環境を構成できます。管理アカウントは絶大な権力を持ち、メンバーの追加／変更／削除だけでなく、SCP（サービスコントロールポリシー）を使用してメンバーアカウントに対して制限を掛けたりできます。いわゆるガードレールです。
また管理アカウント上に組織単位（OU）を作成することができ、作った組織の中にメンバーアカウントを入れて管理し、さらに組織に対してSCPを割り当てたりできます。
例えば、営業部・人事部など部署毎にOUを切ってメンバーアカウントを格納し、SCPにより各部単位に制限をかけたりできます。
AWS Config
AWSサービスの構成情報を記録できます。サービスに対する変更来歴を長期間保存し、いつどのような変更が行われたかを遡って確認することができます。例えば、誤ってS3がパブリック公開された際に、後からバケットポリシーの変更来歴を追いかけたりできます。
このサービスは全リージョン全アカウントで有効化することが推奨されているようです。
Cloud Trail
AWSに対するAPIコールのログを記録することができます。AWS Configと異なり、こちらのサービスではIAMなどのユーザによる操作を可視化することができます。
AWS Organizationsを使えば、管理アカウントから配下のメンバーアカウント全てに対し、一括で有効化することが可能です。
Guard Duty
機械学習を活用してAWS内に蓄積された各種ログ（Cloud Trail、AWS Config、VPCフローログ等）を分析し、検出された脅威に対してアラートを上げることができます。
費用もそれほど高くはなく、非常に強力なサービスなのでできる限り有効化した方がよいです。こちらも全リージョン全アカウントでの有効化が推奨されています。
AWS Config Rule（適合パック）
AWS Configの派生サービスです。サービスに対して加えられた変更を自動的に検知し、予め定めておいたルールに違反した場合にアラートを上げたり、自動で修復（変更内容を取り消し）したりできます。
AWS Config Rule単体ではルール違反の検知しかできないため、以前は自動修復を実現するために色々なサービスと組み合わせる必要がありましたが、適合パックの登場によりAWS Configの１サービスだけで対応ができるようになりました。
今回の実装で工夫した点
今回の実装にあたり、色々調べて工夫した点を以下に記載したいと思います。
セキュリティアカウントによる監査情報の集約
セキュリティ情報を管理する専用のアカウントを用意し、AWS Config、Cloud Trailなど監査系のログを全てここに集約するようにしました。
またAWS ConfigとGuard Dutyには権限の委任機能が用意されており、本来であれば管理アカウントでしか使えないこれらのサービスを、委任先のアカウントでも使用することができます。今回はセキュリティアカウントに対して委任を行い、管理カウントにログインしなくても監査情報を参照できるようにしました。
ちなみにLanding Zone的にはログ収集と監査でそれぞれアカウントを分けるという考え方のようですが、今回は構成をできる限りシンプルにするため、１アカウントに収集と監査の役割を持たせるようにしました。（将来的に見直す可能性はありますが。。）
組織単位（OU）の切り方
上記で少し触れたOUですが、まじめに実装しようとすると相当奥深いです。部署ごとに階層を切る例を挙げたりもしましたが、実際の現場で安易に対応すると後の運用が大変になったりします。例えば毎年部署の統廃合がある会社の場合、その度にOUの構成を見直すというのも現実的ではありません。
今回も切り方については大いに悩みましたが、幸いなことにAWSの技術ブログに参考になる話が載っていたのでエッセンスを使わせて頂くことにしました。
具体的には、以下のようにOUを切りました。
- セキュリティOU：ログの集約や監査など、セキュリティに関連するアカウントを格納。
- インフラOU：ネットワークやADなど、共用インフラを管理するアカウントを格納。今回案件ではTransit Gateway用のアカウントを本OUに配置。
- ポリシー検証OU：新しいSPCのポリシーを作ったときなどに、本番適用前にここで事前検証してからリリース。
- 破棄アカウントOU：削除対象のアカウントを一時的に格納。SCPにより、本OU内に格納されたアカウントの全権限を機能を無効化する。一定期間保管して問題が出なければ実際に削除する、といった使い方。
- 業務OU：日々の業務運用で使うアカウントを格納。ここにたくさんのアカウントが入る。
参考にした技術ブログはこちらです。興味のある方はどうぞ。
##ガードレールの設計
上で少し触れたガードレールですが、大きく分けて発見的統制と予防的統制の２種類があります。
- 発見的統制：やってはいけないことのルールを定義し、これに違反した場合、アラートを上げたり変更内容を自動修復したりします。操作自体に制限を加えることはないので、各アカウントではルール違反の操作を実行すること自体は可能です。起きてしまった後にどう対応するか？といった考え方となります。AWS Config Rule（と適合パック）で実現します。
- 予防的統制：ルール違反の操作自体を禁止します。操作ができないのでより厳しいガードレールとなります。OranizationsのSCPで実現します。
では具体的にどんなガードレールを作ったのか、というところですが、その設計はLanding Zoneのべスプラに準拠しました。というよりも、Landing Zoneの実装であるControl Towerのガードレール定義が公開されているので、今回はここから必要なものをピックアップし、若干手直しして実装しました。現在公開されているControl Towerのガードレールは以下となります。
- 必須のガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/mandatory-guardrails.html
- 強く推奨されるガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/strongly-recommended-guardrails.html
- 選択的ガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/elective-guardrails.html
最後に
前置きだけで長くなってしまったので、具体的な実装方法については記事を分けたいと思います。リンクを貼っておきますので興味のある方は見てもらえると嬉しいです。
今回の記事が誰かのお役に立てると幸いです。