Configuration Manager で使用される暗号化制御のテクニカル リファレンス

 

適用対象: System Center 2012 Configuration Manager,System Center 2012 Configuration Manager SP1,System Center 2012 Configuration Manager SP2,System Center 2012 R2 Configuration Manager,System Center 2012 R2 Configuration Manager SP1

[!メモ]

このトピックは次の場所に表示されます:「System Center 2012 Configuration Manager のサイト管理」ガイドおよび「System Center 2012 Configuration Manager のセキュリティとプライバシー」ガイド

System Center 2012 Configuration Manager は、署名および暗号化を使用して、Configuration Manager 階層内のデバイスの管理を保護します。 署名を使用すると、データが伝送中に変更された場合に、そのデータが破棄されます。 暗号化は、攻撃者がネットワーク プロトコル アナライザーを使用してデータを読み取ることを防ぎます。

Configuration Manager で使用する署名のハッシュ アルゴリズムは SHA-256 です。 2 つの Configuration Manager サイトが互いに通信するときは、SHA-256 を使用して通信に署名します。Configuration Manager に実装される主な暗号化アルゴリズムは 3DES です。 これは、Configuration Manager データベースにデータを格納する場合、およびクライアントが HTTP を使用して通信する場合に使用されます。 HTTPS を介したクライアント通信を使用する場合は、公開キー基盤 (PKI) を構成して、「Configuration Manager での PKI 証明書の要件」で説明している最も強力なハッシュ アルゴリズムおよびキーの最大長を使用した RSA 証明書を使用できます。

Windows ベースのオペレーティング システムの大部分の暗号化操作で、Configuration Manager は、Windows CryptoAPI ライブラリ rsaenh.dll の SHA-1、SHA-2、3DES と AES、RSA アルゴリズムを使用します。

詳細については、次のセクションを参照してください。

• Configuration Manager の操作での暗号化の制御

• Configuration Manager で使用される証明書

• サーバー通信の暗号化制御

• サイト システムに対して HTTPS 通信を使用するクライアントの暗号化制御

• サイト システムに対して HTTP 通信を使用するクライアントの暗号化制御

重要
SSL の脆弱性について における SSL の脆弱性に対応する推奨される変更点に関する情報をご覧ください。

Configuration Manager の操作での暗号化の制御

Configuration Manager で PKI 証明書を使用しているかどうかにかかわらず、Configuration Manager の情報は署名および暗号化できます。

ポリシーの署名と暗号化

クライアントのポリシー割り当ては、証明書に署名する自己署名サイト サーバーによって署名されています。これは、侵害された管理ポイントから改ざんされたポリシーが送信されるというセキュリティ上の危険を防止するためです。 この防御策は特に、インターネットベースのクライアント管理を使用している場合に適しています。これは、この環境ではインターネット接続に公開されている管理ポイントが必要となるためです。

ポリシーに機密データが含まれている場合は、3DES を使用して暗号化されます。 機密データが含まれているポリシーは、承認されているクライアントにのみ送信されます。 機密データが含まれていないポリシーは暗号化されません。

ポリシーがクライアントに保存されるときは、データ保護アプリケーション プログラミング インターフェイス (DPAPI) を使って暗号化されます。

ポリシーのハッシュ

Configuration Manager クライアントがポリシーを要求する場合、まずポリシー割り当てを受け取るので、自身に適用されるポリシーを認識できます。次に、そのポリシーの本文のみを要求します。 各ポリシー割り当てには、対応するポリシー本文用の算出されたハッシュが含まれます。 クライアントは適切なポリシー本文を取得してから、その本文上でハッシュを計算します。 ダウンロードしたポリシー本文のハッシュがポリシー割り当てのハッシュと一致しない場合、クライアントはポリシー本文を廃棄します。

ポリシー用のハッシュ アルゴリズムは SHA-1 と SHA-256 です。

コンテンツのハッシュ

サイト サーバー上の配布マネージャー サービスは、すべてのパッケージのコンテンツ ファイルをハッシュします。 ポリシー プロバイダーには、ソフトウェア配布ポリシーのハッシュが含まれます。Configuration Manager クライアントがコンテンツをダウンロードすると、クライアントはローカルでハッシュを再生成し、ポリシー内のハッシュと比較します。 ハッシュが一致した場合は、コンテンツが改変されていないので、クライアントはコンテンツをインストールします。 コンテンツが 1 バイトでも改変されていると、ハッシュが一致しなくなるため、ソフトウェアはインストールされません。 このチェック機能により、実際のコンテンツがポリシーでクロスチェックされるため、正しいソフトウェアを確実にインストールすることができます。

