asken テックブログ

askenエンジニアが日々どんなことに取り組み、どんな「学び」を得ているか、よもやま話も織り交ぜつつ綴っていきます。 皆さまにも一緒に学びを楽しんでいただけたら幸いです!

複数の AWS アカウントを AWS Organizations 管理にした話

こんにちは。asken 初の専任インフラエンジニアとして 2022年6月に asken に入社した沼沢です。
asken での AWS アカウントとユーザー管理についてお話したいと思います。

asken では以前から複数の AWS アカウントを利用しており、これまではそれぞれのアカウントで個別に管理していました。
そこには、ユーザー管理の課題、セキュリティ・ガバナンス的な課題等、AWS マルチアカウント運用で発生する「あるある」な課題が asken にも多数存在していました。

そこで、これらを解決するため AWS Organizations を導入することにしました。

この記事に書かれていること・いないこと

書かれていること

  • asken における Organizations の設計と適用しているガードレール、セキュリティ系サービスの話
  • asken における ユーザー、アクセス管理について

書かれていないこと

  • Organizations や Control Tower 等、AWS の各サービス自体の説明や関連した用語の解説

AWS アカウント管理

AWS Organizations は、1つの管理アカウントとそれ以外のメンバーアカウントという構図で複数の AWS アカウントを管理します。
そのため、まずは管理アカウントとなる AWS アカウントを新規に発行するところから始めました。
そのアカウントにルートユーザーでログインし、MFA を設定したり、Administrator 権限を付与した IAM ユーザーを1つ用意したりしてルートユーザーはログアウト、以降は Administrator 権限の IAM ユーザーで作業しました。

その後設計に入ろうとしたのですが、自身で Organizations の設計をするのは初めてだったので、「OU 設計ってどうすりゃええねん」「SCP 設計難しい」という壁にぶち当たります。
また、Organizations をガッツリ設計して運用することも、人数を考えると難しいとも思いました。

そこで、Control Tower を使ってマルチアカウント管理をすることにしました。
Control Tower は、AWS がこれまで得てきた経験に基づいたマルチアカウント管理のベストプラクティスを提供してくれるサービスで、AWS Config や CloudTrail の設定等の強制、監査的なログを集約する専用 AWS アカウントの作成、監査用 AWS アカウントの作成等を行ってくれます。

aws.amazon.com

設計する際は、事前に全てを設計したのではなく、Control Tower を実際に動かし試行錯誤しながら進めました。

基本方針

Organizations で厳しく制限しすぎると開発スピードの低下や運用コストが高くなると考えたため、エンジニアを信頼して権限を最大限渡しつつ守るとこだけ守るスタイルを基本方針として設計しました。

設計する上で参考にした情報

aws.amazon.com

aws.amazon.com

Organizations 全体設計

試行錯誤した結果、現在はこのような設計に落ち着いています。

OU 設計

それぞれの OU は以下のような用途として用意しました。

OU 用途
Foundational OU Control Tower によって作成される OU。
監査用アカウント、ログ集約用アカウントを稼働させる。
この2アカウントも Control Tower によって作成、設定される。
Workload OU ソフトウェアライフサイクルに関連する AWS アカウント用 OU。
子 OU として Production, SDLC, Corporate を用意。
それぞれで管理をしやすくするため OU を分離。
Production OU 本番環境用の OU。
SDLC OU 本番環境ではないアカウントのための OU。
ステージング環境、開発環境のアカウントを所属させる。
SDLC は Software Development Life Cycle の略称。
Corporate OU 社内システム用 OU。
Suspended OU クローズ予定の AWS アカウント置き場。
不要になったアカウントはここへ移動し、一定期間経過した後に削除。
ここに配置した AWS アカウントは、全ての操作ができない状態となる。
PolicyStaging OU SCP の変更を検証するための OU。
ここで検証し、問題ないと判断してから適用することで、設定ミスによる事故を防ぐ目的。

AWS Organizations における組織単位のベストプラクティス には、他にも様々な OU が定義してありますが、asken で必要そうなものだけに絞りました。
将来的には Sandbox OU 等の導入も検討したいところです。

各 OU のガードレール

Control Tower によって設定される「必須のガードレール」では、主に Control Tower のためのリソースや、Control Tower が管理するリソースに対しての操作を禁止するルールが適用されます。
例えば AWS Config や CloudTrail の設定変更を禁止したり、ログ用の S3 バケットの公開設定を拒否したりといったものです。
全ては紹介しきれないので、内容は以下を参照ください。

docs.aws.amazon.com

ここでは、「強く推奨されるガードレール」「選択的ガードレール」のうち有効化しているガードレールについて紹介します。
親子関係にある OU では、親 OU で設定されているガードレールは子 OU でも有効となります。

予防的ガードレール 発見的ガードレール 親 OU
Foundational OU ・ルートユーザーのアクセスキーの作成を許可しない ・ルートユーザーの MFA が有効になっているかどうかを検出する
・Amazon S3 バケットへのパブリック読み取りアクセスが許可されているかどうかを検出する
・Amazon S3 バケットへのパブリック書き込みアクセスが許可されているかどうかを検出する
Workload OU ・ルートユーザーのアクセスキーの作成を許可しない ・Amazon RDS データベースインスタンスへのパブリックアクセスが有効になっているかどうかを検出する
・Amazon RDS データベーススナップショットへのパブリックアクセスが有効になっているかどうかを検出する
・無制限の着信 TCP トラフィックが許可されているかどうかを検出する
・SSH を介した無制限のインターネット接続が許可されているかどうかを検出する
・ルートユーザーの MFA が有効になっているかどうかを検出する
・Amazon S3 バケットへのパブリック読み取りアクセスが許可されているかどうかを検出する
・Amazon S3 バケットへのパブリック書き込みアクセスが許可されているかどうかを検出する
Production OU ・Amazon EC2 インスタンスの Amazon EBS 最適化が有効になっているかどうかを検出する
・Amazon EBS ボリュームが Amazon EC2 インスタンスにアタッチされているかどうかを検出する
・Amazon EC2 インスタンスにアタッチされた Amazon EBS ボリュームの暗号化が有効になっているかどうかを検出する
・Amazon RDS データベースインスタンスのストレージ暗号化が有効になっているかどうかを検出する
Workload OU
SDLC OU Workload OU
Corporate OU Workload OU
Suspended OU ・ルートユーザーのアクセスキーの作成を許可しない ・ルートユーザーの MFA が有効になっているかどうかを検出する
PolicyStaging OU ・ルートユーザーのアクセスキーの作成を許可しない ・ルートユーザーの MFA が有効になっているかどうかを検出する

