AI 開発現場で IAM ユーザーをやめるAWS SSO + AssumeRole によるアクセス管理の設定手順

1. なぜ AI 開発現場でアクセスキー方式が危ないのか

MOOBON では、開発も運用も AI に任せる場面が増えてきました。Claude Code のような AI エージェントはとても便利なのですが、その同じ環境に長期キーが置いてあると、気をつけるべきことが一気に増えます。具体的には、次の二つです。

SSO + AssumeRole 方式なら、その前提を根本から変えられます。

• そもそも長期シークレットを PC に置かない ＝ AI に渡しうる「無期限の鍵」が存在しない。
• 使うのは数時間で自動失効する一時キー ＝ 漏れても被害範囲が桁違いに小さい。
• 入口で MFA 必須 ＝ エージェントが勝手に再認証することはできない。

2. アクセスキーと SSO + AssumeRole の比較

では、これまでのアクセスキー(長期キー)と、これからの SSO + スイッチロールは何が違うのか。観点ごとに並べると、差がはっきりします。

並べてみると、従来方式の弱点はどれも 「無期限の鍵が PC に分散して存在する」ことに根があると分かります。便利さと引き換えに、漏れたときの被害範囲が大きく、しかも気づきにくい。SSO + スイッチロールは、その前提自体を取り除きます。具体的な仕組みは、次章で見ていきます。

3. SSO + AssumeRole の構造

考え方はシンプルです。MOOBON の SSO に 1 回だけログインして身分を得て、そこから各クライアントのアカウントへ AssumeRole(スイッチ)して操作します。

あなた(MOOBON の SSO アカウント・MFA 必須)
        │  aws sso login(1 日 1 回くらい)
        ▼
[ MOOBON アカウント <MOOBON_ACCOUNT_ID> ]
        │  AssumeRole(スイッチ)
        ├──────────────► [ クライアント A ]  role: MoobonAdmin
        ├──────────────► [ クライアント B ]  role: MoobonAdmin
        └──────────────► [ クライアント C ]  role: MoobonAdmin

• 各クライアントのアカウントには、MOOBON を信頼する MoobonAdmin というロールを 1 つ用意します。
• そのロールは「MOOBON アカウントの人なら引き受けてよい」という信頼設定になっていて、鍵の受け渡しは不要です。
• クライアントのアカウントはそれぞれ独立(請求も各社のまま)。MOOBON の組織に取り込むわけではありません。

得られる認証情報は最長でも数時間で自動失効する一時キーです。PC に固定の鍵を残さず、必要なときだけその場で短命の鍵を得て使う ── これが全体像です。

設計の三本柱 ─ 一時キー / MFA / 信頼ポリシー

4. 前提 ─ Organization と Identity Center で SSO ログイン

MOOBON では SSO ログイン設定を数年前に実装していたので、今回は詳細な設定方法は割愛させていただきますが、やることは大きく次の流れです。

