背景
- AWSのアカウントサービス(IAMユーザー、IAMポリシー、IAMグループ、IAMロールあたり)の棲み分けが怪しかったためまとめてみる
AWSアカウントの全体像
- AWSには「AWSアカウント」と「IAMユーザー」と呼ばれる2種類のアカウントがある
- AWSアカウントは全てのサービスを利用可能でルートユーザーと呼ばれる
- IAMユーザーはAWSを利用する各利用者向けに作成するアカウントで、AWSアカウントによって作成される
AWSアカウント1/
├── IAMユーザー1
├── IAMユーザー2
└── IAMユーザー3
AWSアカウント2/
├── IAMユーザー3
└── IAMユーザー4
サマリ
- それぞれのサービスの特徴をざっくりと記載すると下記の通り
| サービス | 概要 |
|---|---|
| AWSアカウント | ルートユーザー 全てのサービスを利用可能(※) 各AWS利用者向けにIAMを作成する |
| IAMポリシー | 各AWSサービスの利用可否をポリシーとして設定し、IAMユーザーやIAMグループ、IAMロールへ付与する |
| IAMユーザー | AWSを利用するために各利用者へ割り当てられる認証情報 |
| IAMグループ | 同じ権限を持ったIAMユーザの集まり AWSへのアクセス認証は行わない |
| IAMロール | 一時的にAWSリソースへのアクセス権限を付与する |
| AWS Organizations | 複数のAWSアカウントを階層的にグループ化し一元管理 |
※AWS OrganizationsのSCPによって制限された機能は利用不可
AWSアカウント
- ルートユーザーと呼ばれる
- AWSの全サービスに対して操作可能な権限を持つため扱いには注意が必要
- AWSを利用して何かシステムを構築する場合は基本的にルートユーザーではなくIAMユーザーを使用する
- MFAの設定が推奨される
IAM
- 主要機能として下記の4つがあげられる
- IAMポリシー
- IAMユーザー
- IAMグループ
- IAMロール
IAMポリシー
- Action(どのサービスの)、Resource(どういう機能や範囲を)、Effect(許可/拒否する)という3つのルールを設定することでポリシーを作成
- 作成したポリシーをIAMユーザーやIAMグループ、IAMロールに付与することで各IAMユーザーの制御を実現
インラインポリシー
- 対象ごとに作成、付与を行うポリシー
例）
ユーザーAにはポリシーAを作成し付与
ユーザーBにはポリシーAとポリシーBを作成し付与
ユーザーCにはポリシーBとポリシーCを作成し付与
監視ポリシー
- 1つのポリシーを複数のユーザーやグループに対して適用
- 下記の2種類がある
- AWS管理ポリシー：AWSが用意しているポリシー
- カスタマー管理ポリシー：ユーザー自身で管理するポリシー
例）
ポリシーAを作成しユーザーAとユーザーBに適用
ポリシーBを作成しユーザーBとユーザーCに適用
ポリシーCを作成しユーザーCに適用
IAMユーザー
- AWSを利用するために各利用者へ1つずつ与えられる認証情報(ID)
- 人だけでなくAPIを呼び出したりCLIを実行したりする主体に対しても与えることが可能
- Webコンソールへのログイン時はユーザーIDとパスワードに加え、MFAの組み合わせが推奨される
- CLIやAPIでAWSリソースへアクセスする場合はアクセスキーとシークレットキーを使用
IAMグループ
- 同じ権限を持ったユーザの集まり
- AWSへのアクセス認証情報は保持しないため、認証はあくまで各ユーザーにて行う必要がある
- 認証されたユーザがどのような権限(サービスの利用可否など)を持っているかを管理
例）
部署A、部署B、部署Cではそれぞれ利用するAWSサービスが異なる場合
(各部署のユーザーは1人1つのIAMユーザーを所持)
IAMグループAには、部署AのユーザーのIAMユーザーを割り当てる
IAMグループB、Cも同様に部署B、Cのユーザーを割り当てる
これにより各IAMグループにてサービス利用可否を設定しておくことで、各IAMユーザー単位でサービス利用可否を設定する必要がなくなり運用負荷の軽減に繋がる
IAMロール
- 一時的にAWSリソースへのアクセス権限を付与する場合に利用
- 例えば下記のような場合に利用
- AWSリソースへの権限付与：EC2インスタンス上で稼働するアプリケーションに一時的にAWSリソースへアクセスする権限を付与したい
- クロスアカウントアクセス：複数のAWSアカウント間のリソースを1つのIAMユーザーで操作したい
- IDフェデレーション：社内のADに登録されているアカウントを使用してAWSリソースへアクセスしたい
- Web IDフェデレーション：FacebookやGoogleのアカウントを使用してAWSリソースへアクセスしたい
AWS Organizations
- 複数のAWSアカウントを階層的にグループ化しアカウント群の管理を一元的に実施
- グループにまとめることで請求書を1枚にまとめたり、それぞれのアカウントで利用可能なAWSサービスに制限をかけることが可能
- 組織内には請求アカウントとなる管理アカウントが存在し、その配下に組織単位(OU)と呼ばれる論理グループを作成することが可能
Organizationルート（管理アカウント）/
├── OU/
│ ├── OU/
│ │ ├── アカウントA
│ │ └── アカウントB
│ └── OU/
│ └── アカウントC
└── OU/
└── アカウントD
サービスコントロールポリシー（SCP）
- 組織のアカウントに対して特定の権限や操作の許可/拒否を設定可能
- IAMポリシーではIAMユーザーやIAMロールを対象とするのに対し、SCPではAWSアカウントを対象とするためより強い権限の設定が可能
- SCPで制限された機能を、IAMユーザーやIAMポリシーで許可することは不可
(許可しても使用不可) - ルートユーザーであっても制限される
- SCPで制限された機能を、IAMユーザーやIAMポリシーで許可することは不可