AWS OrganizationsとIAM Identity Center, Terraformを連携した権限管理

STORES Tech talk AWS Organizations活用のリアル
(https://hey.connpass.com/event/268026) の登壇資料です。

Transcript

1. STORES 株式会社 AWS OrganizationsとIAM Identity Center, Terraformを連携した権限管理 2022/12/13 STORES Tech Talk AWS Organizations活用のリアル登壇資料 プロダクト基盤本部 SRE 藤原 涼馬
2. 自己紹介 2 藤原 涼馬 STORES株式会社 プロダクト基盤本部 SRE (他にもいろいろ) 経歴 　SIer R&D →　　　　　　→ 趣味 　自動車の運転 　模型製作 　各種寄稿・登壇 好きなAWSサービス 　ECS Fargate / AWS IAM Identity Center + 他 今ここ
3. • 今回話すこと ◦ AWS Organizations + AWS IAM Identity Center導入の経緯 ◦ AWS Organizationsの説明 ◦ AWS IAM Identity Centerの説明 ◦ 上記構成の実際の運用 • 話さないこと ◦ 個別具体的な実装詳細
4. AWS Organizations + IAM Identity Center導入の経緯
5. 沿革 5 2008/10/10 設立 2012/3/23 設立
6. 沿革 6 2008/10/10 設立 2012/3/23 設立 2013/10/10 設立 ヘイ株式会社へ経営統合及び ホールディングス化 2018/2/1 設立
7. 沿革 7 2008/10/10 設立 2012/3/23 設立 2013/10/10 設立 2020/1/30 ヘイ株式会社へ経営統合及び ホールディングス化 経営統合及び ヘイ株式会社傘下へ 2020/9/1 サービスブランド統合 2018/2/1 設立
8. 沿革 8 2008/10/10 設立 2012/3/23 設立 2013/10/10 設立 2020/1/30 2021/1/1 ヘイ株式会社へ経営統合及び ホールディングス化 経営統合及び ヘイ株式会社傘下へ 3社を吸収合併し提供サービス運 営会社をヘイに一本化 2020/9/1 サービスブランド統合 2012/5/22 設立 経営統合及び ヘイ株式会社傘下へ 2021/12/1 2018/2/1 設立 2022/10/1 社名変更 ヘイ株式会社から STORES 株式会社へ社名変更
9. 沿革 9 STORES 株式会社 は、ホールディングスと事業会社4社が集まった会社です。 2022年10月よりヘイ株式会社から STORES 株式会社に社名変更いたしました。 2008/10/10 設立 2012/3/23 設立 2013/10/10 設立 2020/1/30 2021/1/1 ヘイ株式会社へ経営統合及び ホールディングス化 経営統合及び ヘイ株式会社傘下へ 3社を吸収合併し提供サービス運 営会社をヘイに一本化 2020/9/1 サービスブランド統合 2012/5/22 設立 経営統合及び ヘイ株式会社傘下へ 2021/12/1 2018/2/1 設立 2022/10/1 社名変更 ヘイ株式会社から STORES 株式会社へ社名変更
10. 気になりポイント 10 いずれのサービスもAWSをプロダクトの基盤として利用しています
11. 気になりポイント 11 いずれのサービスもAWSをプロダクトの基盤として利用しています おや？

12. どうなっていたか 個社で別個にAWSアカウントを契約していました (元々別の会社なので当然) 12 そらそうよ
 もったいないがしゃー なし

13. これによって発生しうる問題 1. ガバナンスの問題 2. セキュリティの問題 3. コスト的な問題 ◦ ボリュームディスカウント的な観点でロスが発生する 13 参考)https://www.ntt-tx.co.jp/column/tec/cloud_v11n/190917/
14. これによって発生しうる問題 1. ガバナンスの問題 2. セキュリティの問題 3. コスト的な問題 ◦ ボリュームディスカウント的な観点でロスが発生する 14 参考)https://www.ntt-tx.co.jp/column/tec/cloud_v11n/190917/
15. ガバナンスの問題 ユーザー権限の棚卸しを横断で実施する際に大変すぎる 15 AWS アカウント1 AWS アカウント2 AWS アカウント3 AWS アカウント4 AWS アカウントN-1 AWS アカウントN
16. ガバナンスの問題 ユーザー権限の棚卸しを横断で実施する際に大変すぎる 16 AWS アカウント1 AWS アカウント2 AWS アカウント3 AWS アカウント4 AWS アカウントN-1 AWS アカウントN 各種監査や離任・着任対応コストの増加 （主に工数的な観点で）
17. これによって発生しうる問題 1. ガバナンスの問題 2. セキュリティの問題 3. コスト的な問題 ◦ ボリュームディスカウント的な観点でロスが発生する 17 参考)https://www.ntt-tx.co.jp/column/tec/cloud_v11n/190917/
18. セキュリティの問題(IAMユーザーの利用) 単一AWSアカウントだとIAMユーザーの利用 （コンソールログイン & アクセスキーの利用）に傾きがち 18 まあMFAは
 設定できるけど...