1. AWS Organizations を有効化 ── 複数アカウントを束ねる土台。すでに組織があればそのまま使えます。
2. IAM Identity Center(旧 AWS SSO)を有効化 ── リージョンは普段使う ap-northeast-1 を選びます(後から変えにくいので注意)。
3. アイデンティティソースを決める ── 最小構成なら Identity Center 内蔵ディレクトリで十分。既存の Google Workspace / Microsoft Entra ID などがあれば外部 IdP も選べます。
4. ユーザー(必要ならグループ)を作成 ── 担当者ぶんを登録します。
5. MFA を必須にする ── Identity Center の設定で「サインインごとに MFA を要求」に。本方式の安全性はここで担保するので、必須化は外せません。
6. Permission Set を作成 ── 付与する権限の束。まずは AdministratorAccess の Permission Set を 1 つ用意します(必要に応じて絞れます)。
7. アカウントに割り当て ── 作った Permission Set を「どの担当者が、どのアカウントで使えるか」に結びつけます(これを割り当てと呼びます)。これで担当者が MOOBON アカウントにログインできるようになります。なお、割り当てた Permission Set の名前(例: AdministratorAccess)が、次章の ~/.aws/config に書く sso_role_name の値になります。
8. start URL を控える ── Identity Center のダッシュボードに出るアクセスポータルの URL(https://d-xxxxxxxxxx.awsapps.com/start/)。次章の sso_start_url に使います。

ここまでで、start URL(https://d-xxxxxxxxxx.awsapps.com/start/)から、2 段階認証(MFA)を経て AWS コンソールに Administrator 権限でログインできるようになります。ただしこれは AWS 側(コンソール)までの話です。AI に AWS CLI を使わせるには、次章で手元の設定を行います。

5. 手元の設定 ─ ~/.aws/config に集約する

初期セットアップは最初の 1 回だけです。まず AWS CLI v2 を入れます。

# macOS
brew install awscli
aws --version   # aws-cli/2.x であること

設定はすべて ~/.aws/config に書きます。長期キーを置かないので、~/.aws/credentials にはもう何も書きません。

# ~/.aws/config

[sso-session moobon-sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start/
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access

# MOOBON 本体(あなたの身分)
[profile moobon]
sso_session = moobon-sso
sso_account_id = <MOOBON_ACCOUNT_ID>
sso_role_name = AdministratorAccess
region = ap-northeast-1

これで moobon プロファイルから自社アカウントを操作できます。クライアント(他社)アカウント用のプロファイルは、AssumeRole を説明する 7 章で追記します。

6. 日常の使い方 ─ sso login とプロファイル

ターミナルから SSO ログインする(トークンが切れた場合も)

aws sso login --profile moobon

ターミナルでコマンドを実行するとブラウザが開くので、IAM Identity Center で作成したアカウントでログインします。1 回ログインすれば数時間〜1 日有効です。期限が切れたらまた叩きます。

ログインしたプロファイルで AWS CLI が使えるか確認

コマンドにプロファイル名を付けて、実際に通るか試します。まずは自社アカウント(moobon)で、コマンドが返ってくるか確認します。

aws s3 ls --profile moobon
aws ec2 describe-instances --profile moobon

7. クライアント管理は AssumeRole で ─ 双方 Win-Win

ここからは、他社(クライアント)のアカウントを管理する場合の話です。クライアント側にも Organization と Identity Center を用意してもらい、そこに MOOBON 用の SSO ユーザーを作ってもらう方法もあります。ただ、クライアント全員にその構築・運用をお願いするのは現実的でなく、こちら側もクライアントの数だけ別のログインを抱えることになります。そこで使うのが AssumeRole(スイッチロール)です。次の利点があります。

• クライアント側の手間が最小:Identity Center の構築は不要。「MOOBON を信頼するロール」を 1 つ置いてもらうだけで済みます。
• 身分は 1 つのまま:ログイン済みの MOOBON の身分から、その場でスイッチするだけ。クライアントごとの別ログインは不要です。

この形は、クライアント側の負担が小さいだけでなく、弊社側の日々の運用も大きく楽になります。これまでのようにクライアントごとにユーザー名 × パスワード × 2 段階認証を管理する必要がなくなり、覚えるべき入口が 1 つに集約されるので、AWS CLI の利用も AWS コンソールへのログインも、ぐっとシンプルで扱いやすくなります。

それでは、設定の話に進みます。

① クライアント側に専用ロールを作る

クライアントの了承を得たうえで、そのアカウントに MoobonAdmin ロールを作ります。肝は信頼ポリシーです。「MOOBON アカウントからの引き受け(sts:AssumeRole)を許可する」と書くことで、鍵を渡さずにスイッチできるようになります。下記を trust-policy.json として保存します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<MOOBON_ACCOUNT_ID>:root" },
      "Action": "sts:AssumeRole"
    }
  ]
}

