SwitchRoleを利用したマルチアカウントIAM運用 & 権限委譲した話

こんにちは!クラウドCoEの遠藤です。

クラウドCoEについては以前ご説明させていただきましたが、
blog.engineer.adways.net
今回はミッションの中の「クラウド管理」にフォーカスしたお話です。

昨今、AWS Control Tower(AWS Landing Zone)が注目されたりと、どんどんマルチアカウント運用のしやすい環境が整ってきています。

AWS公式でも下記の理由からマルチアカウント運用が推奨されています。

  • ガバナンス
  • 課金
  • 組織
  • 運用

特に弊社では料金や権限の分離をIAMやタグで管理することに限界を感じ、アカウントを環境ごとに分離していくことになりました。

経緯

現在アドウェイズでは30以上のAWSアカウントを運用しており今後はさらに増えていく見込みですが、IAMについて下記の問題が発生しました。

マルチアカウントで発生したIAM課題

  • 開発チームごとのIAM運用の差
    • 命名規則がバラバラ
      • 同じユーザーが別の名前で他AWSアカウントに存在する
    • MFAが適用されていないユーザーが存在する
  • 統制がとれていない
    • 謎のシステムユーザーのコンソールログインが可能
    • 異動、退職に伴うユーザー追加削除及び権限昇降格が適切に為されていない
    • ユーザーやキーの棚卸しができていない
  • 複数AWSアカウントにアクセスするユーザーはその数だけMFA登録が必要

方針

上記の課題を解決すべく、弊社の目指すべき運用について各所と会話し以下の方針を決定しました。

ユーザー管理を一元化する

  • ログインルール(経路)の統一化
  • IAMロールに権限付与する
    • (システムユーザーを除く) IAMユーザーへの個別権限付与を禁止
  • 退職者処理の漏れを無くす

開発スピードを向上させる

  • 複数AWSアカウントの行き来をスムーズに
  • MFAを強制しつつ、回数を最小限に
  • 権限ポリシーは現場責任者に委任
  • 現場に強めの権限を付与する
    • CloudTrail等でアクティビティ監視をすることでセキュリティを担保
    • 強く制限すべき対象とそうでない対象をAWSアカウントという境界で区切ること

上記方針を実現すべく下記略図のような環境を構築しました。

f:id:AdwaysEngineerBlog:20190725212250p:plain

実現したこと

  • ログインポータルAWSアカウントに(システムユーザーを除く)IAMユーザーを統一
    • ログインポータルAWSアカウントのユーザーをインフラ管理部門が管理
  • 各AWSアカウントから(システムユーザーを除く)IAMユーザーを削除
  • 各AWSアカウントにIAMロールのテンプレートを配布(Terraform)
    • Administrator
    • Developer
    • Operator
    • Readonly
  • ロールごとの権限ポリシー(テンプレートからの変更)は開発チーム責任者に委譲
    • IAMロール及びポリシーのTerraformで管理し、GilLab CI環境を開発チームに委譲
    • チームごとに必要なポリシーの追加や削除を行ってもらいGitLabでバージョン管理
  • AWS Extend Switch Rolesの利用
  • 上記構成のIAM管理をGitLab CI + Terraformでテスト・デプロイ自動化
    • 新規AWSアカウントが作成された際のロールやグループ、GitLab CI環境の構築全自動化

まとめ

今回は既存のOrganizationsでがっつり運用してしまっている環境だったため、新たなOrganizationsの作成が必要となるAWS Control Towerの導入は断念しました。
また、弊社のキーとなるIdPの運用が定まっていなかったため、SAML認証を用いたフェデレーティッドユーザー運用に踏み切ることができませんでしたが、それでも既存のIAMユーザーの整理がかなりできたと思っています。
今後は認証基盤を統一し管理業務を減らすことで、さらに開発に専念できる環境を整えていきたいです。