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

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

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

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

• すべてのユーザーに対して、多要素認証への登録を必須にする
• 管理者に多要素認証の実行を要求する
• 必要に応じてユーザーに多要素認証の実行を要求する
• レガシ認証プロトコルをブロックする
• Azure portal へのアクセスなどの特権が必要な作業を保護する

適した組織

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

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

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

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

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

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

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

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

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

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

1. セキュリティ管理者 以上の権限で Microsoft Entra 管理センター にサインインします。
2. ID>概要>プロパティ を参照します。
3. [セキュリティの既定値群の管理] を選択します。
4. [セキュリティの既定値群] を [有効] に設定します。
5. [保存] を選択します。

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

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

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

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

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

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

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

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

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

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

• 認証ポリシー管理者
• ID ガバナンス管理者

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

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

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

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

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

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

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

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

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

• Microsoft 365 を使用して電子メールを送信するように多機能機器またはアプリケーションを設定する方法

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 も含まれません。

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

ユーザーの準備

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

認証方法

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

B2B ユーザー

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

無効な MFA の状態

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

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

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

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

1. セキュリティ管理者 以上の権限で Microsoft Entra 管理センター にサインインします。
2. ID>概要>プロパティ を参照します。
3. [セキュリティの既定値群の管理] を選択します。
4. [セキュリティの既定値群] を [Disabled (not recommended)] (無効 (非推奨)) に設定します。
5. [保存] を選択します。

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

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

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

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

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

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

次のステップ

• ブログ: セキュリティの既定値群の導入
• ライセンスの詳細については、Microsoft Entra の価格に関するページを参照してください。