IAM ユーザーのアクセスキーを廃止して aws login に移行する

こんにちは、コンサルティング部のシモンです。

IAM ユーザーのアクセスキーは、手動で無効化するまで使い続けられる長期の認証情報です。各ユーザーの端末の ~/.aws/credentials に平文で置かれるので、フィッシングなどで端末がマルウェアに感染して読み取られたり、誤ってリポジトリにコミットしたりして漏れると、持ち主と同じ権限で AWS を操作できてしまいます。AWS Security Hub CSPM の IAM.3（有効なアクセスキーを 90 日以内にローテーションする）で検出され続けたり、社内の監査で指摘されたりして、キーそのものをなくしたい場面もあります。

AWS CLI の aws login を使えば、IAM ユーザーのまま AWS マネジメントコンソールのサインインから短期の認証情報を得られます。認証情報は 15 分で期限が切れ、自動の更新も最長 12 時間で止まるので、漏れても使われる期間は限られます。AWS Organizations や AWS IAM Identity Center を使えない環境でも使えます。

aws login はブラウザでのサインインが前提なので、本記事で移行の対象にするのは人が端末で使うアクセスキーです。

管理者と各ユーザーの作業の順序

作業するのは、アカウントを管理する管理者と、端末で AWS CLI を使う各ユーザーです。

移行するアクセスキーを選ぶ（管理者）

まず、認証情報レポートで、ユーザーごとのアクセスキーの作成日時、最終使用日時、最後に使われたサービスとリージョンを一覧にします。

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv

最終使用の情報だけでは、そのキーを人が端末で使っているのか、CI やバッチが使っているのかは分かりません。一覧にしたキーごとに持ち主に確認し、各ユーザーが端末の AWS CLI や SDK で使っているキーを移行の対象にします。持ち主が分からないキーは、AWS CloudTrail のイベント履歴をキー ID で絞り込み、送信元 IP アドレスとユーザーエージェントから使われ方の見当をつけます。

プログラムが使っているキーは aws login に置き換えられないので、本記事では扱いません。IAM ロールや OIDC によるフェデレーションへの移行を別に検討します。最終使用日時が空のキーや、長く（たとえば 90 日以上）使われていないキーは、移行の対象にせず、そのまま無効化します。

一時パスワードを発行し、各ユーザーが MFA を登録できるようにする（管理者）

aws login は IAM ユーザーのコンソールサインインを使うので、アクセスキーしか持たないユーザーにはパスワードが必要です。管理者が決めるのは一時パスワードだけで、本来のパスワードと MFA は各ユーザーが設定します。

1. 移行するユーザーを IAM グループ（ここでは aws-login-users）にまとめます。この後のポリシーはすべてこのグループに付けます

2. 各ユーザーが自分のパスワードを変更し、MFA デバイスを登録できるように、次のポリシーをグループに付けます

   各ユーザーが自分のパスワードを変更し、MFA デバイスを登録できるようにするポリシー

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "AllowListActions",
         "Effect": "Allow",
         "Action": ["iam:ListUsers", "iam:ListVirtualMFADevices"],
         "Resource": "*"
       },
       {
         "Sid": "AllowUserToCreateVirtualMFADevice",
         "Effect": "Allow",
         "Action": ["iam:CreateVirtualMFADevice"],
         "Resource": "arn:aws:iam::*:mfa/*"
       },
       {
         "Sid": "AllowUserToManageTheirOwnMFA",
         "Effect": "Allow",
         "Action": ["iam:EnableMFADevice", "iam:GetMFADevice", "iam:ListMFADevices", "iam:ResyncMFADevice"],
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       },
       {
         "Sid": "AllowUserToChangeTheirOwnPassword",
         "Effect": "Allow",
         "Action": ["iam:ChangePassword"],
         "Resource": [
           "arn:aws:iam::*:user/${aws:username}",
           "arn:aws:iam::*:user/*/${aws:username}"
         ]
       },
       {
         "Sid": "AllowViewAccountPasswordPolicy",
         "Effect": "Allow",
         "Action": ["iam:GetAccountPasswordPolicy"],
         "Resource": "*"
       }
     ]
   }
   

