申請待ちゼロへ！AWS × Entra IDで実現した「権限付与」のセルフサービス化

「DevOpsDays Tokyo 2026」での登壇資料です。
イベントURL：https://confengine.com/conferences/devopsdays-tokyo-2026

Transcript

1. © 2026 Mizuho Bank, Ltd. 申請待ちゼロへ！AWS × Entra IDで実現した 「権限付与」のセルフサービス化 DevOpsDays Tokyo 2026 2026年4月14日 情報数理工学研究所 デジタル技術開発部 0
2. © 2026 Mizuho Bank, Ltd. 竹島 幸之輔 Konosuke Takeshima • 開発セキュリティ基盤を運営（ID基盤チームのリーダー） • 社内横断検索・AIによる関連情報提示等の技術開発も担当 自己紹介 1 松尾 優成 Yusei Matsuo • 社内向け AWS プラットフォーム / ゴールデンパスの設計・運用 • プラットフォームエンジニアリングの取組事例を発信 • AWS 公式ウェブマガジン builders.flash で連載記事を寄稿 • クラウドネイティブ会議 Day 1~2登壇予定（2026/5/14～2026/5/15） プラットフォームチーム ID基盤チーム
3. © 2026 Mizuho Bank, Ltd. はじめに 2 プラットフォームの概要 • アジリティが求められる DX・内製開発向けの社内プラットフォーム • 社内へセキュアな AWS アカウントを迅速に提供 • 多数の AWS マルチアカウントを運用しており、認証基盤は Entra ID を活用 登場人物は3チーム ID基盤チーム • 認証基盤 Microsoft Entra ID を管理・提供 プラットフォームチーム • AWS 共通機能の 設計・運用 • AWS アカウントの提供 プロダクトチーム • 提供された AWS 上で アプリを開発・運用
4. © 2026 Mizuho Bank, Ltd. プラットフォームと認証・認可の概要 3 Entra ID と AWS IAM Identity Center を SAML 連携し、シングルサインオンを実現 プロダクトチーム 担当者 サインイン ユーザーの所属グループに対して 許可されたAWSアカウントへアクセス SAML
5. © 2026 Mizuho Bank, Ltd. プラットフォームと認証・認可の概要 4 プラットフォームチームは事前に AWS の認可設定を作業 プラットフォーム チーム担当者 事前作業 以下の組み合わせでアクセス権を制御 【グループ（誰が）】×【AWS アカウント（どこに）】× 【許可セット（何ができるか）】
6. © 2026 Mizuho Bank, Ltd. プラットフォームと認証・認可の概要 5 Entra ID グループにユーザーを追加することで、AWS アクセス権を付与 ユーザー追加 Entra ID グループへのメンバー追加運用（権限付与）は頻繁に発生 権限管理者
7. 権限付与の課題 6
8. © 2026 Mizuho Bank, Ltd. 権限付与の課題 7 【課題】新メンバ―が AWS 環境へアクセスするのに最大3営業日かかる （現状の申請フロー） 何が問題？ • 案件増加に伴って AWS アカウント数が増え続け、メンバー入替も頻繁に発生 • SSO で即アクセスできる設計なのに、申請確認・作業がボトルネック • インシデント対応ですぐにアクセスしたい場合も申請経由になってしまう 1.申請 プロダクトチームが グループのメンバー 追加・削除を申請 2. 確認・変更作業 プラットフォームチームが 申請内容を確認後、 Entra ID 上で作業を実施 3. 反映完了 作業完了連絡 ※最大3営業日の 待ち時間が発生
9. © 2026 Mizuho Bank, Ltd. 解決方針 8 【方針】申請をなくし、役割の定義と人のアサインを分離する 申請フローの改善を行ったものの、ボトルネックは消えなかった… （例：ID 基盤チームからプラットフォームチームへ Entra ID 権限の委譲、 AWS 側の制御変更など） 権限管理の責務を分離する 役割の定義（何ができるか） プラットフォームチームが統制 • 許可セットの確認・適用（申請を維持） • グループ/AWS アカウント/許可セットの紐づけ 人のアサイン（誰がその役割を持つか） プロダクトチームに委譲（セルフサービス化） • グループへのメンバー追加・削除 ※Entra ID を直接触らせて高頻度作業を委譲 （操作範囲は厳密に限定） 組織として実績のある委譲パターンを応用 申請フローの改善ではなく、一部の申請をなくすことに
10. © 2026 Mizuho Bank, Ltd. B部署グループ A部署グループ 委譲パターンの補足 9 権限付与の委譲については、社内ファイルサーバーの運用を参考 各部署に「アクセス権限管理者」を置き、部署内のフォルダアクセス権を委譲 アクセス権限 管理者 アクセス権限 管理者 A部署 フォルダ アクセス権付与 新人 配属初日に アクセスできた！ B部署 フォルダ 他部署へのアクセス権は付与できない 人のアサインを委譲する上記パターンを Entra ID × AWSの権限管理にも応用！ （上記の考え方に沿って、プロダクトチームごとに Entra ID 管理対象を限定して委譲）
11. © 2026 Mizuho Bank, Ltd. 技術的な考慮点 10 方針は決まったが、どうやって Entra ID で人のアサインを委譲する？ Entra ID の標準的な権限モデルでは、特定グループに絞った管理権限を付与できない エンタープライズアプリケーションの 所有者は全グループのメンバー入替可能 （委譲されたプラットフォームチームが管理） Entra ID の具体的な実現方法は ID 基盤チームの竹島より紹介！ プロダクトチームに 操作を委譲？ プロダクトチームに 運用を任せたいけど 権限が広すぎる…
12. 実現したこと 11
13. © 2026 Mizuho Bank, Ltd. 実現したこと 12 Microsoft Entra ID とは ◆Microsoft のクラウド向け ID・アクセス管理サービス（旧 Azure AD） ◆「誰が」「何にアクセスできるか」を一元管理する基盤
14. © 2026 Mizuho Bank, Ltd. 実現したこと 13 Entra ID の 管理者ロール について ◆ Entra ID では「管理者ロール」を人に割り当てて管理操作を許可する ◆ たとえばユーザー管理者、グループ管理者、認証管理者などがある ロール例 できること ユーザー管理者 ユーザーアカウントの作成・削除・属性変更 グループ管理者 グループの作成、グループ所有者・メンバーの管理 認証管理者 パスワードリセット・MFA リセット ヘルプデスク管理者 パスワードリセット（管理者以外）
15. © 2026 Mizuho Bank, Ltd. 実現したこと 14 従来の悩み：管理者ロールの効力範囲が広すぎる Entra ID テナント チームA 担当者 ユーザー 管理者 グループ 管理者 管理者ロールを割り当てると、自チームだけでなく、他チームのユーザー・グループも操作可能 ユーザー群 グループ群 ユーザー群 グループ群 チームA チームB チームC ユーザー群 グループ群
16. © 2026 Mizuho Bank, Ltd. 実現したこと 15 管理単位（Administrative Unit）で最初の一歩 ◆ ユーザーやグループを 論理的にまとめる 機能 ◆ この「箱」の 中だけ に効力を限定してロールを付与できる チームA チームA 担当者 ユーザー群 グループ群 チームB チームB 担当者 ユーザー群 グループ群 チームC チームC 担当者 ユーザー群 グループ群 ID基盤 管理者 Entra ID テナント
17. © 2026 Mizuho Bank, Ltd. 実現したこと 16 委譲した範囲（渡したもの） ◆ 頻度が高く、待ち時間がアジリティに直結する作業 ◆ すべて AU スコープ限定のため、テナント全体には影響しない 委譲対象 具体的な操作 グループ設定変更 AU 内グループの所有者・メンバー追加/削除 パスワードリセット AU 内ユーザーのパスワード再設定 MFA リセット AU 内ユーザーの多要素認証リセット
18. © 2026 Mizuho Bank, Ltd. 実現したこと 17 あえて委譲しない範囲（残したもの） ◆ 現行の ID 基盤運用を維持するため、以下操作は委譲していない 操作 理由 ユーザーアカウントの作成・削除 ID ライフサイクルの統制を維持 グループの新規作成 命名規則・構造の統制を維持
19. © 2026 Mizuho Bank, Ltd. 実現したこと 18 AU を使ったチーム内権限管理の実現 AU によりプラットフォームチームが自分達で一次対応できるようになり、アジリティが大きく改善 Entra ID AU (プロダクトA） プロダクトA 管理者 ユーザー群 グループ群 ID基盤 チーム メンバーアカウント① 管理アカウント ユーザー群 グループ群 Entra ID側も チーム内で 作業実施 スイッチ ロール メンバーアカウント② プロダクトA メンバーアカウント③ 基本は 見てるだけ プラットフォーム チーム
20. 権限を与えて大丈夫なの？ ~ 委譲を「安全に回す」ためのセーフティネット~ 19
21. © 2026 Mizuho Bank, Ltd. セーフティネット編 20 3つのセーフティネット RAU 管理単位を保護 職務分離 事前の統制 監査ログ 操作の可視化 「誰が何をしたか」を記録 事中〜事後 棚卸し 権限・対象の定期点検 肥大化を防ぐ 定期
22. © 2026 Mizuho Bank, Ltd. セーフティネット編 21 通常AUでは防げない穴がある ◆ ID 基盤チームの管理作業中に、プロダクトチームのユーザー・グループ情報を 誤操作で変更してしまうリスクがある ◆ 金融系では職務分離も求められるため、「運用ルールで触らないことにしてい る」では、監査上で弱い場合も… 通常AU プロダクト チーム ユーザー群 グループ群 ID基盤チーム Entra ID テナント
23. © 2026 Mizuho Bank, Ltd. セーフティネット編 22 RAU（Restricted Management AU) が実現する技術的統制 ◆ 明示的に AU スコープ付きロールを割り当てられた管理者だけが変更可能 ◆ ID 基盤チームの管理者からの変更もブロック RAU プロダクト チーム ユーザー群 グループ群 ID基盤チーム Entra ID テナント Microsoft Entra ID の 機能「RAU」は 2025年6月に一般提供
24. © 2026 Mizuho Bank, Ltd. セーフティネット編 23 監査ログで変更の可視化と追跡 ◆ 「いつ・誰が・何をしたか」 をすべて記録済 ◆ RAUへの操作に関しても、ロール割り当て自体も監査ログに記録される ◆ SIEM製品へのログ集約・アラートルールを施し、チェックは半自動 チェック例 見ているもの スコープ逸脱 想定外の対象に対して、操作していないか （グループ作成など） 運用外 予定外時間帯（平日夜間帯など）に、権限 付与等の管理作業が実施されていないか ログ基盤 アラートルール アラートルール
25. © 2026 Mizuho Bank, Ltd. セーフティネット編 24 棚卸し ◆ 権限や対象が 「いつの間にか広がる」 のを止める ◆ 権限を渡すだけではいつか事故が起きる… 継続的に健全化を施す ◆ チェック作業自体は、内製スクリプトで半自動化 チェック例 見ているもの 方法 管理者ロール 異動・退職等で、不要な人が残っていないか？ 1. サインオン履歴の確認 2. 本人へ通達・調整 AU 内の対象 ユーザー/グループは想定通りか？ 1. 申請時の内容と、実際の リソースを突合
26. まとめ 25
27. © 2026 Mizuho Bank, Ltd. 26 まとめ AWS × Entra ID 環境で「権限付与」の改善を実施！ 権限付与のための「メンバー変更申請待ち」はゼロに！ 課題 申請経由の権限付与がボトルネック（最大3営業日待ち） やったこと Entra ID の管理単位でスコープを限定し、 権限付与をプロダクトチームへ委譲（セルフサービス化） セーフティネット RAU＋ 監査ログ ＋ 棚卸し で統制を維持 権限委譲とセーフティネットはセット！ 「渡す設計」と「縛る設計」を同時に行うことで アジリティと統制を両立させています