2026年6月29日
AWS のシングルサインオンは、現在は IAM Identity Center（旧称 AWS Single Sign-On）というサービスで設定します。手順は、IAM Identity Center を有効にし、ユーザーの管理元（ID ソース）を決め、権限セットを作ってユーザーやグループを AWS アカウントに割り当てる、という流れです。設定が済むと、利用者は1つのアクセスポータルから複数のアカウントにログインでき、CLI も長期のアクセスキーなしで使えるようになります。この記事では、その手順と、管理者が締め出されないための注意点を説明します。
IAM Identity Center のコンソールの表記や既定の設定は、これまでにも変更されています。ここでの説明は2026年10月現在の情報をもとにしていますが、項目名は目安として読み、作業前に公式ドキュメントで最新の手順を確認してください（2026年10月現在）。
なぜ IAM ユーザーではなく IAM Identity Center なのか
IAM ユーザーにアクセスキーを発行して使うと、キーは削除するまで有効な長期の認証情報になります。開発者の PC や CI の設定ファイルに置かれたキーが漏れると、気付くまで悪用される可能性があります。IAM Identity Center では、ログインのたびに有効期限付きの一時的な認証情報が発行されるため、漏えいしたときの被害の時間を短くできます。
また、アカウントが複数ある場合、IAM ユーザーではアカウントごとにユーザーを作る必要がありますが、IAM Identity Center なら1人1つの ID で、割り当てられたアカウントと権限を切り替えて使えます。退職者が出たときも、ID を1つ無効にすれば全アカウントへのアクセスを止められます。
ステップ1：有効にする前に決めること
組織インスタンスとアカウントインスタンス
IAM Identity Center には、AWS Organizations の管理アカウントで有効にする「組織インスタンス」と、単独のアカウントで有効にする「アカウントインスタンス」があります。AWS アカウントへのログインに権限セットを使えるのは組織インスタンスです。アカウントインスタンスは主に一部の AWS アプリケーション向けの用途に限られるため、AWS アカウントへの SSO が目的なら、Organizations を有効にして管理アカウントで設定します。アカウントが1つだけでも、Organizations を作ればこの方式を使えます。
リージョン
IAM Identity Center はリージョンを選んで有効にするサービスで、ユーザーや設定のデータはそのリージョンに置かれます。あとから別のリージョンに移すのは手間がかかるため、日本の利用者が中心なら東京リージョンなど、普段使うリージョンを最初に選びます。
ID ソース
ユーザーをどこで管理するかを選びます。
- Identity Center ディレクトリ：IAM Identity Center の中でユーザーとグループを作ります。既定の選択肢で、小規模なチームならこれで足ります。
- Active Directory：AWS Managed Microsoft AD や AD Connector を経由して、既存の AD のユーザーを使います。
- 外部 ID プロバイダー：Microsoft Entra ID、Okta、Google Workspace などと SAML 2.0 で連携します。SCIM に対応している ID プロバイダーなら、ユーザーとグループの作成・削除を自動で同期できます。
ID ソースは後から変更できますが、変更の組み合わせによっては既存のユーザーやグループ、割り当て、MFA の登録が削除される場合があります。変更する前に、公式ドキュメントの注意事項を確認してください。
ステップ2：ユーザーとグループを作る
Identity Center ディレクトリを使う場合は、ユーザーを作成して招待メールを送り、利用者が初回ログイン時にパスワードを設定します。権限はユーザーに直接ではなくグループ単位で割り当てると、人の入れ替わりがあっても整理しやすくなります。例えば「管理者」「開発者」「閲覧のみ」のようなグループを作っておきます。
MFA の設定も確認します。新しく有効にしたインスタンスでは MFA が既定で求められる設定になっていることが多いですが、要求のタイミングや使える MFA の種類（認証アプリ、セキュリティキーやパスキーなど）を設定の画面で見直し、組織の方針に合わせます。
ステップ3：権限セットを作り、アカウントに割り当てる
権限セットは「割り当て先のアカウントでどんな権限を持つか」をまとめたテンプレートです。AWS 管理ポリシーを使う定義済みの権限セット（管理者用、閲覧のみ用など）から選ぶか、独自のポリシーを組み合わせたカスタムの権限セットを作ります。セッションの継続時間も権限セットごとに設定できます。
次に、AWS アカウントを選び、グループと権限セットの組み合わせを割り当てます。割り当てを行うと、対象のアカウントに AWSReservedSSO_ で始まる名前の IAM ロールが自動で作られます。このロールは IAM Identity Center が管理するものなので、IAM の画面から直接編集したり削除したりせず、権限セット側で変更します。
最小権限の考え方で、日常の作業は開発者向けの権限セットで行い、管理者の権限セットは必要なときだけ使う、という使い分けをすると、誤操作の影響を減らせます。
ステップ4：アクセスポータルからログインする
設定が終わると、AWS アクセスポータルの URL が発行されます。利用者はこの URL でサインインし、表示されたアカウントと権限セットを選んでコンソールを開きます。URL のサブドメイン部分は、分かりやすい名前に変更できます。
ここで、管理者自身が IAM Identity Center 経由で管理アカウントと各アカウントにログインできることを確かめてから、それまで使っていた IAM ユーザーの整理に進みます。
ステップ5：AWS CLI で SSO ログインを使う
AWS CLI v2 は IAM Identity Center に対応しており、アクセスキーを保存せずに CLI を使えます。設定は対話形式のコマンドで行います。
aws configure ssoセッション名、スタート URL（アクセスポータルの URL）、IAM Identity Center のリージョンなどを入力すると、ブラウザが開いて認証を求められます。認証後に使うアカウントと権限セットを選ぶと、~/.aws/config に次のような設定が書き込まれます（値はダミーです）。
[profile wp-admin]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = AdministratorAccess
region = ap-northeast-1
output = json
[sso-session my-sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access以後は、セッションの有効期限が切れたらログインし直し、プロファイルを指定してコマンドを実行します。
aws sso login --profile wp-admin
aws sts get-caller-identity --profile wp-adminget-caller-identity の結果に AWSReservedSSO_ で始まるロールが表示されていれば、SSO 経由の一時的な認証情報で動いています。キャッシュされた認証情報は ~/.aws/sso/cache に保存されるため、共有の PC では作業後に aws sso logout を実行します。
なお、EC2 上の WordPress から S3 などを操作する場合は、SSO ではなく EC2 にアタッチする IAM ロールを使います。IAM Identity Center は人がログインするための仕組みで、サーバーやプログラムの権限には IAM ロールを使う、と役割を分けて考えます。
締め出されないための注意点
SSO を導入すると、ログインの入口が IAM Identity Center に集まります。設定の誤りや外部 ID プロバイダーの障害があると、全員がログインできなくなることがあるため、次の備えをしておきます。
- ルートユーザーを緊急用に残す：MFA を複数登録したうえで、普段は使わず、認証情報を安全に保管しておきます。
- 緊急用の手段を決めておく：外部 ID プロバイダーと連携している場合、プロバイダー側の障害に備えて、緊急時にだけ使う管理者の入口を用意しておくかどうかを組織の方針として決めます。用意する場合は MFA を必須にし、使用時に通知が届くようにします。
- 既存の IAM ユーザーはすぐに消さない：SSO 経由で必要な操作がすべてできることを確認してから、段階的に無効化・削除します。
- 割り当ての変更を記録する：IAM Identity Center の操作は CloudTrail に記録されます。誰がいつ権限を付け替えたかを後から確認できるようにしておきます。
外部 ID プロバイダーと連携する場合、SAML の証明書には有効期限があります。期限切れでログインできなくなる事故を防ぐため、更新の時期をカレンダーなどで管理しておくと安心です。
まとめ
- AWS の SSO は IAM Identity Center で設定し、ログインのたびに一時的な認証情報が発行されるため、長期のアクセスキーを減らせます。
- AWS アカウントへの SSO には Organizations の管理アカウントで有効にする組織インスタンスを使い、リージョンと ID ソースを最初に決めます。
- 権限はグループと権限セットで管理し、アカウントに割り当てると AWSReservedSSO_ のロールが自動で作られます。
- CLI は aws configure sso と aws sso login で、アクセスキーなしで使えます。サーバーの権限には IAM ロールを使います。
- ルートユーザーの保護、既存ユーザーの段階的な整理、証明書の期限管理で、締め出しを防ぎます。