IAM Identity Centerを利用したAWSアカウントへの ログイン統制戦略 / Login Control Strategy for AWS Accounts Using IAM Identity Center

2025/9/13にJAWS-UG神戸×情シス支部コラボで発表した内容です。
IAM Identity Centerを利用したログイン統制について、ユーザー企業におけるAWS利用開始時からの5年間の間の変遷についてとその間にどのような施策をしてきたかについてお話ししました。

Transcript

1. IAM Identity Centerを利用した AWSアカウントへの ログイン統制戦略 JAWS-UG情シス支部×神戸支部 2025/9/13 山﨑 奈緒美
2. AWS SAMURAI 2015 JAWS-UGアーキテクチャ専門支部 JAWS-UG情シス支部 JAWS FESTA 2024 in 広島 副実行委員長 生活協同組合コープさっぽろ デジタル推進本部 システム企画部 インフラチーム 山﨑 奈緒美 ご挨拶と自己紹介 大阪出身。 就職で上京し、ソフトハウスでインフラエンジニア 地図情報システム開発会社でひとり情シス 旅行会社の情シス部門でクラウド担当 2020年9月に東京から札幌へ移住し10月よりコープさっぽろへJOIN。 AWSのことならなんでも担当。 @nao_spon I ♡ Route53 IAM Organizations 夏はロードバイク、冬はスノボしてます。仲間募集中！
3. 生活協同組合コープさっぽろについて （※2025年3月現在） 設立年月日 1965年7月18日 組合員数 205万人 （組合員組織率 83.4%） 出資金額 892億円 総事業高 3,219億円 職員数 15,864名 （契約職員・パートアルバイト含む） 店舗数 109店舗 移動販売車 97台 （137市町村） 宅配物流センター 43センター 9デポ 車両1,300台 配食工場 6工場（札幌、函館、苫小牧、旭川、釧路、帯広） 生産工場 石狩食品工場、江別食品工場、はまなす食品、江別物流センター 生鮮センター（ＰＣ）、ドリームファクトリー（函館）
4. 生活協同組合コープさっぽろ コープさっぽろは60周年を迎えました!!
5. 60周年企画の一例 5
6. 生活協同組合コープさっぽろについて
7. コープさっぽろのAWSアカウント
8. IAM Identity Centerユーザー数
9. 430 OverのAWSアカウント 約1300ユーザーの AWS SSO ログイン管理
10. AWSアカウント / ログイン について
11. AWSアカウント戦略 • システム単位でAWSアカウントを分離する • 1システムにつき本番、検証、開発環境用のAWSアカウントを用意する ◦ システムによっては本番、開発のみのパターンもあり • Organizationで管理しており、Control Tower Account Factoryで 子アカウントの発行をしている • AWSアカウント発行についてはリセラー側で行っている
12. IAM Identity Centerとの連携について • GoogleWorkspaceをIdPとし、IAM Identity CenterとSAML連携 ◦ ユーザー/グループのプロビジョニングはssosyncを利用 ◦ ssosync: https://github.com/awslabs/ssosync • 当初はLambdaで実行していたが現在はEC2で実行 ◦ ユーザー数の増加に伴い、15分以上かかるようになった ◦ グループの新規追加時に1回の実行で終わらないため ShellScriptでログ確認して完了していない場合はリトライさせる • 2023年にユーザーの自動プロビジョニングができるようになったが グループはプロビジョニングされないため使用していない
13. マネジメントコンソールへのログインについて • マネジメントコンソールへログインするユーザー： ◦ デジタル推進本部職員（インフラT、内製開発者、運用担当者 ◦ 外部ベンダー（各業務チーム所属のSES、構築案件委託ベンダー • 外部ベンダーも複数社あり • チーム所属のSESも複数社に渡る
14. デジタル推進本部発足当初（2020年〜2022年前半頃） インフラチーム 職員 A社 宅配チーム 職員 A社 店舗チーム 職員 A社 B社 アプリチーム 職員 受注管理システム D社へ委託 店舗基幹システム E社へ委託 ALL職員で
 内製開発
 MGNでAWS移行
 MGNでAWS移行
 AWSわかりません
 AWSわかりません
 AWSやっていき！
 ※他にもチームはありますが割愛しています ※社名のアルファベットはイニシャルではありません
15. デジタル推進本部発足当初（2020年〜2022年前半頃） 2020年9月〜 • OrganizationsでAWSアカウント管理はしていたが 各AWSアカウントへのログインはIAMユーザーで個別にログイン • AWS Single Sign-On（SSO）が東京リージョンで利用可能になった • AWS SSOの導入準備開始 2021年10月〜 • AWS SSO利用開始 • マネジメントコンソールへのログインはインフラチームに限定 • QuickSightへのログインも同時に可能に • 内製開発エンジニアは引き続きIAMユーザーによるログイン 2022年1月 • 内製開発エンジニアのSSOログイン開始
16. 2022年後半頃〜現在 インフラチーム 職員 A社 C社 宅配チーム 職員 A社 店舗チーム 職員 A社 B社 アプリチーム 職員 A社 B社 H社 個人事業主 受注管理システム D社へ委託 店舗基幹システム E社へ委託 配達ルートシステム G社へ委託 惣菜受発注システム F社へ委託 職員だけでは
 足りなくなった
 MGNでAWS移行
 MGNでAWS移行
 AWSやっていき！
 AWSやっていき！
 統制しないと...🥶
 サーバーレス！
 サーバーレス！！
 ※他にもチームはありますが割愛しています ※社名のアルファベットはイニシャルではありません
