この記事のスタンス
今まで実際にやってきたことを べき論 や何処かを批判する目的ではなく、こうしたらちょっといい感じだった、というスタイルで公開していきます。
セキュリティと利便性の天秤をいい感じにバランスとることは日頃の努力であり、どこがいい感じかは運用によるのでそこは匙加減。
実際の使用者と管理すべき内容を秤にかけていい感じに各々やっていることと思います。
この記事で説明すること
- AWSアカウントの管理運用方法
実際のRole/Policyの管理運用方法自動化について
取り消し部分はそのうち別記事で書きます
AWSアカウントの管理運用方法
実稼働しているAWSがガンガン増えている昨今、大小様々なところでAWSが使用されていますが、その管理方法をちょっとみていきたいと思います。
よくあるパターン
一個のAWSアカウントの中で様々なサービス(プロジェクト)が同居している状態。
もちろん、規模によりけり運用によりけりではあるものの上図のようなパターンはよく見かけます。
ユーザーアカウント(IAM User 以降Userとする)が大量に作られ、直接 AWSサービスを駆使するような格好。
無論、これも場合によっては特別まずいパターンではない。
このような時のメリット・デメリットは次の通り
よくあるパターンのメリット
- 一個のアカウントだからあちこちを気にしなくてOK
- User側もクロスアカウントとか考えなくていい
- TerraformやServerlessFlameworkを使うときにproviderだったりprofileを分けなくて済む
よくあるパターンのデメリット
- Userに対するIAM Policyの管理が複雑になりがち
- 間違えてデプロイして悲惨なことになる確率UP
- しっかりとした管理を行いたい場合にUserをコンソールから締め出したりする必要も出てくる
他にも説明が必要だったり列挙できるものは沢山あるけど、ただの概要説明なので割愛。(いずれちゃんと書くかも)
このパターンの良い所をまとめると、余計なこと考えないでとりあえず使うにはもってこい。
Organizationsや、IAMRole, IAM Policy等のやりだすと時間かかる部分をとりあえず使うところまで持っていける。
これをクロスアカウントにするとS3のオブジェクト一つにしても、クロスアカウントになるだけで書くべきポリシーは増える(≒必要知識も増える)ので、ちょっとした修行が必要になる。
やってて良い感じだなと思うパターン
プロジェクト(サービス)毎にAWSアカウント自体が分かれていて、ログインユーザーを配置するアカウントも別途用意
図描いてても気持ちいい....
いい感じだったパターンのメリット
- 権限や管理の中央集権制がアカウント単位でなされる
- 実際のAWSユーザーに不便を強いる必要がない
- アカウント丸ごと渡すのであとは好きにしてね
- 但し、CloudTrail等のログはAWS アカウントのポリシーベースの管理 で制限
- アカウント丸ごと渡すのであとは好きにしてね
- Login用アカウントを管理者チームが管理することでLogin用アカウントにポリシーを必要に応じて作成すればグループでの管理も用意(この辺はよくあるパターンでも同様)
- RootアカウントのCloudTrailのログ・AWS Config等による作成するサービスへの制限 によって法人監査にも簡単に対応可能
- 各アカウントごとにサービスが分かれているのでコスト管理がタグよりも大きな枠で可能(目視も簡単)
- 各アカウントのサービスを連携したときにどうなっているか比較的把握しやすい
- 各種サービスのクオータが他のプロジェクトに邪魔されない(これ重大)
- S3のバケット作成数の上限は1000個で、分析とかやるようなプロジェクトが複数あるとすぐ逼迫する
いい感じだったパターンのデメリット
- 作るときに必要な知識がそもそも多い
- 自動化しないと運用がかったるい
- AWSアカウントの作成自動化
- OrganizationAccountAccessRoleの調整
- 誰がAssumeRoleできるの？とか
- loginアカウントへのIAM ユーザー追加
- loginアカウントよりも先のアカウントで自前でCloudTrailしたい！みたいな要望への対応
- これは今現在(2021/03/12)SCPが大分使い勝手良くなったのでよしなにやれる=> SCP
- 管理したがるタイプの人が管理すると使い勝手が激しく悪くなる(なんでもそう)
- 各アカウントの管理者を立てる必要がある
- 別アカウントのS3等からLambdaをキックする時の設定がめんどくさい
いい感じだったパターン時のユーザーから見たAWSの扱い方
- login用のAWSアカウントにログイン(コンソール画面)
- 必要なプロジェクト用のAWSアカウントへスイッチロール
- あとは自由！
この時、あとは自由！になる人が本番環境の場合は当然絞られるべきだし、開発環境だからといって好き勝手やると消し忘れたリソースが溢れて費用的に悲しい結末を迎えたりするので要注意。
もうちょっときれいにどこかで書き直します