ローカルの開発端末に保存されたIAMアクセスキーの漏洩は、クラウドセキュリティにおける最大の事故要因の1つです。PCの紛失、マルウェア感染、誤ってGitリポジトリへコミットしてしまうミスなど、長期的な認証情報を手元に残しておく運用には常に重大な危険が伴います。
現在、AWS公式のベストプラクティスでは、静的なIAMユーザーとアクセスキー（aws_access_key_id / aws_secret_access_key）の利用を廃止し、IAM Identity Center（旧AWS SSO）を通じた一時的な認証情報の利用が推奨されています。
AWS CLI v2のsso-session機能を利用すると、ブラウザ経由で一度認証するだけで、端末上に長期キーを保存することなく安全な短期トークンを自動取得・更新できます。本記事では、初期設定からマルチアカウント環境での活用法、旧アクセスキーの完全撤廃手順まで詳しく解説します。
この記事で行うこと
この記事では、ローカル開発環境のAWS CLI認証を従来の静的アクセスキーからIAM Identity Centerによる一時認証へと安全に移行する手順を扱います。
具体的には、aws configure ssoウィザードを用いた初期プロファイル作成、~/.aws/configファイルを用いたマルチアカウント・マルチロール環境の定義、日常的なCLI操作とセッション更新、そして古いアクセスキーの無効化・削除までの流れを実践形式で進めます。
前提条件・対象読者
本記事は、自社のAWS環境でIAM Identity Centerがすでに有効化されており、ログイン用のAWSアクセスポータルURLが発行されている方を対象としています。
また、手元の環境として以下の条件を満たしている必要があります。
| 項目 | 必要な要件 |
|---|---|
| AWS CLI | AWS CLI v2（バージョン2.0以上、推奨2.22.0以上） |
| IAM Identity Center環境 | 組織でIAM Identity Centerが設定され、自身のアカウント・ロールが割り当てられていること |
| 端末環境 | macOS、Linux、またはWindows（ブラウザ起動が可能な環境） |
| 必要な情報 | AWSアクセスポータルのURL（例: https://example.awsapps.com/start）とリージョン |
AWS CLIのバージョンが古い場合は、公式インストーラーを用いて最新のAWS CLI v2にアップデートしてください。バージョンは以下のコマンドで確認できます。
aws --version
出力結果に aws-cli/2.x.x と表示されれば準備完了です。
なぜIAMアクセスキーを撤廃すべきなのか
従来のIAMユーザーに発行されるアクセスキーは、明示的に削除または無効化しない限り永続的に有効な長期認証情報（Long-term credentials）です。
ローカル環境の ~/.aws/credentials ファイルに平文で保存されるため、以下のようなリスクが常に存在します。
一方、IAM Identity CenterとAWS CLI v2を連携させた場合、手元の端末には短時間（標準で1時間〜最長12時間など組織の設定による）のみ有効な一時トークンしか保存されません。
万が一開発端末が危険に晒された場合でも、トークンの有効期限が切れれば自動的に無効化され、管理コンソール側からセッションを即座に取り消すことも可能です。さらに、社内IdP（Google Workspace、Okta、Microsoft Entra IDなど）と統合されていれば、会社アカウントのMFAログインと連動して統一的にアクセス制御が行えます。
手順1：事前準備（アクセスポータルURLとリージョンの確認）
設定を始める前に、管理者から共有されている以下の2つの情報を手元に用意します。
- AWSアクセスポータルの開始URL（Start URL） 形式例: https://my-company.awsapps.com/start または https://d-xxxxxxxxxx.awsapps.com/start 組織によっては独自ドメインのバニティURLや、最新の発行者URL（https://ssoins-xxxx.portal.ap-northeast-1.app.aws 等）が指定される場合もあります。
- IAM Identity CenterがホストされているAWSリージョン 例: ap-northeast-1（東京）、us-east-1（バージニア北部）など AWSリソースを運用しているリージョンではなく、IAM Identity Centerのディレクトリが置かれているリージョンを指定する必要がある点に注意してください。
手順2：aws configure sso ウィザードで初期設定を行う
必要な情報が揃ったら、ターミナルで以下の対話型コマンドを実行します。
aws configure sso
コマンドを実行すると、対話形式で設定項目を順番に質問されます。以下のように入力してください。
SSO session name (Recommended): my-sso
SSO start URL [None]: https://my-company.awsapps.com/start
SSO region [None]: ap-northeast-1
SSO registration scopes [None]: sso:account:access
各項目の入力内容は以下のとおりです。
Enterキーを押すと、デフォルトのWebブラウザが自動的に起動し、AWSの認可画面が表示されます。
ブラウザ画面に表示されたリクエスト承認画面で「許可」または「Allow」ボタンをクリックし、必要に応じて組織のアカウントでログインおよびMFA認証を完了させてください。
認証が成功すると、ターミナル側で利用可能なAWSアカウント一覧が表示されます。
There are 2 AWS accounts available to you.
> DevAccount (111122223333)
ProdAccount (444455556666)
矢印キーで利用したいアカウントを選択してEnterキーを押します。続いて、割り当てられているIAMロール（Permission Set）を選択します。
Using the account ID 111122223333
There are 2 roles available to you.
> AdministratorAccess
PowerUserAccess
ロールを選択すると、クライアント側の基本設定を求められます。
CLI default client Region [None]: ap-northeast-1
CLI default output format [None]: json
CLI profile name [AdministratorAccess-111122223333]: dev
設定が完了すると、プロファイルの生成完了メッセージが表示されます。
手順3：~/.aws/config の設定内容とマルチアカウント展開
ウィザードが完了すると、ユーザーのホームディレクトリ配下にある ~/.aws/config に設定が書き込まれます。
生成された設定ファイルの内容を確認してみましょう。
[profile dev]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = PowerUserAccess
region = ap-northeast-1
output = json
[sso-session my-sso]
sso_start_url = https://my-company.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access
AWS CLI v2の大きな利点は、[sso-session] セクションが共通定義として独立している点です。
本番アカウントやステージングアカウントなど、複数のアカウントや異なる権限のロールを追加したい場合、毎回ウィザードを実行し直す必要はありません。~/.aws/config に新しい [profile <名前>] セクションを追記し、同じ sso_session を指定するだけで簡単にマルチアカウント環境を構築できます。
複数プロファイルの記述例は以下のとおりです。
# 共通のSSOセッション定義
[sso-session my-sso]
sso_start_url = https://my-company.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access
# 開発環境プロファイル
[profile dev]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = PowerUserAccess
region = ap-northeast-1
output = json
# ステージング環境プロファイル
[profile stg]
sso_session = my-sso
sso_account_id = 222233334444
sso_role_name = PowerUserAccess
region = ap-northeast-1
output = json
# 本番環境プロファイル（読み取り専用ロール）
[profile prod-ro]
sso_session = my-sso
sso_account_id = 444455556666
sso_role_name = ViewOnlyAccess
region = ap-northeast-1
output = json
このように設定しておけば、1回のブラウザ認証だけで、同一のSSOセッションに紐づくすべてのプロファイルをそのまま横断して利用できるようになります。
手順4：日常のCLI運用（ログイン・動作確認・ログアウト）
プロファイルの設定が完了した後の、日々の操作手順を解説します。
セッションへのログイン
作業を開始する際は、以下のコマンドを実行してIAM Identity Centerにサインインします。
aws sso login --profile dev
または、定義したSSOセッション名を直接指定してログインすることも可能です。
aws sso login --sso-session my-sso
コマンドを実行するとブラウザが開き、認証画面が表示されます。認証を承認すると、端末側の ~/.aws/sso/cache/ 配下に一時的なアクセストークンがキャッシュされ、CLIが利用可能な状態になります。
認証状態と実行権限の確認
現在どのプロファイルで認証されているかを確認するには、STSの get-caller-identity コマンドを実行します。
aws sts get-caller-identity --profile dev
成功すると、以下のようなJSONレスポンスが返されます。
{
"UserId": "AROAXXXXXXXXXXXXXXXXX:username",
"Account": "111122223333",
"Arn": "arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_PowerUserAccess_xxxxxxxx/username"
}
Arn の項目に assumed-role/AWSReservedSSO_… と表示されていれば、IAM Identity Center経由で一時クレデンシャルを取得できている証拠です。
通常のAWSコマンドを実行する際も、同様に –profile オプションを付与して呼び出します。
aws s3 ls --profile dev
セッション有効期限と自動更新
IAM Identity Center経由で取得した一時クレデンシャルは、セッションが有効な間、AWS CLIが必要に応じてバックグラウンドで自動更新（リフレッシュ）してくれます。
作業中に有効期限が切れて突然コマンドが失敗する心配はほとんどありません。ただし、SSOログイン自体の最大有効期限（組織設定による。通常は8時間〜24時間程度）が切れた場合は再認証が必要となるため、その際は再度 aws sso login を実行してください。
セッションのログアウト（一時トークンの破棄）
作業が完了した際や、共有端末等でキャッシュされた認証情報を直ちに破棄したい場合は、以下のコマンドでログアウトします。
aws sso logout
ログアウトすると、ローカルに保存されていた一時トークンがすべて削除され、安全な状態に戻ります。
手順5：プロファイル切り替えを快適にする実践テクニック
毎回コマンドに –profile dev や –profile prod を付けるのは手間で、指定忘れによる誤操作の原因にもなります。日常の作業を効率化するテクニックをいくつか紹介します。
環境変数 AWS_PROFILE の活用
ターミナルのセッション全体で特定のプロファイルをデフォルトとして使いたい場合は、環境変数 AWS_PROFILE をエクスポートします。
export AWS_PROFILE=dev
この設定を行ったシェル内では、–profile オプションを省略しても自動的に dev プロファイルとしてコマンドが実行されます。
aws s3 ls
元の設定に戻す、または解除したい場合は環境変数をアンセットします。
unset AWS_PROFILE
direnvによるディレクトリごとの自動切り替え
リポジトリやプロジェクトごとにアクセス先アカウントを自動で切り替えたい場合は、direnvツールの併用が非常に効果的です。
対象プロジェクトのルートディレクトリに .envrc ファイルを作成し、以下を記述しておきます。
export AWS_PROFILE=dev
これにより、そのディレクトリに cd で入った瞬間に自動でプロファイルが切り替わり、ディレクトリを抜ければ元の環境に戻るため、本番アカウントと開発アカウントの取り違えミスを劇的に減らすことができます。
手順6：古いIAMアクセスキーの安全な無効化・撤廃手順
IAM Identity Centerによるログイン環境が正常に動作することを確認できたら、最終目標であるローカル端末の長期IAMアクセスキーを安全に撤廃します。
いきなりアクセスキーを削除してしまうと、バックグラウンドのバッチ処理や他のツールで不意の障害が発生するリスクがあります。必ず以下のステップで段階的に進めてください。
ステップ1：ローカルの ~/.aws/credentials を退避
まず、手元の端末で静的なアクセスキーが読み込まれない状態を作ります。~/.aws/credentials ファイルをリネームしてバックアップします。
mv ~/.aws/credentials ~/.aws/credentials.backup
この状態で、日常利用しているスクリプトやツール（Terraform、AWS SDKアプリ、Dockerコンテナ連携など）が問題なく動作するか数日〜1週間程度運用して検証します。
ステップ2：AWSマネジメントコンソールでアクセスキーを無効化（Inactive）
問題がなければ、AWSマネジメントコンソールにサインインし、対象のIAMユーザーの設定画面を開きます。
- IAMコンソールから「ユーザー」を選択し、該当のIAMユーザーをクリックします。
- 「セキュリティ認証情報」タブを開きます。
- 対象のアクセスキーの「アクション」から「非アクティブ化（Deactivate）」を選択します。
アクセスキーを削除する前に「非アクティブ化」ステータスにすることで、万が一どこかでキーが使われていた場合でも、即座に「アクティブ」に戻して復旧させることができます。
ステップ3：アクセスキーの完全削除
非アクティブ化した状態で一定期間エラーが発生しないことを確認したら、同じ画面から「削除」を実行してアクセスキーを完全に破棄します。
これで、手元の端末からもAWSクラウド上からも漏洩源となる長期アクセスキーが完全に排除されました。
うまくいかない場合の確認ポイント（トラブルシューティング）
設定中や日常の利用でつまずきやすいポイントと解決策をまとめました。
ブラウザが自動で開かない場合
リモートサーバー（SSH接続先）やWSL環境などでブラウザが起動しない場合は、ターミナル上に手動アクセス用のURLが表示されます。
バージョン2.22.0以降のAWS CLIではPKCE認証がデフォルトとなっています。画面に表示されたURLをコピーし、ローカルPCのブラウザのアドレスバーに貼り付けて認証を完了させてください。
なお、別のデバイスで認証コードを入力して承認したい場合は、以下のように –use-device-code オプションを付けてログインを実行できます。
aws sso login --profile dev --use-device-code
指定したURL（https://device.sso…）を任意の端末で開き、画面に表示されたワンタイムコードを入力することで認証できます。
Token has expired エラーが表示される場合
コマンド実行時に以下のエラーが発生することがあります。
Error: The SSO session associated with this profile has expired or is invalid. To refresh this SSO session run aws sso login with the corresponding profile.
これはSSOセッションの有効期限が切れたことを示しています。メッセージに記載されているとおり、対象プロファイルで再度ログインを実行してください。
aws sso login --profile dev
キャッシュの不整合でログインが失敗する場合
設定ファイルの記述ミスやURL変更などでログインが正しく完了しなくなった場合は、~/.aws/sso/cache ディレクトリ内に残っている古いトークンキャッシュが影響している可能性があります。
以下のコマンドでキャッシュフォルダ内のファイルを一度クリアしてから、再度ログインを試みてください。
rm -rf ~/.aws/sso/cache/*
よくある質問（FAQ）
Q1. 旧仕様のSSO設定（sso-sessionがない形式）を使っている場合は移行すべきですか？
はい、sso-session形式への移行を強くおすすめします。
従来のAWS CLIでは、各プロファイル内に sso_start_url や sso_region を直接書き込む形式でした。このレガシーな設定ではトークンの自動更新（リフレッシュトークン機能）が動作せず、複数プロファイル間でセッションを共有することもできません。
sso-session形式を採用することで、1回のログインで同一セッションに紐づくすべてのプロファイルを横断して利用できるようになり、作業効率が大幅に向上します。
Q2. CI/CDパイプライン（GitHub Actionsなど）でもこの方法を使うべきですか？
いいえ、CI/CD環境では aws configure sso ではなく「OIDC（OpenID Connect）連携」を利用するのがベストプラクティスです。
GitHub ActionsやGitLab CIなどの自動化環境では、対話型のブラウザログインが行えません。代わりに、AWS IAMとGitHub Actionsの間でOIDCフェデレーションを設定し、AssumeRoleWithWebIdentityを用いてジョブ実行時のみ有効な一時クレデンシャルを動的に取得する構成を採用してください。
これにより、CI/CDのシークレット（Repository secrets）にも長期アクセスキーを一切保存せずに安全なパイプラインを構築できます。
Q3. セッションの有効期限はどこで変更できますか？
セッションの有効期限は、AWS CLI側ではなくAWS管理コンソールのIAM Identity Center設定画面で制御されています。
作業内容や組織のセキュリティポリシーに応じて、管理者が最適な期間を設定します。
まとめ
本記事では、AWS CLI v2とIAM Identity Centerを連携させ、長期IAMアクセスキーを完全に撤廃する手順について解説しました。
要点を振り返ります。
静的なアクセスキーを排除することは、AWSアカウントのセキュリティレベルを飛躍的に向上させる第一歩です。まだローカルにアクセスキーを残している方は、本記事を参考にぜひIAM Identity Center経由のセキュアな環境へ移行してみてください。
