AD CS を設計および実装する

内部 CA を最適な方法で設計することが重要です。 設計は、PKI 環境のセキュリティと運用面に大きな影響を与えます。

AD CS ベースの階層の設計

AD CS を実装する前に、まず、CA 階層を設計する必要があります。 設計の一部として、必要な CA 層の数と、各層での CA の目的を決定する必要があります。 複雑な環境、安全性の高い環境、分散環境である場合を除き、3 レベルよりも深い CA 階層を構築することはお勧めしません。 ほとんどの場合、CA 階層には 2 つのレベルがあり、ルート CA は最上位レベル、下位の発行元 CA は 2 番目のレベルにあります。 通常は、ルート CA を使用して CA 階層を構築します。 このような場合、証明書の発行と管理に下位 CA を利用している間は、ルート CA はオフラインのままになります。

さらに複雑な CA 設計には次のものがあります。

• ポリシー CA を含む CA 階層。 ポリシー CA は、ルート CA の直下にある下位 CA であり、CA 階層内の他の下位 CA の上位に存在します。 ポリシー CA を使用して、CA 証明書を下位 CA に発行します。 CA 証明書には、PKI をセキュリティで保護するために組織が実装するポリシーと手順、証明書の所有者の身元を検証するプロセス、証明書を管理する手順を適用するプロセスが反映されています。 ポリシー CA は、他の CA に対してのみ証明書を発行します。 これらの証明書を受信した CA では、ポリシー CA で定義されたポリシーを維持し、適用する必要があります。 組織での別々の部門、セクター、場所で異なる発行ポリシーおよび手順が必要になる場合以外は、ポリシー CA の使用は必須ではありません。 たとえば、組織は、内部で従業員に発行するすべての証明書に対して 1 つのポリシー CA を実装し、請負業者に発行されるすべての証明書に対して別のポリシー CA を実装することができます。
• クロス証明の信頼を含む CA 階層。 このシナリオでは、ある階層の CA が別の階層の CA に対してクロス証明された CA 証明書を発行すると、2 つの独立した CA 階層が相互運用されます。 このようにすると、異なる CA 階層間で相互の信頼関係が確立されます。

スタンドアロン CA とエンタープライズ CA

AD CS を使用する場合は、スタンドアロンとエンタープライズの 2 種類の CA をデプロイできます。 これらの CA の種類は階層に関するものではなく、機能や AD DS との統合に関するものです。 スタンドアロン CA は AD DS に依存しません。 エンタープライズ CA では、自動登録などの追加機能を提供するために AD DS を必要とします。 自動登録を使用すると、グループ ポリシーを通じて証明書の自動登録を有効にした後で、ドメイン ユーザーとドメインに参加しているデバイスを証明書に自動で登録できるようになります。

次の表では、スタンドアロン CA とエンタープライズ CA の最も重要な違いについて説明します。

エンタープライズ ルート CA は、AD DS 環境に単一の CA をデプロイするときの最も一般的な選択です。 下位 CA を含む 2 層階層を AD DS 環境にデプロイする場合は、ルート CA としてスタンドアロン ルート CA を使用することを検討する必要があります。 これにより、ドメイン ユーザーとドメインに参加しているデバイスの証明書を管理するプロセスに影響を与えることなく、オフラインにすることができます。

また、オペレーティング システムのインストールの種類も検討してください。 デスクトップ エクスペリエンスと Server Core の両方のインストール シナリオで AD CS をサポートしています。 Server Core は、可能性のある悪意のある外部からのハッカーの対象やオペレーティング システムのメンテナンスのオーバーヘッドを最小限に抑えるので、エンタープライズ環境での AD CS に最適な選択肢になっています。

また、そのコンピューターに任意の種類の CA をデプロイした後は、コンピューター名、ドメイン名、コンピューター ドメイン メンバーシップは変更できなくなることに留意してください。 そのため、デプロイの前にこれらの設定を構成することが重要です。

また、オフラインのスタンドアロン ルート CA のデプロイに固有の考慮事項もいくつかあります。

• ルート CA から下位証明書を発行する前に、すべてのクライアントで使用できる証明書失効リスト配布ポイント (CDP) と AIA の場所を少なくとも 1 つ指定していることを確認してください。 これは、既定で、スタンドアロン ルート CA 自体に CDP と AIA が存在するためです。 したがって、ルート CA をネットワークから切断すると、CDP と AIA の場所にアクセスできなくなるため、失効確認は失敗します。 これらの場所を定義する場合は、CRL と AIA の情報をその場所に手動でコピーする必要があります。
• ルート CA が公開する CRL の有効期間を、1 年間などの長期間に設定します。 したがって、新しい CRL を発行するために年に 1 度ルート CA を有効にしてから、クライアントから利用できる場所にこの CRL をコピーする必要があります。 この操作に失敗した場合、ルート CA の CRL の有効期限が切れると、すべての証明書の失効確認も失敗します。
• グループ ポリシーを使用して、すべてのサーバーおよびクライアント コンピューター上の信頼されたルート CA ストアに、ルート CA 証明書を発行します。 スタンドアロン CA はエンタープライズ CA とは異なり、自動的には実行できないため、手動で行う必要があります。 また、certutil コマンドライン ツールを使用して、ルート CA 証明書を AD DS に発行することもできます。

デモンストレーション

次のビデオは、以下の方法を示しています。

• エンタープライズ ルート CA の前提条件を構成する。
• エンタープライズ ルート CA をデプロイする。

このプロセスの主な手順は次のとおりです。

1. AD DS 環境を作成します。 単一ドメインの AD DS フォレストを作成します。
2. エンタープライズ ルート CA の前提条件を構成する。 必要なサーバーの役割とサーバーの役割サービスをインストールします。
3. エンタープライズ ルート CA をデプロイする。 エンタープライズ ルート CA の設定を構成します。