次の方法で共有

Microsoft Entra ID のセキュリティの既定値群

  • [アーティクル]

セキュリティの既定値群を使用すると、今日の環境で一般的なパスワード スプレー、リプレイ、フィッシングなどの ID 関連の攻撃から組織を簡単に保護できます。

セキュリティの管理は難しい場合があるため、Microsoft では、すべてのユーザーが事前構成されたセキュリティの既定値群を使用できるようにしています。 Microsoft の知見によれば、これらの一般的な ID 関連攻撃の 99.9% 以上は、多要素認証を使ってレガシ認証をブロックすることで阻止されます。 Microsoft の目標は、すべての組織が追加の費用なしで少なくとも基本レベルのセキュリティを確実に有効にできるようにすることです。

これらの基本的なコントロールには、次のものが含まれます:

適した組織

  • セキュリティ体制を向上させたいが、どこから始めればいいのかわからない組織。
  • Microsoft Entra ID ライセンスの Free レベルを使用している組織。

条件付きアクセスを使用する必要がある組織

  • Microsoft Entra ID P1 または P2 ライセンスを所有している組織の場合、セキュリティの既定値群が適切でない可能性があります。
  • 組織に複雑なセキュリティ要件がある場合は、条件付きアクセスを検討する必要があります。

セキュリティの既定値群の有効化

2019 年 10 月 22 日以降に作成されたテナントの場合、セキュリティの既定値群がテナントで有効になっている可能性があります。 すべてのユーザーを保護するために、セキュリティの既定値群は、作成時にすべての新しいテナントにロールアウトされます。

組織を保護するために、Microsoft は常に Microsoft アカウント サービスのセキュリティの向上に取り組んでいます。 この保護の一環として、お客様は次の場合にセキュリティの既定値の自動有効化について定期的に通知されます:

  • 条件付きアクセス ポリシーがない
  • Premium ライセンスを持っていない
  • レガシ認証クライアントを積極的に使用していない

この設定を有効にすると、組織内のすべてのユーザーが多要素認証に登録する必要があります。 混乱を避けるため、受信したメールを参照してください。また、有効にした後にセキュリティ規制値群を無効にすることもできます。

ディレクトリでセキュリティの既定値を構成するには、少なくとも 条件付きアクセス管理者 ロールが割り当てられている必要があります。 既定では、任意のディレクトリの最初のアカウントには、全体管理者と呼ばれるより高位の特権ロールが割り当てられます。

次のようにして、セキュリティの既定値群を有効にします。

  1. 少なくとも 条件付きアクセス管理者として、Microsoft Entra 管理センター にサインインします。
  2. ID>概要>プロパティ を参照します。
  3. [セキュリティの既定値群の管理] を選択します。
  4. [セキュリティの既定値群] を [有効] に設定します。
  5. [保存] を選択します。

セキュリティの既定値群を有効にするためのトグルがある Microsoft Entra 管理センターのスクリーンショット

アクティブなトークンの取り消し

セキュリティの既定値を有効にする一環として、管理者は既存のすべてのトークンを取り消して、すべてのユーザーに多要素認証の登録を要求する必要があります。 この失効イベントにより、以前に認証されたユーザーが多要素認証の認証と登録を強制されます。 このタスクは、Revoke-AzureADUserAllRefreshToken PowerShell コマンドレットを使用して実行できます。

適用されたセキュリティ ポリシー

すべてのユーザーに対して Microsoft Entra 多要素認証への登録を必須にする

Note

2024 年 7 月 29 日以降、新しいテナントには、ユーザーが MFA に登録するための 14 日間の猶予期間がないことがあります。 MFA は ID ベースの攻撃の 99.2% 以上をブロックできるため、14 日間の期間中にアカウント侵害のリスクを軽減するために、この変更をしています。

すべてのユーザーは、14 日以内に Microsoft Authenticator アプリまたはアプリをサポートする任意の OATH TOTP を使用して、登録する必要があります。 14 日が経過すると、ユーザーは登録が完了するまでサインインできなくなります。 14 日の期間は、セキュリティの既定値群が有効になった後、それぞれのユーザーの対話型サインインが最初に成功した時点から始まります。

ユーザーがサインインして、多要素認証の実行を求められると、Microsoft Authenticator アプリに入力する番号を示す画面が表示されます。 この対策は、ユーザーが MFA 疲労攻撃に陥るのを防ぐうえで役立ちます。

入力する番号が表示された [サインイン要求の承認] ウィンドウの例を示したスクリーンショット。

管理者に多要素認証の実行を要求する

管理者は、より自由に環境にアクセスできます。 これらの高度な特権アカウントには権限があるので、特別な注意を払って対処する必要があります。 特権アカウントの保護を強化するための一般的な方法の 1 つは、サインイン時に、より強力な形式のアカウント検証を必須にすること (多要素認証を必須にするなど) です。

