条件付きアクセスを使用して認証セッション管理を構成するConfigure authentication session management with Conditional Access

複雑なデプロイでは、認証セッションの制限が必要になる場合があります。In complex deployments, organizations might have a need to restrict authentication sessions. 次のようなシナリオがあります。Some scenarios might include:

  • 管理対象外のデバイスまたは共有デバイスからのリソース アクセスResource access from an unmanaged or shared device
  • 外部ネットワークから機密情報へのアクセスAccess to sensitive information from an external network
  • 影響の大きなユーザーHigh impact users
  • 重大なビジネス アプリケーションCritical business applications

条件付きアクセス制御を使用すると、すべてのユーザーに影響を与えることなく、組織内の特定のユース ケースを対象とするポリシーを作成できます。Conditional Access controls allow you to create policies that target specific use cases within your organization without affecting all users.

ポリシーを構成する方法を詳しく説明する前に、既定の構成を調べてみましょう。Before diving into details on how to configure the policy, let’s examine the default configuration.

ユーザー サインインの頻度User sign-in frequency

サインインの頻度は、ユーザーがリソースにアクセスしようとしたときにサインインし直すように求められるまでの期間を定義します。Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource.

ユーザー サインインの頻度に関する Azure Active Directory (Azure AD) の既定の構成は、90 日間のローリング ウィンドウです。The Azure Active Directory (Azure AD) default configuration for user sign-in frequency is a rolling window of 90 days. 多くの場合、ユーザーに資格情報を要求することは賢明であるように思われますが、逆効果になることがあります。何も考えずに資格情報を入力するように教えられたユーザーは、意図せずに、資格情報を求める悪意のあるプロンプトに入力してしまう可能性があります。Asking users for credentials often seems like a sensible thing to do, but it can backfire: users that are trained to enter their credentials without thinking can unintentionally supply them to a malicious credential prompt.

ユーザーにサインインし直すように求めないことは不安に感じられるかもしれませんが、実際は IT ポリシーのどのような違反によってもセッションは取り消されます。It might sound alarming to not ask for a user to sign back in, in reality any violation of IT policies will revoke the session. たとえば、パスワードの変更、非準拠のデバイス、アカウントの無効化などがあります (ただしこれらに限定されません)。Some examples include (but are not limited to) a password change, an incompliant device, or account disable. また、明示的に PowerShell を使用してユーザーのセッションを取り消すことができます。You can also explicitly revoke users’ sessions using PowerShell. Azure AD の既定の構成は、結局、「セッションのセキュリティ体制が変更していなければ、資格情報の提供をユーザーに求めない」というものになります。The Azure AD default configuration comes down to “don’t ask users to provide their credentials if security posture of their sessions has not changed”.

サインイン頻度設定は、標準に従って OAUTH2 または OIDC プロトコルを実装したアプリで動作します。The sign-in frequency setting works with apps that have implemented OAUTH2 or OIDC protocols according to the standards. Windows、Mac、次の Web アプリケーションを含むモバイル用のほとんどの Microsoft ネイティブ アプリは、この設定に準拠します。Most Microsoft native apps for Windows, Mac, and Mobile including the following web applications comply with the setting.

  • Word、Excel、PowerPoint OnlineWord, Excel, PowerPoint Online
  • OneNote OnlineOneNote Online
  • Office.comOffice.com
  • Microsoft 365 管理者ポータルMicrosoft 365 Admin portal
  • Exchange OnlineExchange Online
  • SharePoint と OneDriveSharePoint and OneDrive
  • Teams Web クライアントTeams web client
  • Dynamics CRM OnlineDynamics CRM Online
  • Azure portalAzure portal

サインイン頻度設定は、独自の Cookie が削除されず、定期的に認証のために Azure AD にリダイレクトされる限り、SAML アプリケーションでも機能します。The sign-in frequency setting works with SAML applications as well, as long as they do not drop their own cookies and are redirected back to Azure AD for authentication on regular basis.

ユーザーのサインイン頻度と多要素認証User sign-in frequency and multi-factor authentication

以前は、サインイン頻度は、Azure AD 参加済み、Hybrid Azure AD 参加済み、Azure AD 登録済みのデバイス上での第一要素認証のみに適用されていました。Sign-in frequency previously applied to only to the first factor authentication on devices that were Azure AD joined, Hybrid Azure AD joined, and Azure AD registered. お客様がこれらのデバイスに対して多要素認証 (MFA) を再適用する簡単な方法はありませんでした。There was no easy way for our customers to re-enforce multi factor authentication (MFA) on those devices. お客様からのフィードバックに基づいて、サインイン頻度が MFA にも適用されるようになります。Based on customer feedback, sign-in frequency will apply for MFA as well.

サインインの頻度と MFASign in frequency and MFA

ユーザーサインインの頻度とデバイス IDUser sign-in frequency and device identities