コンテンツの既定のハッシュ アルゴリズムは SHA-256 です。 この既定値を変更する場合は、Configuration Manager ソフトウェア開発キット (SDK) のドキュメントを参照してください。

コンテンツのハッシュをサポートしないデバイスもあります。 この例外には、次が含まれます。

• App-V コンテンツをストリーミングするときの Windows クライアント。

• Windows Phone クライアント:ただし、これらのクライアントは、信頼できるソースで署名されたアプリケーションの署名を検証します。

• Windows RT クライアント:ただし、これらのクライアントは、信頼できるソースで署名されたアプリケーションの署名を検証し、パッケージの完全名 (PFN) の検証も使用します。

• iOS:ただし、これらのクライアントは、信頼できるソースの任意の開発者証明書で署名されたアプリケーションの署名を検証します。

• Nokia クライアント:ただし、これらのクライアントは、自己署名証明書を使用するアプリケーションの署名を検証します。 または、信頼できるソースの証明書の署名と証明書によって、Nokia Symbian Installation Source (SIS) アプリケーションに署名することができます。

• Android。 さらに、これらのデバイスは、アプリケーションのインストールに署名の検証を使用しません。

• SHA-256 をサポートしていない Linux および UNIX のバージョンで実行されるクライアント。 詳細については、「Linux および UNIX のオペレーティング システムを操作を行いますしないサポート sha-256」トピックの「Linux および UNIX サーバー用のクライアント展開の計画」セクションを参照してください。

インベントリの署名と暗号化

クライアントが管理ポイントに送信するインベントリは、管理ポイントとの通信に HTTP または HTTPS のどちらが使用されていても、デバイスによって必ず署名されます。 HTTP が使用される場合は、このデータを暗号化することを選択できます。これは、推奨されるセキュリティのベスト プラクティスです。

状態移行の暗号化

オペレーティング システム展開用の状態移行ポイントに保存されているデータは、必ずユーザー状態移行ツール (USMT) で 3DES を使用して暗号化されます。

オペレーティング システムを展開するマルチキャスト パッケージの暗号化

マルチキャストを使用してパッケージをコンピューターに送信する場合、すべてのオペレーティング システムの展開パッケージに対して、暗号化を有効にすることができます。 この暗号化では Advanced Encryption Standard (AES) が使用されます。 暗号化を有効にする場合は、証明書を追加で構成する必要はありません。 マルチキャスト対応の配布ポイントは、パッケージの暗号化のために自動的に対称キーを生成します。 各パッケージには、異なる暗号化キーがあります。 キーは、標準的な Windows API を使用して、マルチキャスト対応の配布ポイントに格納されます。 クライアントがマルチキャスト セッションに接続するとき、PKI 発行のクライアント認証証明書 (クライアントが HTTPS を使用する場合) または自己署名入り証明書 (クライアントが HTTP を使用する場合) で暗号化されたチャネルを通じてキーの交換が実行されます。 クライアントは、マルチキャスト セッション中の場合のみメモリにキーを格納します。

オペレーティング システムを展開するメディアの暗号化

メディアを使用してオペレーティング システムを展開し、メディアを保護するためにパスワードを指定する場合、環境変数は Advanced Encryption Standard (AES) を使用して暗号化されます。 メディア上のその他のデータ (パッケージおよびアプリケーションのコンテンツを含む) は暗号化されません。

クラウドベースの配布ポイントでホストされているコンテンツの暗号化

System Center 2012 Configuration Manager SP1 以降では、クラウドベースの配布ポイントを使用する場合、その配布ポイントにアップロードしたコンテンツは、Advanced Encryption Standard (AES) を使用して 256 ビットのキー サイズで暗号化されます。 コンテンツは、更新するたびに再暗号化されます。 クライアントがコンテンツをダウンロードすると、暗号化され、HTTPS 接続で保護されます。

ソフトウェア更新プログラムの署名

