次の方法で共有

証明機関役割サービスとは

  • [アーティクル]

この記事では、Windows Server オペレーティング システムに展開された Active Directory 証明書サービスの、証明機関役割サービスについて説明します。

証明機関 (CA) はユーザー、コンピューター、および組織の ID を証明する役割を担います。 CA はエンティティを認証し、デジタル署名された証明書を発行することで、その ID を保証します。 CA は証明書の管理、取消、更新もできます。

証明機関には次のようなものがあります。

  • エンド ユーザーの ID を保証する組織。
  • 証明書の発行および管理のために組織によって使用されるサーバー。

Active Directory 証明書サービス (AD CS) の証明機関役割サービスをインストールすることで、CA として動作する Windows サーバーを構成することができます。

証明機関の種類について

Windows Server では、次の 4 種類の CA がサポートされます。

  • エンタープライズのルート CA。
  • エンタープライズの下位 CA。
  • スタンドアロンのルート CA。
  • スタンドアロンの下位 CA。

エンタープライズとスタンドアロンの証明機関

エンタープライズ CA は Active Directory ドメイン サービス (AD DS) に統合されています。 証明書および証明書失効リスト (CRL) を AD DS に発行します。 エンタープライズ CA は、ユーザー アカウントやセキュリティ グループのような AD DS に格納された情報を使用して、証明書要求の承認または拒否を行います。 エンタープライズ CA は証明書テンプレートを使用します。 証明書が発行されると、エンタープライズ CA は証明書テンプレートの情報を使用してその証明書の種類に適した属性を持つ証明書を生成します。

自動証明書承認および自動ユーザー証明書登録を有効にする場合は、エンタープライズ CA を使用して証明書を発行します。 これらの機能は CA インフラストラクチャが Active Directory に統合されている場合にのみ使用できます。 また、スマート カードのサインインを有効にする証明書はエンタープライズ CA しか発行できません。このプロセスでは、スマート カードの証明書が Active Directory のユーザー アカウントに自動的にマップされる必要があるためです。

スタンドアロン CA は AD DS を必要とせず、証明書テンプレートは使用しません。 スタンドアロン CA を使用する場合は、要求された証明書の種類に関するすべての情報を証明書要求に含める必要があります。 既定では、スタンドアロン CA に送信されるすべての証明書要求は、CA 管理者に承認されるまで保留中のキューに保持されます。 証明書が要求に応じて自動的に発行されるようにスタンドアロン CA を構成できますが、これは安全性が低く、要求が認証されないため、通常は推奨されません。

Microsoft 以外のディレクトリ サービスを使用する場合、または AD DS が使用できない場合に証明書を発行するには、スタンドアロン CA を使用する必要があります。 組織内でエンタープライズとスタンドアロンの両方の証明機関を使用することができます。

ルートおよび下位の証明機関

エンタープライズおよびスタンドアロンの CA をルート CA または下位 CA として構成することができます。 下位 CA はさらに中間 CA (ポリシー CA とも呼ばれる) または発行元 CA として構成することができます。

ルート CA は、すべての証明書チェーンの終端となる、証明書階層の最上位にある CA です。 ルート CA 証明書がクライアントに存在する場合、ルート CA は無条件で信頼されます。 エンタープライズとスタンドアロンのどちらの CA を使用する場合でも、ルート CA を指定する必要があります。

ルート CA は証明書階層で最上位の CA であるため、証明書の [サブジェクト] フィールドは [発行者] フィールドと同じ値を持ちます。 同様に、証明書チェーンは自己署名 CA に達すると終了するため、自己署名 CA はすべてルート CA です。 CA を信頼されたルート CA として指定するかどうかは、エンタープライズ レべルで、または IT 管理者個人がローカルで決定することができます。

ルート CA は証明機関信頼モデルの基礎として機能します。 サブジェクトの公開キーが、発行される証明書の [サブジェクト] フィールドに表示される ID 情報と一致することが保証されます。 異なる CA で異なる標準を使用してこの関係を検証することもできます。したがって、公開キーを検証するための機関を信頼する選択を行う前にルート信用機関のポリシーおよび手順を理解することが重要です。

ルート CA は階層内で最も重要な CA です。 ルート CA に問題があると、同じ階層内のすべての CA とそこから発行されるすべての証明書にも問題があると見なされます。 ルート CA をネットワークから遮断し、下位 CA を使用してその他の下位 CA およびエンド ユーザーに証明書を発行することで、ルート CA のセキュリティを最大化することができます。 切断されたルート CA は、オフライン ルート CA とも呼ばれます。

ルート CA ではない CA は下位と見なされます。 階層内の最初の下位 CA は、ルート CA からその CA 証明書を取得します。 この最初の下位 CA はこのキーを使用して他の下位 CA の整合性を確認する証明書を発行します。 このように上位にある下位 CA は中間 CA と呼ばれます。 中間 CA はルート CA より下位にありますが、1 つ以上の下位 CA に対しては上位証明機関として機能します。

中間 CA は通常、ポリシーを通じて区別される証明書のクラスを分離するために使用されるため。ポリシー CA と呼ばれることが多くあります。 たとえば、ポリシーによる区別には CA が提供する保証のレベルや異なるエンドエンティティの生成を区別する CA の地理的な位置が含まれます。 ポリシー CA はオンラインにもオフラインにもすることができます。

証明機関の秘密キー

秘密キーは CA の ID の一部であり、問題が発生しないように保護する必要があります。 多くの組織はハードウェア セキュリティ モジュール (HSM) を使用して CA の秘密キーを保護しています。 HSM を使用しない場合、秘密キーは CA のコンピューターに格納されます。

オフラインの CA は安全な場所に格納し、ネットワークには接続しないでください。 CA の発行では証明書を発行する際に秘密キーを使用するため、CA の使用中はこの秘密キーにアクセスできる (オンライン) ようにする必要があります。 CA とその CA の秘密キーは常に物理的に保護する必要があります。

ハードウェア セキュリティ モジュール

ハードウェア セキュリティ モジュール (HSM) を使用すると、CA および秘密キー基盤 (PKI) のセキュリティを強化できます。

HSM はオペレーティング システムとは別に管理される専用のハードウェア デバイスです。 HSM は、署名および暗号化の処理を高速化するための専用暗号化プロセッサだけでなく、CA キーのためのセキュリティで保護されたハードウェア ストアも提供します。 オペレーティング システムは CryptoAPI インターフェイスおよび HSM の機能を使用して、HSM を暗号化サービス プロバイダー (CSP) デバイスとして利用します。

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

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

次のステップ