自社テナント以外へのアクセス制御 - "テナントの制限" 機能 (Tenant Restrictions)
2017/03/13 :
プロキシ サーバーに追加する HTTP ヘッダーの情報を更新いたしました。
こんにちは、プロダクティビティ担当の和田です。
セキュリティ要件が厳しい組織や業界の場合、Office 365 の利用開始を検討する際、Firewall やプロキシ サーバーでアクセス リスト (ACL) の変更を行い、ホワイトリストに Office 365 で使用するドメイン名や URL を追加して、接続許可の対処をしなければならない場合があります。その際、Office 365 で使用される接続先 URL は全世界共通であるため、自社テナントへの接続を許可すると、他社のテナントや社員が個人契約したテナント、試用版で作成した評価テナントなど、すべての Office 365 テナントへ接続が行えるようになってしまうため、一部のお客様ではこれがセキュリティ リスクとして捉えられてしまうケースがありました。
これに対応するため、Azure Active Directory の機能拡張を行い、「テナントの制限」 (Tenant Restrictions) 機能が一般提供開始されました。(昨年の Tech Summit 2016 ではお伝えできませんでしたが、ようやくリリースされました!)
尚、本設定は Azure Active Directory を認証基盤として使用する全てのサービスに影響しますので、Office 365 以外にも、例えば以下のようなものも同時に制限対象となります。
- Azure 管理ポータル/Azure AD 管理センター
- Dynamics 365
- Windows Defender ATP 管理センター
- Azure ATP 管理センター
- 個人用 Azure RMS
- EA ポータル
- Azure AD からシングルサインオンしているその他のサードパーティーアプリ などなど
この機能を使用すると、組織内 LAN から接続を許可するテナントを制御することができます。テナント制限を実現するには、プロキシ サーバーで以下の 2 つの HTTP ヘッダーを挿入します。
- Restrict-Access-To-Tenants
- Restrict-Access-Context
ヘッダーを挿入する パケット・ URL は以下の 3 つのみで OK です。すべてのパケットを SSL インターセプトする必要はありませんので、プロキシ サーバー負荷を軽減できます。
- login.microsoftonline.com
- login.windows.net
- login.microsoft.com
"Restrict-Access-To-Tenants" ヘッダーには、複数のテナント名を指定することができます。複数のテナントを指定する場合はカンマで区切ります。
例) Contoso テナントと Fabrikam テナントのみアクセスを許可したい場合
Restrict-Access-To-Tenants: contoso.onmicrosoft.com,fabrikam.onmicrosoft.com
"Restrict-Access-Context" ヘッダーには、Azure AD のディレクトリ ID を 1 つ指定します。このヘッダーで宣言した Azure AD ディレクトリで、テナント制限のログを確認することができるようになります。本ヘッダーの値に設定したテナント ID (ディレクトリ ID) に、テナント制限を行った結果のログを出力します。テナント制限のログは、1 つの Azure AD に記録されるため、テナント ID は 1 つのみを設定します。複数指定は出来ません。
例)テナント制限ログの出力先に Contoso テナントを指定する場合
Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d
ディレクトリ ID は Azure Portal で確認できます。 管理者としてサインインし、[Azure Active Directory] を選択して、[プロパティ] を選択します。
Azure AD ではこのヘッダーの有無をチェックして、テナント制限を実現しています。本機能は、Office 365 のサブスクリプションをお持ちのお客様であれば、どなたでもご利用できます。
Office 365 以外の他の SaaS アプリへのアクセスを制御する場合は、Azure AD Premium P1 ライセンスが必要です。
※ 注意 ※
本機能は、組織内 LAN (管理されたプロキシ サーバー) からのテナント アクセス制限を行うための機能であり、社外からのアクセスを制限するための機能ではありません。社外からのアクセス制御を行いたい場合には、引き続き AD FS 等によるアクセス制御が必要です。
本機能を動作させるための諸条件は以下の通りです。
- SSL インターセプトが行え、指定した URL に対して HTTP ヘッダーを挿入できるプロキシ サーバーがあること (サーバー証明書の実装含む)
- Office 365 テナント及び クライアント ソフトウェアで、Modern Authentication (先進認証/ADAL) が有効になっていること
- すべてのクライアントが本プロキシ サーバー経由で Office 365 に接続されること
Azure AD 側の設定等は何も必要ありません。既に本機能は有効化されています。制限がかかっている状態で、クライアントが管理外のテナントにアクセスしようとすると、このように表示され、アクセスを禁止することが出来ます。
"詳細" をクリックするとアクセス元の情報や制限されている理由が表示されます。
テナント管理者は Azure ポータルで、
[Azure Active Directory] – [概要] – [その他の機能] – [テナントの制限]
から、ログ レポートにアクセスできます。
このレポートを使用して、ブロックされたサインイン ログを確認することが出来ますので、社内で許可されたテナント以外へアクセスが試行されているか否かをチェックできます。
※ 注意 ※
本ログ レポート機能をご利用になるためには、Azure AD Premium P1 のライセンスが必要となります。
テナントの制限機能の詳細情報はこちらを参照ください。
Title: テナント制限を使用して SaaS クラウド アプリケーションへのアクセスを管理する
URL: /ja-jp/azure/active-directory/active-directory-tenant-restrictions
Modern Authentication (先進認証/ADAL) の有効化はこちらを参照ください。
Exchange Online、Skype for Business Online、及び Office 2013 では、ADAL は既定で無効化されていますので、有効化設定をお願いします。2017年9月現在、新規に作成されるテナントについては、Exchange Online 及び Skype for Business Online も既定でテナント側の ADAL が有効になるように変更されています。
Title: Exchange Online の先進認証を有効にする
URL: https://support.office.com/ja-jp/article/58018196-f918-49cd-8238-56f57f38d662
Title: Skype for Business Online: Enable your tenant for modern authentication
URL: https://social.technet.microsoft.com/wiki/contents/articles/34339.skype-for-business-online-enable-your-tenant-for-modern-authentication.aspx
Title: Windows デバイスの Office 2013 の先進認証を有効にする
URL: https://support.office.com/ja-jp/article/7dc1c01a-090f-4971-9677-f1b192d6c910
なお、現時点では完全なテナントの制限を実現できない点にもご注意ください。テナントの制限を実現するためには、Modern Authentication (先進認証/ADAL) が使用されていることが前提となります。つまり、ブラウザー ベースのアプリケーションでは本機能は完全に機能しますが、レガシー認証を使用するクライアント (Outlook、Skype for Business など) ではこの認証・認可フェーズを迂回するため、テナントの制限を確実に強制することが出来ません。
レガシー認証を使用するクライアント / アプリケーションであっても、ユーザー認証処理の過程において login.microsoftonline.com, login.windows.net, login.microsoft.com にアクセスするような場合には、本テナント制限の効果が機能する場合がありますが、テナントの制限を確実に実現するためには Modern Authentication (先進認証/ADAL) が使用されていることが前提となります。
Office 2013 ・ Office 2016 については確実に ADAL が有効化されるようにグループ ポリシーを適用したり、インベントリで Office 2010 以前の旧バージョンが組織内に存在しないことを管理・徹底した上で、Outlook クライアントの場合は、グループ ポリシーで既定以外の Exchange アカウントの追加を禁止するなどの対処をご検討ください。また、Outlook 2016 の場合は、以下のサイトでご紹介しているレガシー認証のブロックを行うレジストリ設定も併用することで、必ず ADAL 認証を強制することができるようになります。
続編はこちら
Title: Outlook のレガシー認証ブロック (テナント制限に関連する ADAL 認証の強制)
URL: https://blogs.technet.microsoft.com/office365-tech-japan/2017/09/26/block_legacy_auth_with_tenant_restriction/