どのソフトウェア更新プログラムにも、改変を防ぐために、発行元による署名が必要です。 クライアント コンピューターでは、Windows Update エージェント (WUA) がカタログにある更新プログラムをスキャンしますが、ローカル コンピューターの [信頼された発行元] ストアにデジタル証明書が見つからない場合は、更新プログラムはインストールされません。 更新カタログ (WSUS Publishers Self-signed など) の発行時に自己署名入り証明書が使用された場合、証明書の有効性を検証するために、ローカル コンピューターの [信頼されたルート証明機関] 証明書ストアに証明書がある必要があります。 また、WUA では、ローカル コンピューターで [イントラネットの Microsoft 更新サービスの場所からの署名済みコンテンツを許可する] グループ ポリシー設定が有効になっているかどうかも確認されます。 Updates Publisher で作成および発行された更新プログラムをスキャンするには、WUA でこのポリシー設定が有効になっている必要があります。

ソフトウェア更新プログラムが System Center Updates Publisher で発行されると、アップデート サーバーに発行されるときに、デジタル証明書によってソフトウェア更新プログラムに署名されます。 ソフトウェア更新プログラムに署名するには、PKI 証明書を指定するか、Updates Publisher によって自己署名入り証明書が生成されるように構成します。

コンプライアンス設定のための署名入り構成データ

Configuration Manager では、構成データをインポートするときに、ファイルのデジタル署名を検証します。 ファイルが署名されていない場合、またはデジタル署名の検証チェックが失敗した場合は、警告およびインポートを続行するかどうかを尋ねるメッセージが表示されます。 発行元とファイルの整合性が信頼できる場合にのみ、構成データのインポートを続行します。

クライアント通知の暗号化とハッシュ

クライアント通知を使用する場合、すべての通信は、サーバーとクライアントのオペレーティング システムがネゴシエートできる TLS および最高レベルの暗号化を使用します。 たとえば、Windows 7 を実行するクライアント コンピューターと、Windows Server 2008 R2 を実行する管理ポイントは、128 ビット AES 暗号化をサポートできます。一方、Vista を実行するクライアント コンピューターは同じ管理ポイントに対して、3DES 暗号化まで下げてネゴシエートします。 SHA-1 または SHA-2 を使用してクライアント通知中に転送されるパケットをハッシュする場合、同じネゴシエーションが発生します。

Configuration Manager で使用される証明書

Configuration Manager で使用できる公開キー基盤 (PKI) 証明書の一覧、特別な要件または制限、および証明書の使用方法の詳細については、「Configuration Manager での PKI 証明書の要件」を参照してください。 この一覧には、サポートされるハッシュ アルゴリズムとキーの長さが含まれています。 ほとんどの証明書は、SHA-256 および 2048 ビットのキー長をサポートしています。

[!メモ]

Configuration Manager を使用するすべての証明書のサブジェクト名またはサブジェクトの別名には、1 バイト文字しか使用できません。

次の場合に、PKI 証明書が必要です。

• インターネット上で Configuration Manager クライアントを管理する場合。

• モバイル デバイスで Configuration Manager クライアントを管理する場合。

• Mac コンピューターを管理する場合

• クラウドベースの配布ポイントを使用する場合

• Intel AMT 搭載コンピューターを帯域外で管理する場合。

認証、署名、または暗号化に証明書を必要とするその他ほとんどの Configuration Manager 通信では、Configuration Manager は、使用可能な場合は自動的に PKI 証明書を使用します。 証明書を使用できない場合は、Configuration Manager により自己署名入り証明書が生成されます。

Exchange Server コネクタを使用してモバイル デバイスを管理する場合、Configuration Manager は PKI 証明書を使用しません。

モバイル デバイスの管理および PKI 証明書

モバイル デバイスが携帯電話会社によってロックされていない場合は、Configuration Manager または Microsoft Intune を使用してクライアント証明書を要求してインストールできます。 この証明書は、モバイル デバイス上のクライアントと Configuration Manager サイト システムまたは Microsoft Intune サービスとの間に相互認証を提供します。 モバイル デバイスがロックされている場合は、Configuration Manager または Intune を使用して証明書を展開することはできません。 詳細については、「Configuration Manager を使用して Windows Mobile および Nokia Symbian デバイスにクライアントをインストールする方法」をご覧ください。