19. IAMユーザーを利用することによる問題 1. AWSアカウントごとに認証管理 2. (実質的に)永続的なアクセスキー 19 アカウントが増えるごとに増える 管理対象のID/パスワード/MFA 漏洩時の影響が大きい 開発者体験の悪化!
 セキュリティリスク

20. IAMユーザーを利用することによる問題 1. AWSアカウントごとに認証管理 2. (実質的に)永続的なアクセスキー 20 アカウントが増えるごとに増える 管理対象のID/パスワード/MFA 漏洩時の影響が大きい 開発者体験の悪化!
 セキュリティリスク
 IAMユーザーを利用することは 最早アンチパターン※ ※ 藤原の個人的見解です
21. 解決手段としてのAWS OrganizationとAWS IAM Identity Center AWS Organizations と AWS IAM Identity Center で解決を図ります 21
22. AWS Organizationsの概要
23. AWS Organizations 複数のAWSアカウントをまとめて管理するための仕組みです 23 管理AWSアカウント AWSアカウント1 AWSアカウント2 AWSアカウントN …
24. AWS Organizations 複数のAWSアカウントをまとめて管理するための仕組みです 24 管理AWSアカウント AWSアカウント1 AWSアカウント2 AWSアカウントN … 複数アカウントをまとめてボリュームディスカウントが効くようになります e.g. S3バケット内オブジェクトのストレージ料金
25. AWS Organizations 複数のAWSアカウントをまとめて管理するための仕組みです 25 管理AWSアカウント AWSアカウント1 AWSアカウント2 AWSアカウントN … AWSアカウントN+1
26. AWS Organizations 複数のAWSアカウントをまとめて管理するための仕組みです 26 管理AWSアカウント AWSアカウント1 AWSアカウント2 AWSアカウントN … AWSアカウントN+1 容易にAWSアカウントを払い出すことができるようになります （他にもorganization一括でさまざまなセキュリティ的な仕組みを導入したりといったことが容易になります）
27. AWS Organizationsまとめ • 複数のAWSアカウントをまとめて管理 • 同一Organizationsのアカウントで利用量が合算され さまざまなボリュームディスカウントが効く • AWSアカウントの払い出しが容易に 27
28. AWS IAM Identity Centerの概要
29. AWS IAM Identity Center (旧 AWS SSO) AWS IAM Identity Centerをポータルとして、 複数のAWSアカウントにログインすることができます※ 29 ※ 他のサービスへのSSOも実現可能ですが今回はスコープ外とします AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center SSO
 サイコー

30. AWS IAM Identity Center (旧 AWS SSO) AWS IAM Identity Centerをポータルとして、 複数のAWSアカウントにログインすることができます※ 30 ※ 他のサービスへのSSOも実現可能ですが今回はスコープ外とします AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center SSO
 サイコー
 権限割り当ては ここで集約管理
31. AWS IAM Identity Center (旧 AWS SSO) AWS IAM Identity Centerをポータルとして、 複数のAWSアカウントにログインすることができます※ 31 ※ 他のサービスへのSSOも実現可能ですが今回はスコープ外とします AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center SSO
 サイコー
 権限割り当ては ここで集約管理 SSOによる開発者体験の維持 と 権限割り当ての集約管理によるガバナンス改善を実現
