AWS基礎 #5 CloudShell と IAM Identity Center (SSO)

#4 AWS CLI でローカルセットアップが終わりました。さらに 2 つのツールがあります。

• CloudShell — コンソール内のブラウザターミナル。ノート PC がなくても、一時的な環境でもすぐ CLI を使えます。
• IAM Identity Center (SSO) — マルチアカウント / チーム運用の標準ログイン。永続アクセスキーをほぼなくします。

この 2 つは 1 人での学習にはやや過剰ですが、2 つ目のアカウント / 2 人目の同僚 が登場する瞬間に自然に出会うツールです。先に知っておけば 1 段階スムーズに移行できます。

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 では見えません。なので普通は 1 つのリージョンで使うのが自然です。

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

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 Identity Center はこれを 1 ヶ所 にまとめます。

[社員 1 人]
  └── SSO ポータル (1 回のログイン)
       ├── prod アカウント / AdminAccess
       ├── prod アカウント / ReadOnly
       ├── staging アカウント / DeveloperAccess
       └── dev アカウント / DeveloperAccess

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

誰が使うか #

• Organizations のマルチアカウント — 事実上の標準
• チーム 5 名以上 — ユーザー / 権限管理コスト削減
• 無料 — Organizations と一緒に使えば追加コストなし

1 人での学習 / 単一アカウントには少し過剰です。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-1)。

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 のポリシー束 + セッション時間 + 追加オプションの単位。

セッション時間は普通 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 でやったことを 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-1
# 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-1
# CLI profile name: prod

設定後 ~/.aws/config に:

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

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

日常の流れ #

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 1 つに複数のプロファイルを束ねれば、1 回の aws sso login ですべてログイン。

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

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

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

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

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 モデル #

いつ何を使うかを 1 つの表で。

CI / CD の場合 — IAM Identity Center が独自にサービス用認証を出すわけではないので、GitHub Actions / GitLab は OIDC で IAM Role を直接借りるパターン が標準 (実践 #3 で扱います)。

現実的な移行順序 #

すでに 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 の一時認証情報)

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

よく出会う落とし穴 #

1) 古い名前「AWS SSO」の痕跡 #

資料 / コンソールの一部に古い名前が見えます。同じサービスなので混同しないでください。CLI の aws configure sso は新名称ベースです。

2) 最初の有効化リージョンを間違える #

IAM Identity Center は 有効化リージョンを後で変えるのが非常に難しい。普通は運用メインリージョン / us-east-1 のいずれか。会社が日本中心なら東京 (ap-northeast-1)。

3) Permission Set のセッションが長すぎる / 短すぎる #

12 時間に長すぎると漏洩時に危険、1 時間に短すぎると毎時間ログインが必要です。日常開発 4~8 時間、本番作業 1~2 時間が一般的です。

4) aws sso login のブラウザ自動起動が動かない #

サーバー / コンテナ / SSH 環境。このとき aws sso login --no-browser を使うと URL + コードを出力 → 別の機器で開いて認証。

5) CloudShell の 1 GB 上限 #

大きなデータ / 一時ビルドを CloudShell に貯めると上限超過で動作拒否されます。定期的に掃除するか S3 に移します。

6) IAM ユーザーアクセスキーと SSO が同時に #

移行中の環境では両方が生きています。認証情報チェーン (#4) でどの認証情報が動いているか常に確認します。aws sts get-caller-identity が答えです。

7) Permission Set 内の IAM ポリシー上限 #

Permission Set は結局 IAM Role を作って束ねる仕組みです。1 つの Permission Set にあまりに多くのポリシー / インラインポリシーを入れると IAM Role のポリシー上限に引っかかります。過剰なら分離します。

まとめ #

今回つかんだもの:

• CloudShell — コンソール右上のブラウザターミナル。CLI / Python / git 入り、認証情報自動、1 GB 永続ホーム、無料
• リージョンごとに別、大きなデータは S3 経由
• IAM Identity Center (旧 AWS SSO) — マルチアカウント / チームログインの標準
• 1 回ログイン → 複数アカウント / Permission Set の一時認証情報
• 永続アクセスキーをほぼなくします
• セットアップ — Organizations → Identity Center 有効化 → ユーザー / グループ → Permission Set → アカウント割り当て
• CLI 統合 — aws configure sso + ~/.aws/config の sso-session、aws sso login 1 回
• 移行 — Organizations → SSO 有効化 → 自分が移行 → チーム → IAM ユーザー Console 無効化 → キー廃止
• 落とし穴 — 古い名前の痕跡、有効化リージョンの変更困難、セッション時間バランス、–no-browser オプション、CloudShell の上限、両方の認証情報同時

次回 — セキュリティの基本 #

コンソール / CLI / SSO までセットアップが終わりました。次は セキュリティの基礎 をもう一段かたく — MFA 強制、アクセスキーローテーション、最小権限パターン、そしてよく出会う事故事例まで。

#6 セキュリティの基本 — MFA、キーローテーション、最小権限 では #2 IAM のポリシーの上に、運用で通用するセキュリティのガードレールを整理します。