Azure AD と AWS SSOの連携
はじめに
AWSアカウントがたくさん増えて、アカウントごとにIAMユーザーがいて、それぞれにMFAを設定して、、もう大変！ となった経験はありますでしょうか。
私は今もそういった経験をしておりますが、そんなマルチアカウントのログインの助けになるのがAWS SSOです。 マイボス佐々木さんが構成の整理と説明を以下の記事でわかりやすくしてくれています。
↑の記事でもおススメの構成となっている、IdP + AWS SSOのパターンを今回は試してみたいと思います。
IdPはAzure上でマネージドで作成できる、Azure Active Directoryを使用します。 AWSと同じくクラウド環境のため、画面上からポチポチするだけでADおよびユーザーが作成できるので検証に便利です。
それではやっていきましょう。
AWS SSOの設定
SSOはOrganizationsの組織情報を使用した機能となるため、Organizationsの親アカウントで設定する必要があります。
AWS SSO画面に遷移し、有効にします。
Organizationsの組織が作成されていない場合は、以下のとおり表示されます。 AWS組織の作成を押すことで、組織が自動作成されます。
組織の作成時、メールの検証が必要となるため、アカウントのメールアドレスに届いたメールを確認して青いボタンを押しておきます。
外部のAzureADをIDソースとして利用します。 IDソースを選択を押下して設定画面へすすみます。
IDソースの変更を押します。
メタデータファイルをダウンロードしておきます。
Azure ADの設定
新規テナント、ユーザーの作成
Azureのテナントとは不動産のテナントと同様で、ユーザーやグループ、オブジェクトなどをひとまとまりで管理できる部屋のようなものです。Azureアカウント作成時にデフォルトで1つのテナントがあるのですが、今回は新規でSSO用の専用テナントを作成します。
Azure Active Directoryの画面へ遷移し、テナントを作成をおします。
デフォルトのAzure ADでOK。
任意の組織名、ドメイン名を入力します。
確認して作成します。
テナントの作成が完了したら、作成したテナント上で、ログイン確認用のユーザーを作成しておきます。
（もともとのテナントがダークモードONだったので色が変わりました）
testという名前で作成しておきます。名と姓を入力しておかないとAWS側でエラーになるため注意です。
アプリケーションの作成
AWSへ連携するために、エンタープライズアプリケーションを作成します。
新しいアプリケーションを作成を選ぶと、以下の通り各種サービスが選択できます。 AWSが一番最初に大きく出てくるので押したくなりますが、今回はAWS SSOなので独自のアプリケーションを作成をおします。
名前は任意でOKです。今回はAWS SSOとして作成します。
作成後以下のような画面になるので、シングルサインオンの設定をおします。
SAMLを選択
さきほどAWS SSOの画面からダウンロードしたメタデータを使うので、メタデータファイルのアップロードを選択します。
アップロードすると右側に以下の画面が表示されます。そのまま保存を押せばOKです。
Testするのか表示されますが、AWS側の設定がまだ完了していないため、ここはいいえにします。
このあとブラウザのリロードを行うと、以下のようにSAML署名証明書にメタデータのダウンロードリンクが表示されるので、そこからダウンロードします。
AWS SSOの設定（つづき）
AWS側に戻ります。
IDプロバイダーのメタデータのところから、Azure側でダウンロードしたメタデータファイルをアップロードします。
ACCEPTと入力し、IDソースを変更します。
完了！
今回はADのユーザーが自動的にAWS側にも連携されるよう、自動プロビジョニングを有効化しておきます。
SCIMエンドポイントとアクセストークンの情報はメモしておきます。
Azure 側プロビジョニング設定
またAzureに戻ります（行ったり来たり・・）
さきほど作成したアプリケーションからプロビジョニングの設定をしていきます。
プロビジョニングモードを自動に変更して、さきほどメモしたURLとトークン情報を入力し、テスト接続を行います。無事接続できると右上に成功の旨が表示されます。
その後、左上の保存を押します。
一度保存すると下部のプロビジョニング状態を変更できるので、オンにして保存します。
ユーザー属性のマッピング情報を変更します。
「mobile」と「facsimileTelephoneNumber」を削除します。
「mailNickname」を「objectId」に変更します。2つの削除と1つの変更が終わったら左上の保存を押します。
エンタープライズアプリケーションのページに戻り、ユーザーを追加します。
先ほどADで作成したtestユーザーを追加して割り当てます。
※本来の運用を考えると、グループ単位で割り当てたほうが良いでしょう。今回は検証用途のためユーザー単独で割り当てます。
プロビジョニングの実行間隔は40分になっているため、手動で再開して追加したユーザーを反映させます。
しばらくするとプロビジョニングが完了してユーザー1と表示されます。
AWSのSSO画面にもユーザーが追加されています。
アクセス権限セット、対象AWSアカウントの決定
ログインするAWSアカウントのユーザーに付与する権限（IAMポリシー）を決定します。
アクセス権限セット
まずはアクセス権限セットの作成からです。
今回は検証用途のためAWS側で職務単位で用意されている職務機能ポリシーを使用します。
※本番運用時は、必要な権限を決めて最低限の権限となるように付与しましょう。
閲覧権限のみ与えるViewOnlyAccessを使用します。
タグは特に設定せず、内容確認して作成します。
できました。
対象AWSアカウントの選択と割り当て
次はログインするAWSアカウントを選んでいきます。
Organizations配下に2アカウントあるため2つ共選んでユーザーを割り当てます。
プロビジョニングされたTestUserを選択します。
先ほど作成したアクセス権限セットを作成して完了します。
完了！
ログイン確認
設定がすべて終わったので、SSOのTOPに表示されているデフォルトのポータルURLへアクセスしてログインしてみます。
作成したAzure ADのユーザー名、パスワードを入力します。
AWS Account(2)と表示されています！クリックすると一覧でアカウントが一覧で出るのでログインしたい方を選択します。
今回はマネジメントコンソールで入ります。CLI用のキーも表示できますね。
ログインできました！まっさらな状態のアカウントなのでリソースは特にない状態ですが・・。
検証は以上です。
CLIやMFAなどまだまだ試したいことはありますが、今回の記事はAzure ADでユーザーを作成してSSOと連携するところを主目的として書いていますので、ここまでとしておきます。
まとめ
ただ試してみたかっただけですｗ SSOが便利で重要なことは知っていたのですが、やはり自分で試してみないとわからないという主義なので、実際に触ってみました。 触ってみて改めてですが、以下のポイントが良いですね。
- ID/パスワードの管理がAWS外で一元管理できる。元々業務で使用しているIDがあればそれも流用できる
- アクセス権限セットを使用して、アカウント単位の権限ではなく、必要な権限セットを複数のアカウントに適用できる
- CLIもイケる
AWS SSOの管理がOrganizationsの親アカウント限定なので、これがOU単位であったり、もう少し細かい単位で制御できると最高かと思います。今後に期待です。
これから作ろうと思っている方何かの参考になれば幸いです。
