こんにちは、本記事は上野によるJapan APN Ambassador Advent Calendar 2021の21日目の記事となります。
AWSアカウント、複数使用していますか？
みなさん、用途ごとにAWSアカウントは分けていますでしょうか。最近は一般的になってきたマルチアカウント構成ですが、そもそもなぜアカウントを分けるのでしょうか。特に初心者の方は、なぜアカウントを分けるのか最初はわからないことも多いと思います。本記事でアカウントを分ける理由について深掘りしながら、アカウントをどう分けたら良いか考えていきたいと思います。
シングルアカウントの課題
次の例を見てみましょう。複数のEC2が1つのアカウント上で稼働しています。どういった課題が発生するのか考えてみます。
誤操作によるリソース停止、削除
開発環境のサーバは24時間起動する必要はない、コストを抑えるために停止したいとします。本番サーバと隣り合って表示されているため、誤って停止する可能性が高くなります。開発環境と本番環境ではライフサイクル（停止や変更の頻度）が違うというのがポイントです。
操作する人を分けるのが難しい
本番環境には個人情報が保存されて、特定の管理者のみアクセスする要件があったとします。
1アカウント内でこれを実現する場合、各リソースにタグを付与してタグベースでアクセスをコントロールするというやり方があります。ただ、きちんとタグのルールを決めておかないと正しくできなかったり複雑化することになります。
コストの管理が難しい
開発環境は定期的に停止してコストを抑える。抑えた開発環境のコスト状況はどうなのか見たくなります。AWS利用料の請求はアカウントごとに分かれるため、1アカウントでは環境ごとのコストを把握するのが難しくなります。
1アカウントの場合も、コスト配分タグを使用して環境ごとのコスト管理も可能ですが、複雑化することも多く、ネットワーク等明確にコストを分けられない部分もあります。
アカウントごとに上限（クォータ）がある
ＡＷＳアカウントはアカウントごとに上限を持っています。たとえばVPCは初期状態で5個しか作成できません。申請をすることで個数は増やせます。EC2のインスタンス数もタイプごとに上限が設定されています。開発環境で検証用に多くのインスタンスを起動し、本番環境のオートスケールでインスタンスが増やせなかった。という事態も起こります。
目的の違うリソースの数が、お互いの目的に影響しあってリソースの作成ができなくなってしまいます。また、事前にどこまで上限を設定しておくかという観点でも、複数目的がある場合は決定、管理が難しくなります。
アカウントを分ける
課題がわかると、アカウントを分ける必要性も理解できるかと思います。ライフサイクル、操作する人・権限、コスト管理、クォータの観点で分けて行くことになります。いくつか分け方の例を紹介していきます。
本番環境とそれ以外のアカウント
これが一番わかりやすいかと思います。本番環境とそれ以外の環境では、操作頻度、重要度、権限、コスト管理、クォータ、すべての観点が異なるため、分けたほうが良いのはわかるかと思います。
重要情報を扱うアカウントを分けても良いでしょう。たとえばクレジットカード業界のセキュリティ基準であるPCI-DSSの基準では以下の記載があります。
カード会員名、サービスコード、および有効期限が PAN とともに保存、処理、または送信される場合、またはカード会員データ環境（CDE）に存在する場合、それらは適用される PCI DSS 要件に従って保護される必要があります。
カード情報を取り扱う範囲が適用範囲となるため、もしカード情報を扱うアカウントを独立できた場合、適用対象もそのアカウントのみとなります。監査の対象を明確、最小化するために分けるというやり方です。
ログアーカイブアカウント
ログを1ヵ所にまとめるアカウントです。ログの特徴としてあるのが、見ることは多いけど変更することはないという点です。古いものを引き落とす等の処理はありますが、ログファイルそのものを変更はしないので、変更できないようにしたほうが良いでしょう。また、削除処理も通常はライフサイクルポリシー等を使用して自動削除することが多いです。
つまり、1ヵ所に集めておいて更新作業を実施させない（完全性の確保）、読み取り専用とする目的でアカウントを分けることになります。
AWSではシステムのログだけではなく、AWS CloudTrailやAWS Configなどの操作ログや設定履歴のログが残ります。それらのログは1ヵ所に集めて閲覧専用としたほうが良いでしょう。またVPC等のネットワークリソースを作成すると VPC Flow Logsも作成されます。こういったネットワークやアプリケーションのログも、完全性や保存期間の要件がある場合は、1ヵ所に集めて削除できないよう管理したほうが良いでしょう。
監査アカウント
AWSには多くのセキュリティサービスがあり、構築するシステムに関係なく確認すべきサービスも複数あります。社内でセキュリティ担当者がいる場合や、監査を行う担当がいれば、それらの人が見るべき情報を確認できるアカウントを用意したほうが良いでしょう。
後ほど紹介しますが、Organizationsを使用して複数アカウントのセキュリティ情報を集める機能も存在します。
Sandboxアカウント
Sandbox＝砂場という直訳になりますが、ここでいうSandboxは、新サービスやハンズオンなどで自由に検証する環境を指します。最近はAWSも多くのハンズオンコンテンツを用意していますが、アカウントの用意が課題となることも多いです。会社側でSandboxアカウントを用意して、それを渡す機会も増えてきており、ここではそのアカウントを指しています。
私としては、個人ごとにAWSアカウントを用意することを推します。というのも、利用料があがったり、公開されたセキュリティグループが作成される等、リスクのある設定は個人の操作や検証が理由になることが多いからです。もちろんプロジェクトとして共用の検証アカウントを用意するのも目的によってはあると思います。
マルチアカウントの課題と解決するサービス
さて、アカウントを分けてリソース、コスト、権限の管理がしやすくなりました。分けて解決される課題も多いのですが、分けることで発生する課題もあります。たとえば、以下のような管理は一ヵ所で実施したほうが安全かつ効率的です。
- 請求情報（登録するクレジットカード情報）の管理
- アカウントの素早い作成
- ユーザーID/パスワードの管理
- AWSアカウントのセキュリティサービス一括設定（全アカウントを対象）
- CloudTrail、Config、GuardDuty、Security Hub、IAM Access Analyzerなど
- 監査ログの一元管理 （先ほどのログアーカイブアカウントで実現）
これらマルチアカウントで一元管理すべき設定は、どのように実施すれば良いでしょうか。便利なサービスを紹介していきます。
AWS Organizations
Organizationsは、複数アカウントを使用する場合はほぼ必須のサービスと言って良いでしょう。
Organizationsを使用することで、請求情報を1ヵ所で管理できるようになります。クレジットカード情報を登録するのはManagementアカウント1ヵ所のみでOKです。請求情報は1ヵ所で登録しつつも、料金の明細はAWSアカウントごとに確認できるようになっています。
AWSアカウントの作成も、Organizationsから実施することで素早くできます。メールアドレスとアカウント名のみあれば、すぐに発行可能です。クレジットカード情報は不要です。
OU（Organizational Unit）という機能でアカウントのグループ管理ができ、グループまたはアカウントに対してSCP（Service Control Policy）を設定できます。SCPを設定することで、対象アカウント全体で不可能な操作を指定でき、予防ガードレールとして設定できます。たとえば、rootアカウントのアクセスキー作成禁止や、CloudTrail証跡の削除をできないように設定できます。
Organizationsは他のサービスと連携し、サービスの一括設定や情報集約を行うこともできます。以下はConfigの例です。
他にも連携できるサービスは多くあり、年々増えてきています。マルチアカウント運用を考える場合、まずOrganizationsをどう活用するかを最初に考えても良いくらい、重要なサービスです。
AWS Single Sign-On（SSO）
AWS SSOを使用すると、AWSアカウントへログインするために必要なID、パスワードを1ヵ所で管理できます。Azure AD等外部のIDプロバイダーも利用可能です。
AWS SSOが使用できない場合は、各アカウントごとにIAMユーザーを作成するか、IAMユーザーを1アカウントに作成し、各アカウントにスイッチロールするという運用方法があります。できる限り、IDとパスワードの管理は1ヵ所で行ったほうが安全ですし、利用者の管理負荷も低くなります。
CloudFormation StackSets
CloudFormationは、AWSのリソースをテンプレートでデプロイできるサービスですが、CloudFormation StackSetsを使用するとCloudFormationテンプレートで作成するリソース（スタックと呼びます）を、複数アカウントに同時展開できます。 また、複数リージョンに対してスタックを配置することも可能です。IAM Access Analyzerを全アカウントで作成したい、共通のネットワーク接続設定を作成したいなどの用途があった場合、自動設定できます。
OUやOrganizationsにも対応しており、指定したOUにアカウントが追加されたらスタックを自動作成、OUから外れたら自動削除という便利な機能もついています。
AWS Control Tower
AWS Control Towerは新規のサービスというよりも、これまで紹介したサービスや機能を、AWS管理で自動設定してくれるサービスです。以下のような機能が含まれます。
- CloudTrailの自動設定
- Configの自動設定
- Configルールによる検知ガードレール設定
- SCPによる予防ガードレール設定
- ログアーカイブアカウントの作成、設定
- 監査アカウントの作成、設定
- AWS SSOの自動設定
- セキュリティ通知機能の自動設定
AWS Control Towerがすべてセキュリティ設定をやってくれる。というわけでも無いので必要に応じてOrganizations等の機能を使用して独自設定していくことになります。新規でOrganizationsを使う場合は、是非活用したいサービスです。ただし、大阪リージョンは現時点では対応していないため注意が必要です。
さらなる発展を求めて・・
マルチアカウントの構成の最上級はどうなるのか。というところですが、AWSのホワイトペーパーが参考になります。
本記事で紹介していない機能だと、VPNやDirectConnectを管理するネットワークアカウントや、共用リソースアカウント、SCPの検証用アカウント（OU）、一時停止用アカウント（OU）などが存在します。組織の用途に応じて参考にしましょう。
まとめ
繰り返しになりますが、私が言いたいのはライフサイクル、操作する人・権限、コスト管理、クォータの観点でAWSアカウントを分けましょうという点です。特にこれが絶対正解という構成も無いので、組織の要件に応じて考えると良いでしょう。 また、本記事を読むことで、AWSアカウントを分ける必要性について共感いただけたら幸いです。私もまだアカウント構成に悩むことは多いので、是非プロフェッショナルな方々とも意見交換してみたいです。
それではまた！
AWSアカウントの管理や支払はNRIネットコムにお任せください。
NRIネットコムは、AWS Organizationsを利用した一元管理や日本円での請求書発行などの支払い代行サービスを提供し、お客様のAWSアカウントのセキュリティ・ガバナンスを支援します。
