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

1. MultiVendor
2017.09.15(Fri)
Masamitsu Maehara
みんなが安全にクラウドを使うために考えた結果
セキュリティ勉強会#09

2. ⾃⼰紹介
l 前原 応光（まえはら まさみつ）
l Future Architect, Inc. (Technology Innovation Group)
l エンプラでAWSをゴニョゴニョやってますー
l 最近、いろんなログの意味付けを⽇々考えてますー
l ゆるふわエンジニア
@micci184

3. ⽬的
l マルチベンダでAWSを使うときの検討材料
l 何が正解かわからんのでベストプラクティスを知っている⼈
を探すヽ(*ﾟдﾟ)ノ

4. ！
個⼈的な⾒解を多く含んでるので
暖かい⽬でみてください！！

5. ！ AWSの話で構成しちゃってます

6. この中でマルチベンダで運⽤
している⼈いますか？

7. Attention
l 開発するための環境を提供する側のお話
l あくまで開発からステージングまで

8. どんな環境を作って
何を提供するかについて

9. やりたいこと
l 統合開発環境をつくりたい
l いろんなベンダが同じ環境を使いたい
l 多数のプロジェクトを取り扱う
l 開発⽤のアプリケーションを提供
l クラウドの利⽤権限を制御する
l AWS内で完結

10. 制約

11. AWSアカウントは1つ

12. ((((；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

13. l アカウント単位で権限を考えられる
l 事故率が減る
l お⾦の請求をアカウントに紐付けられる
l ..etc
アカウント分けるといいこと

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. Application
l ソース管理
l ライブラリ管理
l 成果物管理
l プロジェクト管理
l 品質管理
l CI
l コミュニケーションツール
..etc

16. l 可能な限り⾦額を抑えるため
l テスト領域をUSに配置
l Workspaces⾼いからオレゴンに配置
＃とくに問題なく利⽤できている
#USだと⽇本から近いオレゴンに配置
l 事故率を下げるため
なぜマルチリージョンか

17. MultiRegion
Tokyo
Ireland
Virginia
Oregon
l VDI接続
l テスト領域
l xx領域
l 管理領域
l PJ領域
l 各リーションをVyOSを利⽤してVPN接続

18. MultiVendor
AWS ONE Account
×

19. ここから
権限系に絞って話します！

20. l プロジェクトが⼀緒でも会社が違うのでインスタンスなどの
操作をさせたくない
l 会社が⼀緒でもプロジェクトが違ければインスタンスなどの
操作をさせたくない
l 可能な限り⾃由にAWSを使わせたい
l 使ったぶんを請求したい
制御したいこと

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. Vendor#01
l ベンダから作成依頼してもらい、内容確認し..
l タグとかポリシーとか..
l 構築..etc
Administrator
申請
受領
依頼書作成 受領
承認 構築 報告
やっと作業できる！
可能な限り⾃由
※フローは⼀例です

23. Vendor#01
l ベンダから作成依頼してもらい、内容確認し..
l タグとかポリシーとか..
l 構築..etc
Administrator
申請
受領
依頼書作成 受領
承認 構築 報告
やっと作業できる！
可能な限り⾃由

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. 限定したインスタンスタイプ
開発orステージング環境を選択
TemplateImage
固定AMI

26. ベンダ内で同じ権限で
リソースを使えるのは避けたい

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. Summary
l マルチベンダでAWSを1アカウントはやめたほうがいい
l 理由がない限りプロジェクト、サブシステム単位で分けた⽅がいい
l 事故とか請求とか..Orz
l 可能な限り⼈の⼿を⼊れないデザインにすること
l ⽇々、改善していく

29. Thanks