Configuration Manager でセキュリティを計画する

適用対象: Configuration Manager (現在のブランチ)

この記事では、Configuration Manager の実装でセキュリティを計画する際に考慮すべき以下の概念について説明します。

  • 証明書 (自己署名証明書と PKI)

  • 信頼されたルート キー

  • 署名と暗号化

  • ロールベース管理

  • Azure Active Directory

  • SMS プロバイダー認証

開始する前に、Configuration Manager のセキュリティの基本について理解 している必要があります

証明書

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

詳細については、「Plan for certificates」を参照してください

信頼されたルート キー

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

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

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

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

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

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

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

信頼されたルート キーを管理する方法の詳細と手順については 、「Configure security 」を参照してください

署名と暗号化

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

重要

Configuration Manager バージョン 2103 から、HTTP クライアント通信を許可するサイトは廃止されました。 HTTPS または拡張 HTTP のサイトを構成します。 詳細については 、「HTTPS 専用または拡張 HTTP のサイトを有効にする」を参照してください

クライアントが管理ポイントに送信するデータを保護するために、クライアントにデータへの署名を要求できます。 署名には SHA-256 アルゴリズムも必要です。 この構成は、より安全ですが、すべてのクライアントがサポートしない限り、SHA-256 は必要としません。 多くのオペレーティング システムは、このアルゴリズムをネイティブにサポートしていますが、古いオペレーティング システムでは更新プログラムまたは修正プログラムが必要になる場合があります。

署名はデータを改ざんから保護するのに役立ちますが、暗号化はデータを情報漏えいから保護するのに役立ちます。 サイト内の管理ポイントにクライアントが送信するインベントリ データと状態メッセージの暗号化を有効にできます。 このオプションをサポートするために、クライアントに更新プログラムをインストールする必要はありません。 クライアントと管理ポイントでは、暗号化と復号化に必要な CPU 使用率が高い。

注意

データを暗号化するために、クライアントは管理ポイントの暗号化証明書の公開キーを使用します。 管理ポイントだけが対応する秘密キーを持つので、データを解読できるのは管理ポイントのみです。

クライアントは管理ポイントの署名証明書を使用してこの証明書をブートストラップし、サイトの信頼されたルート キーを使用してブートストラップします。 信頼できるルート キーをクライアントに安全にプロビジョニングしてください。 詳細については、「信頼できるルート キー」を参照してください

署名と暗号化の設定を構成する方法の詳細については、「署名と暗号化の構成 」を参照してください

署名と暗号化に使用される暗号化アルゴリズムの詳細については、「 暗号化コントロールのテクニカル リファレンス」を参照してください

ロールベース管理

Configuration Manager では、役割ベースの管理を使用して、管理ユーザーが Configuration Manager を使用するために必要なアクセスをセキュリティで保護します。 また、コレクション、展開、サイトなど、管理するオブジェクトへのアクセスをセキュリティで保護します。

セキュリティ ロール、セキュリティ スコープ、およびコレクションを組み合わせて、組織の要件を満たす管理割り当てを分離します。 一緒に使用して、ユーザー の管理スコープ を定義します。 この管理スコープは、Configuration Manager コンソールで管理ユーザーが表示するオブジェクトを制御し、ユーザーがそれらのオブジェクトに対して持つアクセス許可を制御します。

詳細については、「ロール ベース管理の基礎」を参照してください。

Azure Active Directory

Configuration Manager は、Azure Active Directory (Azure AD) と統合して、サイトとクライアントが最新の認証を使用できます。

このドキュメントの詳細については、「Azure ADドキュメント」をAzure Active Directoryしてください

サイトをオンボーディングするAzure AD 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認証 : デバイスに関連付け、生体認証または PIN を使用する強力な 2 要素認証による認証が必要です。 詳細については、「ビジネス向けWindows Hello」を参照してください

    重要

    この設定を選択すると、SMS プロバイダーと管理サービスでは、ユーザーの認証トークンにビジネス向けサービスからの多要素認証 (MFA) 要求を含Windows Hello必要があります。 つまり、コンソール、SDK、PowerShell、または管理サービスのユーザーは、ビジネス PIN または生体認証のWindowsを使用Windows Hello認証する必要があります。 それ以外の場合、サイトはユーザーのアクションを拒否します。

    この動作は Business Windows Hello の動作で、この 動作はWindows Hello。

この設定を構成する方法の詳細については 、「Configure SMS Provider authentication 」を参照してください

次の手順