はじめに
先日、会社の AWS Organizations で AWS Single Sign-On（SSO）を利用できるようにしました。
既存の AWS アカウントが 40 個ほどあり、一気にすべてのアカウントで AWS SSO の利用を強制することは難しかったので、とりあえず新規のアカウントから AWS SSO を使ってもらうことにしました。
ちょうど今週、初申請があったので、記念に記事にしようと思います。
AWS SSO を導入するといっても、組織の規模によって使い方が異なると思います。
ちなみに筆者の会社は受託開発を事業の柱にしていて、スタッフは 300 人ほどです（全員が AWS ユーザーなわけではありません）。
AWS アカウントは、おおよそ顧客単位で分かれています。
みなさんもこの記事を参考にご自身の組織に合った利用方法を見つけていただければ幸いです。
導入のきっかけ
筆者の会社では、コロナ禍で在宅ワークが前提になり、以前からセキュリティ対策の強化が課題でして、1 つのシングルサインオンサービスからあらゆる Web サービスにユーザー認証できる状態を目指していました。
AWS では個々のアカウント毎にシングルサインオンサービスとの紐づけが可能なことは知っていたのですが、アカウントが 40 個ほどあるので設定が面倒だと感じていたところに、（遅ればせながら） AWS SSO を見つけたので提案することにしました。
AWS SSO のメリット
AWS SSO には下記のようなメリットがあります。
- マスターアカウント上に作成した AWS SSO ユーザーですべての AWS アカウントにサインインできる
- AWS 以外の ID プロバイダー（Azure 等）のユーザーを丸々同期して持って来ることも可能
- スタッフ退職時のユーザー削除が楽
- API キーがセッション単位で自動生成されるため、自分で更新する必要がない
- 各アカウントの IAM ユーザーの場合、自分で API キーを更新する必要がある
- 各アカウントで誰がどんな権限を持っているか一目できる
- サインイン時にシングルサインオンサービスのアクセスポリシーを適用できる
筆者の会社では、Azure を ID プロバイダーとし、Azure ユーザーで AWS を使えるようにしています。
IAM ユーザーは使わないのか
AWS SSO のメリットを最大限に活かすためにも、弊社のスタッフには AWS SSO ユーザーで認証してもらい各アカウントの IAM ユーザーは基本的に利用しない方針としましたが、下記の場合は例外として IAM ユーザーを使ってよいことにしました。
外部ユーザー
過去に、データを受領する場合等、顧客や協業する他ベンダーの担当者に自社 AWS アカウントにアクセスしてもらいたいケースがありました。
ほとんどの場合、そういった方々は ID プロバイダーにユーザーがいないので AWS SSO は使えません。
ID プロバイダーにユーザーを用意するにしても、自社スタッフとはアクセスポリシーを分ける必要がある等、設定が煩雑になります。
ということで、弊社では個々の AWS アカウント内に外部ユーザー用の IAM ユーザーを作成してよいことにしました。
バッチユーザー
S3 からデータを取得して Redshift にインポートする処理を EC2 から定期的に実行したい場合、EC2 のサービスロールを作成したりしますが、同じような感覚で、特定のスタッフに紐づかない共通の IAM ユーザーを作成してよいことにしました。
運用体制はどうするか
筆者の会社では AWS ユーザーを3区分に分類しています。
| 役割名 | 想定人数 | 主な役割 |
|---|---|---|
| アカウント管理者 | 2～3人 | AWS アカウントの作成や削除。ルートユーザーの管理。AWS Organizations の全体管理。プロジェクトへのコストの請求。 |
| リソース管理者 | 数十人 | 割り当てられた AWS アカウントの管理。コスト監視。各種リソースのセキュリティ設定。一般ユーザーの権限調整。AWS アカウントの作成や削除の申請。 |
| 一般ユーザー | 数百人 | 特定の AWS アカウントにおいて、そのアカウントのリソース管理者が決めた権限の範囲内で AWS を操作。 |
リソース管理者は通常、プロジェクトからスキルマッチしたスタッフを割り当てます。
リソース管理者から AWS アカウントの作成申請があれば、アカウント管理者が AWS アカウントを作成し、リソース管理者にそのアカウントで一番強い権限を付与する仕組みにしています。
一般ユーザーの権限は誰が設定するか
一番難しかったのは、一般ユーザーの権限を誰が設定するのかという点でした。
リソース管理者に任せる場合、マスターアカウントで AWS SSO を操作する権限を付与する必要がありますが、リソース管理者は将来的に何十人にもなる想定だったので、そんな大人数に AWS SSO を操作させることに何となく抵抗がありました。
そのため、当初の提案では、リソース管理者の申請に基づきアカウント管理者が一般ユーザーの権限を設定する仕組みにしていました。
ところが現場マネージャー陣へのレビューのタイミングで「アカウント管理者の作業が増えて運用が回らない」と指摘され、再検討することになりました。
たしかに AWS の権限は実際に動かしながら調整することがほとんどですし、徐々に利用するサービスの種類が増えてそれに合わせて権限も広げていかないといけないことが多いと思います。
ということで、最終的にリソース管理者が AWS SSO を操作し、自分の AWS アカウントに一般ユーザーを割り当てたり、一般ユーザーの権限を編集できるようにしました。
リソース管理者に AWS SSO の操作をどこまで許すか
AWS SSO では AWS アカウント、ユーザー、アクセス権限セットの3つを組み合わせることで「どのアカウントで誰が何をできるのか」を設定しますが、リソース管理者にアクセス権限セットの作成や削除を許可してしまうとアクセス権限セットがぐちゃぐちゃになってしまう懸念があったため、アクセス権限セットを作成したり削除できるのはアカウント管理者のみとしました。
つまり、アカウント管理者はアカウント毎に専用の一般ユーザー用アクセス権限セットを作成し、リソース管理者は自分のアカウント用に作成された一般ユーザー用のアクセス権限セットを編集することで一般ユーザーの権限を調整できるようにしました。
一般ユーザー用のアクセス権限セットはデフォルトで3つとし、申請で増やせるようにしました。
このとき、リソース管理者が担当外のアカウントに一般ユーザーを割り当ててしまったり、担当外のアカウントの一般ユーザー用アクセス権限セットを編集してしまったりできないようにする必要がありました。
それを実現するために、リソース管理者が AWS SSO を操作するためのアクセス権限セットにおいて、一般ユーザーの割り当てが可能なアカウントを担当アカウントのみにし、編集可能な一般ユーザー用アクセス権限セットを担当アカウント用に作成されたもののみに限定しました。
なお、リソース管理者の向学のために、担当外のアカウントの一般ユーザー用アクセス権限セットも閲覧はできるようにしています。
アクセス権限セットの使い分け
以上を実現するために下表のとおりアクセス権限セットを使っています。
| No. | アクセス権限セット名 | 割り当て先アカウント | 割り当てる人 | 割り当てられる人 |
|---|---|---|---|---|
| 1 | アカウント管理者権限 | すべてのアカウント | アカウント管理者 | アカウント管理者 |
| 2 | リソース管理者権限 | 担当するメンバーアカウント | アカウント管理者 | リソース管理者 |
| 3 | 一般ユーザー割り当て用権限（〇〇アカウント用） | マスターアカウント | アカウント管理者 | リソース管理者 |
| 4 | 一般ユーザー権限①（〇〇アカウント用） | 担当するメンバーアカウント | リソース管理者 | 一般ユーザー |
| 5 | 一般ユーザー権限②（〇〇アカウント用） | 担当するメンバーアカウント | リソース管理者 | 一般ユーザー |
| 6 | 一般ユーザー権限③（〇〇アカウント用） | 担当するメンバーアカウント | リソース管理者 | 一般ユーザー |
なお、アカウント管理者の作業（1～6の作成と1～3のリソース管理者への割り当て）は PowerShell で自動化しました。
実際に一番大変だったのは
マニュアル作成が大変でした。
この記事でも言えることですが、運用自体は簡単なものの、文字で伝えるには話がちょっとややこしかったです。
「AWS 初めてです」というスタッフもいるので、用語を定義したり画面キャプチャを貼ったりしたので、結構時間がかかりました。
おわりに
わかりやすくまとめられたか心許ありませんが、事実そのままが伝わらなくとも、感じだけでも掴んでいただいて、みなさんの組織で AWS SSO を導入する際の助けになれば幸いです。
AWS SSO の設定方法は下記記事にも書きましたので、よろしかったら参考にしてください（ほぼリンクですが）。
以上