Azure AD 参加済み、ハイブリッド Azure AD 参加済み、または Azure AD 登録済みデバイスがある場合、ユーザーがデバイスのロックを解除するか、対話形式でサインインすると、このイベントはサインイン頻度ポリシーも満たします。If you have Azure AD joined, hybrid Azure AD joined, or Azure AD registered devices, when a user unlocks their device or signs in interactively, this event will satisfy the sign-in frequency policy as well. 次の 2 つの例では、ユーザーのサインイン頻度が 1 時間に設定されています。In the following two examples user sign-in frequency is set to 1 hour:

例 1:Example 1:

  • 00:00 では、ユーザーは Windows 10 Azure AD に参加しているデバイスにサインインし、SharePoint Online に格納されているドキュメントで作業を開始します。At 00:00, a user signs in to their Windows 10 Azure AD joined device and starts work on a document stored on SharePoint Online.
  • ユーザーは、デバイス上の同じドキュメントで1時間、作業を継続します。The user continues working on the same document on their device for an hour.
  • 01:00 では、ユーザーは、管理者によって構成された条件付きアクセス ポリシーのサインイン頻度の要件に基づいて、もう一度サインインするように求められます。At 01:00, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator.

例 2:Example 2:

  • 00:00 では、ユーザーは Windows 10 Azure AD に参加しているデバイスにサインインし、SharePoint Online に格納されているドキュメントで作業を開始します。At 00:00, a user signs in to their Windows 10 Azure AD joined device and starts work on a document stored on SharePoint Online.
  • 00:30 では、ユーザーは立ち上がり、デバイスをロックして休憩します。At 00:30, the user gets up and takes a break locking their device.
  • 00:45 では、ユーザーは休憩から戻り、デバイスのロックを解除します。At 00:45, the user returns from their break and unlocks the device.
  • 01:45 では、前回のサインインが 00:45 で発生したため、管理者によって構成された条件付きアクセスポリシーのサインイン頻度の要件に基づいて、ユーザーはもう一度サインインするように求められます。At 01:45, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator since the last sign-in happened at 00:45.

ブラウズ セッションの永続化Persistence of browsing sessions

永続的なブラウザー セッションでは、ユーザーはブラウザー ウィンドウを閉じてから再度開いた後でもサインインした状態を維持できます。A persistent browser session allows users to remain signed in after closing and reopening their browser window.

ブラウザー セッション永続化に対し、Azure AD では既定で、認証が成功した後に「サインインの状態を維持しますか?」というプロンプトを表示して、個人用デバイスのユーザーがセッションを持続するかどうかをThe Azure AD default for browser session persistence allows users on personal devices to choose whether to persist the session by showing a “Stay signed in?” 選択できるようにしています。prompt after successful authentication. AD FS シングル サイン オンの設定」の記事のガイダンスを使用して AD FS でブラウザー永続化が構成されている場合、そのポリシーに従って、Azure AD セッションも永続化します。If browser persistence is configured in AD FS using the guidance in the article AD FS Single Sign-On Settings, we will comply with that policy and persist the Azure AD session as well. また、テナント内のユーザーに「サインインの状態を維持しますか?」というプロンプトを表示するかどうかを構成することもできます。You can also configure whether users in your tenant see the “Stay signed in?” それには、Azure AD サインイン ページのカスタマイズに関する記事にあるガイダンスを使用して、Azure portal の企業ブランド ウィンドウで適切な設定を変更します。prompt by changing the appropriate setting in the company branding pane in Azure portal using the guidance in the article Customize your Azure AD sign-in page.

認証セッション コントロールの構成Configuring authentication session controls

条件付きアクセスは Azure AD Premium の機能であり、Premium ライセンスが必要です。Conditional Access is an Azure AD Premium capability and requires a premium license. 条件付きアクセスの詳細については、Azure Active Directory の条件付きアクセスの概要に関するページを参照してください。If you would like to learn more about Conditional Access, see What is Conditional Access in Azure Active Directory?

警告

現在、パブリック プレビューで構成可能なトークン有効期間機能を使用している場合、同一のユーザーまたはアプリの組み合わせに対し、異なる 2 つのポリシー (1 つはこの機能で、もう 1 つは構成可能なトークン有効期間機能で使用) を作成することはサポートしていないことに注意してください。If you are using the configurable token lifetime feature currently in public preview, please note that we don’t support creating two different policies for the same user or app combination: one with this feature and another one with configurable token lifetime feature. Microsoft は、2020 年 5 月 1 日に構成可能なトークン有効期間機能を廃止し、条件付きアクセス認証セッション管理機能に置き換える予定です。Microsoft plans to retire the configurable token lifetime feature on May 1, 2020 and replace it with the Conditional Access authentication session management feature.

