APIゲートウェイでSaaSのIDを簡単に管理する①

こんにちは、富士榮です。

先日、CDATAさんのイベントで、CDATA API Serverを利用してローカルADのアカウントをSalesforceへプロビジョニングする、というデモをお見せしました。

当日は時間も限られていたのと、あくまでAPI Serverの活用事例の一つとして紹介したので、あまり細かい話はしなかったのですが、ID管理をやっている方々からは、このデモの仕組みをもう少し細かく知りたい、という声も頂いたので少し細かくご紹介していきたいと思います。

当日の資料はこちら。

アイデンティティ API とデータ統合プラットフォームの活用 from Naohiro Fujie

まずは、どのようなデモをお見せしたのか、動画を用意しているので最初にこちらをご覧ください。

使っている道具は、
・オンプレミスのActive Directory
・Azure AD Connect＋REST Management Agent（カスタム）
・Azure Active Directory
・CDATA API Server 2017J
・Salesforce.com
です。
*ちなみにAzure AD ConnectへカスタムManagement Agentを組み込む場合、所定の手続きを踏まないとサポート対象外となります。今回は手元にちょうどあった環境を使ったのでAzure AD Connectを使いましたが、本番環境ではMIM（Microsoft Identity Manager）やExgen LDAP Managerなど汎用的なID管理ツールを使ってください。

こんなことをしなくてもAzure ADから直接Salesforce.comへプロビジョニングすればいいじゃん、という話はありますが、手軽にテナントが用意できるSaaSなのであえてSalesforce.comを選択しています。もちろんCDATA API Serverが接続用のドライバを持っているサービスであれば何でも構いません。


では、早速環境の解説をしていきます。

１．オンプレミスのActive DirectoryからAzure ADへの同期環境を構成する

これは、特に特殊なことはしていません。Office365向けのID基盤を構築する時と同様にAzure AD Connectを構成します。

ものすごいシンプルな構成です。ローカルADもexample.localですし。。。

２．Salesforce.comのテナントを用意し、Azure ADとシングルサインオンを設定する

これも良くあるものなので、何も細かいことは気にしません。
以下の手順で設定をしていきます。

・Salesforce.comへのカスタムドメインの追加

・Azure ADにSalesforce.comアプリの追加とシングルサインオン設定
　サインオンURL、EntityIDにSalesforce.comに設定したカスタムドメインを指定し、証明書をダウンロードしておきます。

・Salesforce.comへAzure ADとのシングルサインオン設定
　Azure ADからダウンロードした証明書のアップロード、Issuerの設定、SSO URI、SLO URI、Salesforce側のEntityIDの設定を行います。設定すべきURI等の情報はAzure ADの設定ページに手順を含め記載されています。

ここまででシングルサインオンは出来るようになります。

３．API ServerとSalesforce.comを接続する

API Serverはここから評価版のダウンロードができます。
http://www.cdata.com/jp/apiserver/

ただ、この本体にはSalesforce.comとの接続に使うドライバが同梱されていないので、別途Salesforce.comドライバ（ADO.NET版）をダウンロードします。
こちらも評価版があります。
http://www.cdata.com/jp/download/?f=ado

インストール自体は次へ、次への世界なので何も気にすることは無く、インストールが終わるAPI Serverが起動してきます。
ちなみにデモでは手元のWindows 10の端末で動かしています。

設定メニューより接続タブを開き、新規に接続先を追加します。

接続先アプリケーションとしてSalesforceを選択します。

Salesforce.comへの接続に使うユーザIDとパスワードを入れ、保存します。

ちなみに、信頼されていないネットワークから接続している場合は、セキュリティ・トークンの設定が求められることがあります。

このエラーが出た場合は、Salesforce.comに管理者でログインし個人の設定からセキュリティ・トークンをリセットし、メールで送られてくるセキュリティ・トークンをAPI Serverに設定します。

次に、Salesforce.comのユーザを管理しているテーブルをAPI Serverのリソースとして定義し、REST APIとして公開します。
同じく、設定メニューの中のリソースタブを開き、リソースを追加します。

データソースに先ほど定義したSalesforce.comへの接続を選択します。

ユーザ情報が格納されているテーブルの名前はその名の通りUserなので、選択して保存します。

Userテーブルのカラム一覧が自動的に取得されるので、そのまま保存します。

