Configuration Managerでのセキュリティの計画

  • [アーティクル]

Configuration Manager (現在のブランチ) に適用

この記事では、Configuration Manager実装でセキュリティを計画するときに考慮する必要がある次の概念について説明します。

  • 証明書 (自己署名および PKI)

  • 信頼されたルート キー

  • 署名と暗号化

  • ロールベース管理

  • Microsoft Entra ID

  • SMS プロバイダー認証

開始する前に、Configuration Managerのセキュリティの基礎について理解していることを確認してください。

証明書

Configuration Managerでは、自己署名および公開キー 基盤 (PKI) デジタル証明書の組み合わせを使用します。 可能な限り PKI 証明書を使用します。 一部のシナリオでは、PKI 証明書が必要です。 PKI 証明書を使用できない場合、サイトは自動的に自己署名証明書を生成します。 一部のシナリオでは、常に自己署名証明書が使用されます。

詳細については、「 証明書の計画」を参照してください。

信頼されたルート キー

信頼されたルート キー Configuration Managerは、Configuration Managerクライアントがサイト システムが階層に属していることを確認するためのメカニズムを提供します。 すべてのサイト サーバーは、他のサイトと通信するためのサイト交換キーを生成します。 階層内の最上位サイトのサイト交換キーは、信頼されたルート キーと呼ばれます。

Configuration Managerの信頼されたルート キーの機能は、公開キー インフラストラクチャのルート証明書に似ています。 信頼されたルート キーの秘密キーによって署名されたものは、さらに階層の下で信頼されます。 クライアントは、サイトの信頼されたルート キーのコピーを WMI 名前空間に root\ccm\locationservices 格納します。

たとえば、サイトは管理ポイントに証明書を発行し、信頼されたルート キーの秘密キーで署名します。 サイトは、信頼されたルート キーの公開キーをクライアントと共有します。 その後、クライアントは、階層内にある管理ポイントと、階層内にない管理ポイントを区別できます。

クライアントは、次の 2 つのメカニズムを使用して、信頼されたルート キーのパブリック コピーを自動的に取得します。

  • Configuration Managerの Active Directory スキーマを拡張し、サイトをActive Directory Domain Servicesに発行します。 次に、クライアントはグローバル カタログ サーバーからこのサイト情報を取得します。 詳細については、「 サイトの発行のために Active Directory を準備する」を参照してください。

  • クライアント プッシュ インストール方法を使用してクライアントをインストールする場合。 詳細については、「 クライアント プッシュ インストール」を参照してください。

これらのメカニズムのいずれかを使用して信頼されたルート キーを取得できない場合、クライアントは、通信する最初の管理ポイントによって提供される信頼されたルート キーを信頼します。 このシナリオでは、クライアントが不正な管理ポイントからポリシーを受け取る攻撃者の管理ポイントに誤った方向を向ける可能性があります。 このアクションには、高度な攻撃者が必要です。 この攻撃は、クライアントが有効な管理ポイントから信頼されたルート キーを取得するまでの短い時間に制限されます。 攻撃者がクライアントを不正な管理ポイントに誤って送信するリスクを軽減するには、信頼されたルート キーを使用してクライアントを事前にプロビジョニングします。

信頼されたルート キーを管理するための詳細と手順については、「セキュリティの 構成」を参照してください。

署名と暗号化

すべてのクライアント通信に PKI 証明書を使用する場合、クライアント データ通信をセキュリティで保護するために署名と暗号化を計画する必要はありません。 HTTP クライアント接続を許可するように IIS を実行するサイト システムを設定する場合は、サイトのクライアント通信をセキュリティで保護する方法を決定します。

重要

バージョン 2103 Configuration Manager以降、HTTP クライアント通信を許可するサイトは非推奨となりました。 HTTPS または拡張 HTTP 用にサイトを構成します。 詳細については、「 HTTPS 専用または拡張 HTTP のサイトを有効にする」を参照してください。

クライアントが管理ポイントに送信するデータを保護するために、クライアントにデータへの署名を要求できます。 署名には SHA-256 アルゴリズムを必要とすることもできます。 この構成の方が安全ですが、すべてのクライアントが 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 プロバイダー認証の構成」を参照してください。

次の手順