次の方法で共有

Configuration Manager 暗号化コントロールの概要

  • [アーティクル]

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

ネットワーク上のデータを保護するため、データに署名して、転送中に改変された場合にそのデータが廃棄されるようにすることができます。また、データを暗号化して、攻撃者によるネットワーク モニタなどのネットワーク プロトコル アナライザを介したデータの読み取りを防止することもできます。Microsoft System Center Configuration Manager 2007 では署名と暗号化の両方が、混在モードとネイティブ モードの両方で使用されます。詳細については、次の各セクションを参照してください。

すべてのサイト モードでの暗号化コントロール

Configuration Manager 2007 の一部の情報は、サイト モードに関係なく署名したり暗号化したりすることができます。

コンテンツのハッシュ

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

ポリシーのハッシュ

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

必要な構成管理データへの署名

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

サイト間の署名と暗号化

サイト コントロール ファイルには、サイトおよび子サイトのすべての構成プロパティが含まれます。管理者が子サイトの構成を変更すると、サイト コントロール ファイルの変更内容が親サイトから子サイト サーバーに送信されます。子サイトの管理者が構成を変更すると、サイト コントロール ファイル内の変更内容が親サイトに送信されます。また、子サイトはインベントリやステータスなどのデータを親サイトに送信し、親サイトはパッケージやコレクションの定義などのデータを子サイトに送信します。

サイト間でデータを送信する前に、送信元のサイト サーバーはハッシュを生成し、秘密キーで署名します。受信側のサイト サーバーは公開キーを使用して署名を確認し、受信したハッシュをローカルで生成された値と比較します。値が一致した場合は、受信側のサイトはサイト コントロール ファイルを受け入れます。値が一致しない場合は、サイト コントロール ファイルは拒否されます。

関連した構成を使用すると、通信チャネルがセキュリティ保護されていない場合でも、Configuration Manager 2007 では自動的にサイト間の通信キーを親サイトまたは子サイトに配布できます。新規インストールを実行した場合は既定で [セキュリティ キーの交換を必要とする] が有効になりますが、更新している場合は現在の設定が保持されます。

[セキュリティ キーの交換を必要とする] を有効にすると、サイト間の通信公開キーは次の 2 つのいずれかの方法で交換されます。

  • Active Directory ドメイン サービスのスキーマが Configuration Manager 2007 用に拡張され、Configuration Manager 2007 が Active Directory に対する発行の権限を持っている場合は、サイト サーバーが自動的に、[System Management] コンテナ内のサイト オブジェクトに対するサイト間の通信公開キーを発行します。

  • Active Directory スキーマが有効でない場合、または Configuration Manager 2007 が Active Directory に対する発行の権限を持っていない場合は、Configuration Manager 2007 管理者が Preinst コマンドを使用して公開キーをダンプし、転送先のサイトにその公開キーを手動でコピーする必要があります。

    重要

    フォレスト間では、自動キー交換は機能しません。サイト階層がフォレストの境界をまたいでいる場合は、両方のフォレストに拡張されたスキーマがあり、Configuration Manager 2007 が Active Directory に発行している場合でも、管理者は手動でキーを交換する必要があります。

サイト コントロール ファイル内の一部の情報は暗号化されますが、サイト間で転送される場合はサイト コントロール ファイル自体は暗号化されません。サイト間通信用の暗号化を有効にするには、IPsec を使用する必要があります。詳細については、「Configuration Manager 2007 への IPsec の実装」を参照してください。

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

インベントリは、コンピュータではモードにかかわらず常に署名されますが、モバイル デバイスではネイティブ モードでしか署名されません。混在モードでは、暗号化は任意ですが、実行することをお勧めします。詳細については、「クライアント インベントリ レポートを暗号化する方法」を参照してください。

状態移行の暗号化

オペレーティング システムの展開用に状態移行ポイントに保存されたデータは、常に暗号化されます。

ソフトウェアの更新の署名

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

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

モバイル デバイス管理での証明

