CloudShell と IAM Identity Center (SSO)

第4章 CLI と SDK でローカルのセットアップを終えました。ここにもう2つの道具があります。一つは CloudShell で、コンソール内のブラウザターミナルです。ノートパソコンがなくても、一時環境でも即座に CLI を使えます。もう一つは IAM Identity Center (SSO) で、マルチアカウント / チーム運用の標準ログインです。永続的なアクセスキーをほぼなくします。

この2つは個人学習にはやや大げさですが、2つ目のアカウントや2人目の同僚が出てきたときに自然に使う道具です。あらかじめ知っておけば移行がぐっと滑らかになります。

本章は 第4章 の認証情報チェーンの上で、人がログインする流れをもう一段整理するトピックです。マルチアカウントのガバナンス自体は 第29章 セキュリティガバナンス で本格的に扱います。

CloudShell — ブラウザの中のターミナル #

コンソール右上の小さなターミナルアイコンが AWS CloudShell です。ログイン済みの状態ですぐに使えるシェルが開きます。

何が良いか #

• CLI があらかじめインストールされている — aws、python(boto3 を含む)、node、git。
• 認証情報が自動 — コンソールログインの認証情報がシェルにも接続され、aws configure が不要です。
• 1 GB の永続ホームディレクトリ — セッションを終了しても維持されます。
• 無料 — 使用時間 / 出力トラフィックの限度の中でです。

どこに良いか #

素早く使ってみる #

# 認証情報がすでに接続されている
aws sts get-caller-identity

# python もインストールされている
python3 -c "import boto3; print(boto3.client('s3').list_buckets()['Buckets'])"

# ホームディレクトリは 1 GB 永続
echo "hello" > ~/notes.txt
# セッションを終えて次にまた来ても ~/notes.txt は生きている

注意 — リージョン依存 #

CloudShell のホームディレクトリはリージョンごとに別々です。ソウルで作ったファイルは東京の CloudShell では見えません。そのため、通常は一つのリージョンで使うのが自然です。

ファイルのアップロード / ダウンロード #

CloudShell 右上のメニュー → Actions → Upload / Download file で受け取ります。小さいファイルはこれで、大きいファイルは S3 を経由します。

aws s3 cp my-data.zip s3://my-temp-bucket/
# 別の環境で:
aws s3 cp s3://my-temp-bucket/my-data.zip ./

IAM Identity Center (SSO) — それは何で、なぜ使うのか #

名前が何度も変わったサービスです。

AWS Single Sign-On (AWS SSO)  →  IAM Identity Center
                              (2022 年以降の標準名)

古い記事や資料では「AWS SSO」という名前で見かけることが多いですが、同じサービスです。

何を解くのか #

第2章 IAM で見た IAM ユーザーモデルには限界があります。

IAM Identity Center はこれをまとめます。

[従業員一人]
  └── SSO ポータル (ログイン一度)
       ├── prod アカウント / AdminAccess
       ├── prod アカウント / ReadOnly
       ├── staging アカウント / DeveloperAccess
       └── dev アカウント / DeveloperAccess

各アカウントで IAM ユーザーを作る代わりに、SSO が一時認証情報を発行してくれます。ローテーションが必要な永続キーもなくなります。

誰が使うのか #

• Organizations マルチアカウント — 事実上の標準です。
• 5人以上のチーム — ユーザー / 権限管理の負担が減ります。
• 無料 — Organizations と一緒に使うと追加費用がありません。

個人学習 / 単一アカウントにはやや大げさです。2つ目のアカウントが出てきた時点で導入するとちょうどいいです。

IAM Identity Center のセットアップ — 5段階 #

1) Organizations の有効化 #

IAM Identity Center は Organizations の上で作動します。単一アカウントでも Organizations の有効化は無料です。

コンソール → AWS Organizations → "Create an organization"

2) IAM Identity Center の有効化 #

コンソール → IAM Identity Center → "Enable"

リージョンを一度選ぶと変更が難しいので慎重にします。通常は運用の主リージョン(ソウルなら ap-northeast-2)にします。

3) ユーザー / グループを作る #

