はじめに

mediba advent calendar 2016 九日目担当の @mediba_t-sato です。
情報システム部に所属しており社内インフラを担当しています。

情報システム部の昨今の課題といえば、ログインが必要な社内/外のシステムの爆発的な増加です。

これらの管理の煩雑さや情報漏えいリスクを軽減するため mediba ではシングルサインオン(SSO) 基盤の検討をしています。今回は検証中ではありますが、一部運用を開始している Azure Active Directory の IDaaS (ここで上げている AzureAD 以外にも OneLogin、Okta、PingFederation など) による SSO の検証を公開してみたいと思います。

なぜ SSO が必要なのか？

各クラウドサービスはそれぞれユーザ名/パスワードがあります。 まぁ当たり前ですね。
しかし、これら各サービスのユーザ名/パスワードを適切に管理するのは非常に困難です。

定期的にパスワードを変更する
ユーザの死活を管理する
複数のサービスで同じパスワードを利用しない

上記 3 つは古くから言われている安全に運用するための必要な行為ですが、利用するサービスが増えていった場合、確実に実行することは困難になっていきます。

SSO による一本化

SSO は一つの ID（日常的に利用している PC のログインアカウントや、メールアドレス）を利用して、アカウント認証元にログインすることで、各サービスを利用することができる機能です。また、SSO や ID 連携に対応しているサービスであれば、一回の認証で全てのサービスへのログインが可能となります。
また、一つの ID の死活を管理者が管理することで芋づる式にサービスの利用可否を制御することができます。
このため SSO 化することはアカウント管理側にもサービスを利用するユーザ側にもメリットがあるといえます。

mediba の情報システム部では新クラウドサービスの全社導入時の検討材料に SSO の可否も盛り込んでいます。

AzureAD にした理由

IDaaS を幾つか検討をした結果 AzureAD Premium を選択しています。OneLogin なども検討したのですが、下記の理由により AzureAD を利用することにしました。
- ADFS がとてつもなくめんどくさい。
- Office 365 に付いてきた。
- 社内で Active Directory ドメインサービスを利用している。
特に ADFS を自前で構築した場合、冗長性、セキュリティ、証明書管理など構築から稼動までにかかるコストが必要となり、コストやリソースをカットし、実稼動までに一日もあれば実現できるという気軽さが最大のメリットでした。

それでは、早速構築してみましょう。

今回実現すること

AWS の IAM にユーザを作らずにロールのみで利用シチュエーションに応じたアクセス許可を実現してみたいと思います。

ユーザには AWS マネージメントコンソールにアクセスする際に、社内の Active Directory アカウントでのログインが求められ、アカウントの応じた適切なアクセス許可が割り当てられます。
当然、社内の Active Directory でユーザのアカウントの停止をすれば、ユーザは AWS へログインすることが出来なくなります。
また、AzureAD 側で AWS の接続権限を変更することで、一元的に各機能へのアクセス許可を変更することが可能になります。
AWS のマネージメントコンソールを数十人が利用する可能性がある場合、検討の余地があるかと思います。

また、AzureAD は MFA(多要素認証)にも対応しているため、重要な権限を持つロールについては多要素認証を追加することも可能ですが、今回は割愛します。

今回は S3 のみ触るので、S3FullAccess のみに限られた権限と、AdministratorAccess の権限を使い分けてみたいと思います。

環境

必要なもの

AzureAD Premium
- Office 365 についてくる Azure AD Free 版でも可。
- Office のエディションによっては Azure AD Premium が付いてきます。

以上。
Azure AD Premium を利用したほうが、SSO 連携のアプリを無制限に登録することができます。(Free 版は 10 個まで)もっと詳しく知りたい人は、こちらのリンクからご確認ください。
参考：Azure Active Directory のエディション

あったら便利なもの

Windows Server 2012 R2（オンプレ）
- Active Directory ドメインサービスを利用いる場合、社内のアカウント管理と同期させたほうが利便性はぐっとあがります。

今回は、社内の Active Directory ドメインサービスと AzureAD をシンクさせ、ドメインログインアカウントを利用して、SSO を実現を試します。

準備

AzureAD と社内の Active Directory ドメインサービスとのアカウント同期

AzureAD とオンプレのアカウントの同期は非常に簡単です。
ほとんどの場合、ドメインコントローラーに AzureAD Connect をセットアップするだけで完了します。
また、Office 365 をドメインログインアカウントを利用する場合、これらの作業で前準備は完結しています。
参考：Office 365 のディレクトリ同期をセットアップする
参考：簡単設定を使用した Azure AD Connect の開始

かんたんですね。
mediba の場合セカンダリーのドメインコントローラーに AzureAD Connect をセットアップすることと AzureAD 側からのパスワードライトバック（リセットや変更）はカスタマイズをしてさせないように設定しています。

AzureAD へのアプリの登録

ロール毎のアクセス権限は、AzureAD にてアプリケーションとして登録します。
今回は、AdministratorAccess を持つロールと、S3FullAccess を持つロール用の二つのアプリケーションを登録します。

ギャラリーからの Amazon Web Service (AWS) の追加

ギャラリーから Amazon Web Service (AWS) を追加するには、次の手順を実行します。

