

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS Private CA ベストプラクティス
<a name="ca-best-practices"></a>

ベストプラクティスは、 AWS Private CA を効果的に使用するのに役立つ推奨事項です。以下のベストプラクティスは、現在の AWS Certificate Manager と AWS Private CA お客様の実際の経験に基づいています。

## CA の構造とポリシーのドキュメント化
<a name="document-ca"></a>

AWS では、CA を運用するためのすべてのポリシーとプラクティスを文書化することをお勧めします。アプローチには以下が含まれます。
+ CA 構造に関する意思決定の推論
+ CA とその関係を示す図
+ CA の有効期間に関するポリシー
+ CA 承継の計画
+ パスの長さに関するポリシー
+ アクセス許可のカタログ
+ 管理制御構造の説明
+ セキュリティ

この情報は、証明書ポリシー (CP) と証明書プラクティスステートメント (CPS) と呼ばれる 2 つのドキュメントに取り込むことができます。CA オペレーションに関する重要な情報を取得するためのフレームワークについては、「[RFC 3647](https://www.ietf.org/rfc/rfc3647.txt)」を参照してください。

## 可能な場合にはルート CA の使用を最小限に抑える
<a name="minimize-root-use"></a>

ルート CA は、通常、中間 CA 認定を交付するためにのみ使用する必要があります。これにより、中間 CA がエンドエンティティ証明書を発行する毎日のタスクを実行しながら、ルート CA を害のない方法で保存することができます。

ただし、組織の現在のプラクティスがルート CA から直接エンドエンティティ証明書を発行する場合、 はセキュリティと運用のコントロールを向上させながら、このワークフローをサポート AWS Private CA できます。このシナリオでエンドエンティティ証明書を発行するには、ルート CA がエンドエンティティ証明書テンプレートを使用することを許可する IAM アクセス許可ポリシーが必要です。IAM ポリシーの詳細については、「[の Identity and Access Management (IAM) AWS Private Certificate Authority](security-iam.md)」を参照してください。

**注記**  
この設定では、運用上の問題が発生する可能性がある制限が課されます。たとえば、ルート CA が侵害されたり紛失したりした場合、新しいルート CA を作成し、環境内のすべてのクライアントに配布する必要があります。この回復プロセスが完了するまで、新しい証明書を発行することはできません。また、ルート CA から証明書を直接発行すると、アクセスを制限したり、ルートから発行される証明書の数を制限したりできなくなります。これらの証明書は、ルート CA の管理に関するベストプラクティスと見なされます。

## ルート CA を独自のものにする AWS アカウント
<a name="isolate-root-account"></a>

2 つの異なる AWS アカウントにルート CA と下位 CA を作成することが推奨されるベストプラクティスです。これにより、ルート CA に対する追加の保護とアクセス制御が提供されます。そのためには、あるアカウントの下位 CA から CSR をエクスポートして、別のアカウントのルート CA で署名します。このアプローチの利点は、CA の制御をアカウントごとに分けることができることです。欠点は、ウィザードを使用して AWS マネジメントコンソール ルート CA から下位 CA の CA 証明書に署名するプロセスを簡素化できないことです。

**重要**  
にアクセスするときはいつでも多要素認証 (MFA) を使用することを強くお勧めします AWS Private CA。

## 管理者ロールと発行者ロールを分ける
<a name="role-separation"></a>

CA 管理者ロールは、エンドエンティティ証明書の発行のみが必要なユーザーとは別にする必要があります。CA 管理者と証明書発行者が同じ に存在する場合は AWS アカウント、その目的専用の IAM ユーザーを作成して発行者のアクセス許可を制限できます。

## 証明書のマネージド失効を実装する
<a name="managed-revocation"></a>

マネージド失効は、証明書が取り消されたときに、証明書クライアントに自動的に通知します。暗号情報が侵害されたり、証明書が誤って発行されたりした場合は、証明書の取り消しが必要になることがあります。クライアントは通常、失効した証明書の受け入れを拒否します。 AWS Private CA は、オンライン証明書ステータスプロトコル (OCSP) と証明書失効リスト (CRLs 2 つの標準オプションを提供します。詳細については、「[AWS Private CA 証明書失効方法を計画する](revocation-setup.md)」を参照してください。

## をオンにする AWS CloudTrail
<a name="use-cloudtrail"></a>

プライベート CA を作成し、運用を開始する前に、CloudTrail のログ記録をオンにします。CloudTrail を使用すると、アカウントの AWS API コールの履歴を取得して、デプロイをモニタリングできます AWS 。この履歴には AWS マネジメントコンソール、、 AWS SDKs、 AWS Command Line Interface、および高レベルの AWS サービスから行われた API コールが含まれます。また、履歴では、PCA API オペレーションを呼び出したユーザーとアカウント、呼び出し元のソース IP アドレス、および呼び出しの発生日時を特定できます。API を使用して CloudTrail をアプリケーションに統合したり、組織用の証跡作成を自動化したり、証跡の状態を確認したり、CloudTrail のログ記録のオン/オフを管理者が切り替える方法を制御したりすることもできます。詳細については、「[証跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)」を参照してください。 AWS Private CA オペレーションの証跡の例を確認するには[を使用した AWS Private Certificate Authority API コールのログ記録 AWS CloudTrail](logging-using-cloudtrail-pca.md)、「」を参照してください。

## CA キーと証明書の管理
<a name="rotate-keys"></a>

プライベート CA のライフサイクルを管理するには、有効期間を延長するか、CA キーをローテーションします。

### CA の有効期間を延長する
<a name="extend-ca-validity"></a>

有効期限が長い新しい CA 証明書をインポートすることで、CA の有効期間を延長できます。

### CA キーをローテーションする
<a name="rotate-ca-key"></a>

プライベート CA を新しい CA に置き換えて、CA キーを定期的にローテーションします。新しい CA を作成したら、アプリケーションとサービスの CA ARN へのすべての参照を新しく作成された CA ARN に更新し、インフラストラクチャ全体の信頼ストアを新しい CA 証明書に更新します。

**注記**  
CA 自体を置き換える場合は、CA の ARN が変わることに注意してください。自動化におけるハードコードされた ARN リファレンスは破損します。

## 未使用の CA を削除する
<a name="delete-unused-ca"></a>

プライベート CA を完全に削除できます。この操作は、CA が不要になった場合や、より新しいプライベートキーを持つ CA に置き換える必要がある場合に行います。CA を安全に削除するには、「[プライベート CA の削除](PCADeleteCA.md)」で示している手順に従うことをお勧めします。

**注記**  
AWS は、CA が削除されるまで CA の料金を請求します。

## CRL へのパブリックアクセスをブロックする
<a name="bpa-crl"></a>

AWS Private CA では、CRLs を含むバケットで Amazon S3 パブリックアクセスブロック (BPA) 機能を使用することをお勧めします。これにより、プライベート PKI の詳細が潜在的な敵に不必要に公開されるのを防ぐことができます。BPA は S3 の[ベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)であり、新しいバケットではデフォルトで有効になっています。追加のセットアップが必要な場合があります。詳細については、「[CloudFront で S3 パブリックアクセスブロック (BPA) を有効にする](crl-planning.md#s3-bpa)」を参照してください。

## Amazon EKS アプリケーションのベストプラクティス
<a name="kubernetes"></a>

を使用して X.509 証明書で Amazon EKS AWS Private CA をプロビジョニングする場合は、[「Amazon EKS ベストプラクティスガイド」の「マルチテナント環境の保護に関する推奨事項](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/#kubernetes-as-a-service)」に従ってください。 AWS Private CA と Kubernetes との統合に関する一般的な情報については、「[で Kubernetes を保護する AWS Private Certificate Authority](PcaKubernetes.md)」を参照してください。