re:invent2018に行ってきた(day3)

こんにちは、ひろかずです
前回に引き続き、書いていきます。

例によって、ヒアリング能力ゼロの上にリアルタイム執筆なので、いろいろ勘弁してください。

# SEC324 - IAM for Enterprises: How Vanguard Matured IAM Controls to Support Micro Accounts
## 前提知識の解説
まず、IAMの入門からassume roll、STS、Permission Boundary(アクセス許可の境界)、IAM管理の委譲、SCPの基本、ポリシーの評価順序についてざざっと解説がありました。

IAMの入門として、認証の流れの解説
![iOS の画像 (15).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/a0324bea-25a6-fbef-2847-cd866a66d8a1.jpeg)

STS Assume Rollの流れの解説

![iOS の画像 (16).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/3904e892-ddf9-ecd9-f633-11a4ee56ca95.jpeg)

SAMLを使ったIDフェデレーションの流れの解説

![iOS の画像 (19).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/fc097dac-954e-f293-5ac9-964f5e2924b4.jpeg)

管理者権限の委譲の解説

- ステップ１
- アカウントAdminは、Permission BoundaryでCloudTrailのBucketに対するアクセスを拒否する設定を入れる

![iOS の画像 (15).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/9ad690ca-9834-a26c-672b-d5694dab1463.jpeg)

- ステップ２
- アカウントAdminは、CompanyBoundaryが指定されている場合のみ、iamロールの作成を許可するアクセス許可ポリシーを作成します。
- 委任されたIAM Adminプリンシパルにアクセス許可ポリシーを添付します。

![iOS の画像 (16).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/e16415a8-8884-16d4-19e9-b51ba938d563.jpeg)

- ステップ１: 委任された管理者は、委任されたIAM Adminプリンシパルにアクセス許可ポリシーを添付します。
- ステップ２: 委任された管理者向けに、s3のフルアクセス権を持つ許可ポリシーを作成します
- ステップ３: 委任された管理者向けに、新しく作成したRollにポリシーをアタッチします

![iOS の画像 (18).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/2fae6c56-d67a-ca6d-3329-2ba6ef3eab46.jpeg)

- Permission Boundaryで許可した操作と、許可ポリシーで許可されている操作が重なったアクションを行うことができます
- この例では、委任された管理者はs3のフルアクセス権を持っていますが、CloudTrailのログ格納Bucketは削除できないという設定になります。

![iOS の画像 (15).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/24bedad5-63cc-0da4-c636-f800efcf1562.jpeg)

Service Control Policy(SCP)の解説

- SCPは各OUで設定することができますが、AWSアカウントローカルの管理者は、その制限を上書きすることはできません

![iOS の画像 (16).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/41f43fbf-5a95-4d9d-9f92-d60a1db5af88.jpeg)

- SCPとPermission Boundaryで許可した操作、および許可ポリシーで許可されている操作が許可されます。

![iOS の画像 (15).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/e2704016-0121-10ff-3089-0e50cea8d8f9.jpeg)

ポリシーの評価順序の解説

![iOS の画像 (15).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/8d8d7b46-a6f7-58fb-3b36-92081e8cad56.jpeg)

ゴールとして

- DevOpsでは、減速機構を平らにして、プロダクトをマーケットに安全に迅速に出すことができる
- 伝統的なIAMでは、誰がいつ行っているのか、どこから来ているのかを監査する
- 未来のIAMでは、体系的にユーザーを境界内に保つ

![iOS の画像 (16).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/7368b37c-a501-d415-28a9-5936855a2853.jpeg)

## Vanguard社ではどうやっているか
### フェデレーションアクセスの話
2016年のVanguard社の構成はこんなだったようです

- 複数のAWSアカウントをOrganizationでまとめていたようですね

![iOS の画像 (15).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/312559d4-dbf4-e7d6-4358-6d106dd904d7.jpeg)

フェデレーションアクセスで、LDAP RollとAWS Rollを1:1にしてたので...

![iOS の画像 (15).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/fbe8025d-d3d8-81f6-8c52-924302af363f.jpeg)

新しいアカウントのために新しくマッピングをしなければならず...

![iOS の画像 (16).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/3b2e620c-c3c6-8789-e744-2296ec3ded0d.jpeg)

こんなになっちゃいました

![iOS の画像 (17).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/87663fd0-2f65-8e55-5790-038754c1c6a3.jpeg)

ちなみに、2016年ではこのようなSTSを使っていたようです。

![iOS の画像 (16).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/84c256bc-3205-b0c1-248b-c9b721a4a121.jpeg)

そこでCloud Registry Serviceをつくりました。

![iOS の画像 (17).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/98d18208-eb4e-dddf-1eec-7bf282c2edb6.jpeg)

今ではこのようなSTSを使っています

![iOS の画像 (18).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/dd7c0f25-b3a1-cf92-c235-caffd1ce134d.jpeg)

### DevOpsにまつわる権限の話
よくある光景

- s3 Bucketを作成して
- IAM Rollを作成して
- 特定のs3バケットをリソースとして持つ役割に関するIAMポリシーを設定して
- そのIAM Rollだけにアクセスを制限するよう、Bucket Policyを設定する

![iOS の画像 (14).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/06a44b88-6b2a-6323-8bfa-ee6f2d789129.jpeg)

新しいアカウントごとの共通の役割はこんなもんですよね

- 特権系
- 開発系

![iOS の画像 (15).jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/3061b541-6ab7-a78b-d4de-064b8b58aba0.jpeg)

ちょっと、画像が容量制限に引っかかってしまったようです。
続きは後ほど書きます！