はじめに
受託開発において、顧客システムを開発・運用する際にAWSアカウントの運用管理を実施する場合が多くあります。
その場合、AWSを利用するユーザ（開発者、運用者）をアカウント毎に管理する必要があり、顧客数（N）、ユーザ数（M）に対してO（N×M）のオーダーのユーザー数を管理する必要があります。AWSアカウントにユーザを追加する場合、通常は開発者、運用者毎にIAMユーザを作成することが多いですが、O（N×M）ですので、AWSアカウントが多くなるとすぐに管理工数が大きくなります。
また、ユーザ数が多くなることによる管理工数の増大以外にも、以下の問題が発生する可能性があります。
- プロジェクトに対するアサインが変更した場合のユーザ登録削除の手間がかかる
- ユーザが放置された場合にセキュリティリスクがある
- ユーザ毎に発行されたアクセスキーID／シークレットアクセスキーが実際のサービスに組み込んでしまうケースがある（ユーザを削除するとサービスへアクセスできなくなる）
ここでは、管理コストを削減しながら、開発会社としてできるセキュリティの向上策として、SAML2.0ベースのAWSマネージメントコンソールへのフェデレーションを実現する方法をご紹介します。
以下の記事も非常にわかりやすいので、併せて参照下さい。
- ADFS利用による複数AWSアカウントへのSSO
- ADFSでAWS Management ConsoleにSSO
- Active Directory資産を活用したAWS Management ConsoleへのSSO
- SAML 2.0 フェデレーティッドユーザーが AWS マネジメントコンソールにアクセス可能にする
実現できることとメリット
SAML2.0ベースのAWSマネージメントコンソールへのフェデレーションを行うことにより実現できることは以下のとおりです。
- 複数のAWSアカウントのマネジメントコンソールに、一つのアイデンティティ（メールアドレス等、パスワード）でログインできる
- どのユーザ毎にログインできるAWSアカウントを容易に制御できる
- ログインできる環境を制御できる（IPアドレスによる制御）
- IAMユーザを作成しないため、コードにアクセスキー等を埋め込まれるリスクを低減できる
株式会社鈴木商店におけるシステム構成
参考までに弊社（鈴木商店）でのシステム構成をご紹介します。
AWS上にADFS（Active Directory Federation Service）を使って、IdP（Identity Provider）を構築し、VPNで接続されたオフィスからALB（Application Load Balancer）経由でアクセスしています。
ALB経由でのアクセスとすることで、ACM（AWS Certificate Manager）によるSSL証明書を使用し、通信の暗号化をするとともに、セキュリティグループにて、接続できるIPアドレスを制限しています。
また、図には記載されていませんが、外部からもアクセスできるように別途VPNサーバを用意し、VPN接続すれば外部からもアクセス可能です。
従業員数が多くないため、ADFSとADDS（Active Directory Domain Services）を同じサーバで運用していますが、AWS Directory Serviceを使用することも可能です。
今回想定する環境
ここでは、「既にActive Directoryが存在する」ことを前提に、ADFSを用いてSSOが可能な環境を構築します。
想定するバージョンは以下のとおりです。
- Windows Server 2016
また、以下の想定で構築手順をご紹介しますので、環境に応じて適宜読み替えてください。
- IIS、ADFSがインストールされていること
- すべてのAD上のユーザーがSSO用画面にログイン可能であること
- ADFSとADDSは同じサーバにあること
- フェデレーションは内部の信頼できる環境からのみアクセスされること
- SSL証明書は自己証明書を使用すること（証明書は必須）
