0.はじめに
概要
- 本記事は前半 (AWS側) と後半 (IDaaS側) の2部構成です。
- こちらは後半 (IDaaS側) です。前半 (AWS側) はこちら。
- この記事では、社内でIDaaSからAWSへのシングルサインオン (以下、SSO) および案件で利用する各AWSアカウントへのスイッチロールを連携させた際の背景や手順などを紹介します。
- 多数のWebサービスとAWSアカウントを抱え、ユーザー管理に頭を悩ませているシステム管理者の方に読んでいただければと思っています。
1. 大まかな流れ
- 2部構成で、本記事ではIDaaS側で実施する内容を記載しています。
- 弊社ではCloudGateを利用していますが、おそらくは他のIDaaSでも実施内容は概ね同じかと思います。
AWS側
- 踏み台となるAWSアカウントの用意
- IAM Identity Centerの設定
- スイッチロール作成
- → 前の記事へ
IDaaS側 (この記事ではCloudGate UNO)
- サービスプロバイダーの追加
- 既存ユーザーのプロビジョニング
3. IDaaS側
- この記事ではCloudGate UNOについてご説明しますが、細かい設定箇所などはIDaaSによるかと思います。他のIDaaSをご利用の方は適宜読み替えて進めてください。
3-1. サービスプロバイダーの追加
-
CloudGateのAdmin Siteで「設定」メニューの「サービスプロバイダー」から「サービスプロバイダー追加」をクリック
-
サービス名「aws」で検索
-
「Custom Service AWS Single Sign-On SAML2.0」の「+追加」をクリック
- 表示名は任意のものを入力
-
「シングルサインオン」タブで下記を入力して「保存」をクリック
- 「Issuer / Provider name / Entity ID」：AWSの「アイデンティティソースの登録」でメモしたIAM Identity Center Assertion Consumer Service (ACS) の URL
- 「Assertion consumer service URL」：AWSの「アイデンティティソースの登録」でメモした「IAM Identity Center Assertion Consumer Service (ACS) の URL」
- 「Name IDの形式」：
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressを選択 - 「シングルサインオフの設定 - サインオフ方法」：「なし」を選択
- 上記以外は CloudGate HelpCenter - Amazon Web Services SSO連携設定 を参照しながら設定してください。
-
「プロビジョニング設定」タブで下記を入力して「保存」をクリック
- ベースURI：AWSの自動プロビジョニング有効化の際にメモした「SCIMエンドポイント」
- OAuth ベアラートークン：AWSの自動プロビジョニング有効化の際にメモした「アクセストークン」
- アカウントプロビジョニング：Off → On
- 「対象とマッピング」の「アカウントプロビジョニング」について、以下を必要に応じて追加
- 姓 → familyName
- 名 → givenName
- 表示名 → displayName
3-2. 既存ユーザーのプロビジョニング
- CloudGateのAdmin Siteで「設定」メニューの「サービスプロバイダー」から3-1. で追加したサービスプロバイダの下に表示される「プロビジョニング [同期する]」ボタンをクリックする
- 「レポート」メニューの「認証ログ」から「プロビジョニング履歴」タブをクリックする
- 既存のすべてのユーザーについて、3-1. で追加したサービスプロバイダの名称の「イベント：ユーザー作成」が「成功」で完了していることを確認する
3-3. 新たにIDaaSに追加したユーザーのプロビジョニング
- CloudGateのAdmin Siteで「アカウント管理」メニューの「ユーザー」から「＋作成」をクリックする
- 「サービス」にて、3-1. で追加したサービスプロバイダにチェックを入れる
- 「作成」ボタンをクリックする
- 「レポート」メニューの「認証ログ」から「プロビジョニング履歴」タブをクリックする
- 追加したユーザーについて、3-1. で追加したサービスプロバイダの名称の「イベント：ユーザー作成」が「成功」で完了していることを確認する
3-4. アカウント間のスイッチロールについて
- 弊社では、作成するすべてのアカウントについて下記のIAMロール作成用CFnテンプレートを適用する運用としました。
- システム管理者用ロール
- インフラ構築用ロール
- 開発者用ロール
- 細かい内容は割愛しますが、これらのテンプレートはパラメータにて、誰がどのロールに属するかをメールアドレスにて指定することができます。
- ご参考までに、システム管理者用ロールのCFnテンプレートを公開します。 ※. 公開にあたり、一部値を書き換えています。
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Switch role for SystemAdministratorRole'
Parameters:
CompanyAccountID:
Type: String
Default: '01234567890'
CompanyRoleName:
Type: String
Default: 'company_role_name'
RoleName:
Type: String
Default: 'SystemAdministratorRole'
InitialUserNames:
Type: CommaDelimitedList
Conditions:
AddConction: !Not [ !Equals [ "" , !Join [",", !Ref InitialUserNames ] ] ]
Resources:
# Administrator Role
AdministratorRole:
Type: AWS::IAM::Role
Properties:
RoleName: !Ref RoleName
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
AWS: !Sub "arn:aws:iam::${CompanyAccountID}:role/aws-reserved/sso.amazonaws.com/${AWS::Region}/${CompanyRoleName}"
Action:
- sts:AssumeRole
- sts:SetSourceIdentity
Condition:
StringEquals:
aws:PrincipalTag/userName: !If
- AddConction
- !Ref InitialUserNames
- "foo@example.com"
Path: "/"
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AdministratorAccess
4. まとめ
- いかがでしょうか。弊社ではこの仕組みでAWSアカウントへのアクセス方法を一元化するまで、個々の社員にAWSアカウント別のIAMユーザー管理を一任していました。社内には20を超えるAWSアカウントが存在していて、社員は複数のAWSアカウントに所属していたので、IAMユーザー数だけで考えても膨大な数が存在していたことになります。
- この仕組みを導入したことにより、以下のメリットが得られました。
- IDaaS内で社員数分のIDを管理するだけで良くなった
- 仮に退職者のスイッチロール許可の更新を忘れたとしてもその前段のSSOがそもそもできないので、セキュリティリスクも低減
- 社員の増減に応じてAWSのIAMユーザーを個別のアカウントに用意する手間も減った
- IDaaS内で社員数分のIDを管理するだけで良くなった
- CloudGate UNOではGoogle Workspace、AWS以外にもMicrosoft 365やSlackなど当社で利用中の他サービスにも連携しているため、他サービスでも利用を広げていき社内のID管理を一元化していけたらいいのかなと思います。