ここまででSalesforce.comのUserテーブルをAPI ServerがREST APIとして公開できました。
最後にAPI接続を行うためのAPI Server上のユーザを定義します。
ユーザタブを開き、追加をします。

ユーザ名と実行できるメソッドを指定して保存します。

保存すると認証に使うAuthトークンが表示されるのでユーザ名と合わせてメモしておきます。

これで設定は完了です。

接続確認としてユーザ一覧を取得してみます。
APIメニューを開き、先ほど作成したリソースを開くとエンドポイントとメソッドが出てきます。

今回はテストなのでユーザ一覧を取得するので、単純にUserエンドポイントをGETします。
BASIC認証がかかり、ダイアログが出てくるので先ほど作成したユーザとAuthトークンをID、パスワードとして入力します。

上手くいくと、ユーザ一覧がODATA形式で取得出来ます。

これで、API Server経由でSalesforce.com上のユーザを操作するための準備はすべて整いました。

後は、Azure AD ConnectからAPI Serverで公開したAPIを叩くだけです。
この部分は若干コードを書くので、次回詳細は解説したいと思います。

ということで今回はここまでです。

[Azure AD/Office365]自社のテナント以外のOffice365やアプリケーションへのアクセスを制限する

こんにちは、富士榮です。

Office365など、Azure Active Directory（Azure AD）をID基盤として利用しているアプリケーションの良さはインターネット上に認証基盤があることにより、インターネット上のどこからでもセキュアかつ確実にアプリケーションを利用することが出来る、という点です。
（現実にAzure ADと同じレベルの可用性、堅牢性を持つ認証基盤を自前で構築しようとすると莫大な手間と費用が掛かります）


しかし、その反面で、例えば自前や他社のOffice365へのアクセスも出来てしまうことになるので、OneDriveやSharePoint、Exchangeへアクセスして自由に情報を書き込んだりメールを送信したりできてしまい、意図しない情報漏えいにつながってしまう可能性があります。

これまでIT管理者はURLフィルタ製品などを使って例えば、outook.comへの社内からのアクセスを遮断する、というような対策をしてきましたが、この対策だと自社もOffice365を使ってoutlook.comへアクセスをさせたい、という場合にURLフィルタによるドメイン名判別では対策出来ないため、結果として制限を緩めざるを得ない、という状況に陥ります。

そこでAzure ADで新たにリリースされたのが「テナントへのアクセス制限」機能です。

この機能を使うと特定のAzure ADテナントでしか認証が出来なくなるので、他社や自前のOffice365へのアクセスはNG、自社のOffice365へはアクセス可能、という状態を作り出すことが出来ます。

　公式Blogのアナウンス
　　New enhanced access controls in Azure AD: Tenant Restrictions is now Generally Available!
　　https://blogs.technet.microsoft.com/enterprisemobility/2017/01/31/new-enhanced-access-controls-in-azure-ad-tenant-restrictions-is-now-generally-available/

　関連ドキュメント
　　Use Tenant Restrictions to manage access to SaaS cloud applications
　　https://docs.microsoft.com/en-us/azure/active-directory/active-directory-tenant-restrictions


動作の仕組みは非常に単純です。

自社のProxyサーバ等でhttpヘッダに「Restrict-Access-To-Tenants」をセットし、テナント名を値として設定してあげるだけです。

動作概要図：公式Blogより

◆動作イメージ

早速試してみます。

手元にあったsquidを使って構成しようかと思いましたが、面倒なのでChromeのExtension「modHeader」を入れてみました。（fiddlerでもよかったんですが）

これを使うと自由にHTTPヘッダを追加することが出来るようになるので、先ほどの「Restrict-Access-To-Tenants」を追加してみます。

こんな感じで設定すると、pharaoh.onmicrosoft.comにしかアクセスできなくなります。（複数のディレクトリへのアクセスをさせたい場合はカンマ区切りでテナント名を複数記述可能です）


この状態でヘッダがどうなっているかサーバ側でリクエストを見てみます。単純なCGIを使いました。

ちゃんとヘッダが設定されていることがわかります。


この状態で別のテナントへアクセスしてみます。

まず、Access Panelへアクセスしてみます。

別のテナントのユーザでサインインした段階でエラーが表示され、アプリケーションへアクセスが出来ないことがわかります。

同じく、Office365ポータルです。

こちらも同じです。


