Slide 1

Slide 1 text

STORES 株式会社 AWS OrganizationsとIAM Identity Center, Terraformを連携した権限管理 2022/12/13 STORES Tech Talk AWS Organizations活用のリアル登壇資料 プロダクト基盤本部 SRE 藤原 涼馬

Slide 2

Slide 2 text

自己紹介 2 藤原 涼馬 STORES株式会社 プロダクト基盤本部 SRE (他にもいろいろ) 経歴  SIer R&D →      → 趣味  自動車の運転  模型製作  各種寄稿・登壇 好きなAWSサービス  ECS Fargate / AWS IAM Identity Center + 他 今ここ

Slide 3

Slide 3 text

● 今回話すこと ○ AWS Organizations + AWS IAM Identity Center導入の経緯 ○ AWS Organizationsの説明 ○ AWS IAM Identity Centerの説明 ○ 上記構成の実際の運用 ● 話さないこと ○ 個別具体的な実装詳細

Slide 4

Slide 4 text

AWS Organizations + IAM Identity Center導入の経緯

Slide 5

Slide 5 text

沿革 5 2008/10/10 設立 2012/3/23 設立

Slide 6

Slide 6 text

沿革 6 2008/10/10 設立 2012/3/23 設立 2013/10/10 設立 ヘイ株式会社へ経営統合及び ホールディングス化 2018/2/1 設立

Slide 7

Slide 7 text

沿革 7 2008/10/10 設立 2012/3/23 設立 2013/10/10 設立 2020/1/30 ヘイ株式会社へ経営統合及び ホールディングス化 経営統合及び ヘイ株式会社傘下へ 2020/9/1 サービスブランド統合 2018/2/1 設立

Slide 8

Slide 8 text

沿革 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 株式会社へ社名変更

Slide 9

Slide 9 text

沿革 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 株式会社へ社名変更

Slide 10

Slide 10 text

気になりポイント 10 いずれのサービスもAWSをプロダクトの基盤として利用しています

Slide 11

Slide 11 text

気になりポイント 11 いずれのサービスもAWSをプロダクトの基盤として利用しています おや?


Slide 12

Slide 12 text

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


Slide 13

Slide 13 text

これによって発生しうる問題 1. ガバナンスの問題 2. セキュリティの問題 3. コスト的な問題 ○ ボリュームディスカウント的な観点でロスが発生する 13 参考)https://www.ntt-tx.co.jp/column/tec/cloud_v11n/190917/

Slide 14

Slide 14 text

これによって発生しうる問題 1. ガバナンスの問題 2. セキュリティの問題 3. コスト的な問題 ○ ボリュームディスカウント的な観点でロスが発生する 14 参考)https://www.ntt-tx.co.jp/column/tec/cloud_v11n/190917/

Slide 15

Slide 15 text

ガバナンスの問題 ユーザー権限の棚卸しを横断で実施する際に大変すぎる 15 AWS アカウント1 AWS アカウント2 AWS アカウント3 AWS アカウント4 AWS アカウントN-1 AWS アカウントN

Slide 16

Slide 16 text

ガバナンスの問題 ユーザー権限の棚卸しを横断で実施する際に大変すぎる 16 AWS アカウント1 AWS アカウント2 AWS アカウント3 AWS アカウント4 AWS アカウントN-1 AWS アカウントN 各種監査や離任・着任対応コストの増加 (主に工数的な観点で)

Slide 17

Slide 17 text

これによって発生しうる問題 1. ガバナンスの問題 2. セキュリティの問題 3. コスト的な問題 ○ ボリュームディスカウント的な観点でロスが発生する 17 参考)https://www.ntt-tx.co.jp/column/tec/cloud_v11n/190917/

Slide 18

Slide 18 text

セキュリティの問題(IAMユーザーの利用) 単一AWSアカウントだとIAMユーザーの利用 (コンソールログイン & アクセスキーの利用)に傾きがち 18 まあMFAは
 設定できるけど...


