CA 階層の設計

では AWS Private CA、最大 5 つのレベルの認証機関の階層を作成できます。階層ツリーの最上位にあるルート CA は、任意の数のブランチを持つことができます。ルート CA は、各ブランチCAsに最大 4 つのレベルの下位を持つことができます。また、それぞれ独自のルートを持つ複数の階層を作成することもできます。

適切に設計された CA 階層には、次のような利点があります。

• 各 CA に適したきめ細かなセキュリティ制御

• ロードバランシングとセキュリティを向上するための管理タスクの分割

• の日常的な運用における限定的CAsで取り消し可能な信頼の使用

• 有効期間と証明書パスの制限

次の図は、単純な 3 レベルの CA 階層を示しています。

ツリー内の各 CA は、署名権限 ( アイコンでシンボル化) を持つ X.509 v3 証明書によって pen-and-paperバックアップされます。つまり、 としてCAs、自分の下位にある他の証明書に署名できます。CA が下位レベルの CA の証明書に署名すると、署名付き証明書に対する制限付きの取り消し可能な権限が付与されます。レベル 1 のルート CA は、レベル 2 の高レベル下位 CA 証明書に署名します。これらの はCAs、エンドエンティティ証明書を管理する PKI (パブリックキーインフラストラクチャ) 管理者によって使用されるレベル 3 CAsの の証明書に署名します。

