組織観点から IAM Identity CenterとIAMの設計を考える

Transcript

1. 組織観点から IAM Identity CenterとIAMの設計を考える NRIネットコム TECH & DESIGN STUDY #78 2025年9月29日 NRIネットコム株式会社 執行役員 デジタルソリューション事業本部長 クラウドテクニカルセンター センター長 佐々木拓郎
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介 ◼ 2000年 4月 NRIネットコム株式会社入社 ◼ 現在 執行役員 デジタルソリューション事業本部長 クラウドテクニカルセンター センター長 佐々木拓郎 ◼ 執筆
3. 2 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRIネットコムのAWSへの取り組み APNアドバンスド コンサルティングパートナー 複数のAWS Award受賞者と 多数のAWS認定者資格 書籍&ブログ執筆
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. 関連書籍の紹介 2冊のIAM本とAWSアカウントセキュリティの本 IAMの設計を言語化するために 書いた本（2019年執筆） 組織の中でIAMをどう使うかを 書いた本（2025年執筆） AWSのアカウント管理の重要性を 書いた本（2025年執筆）
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWSアカウント管理の進化と課題 01 IAM Identity Centerの基本的な機能と用語 02 IAM Identity Center移行とIdPの選定ポイント 03 ガバナンスと権限設計のベストプラクティス 04 お知らせ 05
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. 1. AWSアカウント管理の進化と課題
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWSアカウント管理のよくあるケース 事業A用 AWSアカウント 事業B用 AWSアカウント 事業C用 AWSアカウント 他社A 請求代行サービス 他社B システム構築ベンダー 自社管理 事業部 マネジメント AWSアカウント 事業A用 AWSアカウント 事業B用 AWSアカウント 事業C用 AWSアカウント AWS Organizations 現状 あるべき姿 AWS Organizationsを導入しアカウント統合したものの、 その後どうしたらよいのか？ 課題 ・事業ごとにAWSアカウントの契約がされている ・管理主体が別々 ・統一されたセキュリティー/ガバナンスが効いていない
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. 個別AWSアカウントのアカウント管理のベストプラクティス IAMを利用して最小権限を実現する ⚫ IAMユーザーの最小化（IAMロール＆フェデレーションの推奨） ⚫ IAMポリシーの最小権限設計（リソースベースポリシー活用） ⚫ MFAの強制適用 ⚫ Rootアカウントの厳格管理 ⚫ IPアドレス制限≒使用場所制限は、結局必要になるケースが多い
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2025年時点のIAMのベストプラクティス 2019年 2025年 1 AWS アカウントのルートユーザーのアクセスキーをロックする 人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを 使用することを必須とする 2 個々のIAM ユーザーの作成 ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする 3 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 多要素認証 (MFA) を必須とする 4 最小権限を付与する 長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する 5 AWS 管理ポリシーを使用したアクセス許可の使用開始 ルートユーザーの認証情報を保護するためのベストプラクティスに沿う 6 インラインポリシーではなくカスタマー管理ポリシーを使用する 最小特権アクセス許可を適用する 7 アクセスレベルを使用して、IAM 権限を確認する AWS 管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する 8 ユーザーの強力なパスワードポリシーを設定 IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する 9 特権ユーザーに対してMFA を有効化する 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する 10 Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する IAM ポリシーで条件を指定して、アクセスをさらに制限する 11 ロールを使用したアクセス許可の委任 IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する 12 アクセスキーを共有しない IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する 13 認証情報を定期的にローテーションする 複数のアカウントにまたがるアクセス許可のガードレールを確立する 14 不要な認証情報を削除する アクセス許可の境界を使用して、アカウント内のアクセス許可の管理を委任する 15 追加セキュリティに対するポリシー条件を使用する 16 AWS アカウントのアクティビティの監視 17 IAM ベストプラクティスについてビデオで説明する 廃止 新規に追加
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWSマルチアカウント運用における課題 ➢退職者アカウントの放置 ➢過剰な権限の付与 ➢管理主体の曖昧さ 気合と根性ではなく、仕組みとして解決する
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. マルチアカウント運用移行後の、よくある課題 IAMユーザー中心の設計パターンとその限界 アカウントA アカウントB アカウントA ユーザーA シングルアカウント運用 マルチアカウント運用 ユーザーB ユーザーC ユーザーA ユーザーB ユーザーC ユーザーA ユーザーB ユーザーC 長期認証情報が持っていた潜在的課題 ⚫ 認証情報 ⚫ 認証と認可の密結合 ⚫ 大きすぎる権限 マルチアカウント化によって顕在化した課題 ⚫ IAMユーザー数の増大 ⚫ IAMユーザーの管理・運用負荷 IAMユーザー 認証 認可
12. 11 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAMユーザー管理最小化のための精一杯の対応（Switch Roleの活用） STS（Security Token Service）を使った一時的な認証情報の発行 ◆ ユーザもしくはロールから、別のアカウントのIAMロールに切り替える ◆ マルチアカウント環境の場合は、認証のみのアカウントを作成し、他アカウントへ切り替えて利用 する運用を取ることがある。IAMユーザー管理の最小化 IAM Role アカウントA ユーザー アカウントB S3 バケット スイッチロールし、 一時的な認可を得る 利用
13. 12 Copyright（C） NRI Netcom, Ltd. All rights reserved. Jampアカウントを使って、IAMユーザーの最小化 踏み台（Jump）アカウントを使った利用例 開発環境 ステージング環境 本番環境 Jumpアカウント ユーザー IAMロール IAMロール IAMロール
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. Switch RoleとJumpアカウントの問題点  ユーザーの管理主体の曖昧さ • 誰が管理するのか？ • 作成、削除のタイミング • 棚卸し  プロジェクト任せの権限管理 • 全体管理する仕組みの不在 • 利用履歴が分割管理 • いつでも本番環境を利用可能 ◼ Jumpアカウント ◼ Switchロール
15. 14 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAMユーザーの運用方針 • 2019年：「IAMユーザーは最小限、ロールを中心に」 • 2025年：「IAM Identity Centerを活用し、IAMユーザーをゼロに」 AWSも公式に、IAMユーザーの利用は非推奨と宣言
16. 15 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2. IAM Identity Centerの基本的な機能と用語
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAMユーザーの運用方針 IAM Identity Center IAM ユーザー管理 中央集約（外部IdP or 内部ディレクトリ） アカウントごとにIAMユーザーを個別作成 認証方式 SSO（SAML/OIDC） AWS認証情報（ID/パスワード or アクセスキー） 認可の定義 許可セット + IAMロール IAMポリシー（ユーザー、ロール、グループに付与） マルチアカウント対応 可能 基本は不可（クロスアカウントロール等で一定の対 応が可能） 推奨度 （2025年現在） 現在の推奨アプローチ 非推奨 IAM Identity Centerを使いながら、できるだけシンプルな設計を目指す
18. 17 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAM Identity Centerの概要 ユーザー IdP 内部IdP：IAM Identity Center 外部IdP：Okta,Entra ID, Etc IAMロール AWS IAM Identity Center 認証依頼 アカウント 一時的な認証情報 SAML token フェデレートされたユーザー 各種AWSリソース 操作 概念図
19. 18 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAM Identity Centerの主な用語 AWS IAM Identity Center インスタンス ワークフォースユーザー 許可セット アクセスターゲット AWSアカウント 一部のAWSのアプリケーション WorkSpaces QuickSight Grafana カスタムアプリケーション （SAML/OIDC対応） 利用者
20. 19 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3. IAM Identity Center移行とIdPの選定ポイント
21. 20 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAM Identity Center設計時の検討事項 主な設計のポイント • インスタンス/アイデンティティソースをどうするか？（≒IdPをどうするか） • 許可セットの設計 • SCIM連携（IdPからのユーザー情報の連携） 設計のポイントが、そのまま悩みのポイントになる
22. 21 Copyright（C） NRI Netcom, Ltd. All rights reserved. インスタンス/アイデンティティソースをどうするか？ インスタンスとアイディンティティソース ◼ インスタンス ⚫ 組織インスタンス ⚫ アカウントインスタンス ◼ アイディンティティソース ⚫ 内部ディレクトリ • IAM Identity Centerディレクトリ ⚫ 外部IdP • Microsoft Entra ID • Entra ID etc 内部 ： 外部 ： 許可セット （ ） 利用者 ンバーアカウント ロール ンバーアカウント ロール のユーザー ータ 認証 認証 認証 に、 のアカウントに の 利用 の のロールに ス ッ ット に ロールは に作 ここの部分 必ず組織インスタンスを選ぶ アイディンティティソースは、外部IdPがある場合は、それを使う
23. 22 Copyright（C） NRI Netcom, Ltd. All rights reserved. 許可セットの設計① Identity Centerの許可セットの役割 内部 ： 外部 ： 許可セット （ ） 利用者 ンバーアカウント ロール ンバーアカウント ロール のユーザー ータ 認証 認証 認証 に、 のアカウントに の 利用 の のロールに ス ッ ット に ロールは に作 ここの部分 どのユーザーもしくは どのグループが どの許可セットで どのアカウントもしくは どのOUにアクセスするのか
24. 23 Copyright（C） NRI Netcom, Ltd. All rights reserved. 許可セットの設計② 許可セットからIAMロールの作成 AWS IAM Identity Center インスタンス 許可セット アクセスターゲット 管理者用 許可セット 開発者用 許可セット 閲覧用 許可セット AWSアカウント IAMロール AWSReservedSSO_xxx_xxx 許可セットを雛形に、指定したアカウントにIAMロールを作成する 許可セットのIAMポリシーを変更した場合、作成済みのIAMロールのポリシーも更新される
25. 24 Copyright（C） NRI Netcom, Ltd. All rights reserved. IdP連携とSCIM連携の関係 IdP AWS IAM Identity Center 認証依頼 SAML token ユーザーA （手動作成） ◼ IdP連携のみ（認証情報のみ委譲） 管理者 ユーザーB ユーザーA IdPに対応する ユーザーを手動作成 ユーザーB 削除 自動で削除 されない ◼ SCIM連携のみ（ユーザ・グループの同期） IdP AWS IAM Identity Center 作成 ユーザーA （自動作成） ユーザーB （自動削除） ユーザーA ユーザーB 削除 自動で削除 されない 作成 AWSユーザーグループ
26. 25 Copyright（C） NRI Netcom, Ltd. All rights reserved. 4. ガバナンスと権限設計のベストプラクティス
27. 26 Copyright（C） NRI Netcom, Ltd. All rights reserved. Identity Centerの設計課題 ◼ 許可セット ⚫ 既存のIAMロールをどうするか？許可セット数の上限（2,000）※引き上げ可能 ⚫ 事前定義済みの許可セットの権限の粒度が粗い（IAMと同じ） ◼ IdP ⚫ IdPが１組織に１つし 設 きない（アカウント ンスタンス 除く） ⚫ IdP外のユーザー う管理 ？（外部パートナー等） ◼ SCIM連携とグループ管理 ⚫ 外部IdPと連携 場合は、SCIM連携 ユーザーやグループ情報 同期 能 ⚫ ットとグループの割当は、 ういうルール 管理 ◼ 管理・運用面 ⚫ IdPと ットとIAMロールの管理主体と役割分担 ⚫ IdPやIdentity Centerの障害に対して、 う対応 ？
28. 27 Copyright（C） NRI Netcom, Ltd. All rights reserved. 許可セットの課題 AWSアカウント IAMロール AWS IAM Identity Center 許可セット IAM Identity Center導入時に、AWSアカウントの既存IAMロールをどうするか？ ⚫ 既存IAMロールをそのまま許可セット化すると、大規模環境では管理が破綻する ⚫ 原則汎用の職能別の許可セット（管理者、開発者etc）を利用する ⚫ 例外ケースとして、個別のAWSアカウント用の許可セットを発行する ⚫ IaC化していると、管理の分担がしやすくなる ⚫ 上記設計に時間が掛かると、IAM Identity Centerへの移行が進まない
29. 28 Copyright（C） NRI Netcom, Ltd. All rights reserved. IdP外の外部ユーザーの対応 全てのユーザーがIdPにいる訳では無い ◼ 対応案 1. 外部ユーザーは該当のAWSアカウントにIAMユーザーとして作成する ⇒ 管理がプロジェクト任せのリスク 2. 外部ユーザーはJumpアカウントに、IAMユーザーとして作成する ⇒ 一元管理はできるが手間が大きい 3. 外部組織にIAMユーザーを作成してもらい、クロスアカウントロールを作成する ⇒ ユーザー管理が外部頼み 4. 外部ユーザーも必ずIdPに登録前提とする ⇒ IdP管理者との合意が難しい 5. 外部ユーザー用のIdPを用意する ⇒ 複数IdP対応の仕組みが必要 IdP ユーザーA ユーザーB 外部パートナー等 どう管理するのか？ 一長一短あり、組織の規模・管理状況によりベストが違う
30. 29 Copyright（C） NRI Netcom, Ltd. All rights reserved. 組織内に複数のIdPがある場合の対応 組織が大きい場合にIdPが別れているケースが多い（グループ会社など） ◼ 対応案 1. ハブ型で集約。ハブとして中心となるIdPを、Identity Centerと連携。他のIdPはハブIdPにSAMLフェデレーション 2. ブリッジ用のIdPを用意。ブリッジIdPは、各IdPのプロキシのような役割で、透過的にIdentity Centerと連携 3. Identity Centerと連携するIdPと、AWSアカウントのIAMロールへ直接フェデレーションするIdPの混在 IdP A ユーザーA ユーザーB 対応方法はあるものの、どれも対応コストが大きくなりがち IdP B ユーザーC ユーザーD IdP C ユーザーE ユーザーF
31. 30 Copyright（C） NRI Netcom, Ltd. All rights reserved. 本番環境へのアクセス可能な問題 開発環境 ステージング環境 本番環境 Jumpアカウント ユーザー IAMロール IAMロール IAMロール 本番環境にいつでもアクセス可能 になっているのが問題 ※IAM Identity Centerを 使っても、この問題は残る 常時アクセス可能にして良いのか？
32. 31 Copyright（C） NRI Netcom, Ltd. All rights reserved. TEAM等を使って、一時的な権限昇格の仕組みの構築 本番環境 Jumpアカウント or IAM Identity Center 利用者 （申請者） IAMロール AWSの場合（Microsoft Entra Privileged Identity Managementも製品ある） 承認者 承認後に権限が 発行され利用可能に アクセス申請の承認要求 監査人 管理者 システムの利用状況を ログから監査 申請ルールの管理
33. 32 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAM Identity Center + IdP+IAMロールをどう管理するか？ 認証認 コントロール ３つのサービスの管理主体がバラバラのケース が多い • IdPの管理主体：情報システム部（全社のID管理） • IAM Identity Center 管理 ット：CCoEな 横断組織 • 各アカウント 業主体が管理 IAMロール： 業部 IAM Identity Center IdP 各AWSアカウント Okta,Entra ID, Etc 権限セット アカウント内 生成の IAMロール IAMポリシー 権限セットから生 成される IAMロール 組織の実態・目指 姿 に、 う管理 の 検討 管理主体の問題 CCoE 情シス 各事業部の管理者
34. 33 Copyright（C） NRI Netcom, Ltd. All rights reserved. ３者での責任範囲の分解例 IAM Identity Center IdP 各AWSアカウント Okta,Entra ID, Etc 権限セット AWS IdPでログインした ユーザがスイッチす るロール CCoE 情シス 各事業部の管理者 Role Role 各事業部でアカウント内の 利用できるリソースを定義 権限セットを元に 利用するロールを管理 ユーザーの 認証情報のみ管理
35. 34 Copyright（C） NRI Netcom, Ltd. All rights reserved. 緊急アクセス用アカウント（Breakglassアカウント）の重要性 IdPやIAM Identity Center自体の障害に対しての対応の検討も必要 ユーザー IdP 内部IdP：IAM Identity Center 外部IdP：Okta,Entra ID, Etc IAMロール AWS IAM Identity Center 認証依頼 アカウント 一時的な認証情報 SAML token フェデレートされたユーザー 各種AWSリソース 操作 ここの障害に対する備え Breakglass用Jumpアカウント ユーザー
36. 35 Copyright（C） NRI Netcom, Ltd. All rights reserved. 5. お知らせ
37. 36 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWSアカウント管理のウェビナー マルチアカウント時代のAWSユーザー管理 IAM Identity Centerで“統制と利便性”を両立させる設計を実現するには！？ 【受講後に得られること】 ・ IAM Identity Centerの機能概要と設計のポイント ・自社の組織に応じた「中央集権/分散/ハイブリッド」運用モデルの選び方 ・監査・法令対応を見据えた証跡管理の体制と例外（ブレークグラス）設計 ・失敗しがちな設計・運用の見直しチェックリスト 【こんな方におススメです】 ・企業でAWSアカウントの管理を任されている方 ・AWSのセキュリティやガバナンスの対策を検討中の方 ・情報システム部門や情報セキュリティ部門、CCoEのご担当の方 https://nrinetcom.connpass.com/event/369781/ 9 月3 0 日（火） 1 2 : 0 0 ～1 3 : 0 0