翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS Private CA のベストプラクティス
ベストプラクティスは、AWS Private CA をより効果的に使用するのに役立つ推奨事項です。次のベストプラクティスは、現在の AWS Certificate Manager クライアントおよび AWS Private CA 顧客の実際の経験に基づいています。
CA の構造とポリシーのドキュメント化
AWS では、CA の運用に関するすべてのポリシーとプラクティスを文書化することを推奨します。アプローチには以下が含まれます。
-
CA 構造に関する意思決定の推論
-
CA とその関係を示す図
-
CA の有効期間に関するポリシー
-
CA 承継の計画
-
パスの長さに関するポリシー
-
アクセス許可のカタログ
-
管理制御構造の説明
-
セキュリティ
この情報は、証明書ポリシー (CP) と証明書プラクティスステートメント (CPS) と呼ばれる 2 つのドキュメントに取り込むことができます。CA オペレーションに関する重要な情報を取得するためのフレームワークについては、「RFC 3647
可能な場合にはルート CA の使用を最小限に抑える
ルート CA は、通常、中間 CA 認定を交付するためにのみ使用する必要があります。これにより、中間 CA がエンドエンティティ証明書を発行する毎日のタスクを実行しながら、ルート CA を害のない方法で保存することができます。
ただし、組織の現在のプラクティスがルート CA から直接エンドエンティティ証明書を発行する場合、AWS Private CA はこのワークフローをサポートすると同時に、セキュリティと運用制御を向上させることができます。このシナリオでエンドエンティティ証明書を発行するには、ルート CA がエンドエンティティ証明書テンプレートを使用することを許可する IAM アクセス許可ポリシーが必要です。IAM ポリシーの詳細については、「の Identity and Access Management (IAM) AWS Private Certificate Authority」を参照してください。
注記
この設定では、運用上の問題が発生する可能性がある制限が課されます。たとえば、ルート CA が侵害されたり紛失したりした場合、新しいルート CA を作成し、環境内のすべてのクライアントに配布する必要があります。この回復プロセスが完了するまで、新しい証明書を発行することはできません。また、ルート CA から証明書を直接発行すると、アクセスを制限したり、ルートから発行される証明書の数を制限したりできなくなります。これらの証明書は、ルート CA の管理に関するベストプラクティスと見なされます。
ルート CA を独自のものにする AWS アカウント
2 つの異なる AWS アカウントでルート CA と下位 CA を作成するのが推奨されるベストプラクティスです。これにより、ルート CA に対する追加の保護とアクセス制御が提供されます。そのためには、あるアカウントの下位 CA から CSR をエクスポートして、別のアカウントのルート CA で署名します。このアプローチの利点は、CA の制御をアカウントごとに分けることができることです。欠点は、AWS Management Console ウィザードを使用して、ルート CA から下位 CA の CA 証明書に署名するプロセスを簡素化できないことです。
重要
AWS Private CA にアクセスするときは常に多要素認証 (MFA) を使用することを強くお勧めします。
管理者ロールと発行者ロールを分ける
CA 管理者ロールは、エンドエンティティ証明書の発行のみが必要なユーザーとは別にする必要があります。CA 管理者と証明書発行者が同じ に存在する場合はAWS アカウント、その目的専用の IAM ユーザーを作成して発行者のアクセス許可を制限できます。
証明書のマネージド失効を実装する
マネージド失効は、証明書が取り消されたときに、証明書クライアントに自動的に通知します。暗号情報が侵害されたり、証明書が誤って発行されたりした場合は、証明書の取り消しが必要になることがあります。通常、クライアントは取り消された証明書の受け取りを拒否します。AWS Private CA には、オンライン証明書ステータスプロトコル (OCSP) と証明書失効リスト (CRL) の 2 つのマネージド失効の標準オプションがあります。詳細については、「証明書失効方法の設定」を参照してください。
AWS CloudTrail をオンにする
プライベート CA を作成して運用を開始する前に、 CloudTrail ログ記録を有効にします。を使用すると CloudTrail、アカウントの AWS API コールの履歴を取得して、AWSデプロイをモニタリングできます。この履歴には、AWS Management Console、AWS SDK、AWS Command Line Interface、およびより高レベルの AWS サービスから行われた API 呼び出しが含まれます。また、履歴では、PCA API オペレーションを呼び出したユーザーとアカウント、呼び出し元のソース IP アドレス、および呼び出しの発生日時を特定できます。API を使用してアプリケーション CloudTrail に統合したり、組織の証跡の作成を自動化したり、証跡のステータスを確認したり、管理者が CloudTrail ログ記録のオンとオフを切り替える方法を制御したりできます。詳細については、「証跡の作成」を参照してください。AWS Private CA オペレーションの証跡の例については、「の使用 CloudTrail」を参照してください。
CA プライベートキーを切り替える
ベストプラクティスとして、プライベート CA のプライベートキーを定期的に更新します。キーを更新するには、新しい CA 認定をインポートするか、プライベート CA を新しい CA に置き換えます。
注記
CA 自体を置き換える場合は、CA の ARN が変わることに注意してください。この結果、ハードコーディングされた ARN に依存する自動化が失敗します。
未使用の CA を削除する
プライベート CA を完全に削除できます。この操作は、CA が不要になった場合や、より新しいプライベートキーを持つ CA に置き換える必要がある場合に行います。CA を安全に削除するには、「プライベート CA の削除」で示している手順に従うことをお勧めします。
注記
AWS は、CA が削除されるまで請求を行います。
CRL へのパブリックアクセスをブロックする
AWS Private CA では、CRL を含むバケットで Amazon S3 パブリックアクセスブロック (BPA) 機能を使用することをお勧めします。これにより、プライベート PKI の詳細が潜在的な敵に不必要に公開されるのを防ぐことができます。BPA は S3 のベストプラクティスであり、新しいバケットではデフォルトで有効になっています。追加のセットアップが必要な場合があります。詳細については、「で S3 ブロックパブリックアクセス (BPA) を有効にする CloudFront」を参照してください。
Amazon EKS アプリケーションのベストプラクティス
AWS Private CA を使用して X.509 証明書による Amazon EKS のプロビジョニングを行う場合は、Amazon EKS Best Practices Guides