情報漏えいを防ぎつつ、自社でもOffice365を使いたい企業・組織ではこの機能を上手く使って行けるといいですね。

Office365管理者は要対応。外部共有により不要なアクセス権が付与される

こんにちは、富士榮です。

OneDrive for Business上のコンテンツやSharePoint Onlineのチームサイトを他組織のユーザと共有をするB2Bシナリオで利用している企業・組織が増えている中、Office365（およびそのID基盤であるAzure AD）の構造上の問題により、意図しないアクセス権を外部ユーザへ付与してしまう場合があるので、注意喚起の意味で本エントリを書きます。

[3/7 Update]
一部修正が行われ、ポータルからのディレクトリ構成情報へのアクセスがデフォルトでブロックされるようになりました。
詳しくはこちらをご覧ください。
　http://idmlab.eidentity.jp/2017/03/office365.html

現在、この課題については米国マイクロソフトのAzure AD開発チームへエスカレーションしており早期の改善を求めていますが、場合によっては長期化する可能性もあるため、自組織でOffice365を管理しており、外部ユーザとのコンテンツ共有をエンドユーザへ開放している管理者は一読の上、対応を行うことをお勧めします。
（いわゆる製品やサービスの脆弱性の類ではないため）

◆課題の概要

OneDrive for Business上のコンテンツ共有やSharePoint Onlineのチームサイトへの招待を受けた外部ユーザは、共有されたコンテンツ以外にも、「Azure AD上ですべてのユーザに対して割り当てを行われたアプリケーションや、Azure Portalを経由したディレクトリ情報へのアクセスが許可されてしまいます。かつ、事前に共有した本人および管理者がこのことに気が付くことはほぼ不可能です（どこにもそのような記述はないため）」。

これは招待されたユーザが自組織でOffice365やAzure ADを使っておらず個人でマイクロソフトアカウントを使っている場合においても発生します。

◆実際の動き

実際にどのような動きになるのか、動画を撮っていますので、まずはこちらをご覧ください。
わかりにくいですが、以下が環境です。

＜組織「eIdentity」：招待する側＞
・Office365を運用しています
・一般ユーザ「test001@ems.adfs20.net」でOneDrive for Businessで外部ユーザ「test001@gapps21.adfs20.net」に対してコンテンツを共有します
・Azure AD上で「ts2016」というアプリケーションをAll Usersグループに対して公開しています

＜組織「InternetWeek」：招待される側＞
・Office365は使っていませんが、Azure ADを利用しています
　（マイクロソフトアカウントの場合も同じ動きになります）
・「test001@gapps21.adfs20.net」という一般ユーザが所属しています

単純にeIdentityテナントのユーザでOneDrive for Businessでフォルダを共有しただけなのに、共有前はInternetWeekテナントのユーザがアクセス出来なかったts2016アプリへアクセスが出来てしまい、かつAzure Portal経由でeIdentityディレクトリの構成情報（ドメイン一覧）が参照できてしまっています。
※アプリケーションのURLを知らなくてもアクセスパネル（https://myapps.microsoft.comへアクセスすると利用できるアプリケーション一覧が表示されてしまいます。
※SharePoint Onlineのチームサイトへの招待の場合は、アプリケーションアクセスは出来ませんが、Azure Portal経由でのディレクトリ情報の参照は可能な状態になります。
（「All Usersグループ」へ自動追加されないため）

ディレクトリ上（ドメイン一覧）の参照

アプリケーションへのアクセス

上記のスクリーンショットはいずれもゲストユーザによりアクセスした状態で撮っています。


管理者としては、特定のコンテンツのみの共有なら、、という気持ちで許可した外部共有がこのような形で他の情報へのアクセスへ影響を与えるということは意図していないことが多いと思われるため、非常に大きな問題となる可能性があります。

◆なぜ発生するのか

OneDrive for BusinessやSharePoint Onlineで外部ユーザを招待すると、招待されたユーザが招待したOffice365側のAzure AD上にゲストユーザとして登録されます。
これはAzure AD B2Bで外部ユーザを招待するのと同じ動作であり、Office365が内部的にAzure AD B2Bの機能を利用しているために発生しています。

そして現状では、ゲストとして登録されたユーザは、
１．ディレクトリへのサインイン（認証）
２．ディレクトリ上の自プロファイルへのアクセス
に加えて、
３．ディレクトリ構成情報へのアクセス（少なくともドメイン一覧の参照）
４．（場合により）All Usersグループへの自動登録
が行われてしまいます。