Azure クラシックポータルの左側のナビゲーションウィンドウで、[Active Directory] をクリックします。
[ディレクトリ] の一覧から、ディレクトリ統合を有効にするディレクトリを選択します。
アプリケーションビューを開くには、ディレクトリビューでトップメニューの [アプリケーション] をクリックします。
ページの下部にある [追加] をクリックします。
[実行する内容] ダイアログで、[ギャラリーからアプリケーションを追加します] をクリックします。
検索ボックスに、「Amazon Web Service (AWS)」と入力します。
結果ウィンドウで [Amazon Web Service (AWS)] を選択し、[完了] をクリックしてアプリケーションを追加します。
上記手順を S3FullAccess と AdministratorAccess 用に二つ作ります。

Amazon Web Service (AWS) との Azure AD シングルサインオンを構成

先ほど追加したアプリにシングルサインオンの設定を行います。
ちなみにこちらの手順について Microsoft の公式な資料があるのですが、残念ながら手順どおりになりません。画面イメージが豊富ですので下記の手順の参考にしてみてください。
参考：チュートリアル: Azure Active Directory と Amazon Web Service (AWS) の統合

Azure クラシックポータルの左側のナビゲーションウィンドウで、[Active Directory] の追加した Amazon Web Service (AWS) アプリケーション統合ページで [シングルサインオンの構成] をクリックして、[シングルサインオンの構成] ダイアログを開きます。
[ユーザーの Amazon Web Service (AWS) へのアクセスを設定してください] ページで、[Azure AD のシングルサインオン] を選択し、[次へ] をクリックします。
[アプリケーション設定の構成] ページで、[識別子] に以下のURIを入力します。

ポイント：AWS エンドポイント（ https://signin.aws.amazon.com/saml ）に付随した URI を指定する必要があります。
たとえば、以下のような URI をユニークで生成します。
(エンドポイントの後ろにパラメーターで識別子を挿入）
https://signin.aws.amazon.com/saml?S3Full

[Amazon Web Service (AWS) でのシングルサインオンの構成] ページで、[メタデータのダウンロード] をクリックし、コンピューターにローカルでメタデータファイルを保存します。
後で使います

AWS 側の設定

IAM を編集できる権限で AWS マネージメントコンソールにサインオンします。
[IAM] のコンソールを開き、左側のナビゲーションから [ID プロバイダー] をクリックします。
[プロバイダの作成]をクリックし、[プロバイダーのタイプ]から SAML を選択します。
[プロバイダ名] に任意の識別子を入れ、先ほどダウンロードした XML ファイルをメタデータドキュメントとしてアップロードし、[次のステップ] をクリックし作成します。
つづいて利用するロールを作成するため、左側のナビゲーションから[ロール]を選択し［新しいロールの作成］をクリックします。
［ロール名］を指定し［次のステップ］をクリックします。 2.［ロールタイプの選択］にて［IDプロバイダアクセス用のロール］を展開し［SAML プロバイダへのウェブシングルサインオン（WebSSO）アクセスを付与］を選択し［次のステップ］をクリックします。
［ロールの信頼の確認］にて 12 行目のエンドポイントを目的の値に修正し［次のステップ］をクリックします。
［ポリシーのアタッチ］で設定したいポリシー名を選択し［次のステップ］をクリックします。
［確認］の画面で［ロール ARN］と［信頼されたエンティティ］の値をメモし［作成］します。
Azure クラシックポータルに戻り、対応するアプリケーションを開きます。
上部のメニューで [属性] をクリックしダイアログを開きます。
[ユーザー属性の追加] をクリックし、追加のダイアログで以下の値を入力して完了します。
1. [属性名] ボックスに、「https://aws.amazon.com/SAML/Attributes/Role」と入力します。
2. [属性値] ボックスに、[Role の ARN 値] , [Trusted Entity の ARN 値] を入力します。
再び[ユーザー属性の追加] をクリックし、追加のダイアログで以下の値を入力して完了します。
1. [属性名] ボックスに、「 https://aws.amazon.com/SAML/Attributes/RoleSessionName 」と入力します。
2. [属性値] ボックスに「user.userprincipalname」と入力するか、ドロップダウンリストから選択します。
[変更の適用] をクリックし、保存をします。

ユーザーへの割り当て

ドメインと同期している場合は、ユーザーへのアクセス管理もかなりシンプルです。

Azure クラシックポータルからユーザーにアクセスを許可させたいアプリケーションを選択します。
上部のメニューで [ユーザーとグループ] をクリックします。
利用させたいユーザーを検索し［割り当て］をクリックします。

使ってみよう

AWS マネージメントコンソールには個人用のアプリポータルからアクセスできます。
https://portal.office.com/myapps

先ほど割り当てたアプリケーションが Office の製品と一緒に並んでいるのは不思議な感じではありますが、クリックすると指定したロールで AWS マネージメントコンソールアクセスすることができます。

まとめ

いかがでしたでしょうか？
クラウドサービスも SAML や OAuth など IDaaS を活用できるサービスが増えてきています。社内のアカウント管理の混乱の収拾にお役立ちできれば幸いです。

AWS マネージメントコンソール を AzureAD で SSO してみる