モバイル デバイスのハードウェア インベントリを有効にすると、Configuration Manager または Intune ではモバイル デバイスにインストールされている証明書もインベントリされます。

帯域外管理および PKI 証明書

Intel AMT ベースのコンピューターでの帯域外管理では、少なくとも AMT プロビジョニング証明書と Web サーバー証明書という 2 種類の PKI 発行の証明書を使用します。

帯域外サービス ポイントは、AMT プロビジョニング証明書を使用して帯域外管理用のコンピューターを準備します。 プロビジョニングされる AMT ベースのコンピューターは、帯域外管理ポイントによって提示される証明書を信頼する必要があります。 既定では、コンピューターの製造元が AMT ベースのコンピューターを VeriSign、Go Daddy、Comodo、Starfield などの外部の証明機関 (CA) を使用するように構成します。 外部の CA からプロビジョニング証明書を購入し、このプロビジョニング証明書を使用するように Configuration Manager を構成した場合、AMT ベースのコンピューターがプロビジョニング証明書の CA を信頼するので、プロビジョニングを正常に実行できます。 ただし、推奨されるセキュリティ運用方法は、独自の内部 CA を使用して AMT プロビジョニング証明書を発行することです。 詳細については、「帯域外管理用のセキュリティのベスト プラクティス」をご覧ください。

AMT ベースのコンピューターは、Web サーバー コンポーネントをファームウェア内で実行します。また、この Web サーバー コンポーネントは、Transport Layer Security (TLS) を使用して、帯域外サービス ポイントとの通信チャネルを暗号化します。 証明書を手動で構成できる AMT BIOS のユーザー インターフェイスはありません。したがって、要求元の AMT ベースのコンピューターからの証明書要求を自動的に承認する Microsoft エンタープライズ証明機関を使用する必要があります。 要求では、要求の形式に PKCS#10 が使用され、次に AMT ベースのコンピューターに証明書情報を送信するために PKCS#7 が使用されます。

AMT ベースのコンピューターは、それを管理するコンピューターに対して認証されますが、管理しているコンピューターには、対応するクライアント PKI 証明書はありません。 その代わり、これらの通信では、Kerberos または HTTP Digest 認証が使用されます。 HTTP Digest が使用される場合、TLS を使用して暗号化されます。

帯域外の AMT ベースのコンピューターの管理には、802.1X 認証ワイヤード (有線) ネットワークおよびワイヤレス ネットワーク用のオプションのクライアント証明書のような、追加の種類の証明書が必要な場合があります。 RADIUS サーバーで認証するために、AMT ベースのコンピューターのクライアント証明書が必要な場合があります。 RADIUS サーバーが EAP-TLS 認証用に構成されている場合、クライアント証明書は常に必要です。 RADIUS サーバーが、EAP-TTLS/MSCHAPv2 または PEAPv0/EAP-MSCHAPv2 用に構成されている場合、クライアント証明書が必要かどうかはその RADIUS 構成によって指定されます。 この証明書は、Web サーバー証明書の要求と同じ処理を使用して、AMT ベースのコンピューターによって要求されます。

オペレーティング システムの展開と PKI 証明書

Configuration Manager を使用してオペレーティング システムを展開していて、管理ポイントが HTTPS を使用したクライアント接続を要求している場合、クライアント コンピューターには管理ポイントと通信するための証明書も必要となります。移行段階にある場合 (タスク シーケンス メディアや PXE 対応配布ポイントから起動中である場合など) でも同様です。 この場合は、PKI クライアント認証証明書を作成し、秘密キーを使用してエクスポートしてから、サイト サーバーのプロパティにインポートし、管理ポイントの信頼されたルート CA の証明書も追加する必要があります。

起動可能なメディアを作成する場合は、起動可能なメディアの作成時にクライアント認証証明書をインポートします。 タスク シーケンスで構成した秘密キーやその他の機密データを保護するには、起動可能なメディアにパスワードを構成します。 起動可能なメディアから起動されるすべてのコンピューターは、クライアント ポリシーの要求などのクライアント機能で必要な場合に、同じ証明書を管理ポイントに提示します。

