NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

AWS SSOの利用と権限セットの設計の考え方

 こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木です。
 今日は、みんな気になるけど、なかなか手が出しにくいAWS SSOについて解説します。一口にSSOと言っても多岐に渡るので、SSOの中の権限セットを中心に説明します。

AWS SSOとは?

 AWS Single Sign-On(SSO)は、その名のとおりシングルサインオンのためのサービスです。そもそもシングルサインオン(SSO)とは何かという話は割愛して、まずAWSにおけるSSOの必要性について説明します。AWSにおいて何故SSOが必要になるのか?それは、今やAWSではマルチアカウントで運用するのが定石だからです。そして、マルチアカウント運用時に、SSOの仕組みを導入していないと、すぐにIAMユーザーのアカウントがいっぱいになるという問題に直面します。

f:id:takurosasaki:20210326011815p:plain

 それを回避するのがSSOです。SSOを実現するソリューションとして、AzureADやOkta、OneLoginなどいろいろあります。AWSにもAWS SSOという名前そのままなサービスがあり、なんと無料で使えます。AWS SSOを導入すると、次のようなイメージで先程のアカウントいっぱい問題は解決できます。

f:id:takurosasaki:20210326012024p:plain

権限セットとは?

 しかし、AWS SSOを導入すれば万事解決という訳ではありません。AWS SSOでログイン後に、予め利用できるように設定したAWSアカウントにスイッチするのですが、この際に内部的には各AWSアカウントのIAM RoleへSwitch Roleすることで実現しています。AWS SSOあるいはそこから委任されたIdP(Identify Provide)で認証を行い、認可はどのIAMロールと結びつけるかで実現しているということです。
 それでは、各アカウントに配置されたIAMロールは、どうやって管理されているのでしょうか?スイッチ先のアカウントで、個々に作る必要があるのでしょうか?答えは、否です。
 AWS SSOには、権限セットという概念があります。これは、個々のアカウントにIAMロールを作るためのテンプレートのようなものです。AWS SSOでは、ユーザーごとにどのアカウントのどの権限セットに紐付けるかを設定します。アカウントに紐付けられた権限セットは、その内容をIAMロールとして対象のアカウントに作成します。

f:id:takurosasaki:20210326101337p:plain

権限セットの設計の考え方

 権限セットの概要を理解した上で、実際に作成しようとした時に困ったことに気が付きます。AWS SSOのデフォルトでは、権限セットは50個(※)までしか作れません。つまり50種類のIAMロールしか作れないということです。1アカウントに50個のIAMロールであれば、充分すぎるほどありますが、Organization全体で50個です。例えばアカウントが10個あるOrganizationだと1アカウントごとに別々のIAMロールを作るとしたら5個づつしかつくれません。100アカウントだと、そもそも足りません。

f:id:takurosasaki:20210326102240p:plain

 この50個という制限がポイントになります。つまり、AWSは個々のアカウントに対して個別のIAMロールの設計をするのではないと伝えているのだと私は考えています。(そのうち、シレッと1,000個まで権限セット作れるようになりましたとアナウンスあるかもしれないけど) つまりIAMロールは個々のアカウントごとに設計するのではなく、アカウント間で共通化して使いなさいということです。

※読者からご指摘を受けて英語版のドキュメントを確認すると、権限セットは500まで設定可能なようです。(アカウントごとのMaxは50)
 話の本質的な部分は変わらないので、本文表記はそのままにしています。

S3へのアクセス制限の例

 権限セットは標準テンプレートとしてと使えということは理解できたと思いますが、それだと困ったケースがあります。IAMで個別リソースのアクセス制御をしている場合です。例えばS3の機密情報が入っているバケットにAさんはアクセス可能だけど、Bさんはアクセス不可にしたい場合があります。これをIAMの権限設定で実現していた場合、AWS SSOの権限セットだと破綻してしまいます。そういう時はどうすればよいのでしょうか?IAMのアクセス権ベースのコントロールではなく、S3側のリソース側の制限を利用するのが正解となります。

f:id:takurosasaki:20210326103519p:plain

とは言ったものの

 原理原則としては、上記の通りとなります。一方で、数百のアカウントが既にある場合に、その原理原則に従って設計しなおすというのも現実的ではありません。この部分はAWS SSOで解決するように動くのか、現状を維持し既存のIAMロールを活用するのか。これは悩みどころになります。

まとめ

 最後に悩みを吐き出しつつも、基本的にはAWS SSOは素晴らしいサービスだと思います。これからAWSを活用しだす場合は、ぜひ最初から導入を検討しましょう。既存のAWSアカウントが大量にあってIAMロールの変更が難しい場合、いろいろ考える必要があるので次の機会に考察してみます。楽しみにしてください

f:id:takurosasaki:20210326005216p:plain

執筆者佐々木拓郎

Japan APN Ambassador 2019
ワイン飲みながら技術書を書くのが趣味なおじさんです

Twitter:https://twitter.com/dkfj

Facebook:https://www.facebook.com/takuro.sasaki

個人ブログ:https://blog.takuros.net/

Amazon著者ページ:Amazon.co.jp: 佐々木 拓郎:作品一覧、著者略歴