１、２については本来のゲストユーザとしてアクセスを行うために最低限必要な機能なので、仕方がありませんが、問題は３、４です。

◆Office365/Azure ADの内部構造の課題

ここまで見てきたとおり、Azure ADにゲストとして登録された外部ユーザが想定以上に権限を持ってしまっていることが根本的な課題です。
少なくとも、
・自プロファイル以外のディレクトリ情報へのアクセス
・ディレクトリに登録されたアプリケーションへのアクセス
はデフォルトでは禁止されるべきでしょう。

早々にマイクロソフトが対応してくれることを望みます。

◆推奨される対応

このような状況なので管理者が出来ることと出来ないことがあるのですが、少なくとも以下の対応をしておくべきでしょう。

１．ゲストユーザが自ディレクトリ上に存在するかどうかの確認

まず、自ディレクトリ上にゲストユーザが存在しているかどうかは定期的に確認をしておくべきでしょう。
以下のAzure Active DirectoryのPowerShellを使い、以下のコマンドレットを実行することでゲストの存在を確認できます。

Get-MsolUser | Where-Object { $_.userType -eq 'Guest' }

２．All Usersではなく、自ディレクトリ上の本来のメンバだけが含まれるグループの作成

動的メンバシップグループをカスタムで作成し、userType=Memberのユーザだけが所属する様に構成することで自ディレクトリ上で作成されたユーザのみが含まれるグループを作成することが可能です。

逆にuserType=Guestだけが含まれるグループを作成するとゲストだけが含まれるグループを作成することが出来ます。

３．All Usersグループへ割り当てられているアプリケーションの割り当て変更

All Usersグループへのアプリケーション割り当ては非常に便利なので使ってしまいがちなのですが、ここは先の２で作成したメンバだけが所属しているグループへの付け替えを検討しましょう。

こうしておけば、Azure ADからプロビジョニングを行っているアプリケーションであっても、ゲストユーザはプロビジョニングされませんし、アクセスパネル（https://myapps.microsoft.com）にもアプリケーションは出てきませんので安心です。

＜変更前＞

＜変更後＞

４．アプリケーション側でしっかり認可を行う

この問題は最終的にはアプリケーションの作りに依存するので、認証されただけでは利用できないようにアプリケーションを構成する（きちんと認可する）ことが最も大切です。

例えば、今回の動画の中でアクセスしている「ts2016」というアプリケーションはディレクトリ上にユーザが存在していれば使える、という簡易な実装にしてしまっているためゲストであっても使えてしまいます。

しかし、アプリケーション側の実装で、認証されてアクセスしてきたユーザへのアクセス制御を他の属性（所属など）を用いてしっかりと管理を行うことで、少なくとも重要なデータへのアクセスを防ぐことが出来ます。

５．ポータルへのアクセスを禁止する（要注意：影響度大）

設定を間違えると管理者でさえ管理ポータルへアクセスできなくなったり、他のAPIを使うアプリケーションへのアクセスが一切できなくなるので、この設定を行う場合は十分にテストを行った上で慎重に実施してください。著者は一切責任をとれません。

かなり強引なやり方ですが、条件付きアクセスを利用してゲストユーザからWindows Azure Service Management APIへのアクセスをブロックしてしまえば管理ポータルへのアクセスが出来なくなります。

以下の条件付きアクセスポリシーを作成します。
・Users and groups：All Guests（先ほど作成したゲストだけのグループ）
・Cloud apps：Windows Azure Service Management API
・Grant：Block access
・Enable policy：On

このポリシーを有効にすると、管理ポータルへアクセスしようとするとアクセスがブロックされます。

ディレクトリを切り替えようとすると、

アクセスがブロックされます。

◆今後の対応

現状、この動作はサービスの仕様の問題であり、いわゆるバグ等の不具合には該当しないためサービスのエンハンス要求を挙げている状態です。

この状態で出来ることは管理者の自衛が中心となりますので、動作および自テナントの状態をよく理解して運用をしていってください。

今後、動作に変更などあれば本ブログでも更新情報を発信していきたいと思います。

[Internet Weekフォローアップ]デモ環境の作り方⑥

こんにちは、富士榮です。

引き続きInternet Weekのフォローアップです。いよいよ最終回です。