モバイル オペレータによってモバイル デバイスがロックされていない場合、Configuration Manager 2007 では、構成項目として証明書を送信したり、クライアント ソフトウェアとともに証明書をインストールしたりすることにより、モバイル アプリケーションの署名の検証に必要な証明書をインストールすることができます。モバイル デバイスがロックされている場合は、Configuration Manager 2007 を使用して証明書を展開することはできません。詳細については、「モバイル デバイス クライアントへの証明書の展開」を参照してください。

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

帯域外管理の証明書 (Configuration Manager 2007 SP1 以降)

帯域外管理では、少なくとも 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 を使用して暗号化されます。

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

詳細については、「帯域外管理の証明書について」を参照してください。

マルチキャスト パッケージの暗号化 (Configuration Manager 2007 R2)

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

ネイティブ モードでの暗号化コントロール

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

重要

ネイティブ モードでは、クライアントと一部のサイト システムの間の通信のみが保護されます。ネイティブ モードでは、サイト サーバーとサイト システムの間や、サイト サーバー間の通信チャネルの保護はまったく行われません。

ネイティブ モードの証明書

ネイティブ モードでは、次のようないくつかのタイプの証明書が必要になります。

IIS を必要とするサイト システムでは、SSL 上でのクライアントとの通信を暗号化するときに、Web サーバー証明書が必要になります。Web サーバー証明書が必要なサイト システムは次のとおりです。

  • 管理ポイント

  • プロキシ管理ポイント

  • 配布ポイント

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

  • 状態移行ポイント

すべてのクライアント (クライアント コンピュータおよびモバイル デバイス クライアントの両方) で、クライアント認証証明書が必要です。また、管理ポイントと状態移行ポイントに Configuration Manager 2007 クライアントがインストールされていない場合でも、これらのポイントにクライアント認証証明書を展開する必要があります。クライアントが既にクライアント認証証明書を持っている場合、Configuration Manager 2007 で既存の証明書を使用できる場合があります。

クライアントに送信されるポリシーに署名するには、サイト サーバーでカスタムのサイト サーバー署名証明書が必要になります。この証明書にはドキュメントの署名機能が備わっている必要があります。また、サブジェクト名として特定のテキスト文字列が含まれている必要があります。クライアントでポリシーの署名を検証するには、すべてのクライアントにサイト サーバー署名証明書のコピーがある必要があります。

詳細については、「ネイティブ モードの証明書要件」を参照してください。

Configuration Manager 2007 階層内のすべてのコンピュータで同じ証明機関の証明書を使用している場合は、1 つの信頼されたルート証明機関のみを展開する必要があります。ただし、同じ証明機関を使用するという要件は存在しないため、クライアントとサーバーに複数のルート CA をインストールすることが必要になる場合があります。Microsoft PKI ソリューションを使用していない場合は、サイト システムに中間 CA の証明書をインストールする必要もあります。

詳細については、「ネイティブ モードで必要な PKI 証明書の展開」を参照してください。

注意

すべての Configuration Manager 2007 証明書のサブジェクト名またはサブジェクトの別名には、1 バイト文字しか使用できません。詳細については、「ネイティブ モード証明書と 2 バイト文字セット」を参照してください。

インターネットベースのクライアント管理証明書

インターネットベースのクライアント管理では、ネイティブ モードとそのすべての証明書基盤が必要になります。また、サイトがインターネットベースのクライアント管理をサポートしており、SSL ターミネーション機能付きのプロキシ サーバーを使用 (ブリッジング) してインターネット接続を受信している場合は、プロキシ サーバー上でサーバー認証およびクライアント認証用に証明書を設定する必要があります。SSL ターミネーション機能がないプロキシ サーバーを使用 (トンネリング) している場合は、プロキシ サーバー上に追加の証明書は必要ありません。詳細については、「インターネット ベースのクライアント管理で使用するプロキシ Web サーバーの要件を確認する」を参照してください。

ネイティブ モードでのモバイル デバイス クライアント証明書