全ての OU で共通して、ルートユーザーはガッチリ守っています。
ここを破られたらそのアカウントはもう死んだも同然になりますので、当然です。
また、発見的ガードレールによって設定値のチェックも最低限できるようになりました。

セキュリティ系サービスの導入

ガードレールによって最低限の防御とチェックができるようになりましたが、せっかくなので以下のような AWS サービスを導入してセキュリティとガバナンスの向上を図りました。

このうち、GuardDuty、Config、SecurityHub、Detective の管理を Audit アカウントに委任して集約することで、監査系のオペレーションを Audit アカウント上でのみ行えるようにしています。
Security Hub では CIS AWS Foundations BenchmarkAWS Foundational Security Best Practices を有効化しており、検知された内容を Slack に投稿することで、チェックを自動化しています。
人手が足りないので、AWS に任せられるところは任せる、自動化できるところはどんどん自動化しています。

ユーザー、アクセス管理

Organizations の導入を機に、ユーザー、アクセス管理を AWS SSO に移行することにしました。

asken では以前から OneLogin を利用していて、OneLogin が AWS SSO との連携も可能なため、OneLogin を ID プロバイダとして利用することにしました。
これによって OneLogin は認証を、AWS は認可を管理する形となります。
AWS の管理と OneLogin の管理は別のチームが行っているため、ガバナンス的にも意味があります。
また、OneLogin 側では MFA の設定を強制しているため、認証の強化にも繋がりました。

OneLogin との連携では SCIM による自動プロビジョニングを採用したかったのですが、弊社が契約している OneLogin のプランでは残念ながらサポートされていなかったため、手動プロビジョニングの方法で進めることにしました。

設定を進める際には、クラスメソッドさんの記事を参考にしました。
dev.classmethod.jp

権限の付与ルール

ユーザー(orグループ)には、1アカウントに対して1つのアクセス権限セットを付与することにしました。
また、グループは会社の組織構造に依存させないようにしたかったため、広範囲に同じ権限を付与したい場合のみ利用することとし、原則ユーザーに対して権限付与することにしました。
これは、シンプルにすることで管理のしやすさを確保し、なるべく運用コストがかからないようにするためです。

グループ設計

前述の通り、一括で同じ権限を付与した方が効率が良いものだけグループを用意しました。
あくまで設計時点のグループです。今後状況に応じて追加や削除を行っていきます。

グループ名 説明
Administrators AWS の管理者用グループ。
Organizations 配下の AWS アカウント全てに Administrator 権限でログインすることができる。
Accounting 経理メンバー用グループ。
請求周りの閲覧を行うメンバー用グループ。
経理担当者のみが所属する。
AllEngineers システム部のメンバー全員用グループ。
Workload OU 配下の全ての AWS アカウントに対する ReadOnly 権限を付与する。

アクセス権限セット

個人や組織構造を意識せず、役割に対して必要となる権限を意識して定義しました。
こちらもあくまで設計時点のアクセス権限セットです。今後状況に応じて追加や変更を加えていきます。

名前 権限の内容と用途 付与ポリシー
Administrator Administrator 権限。
基本的には Administrators グループ(AWS 管理者用グループ)にしか付与しない。
・AdministratorAccess(Managed)
BillingCheck 請求確認用権限。
基本的には Accounting グループ(経理メンバー用グループ)にしか付与しない。
・Billing(Managed)
PowerUser PowerUser 権限。
一般エンジニアにも、本番環境以外で付与。
IAM, Organizations, Account 以外の全ての操作が可能。
・PowerUserAccess(Managed)
・iam:PassRole 権限等、足りない権限入りのインラインポリシー
Production 本番環境用権限。
本番環境における致命的なオペレーションミスを抑止するため、必要な権限のみ付与。
・利用している AWS サービスのフルアクセスのインラインポリシー
  例) “ec2:*”
・禁止操作を定義したインラインポリシー
  例) RDS のインスタンス削除禁止 等
AIOperation AI 業務に必要な権限。
機械学習等で必要となる権限のみ付与。
・利用している AWS サービスのフルアクセスのマネージドポリシーを付与
  例) AmazonSageMakerFullAccess 等
・禁止操作を定義したインラインポリシー
  例) S3 バケットの削除禁止 等
S3Operation S3 への操作を行うメンバー用の権限。
開発者以外のメンバーで必要な場合に割り当てる。
・AmazonS3FullAccess(Managed)
・禁止操作を定義したインラインポリシー
  例) S3 バケットの削除禁止 等
ReadOnly 読み取り専用権限。 ・ReadOnlyAccess(Managed)
・AWSSupportAccess(Managed)

権限の紐付けイメージ

インフラエンジニア、カモンヌ

ということで、積極採用中です。
asken にはこのような課題がまだまだ盛りだくさんです。誰か助けてください。
興味を持った方のご連絡をお待ちしております。

www.wantedly.com