利用部門で勝手に構築したOpenAMを完全に撤廃して、情シス管理のAzure Active Directory（Azure AD）にすべてをゆだねます。

• 第1回：環境の説明、OpenAMの認証を社内ADで行う
• 第2回：OpenAMのデータストアとして社内ADを利用する
• 第3回：OpenAMとG SuiteのID連携を行う
• 第4回：OpenAMでDesktop SSOを設定する
• 第5回：Azure ADとOpenAMと連携したままのG Suiteを連携する
• 第6回（今回）：G SuiteのID連携先をOpenAMからAzure ADへ切り替える

すでに前回、G SuiteへのID管理（プロビジョニング）はAzure ADで実施する様に構成し、シングルサインオンについても経過期間ということでOpenAMと連携する様に設定を行いました。

今回はG SuiteとOpenAMの連携を解除し、Azure ADと直接連携することでOpenAMを使わないようにします。

では、早速初めて行きます。

＜Step 3＞

◆G SuiteとAzure ADのシングルサインオン設定をSAMLベースへ変更する

前回は、既存のOpenAMを活用するためにAzure AD上に登録したG Suiteのシングルサインオン設定に「リンクされたサインオン」を選択しましたが、今回からはG SuiteとAzure ADを直接連携させるため、ここの設定を「SAMLベースのサインオン」へ変更します。

SAMLを使って連携する属性を編集します。
今回、メールアドレス属性にGoogleで使うログインIDが入っていますので、ユーザ識別子として「user.mail」を指定します。

また、デフォルトでgivenNameやsurNameなどがAttributeStatementに含まれるように構成されますが、日本語の値が入っているとGoogle側でエラーになるので、不要な属性は削除しておきます。

この辺りは以前紹介した注意事項を参照してください。

次にSAMLアサーションに署名するための証明書を作成します。

注意）ここで証明書をダウンロードしてG Suiteへアップロードするのですが、現在新ポータルでダウンロードした証明書をアップロードするとG Suiteがエラーを出しますので、ここだけクラシックポータルへアクセスして証明書をダウンロードしてください。

G Suiteの出すエラー

クラシックポータルでの証明書ダウンロード

後は、G Suiteへ設定するAzure AD側のエンドポイント情報を確認します。
Google Appsの構成メニューを選択すると右側に設定すべきエンドポイントの情報が出てきますので、これをコピーしておきます。

◆G Suite側の設定を更新する

ここまでくればあとは、G Suite側へ設定を入れるだけです。
先ほどメモしたログインページのURL、ログアウトページのURL、パスワード変更URLを入力し、証明書をアップロードします。

尚、この設定を行っている間（Azure ADで設定変更～保存、G Suite側の保存）はシングルサインオン設定がAzure ADとG Suite側でズレているので利用者へ影響が出ますので、事前にアナウンスをしてから実施する様にしましょう。

◆動作確認を行う

これで、設定は完了です。
後は動作確認をしてみます。

ドメイン参加したPCでアクセスパネル（https://myapps.microsoft.com）へアクセスします。
Azure ADと連携されたドメインに参加しているので、Desktop SSOが有効なのでAzure ADのログイン画面が表示されることなくパネルへアクセスできます。

ここでGoogle Appsをクリックし開くとシングルサインオンされます。この際、前回までの構成だと一旦OpenAMへアクセスしていましたが、今回からは直接Azure ADと連携しているのでOpenAMを経由することなくG Suiteへアクセスしていることがわかります。

※もちろん、アクセスパネルを経由せずに直接G SuiteへアクセスしてもDesktop SSOが実行されるので、ユーザは何も意識することはありません。



後は、OpenAMを停止するだけです。
ようやく利用部門が抱えていた認証基盤およびアプリケーションの管理がすべて情報システム部門へ移管されました。

めでたし、めでたし。

◆最後に

今回、Internet Week向けのデモということであまり情シス目線だけに閉じたものはやめておこうというコンセプトで今回のコンテンツを作成しました。
また、オーディエンスが技術者の方が中心ということもあり、家に帰ってすぐに試せるもの、というのも大きなテーマでしたので、あえてOpenAMを引っ張り出してきました。


なかなか実世界では考えにくいシナリオだったかもしれませんが、技術要素としてのSAMLやKerberosを使ったDesktop SSOなどは覚えておいても損はありませんので、少しでもエッセンスが伝われば幸いです。