3. アカウントのパスワードポリシーを満たすランダムな一時パスワードを、パスワード管理ツールなどでユーザーごとに用意します。IAM コンソールで各ユーザーのコンソールアクセスを有効にし、用意した一時パスワードをカスタムパスワードに設定して、次回のサインイン時にパスワードの変更を求めます

   

   人数が多い場合は、AWS CLI で発行できます。

   一時パスワードを発行し、次回のサインイン時に変更を求める

   aws iam create-login-profile \
     --user-name example-user \
     --password '一時パスワード' \
     --password-reset-required
   

4. ユーザー名、一時パスワード、アカウントのサインイン URL（https://アカウント ID.signin.aws.amazon.com/console）を各ユーザーに渡します

MFA を必須にするポリシー（aws:MultiFactorAuthPresent が false なら拒否する、よくある形のもの）を使っている場合は、拒否の例外に iam:ChangePassword と iam:GetAccountPasswordPolicy を加えます。加えないと、各ユーザーはパスワードの変更を求められたときに変更できず、サインインできなくなります。

パスワードを作ってから各ユーザーが MFA を登録するまでの間、そのユーザーは Security Hub CSPM の IAM.5（コンソールパスワードを持つ IAM ユーザーは MFA を有効にする）で検出されます。一時パスワードを渡したら、早めに MFA まで済ませてもらいます。

SignInLocalDevelopmentAccess を付ける（管理者）

aws login に必要な権限は signin:AuthorizeOAuth2Access と signin:CreateOAuth2Token の 2 つで、AWS 管理ポリシー SignInLocalDevelopmentAccess にまとまっています。移行するユーザーのグループに付けます。

aws iam attach-group-policy \
  --group-name aws-login-users \
  --policy-arn arn:aws:iam::aws:policy/SignInLocalDevelopmentAccess

パスワードを変更し、MFA を登録する（各ユーザー）

管理者からユーザー名、一時パスワード、アカウントのサインイン URL を受け取ったら、IAM ユーザーとしてコンソールにサインインし、自分のパスワードに変更します。続けて、画面右上のユーザー名のメニューからセキュリティ認証情報のページを開き、MFA デバイスを登録します。認証アプリのほか、パスキーやセキュリティキーも使えます。

登録したら一度サインアウトし、MFA 付きでサインインし直します。MFA を必須にするポリシーがある場合、MFA を登録する前のセッションのままでは aws login が 400 エラーになるためです。

aws login に切り替える（各ユーザー）

AWS CLI 2.32.0 以降を使う

AWS CLI のバージョンを確認し、aws login を使える 2.32.0 より前なら更新します。

aws --version

aws login を実行する

パスワード管理ツールなどからアクセスキーを credential_process で取り出している場合は、aws login を実行する前に、そのプロファイルから credential_process の行を外します。credential_process が書いてあるプロファイルでは、aws login はブラウザを開く前に実行を拒否します。

[default]
region = ap-northeast-1
credential_process = /usr/local/bin/aws-credential-helper

[default]
region = ap-northeast-1

aws login

aws login の認証情報は、アクセスキーを書いていたのと同じプロファイルに設定します。[default] 以外のプロファイルを使用する場合は、--profile でプロファイル名を指定します。プロファイル名が変わらないので、スクリプトや AWS_PROFILE の指定も、source_profile でこのプロファイルを指すロールのプロファイルも、書き換えずに使えます。ブラウザが開くので、サインインします。

サインイン画面に、同じブラウザに残っているコンソールセッション（別の IAM ユーザーのセッションや、MFA を登録する前の自分のセッション）が候補として出たら、AWS CLI が表示する URL をプライベートウィンドウで開き、移行する IAM ユーザーでサインインします。

サインインが終わると、~/.aws/config の実行したプロファイル（ここでは [default]）に login_session の行が追記されます。

[default]
login_session = arn:aws:iam::111122223333:user/example-user
region = ap-northeast-1

古いアクセスキーを端末から消す

~/.aws/credentials から、aws login のプロファイルと同じ名前のプロファイルのアクセスキーを消します。移行前の ~/.aws/credentials が次の形なら、[default] の 3 行を消します。

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

環境変数 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY にキーを設定している場合は、シェルの設定ファイルや .env ファイルからも消します。

どちらかが残っていると、AWS CLI は aws login の認証情報よりキーのほうを使います。環境変数のキーは、[default] や AWS_PROFILE で aws login のプロファイルを選んでいても使われます。

消したら、aws configure list --profile default で認証情報の取得元を確認します。TYPE の列が login なら aws login の認証情報が、shared-credentials-file なら ~/.aws/credentials のキーが使われています。

