Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

みんなが安全にクラウドを使うために色々考えた結果

736 views

Published on

セキュリティ勉強会9回目の発表資料
テーマは、クラウド権限

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

みんなが安全にクラウドを使うために色々考えた結果

  1. 1. MultiVendor 2017.09.15(Fri) Masamitsu Maehara みんなが安全にクラウドを使うために考えた結果 セキュリティ勉強会#09
  2. 2. ⾃⼰紹介 l 前原 応光(まえはら まさみつ) l Future Architect, Inc. (Technology Innovation Group) l エンプラでAWSをゴニョゴニョやってますー l 最近、いろんなログの意味付けを⽇々考えてますー l ゆるふわエンジニア @micci184
  3. 3. ⽬的 l マルチベンダでAWSを使うときの検討材料 l 何が正解かわからんのでベストプラクティスを知っている⼈ を探すヽ(*゚д゚)ノ
  4. 4. ! 個⼈的な⾒解を多く含んでるので 暖かい⽬でみてください!!
  5. 5. ! AWSの話で構成しちゃってます
  6. 6. この中でマルチベンダで運⽤ している⼈いますか?
  7. 7. Attention l 開発するための環境を提供する側のお話 l あくまで開発からステージングまで
  8. 8. どんな環境を作って 何を提供するかについて
  9. 9. やりたいこと l 統合開発環境をつくりたい l いろんなベンダが同じ環境を使いたい l 多数のプロジェクトを取り扱う l 開発⽤のアプリケーションを提供 l クラウドの利⽤権限を制御する l AWS内で完結
  10. 10. 制約
  11. 11. AWSアカウントは1つ
  12. 12. ((((;゚Д゚)))ガクガクブルブル
  13. 13. l アカウント単位で権限を考えられる l 事故率が減る l お⾦の請求をアカウントに紐付けられる l ..etc アカウント分けるといいこと
  14. 14. l 固定の拠点からだけでなく、様々な場所からアクセス可能 l マルチリージョンで構成 Configuration Tokyo Region VPC@MGR Private Subnet Public Subnet VPC@DEV Private Subnet Public Subnet VPC@STG Private Subnet Public Subnet VendorA Oregon Region VPC Public Subnet Private Subnet Ireland Region VPC Virginia Region VPC VendorB VendorN ・・・ Public Subnet Public Subnet Private Subnet Private Subnet WorkSpacesを利⽤ Internet 開発⽤アプリ設置
  15. 15. Application l ソース管理 l ライブラリ管理 l 成果物管理 l プロジェクト管理 l 品質管理 l CI l コミュニケーションツール ..etc
  16. 16. l 可能な限り⾦額を抑えるため l テスト領域をUSに配置 l Workspaces⾼いからオレゴンに配置 #とくに問題なく利⽤できている #USだと⽇本から近いオレゴンに配置 l 事故率を下げるため なぜマルチリージョンか
  17. 17. MultiRegion Tokyo Ireland Virginia Oregon l VDI接続 l テスト領域 l xx領域 l 管理領域 l PJ領域 l 各リーションをVyOSを利⽤してVPN接続
  18. 18. MultiVendor AWS ONE Account ×
  19. 19. ここから 権限系に絞って話します!
  20. 20. l プロジェクトが⼀緒でも会社が違うのでインスタンスなどの 操作をさせたくない l 会社が⼀緒でもプロジェクトが違ければインスタンスなどの 操作をさせたくない l 可能な限り⾃由にAWSを使わせたい l 使ったぶんを請求したい 制御したいこと
  21. 21. ControlPolicy#01 l IAM PolicyでAWSリソース制御 l リソース制御を会社、プロジェクトとタグを設定 l 請求もタグで制御 l サーバからのAWSリソースへのアクセスは、IAM Roleで制御 Vendor-A Vendor-B Vendor-A Vendor-B Delete Delete Delete Vendor-A Vendor-B Vendor-A Vendor-B Put Put Put Policy: Vendor Project: Project Company: Vendor
  22. 22. Vendor#01 l ベンダから作成依頼してもらい、内容確認し.. l タグとかポリシーとか.. l 構築..etc Administrator 申請 受領 依頼書作成 受領 承認 構築 報告 やっと作業できる! 可能な限り⾃由 ※フローは⼀例です
  23. 23. Vendor#01 l ベンダから作成依頼してもらい、内容確認し.. l タグとかポリシーとか.. l 構築..etc Administrator 申請 受領 依頼書作成 受領 承認 構築 報告 やっと作業できる! 可能な限り⾃由
  24. 24. ControlPolicy#02 l ベンダに提供するサービスをCloudFormationのテンプレート で提供(選べるインスタンスタイプやAMIを限定) l タグは、すべて埋め込んでおく(ユーザは意識しない) l テンプレートは指定のS3バケットに配置 Vendor-A Vendor-B Vendor-A Vendor-B Vendor-A Vendor-A Policy: Vendor Project: Project Company: Vendor EC2-Template RDS-Template ..etc CloudFormation CloudFormation
  25. 25. 限定したインスタンスタイプ 開発orステージング環境を選択 TemplateImage 固定AMI
  26. 26. ベンダ内で同じ権限で リソースを使えるのは避けたい
  27. 27. IAM Role & AD l 会社単位のADグループとIAM Roleをマッピング l ADグループに管理者と⼀般ユーザグループを作成 l AWSやOSもADで⼀元管理 Vendor-MemberA LoginPage : Role-Vendor-Admins : Role-Vendor-Users = : Vendor-Users : Vendor-Admins Login Authentication AWS Directory Service
  28. 28. Summary l マルチベンダでAWSを1アカウントはやめたほうがいい l 理由がない限りプロジェクト、サブシステム単位で分けた⽅がいい l 事故とか請求とか..Orz l 可能な限り⼈の⼿を⼊れないデザインにすること l ⽇々、改善していく
  29. 29. Thanks

×