目次
はじめに
2023/03 AWSマルチアカウント管理の構成がAWS Well-Architected Frameworkのセキュリティの柱でも推奨されていることを追記
企業でAWSの活用が進むと、AWSアカウントが個別案件ごとに乱立したり、社内のクラウド利用の承認プロセスをバイパスして野良クラウドが利用されたり、といったセキュリティ統制や運用効率の問題が発生することがままあります。
そうしたクラウドガバナンスの問題に対して、AWSから提供されているのがAWSマルチアカウント管理の手法です。AWSを大規模に、効率良く、組織横断でセキュリティ統制を効かせながら活用するためには、どういったサービスを利用することができるのか本記事では前後編に分割してご紹介します。
AWSマルチアカウント管理のコンセプト
AWSを比較的早くから利用されている企業等でありがちな構成が、オンプレミス環境の延長で、同じAWSアカウント内で環境面ごとにVPCを大きく取って分割し、NWの境界を単位としてワークロードを区分しているケースです。
オーナーが異なるワークロードが同じAWSアカウントの中に混在するとどのような問題が発生するでしょうか。以下のような課題が挙げられます。
- 1つのAWSアカウント内で複数システムが稼働するため、利用者ごとにお互いのワークロードに干渉しないようIAMの権限管理が煩雑になる(あるいは、誤操作やオペミスのリスクを負いながら緩い権限管理で運用する)
- システムごとにAWSリソースのコストを按分するために、コスト配分タグを使用するが、タグ付けに対応していないリソース等、システムごとにきれいにコスト管理が出来ない
- 上記のような共通環境での制約を嫌って、システム独自で個別にAWSアカウントを持ってしまい、結果的に必要なセキュリティ統制から漏れてしまう
こうした問題点を解決してクラウドガバナンスを向上させる方法が、以下に挙げる構成です。
- 利用者用の環境は、1システム1環境1アカウントとして個別に管理する(権限・コスト分離)
- 利用者用アカウントとは別に、セキュリティ・ログ・NWといった共通機能を機能ごとに分割した管理用AWSアカウント群を作成する(運用効率化・重複機能の共通化)
- 利用者用AWSアカウントに対して、必要なセキュリティをガードレールのように展開するが、ガードレールに抵触しない範囲では最大限の自由と操作権限を利用者に渡す(セキュリティ統制と自由の両立)
AWSアカウントレベルでワークロードを分離することは、AWS Well-Architected Frameworkのセキュリティの柱でも強く推奨されているため、これからAWSを使い始める方はマルチアカウント管理の考え方を基に、AWS OrganizationsやAWS Control Towerを利用する前提で構成検討を行うと良いでしょう。
AWSマルチアカウント管理の構成を行うためにどういった検討要素があるのか、私が考える構成観点は以下の通りです。
- マルチアカウント管理の運用方針の策定
- セキュリティ管理の構成
- ログ管理の構成
- ID管理の構成
- NW管理の構成
前編では、マルチアカウント管理の運用方針の策定、セキュリティ管理の構成、ログ管理の構成についてご紹介します。
1. マルチアカウント管理の運用方針の策定
役責と責任分界点の整理
AWSマルチアカウント管理を行う上で、AWSを組織全体のプラットフォームとして運用するための運用者とそれを利用する利用者が発生することになりますが、事前にそれぞれがどの機能までの運用をカバーするかをまず決定します。
例えば、運用者は事前にプラットフォームの初期整備を行うことになりますが、その後の運用の中では、利用者の申請に応じてAWSアカウントの払い出し作業をするとか、各アカウントの中でセキュリティ違反が発生した時に監視と連絡を行うといった役割を負います。 利用者については、運用者が一部の運用作業を担当していることを理解しつつ、それ以外のシステムに必要なアプリケーション開発等の自由と責任を負う、といった定義を事前に行うことで、プラットフォームの円滑な運用を行うことが可能です。
マルチアカウント管理に必要な範囲の標準化
運用者が申請に応じてアカウントの払い出し作業を行うとき、アカウントの作成に合わせて標準的な構成でベースVPCを作成し必要なNWルーティングの設定も行った上で払い出す、ということをすると、全ての個別アカウントの構成を必要な要件を満たす形である程度統一することが出来ます。
その際にあらかじめ決めておくべきなのは、利用者がどのリージョンを使用可能とするのか、AZ構成は何を基本とするか、ログの保管期間はどの程度を基準とするか、タグは何を付与するか、等の全員が守るべき標準です。あらかじめあらゆる規約を作成するというのは難しいでしょうが、マルチアカウント管理を行う上で運用を円滑に行うための標準は最初に抑えておくべきでしょう。
運用ガイドラインの策定
プラットフォームの運用を行う上で、利用者と運用者へのガイドラインを策定しておくことも重要です。運用者向けには定型作業の定義としてアカウント払い出し作業、セキュリティ違反検知時の対応フロー、障害発生時の対応方針といった事項を文書化しておくべきですし、利用者向けには、プラットフォームが何を提供してくれるのか、プラットフォームをどのように利用すべきなのかが分かるようなガイダンスを行うことで、プラットフォームの正しい形での活用を促進することが出来ます。
2. セキュリティ管理の構成
ガードレールの構成
AWSマルチアカウント管理の肝となるのが、AWSが提供しているAWS OrganizationsとAWS Control Towerの機能になります。両者の機能説明は世の中で広くされていますので、ここでは割愛しますが、Control Towerが標準で提供する予防的/検出的ガードレールを使用することで、プラットフォームのセキュリティを一定程度担保できます。
このガードレールはいわゆる境界型セキュリティの考えを元に作成されたものが多く、例えばS3バケットのパブリック公開を禁止するであるとか、RDS/Redshiftがパブリックサブネットに配置されたらアラートを発するという考え方になります。S3バケットの暗号化設定を変更させない、ルートユーザーの操作を禁止するといったセキュリティポリシーとして利用者に守らせたい規則を敷くこともできます。
Security Hub/GuardDuty/Inspector等のセキュリティ機能
Security Hub/GuardDuty/Inspector等のAWSの有用なセキュリティ系サービスについて、AWS Organizationsの機能でサービス統合を行うとマルチアカウントの管理を効率的に行うことが可能です。
サービス統合を行うと、各アカウントの情報が管理アカウントのコンソールに集約されるため、運用者は今どのアカウントがどのような状況になっているかを俯瞰して確認することができます。セキュリティ違反が発生した時は、すぐにコンソールで該当アカウントの状況を確認できるでしょう。
最小権限の原則に従って、セキュリティ系サービスについては管理者の委任設定を行うことでAuditアカウントに委譲し、強い権限が集中している管理アカウントではなく、Auditアカウント側で運用作業を行えるようにすることが推奨されます。
AWS Service Catalogの作成
AWS Service Catalogとは、CloudFormationテンプレートをラップしたような機能になり、今回のケースでの活用例としては、運用者があらかじめ必要なセキュリティ設定やセキュリティエージェントを導入したEC2を作成するテンプレートを用意し、それをService Catalogでポートフォリオ化して利用者のアカウントに共有することが出来ます。利用者にてそれを使用してEC2のデプロイを実施してもらえば、必要なセキュリティ設定が行われたEC2を負荷なくデプロイすることができ、セキュリティ管理から漏れたEC2の発生を抑制できます。
3. ログ管理の構成
監査ログの収集
Control Towerを有効化すると、利用者用の各AWSアカウントからCloudTrailログとConfigログをLog ArchiveアカウントのS3バケットに集約して保存するよう設定が行われます。 監査ログやセキュリティ系のログが中央集約されれば、運用者が監査対応しやすくなりますので運用上望ましいことと思います。
アプリケーションログの集約
Control Towerが収集設定をしてくれるのは監査ログのみですが、その他のログ、例えばVPCフローログやGuardDuty等のセキュリティサービスのログも手動で収集するよう設定を追加することも検討できます。また、利用者アカウントのCloudFront、ELB、WAFといったインターネットと接しているサービスのログ集約も有用でしょう。SIEM製品をLog Archiveアカウントに展開すればそうして収集したログ監視が出来ますし、Log Archiveアカウントにログ分析基盤を展開すれば、更にあらゆるアプリケーションログを収集して、ログの横串分析を行い、ビジネスに寄与する洞察を得るといった展開も考えられます。
AWS JapanからSIEM on Amazon Opensearch Serviceというサービスが提供されていますが、あらかじめ代表的なAWSサービスログの取り込みに対応しており、サードパーティのSIEM製品やログ分析サービスを検討するまでの議論にならない場合は、AWSネイティブの機能で完結するため、Log Archiveアカウントにログ分析基盤を作るための有力な候補となります。
留意事項
ここまで、AWS OrganizationsとAWS Control Towerの機能を活用してマルチアカウント管理を構成する方法を記載しましたが、実際にシステムに導入を行う際、留意すべき事項が2点あります。
AWS再販環境の制約
世の中では多くのAWSパートナーがAWS再販ベンダーとしてAWS資源の提供を行っていますが、AWS再販には、エンドカスタマーアカウントモデル(ECAM)とソリューションプロバイダーアカウントモデル(SPAM)の二通りが存在します。
SPAMの場合、再販ベンダーが全てのAWSアカウントのrootユーザーを所有することになり、ECAMでは顧客がアカウントのrootユーザーの所有権を持ちます。一般的には、SPAMの方が再販ベンダーが他のアカウントと合算してボリュームディスカウントを効かせることが出来るので、値引き率は高めになりますが、管理アカウントを再販ベンダーが全顧客共通で管理しているため、顧客専用のAWS Organizationsを組めません。一方で、ECAM方式であれば、アカウントの所有権は顧客にありますので、顧客がAWS Organizationsを組むことが可能です。ただし、ボリュームディスカウントが効かない分、値引き率が下がることがあります。
どちらも一長一短になりますが、中間のような再販の形態もあり、再販の仕方はSPAM方式だが、特定の顧客専用のAWS Organizationsを作成することで、再販ベンダーが顧客にAWS組織を間貸しするような形でAWS OrganizationsやAWS Control Towerの機能を使用させることもあります。
いずれのケースにしても、AWSマルチアカウント管理を行うにはAWS OrganizationsやControl Towerの機能が不可欠ですので、再販を利用する場合は自組織専用のAWS Organizationsを組めて、かつControl Towerも利用できる再販ベンダーを選定すべきです。
AWS ソリューションプロバイダー向け AWS Control Tower のベストプラクティス | AWS JAPAN APN ブログ
Control Towerの必要有無
私自身もそうだったのですが、Control Towerが一見複雑そうに見えて、マルチアカウント管理を行う上で本当に導入した方が良いのか疑問を持つ方がいます。私の結論としては、Control TowerはAWS Organizationsの機能を便利に利用するために各サービス機能をラップしたようなサービスになり、AWSも開発を推進しているため、使用するべきと思います。
本記事で触れたAuditアカウントやLog Archiveアカウントも、Control Tower有効化時に自動で作成されますし、ガードレールもControl Towerを利用しないで作りこむのは手間がかかります。また、再販環境だと出来ないことが大半ですが、アカウントファクトリー機能を使用すると自分で新規AWSアカウントの作成を簡単に行うことができるのも利点です。
まとめ
本記事では、AWSを大規模に活用する際に、AWSマルチアカウント管理を行うことがなぜ推奨されるのか概要を説明し、マルチアカウント管理を構成するために必要なマルチアカウント管理の運用方針の策定、セキュリティ管理の構成、ログ管理の構成について説明しました。後編では、ID管理の構成とNW管理の構成について説明をします。