CA 階層内のセキュリティは、ツリーの最上部で最強になるように構成する必要があります。この構成により、ルート CA 証明書とそのプライベートキーが保護されます。ルート CA は、下位のすべての証明書CAsと下位のエンドエンティティ証明書の信頼をアンカーします。エンドエンティティ証明書の侵害によってローカライズされた損害が発生する可能性がありますが、ルートの侵害は 全体の信頼を破壊しますPKI。ルートと高レベルの下位CAsは、まれにしか使用されません (通常は他の CA 証明書に署名するため）。その結果、リスクの低減を保証するために、厳密に管理および監査されます。階層の下位レベルでは、セキュリティは制限が少なくなります。このアプローチにより、ユーザー、コンピュータホスト、ソフトウェアサービスのエンドエンティティ証明書の発行と失効という日常的な管理タスクが可能になります。

注記

ルート CA を使用して下位証明書に署名することは、ごく少数の状況で発生するまれなイベントです。

• PKI の作成時

• 高レベルの認証機関を置き換える必要がある場合

• 証明書失効リスト (CRL) またはオンライン証明書ステータスプロトコル (OCSP) レスポンダーを設定する必要がある場合

ルートやその他の高レベルには、安全性の高い運用プロセスとアクセスコントロールプロトコルCAsが必要です。

エンドエンティティ証明書を検証する

エンドエンティティ証明書は、下位をルート CA CAs に引き継ぐ認証パスから信頼を得ます。ウェブブラウザまたは他のクライアントにエンドエンティティ証明書が提示されると、信頼チェーンを構築しようとします。たとえば、証明書の発行者識別名とサブジェクト識別名が、発行元 の CA 証明書の対応するフィールドと一致しているかどうかを確認する場合があります。一致は、クライアントが信頼ストアに含まれている信頼されたルートに到達するまで、階層の連続した各レベルで継続されます。

信頼ストアは、ブラウザまたはオペレーティングシステムに含まれる信頼CAsされた のライブラリです。プライベート の場合PKI、組織の IT は、各ブラウザまたはシステムが以前にプライベートルート CA を信頼ストアに追加していることを確認する必要があります。それ以外の場合、証明書パスを検証できず、クライアントエラーが発生します。

次の図は、エンドエンティティ X.509 証明書が提示されたときにブラウザが従う検証パスを示しています。エンドエンティティ証明書には署名権限がなく、それを所有するエンティティの認証にのみ機能することに注意してください。

ブラウザは、エンドエンティティ証明書を検査します。ブラウザは、証明書が信頼認証情報として下位 CA (レベル 3) からの署名を提供していることを検出します。下位の証明書は、同じPEMファイルに含めるCAs必要があります。または、信頼チェーンを構成する証明書を含む別のファイルに保存することもできます。これらを見つけると、ブラウザは下位 CA (レベル 3 ) の証明書を確認し、下位 CA（レベル 2）からの署名を提供していることが検出されます。次に、下位 CA (レベル 2 ) は、ルート CA (レベル 1) からの署名を信頼認証情報として提供しています。ブラウザが信頼ストアに事前インストールされているプライベートルート CA 証明書のコピーを検出すると、エンドエンティティ証明書が信頼済みとして検証されます。

通常、ブラウザは各証明書を証明書失効リスト () と照合しますCRL。期限切れ、失効、誤って設定された証明書は拒否され、検証は失敗します。

CA 階層の構造を計画する

一般に、CA 階層は組織の構造を反映する必要があります。管理およびセキュリティの役割を委任するのに必要最低限のパスの長さ (つまり、CA レベルの数) を設定します。CA を階層に追加すると、証明書パス内の証明書の数が増え、検証時間が長くなります。パスの長さを最小限に抑えることで、エンドエンティティ証明書の検証時にサーバーからクライアントに送信される証明書の数も減ります。

理論的には、 pathLenConstraint パラメータを持たないルート CA は、無制限レベルの下位 を承認できますCAs。下位 CA には、内部設定で許可される数の子下位を持つことができます。 AWS Private CA マネージド階層CAsは、最大 5 つのレベルの深さの CA 認証パスをサポートします。

適切に設計された CA 構造には、いくつかの利点があります。

• 組織単位ごとに個別の管理コントロール

• 部下にアクセスを委任する機能 CAs

• セキュリティコントロールCAsを追加して上位レベルを保護する階層構造

これを実現するのは、次の 2 つの共通の CA 構造です。

• 2 つの CA レベル: ルート CA と下位 CA

  これは、ルート CA と下位 CA に対して個別の管理、制御、セキュリティポリシーを許可する、最も単純な CA 構造です。ルート CA に対する制限の厳しい制御とポリシーを維持しながら、下位 CA に対するより許可されたアクセスを許可できます。後者は、エンドエンティティ証明書の一括発行に使用されます。

• 3 つの CA レベル: ルート CA と 2 つの下位 CA のレイヤー

  上記と同様に、この構造はさらに CA レイヤーを追加し、ルート CA を低レベル CA のオペレーションから分離します。中間 CA レイヤーは、エンドエンティティ証明書の発行CAsを実行する下位に署名する場合にのみ使用されます。

あまり一般的ではない CA 構造には、次のようなものがあります。

• 4 以上の CA レベル

  3 レベルの階層よりも一般的ではありませんが、4 以上のレベルを持つ CA 階層は可能であり、管理委任を許可するために必要になる場合があります。

• 1 つの CA レベル: ルート CA のみ

  この構造は、完全な信頼チェーンが必要ない場合に開発およびテストによく使用されます。生産に使用され、非定型です。さらに、ルート CA と、エンドエンティティ証明書を発行CAsする に対して個別のセキュリティポリシーを維持するというベストプラクティスに違反します。

  ただし、ルート CA から直接証明書を発行している場合は、 に移行できます AWS Private CA。これにより、OpenSSL やその他のソフトウェアで管理されるルート CA を使用するよりも、セキュリティと制御上の利点が得られます。

PKI メーカーのプライベートの例

この例では、ある架空のテクノロジー企業が、スマート電球とスマートトースターの 2 つのモノのインターネット (IoT) 製品を製造しています。本番稼働時には、各デバイスにはエンドエンティティ証明書が発行されるため、インターネット経由で製造元と安全に通信できます。また、 は、内部ウェブサイトや、財務およびビジネスオペレーションを実行するさまざまなセルフホスト型コンピュータサービスなど、コンピュータインフラストラクチャPKIも保護しています。

その結果、CA 階層は、ビジネスのこれらの管理面と運用面を密接にモデル化します。

この階層には、内部オペレーション用に 1 つ、および外部オペレーション用に 2 つ (製品ラインごとに 1 つのルート CA) の 3 つのルートが含まれます。また、内部オペレーション用の 2 つのレベルの CA と、外部オペレーション用の 3 つのレベルを持つ、複数の証明書のパスの長さについても説明します。

外部オペレーション側で分離されたルート CA レイヤーCAsと追加の下位 CA レイヤーを使用することは、ビジネスとセキュリティのニーズに対応する設計上の決定です。複数の CA ツリーを使用すると、 PKIは企業の再編成、売却、買収に対して将来も保護されます。変更が発生すると、ルート CA 階層全体が、セキュリティで保護されている分割とともに正常に移動できます。また、2 つのレベルの下位 CA では、ルートCAsはレベル 3 から高い分離度CAsを持ち、数千または数百万の製造品目の証明書に一括署名します。

内部では、企業のウェブと内部コンピュータの操作は、2 レベルの階層を完了します。これらのレベルにより、ウェブ管理者と運用エンジニアは、各自のワークドメインで証明書発行を個別に管理できます。を個別の機能ドメインPKIに分割することは、セキュリティのベストプラクティスであり、互いに影響する可能性のある侵害からそれぞれを保護します。ウェブ管理者は、社内のウェブブラウザで使用するためのエンドエンティティ証明書を発行し、社内のウェブサイトで通信を認証および暗号化します。運用エンジニアは、データセンターホストとコンピュータサービスを相互に認証するエンドエンティティ証明書を発行します。このシステムは、機密データを で暗号化することで、機密データの安全性を維持するのに役立ちますLAN。

認証パスの長さ制約を設定する

CA 階層の構造は、各証明書に含まれる基本制約拡張によって定義され、適用されます。拡張では、次の 2 つの制約が定義されています。

• cA — 証明書が CA を定義しているかどうか。この値が false (デフォルト) の場合、証明書はエンドエンティティ証明書です。

• pathLenConstraint – 有効な信頼チェーンに存在するCAsことができる下位下位下位の下位の最大数。エンドエンティティ証明書は CA 証明書ではないためカウントされません。

ルート CA 証明書には最大限の柔軟性が必要であり、パス長の制約は含まれません。これにより、ルートは任意の長さの証明書パスを定義できます。

注記

AWS Private CA は、認証パスを 5 つのレベルに制限します。

下位CAsのpathLenConstraint値は、階層配置の場所と必要な特徴に応じて、0 以上になります。例えば、3 つの を持つ階層ではCAs、ルート CA にパス制約が指定されていません。最初の下位 CA のパス長は 1 であるため、子 に署名できますCAs。これらの子はそれぞれCAs、必ず 0 pathLenConstraintの値である必要があります。つまり、エンドエンティティ証明書に署名することはできますが、追加の CA 証明書を発行することはできません。新しい を作成する権限を制限することは、重要なセキュリティコントロールCAsです。

次の図は、階層の下に、制限された権限のこの伝播を示しています。

この 4 レベルの階層では、ルートは拘束されません (いつものように)。ただし、最初の下位 CA のpathLenConstraint値は 2 であるため、子が 2 レベル以上深くなるCAsことが制限されます。したがって、有効な証明書パスの場合、制約値は次の 2 つのレベルでゼロに減少する必要があります。ウェブブラウザで、パス長が 4 を超えるこのブランチからのエンドエンティティ証明書が検出された場合、検証は失敗します。このような証明書は、誤って作成された CA、誤って設定された CA、または不正な発行が原因である可能性があります。

テンプレートを使用してパスの長さを管理する

AWS Private CA には、ルート、下位、およびエンドエンティティ証明書を発行するためのテンプレートが用意されています。これらのテンプレートは、パス長を含む基本的な制約値のベストプラクティスをカプセル化します。テンプレートには、次のものがあります。

• RootCACertificate/V1

• S ubordinateCACertificate_PathLen0/V1

• S ubordinateCACertificate_PathLen1/V1

• S ubordinateCACertificate_PathLen2/V1

• S ubordinateCACertificate_PathLen3/V1

• EndEntityCertificate/V1

発行元の CA 証明書のパス長以上のパス長を持つ CA を作成しようとすると、 IssueCertificate API はエラーを返します。

証明書テンプレートの詳細については、「 AWS Private CA 証明書テンプレートを使用する」を参照してください。

で CA 階層設定を自動化する AWS CloudFormation

CA 階層の設計を確定したら、 AWS CloudFormation テンプレートを使用してテストして本番環境に配置できます。このようなテンプレートの例については、「AWS CloudFormation ユーザーガイド」の「プライベート CA 階層の宣言」を参照してください。