Configuration Manager (現在のブランチ) に適用
この記事では、Configuration Manager の実装によるセキュリティを計画するときに考慮すべき次の概念について説明します。
証明書 (自己署名証明書と PKI)
信頼されたルート キー
署名と暗号化
ロールベース管理
Microsoft Entra ID
SMS プロバイダー認証
開始する前に、Configuration Manager のセキュリティの基礎を理解していることを確認してください。
証明書
Configuration Manager では、自己署名証明書と公開キー基盤 (PKI) デジタル証明書を組み合わせて使用します。 可能な限り PKI 証明書を使用します。 一部のシナリオでは PKI 証明書が必要です。 PKI 証明書を利用できない場合、サイトは自己署名証明書を自動的に生成します。 一部のシナリオでは、常に自己署名証明書が使用されます。
詳細については、「 証明書の計画」を参照してください。
信頼されたルート キー
Configuration Manager の信頼されたルート キーは、Configuration Manager クライアントがサイト システムが階層に属していることを確認するメカニズムを提供します。 すべてのサイト サーバーは、他のサイトと通信するためにサイト交換キーを生成します。 階層内の最上位サイトのサイト交換キーは、信頼されたルート キーと呼ばれます。
Configuration Manager の信頼されたルート キーの機能は、公開キー基盤におけるルート証明書に似ています。 信頼されたルート キーの秘密キーで署名されたものはすべて、階層のさらに下位で信頼されます。 クライアントは、サイトの信頼されたルート キーのコピーを root\ccm\locationservices WMI 名前空間に格納します。
たとえば、サイトは管理ポイントに証明書を発行し、管理ポイントは信頼されたルート キーの秘密キーで署名します。 サイトは、信頼されたルート キーの公開キーをクライアントと共有します。 そうすると、クライアントは階層内の管理ポイントと階層内にない管理ポイントを区別できます。
クライアントは、次の 2 つのメカニズムを使用して、信頼されたルート キーのパブリック コピーを自動的に取得します。
Configuration Manager の Active Directory スキーマを拡張し、サイトを Active Directory Domain Services に公開します。 次に、クライアントはグローバル カタログ サーバーからこのサイト情報を取得します。 詳細については、「 サイトを公開するために Active Directory を準備する」を参照してください。
クライアント プッシュ インストール方法を使用してクライアントをインストールする場合。 詳細については、「 クライアント プッシュ インストール」を参照してください。
クライアントがこれらのメカニズムのいずれかを使用して信頼されたルート キーを取得できない場合、クライアントは、通信する最初の管理ポイントによって提供される信頼されたルート キーを信頼します。 このシナリオでは、クライアントが攻撃者の管理ポイントに誤って誘導され、不正な管理ポイントからポリシーを受け取る可能性があります。 このアクションには、巧妙な攻撃者が必要です。 この攻撃は、クライアントが有効な管理ポイントから信頼されたルート キーを取得するまでの短い時間に限定されます。 攻撃者がクライアントを不正な管理ポイントに誤って転送するリスクを軽減するには、信頼されたルート キーを使用してクライアントを事前にプロビジョニングします。
信頼されたルート キーを管理するための詳細と手順については、「 セキュリティの構成」を参照してください。
署名と暗号化
すべてのクライアント通信に PKI 証明書を使用する場合、クライアント データ通信をセキュリティで保護するために署名と暗号化を計画する必要はありません。 HTTP クライアント接続を許可するように IIS を実行するサイト システムを設定する場合は、サイトのクライアント通信をセキュリティで保護する方法を決定します。
重要
Configuration Manager バージョン 2103 以降では、HTTP クライアント通信を許可するサイトは非推奨です。 HTTPS または拡張 HTTP 用にサイトを構成します。 詳細については、「 サイトで HTTPS のみまたは拡張 HTTP を有効にする」を参照してください。
クライアントが管理ポイントに送信するデータを保護するために、クライアントにデータの署名を要求できます。 署名に SHA-256 アルゴリズムを要求することもできます。 この構成はより安全ですが、すべてのクライアントがサポートしない限り、SHA-256 は必要ありません。 多くのオペレーティング システムではこのアルゴリズムがネイティブでサポートされていますが、以前のオペレーティング システムでは更新プログラムまたは修正プログラムが必要になる場合があります。
署名はデータを改ざんから保護するのに役立ちますが、暗号化はデータを情報漏えいから保護するのに役立ちます。 クライアントがサイト内の管理ポイントに送信するインベントリ データと状態メッセージの暗号化を有効にすることができます。 このオプションをサポートするために、クライアントに更新プログラムをインストールする必要はありません。 クライアントと管理ポイントでは、暗号化と暗号化解除のためにより多くの CPU 使用率が必要になります。
注:
データを暗号化するために、クライアントは管理ポイントの暗号化証明書の公開キーを使用します。 対応する秘密キーを持っているのは管理ポイントだけなので、管理ポイントだけがデータを復号化できます。
クライアントは、サイトの信頼されたルート キーを使用してブートストラップする管理ポイントの署名証明書を使用してこの証明書をブートストラップします。 クライアントで信頼されたルート キーを安全にプロビジョニングしてください。 詳細については、「 信頼されたルート キー」を参照してください。
署名と暗号化の設定を構成する方法の詳細については、「 署名と暗号化の構成」を参照してください。
署名および暗号化に使用される暗号化アルゴリズムの詳細については、「 暗号化制御テクニカル リファレンス」を参照してください。
ロールベース管理
Configuration Manager では、役割ベースの管理を使用して、管理ユーザーが Configuration Manager を使用するために必要なアクセスをセキュリティで保護します。 また、コレクション、デプロイ、サイトなど、管理するオブジェクトへのアクセスもセキュリティで保護します。
セキュリティ ロール、セキュリティ スコープ、コレクションを組み合わせることで、organizationの要件を満たす管理割り当てを分離できます。 これらを組み合わせて使用すると、ユーザーの 管理スコープ が定義されます。 この管理スコープは、管理ユーザーが Configuration Manager コンソールに表示するオブジェクトを制御し、それらのオブジェクトに対するユーザーのアクセス許可を制御します。
詳細については、「ロール ベース管理の基礎」を参照してください。
Microsoft Entra ID
Configuration Manager は Microsoft Entra ID と統合され、サイトとクライアントが最新の認証を使用できるようにします。
Microsoft Entra ID の詳細については、Microsoft Entra のドキュメントを参照してください。
Microsoft Entra ID を使用してサイトをオンボードすると、次の Configuration Manager シナリオがサポートされます。
クライアント シナリオ
サーバーのシナリオ
SMS プロバイダー認証
管理者が Configuration Manager サイトにアクセスするための最小認証レベルを指定できます。 この機能により、管理者は Configuration Manager にアクセスする前に、必要なレベルで Windows にサインインする必要があります。 これは、SMS プロバイダーにアクセスするすべてのコンポーネントに適用されます。 たとえば、Configuration Manager コンソール、SDK メソッド、Windows PowerShell コマンドレットなどです。
Configuration Manager は、次の認証レベルをサポートします。
Windows 認証: Active Directory ドメイン資格情報による認証を要求します。 この設定は、以前の動作であり、現在の既定の設定です。
証明書認証: 信頼された PKI 証明機関が発行した有効な証明書による認証を要求します。 この証明書は Configuration Manager では構成しません。 Configuration Manager では、管理者が PKI を使用して Windows にサインインする必要があります。
Windows Hello for Business 認証: デバイスに関連付けられ、生体認証または PIN を使用する強力な 2 要素認証による認証が必要です。 詳しくは、「Windows Hello for Business」をご覧ください。
重要
この設定を選択すると、SMS プロバイダーと管理サービスでは、ユーザーの認証トークンに Windows Hello for Business からの多要素認証 (MFA) 要求が含まれている必要があります。 つまり、コンソール、SDK、PowerShell、または管理サービスのユーザーは、Windows Hello for Business PIN または生体認証を使用して Windows に対して認証する必要があります。 それ以外の場合、サイトはユーザーのアクションを拒否します。
この動作は、Windows Hello ではなく Windows Hello for Business 向けです。
この設定を構成する方法の詳細については、「 SMS プロバイダー認証を構成する」を参照してください。