[サインインの頻度] を有効にする前に、テナントで他の再認証設定が無効になっていることを確認してください。Before enabling Sign-in Frequency, make sure other reauthentication settings are disabled in your tenant. [信頼されたデバイスで MFA を記憶する] が有効になっている場合は、[サインインの頻度] を使用する前に必ず無効にしてください。この 2 つの設定を一緒に使用すると、ユーザーに予期せずにメッセージが表示される可能性があります。If "Remember MFA on trusted devices" is enabled, be sure to disable it before using Sign-in frequency, as using these two settings together may lead to prompting users unexpectedly. 再認証のプロンプトとセッションの有効期間の詳細については、「再認証プロンプトを最適化し、Azure Multi-Factor Authentication のセッションの有効期間を理解する」の記事を参照してください。To learn more about reauthentication prompts and session lifetime, see the article, Optimize reauthentication prompts and understand session lifetime for Azure Multi-Factor Authentication.

ポリシー 1:サインイン頻度コントロールPolicy 1: Sign-in frequency control

  1. 新しいポリシーを作成しますCreate new policy

  2. ターゲット クラウド アプリなど、顧客の環境に必要なすべての条件を選択します。Choose all required conditions for customer’s environment, including the target cloud apps.

    注意

    最高のユーザー エクスペリエンスが得られるように、Exchange Online や SharePoint Online などの主要な Microsoft Office アプリに、同じ認証プロンプト頻度を設定することをお勧めします。It is recommended to set equal authentication prompt frequency for key Microsoft Office apps such as Exchange Online and SharePoint Online for best user experience.

  3. [アクセス制御] > [セッション] に移動して、 [サインインの頻度] をクリックしますGo to Access Controls > Session and click Sign-in frequency

  4. 最初のテキスト ボックスに必要な日数および時間数の値を入力しますEnter the required value of days and hours in the first text box

  5. ドロップダウンから [時間] または [日] の値を選択しますSelect a value of Hours or Days from dropdown

  6. ポリシーを保存しますSave your policy

サインイン頻度が構成された条件付きアクセス ポリシー

Azure AD 登録済み Windows デバイスでは、デバイスへのサインインはプロンプトと見なされます。On Azure AD registered Windows devices sign in to the device is considered a prompt. たとえば、Office アプリのサインイン頻度を 24 時間に構成している場合、Azure AD 登録済み Windows デバイスのユーザーは、デバイスにサインインすることによって、サインイン頻度ポリシーを満たし、Office アプリを開いたときに再度プロンプトされることはありません。For example, if you have configured the sign-in frequency to 24 hours for Office apps, users on Azure AD registered Windows devices will satisfy the sign-in frequency policy by signing in to the device and will be not prompted again when opening Office apps.

ポリシー 2:永続的ブラウザー セッションPolicy 2: Persistent browser session

  1. 新しいポリシーを作成しますCreate new policy

  2. すべての必要な条件を選択します。Choose all required conditions.

    注意

    このコントロールは条件として [すべてのクラウド アプリ] を選択する必要があることに注意してください。Please note that this control requires to choose “All Cloud Apps” as a condition. ブラウザー セッション永続化は認証セッション トークンによって制御されます。Browser session persistence is controlled by authentication session token. ブラウザー セッションのすべてのタブは 1 つのセッション トークンを共有するため、それらすべては永続性の状態を共有する必要があります。All tabs in a browser session share a single session token and therefore they all must share persistence state.

  3. [アクセス制御] > [セッション] に移動し、 [永続的ブラウザー セッション] をクリックしますGo to Access Controls > Session and click Persistent browser session

  4. ドロップダウンから値を選択しますSelect a value from dropdown

  5. ポリシーを保存しますSave you policy

永続的ブラウザーが構成された条件付きアクセス ポリシー

注意

Azure AD 条件付きアクセスの永続的ブラウザー セッション構成は、Persistent Browser Session configuration in Azure AD Conditional Access will overwrite the “Stay signed in?” 両方のポリシーが構成されている場合、同じユーザーの Azure portal の企業ブランド ウィンドウにある「サインインの状態を維持しますか?」の設定を上書きします。setting in the company branding pane in the Azure portal for the same user if you have configured both policies.

検証Validation

What-If ツールを使用して、ポリシーをどのように構成するかに基づき、ユーザーからターゲット アプリケーションへのログインおよび他の条件をシミュレートします。Use the What-If tool to simulate a login from the user to the target application and other conditions based on how you configured your policy. 認証セッションの管理コントロールが、ツールの結果に表示されます。The authentication session management controls show up in the result of the tool.

条件付きアクセスの What If ツールの結果

ポリシーのデプロイPolicy deployment

ポリシーが期待どおりに機能することを確実にするために推奨されるベスト プラクティスは、運用環境にロールアウトする前にポリシーをテストすることです。To make sure that your policy works as expected, the recommended best practice is to test it before rolling it out into production. テスト テナントを使用して、新しいポリシーが意図したとおりに機能するかどうかを確認するのが理想的です。Ideally, use a test tenant to verify whether your new policy works as intended. 詳細については、「Azure Active Directory の条件付きアクセスのベスト プラクティス」の記事を参照してください。For more information, see the article Best practices for Conditional Access in Azure Active Directory.

次のステップNext steps