PXE ブートを使用する場合は、PXE 対応の配布ポイントにクライアント認証証明書をインポートします。PXE 対応の配布ポイントは、PXE 対応の配布ポイントから起動を行うすべてのクライアントに同じ証明書を使用します。 推奨されるセキュリティのベスト プラクティスとして、タスク シーケンス内の秘密キーおよびその他の機密データを保護するためには、PXE サービスにコンピューターを接続するユーザーに、パスワードの入力を要求します。

これらのいずれかのクライアント認証証明書が改ざんされた場合、[管理] ワークスペースの [証明書] ノードおよび [セキュリティ] ノード内の証明書をブロックします。 これらの証明書を管理するには、[オペレーティング システム展開証明書の管理] 権限が必要です。

オペレーティング システムが展開され、Configuration Manager がインストールされた後は、クライアントが HTTPS クライアント通信を行うために独自の PKI クライアント認証証明書が必要になります。

ISV プロキシ ソリューションと PKI 証明書

Independent Software Vendor (ISV) では、Configuration Manager を拡張するアプリケーションを作成できます。 たとえば、ISV では、Windows 以外のクライアント プラットフォーム (Macintosh や UNIX コンピューターなど) をサポートする拡張アプリケーションを作成できます。 ただし、サイト システムに HTTPS クライアント接続が必要な場合、これらのクライアントは、サイトとの通信に PKI 証明書を使用する必要もあります。Configuration Manager には、ISV プロキシ クライアントと管理ポイントの間の通信を可能にする ISV プロキシに証明書を割り当てる機能が含まれています。 ISV プロキシ証明書を必要とする拡張アプリケーションを使用する場合は、その製品のマニュアルを参照してください。 ISV プロキシ証明書を作成する方法の詳細については、Configuration Manager Software Developer Kit (SDK) を参照してください。

ISV 証明書が改ざんされた場合は、[管理] ワークスペースの [証明書] ノードおよび [セキュリティ] ノード内の証明書をブロックします。

資産インテリジェンスと証明書

Configuration Manager は、Microsoft に接続するために資産インテリジェンス同期ポイントで使用される X.509 証明書と共にインストールされます。Configuration Manager は、この証明書を使用して、Microsoft 証明書サービスからクライアント認証証明書を要求します。 クライアント認証証明書は、資産インテリジェンス同期ポイント サイト システム サーバーにインストールされます。これは、Microsoft に対してサーバーを認証するときに使用されます。 Configuration Manager は、クライアント認証証明書を使用して、資産インテリジェンス カタログをダウンロードし、ソフトウェア タイトルをアップロードします。

この証明書のキーの長さは 1024 ビットです。

クラウドベースの配布ポイントと証明書

System Center 2012 Configuration Manager SP1 以降では、クラウドベースの配布ポイントには、Microsoft Azure にアップロードする管理証明書 (自己署名または PKI) が必要です。 この管理証明書には、サーバー認証機能とキー長が 2,048 ビットの証明書が必要です。 さらに、各クラウドベースの配布ポイントでサービス証明書を構成する必要があります。このとき、自己署名証明書ではなく、サーバー認証機能があり、キー長が 2,048 ビット以上の証明書を構成する必要があります。

[!メモ]

自己署名管理証明書はテスト目的専用であり、運用ネットワークには使用できません。

クライアントがクラウドベースの配布ポイントを使用するには、クライアント PKI 証明書は必要ありません。クライアントは管理ポイントに対して、自己署名証明書またはクライアント PKI 証明書を使用して認証します。 次に、管理ポイントは Configuration Manager アクセス トークンをクライアントに発行し、クライアントはそのトークンをクラウドベースの配布ポイントに提示します。 トークンの有効期間は 8 時間です。

Microsoft Intune コネクタと証明書

Microsoft Intune でモバイル デバイスを登録すると、Microsoft Intune コネクタを作成して、Configuration Manager でこれらのモバイル デバイスを管理できます。 コネクタは PKI 証明書とクライアント認証機能を使用して Configuration Manager に対して Microsoft Intune を認証し、SSL を使用してすべての情報を転送します。 証明書のキーのサイズは 2,048 ビットであり、SHA-1 ハッシュ アルゴリズムを使用します。