32. AWS IAM Identity Center (旧 AWS SSO) 期間限定のアクセスキーを生成 & 取得できます （ブラウザからの取得 & AWS CLIからの取得） 32 Webブラウザでの取得 AWS CLI(v2) での取得 $ aws sso login --profile プロファイル名
33. AWS IAM Identity Center (旧 AWS SSO) 期間限定のアクセスキーを生成 & 取得できます （ブラウザからの取得 & AWS CLIからの取得） 33 Webブラウザでの取得 AWS CLI(v2) での取得 $ aws sso login --profile プロファイル名 永続的なアクセスキーを不要にすることでセキュリティ面のリスク緩和を実現
34. AWS IAM Identity Centerまとめ • SSOによる開発者体験の維持 • 権限管理を集約することによるガバナンス改善 • 期間限定のアクセスキーによるセキュリティリスク緩和 34
35. ここまでのまとめ 1. AWS Organizationを導入 ◦ 複数アカウント総計でのボリュームディスカウントの適用(コストメリット) ◦ アカウント払い出しの容易化(業務プロセスの単純化) 2. AWS IAM Identity Centerを導入 ◦ SSOによる複数AWSアカウントへのログイン容易化(開発者体験の改善) ◦ 権限管理の集約 (ガバナンスの改善) ◦ 期間限定のアクセスキー生成 & 取得(セキュリティリスク緩和) 35
36. ここまでのまとめ 1. AWS Organizationを導入 ◦ 複数アカウント総計でのボリュームディスカウントの適用(コストメリット) ◦ アカウント払い出しの容易化(業務プロセスの単純化) 2. AWS IAM Identity Centerを導入 ◦ SSOによる複数AWSアカウントへのログイン容易化(開発者体験の改善) ◦ 権限管理の集約 (ガバナンスの改善) ◦ 期間限定のアクセスキー生成 & 取得(セキュリティリスク緩和) 36 以降はSTORES社内でどう運用しているか？を解説
37. STORES社内でのAWS Organizationsと AWS IAM Identity Centerの活用
38. AWS Organization • AWSアカウント払出 ◦ rootメールアドレス ▪ Google Workspaceのグループメールアドレス + サフィックスで払出を容易化 ◦ アカウントそのものはTerraformでIaC化 38
39. AWS Organization • AWSアカウント払出 ◦ rootメールアドレス ▪ Google Workspaceのグループメールアドレス + サフィックスで払出を容易化 ◦ アカウントそのものはTerraformでIaC化 ▪ PRベースでAWSアカウントを管理 39
40. AWS Organization • AWSアカウント払出 ◦ rootメールアドレス ▪ Google Workspaceのグループメールアドレス + サフィックスで払出を容易化 ◦ アカウントそのものはTerraformでIaC化 ▪ PRベースでAWSアカウントを管理 40 素朴 & シンプル (plan/applyを自動化したいなどはある)
41. AWS IAM Identity Center (こちらがメイン) 考えなければいけないこと 1. 権限割り当ての管理 2. 入社・退職・離着任管理 41
42. AWS IAM Identity Center (こちらがメイン) 考えなければいけないこと 1. 権限割り当ての管理 2. 入社・退職・離着任管理 42
43. 権限管理 • AWSアカウント(≒ STORESのサービス)ごとに権限を管理 ◦ 管理主体は個々のサービスのSREが中心に対応 ◦ 権限(権限セット)の定義とユーザへの割当は全社で集約管理(GitHub上のリポジトリに集約) ◦ Terraformを利用 43
44. 権限管理 • AWSアカウント(≒ STORESのサービス)ごとに権限を管理 ◦ 管理主体は個々のサービスのSREが中心に対応 ◦ 権限(権限セット)の定義とユーザへの割当は全社で集約管理(GitHub上のリポジトリに集約) ◦ Terraformを利用 44 個別のAWSアカウントご とにどの権限を
45. 権限管理 • AWSアカウント(≒ STORESのサービス)ごとに権限を管理 ◦ 管理主体は個々のサービスのSREが中心に対応 ◦ 権限(権限セット)の定義とユーザへの割当は全社で集約管理(GitHub上のリポジトリに集約) ◦ Terraformを利用 45 誰に割り当てているか？ を一眼でわかるように
46. AWS IAM Identity Center (こちらがメイン) 考えなければいけないこと 1. 権限割り当ての管理 2. 入社・退職・離着任管理 46
47. 入社・退職・離着任管理 特に退職後はさわれないようにしたい (残る側、退職する側双方のためにも) 47
48. 入社・退職・離着任管理 特に退職後はさわれないようにしたい (残る側、退職する側双方のためにも) 48 誰が一番リアルな情報を 持っているか？

