翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ベストプラクティス
ベストプラクティスは、AWS Certificate Manager(AWS Certificate Manager) をより効果的に使用するのに役立つ推奨事項です。次のベストプラクティスは、現在の ACM クライアントの実際の経験に基づいています。
アカウントレベルの分離
ポリシーでアカウントレベルの分離を使用して、アカウントレベルで証明書にアクセスできるユーザーを制御します。本稼働用の証明書は、テスト用証明書や開発証明書とは別のアカウントに保管してください。アカウントレベルの分離を使用できない場合は、ポリシーで kms:CreateGrant アクションを拒否することで、特定のロールへのアクセスを制限できます。これにより、アカウント内で証明書に署名できるロールを高レベルで制限できます。許可に関する情報、特に用語については、AWS Key Management Service デベロッパーガイドの「AWS KMS での許可」を参照してください。
アカウント単位での kms:CreateGrant の使用制限以上の詳細な制御が必要な場合は、kms:EncryptionContext 条件キーを使用して特定の証明書に kms:CreateGrant を制限できます。キーとして arn:aws:acm を指定し、制限する ARN の値を指定します。次のポリシー例は、特定の証明書の使用を防ぎ、他の証明書の使用を許可します。
AWS CloudFormation
AWS CloudFormationを使用すると、使用するAWSリソースを記述するテンプレートを作成できます。 CloudFormationは、これらのリソースをプロビジョニングして設定します。CloudFormation は、Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway などの ACM でサポートされているリソースをプロビジョニングできます。詳細については、「統合サービスによるマネージドオートメーション」を参照してください。
CloudFormationを使用して複数のテスト環境をすばやく作成および削除する場合は、環境ごとに個別の ACM 証明書を作成しないことをお勧めします。これを行うと、証明書のクォータをすぐに使い切ってしまいます。(詳細については、クォータ を参照してください)。代わりに、テストに使用しているすべてのドメイン名をカバーするワイルドカード証明書を作成します。例えば、<version>.service.example.com などの、バージョン番号だけ異なるドメイン名に対して ACM 証明書を繰り返し作成する場合は、代わりに <*>.service.example.com のワイルドカード証明書を 1 つ作成します。
重要
Amazon CloudFront ディストリビューションを使用している場合、HTTP 検証はワイルドカード証明書をサポートしていないことにご注意ください。Amazon CloudFront で使用するワイルドカード証明書を CloudFormation テンプレートに含める場合は、DNS 検証または E メール検証を使用する必要があります。自動更新機能には DNS 検証をお勧めします。
がテスト環境の作成CloudFormationに使用するテンプレートにワイルドカード証明書を含めます。
カスタム信頼ストア
ACM 証明書で保護されたエンドポイントへの接続を確保するために、Amazon ルート
証明書のピンニング
証明書ピニング (SSL ピンニングとも呼ばれる) は、アプリケーションで、ホストに証明書階層ではなく X.509 証明書またはパブリックキーを直接関連付けることによって、リモートホストを検証するのに使用できるプロセスです。したがって、アプリケーションでは、ピニングを使用して SSL/TLS 証明書チェーンの検証をバイパスします。一般的な SSL 検証プロセスでは、ルート認証局 (CA) 証明書から下位 CA 証明書 (存在する場合) まで、証明書チェーン全体の署名をチェックします。また、階層の最下位にあるリモートホストの証明書もチェックします。その代わりに、アプリケーションは、証明書をピニングすることにより、リモートホストに、ルート証明書またはチェーン内の他のものではなく、その証明書のみが信頼できるということを伝えられます。リモートホストの証明書またはパブリックキーを開発中にアプリケーションに追加できます。または、最初にホストに接続する際にアプリケーションが証明書またはキーを追加することができます。
警告
アプリケーションでは、ACM 証明書をピニングしないことをお勧めします。&CM は、でのマネージド証明書の更新 AWS Certificate Manager を実行し、Amazon 発行の SSL/TLS 証明書を有効期限が切れる前に自動的に更新します。証明書を更新するために ACM は新しいパブリックキーとプライベートキーのペアを生成します。アプリケーションが ACM 証明書をピン留めし、証明書が新しいパブリックキーで正常に更新された場合、アプリケーションはドメインに接続できない可能性があります。
証明書をピンすることを決定した場合は、次のオプションを選択しても、アプリケーションのドメインへの接続が妨げられることはありません。
-
保持する証明書を ACM にインポートし、アプリケーションをインポートした証明書に固定化します。ACM はインポートした証明書を自動的に更新しようとはしません。
-
パブリック証明書を使用している場合は、アプリケーションを利用可能なすべての Amazon ルート証明書
に固定化します。プライベート証明書を使用している場合は、アプリケーションを CA のルート証明書にピンニングします。
ドメイン検証
Amazon 認証機関 (CA) がサイトの証明書を発行する前に、AWS Certificate Manager(ACM) はリクエストで指定したすべてのドメインを所有または管理していることを確認する必要があります。E メールまたは DNS のいずれかを使用して検証を実行できます。詳しくは、AWS Certificate Manager DNS 検証 または AWS Certificate Manager E メール検証 を参照してください。
ドメイン名の追加または削除
既存の ACM 証明書からドメイン名を追加または削除することはできません。代わりに、修正済みのドメイン名のリストから新しい証明書をリクエストする必要があります。たとえば、証明書に 5 つのドメイン名があり、さらに 4 つを追加する場合は、9 つのドメイン名すべてで新しい証明書をリクエストする必要があります。新しい証明書と同様に、元の証明書に対して事前に検証済みの名前を含むリクエスト内のすべてのドメイン名の所有権を検証する必要があります。
E メール検証を使用する場合、ドメインごとに最大で 8 件の検証 E メールメッセージが送信され、そのうち少なくとも 1 件を 72 時間以内に処理する必要があります。たとえば、5 つのドメイン名で証明書をリクエストすると、最大で 40 件の検証メッセージが送信され、そのうち少なくとも 5 件を 72 時間以内に処理する必要があります。証明書リクエストのドメイン名の数が増えると、E メールを使用してドメインの所有権を検証するために必要な作業も増えます。
代わりに DNS 検証を使用する場合は、検証する FQDN のデータベースに対して新しい DNS レコードを 1 つ書き込む必要があります。ACM はレコードを送信してデータベースを作成し、後でそのデータベースに対してクエリを実行してレコードが追加されたかどうかを判断します。レコードの追加によって、お客様がドメインの所有者または管理者であることがアサートされます。前述の例では、5 つのドメイン名で証明書をリクエストした場合、5 つの DNS レコードを作成する必要があります。可能な場合は、DNS 検証を使用することをお勧めします。
オンにするAWS CloudTrail
ACM の使用を開始する前に、CloudTrail のログ記録を有効にします。CloudTrail を使用すると、 AWSマネジメントコンソール、AWSSDKs、、および上位レベルの Amazon Web Services を介して行われた AWSAPI コールなど、アカウントの API コールの履歴を取得してAWS Command Line Interface、AWSデプロイをモニタリングできます。また、履歴では、ACM API を呼び出したユーザーとアカウント、呼び出し元のソース IP アドレス、および呼び出しの発生日時を特定できます。API を使用して CloudTrail をアプリケーションに統合したり、組織用の証跡作成を自動化したり、証跡の状態を確認したり、CloudTrail のログ記録のオン/オフを管理者が切り替える方法を制御したりすることもできます。詳細については、「証跡の作成」を参照してください。ACM アクションの証跡の例については、「での CloudTrail の使用 AWS Certificate Manager」を参照してください。