ネイティブ モードのサイトに割り当てられているモバイル デバイスがある場合、ネイティブ モードをサポートする証明書が必要になります。ネイティブ モードのモバイル デバイス クライアントには、サイト サーバー署名証明書のコピー、モバイル デバイスをサポートする管理ポイントと配布ポイントの Web サーバー証明書のコピー、および中間 CA とルート CA のコピーが必要です。モバイル デバイスでは、クライアント認証機能がある個人用ストアに証明書が必要です。詳細については、「モバイル デバイス クライアントのネイティブ モード証明書について」を参照してください。

コンピュータ認証用の証明書が必要なクライアント コンピュータと異なり、モバイル デバイスではネイティブ モードのサイト システムを認証するためのユーザー認証証明書が必要になります。

ネイティブ モードでのオペレーティング システム展開証明書

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

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

PXE ブートを使用する場合は、PXE サービス ポイントへのクライアント認証証明書をインポートします。このとき PXE サービス ポイントは、PXE サービス ポイントから起動を行うすべてのクライアントに同じ証明書を貸与します。タスク シーケンス内の秘密キーおよびその他の機密データを保護するためには、PXE サービス ポイントに接続するユーザーに、パスワードの入力を要求する必要があります。

これらのクライアント認証証明書のうち 1 つでも改ざんされた場合は、[証明書] ノード内のサイトのプロパティで証明書をブロックする必要があります。これらの証明書を管理するには、オペレーティング システム展開証明書の管理権限が必要です。

オペレーティング システムが展開され、Configuration Manager 2007 がインストールされた後は、クライアントがネイティブ モードの通信を行うのに独自の PKI クライアント認証証明書が必要になります (このことはこのセクションで既に説明しています)。

詳細については、「ネイティブ モード証明書とオペレーティング システムの展開の管理方法」を参照してください。

ネイティブ モードでの Configuration Manager のサポート

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

ISV 証明書が改ざんされた場合は、[証明書] ノードのサイトのプロパティで、証明書をブロックする必要があります。

ネイティブ モードでの暗号化されていない通信

ネイティブ モードでは、通信は通常、SSL で暗号化されています。ただし、次のような状況では、ネイティブ モードのクライアントは暗号化を使用せずにサイト システムと通信します。

  • [配布ポイントからプログラムを実行する] オプションで提供情報が設定されている。

  • クライアントが配布ポイントと HTTPS 接続を実行できない。

  • クライアントが次のサイト システムと通信している。

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

    • サーバー ロケータ ポイント

    • PXE サービス ポイント

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

  • ネイティブ モードでは、サーバー ロケータ ポイントと通信するため、クライアント コンピュータはローミングおよびサイト割り当ての HTTP 通信ができるように設定されています。

  • ネイティブ モードでも、サーバー メッセージ ブロック (SMB) プロトコルを常に使用する、ブランチ配布ポイント。

  • [クライアントがこの配布ポイントから、デバイス クライアントおよびインターネット ベース クライアントに必要な BITS、HTTP、および HTTPS を使用してコンテンツを転送できるようにする] が設定されていない配布ポイント。このオプションが設定されていないため、クライアントはネイティブ モードの場合でも常に SMB を使用します。

レポート ポイントは、サイト モードに関係なく HTTP または HTTPS を使用するように設定されています。

詳細については、「混在モードとネイティブ モードでのクライアント通信」を参照してください。

ネイティブ モードでの署名

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

CRL チェック

IIS では、証明書失効リスト (CRL) が既定で有効になっています。このため、PKI の展開で CRL を使用している場合、ほとんどの Configuration Manager サイト システムには追加される設定項目はありません。ただし、ソフトウェアの更新は例外で、ソフトウェア更新ファイルの署名を検証するには、手動の手順で CRL チェックを有効にする必要があります。詳細については、「ソフトウェアの更新の CRL チェックを有効にする方法」を参照してください。

