次の方法で共有

Active Directory 証明書サービスを使用した PKI の設計に関する考慮事項

Active Directory 証明書サービスを使用して公開キー インフラストラクチャの展開を計画する際には、いくつかの点を考慮する必要があります。 ここでは、PKI 環境を正常にインストールして構成するために計画する必要がある内容を確認できます。

高レベルであなたは次の手順を実行する必要があります。

  • 組織に適した公開キー 基盤 (PKI) を計画します。
  • HSM ベンダーの指示に従ってハードウェア セキュリティ モジュール (HSM) をインストールして構成します (使用する場合)。
  • 既定のインストール設定を変更する場合は、適切な CAPolicy.infを作成します。
  • 暗号化オプションを選択する
  • CA 名を決定する
  • 有効期間の決定
  • CA データベースの選択
  • 機関情報アクセスと証明書失効リスト配布ポイントの設定

PKI の計画

組織が Active Directory 証明書サービス (AD CS) のインストールを最大限に活用できるようにするには、PKI の展開を適切に計画する必要があります。 CA をインストールする前に、必要な CA の数と構成を決定する必要があります。 たとえば、エンタープライズ ルート CA またはスタンドアロン ルート CA が必要ですか。 証明書の承認要求はどのように処理されますか? 証明書の失効はどのように管理しますか? 適切な PKI 設計の作成には時間がかかる場合がありますが、PKI を成功させるためには重要です。

HSM を使用する

HSM は、オペレーティング システムとは別に管理される専用のハードウェア デバイスです。 これらのモジュールは、署名と暗号化操作を高速化するための専用の暗号化プロセッサに加えて、CA キー用のセキュリティで保護されたハードウェア ストアを提供します。 オペレーティング システムは CryptoAPI インターフェイスを介して HSM を利用し、HSM は暗号化サービス プロバイダー (CSP) デバイスとして機能します。

通常、HSM は PCI アダプターですが、ネットワーク ベースのアプライアンス、シリアル デバイス、USB デバイスとしても使用できます。 1 つの組織で 2 つ以上の CA を実装する予定の場合は、1 つのネットワーク ベースの HSM をインストールし、複数の CA 間で共有できます。

HSM を使用して CA を設定するには、HSM に格納する必要があるキーを持つ CA を設定する前に、HSM をインストールして構成する必要があります。

CAPolicy.inf ファイルについて考えてみましょう

CAPolicy.inf ファイルは AD CS をインストールするために必要ありませんが、CA の設定をカスタマイズするために使用できます。 CAPolicy.inf ファイルには、CA のインストール時または CA 証明書の更新時に使用されるさまざまな設定が含まれています。 CAPolicy.inf ファイルを使用するには、%systemroot% ディレクトリ (通常はC:\Windows) に作成して格納する必要があります。

CAPolicy.inf ファイルに含める設定は、作成する展開の種類によって大きく異なります。 たとえば、ルート CA には、次のような CAPolicy.inf ファイルが含まれる場合があります。