Slide 19

Slide 19 text

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


Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

解決手段としてのAWS OrganizationとAWS IAM Identity Center AWS Organizations と AWS IAM Identity Center で解決を図ります 21

Slide 22

Slide 22 text

AWS Organizationsの概要

Slide 23

Slide 23 text

AWS Organizations 複数のAWSアカウントをまとめて管理するための仕組みです 23 管理AWSアカウント AWSアカウント1 AWSアカウント2 AWSアカウントN …

Slide 24

Slide 24 text

AWS Organizations 複数のAWSアカウントをまとめて管理するための仕組みです 24 管理AWSアカウント AWSアカウント1 AWSアカウント2 AWSアカウントN … 複数アカウントをまとめてボリュームディスカウントが効くようになります e.g. S3バケット内オブジェクトのストレージ料金

Slide 25

Slide 25 text

AWS Organizations 複数のAWSアカウントをまとめて管理するための仕組みです 25 管理AWSアカウント AWSアカウント1 AWSアカウント2 AWSアカウントN … AWSアカウントN+1

Slide 26

Slide 26 text

AWS Organizations 複数のAWSアカウントをまとめて管理するための仕組みです 26 管理AWSアカウント AWSアカウント1 AWSアカウント2 AWSアカウントN … AWSアカウントN+1 容易にAWSアカウントを払い出すことができるようになります (他にもorganization一括でさまざまなセキュリティ的な仕組みを導入したりといったことが容易になります)

Slide 27

Slide 27 text

AWS Organizationsまとめ ● 複数のAWSアカウントをまとめて管理 ● 同一Organizationsのアカウントで利用量が合算され さまざまなボリュームディスカウントが効く ● AWSアカウントの払い出しが容易に 27

Slide 28

Slide 28 text

AWS IAM Identity Centerの概要

Slide 29

Slide 29 text

AWS IAM Identity Center (旧 AWS SSO) AWS IAM Identity Centerをポータルとして、 複数のAWSアカウントにログインすることができます※ 29 ※ 他のサービスへのSSOも実現可能ですが今回はスコープ外とします AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center SSO
 サイコー


Slide 30

Slide 30 text

AWS IAM Identity Center (旧 AWS SSO) AWS IAM Identity Centerをポータルとして、 複数のAWSアカウントにログインすることができます※ 30 ※ 他のサービスへのSSOも実現可能ですが今回はスコープ外とします AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center SSO
 サイコー
 権限割り当ては ここで集約管理

Slide 31

Slide 31 text

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による開発者体験の維持 と 権限割り当ての集約管理によるガバナンス改善を実現

Slide 32

Slide 32 text

AWS IAM Identity Center (旧 AWS SSO) 期間限定のアクセスキーを生成 & 取得できます (ブラウザからの取得 & AWS CLIからの取得) 32 Webブラウザでの取得 AWS CLI(v2) での取得 $ aws sso login --profile プロファイル名

Slide 33

Slide 33 text

AWS IAM Identity Center (旧 AWS SSO) 期間限定のアクセスキーを生成 & 取得できます (ブラウザからの取得 & AWS CLIからの取得) 33 Webブラウザでの取得 AWS CLI(v2) での取得 $ aws sso login --profile プロファイル名 永続的なアクセスキーを不要にすることでセキュリティ面のリスク緩和を実現

Slide 34

Slide 34 text

AWS IAM Identity Centerまとめ ● SSOによる開発者体験の維持 ● 権限管理を集約することによるガバナンス改善 ● 期間限定のアクセスキーによるセキュリティリスク緩和 34

Slide 35

Slide 35 text

