はじめに
AWSを利用する際、これまではIAMユーザーを作成し、アクセスキーやシークレットアクセスキーを使ってAWSにアクセスする方法が一般的だと思っていました。
しかし、最近 IAM Identity Center というサービスを知りました。
IAMユーザーとは何が違うのか、なぜIAM Identity Centerを使うのか。
今回は、AWS初心者の方向けに、IAM Identity Centerの基本的な仕組みやIAMユーザーとの違いを整理してみます。
IAM Identity Centerとは？
IAM Identity Centerは、複数のAWSアカウントへのアクセスを一元管理するためのサービスです。
簡単にいうと、一度のログインを入口として、許可された複数のAWSアカウントにアクセスできる仕組みです。
イメージとしては、次のような違いがあります。
- IAMユーザー：AWSアカウントごとに個別の鍵を持つ
- IAM Identity Center：共通の社員証を使って、許可された複数の部屋に入る
IAM Identity Centerにログインすると、アクセス権が割り当てられているAWSアカウントや権限セットを選択できます。
また、AWSの管理画面だけでなく、AWS CLIからも利用できます。
以前はAWS Single Sign-On（AWS SSO）という名称でしたが、現在はIAM Identity Centerに変更されています。
なぜIAM Identity Centerが必要なのか？
例えば、会社で次のようなAWSアカウントを運用しているとします。
| AWSアカウント | 用途 |
|---|---|
| 開発環境 | 開発・動作確認 |
| 検証環境 | リリース前のテスト |
| 本番環境 | 実際のサービス運用 |
IAMユーザーを利用する場合、アカウントごとにユーザーを作成・管理する必要があります。
そのため、アカウントが増えるほど、ユーザーの追加や削除、権限変更などの管理が煩雑になります。
また、退職者のIAMユーザーを削除し忘れたり、アクセスキーが長期間有効なまま残ってしまったりするリスクもあります。
IAM Identity Centerを利用すると、ユーザーやアクセス権を一元的に管理できるため、こうした管理の負担を軽減できます。
AWS Organizationsとの関係
IAM Identity Centerを理解するうえで、AWS Organizationsというサービスも知っておくと分かりやすいです。
AWS Organizationsは、複数のAWSアカウントをまとめて管理するためのサービスです。
例えば、次のような構成を作れます。
AWS Organizations
│
├── 管理アカウント（Management account）
│ └── IAM Identity Centerを有効化・管理
│
├── 開発環境アカウント
│
├── 検証環境アカウント
│
└── 本番環境アカウント
管理アカウントでIAM Identity Centerを有効化し、各AWSアカウントへのアクセス権を管理する構成が一般的です。
ユーザーはIAM Identity Centerで認証した後、割り当てられたAWSアカウントとPermission Setを選択してアクセスします。
それぞれの役割を簡単に整理すると、次のようになります。
| サービス・アカウント | 役割 |
|---|---|
| AWS Organizations | 複数のAWSアカウントをまとめて管理する |
| 管理アカウント | OrganizationsやIAM Identity Centerなどを管理する |
| IAM Identity Center | ユーザーとAWSアカウントへのアクセス権を管理する |
| IAMロール | AWSアカウント内で実際に利用する権限を持つ |
なお、IAM Identity CenterはOrganizationsの管理アカウント以外に、委任管理者アカウントを設定して管理を任せることもできます。
Permission Setとは？
IAM Identity Centerでは、Permission Set（許可セット）という仕組みを使って、ユーザーに付与する権限を管理します。
Permission Setは、AWSアカウントにアクセスする際に適用する権限を定義したものです。
例えば、次のようなPermission Setを作成できます。
| Permission Set | 想定する用途 |
|---|---|
DeveloperAccess |
開発作業に必要な権限 |
ReadOnlyAccess |
AWSリソースの参照のみ |
AdministratorAccess |
管理者向けの権限 |
※これらは説明用の名前の例です。実際に利用するPermission Setは管理者が作成・設定します。
例えば、開発環境では DeveloperAccess、本番環境では ReadOnlyAccess を割り当てるといった使い分けができます。
このように、誰に、どのAWSアカウントへの、どの権限を付与するかを組み合わせて管理できます。
IAMロールとの関係
Permission SetをAWSアカウントに割り当てると、その権限に対応するIAMロールが対象アカウントに作成されます。
IAM Identity Centerが管理するIAMロールには、次のような名前が付いています。
AWSReservedSSO_DeveloperAccess_xxxxxxxxx
このIAMロールを使って、実際にAWSアカウント内のリソースへアクセスします。
つまり、Permission Setで権限を定義し、その設定をもとに対象のAWSアカウントにIAMロールが作成されるという関係です。
なお、これらのIAMロールはIAM Identity Centerによって管理されるため、通常は直接編集せず、Permission Set側で権限を管理します。
IAMユーザーとの違い
ここまでの内容を踏まえて、IAMユーザーとIAM Identity Centerの違いを整理してみます。
| 比較項目 | IAMユーザー | IAM Identity Center |
|---|---|---|
| ユーザー管理 | AWSアカウントごとに作成・管理 | 複数アカウントのユーザーを一元管理 |
| 複数アカウントへのアクセス | アカウントごとに認証情報や権限を管理 | 一度の認証で許可されたアカウントにアクセス |
| 権限管理 | IAMポリシーなどで設定 | Permission Setで管理 |
| 認証方法 | パスワード・アクセスキーなど | SSOによる認証 |
| CLIでの利用 | アクセスキーなどを設定 | 一時的な認証情報を利用 |
| 主な用途 | 個別のAWSアカウントでの利用 | 複数アカウントを利用する組織での管理 |
特に大きな違いは、ユーザー管理と認証情報の扱いです。
IAMユーザーでは、アクセスキーを発行してローカル環境に保存する運用がよくあります。
一方、IAM Identity Centerでは、ログイン後に一時的な認証情報を取得してAWSにアクセスします。
一時的な認証情報を利用するメリット
IAM Identity Centerでは、ログイン後に一時的な認証情報を取得してAWSのサービスを利用します。
IAMユーザーのアクセスキーのように、長期間有効な認証情報をローカル環境に保存し続ける必要がありません。
一時的な認証情報には有効期限があり、期限が切れると再認証などが必要になります。
そのため、アクセスキーの漏えいや管理漏れによるリスクを抑えやすくなります。
もちろん、IAM Identity Centerを利用すれば情報漏えいのリスクがなくなるわけではありません。
MFA（多要素認証）の設定や、必要最小限の権限を付与することも重要です。
CLIでも使える
AWS CLI（v2）からも、アクセスキーを直接発行・保存せずにIAM Identity Centerを利用できます。
まずは、接続設定を行います。
# 最初に1回だけ設定
aws configure sso
実行すると、対話形式でいくつかの情報を聞かれます。途中でブラウザが開くので、IAM Identity Centerで認証を行ってから、接続先のアカウントとPermission Setを選択します。
| 設定項目 | 内容 |
|---|---|
| SSO session name | ログイン設定を識別する名前 |
| SSO start URL | IAM Identity CenterのログインURL |
| SSO region | IAM Identity Centerを利用しているリージョン |
| AWS account | 接続先のAWSアカウント |
| Permission Set | 利用する権限セット |
| Default client Region | AWS CLIで利用するデフォルトリージョン |
| CLI profile name | 接続設定を識別する名前 |
※表にない項目（SSO registration scopesなど）は、Enterで既定値のままで問題ありません。
例えば、会社で staging（検証環境）と production（本番環境）の2つのAWSアカウントを利用している場合、aws configure sso を2回実行して、それぞれのプロファイルを作成します。
2回目の設定では、SSO session nameに1回目と同じ名前を指定します。こうすることで、2つのプロファイルが同じログイン情報を共有できます。
最後のCLI profile nameには、任意の名前を付けます。例えば、次のように登録できます。
| プロファイル名 | 接続先 | Permission Set |
|---|---|---|
staging |
検証環境 | DeveloperAccess |
production |
本番環境 | ReadOnlyAccess |
※実際に選択できるAWSアカウントやPermission Setは、管理者から割り当てられたアクセス権によって異なります。
設定が完了したら、プロファイル名を指定してログインします。
# staging環境にログイン（ブラウザで認証）
aws sso login --profile staging
aws sso login を実行するとブラウザが開き、IAM Identity Centerで認証を行います。
認証に成功すると、ターミナルに次のようなメッセージが表示されます。
Attempting to open the SSO authorization page in your default browser.
Successfully logged into Start URL: https://example.awsapps.com/start
これで、staging プロファイルを使ってAWS CLIからAWSにアクセスできるようになります。
まずは、意図したAWSアカウントに接続できているか確認してみましょう。
# 接続先を確認
aws sts get-caller-identity --profile staging
aws sts get-caller-identity は、現在どのAWSアカウントに、どの権限で接続しているかを確認するコマンドです。
例えば、次のような結果が返ってきます。
{
"UserId": "AROAXXXXXXXXXXXXX:example",
"Account": "123456789012",
"Arn": "arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_DeveloperAccess_xxxxx/example"
}
Account でAWSアカウントを、Arn で利用しているIAMロールを確認できます。
接続先を確認できたら、実際にAWS CLIから操作してみます。
# S3バケットの一覧を取得
aws s3 ls --profile staging
# EC2インスタンスの一覧を取得
aws ec2 describe-instances --profile staging
実行できる操作は、割り当てられたPermission Setの権限によって異なります。
プロファイルの指定について
ここまでの例では、コマンドを実行するたびに --profile staging を指定しています。
毎回指定するのが面倒な場合は、環境変数 AWS_PROFILE を設定する方法もあります。
# stagingをデフォルトのプロファイルとして指定
export AWS_PROFILE=staging
これを設定すると、そのターミナルでは以降のAWS CLIコマンドで --profile を省略できます。
# --profile staging を省略できる
aws s3 ls
aws sts get-caller-identity
別のプロファイルに切り替えたい場合は、環境変数を変更します。
# productionに切り替え
export AWS_PROFILE=production
※環境変数の設定は、そのターミナルのセッション内で有効です。
staging と production は同じSSOセッションを共有しているため、staging でログインしていれば、production に切り替えるときに改めてログインする必要はありません。
一度のログインで複数のAWSアカウントを使い分けられるのが、IAM Identity Centerの便利なところです。
これで、ローカルに長期間有効なアクセスキーを保存しなくてもCLIが使えるようになります。サインインセッションの有効期限が切れた場合は、再度 aws sso login を実行します。
まとめ
今回は、IAM Identity Centerの基本的な仕組みとIAMユーザーとの違いについて整理しました。
ポイントをまとめると、次のとおりです。
- IAM Identity Centerは、複数のAWSアカウントへのアクセスを一元管理するサービス
- AWS Organizationsと連携することで、組織内のAWSアカウントをまとめて管理できる
- Permission Setを使って、ユーザーに付与する権限を管理する
- IAMが不要になるわけではなく、裏側ではIAMロールやIAMポリシーが使われている
- AWS CLIからも利用でき、長期間有効なアクセスキーを保存せずにAWSへアクセスできる