49. 入社・退職・離着任管理 特に退職後はさわれないようにしたい (残る側、退職する側双方のためにも) 49 誰が一番リアルな情報を 持っているか？
 社内ITを司るokta!
50. AWS IAM Identity Centerの構成(STORESの場合) oktaを認証に挟むことで入社・退職への対応を容易に 50 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center
51. AWS IAM Identity Centerの構成(STORESの場合) oktaを認証に挟むことで入社・退職への対応を容易に 51 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か？ ログインさせて良いか？
52. AWS IAM Identity Centerの構成(STORESの場合) oktaを認証に挟むことで入社・退職への対応を容易に 52 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か？ ログインさせて良いか？ 認可
 どのアカウントに どの権限でアクセス させてよいか？
53. AWS IAM Identity Centerの構成(STORESの場合) 退職者はどうなるか？ 53 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か？ ログインさせて良いか？ 認可
 どのアカウントに どの権限でアクセス させてよいか？ 認証を通過できなくなるので、認可側で慌てて対応をする必要はなくなる (とはいえちゃんと棚卸し & 削除は必要)
54. AWS IAM Identity Centerの構成(STORESの場合) 認可部分の設定はTerraformでIaC化(先述の通り) 54 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か？ ログインさせて良いか？ 認可
 どのアカウントに どの権限でアクセス させてよいか？
55. なぜoktaに認証、認可両方をよせないのか？ 1. okta … 社内ITとしての管理(非プロダクト開発ITエンジニア含) 2. AWSアカウント … プロダクト開発ITエンジニアのみ 55 AWSアカウント1 AWSアカウント2 AWSアカウントN … 認証
 認可
 この情報って
 どちらの管理
 でしたっけ？
 どっちだったか なぁ...

56. なぜoktaに認証、認可両方をよせないのか？ 1. okta … 社内ITとしての管理(非プロダクト開発ITエンジニア含) 2. AWSアカウント … プロダクト開発ITエンジニアのみ 56 AWSアカウント1 AWSアカウント2 AWSアカウントN … 認証
 認可
 この情報って
 どちらの管理
 でしたっけ？
 どっちだったか なぁ...
 oktaの管理が社内ITとプロダクト開発組織の間で混ざってポテンヒットを避けたい 組織ごとに管理すべきものの境界を明確に定めたい
57. AWS IAM Identity Centerの構成(STORESの場合)(再掲) oktaを認証に挟むことで入社・退職への対応を容易に 57 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か？ ログインさせて良いか？ 認可
 どのアカウントに どの権限でアクセス させてよいか？
58. 入社・着任の対応 入社・退職・離任・着任の対応(認可部分) これもGitHubのPRを起点に実施 58 退職・離任の対応
59. 入社・着任の対応 入社・退職・離任・着任の対応(認可部分) これもGitHubのPRを起点に実施 59 退職・離任の対応 定型的にかつ確実 & アジリティ高く人の出入りに対応できるようにしています。 権限を追加、削除される ユーザーアカウントが一目瞭然
60. まとめ • STORESでは a. AWS Organizationsを導入して コスト・ガバナンスの問題の解決を測りました b. AWS IAM Identity Center + oktaの組み合わせを活用して 開発者体験とセキュリティ、ガバナンスの総取りを目指しました 60
61. 時間が余ったら補足) AWS IAM Identity Centerの注目すべきアップデート AWS IAM Identity CenterはAWS SSOのリリース以降アップデートが続いており利便性は大幅に改 善されています以前検討して導入できなかった場合も今再検討すればいけるかもしれません 1. 東京リージョンにも対応 ◦ 以前はus-east-1のみでしたが、今はap-northeast-1でも利用できます 2. Announcing increased AWS IAM Identity Center default quota values ◦ IAM Identity Center単独（外部のIdPを利用しない場合）でも 10万ユーザーまで対応できるようになっています 3. Announcing new AWS IAM Identity Center (successor to AWS SSO) APIs to manage users and groups at scale ◦ 外部のIdPを頼らずともAPI経由でIAM Identity Centerのユーザーが作成できるようになっています 4. AWS Single Sign-On (AWS SSO) adds support for AWS Identity and Access Management (IAM) customer managed policies (CMPs) ◦ 権限セットとして割り当てられるのがインラインポリシー or AWS管理ポリシーのみでしたが、 カスタマー管理ポリシーの割り当ても可能になっています 61