コネクタをインストールするときに、サイドローディング キーの署名証明書を作成してサイト サーバーに保存し、Simple Certificate Enrollment Protocol (SCEP) チャレンジを暗号化するための暗号化証明書を作成して証明書登録ポイントに保存します。 これらの証明書のキーのサイズは 2048 ビットで、SHA-1 ハッシュ アルゴリズムを使用します。

Intune でモバイル デバイスを登録すると、PKI 証明書がモバイル デバイスにインストールされます。 この証明書にはクライアント認証機能があり、2,048 ビットのキー サイズを使用し、SHA-1 ハッシュ アルゴリズムを使用します。

このような PKI 証明書は、Microsoft Intune によって要求、生成、およびインストールが自動的に行われます。

PKI 証明書の CRL チェック

PKI の証明書失効リスト (CRL) を使用すると、管理や処理のオーバーヘッドが増加しますが、安全性が高まります。 ただし、CRL チェックが有効にされていて、CRL にアクセスできない場合、PKI 接続は失敗します。 詳細については、「PKI 証明書失効の計画」トピックの「Planning for Security in Configuration Manager (Configuration Manager でのセキュリティ計画)」セクションを参照してください。

IIS では、証明書失効リスト (CRL) が既定で有効になっています。このため、PKI の展開で CRL を使用している場合、IIS を実行するほとんどの Configuration Manager サイト システムでは追加で構成する項目はありません。 ただし、ソフトウェア更新プログラムは例外です。ソフトウェア更新プログラム ファイルの署名を検証するには、手動で CRL チェックを有効にする必要があります。

クライアント コンピューターで HTTPS クライアント接続を使用する場合、CRL チェックは既定で有効にされます。 帯域外管理コンソールを実行して AMT ベースのコンピューターに接続する場合、CRL チェックは既定で有効になりませんが、このオプションを有効にすることができます。Configuration Manager SP1 以降では、Mac コンピューターのクライアントで CRL チェックを無効にすることはできません。

CRL チェックは、Configuration Manager の次の接続ではサポートされません。

• サーバー間の接続。

• Configuration Manager が登録したモバイル デバイス。

• Microsoft Intune が登録したモバイル デバイス。

サーバー通信の暗号化制御

Configuration Manager は、サーバー通信のために次の暗号化制御を使用します。

サイト内でのサーバーの通信

各サイト システム サーバーは、同じ Configuration Manager サイト内の他のサイト システムにデータを転送するために証明書を使用します。 一部のサイト システムの役割は、認証に証明書も使用します。 たとえば、あるサーバーに登録プロキシ ポイントを、別のサーバーに登録ポイントをインストールした場合、この識別証明書を使用することにより相互に認証することができます。Configuration Manager がこの通信に証明書を使用するときに、サーバー認証機能がある PKI 証明書を使用できる場合、Configuration Manager はその証明書を自動的に使用します。使用できない場合、Configuration Manager は自己署名証明書を生成します。 この自己署名証明書にはサーバー認証機能があり、SHA-256 を使用します。また、キーの長さは 2048 ビットです。Configuration Manager は、他のサイト システム サーバー上の信頼されたユーザー ストアに証明書をコピーします。このサーバーは、サイト システムを信頼する必要がある場合があります。 サイト システムは、これらの証明書と PeerTrust を使用することにより、相互に信頼することができます。

各サイト システム サーバーのこの証明書に加えて、Configuration Manager は、ほとんどのサイト システムの役割に対して、自己署名入り証明書を生成します。 同じサイトに複数のサイト システムの役割のインスタンスがある場合、それらは同じ証明書を共有します。 たとえば、同じサイトに複数の管理ポイントまたは複数の登録ポイントがある場合があります。 この自己署名入り証明書も、SHA-256 を使用し、キーの長さは 2048 ビットです。 これは、それを信頼する必要があるサイト システム サーバー上の信頼されたユーザー ストアにもコピーされます。 次のサイト システムの役割はこの証明書を生成します。

• アプリケーション カタログ Web サービス ポイント

• アプリケーション カタログ Web サイト ポイント

• 資産インテリジェンス同期ポイント

• 証明書登録ポイント

• Endpoint Protection ポイント

• 登録ポイント

• フォールバック ステータス ポイント

• 管理ポイント

• マルチキャスト対応の配布ポイント

• 帯域外サービス ポイント

• レポート サービス ポイント

• ソフトウェアの更新ポイント

• 状態移行ポイント