NAME       : VALUE                    : TYPE             : LOCATION
profile    : default                  : manual           : --profile
access_key : ****************ABCD     : login            :
secret_key : ****************WXYZ     : login            :
region     : ap-northeast-1           : config-file      : ~/.aws/config

NAME       : VALUE                    : TYPE             : LOCATION
profile    : default                  : manual           : --profile
access_key : ****************MPLE     : shared-credentials-file :
secret_key : ****************EKEY     : shared-credentials-file :
region     : ap-northeast-1           : config-file      : ~/.aws/config

切り替えた後の再サインインと aws logout

認証情報の更新は、AWS CLI と対応するバージョンの SDK が自動で行います。更新が止まる 12 時間を過ぎたら、aws login をやり直します。

作業を終えたら aws logout を実行します。キャッシュにはリフレッシュトークンが平文で残るので、消しておけば端末から新しい認証情報を得られる期間を短くできます。

aws logout

Removed cached login credentials for profile 'default'. Note, any local developer tools that have already loaded the access token may continue to use it until its expiration. Access tokens expire in 15 minutes.

アクセスキーを廃止する（管理者）

使われなくなったことを確認する

各ユーザーが切り替えたら、認証情報レポートを作成し直します。レポートは 4 時間に 1 回までしか作り直されないので、移行するキーを選んだときから 4 時間以内なら、時間を置いてから作成します。

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv

CSV を表計算ソフトなどで開き、移行したユーザーの access_key_1_last_used_date と access_key_2_last_used_date の列を見ます。

移行したユーザーの最終使用日時が、切り替えた日より後になっている場合は、どこかでまだキーが使われています。そのユーザーに、端末に残ったキーや、キーを使っているほかのツールがないかを確認してもらいます。

無効化してから削除する

まず無効化します。無効化したキーでの呼び出しは失敗するので、キーを使っている箇所が残っていれば各ユーザーからの連絡で気づけることが多く、問題が出たら有効に戻せます。

aws iam update-access-key --user-name example-user --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

一定期間（たとえば 2 週間）問題がなければ、削除します。

aws iam delete-access-key --user-name example-user --access-key-id AKIAIOSFODNN7EXAMPLE

新しいアクセスキーを作れないようにする

キーを削除しても、各ユーザーが自分で新しいキーを作れる権限を持っていれば、アクセスキーのある状態に戻ります。移行したユーザーのグループに、iam:CreateAccessKey を明示的に拒否するポリシーを付けます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCreateAccessKey",
      "Effect": "Deny",
      "Action": "iam:CreateAccessKey",
      "Resource": "*"
    }
  ]
}

このポリシーが止めるのは、グループのメンバーによるキーの作成です。グループに入っていない管理者が、ほかのユーザーのキーを作ることは止めません。AWS Organizations の管理アカウントを運用している場合は、例外にする管理用のロールを除いて iam:CreateAccessKey を拒否するサービスコントロールポリシー（SCP）で、メンバーアカウント全体に適用できます。管理アカウント自身には SCP が効かないので、管理アカウントのユーザーには上のポリシーを付けます。

移行で変わる Security Hub CSPM の検出結果（管理者）

Security Hub CSPM を使っている場合は、この移行で次のコントロールの結果が変わります。

IAM.22 は 4 時間ごとに更新される認証情報レポートで評価するので、IAM ユーザーへの変更が IAM.22 の結果に出るまで最大で 4 時間かかります。aws login のブラウザでのサインインも、パスワードの最終使用日時に記録されます。

まとめ

本記事では、IAM ユーザーが端末で使っているアクセスキーを、aws login による短期の認証情報に置き換える手順を紹介しました。

アクセスキーは無効化するまで期限なく使えるため、端末から漏れると、持ち主と同じ権限で AWS を操作されるおそれがありました。

aws login に移行すると、各ユーザーの端末に期限のないキーが残らなくなり、漏れても認証情報は最長 12 時間で使えなくなります。キーを削除すれば、Security Hub CSPM の IAM.3 の検出もなくなります。AWS Organizations や IAM Identity Center を使えない環境でも、IAM ユーザーのまま実現できます。

参考資料

aws login の設定と権限:

• コンソールの認証情報を使った aws login（AWS CLI ユーザーガイド）
• AWS Sign-In の AWS 管理ポリシー
• aws loginでスイッチロールを試してみる

Security Hub CSPM:

• Security Hub CSPM の IAM のコントロール