はじめに

私が所属している組織では以前までIAMユーザーとスイッチロールを組み合わせて運用していました。しかし、AWS Organizations配下のアカウントが増えるにつれ、権限管理の煩雑さやセキュリティリスク(退職者の権限無効化忘れ、credentialsの漏洩リスクなど) が大きな課題になっていました。

そこで、AWS Identity and Access Management のセキュリティのベストプラクティスにある「ユーザーはフェデレーション(認証連携)を使用する」という原則に則り、IAM Identity Centerによるアカウント管理の一元化を実施しました。

本記事では外部IDプロバイダーとしてGoogle Workspace(以下、GW)を IdP(Identity Provider)として統合する際の要点。また導入時にぶつかった「仕様の壁」への対処方法、そして業務効率を高めるユーザ管理方法について記載します。

1. Google Workspace × IAM Identity Centerの連携手順

まずは、基本的な連携の流れを整理します。公式ドキュメント「Google Workspace および IAM アイデンティティセンターによる SAML と SCIM の設定」に沿いつつポイントを掻い摘んでご説明します。

①：SAMLアプリケーションの設定(認証の連携)

GW管理コンソールからAWS用のSAMLアプリを作成し、互いの情報を交換・登録します。

GW側で発行され、AWS側へ登録する情報:
- SSO URL
- エンティティID
- 証明書(.pem)
AWS側で発行され、GW側へ登録する情報:
- ACS URL(Assertion Consumer Service URL)
- IAM Identity Center発行者URL

②：自動プロビジョニング(SCIM)の設定(ユーザーの同期)

ユーザー情報をGWからAWSへ自動同期させるため、SCIMの設定を行います。

AWS側での準備:
自動プロビジョニングを有効化し、「SCIMエンドポイント」と「アクセストークン」を生成・取得します。
GW側での設定:
上記2つの情報をGWアプリの「自動プロビジョニング」設定に入力します。
実運用のポイント:
GWにて同期対象とするグループ(例：aws-users)を作成し、SAMLアプリのアクセス対象として割り当てます。今後、このGWグループにユーザーを追加するだけで、AWS側にユーザーアカウントが自動作成(プロビジョニング)されるようになります。

2. [課題1] SCIM連携における「グループが同期されない」問題

設定が完了し、無事にユーザー情報がAWS側に同期されました。「あとは権限を割り当てるためにグループを作るだけだ」と思い、AWSマネジメントコンソールを開いたところ、問題が発生しました。

IAM Identity Centerのコンソール画面から「グループの作成やユーザーの追加操作ができなくなっていた」のです。

調べてみるとGWの標準機能でSCIMを有効化した場合「ユーザーは同期されるが、グループの同期はサポートされておらず」。また自動プロビジョニングが有効な状態では、AWS側の仕様としてコンソールからのグループ操作が制限(グレーアウト)されていました。

💡 エビデンス:
AWSの公式ガイドラインでも、Google WorkspaceはSCIM経由でのユーザー同期のみサポート(グループ同期は非対応)と明記されています。

参考文献: AWS Prescriptive Guidance の AWS IAM Identity Center

「ユーザーのアカウント自体は自動で同期されるのに、グループに所属させることができない」というジレンマに陥りました。そこで後述する方法にて対処しました。

2-1. グループの追加(AWS CLI)

グループの作成は、AWSコンソール右上のアイコンから起動できる CloudShell 上でAWS CLIを用いて行います。
事前に以下のIDを控えておきます。

a. Identity Store ID: [IAM Identity Center] - [Identity source]タブ内の Identity Store ID をメモしておく
b. グループの作成

$ aws identitystore create-group \
--identity-store-id <Identity Store ID> \
--display-name <任意グループ名>

※実行結果として出力される GroupId を控えておきます(作成後はAWSコンソールのGroup一覧からも同IDを確認出来るようになります)

2-2. グループへの権限付与(AWSコンソール)

グループさえ作成できれば、権限(Permission set)の割り当てはコンソールから可能です。

権限付与
[IAM Identity Center] - [AWS accounts] にて、対象のAWSアカウントと先程作成したグループを選択し、適切なPermission set(AWSAdministratorAccess や AWSReadOnlyAccess など)をアサインします。

3. [課題2] グループへのユーザ追加

作成および権限を付与したグループにユーザーを追加します。

3-1. グループにユーザ追加(AWS CLI)

単一のユーザーを追加する場合は以下のコマンドで可能です。

$ aws identitystore create-group-membership \
  --identity-store-id <Identity Store ID> \
  --group-id <対象グループの GroupId> \
  --member-id UserId=<対象ユーザーの UserId>

