スタートアップがAWSを使う時にやりたいこと(アカウントとユーザー管理編)

Transcript

1. スタートアップこそ AWSアカウントを ええ感じに管理しよ! AWS Startup Tech Meetup Online #2
2. 1988年⽣まれ∕⼤阪府出⾝ webエンジニア、情シス、CSIRTを経て 現在株式会社オークンで情シスのお姉さんをし てます。好きなAWSサービスは、GuardDuty, AWS
   Organizations,
   AWS
   SSO O-KUN, Inc. Business IT SUMI SHIOMI suemin_jp
3. 社名
   :
   株式会社オークン 代表
   :
   ⼭下 亮 設⽴
   :
   2015年3⽉ 従業員
   :
   26名
   (2021年2⽉時点) 事業内容
   :
    ファンド向け⾦融商品開発  Webサービス開発  ソフトウェア開発  など
4. 素晴らしいプロダクトを 世の中に出したい ⽇のおはなし 情シスとして⼤事にしていること
5. 最⾼のプロダクトにするために エンジニアがプロダクト開発に 全集中できる環境を整える 情シスとして⼤事にしていること
6. 組織でAWSを 利⽤するってなったら やっておきたいこと アカウントとユーザーの管理編
   
7. 組織でAWSを 利⽤する上で 避けられない問題
8. マルチアカウント 管理
10. マルチ アカウントの ベスト プラクティス
11. ⽤: AWS におけるマルチアカウント 理の⼿ とベストプラクティス https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T2-2.pdf
12. スタートアップで 最初からこれが 考慮されているか
13. アイデアに 気づく 仲間を 集める プロトタイプ つくる ローンチ する
14. 理想
15. 現 もしくはOrganizations で 理されていない場 も。 とりあえず まとめるために つかってみた
16. この状 のまま が⼤きくなると 何が きるか
17. アカウント SCP もいい じにあてられん…
18. 件A prod 件B dev / stg なんかよく わかんない やつ 件B prod ⽤ 件 アカウントの⽬的が ⾏ 不 件C dev Account - A Accout - B Account - C この 件のリソースは どのアカウントなんだぁぁぁぁぁ 件別に まとめるのが ⼤ だぁぁぁぁ さらに
19. 開発効率  
20. こうなると Organizationsを 再設計し直すのは めっちゃしんどい
22. ユーザー 理 の 題 それに えて
23. やりがちなユーザー管理 1⼈の利⽤者に対して、 IAMユーザを各アカウントに個別に作成 パスワードを覚えるのが⾯倒 MFAも⾯倒 IDの棚卸しも⾯倒 ID + Pass + MFA ID + Pass + MFA ID + Pass + MFA
24. パスワードポリシーが 超 めんどくさい パスワードポリシーが超 しい 半⾓英⼩ 半⾓英⼤ 半⾓ 20 桁 上 使い回し禁⽌ さらにMFA 制 これがアカウントごとに。。
25. した の IAM ユーザの アクセスキー が プログラムの中で使われていた したA さんの IAM ユーザを消したら プログラムが動かなく なっちゃったんだよね〜 えー まじっすかー 開発 情シス
26. 開発どころじゃない
28. アカウントとユーザーは ちゃんと 理した がいい
29. ⼩ 模なうちなら いい じに えやすい
30. に何を やっておくべきなのか について えてみた そうならない ために...
31. AWSアカウントは ⽬的別に作成する
32. ガバナンス 課⾦ 組織 運⽤ 本番環境と⾮本番環境を管理するメンバーとで 明確な権限の分離 環境間におけるセキュリティ対策の分離が可能 アカウント毎に明確な課⾦管理ができる アカウントの請求をまとめられる 案件や部⾨などの業務ユニットごとにアカウン トを払い出して独⾃のポリシーで運⽤ができる 特定のアカウントへ権限を委譲することも可能 構成変更時の影響範囲のを⼩さくする リソースの上限を気にせず利⽤できる AWSアカウント分割のポイント
33. TAG
    :
    dev TAG
    :
    poc_A TAG
    :
    verify TAG
    :
    pj_A TAG
    :
    dev TAG
    :
    pj_B TAG
    :
    verify TAG
    :
    poc_B 管理側 開発側
34. OU
    設計は AWS
    Organizations 全体の核⼼
35. AWS
    Organizationsの基本的なOU構成
36. 組織で共有されるインフラサービス セキュリティ監査ログなど AWS
    Organizationsの基本的なOU構成
37. AWS
    Organizationsの基本的なOU構成 AWSのサービスを学んだり試したりするために利⽤
    社内ネットワークから切り離して構築 ⼀定の料⾦制限を設定して使いすぎを防⽌
38. AWS
    Organizationsの基本的なOU構成 顧客向けアプリケーションや バックエンドプロセスなど
39. AWS
    Organizationsの基本的なOU構成 SCPを利⽤して アカウント/OU全体に 禁⽌事項の設定 予防的統制
40. IAMユーザーは 作らない
41. AWSにおけるユーザー管理 1⼈の利⽤者に対して、 IAMユーザを各アカウントに個別に作成 パスワードを覚えるのが⾯倒 MFAも⾯倒 IDの棚卸しも⾯倒 アカウントの数だけ多重苦に陥ってしまう
42. AWSにおけるユーザー管理 踏み台からロールを切り替えて 各AWSアカウントの操作権限を取得 接続先のアカウントで付与される権限の管理は 各AWSアカウントのIAMで個別にロールを作成し メンテナンスする必要がある
43. AWSにおけるユーザー管理 せっかくなので
    Organizations
    を活⽤ AWS
    SSOでマネージドに実現
44. AWS
    SSO
    なら
    マネコンへのアクセスが楽
45. AWS
    SSO
    なら
    CLI
    も便利
46. AWS
    SSO
    はいいぞ
47. 的にこれでいくことにした
48. 果 ユーザーはアカウントへのアクセスが楽になり アカウントの切り替えも便利になった アカウントに紐づくグループごとに権限設定
    & AWS
    SSOで⼀元管理できてアクセス権管理が楽 IdPからユーザとグループがプロビジョニングされて ユーザーのメンテナンスがめっちゃ楽
49. でやりたいこと ステージ別にSCPを割り当てて 組織として⼀定のセキュリティレベルを担保 Config
    で
    IAM
    ユーザーの作成を監査
    & Cloud
    Trail
    で
    IAM
    ユーザーの使⽤を検知 監査ログを集約&活⽤ 結局
    Control
    Tower
    ってどうなん
50. アカウントはシステムの種類や環境別に分割して 開発者も管理者もみんなハッピー OU設計はAWS
    Organizations全体設計の核⼼ 早い段階で⼊念な検討を推奨。 AWS
    SSOはいいぞ
    まとめ
51. アカウントとユーザーを 早い段階で整理することで、 セキュアで良質な ガードレールを整えて 最⾼のプロダクトを世の中へ (後編) (前編)
52. THANK YOU. ⼤ オフィス オフィス 〒541-0043⼤阪府⼤阪市中央区⾼麗橋4-5-2⾼麗橋ウエストビル 〒812-0016福岡県福岡市博多区博多駅南1-4-18博多シティアークビル