こんにちは。森です。
突然ですが皆さんは、AWSのアカウント設計・管理をしていて困ったことってありませんか？
私はたくさんあります。
例えば過去に下記のようなことについて困ったことがあります。
- ユーザー管理はどうしたらいいか
- AWSアカウントのセキュリティって何をすればいいのか
- OUってどうやって分ければいいのか(OU設計)
etc
今回は一部ですが私が過去に困ったことに対して、どのようにして対応したかを簡単に記載していこうかと思います。
困ったことCASE1 : ユーザー管理どうしたらいいか
内容
ユーザー管理というのは、「どの利用者がどのアカウントにどんな権限でアクセスするのか」という内容になります。
実際に沢山の利用者やAWSアカウントがある場合、管理がとても煩雑になりやすいですよね。
実際に過去に行っていた運用方法では下記のような問題がありました。
過去の運用と問題
各AWSアカウント毎に利用者のIAMユーザーで運用
各AWSアカウント毎に利用者のIAMユーザーを用意して運用する方法になります。
下記の画像を例にするとAWSアカウントの数だけ利用者のIAMユーザーが発行されていることになります。
※男の子と女の子は3つ分のIAMユーザーを管理することになる。
この運用をしていると下記のような問題点があり、運用・管理コスト的にもよろしくなかった状態でした。
- 1人の人が複数アカウントのIAMユーザーを管理することになる。またMFA(多要素認証)の設定も沢山管理することになる。
- 入社・退社などあった際に必要なAWSアカウント分のIAMユーザー作成・削除作業が発生する。また人数が多いと抜け漏れが発生する。
それらの課題を解決するために次に行ったのが下記の運用方法になります。
踏み台アカウントからスイッチロールによる運用
踏み台アカウントからスイッチロールを利用した運用になります。
下記の画像を例にすると踏み台アカウントに各利用者がログインをしてもらい、そこからスイッチロールを利用して各AWSアカウントへログインすることができます。
その為、作成するIAMユーザーは踏み台アカウントにのみ作成すればいいわけです。
これにより利用者のIAMユーザー管理や入社・退社があった際の抜け漏れも減らすことが出来ました。
ただこの運用をしていても下記のような新たな問題が発生しました。
- AWSアカウント先のスイッチロール(IAMロール)の管理
- スイッチロール(IAMロール)をアカウント毎に作成するのが大変
こちらはどのAWSアカウントにも同様なスイッチロール(IAMロール)と権限を作成することができればCloudFormation(またはCloudFormation Stacksets)を使用して比較的簡単に作成や管理が出来ると思います。
ただ弊社では当時諸事情によりそれが出来なかった為、一部の作業を手動で行っておりました。
その為、AWSアカウントが増える度にスイッチロール(IAMロール)を作成しないといけないという作業が発生し、日に日にスイッチロール(IAMロール)の作成・管理コスト的に工数が増えてきたのでそれらを解決するために下記の方法に運用を切り替えました。
現在の運用
AWS IAM Identity Centerを導入しました。※導入当時はAWS SSOでしたが本ブログでは、AWS IAM Identity Centerと記載致します。
元々弊社ではAzureも使用していたこともありAWS IAM Identity Centerを利用してAzure Active Directory(Azure AD)のユーザー情報でAWSアカウントへのログインを出来るようにしました。
このようにすることで下記のメリットが得られました。
メリット
IAMユーザーの管理をしなくてよくなった。
過去の運用方法でも記載しましたが、IAMユーザーを利用したログイン方法だと
IAMユーザーの管理が必要になってきます。そうなってくると利用者が増えていけばいくほど作成・管理コストが高くなっていきます。
この仕組みにしてからIAMユーザーを使用しなくなった為、今までの作成・管理コストが掛からなくなりました。
1つのAWSアカウントで権限回りを管理できるようになった。
スイッチロールで運用していた時は各AWSアカウントに作成されているスイッチロール(IAMロール)で権限の制御を行っていた為、確認するのにも各AWSアカウントにログインする必要があり時間が掛かっておりました。
この仕組みにしてからAWS IAM Identity Center内で権限回りの作成や設定が可能な為、管理がしやすくなりました。
一時的クレデンシャルが発行されるようになった。
AWS IAM Identity Centerを導入することによりIAMユーザーの永続的なクレデンシャルを管理せずに済むようになりました。
詳細は下記ブログ記事見てください。
AWS Single Sing-On(AWS SSO) 改め AWS IAM Identity Center でCLIする
AWSアカウントへのログインが楽になった。
下記のような画面からボタン一つで各アカウントにログインが出来るため、楽になりました。
※個人的にこれが一番うれしい。
困ったことCASE2 : AWSアカウントのセキュリティって何をすればいいのか
内容
複数のAWSアカウントを管理しているとどうのようにセキュリティを担保するかが重要になるかと思います。
実際にどのようなサービスを使用してどのようなことをしたのかを下記に記載していこうと思います。
対応方法
下記のサービスを使用して対応を行っていきました。
Amazon GuardDutyとAWS Security Hub
全アカウントにAmazon GuardDutyとAWS Security Hubを有効化しております。
Amazon GuardDutyによりアカウント内で不審な動きがあってもすぐ検知してくれます。
またAWS Security HubでGuardDutyで検知した内容を自動で纏めてくれるため、各AWSアカウントの
Amazon GuardDutyの結果を1つのAWSアカウントにまとめておけばとても楽になります。
Amazon GuardDutyやAWS Security Hubの詳細については下記の記事を参照ください。
AWS Organizationsのサービスコントロールポリシー
絶対に触らせてたくないサービスや禁止させたいサービスがあった場合は、利用者から実行できないようにすることが出来ます。
それがAWS Organizationsのサービスコントロールポリシー(以下、SCPと言います。)という機能になります。
これを設定することにより、そもそもリスクあるアクションを起こさないように出来るようになるのでとてもいいです。
※AWSではこれを予防的ガードレールと言います。
AWS Control Tower
AWS Control Towerにはガードレール(=AWS 環境全体に継続的なガバナンスを提供する高レベルのルール)というものがあります。
これらを有効化することによりAWS Control Towerに記載されているガードレールが各AWSアカウントに自動で適用されるようになりますので、簡単に各AWSアカウントにガードレール(正確にはSCPやAWS Configなど)の設定がされるようになり楽に運用が出来るようになります。
※AWS Control Towerに登録されたAWSアカウントのみが対象になります。
困ったことCASE3 :OUってどうやって分ければいいのか(OU設計)
マルチアカウント環境を構築していくときに避けては通れないのがこのOU設計かなと思います。
私が設計したときは OrganizationsのSCP も考慮しながらの設計を行いました。
実際にどのように考えたのかを下記に記載していきます。
対応方法
OU設計について右も左もわからない状態でしたので下記AWSのサイトを読み考えてみました。
Best Practices for Organizational Units with AWS Organizations
やったことがない作業だったので基本的にAWSベストプラクティスに沿った形でOUの設計をしていきました。
ここ等辺は企業によって様々だと思いますが、運用が始まったらなかなか設計変更も難しい箇所かと思いますので、あとから後悔しないように検討するのがいいかなと思います。
最後に
いかがだったでしょうか。
一部ではございましたが、どのように対応したかをご紹介させて頂きました。
マルチアカウントの設計・管理は大変だと思いますが、あまり経験できない機能ばかりを扱うことが出来るので貴重かなと思います。
本ブログがこれからマルチアカウントの設計・管理を行う方の助けになれば幸いです。
それでは。