[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
LoadDefaultTemplates=0

暗号化オプションを選択する

証明機関 (CA) の暗号化オプションを選択すると、その CA のセキュリティ、パフォーマンス、互換性に大きな影響を与える可能性があります。 既定の暗号化オプションは、ほとんどの CA に適している場合があります。 カスタム オプションを実装する機能は、暗号化をより高度に理解し、この柔軟性を必要とする管理者やアプリケーション開発者にとって役立ちます。 暗号化オプションは、暗号化サービス プロバイダー (CSP) またはキー ストレージ プロバイダー (KSP) を使用して実装できます。

CSP は、一般的な暗号化機能を提供する Windows オペレーティング システムのハードウェアおよびソフトウェア コンポーネントです。 CSP は、さまざまな暗号化アルゴリズムと署名アルゴリズムを提供するために記述できます。

プロバイダー、ハッシュ アルゴリズム、キーの長さを選択するときは、使用するアプリケーションとデバイスでサポートできる暗号化オプションを慎重に検討してください。 最も強力なセキュリティ オプションを選択することをお勧めしますが、すべてのアプリケーションとデバイスでこれらをサポートできるわけではありません。

CA によって秘密キーにアクセスされたときに管理者の操作を許可するオプションは、通常、ハードウェア セキュリティ モジュール (HSM) で使用されます。 このオプションを使用すると、CA の秘密キーにアクセスするときに、暗号化プロバイダーがユーザーに追加の認証を求められます。 たとえば、すべての暗号化操作の前にパスワードを入力するよう管理者に要求します。

組み込みの暗号化プロバイダーは、次の表に示すように、特定のキー長とハッシュ アルゴリズムをサポートします。

Cryptographic provider Key lengths Hash algorithm
Microsoft Base Cryptographic Provider v1.0 - 512
- 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
Microsoft Base DSS 暗号化プロバイダー - 512
- 1024		 SHA1
Microsoft ベース スマートカード クリプト プロバイダー - 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
Microsoft Enhanced Cryptographic Provider v1.0 - 512
- 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
マイクロソフト高強度暗号プロバイダ - 512
- 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
RSA#マイクロソフト ソフトウェア キー ストレージ プロバイダー - 512
- 1024
- 2048
- 4096		 - SHA1
- SHA256
- SHA384
- SHA512
- MD2
- MD4
- MD5
DSA#Microsoft ソフトウェア キー ストレージ プロバイダー - 512
- 1024
- 2048		 SHA1
ECDSA_P256#Microsoft ソフトウェア キー ストレージ プロバイダー 256 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P384#Microsoft ソフトウェア キー ストレージ プロバイダー 384 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P521#Microsoft ソフトウェア キー ストレージ プロバイダー 521 - SHA1
- SHA256
- SHA384
- SHA512
RSA#Microsoft スマート カード キー ストレージ プロバイダー - 1024
- 2048
- 4096		 - SHA1
- SHA256
- SHA384
- SHA512
- MD2
- MD4
- MD5
ECDSA_P256#Microsoft スマート カード キー ストレージ プロバイダー 256 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P384#Microsoft スマート カード キー ストレージ プロバイダー 384 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P521#Microsoft スマート カード キー ストレージ プロバイダー 521 - SHA1
- SHA256
- SHA384
- SHA512

CA 名を決定する

組織で証明機関 (CA) を構成する前に、CA の名前付け規則を確立する必要があります。

任意の Unicode 文字を使用して名前を作成できますが、相互運用性が重要な場合は ANSI 文字セットを使用できます。 たとえば、CA 名にアンダースコアなどの特殊文字が含まれている場合、特定の種類のルーターでは、ネットワーク デバイス登録サービスを使用して証明書を登録することはできません。

ラテン文字以外の文字 (キリル文字、アラビア文字、中国語など) を使用する場合は、CA 名に含める文字数が 64 文字未満である必要があります。 非ラテン文字のみを使用する場合、CA 名の長さは 37 文字以下です。

Active Directory Domain Services (AD DS) では、サーバーを CA として構成するときに指定する名前が CA の共通名になります。 共通名は、CA が発行するすべての証明書に反映されます。 このため、CA の共通名に完全修飾ドメイン名を使用しないようにすることが重要です。 これにより、証明書のコピーを取得した悪意のあるユーザーは、CA の完全修飾ドメイン名を識別して使用して潜在的なセキュリティの脆弱性を作成できません。

CA 名は、コンピューターの名前 (NetBIOS または DNS 名) と同じにしないでください。 また、ACTIVE Directory 証明書サービス (AD CS) がインストールされた後に、CA によって発行されたすべての証明書を無効にせずに、サーバーの名前を変更することはできません。

AD CS のインストール後にサーバー名を変更するには、CA をアンインストールし、サーバーの名前を変更し、同じキーを使用して CA を再インストールし、既存の CA キーとデータベースを使用するようにレジストリを変更する必要があります。 ドメイン名を変更する場合は、CA を再インストールする必要はありません。ただし、名前の変更をサポートするには CA を再構成する必要があります。

有効期間の決定

証明書ベースの暗号化では、公開キー暗号化を使用してデータを保護し、署名します。 時間の経過と共に、攻撃者は公開キーで保護されたデータを取得し、そこから秘密キーを派生させようとする可能性があります。 十分な時間とリソースがあると、この秘密キーが侵害され、事実上、保護されているすべてのデータが保護されていない状態になる可能性があります。 また、証明書によって保証される名前は、時間の経過と同時に変更する必要があります。 証明書は名前と公開キーの間のバインディングであるため、いずれかの変更時に証明書を更新する必要があります。

すべての証明書には有効期間があります。 有効期間が終了すると、証明書は許容される資格情報または使用可能な資格情報とは見なされなくなります。

CA は、独自の有効期間を超えて有効な証明書を発行できません。 有効期間の半分が期限切れになったら、CA 証明書を更新することをお勧めします。 CA をインストールするときは、この日付を計画し、将来のタスクとして記録されるようにする必要があります。

CA データベースの選択

証明機関のデータベースは、ハード ドライブ上のファイルです。 このファイルに加えて、他のファイルはトランザクション ログとして機能し、変更が行われる前にデータベースに対するすべての変更を受け取ります。 これらのファイルは頻繁に同時にアクセスされる可能性があるため、データベースログとトランザクションログを別々のボリュームに保持することをお勧めします。

証明書データベースとログ ファイルの場所は、次のレジストリの場所に保持されます。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

レジストリには、次の値が含まれています。

  • DBDirectory
  • DBLogDirectory
  • DBSystemDirectory
  • DBTempDirectory

機関情報アクセスと証明書失効リスト配布ポイントの設定

ルート CA または下位 CA がインストールされたら、CA が証明書を発行する前に、証明機関情報アクセス (AIA) および CRL 配布ポイント (CDP) 拡張機能を構成する必要があります。 AIA拡張機能は、CAのup-to日時証明書を検索する場所を指定します。 CDP 拡張機能は、CA に署名された up-to-date CRL を検索する場所を指定します。 これらの拡張機能は、その CA によって発行されるすべての証明書に適用されます。

これらの拡張機能を構成すると、CA が発行する各証明書にこの情報が確実に含まれるので、すべてのクライアントが使用できるようになります。 拡張機能を使用すると、未確認の証明書チェーンまたは証明書失効によるエラーが少なくなります。その結果、VPN 接続の失敗、スマート カードのサインインの失敗、未確認の電子メール署名が発生する可能性があります。

CA 管理者は、CRL 配布ポイントと CDP および AIA 証明書発行の場所を追加、削除、または変更できます。 CRL 配布ポイントの URL を変更すると、新しく発行された証明書にのみ影響します。 以前に発行された証明書は引き続き元の場所を参照するため、CA が証明書を配布する前にこれらの場所を確立する必要があります。

CDP 拡張 URL を構成する場合は、次のガイドラインを考慮してください。

  • オフライン ルート CA でのデルタ CRL の発行は避けてください。 オフライン ルート CA では多くの証明書を取り消さないため、デルタ CRL は必要ない可能性があります。
  • 証明機関の [プロパティ拡張機能] タブの [拡張機能] タブで、既定の LDAP:// と http:// URL の場所をニーズに応じて調整します。
  • 組織外のユーザーとアプリケーションが証明書の検証を実行できるように、HTTP インターネットまたはエクストラネットの場所に CRL を発行します。 CDP の場所の LDAP URL と HTTP URL を発行して、クライアントが HTTP と LDAP を使用して CRL データを取得できるようにします。
  • Windows クライアントは、有効な CRL が取得されるまで、常に URL の一覧を順番に取得します。
  • HTTP CDP の場所を使用して、Windows 以外のオペレーティング システムを実行しているクライアントにアクセス可能な CRL の場所を提供します。

Next steps

AD CS の展開の詳細については、「 Active Directory 証明書サービスの実装と管理」を参照してください。