553 Views
November 08, 25
スライド概要
仕事:AWS運用保守&PM的なことをしています。 2023-25 Japan AWS All Certifications Engineers.
[IAMスペシャル!]Security-JAWS【第39回】 勉強会 開発チームに IAM管理の権限委譲を していく⽅法を考える 2025.11.08 ますの
ますの(おさとう) 業種 インフラエンジニア / PM(仮) 受賞 AWS Samurai 2024(JAWS 配信部メンバー) 2025 Japan AWS All Certifications Engineer 2025 Japan AWS Top Engineer コミュニティ2 JAWS-UG 配信部 最近の悩み ・お酒を飲んだら何故か家に帰れない ・英語何もわからん( re:Invent楽しみたい)
本⽇お話しすること ・現AWS環境で開発者チームへ IAM管理を権限移譲するまでのステップ ・IAM Identity Center でのユーザ管理 (IdP機能利用) ・Permissions Boundary によるガードレールの設定 (最大権限の制限) ・属性ベースアクセス制御( ABAC)を利用したタグのアクセス制御 勉 再 から た って 変わ するよ ス ティ ェア ラク 容をシ プ 内 スト のベ してきた M IA 強
2019年くらいの苦い思い出(AWS初⼼者時代) ・SESの客先常駐時:ユーザ企業の情シスとして IAM管理を行う ・開発者から依頼をもらって極力最小権限を目標に頑張る おけ。 ECSの最小権限調べるわ。 (地獄の始まり) ECS使って開発したいから 権限くださいな。
2019年くらいの苦い思い出(IT&AWS初⼼者時代) ・ECSだけで開発するわけもなくトライアンドエラーで都度権限付与をする ・お互い本来の業務が出来ずモヤモヤが募る ・最終的に開発スピードを重視して Admin権限で妥協する マネージドポリシーから 不要そうな権限削除おけ。 完璧なお仕事してやったぜ エラー出たっす。 あとRDSとS3も追加ね ※以降エンドレスに続く (遠くから見ていた上長参戦) お互い仕事回ってないから 今回はAdmin渡して進めよう
最小権限での IAM運用は理想だが 本格的にやろうとすると開発スピードが落 ちるという現実に遭遇
開発チームが触れる権限を限定して 専用IAMを担当者に管理してもらいたい (そんな夢みたいなことあるわけ ...)
ありました ※なお構築難易度はちょい高め
IAM管理権限移譲:実現までの道のり ・IAM Identity Center & ABAC 有効化 ・IAMポリシー作成(合計 5つ) → IAM Identity Center 許可セット用: 4種類 → Devチーム IAMの境界設定用: 1種類 AWS管理者 DevAdmin ・IAM Identity Center 許可セット設定 ・開発者ユーザを作成 ・自チームの IAMロール、ポリシーを作成 ・自チームの Tagリソースのみフル権限 ・自チームの Tagリソースのみフル権限 DevMember
IAM管理権限移譲:概要図 IAM AWS管理者 ・各種IAMポリシー作成 ・許可セット作成 ・Devユーザ作成(属性付与) AWS IAM Identity Center DevRole Protection Policy IAM ABAC Policy Resource ABAC Policy DevTeam Permissions Set DevTeam Boundary Policy DevRole PB Policy DevAdmin ・Dev用IAMの作成が可能 ・所属チームタグのみ作成可能 ・「許可の境界設定」が必須 IAM Identity Center を利用して SSOでAWS環境にアクセスする タグ:TeamA 属性:DevAdmin(TeamA) AWS管理者が設定した 許可セットの権限が付与される TeamA Role/Policy AWS管理者が設定したPermissions Boundaryにアクセス制限をす ることが可能。 属性:DevMember(TeamA) DevAdmin/Member ・設定されたチーム名以外の リソースは変更不可 タグ:TeamB
コンセプト / 前提 ・AWS管理者: ざっくり開発者にアクセス権限を付与する 自チームのリソースに限定して開発者へ管理委譲をしていく 触らせたくないサービスは Permissions Boundaryで重ねがけ制御する 1つのAWSアカウント内で完結させる ・開発管理者: AWS管理者が設定している範囲内のみアクセスが可能 間違えて Admin権限のIAMロールを作っても境界設定が有効化されて安心 境界ポリシーと自分のチームタグの設定を必須化
設定していく
IAM管理権限移譲:実現までの道のり ・IAM Identity Center & ABAC 有効化 ・IAMポリシー作成(合計 5つ) → IAM Identity Center 許可セット用: 4種類 → Devチーム IAMの境界設定用: 1種類 AWS管理者 DevAdmin ・IAM Identity Center 許可セット設定 ・開発者ユーザを作成 ・自チームの IAMロール、ポリシーを作成 ・自チームの Tagリソースのみフル権限 ・自チームの Tagリソースのみフル権限 DevMember
IAM Identity Center:有効化 リージョナルサービスであるため 有効化時はリージョンの確認を推奨。
IAM Identity Center:有効化 今回は外部 IdPは利用しない。 Identity Center をIdPとして利用する。 Identity Centerに作成されたユーザは AWS access portal URLからログインする。
IAM Identity Center > ABAC:有効化 設定 > アクセスコントロールの属性 > 有効にする をクリック
IAM Identity Center > ABAC:有効化 アクセスコントロールの属性 > 属性の管理 > ABACのタグを設定
IAM Identity Center > ABAC:有効化(属性について) ABACでのタグ制御に利用する属性を決める ・Team:「部」を利用 ・Role:「ユーザタイプ」を利用 IdPとして利用出来る属性を確認 (例) ・「DevAdmin」は管理者のみ付与 ・「部」に各チームのチーム名を入力 ※対象ユーザは設定されたチーム名と 一致するリソースのみアクセス可能 IAM Identity Center でSSOする時、 各ユーザの属性がセッションタグとして引き継 がれる。 これによりABAC制御が可能となる。 引用:サポートされている外部 ID プロバイダ属性
IAM管理権限移譲:実現までの道のり ・IAM Identity Center & ABAC 有効化 ・IAMポリシー作成(合計 5つ) → IAM Identity Center 許可セット用: 4種類 → Devチーム IAMの境界設定用: 1種類 AWS管理者 DevAdmin ・IAM Identity Center 許可セット設定 ・開発者ユーザを作成 ・自チームの IAMロール、ポリシーを作成 ・自チームの Tagリソースのみフル権限 ・自チームの Tagリソースのみフル権限 DevMember
どんな設定になってるの?(ざっくり) IAM AWS IAM Identity Center DevRole Protection Policy IAM ABAC Policy Resource ABAC Policy DevTeam Boundary Policy DevRole Boundary Policy DevTeam Permissions Set ・DevRole Protection:DevRoleの境界用ポリシー保護& IAM作成時の PB設定強制 ・IAM ABAC:チーム専用の IAM Role/Policy の作成を許可 (DevAdmin限定) ・Resource ABAC:チーム専用のリソース作成、変更を許可 (DevUser共通) ・DevTeam Boundary:Devユーザに対するガードレール設定 →上記4つを「許可セット」に登録して Devユーザの権限範囲を決定 ・DevRole Boundary:チーム専用の IAM に対するガードレール設定
各ポリシーの詳細はGitHubへ https://github.com/masno-soy/secjaws39-iam-for-devteams-json-list
1.DevRole Protection Policy DevAdmin用ポリシー DevAdminのIAM設定( Deny範囲) IAMポリシー「 IAM-DevRole-Boundary」の変 更、削除を Denyする IAMユーザ/ロールを作成する際に、 許可の境界へ「 IAM-DevRole-Boundary」が設 定されていない場合 Denyする
2.IAM ABAC Policy(1) DevAdmin用ポリシー DevAdminのIAM設定( Allow範囲) IAMロール/ポリシー作成: IAM Identity Center でユーザ属性 「Role:DevAdmin」が設定されているユーザのみ IAM ロール、ポリシーの作成が可能。 インスタンスプロファイル作成: EC2インスタンス用の IAMロールに必要な権限も併せ て付与
2.IAM ABAC Policy(2) DevAdmin用ポリシー DevAdminのIAM設定( Allow範囲) IAMロール/ポリシー変更管理: IAM Identity Center でユーザ属性 「Role:DevAdmin」が設定されているユーザのみ IAMロール、ポリシーの管理が可能。 変更可能な IAMは「Team:(同一チーム名 )」に限定。
2.IAM ABAC Policy(余談) DevAdmin用ポリシー ABAC判定実現方法は「 Tag値の比較」を行う ・aws:RequestTag:これから付けようとしているタグ値 ・aws:PrincipalTag:操作をしているユーザのタグ値 ・aws:ResourceTag:既存リソースに設定されているタグの値 IAM作成時:「 RequestTag」と「PrincipalTag」を比較して ABAC判定を実現 TeamAメンバーだったら 「TeamA」のタグでリクエストしてね! IAM作れるのは 「DevAdmin」だけだよ! IAM変更時:「 ResourceTag」と「PrincipalTag」を比較して ABAC判定を実現 「TeamA」のIAMだけど、君は TeamAだよね?
3.Resource ABAC Policy DevAdmin/Member 共通ポリシー 各Devチーム全員に付与される権限 リソース作成: iam以外は全部許可 リソースに設定される Teamタグとユーザ のTeamタグが一致していること リソース管理: iam以外は全部許可 リソースに設定されている Teamタグと ユーザの Teamタグが一致していること
3.Resource ABAC Policy(補⾜) DevAdmin/Member 共通ポリシー 各Devチーム全員に付与される権限 触っても良いサービスが大体決まっているようであればサービス名を羅列のほうがオススメ。 ガードレール的な最大権限を「 Permissions Boundary」で設定することがベストプラクティス。
4.DevTeam Boundary Policy DevAdmin/Member 共通ポリシー 各チームの最終防衛権限 ・記載の対象 Action以外は全て許可 ・セキュリティ関連操作は削除、停止、更新を禁止 ・管理系は全ての操作を禁止 Permissions Boundaryの考え方 ・拒否ではなく許可を設定する ・許可されていない権限は Denyされる ・ユーザ設定ポリシーに権限が重ねがけされる 引用:魔法の Permissions Boundary
IAM管理権限移譲:実現までの道のり ・IAM Identity Center & ABAC 有効化 ・IAMポリシー作成(合計 5つ) → IAM Identity Center 許可セット用: 4種類 → Devチーム IAMの境界設定用: 1種類 AWS管理者 DevAdmin ・IAM Identity Center 許可セット設定 ・開発者ユーザを作成 ・自チームの IAMロール、ポリシーを作成 ・自チームの Tagリソースのみフル権限 ・自チームの Tagリソースのみフル権限 DevMember
5.DevRole Boundary Policy DevAdmin/Member 共通ポリシー 開発中 AWSリソースの最終防衛権限 ・DevAdminが作成する IAMロールの最大権限 ・Permissions Boundaryとして設定する ・AWS管理者のみ権限変更が可能 DevAdminが誤って IAMロールに大 きな権限を与えても、 AWS管理者設 定以上の権限は付与されない。
IAM管理権限移譲:実現までの道のり ・IAM Identity Center & ABAC 有効化 ・IAMポリシー作成(合計 5つ) → IAM Identity Center 許可セット用: 4種類 → Devチーム IAMの境界設定用: 1種類 AWS管理者 DevAdmin ・IAM Identity Center 許可セット設定 ・開発者ユーザを作成 ・自チームの IAMロール、ポリシーを作成 ・自チームの Tagリソースのみフル権限 ・自チームの Tagリソースのみフル権限 DevMember
IAM Identity Center > 許可セット設定 許可セット > 許可セットを作成 > カスタム許可セット > 次へ をクリック
IAM Identity Center > 許可セット設定 ・AWSマネージドポリシー: ReadOnlyAccessを設定 必要に応じて設定。 チームのリソース以外は見せたくない場合は不要。
IAM Identity Center > 許可セット設定 ・カスタマーマネージドポリシー:先程の「 1〜3」のポリシーをアタッチする 1. DevRole Protection 2. IAM ABAC 3. Resource ABAC
IAM Identity Center > 許可セット設定 ・アクセス許可の境界:許可の境界をチェック ・カスタマーマネージドポリシーをチェック:先程の「 4」のポリシーを設定 4. DevTeam Boundary ・全て設定したら「次へ」をクリック
IAM Identity Center > 許可セット設定 ・許可セット名を入力 ・他は任意の値を設定 > 次へ をクリック
許可セット作成完了 グループに紐づける
IAM Identity Center > グループ作成 グループ > グループを作成 > (グループ名 ) > グループを作成 をクリック ・ユーザをグループ管理:グループごとに分割・ひとつに集約どちらでも ・今回の IAM設定では全チーム動的に統制管理可能としたので 「TeamA」「TeamB」をグループ内に集約しても問題無し OK
IAM Identity Center > 許可セット割り当て グループ > (グループ名 ) > タブ: AWSアカウント > アカウントを割り当てるをクリック
IAM Identity Center > 許可セット割り当て ・許可セットを紐づけたい AWSアカウントをチェック ・作成した許可セットを選択 > 割り当てる をクリック
IAM Identity Center > 許可セット割り当て グループにアカウント割り当てが完了
IAM管理権限移譲:実現までの道のり ・IAM Identity Center & ABAC 有効化 ・IAMポリシー作成(合計 5つ) → IAM Identity Center 許可セット用: 4種類 → Devチーム IAMの境界設定用: 1種類 AWS管理者 DevAdmin ・IAM Identity Center 許可セット設定 ・開発者ユーザを作成 ・自チームの IAMロール、ポリシーを作成 ・自チームの Tagリソースのみフル権限 ・自チームの Tagリソースのみフル権限 DevMember
IAM Identity Center > 開発者ユーザ作成 DevAdminユーザ DevMemberユーザ ジョブ関連情報の属性 ・システム管理者: IAMを作成出来るように「 DevAdmin」を設定する ・全開発者共通:自分のチーム名だけ変更出来るように「チーム名」を設定する
設定した属性がABACとして適⽤(再掲) ABACでのタグ制御に利用する属性を決める ・Team:「部」を利用 ・Role:「ユーザタイプ」を利用 IdPとして利用出来る属性を確認 (例) ・「DevAdmin」は管理者のみ付与 ・「部」に各チームのチーム名を入力 ※対象ユーザは設定されたチーム名と 一致するリソースのみアクセス可能 IAM Identity Center でSSOする時、 各ユーザの属性がセッションタグとして引き継 がれる。 これによりABAC制御が可能となる。 引用:サポートされている外部 ID プロバイダ属性
IAM管理 権限委譲設定 無事に完了
IAM管理権限移譲:実現までの道のり ・IAM Identity Center & ABAC 有効化 ・IAMポリシー作成(合計 5つ) → IAM Identity Center 許可セット用: 4種類 → Devチーム IAMの境界設定用: 1種類 AWS管理者 DevAdmin ・IAM Identity Center 許可セット設定 ・開発者ユーザを作成 ・自チームの IAMロール、ポリシーを作成 ・自チームの Tagリソースのみフル権限 ・自チームの Tagリソースのみフル権限 DevMember
DevAdminでIAMロールを作ってみる
DevAdminでIAMロールを作ってみる AdministratorAccessを設定しても 「許可の境界」に設定するポリシーが権限を重ねがけするため 統制が取れるようになる。 許可の境界を設定:「 5. DevRole Boundary」のポリシーが必須 「1. DevRole Protection」内に記載されいている IAMポリシー名を設定する必要がある
DevAdminでIAMロールを作ってみる タグ設定を忘れる or 許可の境界を忘れると ロール作成時にエラーとなる。
DevAdminでIAMロールを作ってみる IAM Identity Centerのユーザ属性で設定したタグ名と一致した場合 リソースの作成が完了する状態となる。
許可されていないリソースも作成不可 Teamタグを設定しても権限外のリソースはエラーになる(例: Amazon IVS)
Permissions Boundary と ABACによる統制管理 〜完了〜
まとめ ・2025年11月現在、 IAMユーザ/グループは非推奨となっている - IAM Identity Center の利用が推奨 ・属性ベースのアクセス制御( ABAC)でタグベースの 動的な権限管理が可能 ・IAM Identity Center 内蔵のIdP機能で外部 IdP不要 - ユーザー属性の設定も簡単に実現可能 ・Permissions Boundaryで最終防衛ラインを構築 - 組織全体のセキュリティポリシーを強制し統制管理可能 ・難易度は高いが AWS管理者とシステム管理者が幸せになる道を歩みたい。
ご清聴ありがとうございました
参考情報 ●魔法の Permissions Boundary https://pages.awscloud.com/rs/112-TZM-766/images/20230224_27th_ISV_DiveDeepSeminar_Permissionsboundary.pdf https://www.youtube.com/watch?v=O6MkF5PHeTc ●チェックリスト: IAM Identity Center AWS を使用した での ABAC の設定 https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/abac-checklist.html ●IAM アイデンティティセンターと外部 ID プロバイダーディレクトリ間の属性マッピング https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/attributemappingsconcept.html#supportedidpattributes ●Permissions boundaryを使ってみた https://www.ctc-g.co.jp/solutions/cloud/column/article/76.html ●GitHubリポジトリ > masno-soy/secjaws39-iam-for-devteams-json-list https://github.com/masno-soy/secjaws39-iam-for-devteams-json-list ●20分で分かるIAM全機能 /20240621-aws-summit-iam https://speakerdeck.com/opelab/20240621-aws-summit-iam ●25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全 / 20250625-aws-summit-aws-policy https://speakerdeck.com/opelab/20250625-aws-summit-aws-policy ●AWSの薄い本6 IAMのマニアックな話 2025 https://booth.pm/ja/items/6969928?srsltid=AfmBOoq_47Z8D0QpNdlEtO0BhK71S8ykVd488_A0f5BYOmrdKQyb53Zs ●IAMのマニアックな話 2025を執筆して、 見えてきたAWSアカウント管理の現在 https://speakerdeck.com/nrinetcom/iamnomaniatukunahua-2025wozhi-bi-site-jian-etekitaawsakauntoguan-li-noxian-zai