2020年3月以来の世界の出来事は、Office 365やクラウドベースのSaaSサービスの主要な利点の1つを浮き彫りにしました：それらはいつでも、どこでも、どのデバイスでも利用できます。世界が自宅からの作業を強いられたとき、Teams、Outlook、SharePoint、OneDriveなどのOffice 365アプリは、従来の企業ネットワーク外でも、さらには非企業デバイスでも簡単にアクセスできました。実際、ほとんどのOffice 365およびMicrosoft 365サブスクリプションでは、ユーザーがアプリを最大5台のデバイスにインストールして使用できるようライセンスが付与されています。

この結果、あなたの主な懸念の1つはデータ損失防止かもしれません。たとえば、デフォルトでは、ユーザーは個人デバイスで企業のOneDriveやメールボックスに認証でき、そのサービスにホストされているすべてのファイルとメールを同期する能力に制限がありません。そのユーザーが組織を離れたときに、データのローカルコピーはどうなるのでしょうか？

Azure Active Directory Conditional Accessを使用すると、管理者が再び制御できます。 Azure Active Directory Premium P1ライセンスの一部であるConditional Accessでは、ユーザーがAzure ADリソースにアクセスを許可またはブロックされる条件を制御します。アクセスを許可しても、追加の手段を強制することができます。たとえば、多要素認証（MFA）のプロンプトへの応答、または再度ログインするまでの時間などです。

条件付きアクセスが企業デバイスを識別する方法

このシナリオでは、Conditional Accessを使用して、ユーザーがOffice 365にサインインできるのは企業デバイスのみに制限します。これは、デバイスの状態に基づいて行います。

Conditional Access に「法人デバイス」というデバイス状態はありませんが、デバイスについて2つのことを特定し、それからデバイスが法人所有であることを推測することができます。

1. デバイスがハイブリッド Azure AD に参加していますか？
2. デバイスが準拠としてマークされていますか？

ハイブリッド Azure AD 参加とは、デバイスがオンプレミスのActive Directoryに参加しているが、クラウドベースのAzure ADにも同期して参加している状態を指します。この状態にデバイスを持っていく方法についてはこちらをご覧ください。これはWindowsデバイスにのみ適しています。

以下のスクリーンショットで、Azure ADがハイブリッド Azure AD 参加タイプを報告する様子を確認できます。

準拠としてマークされているとは、デバイスがIntuneなどのモバイルデバイス管理ソリューションに登録され、そしてそのMDMの準拠要件を満たしていることを意味します。これはデバイスのドメイン参加を確認するだけよりも優れた制御方法であり、セキュリティポストのレベルも確認しているため、ゼロトラスト戦略にとって有益です。ただし、デバイスがIntuneに登録されていることだけを確認したい場合は、特定のセキュリティ要件がない準拠ポリシーを設定することができます。この方法は、Windows 10、macOS、iOS、Androidといった「ビッグ4」のモダンプラットフォームに使用できます。

以下のスクリーンショットでは、Intuneがデバイスのコンプライアンスを報告する方法がわかります。

厳密に言えば、これらの状態のいずれかにあるデバイスの正確な用語は管理されたデバイスです。これは、IT管理者がそのデバイスに対して、Group PolicyやIntuneから設定を適用し制御する能力など、ある程度の制御を持っていることを意味します。どちらの状態にもないデバイスは、非管理と見なされます。Intuneへの登録を企業デバイスのみに制限していると仮定すれば、管理されたと企業の用語を同義に使用できます。

重要なポイントは、Azure ADがデバイス状態に基づいた条件付きアクセスポリシーを使用している場合、一部のプラットフォームやブラウザーから証明書情報を要求することがあることです。これは、通常、AppleやGoogleのプラットフォームなどのMicrosoft以外のプラットフォームです。これは、デバイスの状態情報がそのデバイス上の証明書に保持されているため、すべてのソフトウェアが自動的に認証中にこれをAzure ADに提供するわけではないためです。

条件付きアクセスポリシーの作成

条件付きアクセスポリシーは、Azure AD ＞ セキュリティ ＞ 条件付きアクセス内で作成されます。最良の手法は、ポリシーに、ポリシーが正確に達成しようとしている目標を簡単に識別できる名前を付けることです。正確に複数のポリシーが認証試行に一致した場合、それらすべてが適用され、良い命名規則はトラブルシューティングと管理を簡素化します。

ポリシーは、割り当てとアクセス制御に分かれています。 割り当ては、ポリシーがサインインに適用されるために真である必要があるすべてのチェックリストのようなものです。これらの設定のほとんどについて、条件を含めたり除外したりすることができます。 たとえば、すべてのユーザーを含めますがITスタッフを除外します。 ポリシーが適用される場合、アクセス制御は、アクセスが拒否されるか許可されるかを決定し、許可される場合は、どの他の手順や措置が適用されるかどうかを決定します。

条件付きアクセスに取り組む前に、その強力さを考慮することが重要です。これにより、すべてのアプリケーションへの認証を完全にブロックする能力が得られます。したがって、何かを誤って構成し、重要なユーザーを重要なアプリケーションからロックしたり、すべての管理者をロックしたりする可能性があります。 サインイン活動を監視する緊急アクセスアカウントの例外を作成することを検討すべきです。 個人的には、条件付きアクセスポリシーを作成する際に取る最初のステップです。

割り当て

