こんにちは、ひろかずです
前回に引き続き、書いていきます。
例によって、ヒアリング能力ゼロの上にリアルタイム執筆なので、いろいろ勘弁してください。
SEC324 - IAM for Enterprises: How Vanguard Matured IAM Controls to Support Micro Accounts
前提知識の解説
まず、IAMの入門からassume roll、STS、Permission Boundary(アクセス許可の境界)、IAM管理の委譲、SCPの基本、ポリシーの評価順序についてざざっと解説がありました。
IAMの入門として、認証の流れの解説
STS Assume Rollの流れの解説
SAMLを使ったIDフェデレーションの流れの解説
管理者権限の委譲の解説
- ステップ１
- アカウントAdminは、Permission BoundaryでCloudTrailのBucketに対するアクセスを拒否する設定を入れる
- ステップ２
- アカウントAdminは、CompanyBoundaryが指定されている場合のみ、iamロールの作成を許可するアクセス許可ポリシーを作成します。
- 委任されたIAM Adminプリンシパルにアクセス許可ポリシーを添付します。
- ステップ１: 委任された管理者は、委任されたIAM Adminプリンシパルにアクセス許可ポリシーを添付します。
- ステップ２: 委任された管理者向けに、s3のフルアクセス権を持つ許可ポリシーを作成します
- ステップ３: 委任された管理者向けに、新しく作成したRollにポリシーをアタッチします
- Permission Boundaryで許可した操作と、許可ポリシーで許可されている操作が重なったアクションを行うことができます
- この例では、委任された管理者はs3のフルアクセス権を持っていますが、CloudTrailのログ格納Bucketは削除できないという設定になります。
Service Control Policy(SCP)の解説
- SCPは各OUで設定することができますが、AWSアカウントローカルの管理者は、その制限を上書きすることはできません
- SCPとPermission Boundaryで許可した操作、および許可ポリシーで許可されている操作が許可されます。
ポリシーの評価順序の解説
ゴールとして
- DevOpsでは、減速機構を平らにして、プロダクトをマーケットに安全に迅速に出すことができる
- 伝統的なIAMでは、誰がいつ行っているのか、どこから来ているのかを監査する
- 未来のIAMでは、体系的にユーザーを境界内に保つ
Vanguard社ではどうやっているか
フェデレーションアクセスの話
2016年のVanguard社の構成はこんなだったようです
- 複数のAWSアカウントをOrganizationでまとめていたようですね
フェデレーションアクセスで、LDAP RollとAWS Rollを1:1にしてたので...
新しいアカウントのために新しくマッピングをしなければならず...
こんなになっちゃいました
ちなみに、2016年ではこのようなSTSを使っていたようです。
そこでCloud Registry Serviceをつくりました。
今ではこのようなSTSを使っています
DevOpsにまつわる権限の話
よくある光景
- s3 Bucketを作成して
- IAM Rollを作成して
- 特定のs3バケットをリソースとして持つ役割に関するIAMポリシーを設定して
- そのIAM Rollだけにアクセスを制限するよう、Bucket Policyを設定する
新しいアカウントごとの共通の役割はこんなもんですよね
- 特権系
- 開発系
ちょっと、画像が容量制限に引っかかってしまったようです。
続きは後ほど書きます！