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」をセットし、テナント名を値として設定してあげるだけです。
◆動作イメージ
早速試してみます。手元にあったsquidを使って構成しようかと思いましたが、面倒なのでChromeのExtension「modHeader」を入れてみました。（fiddlerでもよかったんですが）
これを使うと自由にHTTPヘッダを追加することが出来るようになるので、先ほどの「Restrict-Access-To-Tenants」を追加してみます。
この状態でヘッダがどうなっているかサーバ側でリクエストを見てみます。単純なCGIを使いました。
ちゃんとヘッダが設定されていることがわかります。
この状態で別のテナントへアクセスしてみます。
まず、Access Panelへアクセスしてみます。
別のテナントのユーザでサインインした段階でエラーが表示され、アプリケーションへアクセスが出来ないことがわかります。
同じく、Office365ポータルです。
こちらも同じです。
情報漏えいを防ぎつつ、自社でもOffice365を使いたい企業・組織ではこの機能を上手く使って行けるといいですね。
投稿
0 件のコメント:
コメントを投稿