💡しかし、対象ユーザーが数十人いる場合、このコマンドを1ユーザーごとに実行するのは非常に手間です。

3-2. グループにユーザ追加(一括登録)

AWS Security Blogにて、まさにこの課題を解決する方法が公開されていました。

How to bulk import users and groups from CSV into AWS IAM Identity Center

この記事に従い「PowerShellスクリプトによるユーザーとグループの一括紐付け」を行うことで、運用コストを劇的に下げることが出来ました。

■ 準備

上述したAWS Security Blog提供のテンプレート(csv) と 登録スクリプト(create_users.ps1)を取得し、下記編集を行う

PowerShellスクリプトの変数を設定

#Input SCIM configuration and CSV file location
$Url = "<SCIMENDPOINT>"        # 例: https://scim.ap-northeast-1.amazonaws.com/
$Bearertoken = "<BEARERTOKEN>" # 例: SCIM設定時に発行されたアクセストークン
$CSVfile = "<CSVLOCATION>"     # 例: "./iamidentity-users.csv"
$Headers = @{ Authorization = "Bearer $Bearertoken" }

登録するユーザとグループを記載したCSVファイルを用意

■ 実行手順

AWSコンソールからCloudShellを開く
[アクション]メニューをクリックして[Upload file]を選択し、スクリプトと CSVをアップロードする
※ アップロードしたファイルは、CloudShellのホームディレクトリに配置されます

ファイルの確認:

$ pwd
/home/cloudshell-user

$ find . -name "*.csv" -o -name "*.ps1"

スクリプト実行:

$ pwsh -File create_users.ps1

残作業:

登録完了後、ユーザ情報を含むcsv とスクリプトファイルを念のためCloudShell上から削除しておきます

# ファイルの削除コマンド
$ rm iamidentity-users.csv create_users.ps1

4. Googleアカウントでのログイン確認

ここまでの設定で、ユーザーに権限が割り当てられました。
実際にAWSアクセスポータル(https://example.awsapps.com/start/#/)へアクセスし、Googleアカウントの認証でログインします。

ログイン後、対象AWSアカウントに対して、設定した権限(Administrator や ReadOnly) のロールが表示され、マネジメントコンソールへ遷移できることを確認します。

5. 運用フェーズ：CLIでの利便性を高める設定

連携が確立しましたら、開発者が快適にAWSを利用できるようCLIの設定(~/.aws/config)を配布・案内しましょう。sso-session 形式を利用すると一度のブラウザログインで複数のプロファイルを使い分けられます。

SSOプロファイルの設定例(~/.aws/config)

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

[profile dev-admin]
sso_session = google-idp
sso_account_id = 123456789012
sso_role_name = AWSAdministratorAccess
region = ap-northeast-1

[profile prd-readonly]
sso_session = google-idp
sso_account_id = 987654321098
sso_role_name = AWSReadOnlyAccess
region = ap-northeast-1

利用方法

# 1. SSOログイン (ブラウザが立ち上がり、Googleアカウントで認証)
$ aws sso login --sso-session google-idp

# 2. AWS Profile指定 (環境変数を切り替えて各アカウントへアクセス)
$ export AWS_PROFILE=dev-admin
$ aws s3 ls

さらなるセキュリティ強化の取り組み

IdP連携だけでなく、ベストプラクティスに準拠するため以下の設定も併せて運用しています。

MFA(多要素認証)の強制:
AWS側ではなく、IdPであるGoogle Workspace側で強固なMFA(パスワード＋多要素認証)を必須化し、セキュアなログインプロセスを担保しています。
最小権限の原則 (Least Privilege):
当初はAdministratorとReadOnlyのみでしたが、現在はインラインポリシーなどを活用し、開発アカウントごとに必要な権限だけを定義したカスタムPermission setを付与しています。
セッション時間の最適化:
万が一のセッションハイジャックや離席時のリスクに備え、Permission setのセッション期間は安全側に倒して「一律1時間」としています。(作業内容によっては今後柔軟に見直す予定です)

おわりに

「SCIMを有効にするとコンソールからグループ操作ができない」という罠に直面したときは焦りましたが、公式の一次情報を辿ることで、CLIとスクリプトを組み合わせた確実な運用フローを確立することができました。

将来的には、AWS Labsが公開している ssosync ¹ を用いた完全自動化や、Terraform等によるIaC管理など、よりモダンな運用へステップアップしていければと考えています。

この記事が、同じようにIAM Identity CenterとGoogle Workspaceの連携で悩んでいる方の助けになれば幸いです。最後までお読みいただき、ありがとうございました。

ssosyncについて: GWのAPI経由でグループ情報を取得し、AWS側へ自動反映させるオープンソースのLambdaアプリケーションになります。 ↩