ユーザーとグループは、ポリシーが適用される対象を制御します。 この割り当てに含まれていない場合、その規則の対象ではありません。 管理されていないデバイス上のOffice 365へのアクセスをブロックするポリシーの場合は、すべてのユーザーにスコープを設定したい場合もありますが、ゲスト/外部ユーザーや緊急アクセスアカウントを除外することも望ましい場合があります。 または、適切なAzure ADグループのみを含めることもできます。

クラウドアプリやアクションに対して、Office 365を選択します。複数のクラウドアプリを選択することができるため、ただしOffice 365だけでなくすべてのデータが機密と見なすアプリを制限する規則を作成することが望ましいかもしれません。 Conditional AccessにリストされているOffice 365アプリは実際には他のアプリのコレクションであり、個別に選択することができます。例えば、Exchange OnlineやSharePoint Onlineなどが含まれていますが、理論上コンポーネントアプリを選択できます。 Office 365を選択し、その部分ではなくOffice 365全体を選択する理由は、統合されたサービスであるためです。 統合されたプラットフォームを選択することで、お互いに依存する問題を減らすことができます。

条件は、信号や認証プロパティ（IPアドレス、オペレーティングシステム、アプリなど）を指定する場所です。 例では、Office 365へのすべてのアクセス方法をブロックするため、条件は指定しないでください。 この意味は、すべての条件が適用されるということです。 ただし、これらの条件の一般的な使用法は、Webアクセスとデスクトップアプリアクセスのために異なるルールを持っていることです。

また、ここにはデバイスの状態条件もありますが、このポリシーには選択しないでください。 その理由を確認するために読み続けてください。

アクセスコントロール

このポリシーの”もし〜なら”要素に対処したので、”それなら〜する”要素に移ります。アクセスコントロールは、グラントとセッションの設定に分かれています。

グラントペインで、アクセスの付与を選択し、適合としてマークされる必要なデバイスとハイブリッド Azure AD 参加デバイスが必要のチェックボックスをオンにします。 また、これらのいずれか、または両方でデバイスがあるかどうかを選択するオプションもあります。推奨されるのは選択したコントロールのいずれかを必要とするを選択することで、オンプレミス ドメイン参加および Azure AD のみ参加デバイスの両方がアクセスできるようにします。

ここで行ったことは「アクセス権を得ることはできますが、管理されたデバイスが必要です」というものです。別の方法で言うと、「管理されたデバイスでない限り、アクセス権を得ることはできません」とも言えます。オンプレミスのドメイン参加プロセスが安全であると仮定し、Intune の登録が法人デバイスに限定されている場合、すべての Office 365 へのアクセスを法人デバイスに制限できます。

セッションの設定は、ユーザーがアクセス権を得た後に許可される操作を制御します。たとえば、Web ブラウザー セッションでは、Exchange Online や SharePoint Online などのサービスからのダウンロードをブロックするためにアプリ制限の強制を使用できます。おそらく、これにより、ポリシーを形成するさまざまな方法について考えるよう促されるでしょう: 管理されていないデバイス上の完全なアプリに対するアクセスをブロックするポリシー、ただしダウンロードを禁止する Web アプリのみへのアクセスを許可する別のポリシーなど。

条件付きアクセス ポリシーの展開

設定がすべて適用されたら、条件付きアクセスポリシーは報告のみまたはオンの状態にすることができます。報告時の目的は、Azure ADサインインログを使用して、製品環境を中断せずに何が起こるかを監査することです。この情報を使用して、ポリシーの結果を理解し、たとえば、どの程度の混乱が予想されるか、その結果ユーザーにどのような教育を提供すべきかを把握できます。

ただし、報告のみモードでは、私たちの場合、重要な警告があります。前述のように、Azure ADがデバイスの状態を確認するためには、証明書をクエリする必要があり、一部のプラットフォームではこれを自動で許可していません。報告のみモードであっても、ポリシーが何を行うかを知るためにその証明書が必要です。デバイスの状態に基づく設定を含める場合は、常にこの警告が表示されます。

ポリシーが正しく構成され、ビジネスに悪影響を与えないことが確認されたら、状態をオンに変更するだけで、ポリシーは今後のAzure AD認証試行で即座に強制されます。

ユーザーエクスペリエンス

ユーザーが今後、Intuneに準拠したデバイスまたはハイブリッドAzure ADに参加していないデバイスでOffice 365リソースにアクセスしようとすると、Azure ADはアクセスがブロックされたことを通知します。これは、Webアプリまたはフルクライアントアプリを使用してアクセスしようとする場合にも当てはまります。再び、Webアプリとクライアントアプリのために異なるルールを定義するために条件を使用できます。

法人向けのデバイスで、認証プロセスはユーザーに関係なく変わらず、スムーズに進みます。ただし、そのアプリがデバイスの状態を確認できない場合には例外があります。これは、Office 365スイートのようなファーストパーティアプリには問題ありませんが、例えば、Windows上でもサードパーティのブラウザでは問題が発生する可能性があります。ユーザーは、上記のスクリーンショットのようなエラーが発生することがあります。Windows向けのChromeはWindows 10 Accounts extensionを使用する場合にはデバイスの状態をサポートしていますし、ChromiumベースのEdgeは標準でサポートしています。

関連記事:

• Microsoft条件付きアクセスポリシーを使用してOffice 365へのアクセス制限を行う理由