ここまでのまとめ 1. AWS Organizationを導入 ○ 複数アカウント総計でのボリュームディスカウントの適用(コストメリット) ○ アカウント払い出しの容易化(業務プロセスの単純化) 2. AWS IAM Identity Centerを導入 ○ SSOによる複数AWSアカウントへのログイン容易化(開発者体験の改善) ○ 権限管理の集約 (ガバナンスの改善) ○ 期間限定のアクセスキー生成 & 取得(セキュリティリスク緩和) 35

Slide 36

Slide 36 text

ここまでのまとめ 1. AWS Organizationを導入 ○ 複数アカウント総計でのボリュームディスカウントの適用(コストメリット) ○ アカウント払い出しの容易化(業務プロセスの単純化) 2. AWS IAM Identity Centerを導入 ○ SSOによる複数AWSアカウントへのログイン容易化(開発者体験の改善) ○ 権限管理の集約 (ガバナンスの改善) ○ 期間限定のアクセスキー生成 & 取得(セキュリティリスク緩和) 36 以降はSTORES社内でどう運用しているか?を解説

Slide 37

Slide 37 text

STORES社内でのAWS Organizationsと AWS IAM Identity Centerの活用

Slide 38

Slide 38 text

AWS Organization ● AWSアカウント払出 ○ rootメールアドレス ■ Google Workspaceのグループメールアドレス + サフィックスで払出を容易化 ○ アカウントそのものはTerraformでIaC化 38

Slide 39

Slide 39 text

AWS Organization ● AWSアカウント払出 ○ rootメールアドレス ■ Google Workspaceのグループメールアドレス + サフィックスで払出を容易化 ○ アカウントそのものはTerraformでIaC化 ■ PRベースでAWSアカウントを管理 39

Slide 40

Slide 40 text

AWS Organization ● AWSアカウント払出 ○ rootメールアドレス ■ Google Workspaceのグループメールアドレス + サフィックスで払出を容易化 ○ アカウントそのものはTerraformでIaC化 ■ PRベースでAWSアカウントを管理 40 素朴 & シンプル (plan/applyを自動化したいなどはある)

Slide 41

Slide 41 text

AWS IAM Identity Center (こちらがメイン) 考えなければいけないこと 1. 権限割り当ての管理 2. 入社・退職・離着任管理 41

Slide 42

Slide 42 text

AWS IAM Identity Center (こちらがメイン) 考えなければいけないこと 1. 権限割り当ての管理 2. 入社・退職・離着任管理 42

Slide 43

Slide 43 text

権限管理 ● AWSアカウント(≒ STORESのサービス)ごとに権限を管理 ○ 管理主体は個々のサービスのSREが中心に対応 ○ 権限(権限セット)の定義とユーザへの割当は全社で集約管理(GitHub上のリポジトリに集約) ○ Terraformを利用 43

Slide 44

Slide 44 text

権限管理 ● AWSアカウント(≒ STORESのサービス)ごとに権限を管理 ○ 管理主体は個々のサービスのSREが中心に対応 ○ 権限(権限セット)の定義とユーザへの割当は全社で集約管理(GitHub上のリポジトリに集約) ○ Terraformを利用 44 個別のAWSアカウントご とにどの権限を

Slide 45

Slide 45 text

権限管理 ● AWSアカウント(≒ STORESのサービス)ごとに権限を管理 ○ 管理主体は個々のサービスのSREが中心に対応 ○ 権限(権限セット)の定義とユーザへの割当は全社で集約管理(GitHub上のリポジトリに集約) ○ Terraformを利用 45 誰に割り当てているか? を一眼でわかるように

Slide 46

Slide 46 text

AWS IAM Identity Center (こちらがメイン) 考えなければいけないこと 1. 権限割り当ての管理 2. 入社・退職・離着任管理 46

Slide 47

Slide 47 text

入社・退職・離着任管理 特に退職後はさわれないようにしたい (残る側、退職する側双方のためにも) 47

Slide 48

Slide 48 text