ヒント

管理者向けの推奨事項:

  • 認証方法に登録できるように、セキュリティの既定値を有効にした後は、すべての管理者がサインインするようにしてください。
  • 管理者の MFA の回数を大幅に減らすために、管理タスクと標準の生産性タスク用に個別のアカウントを用意してください。

次の管理者の役割では、登録が完了した後、サインインのたびに多要素認証を実行する必要があります。

  • グローバル管理者
  • アプリケーション管理者
  • 認証管理者
  • 課金管理者
  • クラウド アプリケーション管理者
  • 条件付きアクセス管理者
  • Exchange 管理者
  • ヘルプデスク管理者
  • パスワード管理者
  • 特権認証管理者
  • 特権ロール管理者
  • セキュリティ管理者
  • SharePoint 管理者
  • ユーザー管理者
  • 認証ポリシー管理者
  • Identity Governance 管理者

必要に応じてユーザーに多要素認証の実行を要求する

認証の追加のレイヤーが必要なアカウントは管理者アカウントだけであると考えがちです。 管理者は、機密情報への広範なアクセス権を持ち、サブスクリプション全体の設定に変更を加えることができます。 しかし、多くの場合、攻撃者はエンド ユーザーをターゲットにします。

これらの攻撃者は、アクセス権を取得した後、元のアカウント所有者の代わりに機密性の高い情報へのアクセスを要求できます。 ディレクトリ全体をダウンロードして、組織全体に対してフィッシング攻撃を実行することさえできます。

すべてのユーザーを対象にした保護を向上させるための一般的な方法の 1 つは、全員に多要素認証を要求するなど、より強力な形式のアカウント検証を要求することです。 ユーザーが登録を完了すると、必要に応じて他の認証を求められるようになります。 Microsoft では、場所、デバイス、役割、タスクなどの要素に基づいて、ユーザーに多要素認証を求めるタイミングが決定されます。 この機能は、SaaS アプリケーションを含め、登録されているすべてのアプリケーションを保護します。

Note

B2B 直接接続ユーザーの場合、リソース テナントで有効になっているセキュリティの既定値による多要素認証の要件 (ホーム テナントの直接接続ユーザーによる多要素認証の登録など) を満たす必要があります。

レガシ認証プロトコルをブロックする

ユーザーがクラウド アプリに簡単にアクセスできるように、レガシ認証を含め、さまざまな認証プロトコルがサポートされています。 "レガシ認証" は、以下のものによって行われる認証要求を指す用語です。

  • 先進認証を使用していないクライアント (Office 2010 クライアントなど)
  • IMAP、SMTP、POP3 などの古いメール プロトコルを使用しているクライアント

現在、危険にさらそうとするサインイン試行はほとんどレガシ認証から来ています。 レガシ認証では、多要素認証がサポートされていません。 ディレクトリで多要素認証 ポリシーが有効になっている場合でも、攻撃者は、古いプロトコルを使用して認証を受け、多要素認証をバイパスすることができます。

テナントでセキュリティ デフォルトが有効になった後は、古いプロトコルによるすべての認証要求がブロックされます。 セキュリティ既定値は、Exchange Active Sync 基本認証をブロックします。

警告

セキュリティの既定値群を有効にする前に、管理者が古い認証プロトコルを使用していないことを確認してください。 詳細については、レガシ認証から移行する方法に関するページを参照してください。

Azure portal へのアクセスなどの特権が必要な作業を保護する

組織では、Azure Resource Manager API によって管理される、次のようなさまざまな Azure サービスを使用します。

  • Azure portal
  • Microsoft Entra 管理センター
  • Azure PowerShell
  • Azure CLI

Azure Resource Manager を使用してご自身のサービスを管理する操作は、高い権限が与えられているアクションです。 Azure Resource Manager では、サービス設定、サブスクリプションの課金など、テナント全体の構成を変更できます。 単一要素認証は、フィッシング、パスワード スプレーなどのさまざまな攻撃に対して脆弱です。

Azure Resource Manager にアクセスして構成を更新しようとするユーザーの ID を検証することが重要です。 アクセスを許可する前に、追加の認証を要求して ID を検証します。

テナントでセキュリティの既定値群を有効にした後、次のサービスにアクセスするすべてのユーザーが多要素認証を完了する必要があります。

  • Azure portal
  • Microsoft Entra 管理センター
  • Azure PowerShell
  • Azure CLI

このポリシーは、Azure Resource Manager サービスにアクセスしようとしているユーザーであれば、管理者であるかユーザーであるかに関係なく全員に適用されます。 このポリシーは、サブスクリプション、VM、ストレージ アカウントなどへのアクセスなど、Azure Resource Manager API に適用されます。 このポリシーには、Microsoft Entra ID も Microsoft Graph も含まれません。

