ベスプラに憧れてIAMユーザーを集約した話 ～Identity Center × Jump アカウント × CDK で実現するマルチアカウントのアクセス管理～ Speaker: 彩の国埼玉支部 瀬山 政樹 

自己紹介 氏名 瀬山 政樹（@MasakiS_0402） 所属 ITを本業としない事業会社 → クラウドCoE として苦悩を楽しむ日々 好きな AWS サービス IAM とか AWS Organizations x 連携機能 表彰 Japan AWS TopEngineer 2021/2022/2025 ALL AWS Certifications Engineer 2022/2024/2025 

Agenda 1. 目指したベストプラクティス 2. 現場の壁とその背景 3. 解決のアーキテクチャ設計 4. まとめ 

ベストプラクティス システムを設計・運用する際の経験則や推奨事 項をまとめたもの 

目指していた 【ベストプラクティス】 参考ドキュメント：https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users 

目指していた 【ベストプラクティス】 • AWSが推奨する構成イメージ（個人の理解） ✓人が利用するIAMユーザー非推奨 → AWS IAM Identity Center で一元管理 ✓組織全体での統一アクセス管理（Permission Set + SCIM） ✓MFA でセキュリティを確保 AWS IAM Identity Center 自社エンジニア AWS account AWS account AWS account 

AWS IAM Identity Centerの動作イメージ PC操作 スマートフォン操作(MFA) 1. Identity Center ポータルへアクセス 2. リダイレクト先のMicrosoft Entra ID ログイン画面 3. MFA認証（スマホ等） 4. Identity Center ポータルへ遷移 5. Permission Set に応じてアカウント一覧表示 6. 任意のAWSアカウントにログイン 動画再生のスライドの ため、YouTubeの配信 動画をご確認ください 🙇 

現場ではベストプラクティスがそのままでは通用しない • 「Identity Centerで一元管理」って言うのは簡単だけど… ✓外部ベンダーのユーザーがEntra IDに存在しない ✓Permission Set割当ての運用が複雑 ✓ワークロードアカウントにIAMユーザー文化が根強く残る ✓AWS Organizations管理外のAWSアカウントの一部存在 ✓Identity Center がアイデンティティソースを１つしか指定できない AWS IAM Identity Center 自社エンジニア AWS account AWS account AWS account 

現場ではベストプラクティスがそのままでは通用しない AWS IAM Identity Center 自社エンジニア AWS account AWS account AWS account 

外部ベンダーさんだけ、IdPにユーザーを作成できない… AWS IAM Identity Center 自社エンジニア AWS account AWS account AWS account 諸事情により、 ここに作れない！ 外部ベンダー （ライセンス数の都合上、契約上と理由は様々） 自社エンジニア（管理者側）すると… 外部ベンダー（利用者側）からすると… • AWSアカウントの数だけIAMユーザーを持ちたくない… • 各AWSアカウントにIAMユーザーがあるのはリスク… • AWSアカウントが増えるたびにIAMユーザーが増殖… 予算が… なんで… A W S ア カ ウ ン ト 数 は 4 0 以 上 存 在 

AWS account AWS account AWS account JUMPアカウント IAM Role Role Role 外部ベンダーさん IAMユーザー集中管理のための「Jumpアカウント」構成 ① 1. JUMPアカウントにIAMユーザーを作成 • IAMユーザーは原則、JUMPアカウントのみに作成 • MFA必須として、設定していない場合、 AssumeRole不可ポリシーを適用 2. 各AWSアカウントにはJUMPアカウント&指定されたＩＡＭグループ からの AssumeRole を許可するＩＡＭロールを作成 3. 外部ベンダーさんは以下のステップでログオン • ＪUMPアカウントのIAMユーザーでログイン • 目的のＡＷＳアカウントにAssumeRoleを行なう ② ③ より効率的なIAMリソースの管理を実現に向けて。。。 

CDKによるIAMリソースの作成と管理を実施 Parameter Store 1. クロスアカウントアクセス管理 • AWS Organizations内の複数アカウントへのアクセスを一元管理 • JUMP アカウントでIAMユーザーを集中管理 • 各アカウントにはロールを配置し、ロールスイッチで権限付与 2. セキュリティ機能 • MFA強制機能：MFA未設定ユーザーは限定操作のみ可能 • IP制限：特定のIPアドレスからのみアクセス可能に制限 • Permissions Boundary：権限の境界を設定可能 • 初期パスワード自動生成：安全なパスワード生成と設定 3. 権限管理 • 複数の権限レベル：Admin、Power、Read、PowerAndIam、SSM • パートナー企業ごとのグループ管理 • カスタム権限の定義も可能 4. アカウント管理 • 複数のOrganizations 配下に存在するAWSアカウントに対応 • OU（組織単位）ベースの管理 ※CDKを使うに至った理由は「使ってみたかった」 

GitHub Actionとの連携 AWS account AWS account AWS account JUMPアカウント IAM Role Role Role CloudFormation ④各AWSアカウントにCFnのデプロイ ①CDKコーディング ②CDKコード push ③CI/コードレビュー ③マージ後、自動デプロイ ④CDKでJUMPアカウント内のリソー ス作成/更新を実施 

Qiitaに記事公開しているので興味があれば見てください！ Parameter Store 

まとめ 1. ベストプラクティスはとても参考になる • 「教科書通りの答え」に近いイメージ 2. ただし、ベストプラクティスがそのまま現場で使えるとは限らない • 理由は様々（既存環境との兼ね合い、文化など） • 現場に合わせた最適を選ぶために「教科書通りの答え」をどう緩ませていくかが大事 • ゼロベースでの構築ならまずはベストプラクティスを前提に考える 3. Qiita見てください！ 

ご清聴ありがとうございました！