AWS 初心者なんですが、今後 AWS とガチで向き合う必要が出てきました。 AWS といえば、まず押さえるべきは IAM でしょうということで、「AWS IAM のマニアックな話」を読みました。
全体的な感想
まず買ってよかったし読んでよかったです。
IAM のベストプラクティス はもちろん事前に読んでいたのですが、 なかなか実運用のイメージがつかめませんでした。 この本では IAM の設計パターン・運用・それを実現するポリシーを含め、なるほどこのようにして実践するのか、という実運用に即した学びが非常に多くありました。
IAM に特化した本というのは多くなく、商業誌としても取り扱いにくいテーマなので、こういった本が同人誌として手に入る世の中はとても良いですね。
IAM の運用
上記の通り、IAM 運用には非常に興味があったので、「IAM の運用」は自分にとって刺さる章でした。 冒頭のまず必要なのは「役割と責任の明確化だ」という原則論すら、私としては明示的な意識ができていなかったところでもあります。
その明確化を実施した上で、IAM ユーザーの管理としての原則、そして運用が展開されていきます。 最小権限の付与や棚卸しはもちろん、人間はミスをするものであるという前提からのサービスでのサポート (CloudTrail や Config Rule)という流れは、 自分でも納得しやすいものでした。
プログラム用の IAM ユーザーに対して、タグに担当者を書いておくというのも、実は目に鱗だったところです。
踏み台アカウントという概念
興味深かったのは踏み台アカウントです。
私の知る限り、dev、stg、prod といった各環境を作る場合、AWS アカウントごとわけるのがベストプラクティスです。 一方で、各環境に IAM ユーザを作っていくと管理が煩雑になる。それをどのようにして回避するのかというところで言及されていたのが、「踏み台アカウント」という概念でした。
- 「踏み台アカウント」という独立した AWS アカウントを作成しておき、そこで IAM ユーザを定義です。
- dev/stg/prod といったアカウントでは、IAM Role、ポリシーのみ定義する
これにより、アカウントの管理が一箇所で済む。 小規模なサービスでどこまでやるかという話もありますが、最初からこういう仕組みを取り込んでいくのもよさそうだなと考えています。
今後
マルチアカウント管理のベストプラクティスがぜひ知りたくて、著者の @dkfjさんが今後書かれる予定(?)の Organizations 本も楽しみにしています。
こちらこそありがとうございます!
— Yuichi Kiri (@kiririmode) March 23, 2020
Organization 本も楽しみにしてます!!