一般的な条件付きアクセス ポリシー: すべてのユーザーに対して MFA を必須にする
Microsoft の ID セキュリティ責任者、Alex Weinert は彼のブログ投稿「Your Pa$$word doesn't matter」で次のように言っています。
「重要なのはパスワードではなく、MFA です!」 私たちの研究によると、MFA を使用すると、アカウントは 99.9% 以上侵害されにくくなります。
この記事のガイダンスは、組織が環境に適した MFA ポリシーを作成する際に役立ちます。
ユーザーの除外
条件付きアクセス ポリシーは強力なツールであり、次のアカウントをポリシーから除外することをお勧めします。
- 緊急アクセス用アカウントまたは非常用アカウント。テナント全体でアカウントがロックアウトされるのを防ぎます。 発生する可能性は低いシナリオですが、すべての管理者がテナントからロックアウトされた場合に、ご自身の緊急アクセス用管理アカウントを使用してテナントにログインし、アクセスの復旧手順を実行できます。
- 詳細については、「Azure AD で緊急アクセス用アカウントを管理する」を参照してください。
- サービス アカウントとサービス プリンシパル (Azure AD Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型のアカウントです。 これらは通常、アプリケーションへのプログラムによるアクセスを可能にするバックエンド サービスによって使用されますが、管理目的でシステムにサインインする場合にも使用されます。 プログラムでは MFA を完了できないため、このようなサービス アカウントは対象外とする必要があります。 サービス プリンシパルによる呼び出しは、ユーザーをスコープとする条件付きアクセス ポリシーではブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
- 組織のスクリプトまたはコードでこれらのアカウントが使用されている場合は、それをマネージド ID に置き換えることを検討してください。 これらの特定のアカウントは、一時的な回避策として、ベースライン ポリシーの対象外にすることができます。
アプリケーションの除外
組織には、使用中のクラウド アプリケーションが多数あります。 これらのアプリケーションすべてで、同等のセキュリティが必要なわけではありません。 たとえば、給与と勤怠のアプリケーションには MFA が必要でも、カフェのアプリケーションでは必要ない可能性があります。 管理者は、ポリシーから特定のアプリケーションを除外することを選択できます。
サブスクリプションのライセンス認証
サブスクリプションのアクティブ化を使用してユーザーが Windows をあるバージョンから別へと "ステップアップ" できるようにする組織は、ユニバーサル ストア サービス API と Web アプリケーション (AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f) をすべてのユーザーのすべてのクラウド アプリ MFA ポリシーから除外できます。
テンプレートのデプロイ
組織は、このポリシーをデプロイするのに以下に示す手順を使用するか、条件付きアクセス テンプレートを使用するかを選ぶことができます。
条件付きアクセス ポリシーを作成する
次の手順は、すべてのユーザーに対して多要素認証の実行を必須にする条件付きアクセス ポリシーを作成するのに役立ちます。
- 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。
- [保護]>[条件付きアクセス] に移動します。
- [新しいポリシーの作成] を選択します。
- ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
- [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
- [Include](含める) で、 [すべてのユーザー] を選択します。
- [除外] で、 [ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
- [ターゲット リソース]>[クラウド アプリ]>[対象] で、[すべてのクラウド アプリ] を選択します。
- [除外] で、多要素認証を必要としないアプリケーションを選択します。
- [アクセス制御]>[許可] で、[アクセス権の付与]、[多要素認証を要求する] の順に選択し、[選択する] を選択します。
- 設定を確認し、 [ポリシーの有効化] を [レポート専用] に設定します。
- [作成] を選択して、ポリシーを作成および有効化します。
管理者は、レポート専用モードを使用して設定を確認したら、[ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動できます。
ネームド ロケーション
組織では、条件付きアクセス ポリシーに「ネームド ロケーション」と呼ばれる既知のネットワークの場所を組み込むことができます。 こうしたネームド ロケーションには、メイン オフィスの場所のような信頼できる IPv4 ネットワークを含めることができます。 ネームド ロケーションの構成の詳細については、「Azure Active Directory 条件付きアクセスの場所の条件の概要」の記事を参照してください。
上記のポリシーの例では、組織は自社のネットワークからクラウド アプリにアクセスする場合に多要素認証を必要としないことを選択できます。 この場合、次の構成をポリシーに追加できます。
- [割り当て] で、 [条件]>[場所] を選択します。
- [はい] を構成します。
- [任意の場所] を含めます。
- [すべての信頼できる場所] を除外します。
- [Done] を選択します。
- [Done] を選択します。
- ポリシーの変更を保存します。