• システム正常性検証ツール ポイント

• Microsoft Intune コネクタ

これらの証明書は、Configuration Manager によって自動的に管理され、必要に応じて自動的に生成されます。

また、Configuration Manager は配布ポイントから管理ポイントにステータス メッセージを送信するために、クライアント認証証明書も使用します。 管理ポイントが HTTPS クライアント接続用のみに構成されている場合は、PKI 証明書を使用する必要があります。 管理ポイントが HTTP 接続を受け入れる場合は、PKI 証明書を使用するか、自己署名入り証明書 (クライアント認証機能があり、SHA-256 を使用し、キーの長さが 2048 ビット) を使用するオプションを選択できます。

サイト間のサーバー通信

Configuration Manager は、データベースのレプリケーションとファイルベースのレプリケーションを使ってサイト間でデータを転送します。 詳細については、「Configuration Manager のサイト通信のテクニカル リファレンス」をご覧ください。

Configuration Manager は、サイト間のデータベース レプリケーションを自動的に構成し、サーバー認証機能を持つ PKI 証明書を使用します (利用できる場合)。利用できない場合、Configuration Manager はサーバー認証のために自己署名入り証明書を作成します。 どちらの場合も、PeerTrust を使用する信頼されたユーザー ストアの証明書を使用して、サイト間の認証が行なわれます。 この証明書ストアは、Configuration Manager 階層で使用される SQL Server コンピューターのみがサイト間レプリケーションに加わるようにするために使用します。 プライマリ サイトと中央管理サイトは、構成の変更を階層内のすべてのサイトにレプリケートできますが、セカンダリ サイトは、親サイトにのみ構成の変更をレプリケートできます。

サイト サーバーは、自動的に行われるセキュリティ キーの交換を使用して、サイト間通信を確立します。 送信側のサイト サーバーは、ハッシュを生成し、秘密キーで署名します。 受信側のサイト サーバーは公開キーを使用して署名を確認し、受信したハッシュをローカルで生成された値と比較します。 値が一致した場合、受信側のサイトはレプリケートされたデータを受け入れます。 値が一致しない場合、Configuration Manager はレプリケーション データを拒否します。

Configuration Manager のデータベース レプリケーションは、SQL Server Service Broker を使用し、次のメカニズムを使用して、サイト間でデータを転送します。

• SQL Server 間の接続:これは、サーバー認証および自己署名入り証明書 (1024 ビット) に Windows 資格情報を使用し、Advanced Encryption Standard (AES) を使用してデータに署名および暗号化します。 サーバー認証機能を持つ PKI 証明書を利用できる場合は、それらが使用されます。 証明書は、コンピューター証明書ストアの個人用ストアに保存されている必要があります。

• SQL サービス ブローカー:これは、認証に 2048 ビットの自己署名入り証明書を使用し、Advanced Encryption Standard (AES) を使用してデータに署名および暗号化します。 この証明書は、SQL Server マスター データベースに保存されている必要があります。

ファイル ベースのレプリケーションは、サーバー メッセージ ブロック (SMB) プロトコルを使用しており、SHA-256 を使用してこのデータ (暗号化されていないが、機密データが含まれていない) に署名します。 このデータを暗号化する場合は、IPsec を使用できますが、Configuration Manager とは別にそれを実装する必要があります。

サイト システムに対して HTTPS 通信を使用するクライアントの暗号化制御

サイト システムの役割がクライアント接続を受け入れる場合は、HTTPS 接続および HTTP 接続を受け入れるように、または HTTPS 接続のみを受け入れるように構成できます。 インターネットからの接続を受け入れるサイト システムの役割は、HTTPS を使用したクライアント接続のみを受け入れます。

HTTPS 経由のクライアント接続では、クライアント/サーバー間の通信を保護するための公開キー基盤 (PKI) と統合することにより高いレベルのセキュリティが実現されています。 ただし、PKI の計画、展開、および操作をよく理解せずに HTTPS クライアント接続を構成すると、脆弱性が改善されないことがあります。 たとえば、ルート CA を保護していない場合は、攻撃者によって PKI 基盤全体の信頼性が侵害される恐れがあります。 管理されて保護された処理を使用して PKI 証明書を展開および管理できない場合、クライアントが管理されていないクライアントとなり、重要なソフトウェア更新プログラムまたはパッケージを受け取ることができないことがあります。

