SSO方式とJumpアカウント方式の比較と設計方針

Transcript

1. SSO方式とJumpアカウント方式の比較と設計方針 2025年12月11日 NRIネットコム株式会社 デジタルソリューション事業本部 クラウド事業推進部 大林 優斗
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 登壇者：大林 優斗 ◼ 受賞歴 ⚫ 2025 Japan AWS Top Engineer (Services) ⚫ 2024 Japan AWS Jr. Champion ◼ AWS認定資格 ◼ 書籍執筆 自己紹介 ◼ ブログ執筆 ◼ NRI Netcom BLOG：https://tech.nri- net.com/archive/author/y-obayashi ◼ 登壇活動 ⚫ NRIネットコム主催の外部向け勉強会(TECH & DESIGN STUDY) ⚫ JAWS-UG朝会 ⚫ JAWS Days 2025 ⚫ 他社で開催される勉強会 ⚫ 登壇資料：https://speakerdeck.com/yuobayashi
3. 2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します なぜ今このテーマなのか
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 多くのAWS環境では、アカウント数の増加とともに以下の議論が必ず発生します。 ◼ 「Jumpアカウント経由でアクセスするべきか」 ◼ 「SSOに全面移行すべきか」 実際の環境を見てみると、以下の状況になっている環境が多くあります。 ◼ セキュリティだけでSSOが選ばれている ◼ 既存運用の延長でJumpが残り続けている ◼ 両方が混在して統制が取れない ➢SSO方式とJumpアカウント方式を比較し、最終的にどのように意思決定すべきかを整理します。 なぜ今このテーマなのか
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します Jumpアカウント方式
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 概要 Jumpアカウント方式 ◼ Jumpアカウント方式は以下のステップを踏む。 ① 利用者はまず Jumpアカウントにログイン ② そこから各業務用アカウントへ AssumeRole で横断アクセス Jumpアカウント IAM ユーザー 開発環境 Role
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 採用されるパターン Jumpアカウント方式 AWSアカウントが増えてきたが、IAMユーザーの作成を最小限にしたい。 Jumpアカウント IAM ユーザー 開発環境 検証環境 本番環境 Role Role Role
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 課題 Jumpアカウント方式 ① アカウントが増えるほどロール爆発＋設定破綻 ⚫ 30アカウント → 30ロール ⚫ 100アカウント → 100ロール ⚫ 500アカウント → 人的管理が物理的に不可能 ② Jumpが“特権ゾーン”になりやすい ⚫ 本来は単なる経由点のはずが ⚫ 「何でもできる管理特権」が集中する ⚫ 結果：侵害されたら全滅構成 ③ 属人化が極端に進む ⚫ 誰がどのアカウントに入れるのか分からない ⚫ 設計者しか構成を理解していない ⚫ 異動・退職で 即ブラックボックス化 Jumpアカウント アカウントA Role Role アカウントB Role アカウントC Role Role Role ・ ・ ・
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します SSO方式
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 概要 SSO方式 SSO方式とは、 ⚫ 組織のIdP（Entra ID / Okta / Google Workspace など）と連携 ⚫ 利用者は 1回の認証で複数AWSアカウントに直接ログイン ⚫ 権限は グループ × ロールの割当で集中管理 という方式。 AWS IAM Identity Center ユーザー 開発環境 検証環境 本番環境 Role Role Role
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 設計のポイント①：IdPの選定 SSO方式 ◼ IdP は「誰が」「どのグループに属しているか」の一次情報源 ⚫ 社員・協力会社・業務委託などの種別もここで管理する ◼ AWS 側ではユーザーを新たに増やさず、IdP を唯一の認証基盤にする ◼ グループ設計は「組織・職務」ベースで行い、 ⚫ プロジェクトごとにバラバラにグループを作らせない ◼ 入社／異動／退職などのライフサイクルは ⚫ HR → IdP → IAM Identity Center の順に自動反映させる ◼ MFA・条件付きアクセス・デバイス制限など、 ⚫ 「ログインしてよい条件」は IdP 側で統制する ◼ 逆に、AWS 内での具体的な権限内容は許可セット／IAM ロール側で持つ ⚫ IdP は「誰か」、Identity Center は「どこに・どのロールで入るか」を担当
12. 11 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 設計のポイント②：許可セット SSO方式 ◼ Identity Center の許可セットは「認可のハブ」 ⚫ どのユーザー／グループが ⚫ どの許可セットで ⚫ どのアカウント or OU にアクセスするか ◼ ユーザーやグループに直接権限を持たせない ⚫ 「ユーザー／グループ → 許可セット → アカウント」の3段階で管理 ◼ 許可セットは「職務ロール × 環境」を意識して設計する ⚫ 例：開発者用／運用者用／参照専用 × 開発／検証／本番 ◼ プロジェクトごとに許可セットを乱立させず、組織共通のパターンにまとめておく 職務 環境 Role
13. 12 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します IAM Identity Centerを最大限活用するために SSO方式 IAM Identity Centerだけではカバーしきれないこと・脆弱性を生むこともある。 ◼ 利用者が「自分の権限範囲を超えた操作」を申請ベースで一時的に実行したい ◼ 操作ごとに「承認フロー」を通したい ◼ プロジェクト単位・一時対応・緊急作業の権限を時間を指定して制御したい ◼ 最小権限を実現するために、許可セットだけではカバーしきれない範囲をSCPやRCPで何とか制御しようとするが、ポリ シーの数が増加して、思わぬ脆弱性を生む可能性がある 開発環境 Role 管理アカウント AWS IAM Identity Center AWS Organizations SCP RCP 検証環境 Role SCP RCP
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します TEAMの活用
15. 14 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 概要 TEAMの活用 Just-In-Time Access 的な考え方を採り入れた仕組み。 ◼ 一時的アクセス ◼ 承認付きアクセス ◼ 作業単位での権限付与 ◼ 作業終了と同時に自動剥奪 一般ユーザー 検証環境 Role TEAM AWS IAM Identity Center 管理ユーザー ①アクセス申請 ②アクセス許可
16. 15 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します リクエスト時に必要な情報 TEAMの活用 ◼ Email（リクエスト者） ◼ Account（ elevated access を行いたいAWSアカウント） ◼ Role（許可セットに紐づくElevated Role） ◼ Start time（権限の付与開始日時） ◼ Duration（権限を使用できる時間） ◼ Ticket no（チケット番号） ◼ Justification（ビジネス上の理由） 引用：https://aws-samples.github.io/iam-identity-center-team/docs/overview/architecture.html
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します 構成 TEAMの活用 TEAMのコードはGitHubに公開されている。サーバレスなAWSサービスで構成されている。 引用：https://aws-samples.github.io/iam-identity-center-team/docs/overview/architecture.html
18. 17 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します まとめ
19. 18 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ Jump方式とSSO方式は「どちらが正解」ではない ◼ 重要なのは、「誰に」、「どんな権限を」、「どの範囲で」、「どの期間で」付与したいのかを整理すること ◼ 組織の規模・成熟度・制約条件に応じた設計が必要 ◼ SSOは長期運用・大規模環境ほど真価を発揮する ◼ TEAMは承認フローを組み込んだSSOを実現できる まとめ