このポリシーでロールを作成し、権限(ここでは AdministratorAccess)を付与します。クライアントのアカウントで、一時的な管理権限を使って 1 回だけ実行します。

# クライアントのアカウントで(一時的な管理権限で)1 回だけ実行
aws iam create-role \
  --role-name MoobonAdmin \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name MoobonAdmin \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Principal に MOOBON アカウントの root を指定しているのは、「MOOBON アカウントの誰か」を信頼し、実際に誰が引き受けてよいかの判断を MOOBON 側の権限設定(SSO の Permission Set)に委ねる、という意味です。前提の Permission Set が sts:AssumeRole を許可していれば、これでスイッチが通ります。

② ~/.aws/config にクライアント用プロファイルを足す

作成したロールの ARN を、5 章の ~/.aws/config にスイッチ先のプロファイルとして追記します。

# ~/.aws/config に追記
# クライアントごとに 1 つずつ(スイッチ先)。role_arn の数字はそのクライアントのアカウント ID。
[profile clienta]
role_arn = arn:aws:iam::<CLIENT_ACCOUNT_ID>:role/MoobonAdmin
source_profile = moobon
region = ap-northeast-1

# [profile clientb] ... 以降、担当クライアントを同様に追加

ポイントは source_profile = moobon です。これが「MOOBON の身分を使ってスイッチする」という意味になります。クライアントを増やすときは、同じブロックを足していくだけです。

③ スイッチして操作する

あとは CLI にクライアントのプロファイル名を付けるだけ。スイッチ先の一時キーが自動で使われます。

aws s3 ls --profile clienta
aws ec2 describe-instances --profile clienta

8. AssumeRole を使用して AWS コンソールにログインする

AWS CLI だけでなく、クライアントのコンソールをブラウザ画面で開きたいこともあります。AssumeRole は Organization に所属する設定ではないので、SSO ログインページでクライアントの AWS アカウントが選択できるわけではありません。AWS コンソールへログインできないと思ってしまうのですが、実はこれも MOOBON の SSO にログインした状態から、スイッチしてコンソールを開くことができます。スイッチで得た一時キーからサインイン URL を生成するヘルパーを用意しておくと便利です。下記を ~/bin/aws-console として保存します。

#!/usr/bin/env bash
# 使い方: aws-console <プロファイル名>   例) aws-console clienta
set -euo pipefail
PROFILE="${1:?プロファイル名を指定}"

# トークンが切れていたら SSO ログインを促す
aws sts get-caller-identity --profile "$PROFILE" >/dev/null 2>&1 \
  || aws sso login --profile moobon

# スイッチ先の一時クレデンシャルを取り出し、federation 用のセッション JSON を組み立てる
# (--format process の中身は JSON。python3 一発でパース→URL エンコードまで行う)
CREDS=$(aws configure export-credentials --profile "$PROFILE" --format process)
SESSION=$(echo "$CREDS" | python3 -c '
import sys, json, urllib.parse
d = json.load(sys.stdin)
print(urllib.parse.quote(json.dumps({
    "sessionId": d["AccessKeyId"],
    "sessionKey": d["SecretAccessKey"],
    "sessionToken": d["SessionToken"]
})))
')

# federation のサインイントークンを取得 → ログイン URL を組み立てて開く
TOKEN=$(curl -s "https://signin.aws.amazon.com/federation?Action=getSigninToken&Session=$SESSION" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["SigninToken"])')
DEST=$(python3 -c "import urllib.parse;print(urllib.parse.quote('https://ap-northeast-1.console.aws.amazon.com/'))")
URL="https://signin.aws.amazon.com/federation?Action=login&Issuer=moobon&Destination=$DEST&SigninToken=$TOKEN"
echo "$URL"; open "$URL" 2>/dev/null || true

chmod +x ~/bin/aws-console
aws-console clienta     # → ブラウザでクライアント A のコンソールが開く(1 時間ほど有効)