デフォルトの自前ディレクトリ(Identity store)、または外部 IdP(Google Workspace、Microsoft Entra、Okta など)を連携します。

IAM Identity Center → Users → Add user
- メール / 名前を入力
- 招待メールを送信 → パスワード + MFA のセットアップ

Admins
Developers
ReadOnly
Billing

4) Permission Set を作る #

Permission Set は 第2章 IAM のポリシーの束にセッション時間と追加オプションを加えた単位です。

セッション時間は通常1 ~ 12時間(デフォルト1時間)です。運用用は短く(2時間)、日常開発は8時間にします。

5) Account Assignment — 誰が + どこ + 何を #

IAM Identity Center → AWS accounts
- アカウントを選択 (例: prod)
- "Assign users or groups"
- Group: Developers + Permission Set: PowerUserDeveloperAccess

この3つが集まる形はグループ × アカウント × Permission Set です。Developers グループが prod アカウントに PowerUser として入ります。

SSO ポータルの使用の流れ #

従業員の立場での流れは次のとおりです。

1. 開始 URL(例: https://my-org.awsapps.com/start)へ接続します。
2. パスワードと MFA を入力します。
3. 自分に割り当てられたアカウント + Permission Set のリストが見えます。
4. 各項目の隣の「Management console」のクリックで、そのアカウントのコンソールに自動ログインします。
5. 「Command line / programmatic access」をクリックすると CLI 認証情報の案内を受け取ります。

CLI で SSO ログイン #

aws cli v2 が SSO をネイティブにサポートします。第4章 CLI と SDK でしたことを SSO でやり直します。

aws configure sso
# SSO session name (Recommended): my-org
# SSO start URL [None]: https://my-org.awsapps.com/start
# SSO region [None]: ap-northeast-2
# SSO registration scopes [sso:account:access]:
# ブラウザが開いてログイン → 権限の同意 →
# Available accounts:
#   prod (123456789012)
#   staging (...)
#   dev (...)
# Choose an account ID: prod
# Choose a role: PowerUserDeveloperAccess
# CLI default Region: ap-northeast-2
# CLI profile name: prod

設定後 ~/.aws/config に次のように入ります。

[sso-session my-org]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-northeast-2
sso_registration_scopes = sso:account:access

[profile prod]
sso_session = my-org
sso_account_id = 123456789012
sso_role_name = PowerUserDeveloperAccess
region = ap-northeast-2

日常の流れ #

aws sso login --profile prod
# ブラウザが開く → ログイン → 認証情報キャッシュ

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

セッションは通常8 ~ 12時間です。切れたら再び aws sso login します。

複数のアカウントに一度にログイン #

my-org という sso-session 一つに複数のプロファイルを束ねると、一度の aws sso login ですべてログインされます。

[sso-session my-org]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-northeast-2
sso_registration_scopes = sso:account:access

[profile prod]
sso_session = my-org
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = ap-northeast-2

[profile staging]
sso_session = my-org
sso_account_id = 222222222222
sso_role_name = PowerUserDeveloperAccess
region = ap-northeast-2

[profile dev]
sso_session = my-org
sso_account_id = 333333333333
sso_role_name = PowerUserDeveloperAccess
region = ap-northeast-2

aws sso login --sso-session my-org
aws s3 ls --profile prod
aws s3 ls --profile staging
aws s3 ls --profile dev

IAM ユーザーモデル vs SSO モデル #

いつ何を使うかを一つの表で整理します。

CI/CD の場合、IAM Identity Center が自前のサービス認証情報を与えるわけではありません。そのため GitHub Actions や GitLab は OIDC で IAM Role を直接借りるパターンが標準です(第24章 CI/CD パイプライン で扱います)。

現実的なマイグレーションの順序 #

すでに IAM ユーザーを使っている環境から SSO へ移す順序です。

1. Organizations の有効化(単一アカウントでも無料)
2. IAM Identity Center の有効化 + 最初のユーザー / グループ / Permission Set
3. 自分からまず SSO へ転換 — 1 ~ 2週間の並行運用
4. 同僚たちを SSO に招待
5. IAM ユーザーの Console access を無効化 — SSO へ強制
6. IAM ユーザーのアクセスキー — 自動化は OIDC / インスタンスプロファイルへ移し、ユーザーのアクセスキーは段階的に廃止
7. 結果: 人はすべて SSO、マシンはすべて Role

この順序が1ヶ月 ~ 四半期で自然に進行します。

CloudShell + SSO の出会い #

コンソールに SSO でログインしたら、その環境で CloudShell を開くと SSO の一時認証情報がシェルに接続されます。認証情報を扱うことなく即座に作業します。

aws sts get-caller-identity
# Arn: arn:aws:sts::123:assumed-role/AWSReservedSSO_AdministratorAccess_xxx/email@example.com
# (assumed-role — 永続的なユーザーではなく SSO の一時認証情報)

この環境は一時認証情報が自動的に更新されます。小さな点検や一回限りの作業に非常に便利です。

よく出会う落とし穴 #

• 古い名前「AWS SSO」の痕跡 — 資料やコンソールの一部で古い名前が見えます。同じサービスなので混乱しません。CLI の aws configure sso は新しい名前基準です。
• 最初の有効化リージョンを間違って選ぶ — IAM Identity Center は有効化リージョンを後で変えるのが非常に難しいです。通常は運用の主リージョンか us-east-1 のどちらかです。会社が韓国中心ならソウル(ap-northeast-2)です。
• Permission Set のセッションが長すぎるか短すぎる — 12時間で長すぎると漏洩時に危険で、1時間で短すぎると毎時間ログインしなければなりません。日常開発は4 ~ 8時間、運用作業は1 ~ 2時間がよくあります。
• aws sso login のブラウザの自動オープンができない — サーバー / コンテナ / SSH 環境です。このとき aws sso login --no-browser を使うと URL とコードを出力するので、別の機器で開いて認証します。
• CloudShell の 1 GB 限度 — 大きなデータや一時ビルドを CloudShell の中に累積すると、限度超過で動作が拒否されます。定期的に掃除するか S3 へ移します。
• IAM ユーザーのアクセスキーと SSO が同時に — 転換中の環境では両方が生きています。第4章 の認証情報チェーンで、どの認証情報で動いているかを常に確認します。aws sts get-caller-identity が答えです。
• Permission Set の中の IAM ポリシーの制限 — Permission Set は結局 IAM Role を作って束ねる方式です。一つの Permission Set にあまりに多くのポリシーやインラインポリシーを入れると、IAM Role のポリシー限度に引っかかります。過ぎれば分離します。

練習問題 #

1. §「どこに良いか」の表を根拠に、自分が最近した作業3つを CloudShell とローカルのどちらでするのが適切かを分類し、その理由を一文ずつ書いてみましょう。
2. §「IAM Identity Center のセットアップ — 5段階」を見ずに順番に書いてみましょう。各段階が 第2章 IAM のどの要素(ユーザー · グループ · ポリシー)と対応するかを結びつけておきましょう。
3. §「IAM ユーザーモデル vs SSO モデル」の表で CI/CD の行を根拠に、GitHub Actions が永続的なアクセスキーの代わりに OIDC + Role を使う理由を 第24章 CI/CD パイプライン と結びつけて一段落で説明してみましょう。

一行まとめ: CloudShell はコンソール内の無料ブラウザターミナルで、認証情報が自動接続され 1 GB の永続ホームを持ち、リージョンごとに別々です。IAM Identity Center はマルチアカウント / チームログインの標準で、一度ログインすれば複数のアカウントに一時認証情報を発行して永続的なアクセスキーをほぼなくします。人は SSO、マシンは Role へ行くのがマイグレーションの終着点です。

次の章 #

コンソールと CLI、SSO まで、セットアップが終わりました。次の 第6章 セキュリティ基本 では、セキュリティの基礎をもう一度しっかり固めます。MFA 強制、アクセスキーのローテーション、最小権限のパターン、そしてよく出会う事故事例まで — 第2章 IAM のポリシーの上に、運用で通用するセキュリティのガードレールを整理します。