こんにちは!エンタープライズクラウド部ソリューションアーキテクト1課の足達です。
本ブログは、Baseline Environment on AWS(以下、BLEA)の内容を基に、「マルチアカウントとはそもそも何か?」「どのように構成されているのか?」についてまとめたものになります。
はじめに
クラウド環境が広がる中で、さまざまなプロジェクトやチームにおいてAWSが活用されてきています。
しかし、複数のプロジェクトを一つのアカウントに統合すると、セキュリティリスクが増加したり、管理が複雑化することがあります。
そこで登場するのが「マルチアカウント戦略」です。
この戦略を活用することで、各プロジェクトごとにアカウントを分けて管理し、セキュリティの強化や運用効率の向上を図ることができます。
マルチアカウントとは
マルチアカウントとは、言葉の通り、複数のアカウントを使い分けながらAWS環境を利用することです。
しかし、ただ闇雲にアカウントを増やすだけでは、かえって管理や運用が煩雑になってしまいます。
例えば、以下のような問題が生じてきます。
- アカウント間の設定の整合性が維持できない
- 共通のセキュリティ設定等を各アカウントごとに行う必要があり、作業が煩雑になる
- 継続的にコンプライアンスを遵守しているか各アカウントを巡回して管理しなければいけない
そこで重要となってくるのが、適切なアカウントの構成と管理です。
これらを実現するために、AWSでは、複数アカウントの一元管理が可能となる「AWS Organizations」やベストプラクティスに従ったマルチアカウント環境を簡単にセットアップおよび管理が可能となる「AWS Control Tower」といったサービスが提供されています。
上記についてざっくりと説明すると、まずAWSユーザーは、1つの大元のアカウント上で、先に述べた「AWS Organizations」や「AWS Control Tower」の設定を行います。すると、これらを設定したアカウントを親アカウント(管理アカウント)として、階層構造のように子アカウント(メンバーアカウント)を作成できるようになります。
子アカウントでは、親アカウントへ施したセキュリティ設定や権限設定などがそのまま引き継がれますので、全てのアカウントに共通して付与したい設定を親アカウント上に行うことで、セキュリティ設定等が既に完了されたアカウントを簡単に作成することができます。
厳密には、組織単位(Organization Unit:OU)と呼ばれるアカウントの論理的なグループを作成し、その配下に各アカウントを作成するなど、表現が違ったり、もっと多くの機能があったりするのですが、一旦は「アカウントが階層構造で統制されるんだな」という部分のイメージを付けてもらえればOKです。
マルチアカウント構成の利点
適切にマルチアカウントを構成できると、以下のような利点があります。
- セキュリティの強化:各アカウントごとにセキュリティポリシーを設定することで、不要なアクセスを制限できます。
- コスト管理の効率化:アカウントごとにコストを分けて管理することで、どの部署がどれだけコストを使っているのか一目瞭然となります。
- 環境の分離:開発環境と本番環境を別々のアカウントで運用することで、リスクを減らし、トラブル発生時の影響を最小限に抑えます。
- ガバナンスの強化:アカウントごとに役割と権限を明確にすることで、組織全体のクラウドガバナンスを強化できます。
これらを念頭において、以下では「どのような構成が適切なマルチアカウント構成となるのか」についてみていきたいと思います。
BLEAとは
AWSが提供する「Baseline Environment for AWS(BLEA)」は、AWSにおけるセキュリティのベストプラクティスを実装した環境を、シングルアカウントもしくはマルチアカウントで迅速に実現するためのテンプレート群です。
また、これらのテンプレート群は、以下リング先のGitで公開されているため、誰でも利用することが可能です。
これにより、基本的なセキュリティが実現された状態でシステム構築の開始が可能となります。
つまりマルチアカウント版BLEAで実装されている構成は、AWSにおけるセキュリティの基本が踏襲されているお手本のような構成になっていると言えます。
ようやく本ブログの本題となりますが、次で、マルチアカウント版BLEAの中身がどのような構成になっているのかをみていきたいと思います。
BLEA for Multi-Accountに構成されている5つの役割について
BLEA for Multi-Accountでは、Organizations配下にあるアカウントを以下の5つの役割に分類しています。
- 管理アカウント
- ログアーカイブアカウント
- 監査アカウント
- 共有サービスアカウント
- ゲストアカウント
では、それぞれについて簡単に説明していきたいと思います。
1. 管理アカウント
組織全体の管理を担当するアカウントです。
主な役割には、組織の作成・管理、アカウントの作成・招待・削除、サービスコントロールポリシー(SCP)と呼ばれる組織単位ごとのアクセス許可を管理するポリシーの適用、組織全体の請求の一元管理などが挙げられます。
このアカウントでは、最小限のAWSサービスのみを使用し、本番環境のワークロード等は実行しません。
2. ログアーカイブアカウント
組織全体のログを一元管理するためのアカウントです。
AWS CloudTrailやAWS Config、VPCフローログなどの各種ログを組織全体のアカウントから集約し、長期保存および分析を行う役割を担っています。
1つのアカウントで全アカウントのログを集中管理することにより、セキュリティ監査やコンプライアンス確認、トラブルシューティングなどが容易になります。
3. 監査アカウント
組織全体のコンプライアンスと監査を担当するアカウントです。
主な役割として、AWS Security HubやAmazon GuardDutyを用いた、セキュリティベストプラクティスの適用状況の監視、侵入検知などが挙げられます。
また、AWS IAM Access Analyzerを使用して組織全体のリソース共有とアクセス権限を分析し、意図しない公開設定がされていないかどうかの検知なども行います。
4. 共有サービスアカウント
組織全体で共通して使用されるサービスやリソースを管理するアカウントです。
例えば、Active DirectoryサービスやDNSサービス、共有VPC、トランジットゲートウェイといったネットワークインフラなどをこのアカウント上でまとめて管理します。そして、他のアカウントでは、この共有サービスアカウント上のリソースを利用するように設定します。
このようにすることで、リソースの重複を避け、一貫性のある設定と管理を実現することができます。
また、コスト最適化や運用効率の向上にも繋がってきます。
5. ゲストアカウント
実際のビジネスワークロードを実行するアカウントです。
組織内の各部門や事業単位ごとに必要な分だけアカウントを分けて作成するのが一般的です。
このアカウント上で、アプリケーションやデータベース、ストレージなど、具体的なビジネス機能を実現するためのAWSリソースを構築します。
まとめ
いかがだったでしょうか?
会社のような組織も、経理を担当する部署や監査組織、情報セキュリティ部門など、役割ごとに担当を分けているかと思います。AWSのマルチアカウント構成もそういった考え方に近しいものと理解すると、よりイメージしやすいかもしれません。
マルチアカウントを構成する際は、上記の説明に挙げた1~4のアカウントのように、全てのアカウントで共通して使用される各種設定を役割分担させて管理することが重要となってきます。
そして、この基盤の上に「ゲストアカウント」として実際のワークロードで使用するアカウントを作成していくことで、より統制のとれたマルチアカウント構成とすることが可能になります。
ちなみに、余談にはなりますが、Control Tower上で役割ごとにOUを作成する際の一般的なユースケースには以下のようなものもあり、実際には上記5つの役割以外の分類が作成されるケースもあります。
今回ご紹介したBLEAはあくまで「ベースライン」ですので、実際には、要件に合わせて各種細かい設計を行う必要がありますが、本ブログを通して、マルチアカウントを導入するイメージが少しでも明瞭になっていただければ幸いです。
最後まで読んでくださり、ありがとうございました!