【AWS SSO 東京リージョン対応記念！】AWS上にIAMユーザを作りたくない話
今回のお話
昨日、AWS SSOが東京リージョンに来ました！！
それを記念して、AWSの認証について、ひとネタ書きたいと思います。
前回、AWS Well-Architected Framework - Financial Services Industry Lens（FSI Lens ）を図解した中で、以下の質問を紹介しました。
FSISEC4: 全ての人的アクセスがフェデレーションを使用していることをどのように保証していますか？
まだ、後編を書いていないくせに、AWS SSOと絡めて、先にこの質問に対する実装例の一つとして、AzureADとの連携を考えてみたいと思います。
動機づけ
FSISEC4は「IAMユーザを作らないこと」として、以下のように図解しました。もう一段、なぜIAMユーザを作ってはいけないのか考えてみたいと思います。
IDの管理は管理者／利用者の双方にとって、"Undifferentiated Heavy Lifting"（差別化にならない重労働）と言えます。管理者はIDの棚卸し等が面倒ですし、利用者はパスワードを覚えたり、最近だとMFAを設定するのが一般的なので、MFAトークンの管理も面倒かと思います。一方で、この面倒を怠ってしまうと、統制・セキュリティリスクになってしまう点が、ID管理の "Heavy Lifting" なポイントだと思います。そして、この "Heavy Lifting" が認証機構の数だけ増えていき、多重苦に陥ってしまうので、各サービスで個別にユーザを作らない方が好ましいと言えます。
前回の図解では、オンプレミスのActive Directoryと連携する例で描きましたが、最近では、外部SaaSの利用も増え、IDaaSの検討を進めている企業も多いかと思います。中でもOffice 365の利用と合わせて、AzureADを利用しているケースを頻繁にうかがいます。今回は、AWSの認証をAzureADと統合することを考えていきたいと思います。
AWSにおけるユーザ管理
まずは、AWSにおけるユーザ管理についておさらいしていきます。
前回ご紹介したFSI Lensの6つ目の質問にある通り、権限・リソースの境界としてAWSアカウントを分離し、マルチアカウント戦略を持つことが、ベストプラクティスとされています。
FSISEC6: SDLC環境（dev、test、prod）間の分離をどのように確保していますか？
AWSアカウントは適切な粒度で分離すべきですが、通常、以下のように1人の利用者に対して、IAMユーザを各アカウントに個別に作成することはしません。複数のユーザを作成することの弊害は前述の通りです。
そこで、一般的には以下の通り、ユーザ管理用のAWSアカウントを作成し、そこからロールを切り替える形で、各AWSアカウントの操作権限を取得する方式を取ります。
今回、東京リージョンで提供開始されたAWS SSOを利用すると、同様の構成をマネージドに実現できます。「アクセス権限セット」というIAMロールに類似した形式でユーザに付与する権限を定義し、どのAWSアカウントにどの権限でアクセス可能とするかを設定します。ここで定義したアクセス権限セットとAWSアカウントの紐付け定義にしたがい、接続先のアカウントに切り替え用のIAMロールが自動作成されます。
利用者はAWS SSOのポータルサイトに一度ログインするだけで、ポータルサイトから、接続したいAWSアカウントと利用したいロールを選択し、マネジメントコンソールへのアクセスor CLI用の一時クレデンシャルを取得することができます。
ユーザ管理アカウントからスイッチロールする形式では、接続先のアカウントで付与される権限の管理は、各AWSアカウントのIAMで個別にロールを作成し、メンテナンスする必要がありますが、AWS SSOを利用すると、ユーザに付与される権限の管理を単一のアカウントに一元化でき、接続先のアカウントでの個別にロールを作成・管理することが不要になります。
今回はもう一段、AWS上にユーザを作らない方法を考えていきます。
AzureADに認証を統合する
Office 365等で既にAzureADを利用していることを想定し、既存のAzureADユーザでOffice 365のポータルサイトにアクセスすると、追加の認証は求められずにAWS環境にアクセスできることを目標にします。
AzureADにAWSの認証を統合するパターンはいくつか考えられます。今回は以下の3パターンを見ていきたいと思います。先ほどのユーザ管理の3つの構成例と同じ順番で対応しているかと思います。
まずは、①AWSアカウントごとにAWS IAMとAzureADを連携する構成です。
AzureAD上で各AWSアカウントをそれぞれ別のアプリケーションとして定義し、各アカウントに対するフェデレーションアクセスを提供します。AzureADが自動でAWS IAMからIAMロールの一覧を取得するように構成可能で、AzureAD上に完結する形で、AzureADユーザ／グループがどのAWSアカウントにどのロールでアクセスできるかを管理することが可能になります。
ただし、1つのAzureADユーザ／グループに対して、1 つの接続先AWSアカウントでは、1つのロールしか割当できません。この点は、設計上の考慮が必要かと思います（例えば、単一のユーザが、書き込み権限のあるロールとReadOnlyのロールをその時の業務に応じて使い分けるといったケース）。結局、接続先アカウントでスイッチロールの権限をつけるのであれば、どのロールを使えるかの定義がAzureAD上に完結するという部分が損なわれてしまいます。
次に、②ユーザ管理アカウントとAzureADを連携する方式です。
この構成では、どのAzureADユーザ／グループにどのスイッチロール権限を付与するかは、AzureAD上で定義します。そのスイッチロール権限を使うと、どのAWSアカウントにどのロールで接続できるようになるかはAWSのユーザ管理アカウント上で定義します。最終的な接続先AWSアカウントのロール管理は各アカウント上で個別に必要です。
最後に、③AzureADとAWS SSOを連携させる構成です。
この構成では、ユーザ／グループがどのAWSアカウントにどの権限でアクセスできるかは全てAWS SSO上で定義します。AzureADでは、AzureADユーザ／グループがAWS SSOのポータルサイトに接続できるか否か、および、ユーザとグループの紐付けだけを定義します。
このように各構成において、どこまでをAzureADで定義するか、どこまでをAWS上で定義するかが異なります。個人的には③の構成で、認証だけをAzureADに委任し、AWS上の権限管理はAWS SSOに集約する方が良いのではないかと感じました。ただし、1点改善要望としてあるのは、AWS SSOがCloudFormationやAPIに対応していないことです。アクセス管理はワークフローと統合し、自動化されることが統制・セキュリティ上も好ましいと考えられますので、この点が改善されると良いなぁと思います。
おわりに
祝！AWS SSO 東京リージョン対応！ということで、AWS SSOを混じえつつ、AWSにおける認証の統合について考えてみました。最終的に、もやっと終わりましたが、お気づきの点をコメントいただけますと幸いです。
図解FSI Lensの後編は近日中に書きます。。。