CRL チェックは、サイトがネイティブ モードでインストールされている場合は、ネイティブ モードのクライアント コンピュータに対して既定で有効にされますが、サイトが混在モードでインストールされてからネイティブ モードに移行された場合は、既定で無効になります。CRL チェックを有効にすると、管理や処理のオーバーヘッドが増加しますが、安全性が高まります。ただし、CRL チェックを有効にしてもクライアントが CRL にアクセスできない場合は、クライアントはサイトと通信できません。詳細については、「クライアントで証明書失効確認 (CRL) を有効にするかどうかを判断する (ネイティブ モード)」を参照してください。

混在モードでの暗号化コントロール

混在モードでは、一部の証明書は引き続き使用されますが、自己署名されているため PKI 基盤は必要ありません。ほとんどの場合、自己署名された証明書に管理者が操作する必要はありません。

ポリシーの署名

クライアントが混在モードでポリシーを要求した場合は、返信されるポリシー割り当ては、管理ポイントの自己署名証明書によって署名されています。ネイティブ モードの方が安全である理由のひとつは、管理ポイントから PKI で発行された証明書に加え、証明書に署名するセントラル サイト サーバーによってポリシーが署名されていることです。混在モードでは、管理ポイントに進入する攻撃者が任意のポリシーを作成および署名できます。ポリシー割り当て上の署名をクライアントが検証できない場合は、クライアントはポリシー割り当てを廃棄します。

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

Configuration Manager 2007 を使用して混在モードでオペレーティング システムを展開している場合は、クライアント コンピュータに管理ポイントと通信するための証明書も必要です。コンピュータが移行段階にある場合（タスク シーケンス メディアや PXE サービス ポイントから起動中である場合など）でも同様です。混在モードではこのシナリオに対応するために、Configuration Manager 2007 は自己署名証明書を生成します。自己署名証明書が改ざんされた場合、[証明書] ノードのサイトのプロパティで証明書をブロックし、攻撃者が証明書を使用して信頼されたクライアントを装うことができないようにする必要があります。

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

混在モードでは、クライアントは Active Directory ドメイン サービスまたは Configuration Manager 2007 で信頼されたルート キーを使用して、管理ポイントを認証します。詳細については「信頼されたルート キーについて」を参照してください。クライアントは、状態移行ポイントやソフトウェア更新ポイントなど、サーバーが持つ他の役割は認証しません。混在モードのクライアントが自己署名証明書を生成し、管理ポイントがそれを使用してクライアントを認証します。管理ポイントで受け付けられる自己署名証明書はどのクライアントでも生成できるため、混在モードで提供されるセキュリティは最低限のものになります。しかし、機密情報を含むポリシーを受け取れるだけの信頼を得るのは、承認されたクライアントのみです。

Configuration Manager で使用される暗号化アルゴリズム

Configuration Manager 2007 で使用される主なハッシュ アルゴリズムは SHA-1 です。2 つの Configuration Manager 2007 サイトが相互に通信する場合、通信は SHA-2 を使用して署名されます。Configuration Manager 2007 で実装されている主な暗号化アルゴリズムは 3DES です。また、ネイティブ モードが実装されている場合は、PKI を構成して、「ネイティブ モードの証明書要件」で説明しているキーの最大長を使用した RSA 証明書を使用することもできます。大部分の暗号化操作では、Configuration Manager は Windows CryptoAPI ライブラリ rsaenh.dll の SHA-1、SHA-2、3DES、および RSA アルゴリズムを使用します。

注意

サイト階層に SMS 2003 サイトがある場合、Configuration Manager 2007 では MD5 ハッシュを使用して SMS 2003 子サイトとの通信に署名します。SMS 2003 (サービス パックなし) で作成したパッケージは、SMS 2003 (サービス パックあり) または Configuration Manager 2007 内で配布ポイントの更新ウィザードを使用して更新されるまで、MD5 でハッシュされます。更新後は SHA-1 でハッシュされます。

参照:

その他のリソース

Configuration Manager のセキュリティとプライバシーの概要

その他の情報については、「Configuration Manager 2007 Information and Support」 (Configuration Manager 2007 の情報とサポート) を参照してください。
ドキュメント チームに連絡するには、次のアドレスに電子メールを送信してください。 SMSdocs@microsoft.com.