重要
クライアント通信に使用される PKI 証明書は、クライアントといくつかのサイト システム間の通信のみを保護します。 PKI 証明書は、サイト サーバーとサイト システムの間や、サイト サーバー間の通信チャネルを保護しません。

クライアントが HTTPS 通信を使用する場合に暗号化されない通信

クライアントが HTTPS を使用してサイト システムと通信する場合、通常、通信は SSL を使用して暗号化されます。 ただし、次のような状況では、クライアントは暗号化を使用せずにサイト システムと通信します。

• クライアントがイントラネット上での HTTPS 接続に失敗し、代替で HTTP を使用する (サイト システムがこの構成を許可する場合)。

• 次のサイト システムの役割への通信:

  • クライアントが状態メッセージをフォールバック ステータス ポイントに送信する。

  • クライアントが PXE 要求を PXE 対応配布ポイントに送信する。

  • クライアントが通知データを管理ポイントに送信する

レポート サービス ポイントは、クライアントの通信モードに関係なく、HTTP または HTTPS を使用するように構成されています。

サイト システムに対して HTTP 通信を使用するクライアントの暗号化制御

クライアントがサイト システムの役割に対して HTTP 通信を使用する場合、クライアント認証に PKI 証明書、または Configuration Manager が生成した自己署名入り証明書を使用できます。Configuration Manager が生成した自己署名入り証明書には、署名と暗号化用のカスタム オブジェクト識別子が付いており、この証明書によってクライアントが識別されます。 Windows Server 2003 を除き、サポートされているすべてのオペレーティング システムの自己署名入り証明書で SHA-256 アルゴリズムが使用され、キーの長さは 2048 ビットです。 Windows Server 2003 では、SHA1 アルゴリズムが使用され、キーの長さは 1024 ビットです。

オペレーティング システムの展開と自己署名入り証明書

Configuration Manager を使用し、自己署名入り証明書を使用してオペレーティング システムを展開している場合、クライアント コンピューターには管理ポイントと通信するための証明書も必要となります。コンピューターが移行段階にある場合 (タスク シーケンス メディアや PXE 対応配布ポイントから起動中である場合など) でも同様です。 このために、Configuration Manager は、署名と暗号化用のカスタム オブジェクト識別子の付いた自己署名入り証明書を生成し、この証明書によってクライアントが識別されるようにします。 Windows Server 2003 を除き、サポートされているすべてのオペレーティング システムの自己署名入り証明書で SHA-256 アルゴリズムが使用され、キーの長さは 2048 ビットです。 Windows Server 2003 では、SHA1 アルゴリズムが使用され、キーの長さは 1024 ビットです。 自己署名証明書が改ざんされた場合は、攻撃者がこれを使用して信頼されたクライアントになりすますことを防ぐため、[管理] ワークスペースの [証明書] ノードおよび [セキュリティ] ノードで証明書をブロックします。

クライアントおよびサーバーの認証

クライアントが HTTP を使用して接続する場合は、管理ポイントでの認証に Active Directory ドメイン サービスまたは Configuration Manager の信頼されたルート キーを使用します。 状態移行ポイントやソフトウェアの更新ポイントなどのその他のサイト システムの役割では、クライアントの認証は行なわれません。

管理ポイントが最初に自己署名入りクライアント証明書を使用してクライアントを認証する場合、すべてのコンピューターは自己署名入り証明書を生成できるため、このメカニズムでのセキュリティは最低限のものとなります。 この場合は、クライアントを承認することによって、識別プロセスを強化する必要があります。 信頼されたコンピューターのみを、Configuration Manager によって自動的に承認するか、管理ユーザーによって手動で承認する必要があります。 詳細については、「クライアントによって開始される通信」の承認のセクションを参照してください。

SSL の脆弱性について

Microsoft では、Configuration Manager サーバーのセキュリティを向上させるため、SSL 3.0 の無効化、TLS 1.1 と 1.2 の有効化、TLS 関連の暗号スイートの並べ替えを実行することを推奨しています。このサポート技術情報の記事では、これらの操作方法について説明しています。 この操作は、Configuration Manager の機能には影響しません。

参照

Configuration Manager のサイト管理のテクニカル リファレンス