17. 2022年後半〜に何が起きたか 総AWSアカウント数 236 オンプレ移行用AWSアカウント 88 新規システム用AWSアカウント 91 インフラ共通基盤用AWSアカウント 30 その他用AWSアカウント 9 EC2インスタンス数 273 RDSインスタンス数 58 2022年6月時点の状況
18. 2022年後半〜に何が起きたか • インフラチームだけではAWSリソースの運用がまわらなくなってきた ◦ 業務チーム運用担当者にもマネコン操作を解放 ◦ まずはEC2のSTART/STOP/REBOOT、S3アクセスから ◦ 運用担当者のAWS習熟度に応じて解放範囲は広げる予定 • 内製開発チームに外部ベンダーからのメンバーがJOIN • 業務チームにも内製開発エンジニアがJOIN • 外部委託でのシステム構築でサーバーレスアーキテクチャ採用 ◦ それまではEC2をOS渡しで構築するパターンばかりだった
19. 2022年後半〜に何が起きたか インフラチームと内製開発者・ベンダー間のリソース作成の責任分界点 作業項目 インフラチーム 内製開発者 ベンダー AWSアカウント発行申請・セットアップ ◦ × VPC/Subnet作成（必要な場合） Transit Gateway接続 ◦ × Route53レコード登録 ◦ × システム稼働に必要なリソース作成 ◦ ◦ IAMユーザー作成 ◦ × IAM Role作成 ◦ △
20. ログイン権限を分けた Permission set 権限 対象者 Admin AdministratorAccess インフラチーム Builders AdministratorAccess IAMUser/IAMRole/VPC/NW系はDeny 内製開発者 Operators START/STOP/REBOOT EC2, S3アクセス 業務チーム運用担当者 Vendor AdministratorAccess IAMUser/IAMRole/VPC/NW系はDeny 外部ベンダー ReadOnly ReadOnlyAccess 上記全員 ※Deny項目はPermissions boundaryで制限
21. Permissions boundaryによる制限 • IAMユーザー、IAM Roleを自由に作れると抜け道ができてしまう • IAMユーザー作成はインフラTへ依頼 • IAM Roleは作成時に指定のIAM PolicyをPermissions boundaryに セットする場合のみ作成・削除・変更可能とした • CDKでは明示的にIAM Roleを作成し、リソースへアタッチ • 指定のIAM PolicyはStackSetsで全アカウントへ配布 https://qiita.com/f-daiki/items/e435159db6bde4d0c0ec
22. 各Permission setを関連づけるアカウント Permission set 対象者 ログイン対象 Admin インフラチーム 全アカウント Builders 内製開発者 自チームが担当するアカウント Operators 業務チーム運用担当者 自チームが担当するアカウント Vendor 外部ベンダー 各社が担当するアカウント
23. 各Permission setを関連づけるIICグループ Permission set IICグループ ログイン対象 Admin インフラチームグループ 全アカウント Builders 内製開発者グループ 自チームが担当するアカウント Operators 宅配チームグループ 受注管理システム (D社へ委託 配達ルートシステム (G社へ委託 店舗チームグループ 店舗基幹システム (E社へ委託 惣菜受発注システム (F社へ委託 Vendor F社グループ 惣菜受発注システム (F社へ委託 G社グループ 配達ルートシステム (G社へ委託
24. 各Permission setを関連づけるアカウント
25. QuickSightへのログインについて • GoogleWorkspaceをIdPとし、IAM Identity CenterとSAML連携 • QuickSightへログインするユーザー： ◦ 店舗、宅配、食品工場、物流等の現場部門職員 ◦ マーケティング部、経理部、商品部職員 ◦ データチームメンバー
26. QuickSightへのログインについて • QuickSightへはIICからさらにApplication assignmentsでログイン ◦ ログイン時にIAM Roleの権限をフェデレーションしている • QuickSight側のユーザープロビジョニングはStepFunctionsで別途実施 ◦ IICではQuickSightとの自動プロビジョニング機能が当時は無かった • QuickSightでは自部門の分析やダッシュボードのみアクセスさせる ◦ QuickSightのグループで管理
27. QuickSightへのログインについて
28. QuickSightへの初回アクセス時
29. QuickSightユーザープロビジョニングStepFunctions
30. http://bit.ly/44E52Kz 資料はこちら
31. Step Functions稼働後にアップデートきた
32. Step Functions稼働後にアップデートきた 担当SAさん 担当SAさん
33. QuickSightのIICとの統合の実施判断 • 2023年8月にQuickSightでIICとの統合がされ直接連携可能に ◦ それよりも前に作られたQuickSightは対象外→作り直しが必要 ◦ 既に数百の帳票、データソースが登録されているため移行困難 ◦ QuickSightユーザー数も1000 Overなので業務影響大
34. ウチのQuickSightに 生えてくるまで待とう...
35. ログイン周りについての今後の課題 • Builders権限のチーム分割 • Operators権限で許可する権限の拡大 ◦ 教育もセットで込み • Builders権限・Operators権限の判断基準の明確化 ◦ Operators権限の拡大で良いケースもあるかもしれない • Permissions boundaryの拒否権限チューニング • 既存QuickSightのIICとの統合のAWSへのリクエストがんばる
36. まとめ • ログイン時の権限、ロール設計を最初にしておくことは大事 • 組織やシステムを取り巻く状況の変更に合わせて見直すことが超大事 ◦ AWSアカウント/AWSリソースの増加 ◦ 新サービスの追加 ◦ ユーザーからのフィードバック ◦ メンバーのAWS習熟度のレベルアップ