Note

2017 年より前の Exchange Online テナントでは、先進認証が既定で無効になっています。 これらのテナントを通じて認証を行うときにログイン ループの可能性を回避するために、先進認証を有効にする必要があります。

Note

Microsoft Entra Connect の同期アカウントはセキュリティの既定値群から除外されており、多要素認証の登録または実行を求めるプロンプトは表示されません。 組織は、このアカウントを他の目的で使用しないでください。

デプロイに関する考慮事項

ユーザーの準備

予定されている変更、登録要件、必要なユーザー操作について、ユーザーに通知することが重要です。 お客様のユーザーに新しいエクスペリエンスに向けて準備をさせ、ロールアウトの確実な成功を支援するために、通信テンプレートとユーザー ドキュメントが用意されています。 ユーザーを https://myprofile.microsoft.com に誘導し、そのページの [セキュリティ情報] リンクを選択して登録してもらいます。

認証方法

セキュリティの既定値群のユーザーは、通知を使用する Microsoft Authenticator アプリを使って多要素認証に登録し、多要素認証を使用する必要があります。 ユーザーは、Microsoft Authenticator アプリからの確認コードを使用できますが、通知オプションを使用した場合にのみ登録できます。 ユーザーは、OATH TOTP を 使用してコードを生成するサード パーティ製アプリケーションを使用することもできます。

警告

セキュリティの既定値群を使用している場合は、組織のメソッドを無効にしないでください。 メソッドを無効にすると、ご自分のテナントからロックアウトされる可能性があります。 MFA サービス設定ポータルで、 [ユーザーが使用できる方法] をすべて有効のままにしておきます。

B2B ユーザー

ディレクトリにアクセスするすべての B2B ゲスト ユーザーまたは B2B 直接接続ユーザーは、組織のユーザーと同じように扱われます。

無効な MFA の状態

組織が以前にユーザーごとの多要素認証を使用していた場合、多要素認証の状態のページを確認したときに、ユーザーが [有効] または [強制] 状態になっていなくても問題ありません。 セキュリティの既定値群または条件付きアクセスをベースとする多要素認証を使用しているユーザーの場合は、[無効] が適切な状態です。

セキュリティの既定値群を無効にする

セキュリティの既定値群を置き換える条件付きアクセス ポリシーを実装する組織では、セキュリティの既定値群を無効にする必要があります。

ディレクトリでセキュリティの既定値群を無効にするには、次のようにします。

  1. 少なくとも 条件付きアクセス管理者として、Microsoft Entra 管理センター にサインインします。
  2. ID>概要>プロパティ を参照します。
  3. [セキュリティの既定値群の管理] を選択します。
  4. [セキュリティの既定値群] を [Disabled (not recommended)] (無効 (非推奨)) に設定します。
  5. [保存] を選択します。

セキュリティの既定値群から条件付きアクセスに移行する

セキュリティの既定値群は、セキュリティ態勢を開始するための適切なベースラインですが、多くの組織が必要とするカスタマイズに対応していません。 条件付きアクセス ポリシーは、より複雑な組織が必要とするさまざまなカスタマイズを提供します。

セキュリティの既定値群 条件付きアクセス
必要なライセンス なし Microsoft Entra ID P1 以上
カスタマイズ カスタマイズなし (オンまたはオフ) フル カスタマイズが可能
有効化 Microsoft または管理者 管理者
複雑性 簡単に使用できる 要件に基づいてフル カスタマイズが可能

セキュリティの既定値群から移行するときに推奨される手順

条件付きアクセスの機能をテストしたい組織は、無料試用版にサインアップして開始できます。

管理者がセキュリティの既定値群を無効にした後、組織は、組織を保護するためにただちに条件付きアクセス ポリシーを有効にする必要があります。 これらのポリシーには、条件付きアクセス テンプレートのセキュリティで保護された基盤カテゴリに、少なくともこれらのポリシーを含める必要があります。 Microsoft Entra ID Protection を含む Microsoft Entra ID P2 ライセンスを持つ組織は、この一覧を展開して、ユーザー リスクベースとサインイン リスクベースのポリシーを含めて態勢をさらに強化できます。

Microsoft は、組織が全体管理者ロールが永続的に割り当てられる 2 つのクラウド専用緊急アクセス アカウントを作成することを推奨しています。 このようなアカウントは高い特権を持っており、特定のユーザーには割り当てられません。 これらのアカウントは、通常のアカウントを使用できない、または他のすべての管理者が誤ってロックアウトされたという緊急または "break glass" のシナリオに限定されます。これらのアカウントは、緊急アクセス アカウントに関する推奨事項に従って作成する必要があります。

次のステップ