入社・退職・離着任管理 特に退職後はさわれないようにしたい (残る側、退職する側双方のためにも) 48 誰が一番リアルな情報を 持っているか?


Slide 49

Slide 49 text

入社・退職・離着任管理 特に退職後はさわれないようにしたい (残る側、退職する側双方のためにも) 49 誰が一番リアルな情報を 持っているか?
 社内ITを司るokta!

Slide 50

Slide 50 text

AWS IAM Identity Centerの構成(STORESの場合) oktaを認証に挟むことで入社・退職への対応を容易に 50 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center

Slide 51

Slide 51 text

AWS IAM Identity Centerの構成(STORESの場合) oktaを認証に挟むことで入社・退職への対応を容易に 51 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か? ログインさせて良いか?

Slide 52

Slide 52 text

AWS IAM Identity Centerの構成(STORESの場合) oktaを認証に挟むことで入社・退職への対応を容易に 52 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か? ログインさせて良いか? 認可
 どのアカウントに どの権限でアクセス させてよいか?

Slide 53

Slide 53 text

AWS IAM Identity Centerの構成(STORESの場合) 退職者はどうなるか? 53 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か? ログインさせて良いか? 認可
 どのアカウントに どの権限でアクセス させてよいか? 認証を通過できなくなるので、認可側で慌てて対応をする必要はなくなる (とはいえちゃんと棚卸し & 削除は必要)

Slide 54

Slide 54 text

AWS IAM Identity Centerの構成(STORESの場合) 認可部分の設定はTerraformでIaC化(先述の通り) 54 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か? ログインさせて良いか? 認可
 どのアカウントに どの権限でアクセス させてよいか?

Slide 55

Slide 55 text

なぜoktaに認証、認可両方をよせないのか? 1. okta … 社内ITとしての管理(非プロダクト開発ITエンジニア含) 2. AWSアカウント … プロダクト開発ITエンジニアのみ 55 AWSアカウント1 AWSアカウント2 AWSアカウントN … 認証
 認可
 この情報って
 どちらの管理
 でしたっけ?
 どっちだったか なぁ...


Slide 56

Slide 56 text

なぜoktaに認証、認可両方をよせないのか? 1. okta … 社内ITとしての管理(非プロダクト開発ITエンジニア含) 2. AWSアカウント … プロダクト開発ITエンジニアのみ 56 AWSアカウント1 AWSアカウント2 AWSアカウントN … 認証
 認可
 この情報って
 どちらの管理
 でしたっけ?
 どっちだったか なぁ...
 oktaの管理が社内ITとプロダクト開発組織の間で混ざってポテンヒットを避けたい 組織ごとに管理すべきものの境界を明確に定めたい

Slide 57

Slide 57 text

AWS IAM Identity Centerの構成(STORESの場合)(再掲) oktaを認証に挟むことで入社・退職への対応を容易に 57 AWSアカウント1 AWSアカウント2 AWSアカウントN … AWS IAM Identity Center 認証
 この人は誰か? ログインさせて良いか? 認可
 どのアカウントに どの権限でアクセス させてよいか?

Slide 58

Slide 58 text

入社・着任の対応 入社・退職・離任・着任の対応(認可部分) これもGitHubのPRを起点に実施 58 退職・離任の対応

Slide 59

Slide 59 text

入社・着任の対応 入社・退職・離任・着任の対応(認可部分) これもGitHubのPRを起点に実施 59 退職・離任の対応 定型的にかつ確実 & アジリティ高く人の出入りに対応できるようにしています。 権限を追加、削除される ユーザーアカウントが一目瞭然

Slide 60

Slide 60 text

まとめ ● STORESでは a. AWS Organizationsを導入して コスト・ガバナンスの問題の解決を測りました b. AWS IAM Identity Center + oktaの組み合わせを活用して 開発者体験とセキュリティ、ガバナンスの総取りを目指しました 60

Slide 61

Slide 61 text

時間が余ったら補足) 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