翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ベストプラクティス ベストプラクティスは、 AWS Certificate Manager (AWS Certificate Manager) をより効果的に使用するのに役立つ推奨事項です。次のベストプラクティスは、現在の ACM クライアントの実際の経験に基づいています。 **Topics** + [アカウントレベルの分離](#best-practices-account-separation) + [AWS CloudFormation](#best-practices-cloudformation) + [カスタム信頼ストア](#best-practices-custom-trust-stores) + [証明書のピンニング](#best-practices-pinning) + [ドメイン検証](#best-practices-validating) + [ドメイン名の追加または削除](#best-practices-add-delete) + [証明書の透明性ログ記録のオプトアウト](#best-practices-transparency) + [オンにする AWS CloudTrail](#best-practices-ct) ## アカウントレベルの分離 ポリシーでアカウントレベルの分離を使用して、アカウントレベルで証明書にアクセスできるユーザーを制御します。本稼働用の証明書は、テスト用証明書や開発証明書とは別のアカウントに保管してください。アカウントレベルの分離を使用できない場合は、ポリシーで `kms:CreateGrant` アクションを拒否することで、特定のロールへのアクセスを制限できます。これにより、アカウント内で証明書に署名できるロールを高レベルで制限できます。許可に関する情報、特に用語については、*AWS Key Management Service デベロッパーガイド*の「[AWS KMSでの許可](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)」を参照してください。 アカウント単位での `kms:CreateGrant` の使用制限以上の詳細な制御が必要な場合は、[kms:EncryptionContext](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-encryption-context) 条件キーを使用して特定の証明書に `kms:CreateGrant` を制限できます。キーとして `arn:aws:acm` を指定し、制限する ARN の値を指定します。次のポリシー例は、特定の証明書の使用を防ぎ、他の証明書の使用を許可します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Deny", "Action": "kms:CreateGrant", "Resource": "*", "Condition": { "StringEquals": { "kms:EncryptionContext:aws:acm:arn": "arn:aws:acm:us-east-1:111122223333:certificate/b26def74-1234-4321-9876-951d4c07b197" } } } ] } ``` ------ ## AWS CloudFormation AWS CloudFormation を使用すると、使用する AWS リソースを記述するテンプレートを作成できます。 CloudFormation その後、 はそれらのリソースをプロビジョニングして設定します。 CloudFormation は、Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway などの ACM でサポートされているリソースをプロビジョニングできます。詳細については、「[サービスと ACM の統合](acm-services.md)」を参照してください。 CloudFormation を使用して複数のテスト環境をすばやく作成および削除する場合は、環境ごとに個別の ACM 証明書を作成しないことをお勧めします。これを行うと、証明書のクォータをすぐに使い切ってしまいます。(詳細については、[クォータ](acm-limits.md) を参照してください)。代わりに、テストに使用しているすべてのドメイン名をカバーするワイルドカード証明書を作成します。例えば、**`.service.example.com` などの、バージョン番号だけ異なるドメイン名に対して ACM 証明書を繰り返し作成する場合は、代わりに *<\$1>*`.service.example.com` のワイルドカード証明書を 1 つ作成します。 **重要** Amazon CloudFront ディストリビューションを使用している場合、HTTP 検証はワイルドカード証明書をサポートしていないことにご注意ください。Amazon CloudFront で使用するワイルドカード証明書を CloudFormation テンプレートに含める場合は、DNS 検証または E メール検証を使用する必要があります。自動更新機能には DNS 検証をお勧めします。 がテスト環境の作成 CloudFormation に使用するテンプレートにワイルドカード証明書を含めます。 ## カスタム信頼ストア ACM 証明書で保護されたエンドポイントへの接続を確保するために、[Amazon ルート](https://www.amazontrust.com/repository/) をカスタム信頼ストアに含めることをお勧めします。Amazon ルート認証機関は、さまざまなキータイプとアルゴリズムを表すことができます。Starfield Services ルート認証局 - G2 は、更新できない他の古い信頼ストアやクライアントと互換性がある古いルートです。すべてのルート CA を含めることで、アプリケーションの最大の互換性を確保できます。 ## 証明書のピンニング 証明書ピニング (SSL ピンニングとも呼ばれる) は、アプリケーションで、ホストに証明書階層ではなく X.509 証明書またはパブリックキーを直接関連付けることによって、リモートホストを検証するのに使用できるプロセスです。したがって、アプリケーションでは、ピニングを使用して SSL/TLS 証明書チェーンの検証をバイパスします。一般的な SSL 検証プロセスでは、ルート認証局 (CA) 証明書から下位 CA 証明書 (存在する場合) まで、証明書チェーン全体の署名をチェックします。また、階層の最下位にあるリモートホストの証明書もチェックします。その代わりに、アプリケーションは、証明書をピニングすることにより、リモートホストに、ルート証明書またはチェーン内の他のものではなく、その証明書のみが信頼できるということを伝えられます。リモートホストの証明書またはパブリックキーを開発中にアプリケーションに追加できます。または、最初にホストに接続する際にアプリケーションが証明書またはキーを追加することができます。 **警告** アプリケーションでは、ACM 証明書をピニング**しない**ことをお勧めします。&CM は、[でのマネージド証明書の更新 AWS Certificate Manager](managed-renewal.md) を実行し、Amazon 発行の SSL/TLS 証明書を有効期限が切れる前に自動的に更新します。証明書を更新するために ACM は新しいパブリックキーとプライベートキーのペアを生成します。アプリケーションが ACM 証明書をピン留めし、証明書が新しいパブリックキーで正常に更新された場合、アプリケーションはドメインに接続できない可能性があります。 証明書をピンすることを決定した場合は、次のオプションを選択しても、アプリケーションのドメインへの接続が妨げられることはありません。 + [保持する証明書](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)を ACM にインポートし、アプリケーションをインポートした証明書に固定化します。ACM はインポートした証明書を自動的に更新しようとはしません。 + パブリック証明書を使用している場合は、アプリケーションを利用可能なすべての [Amazon ルート証明書](https://www.amazontrust.com/repository/)に固定化します。プライベート証明書を使用している場合は、アプリケーションを CA のルート証明書にピンニングします。 ## ドメイン検証 Amazon 認証機関 (CA) がサイトの証明書を発行する前に、 AWS Certificate Manager (ACM) は、リクエストで指定したすべてのドメインを所有または管理していることを確認する必要があります。E メールまたは DNS のいずれかを使用して検証を実行できます。詳しくは、[AWS Certificate Manager DNS 検証DNS での検証](dns-validation.md) または [AWS Certificate Manager E メール検証](email-validation.md) を参照してください。 ## ドメイン名の追加または削除 既存の ACM 証明書からドメイン名を追加または削除することはできません。代わりに、修正済みのドメイン名のリストから新しい証明書をリクエストする必要があります。たとえば、証明書に 5 つのドメイン名があり、さらに 4 つを追加する場合は、9 つのドメイン名すべてで新しい証明書をリクエストする必要があります。新しい証明書と同様に、元の証明書に対して事前に検証済みの名前を含むリクエスト内のすべてのドメイン名の所有権を検証する必要があります。 E メール検証を使用する場合、ドメインごとに最大で 8 件の検証 E メールメッセージが送信され、そのうち少なくとも 1 件を 72 時間以内に処理する必要があります。たとえば、5 つのドメイン名で証明書をリクエストすると、最大で 40 件の検証メッセージが送信され、そのうち少なくとも 5 件を 72 時間以内に処理する必要があります。証明書リクエストのドメイン名の数が増えると、E メールを使用してドメインの所有権を検証するために必要な作業も増えます。 代わりに DNS 検証を使用する場合は、検証する FQDN のデータベースに対して新しい DNS レコードを 1 つ書き込む必要があります。ACM はレコードを送信してデータベースを作成し、後でそのデータベースに対してクエリを実行してレコードが追加されたかどうかを判断します。レコードの追加によって、お客様がドメインの所有者または管理者であることがアサートされます。前述の例では、5 つのドメイン名で証明書をリクエストした場合、5 つの DNS レコードを作成する必要があります。可能な場合は、DNS 検証を使用することをお勧めします。 ## 証明書の透明性ログ記録のオプトアウト **重要** 証明書の透明性のログ記録を無効にするために実行するアクションにかかわらず、証明書のバインド先のパブリックエンドポイントまたはプライベートエンドポイントにアクセスできるクライアントまたは個人によって、証明書が引き続きログに記録される場合があります。ただし、証明書には署名付き証明書タイムスタンプ (SCT) は含まれません。発行元の CA のみが、証明書に SCT を埋め込むことができます。 2018 年 4 月 30 日に、Google Chrome は証明書の透明性ログに記録されていないパブリック SSL/TLS 証明書の信頼を停止しました。したがって、2018 年 4 月 24 日から Amazon CA は、すべての新しい証明書と更新を少なくとも 2 つの公開ログに公開するようになりました。証明書がログに記録されると、削除することはできません。(詳細については、[証明書の透明性ログ記録](acm-concepts.md#concept-transparency) を参照してください)。 ログ記録は、証明書をリクエストするとき、または証明書が更新されたときに自動的に実行されますが、オプトアウトすることもできます。その一般的な理由には、セキュリティとプライバシーに関する懸念があります。たとえば、内部ホストドメイン名のログ記録により、それ以外の場合には公開されない内部ネットワークについての情報が潜在的な攻撃者に提供されます。さらに、ログ記録により、新規または未リリース製品やウェブサイトの名前が漏洩する可能性があります。 証明書をリクエストするときに、透明性ログを出力しないようにするには、[request-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) AWS CLI コマンド、または [RequestCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html) API オペレーションの `options` パラメータを使用します。証明書が 2018 年 4 月 24 日より前に発行され、[更新中にログに記録](https://docs.aws.amazon.com/cli/latest/reference/acm/update-certificate-options.html)されないようにする場合は、 コマンド、または [UpdateCertificateOptions](https://docs.aws.amazon.com/acm/latest/APIReference/API_UpdateCertificateOptions.html) API オペレーションを使用してオプトアウトすることができます。 **制限事項** + コンソールを使用して、透明性ログを有効または無効にすることはできません。 + 証明書が更新期間に入った後、通常はパブリック証明書の証明書の有効期限が切れる 45 日前にログ記録ステータスを変更することはできません。ステータスの変更が失敗しても、エラーメッセージは生成されません。 証明書がログに記録されると、ログから削除することはできません。その時点でオプトアウトしても効果はありません。証明書をリクエストしたときにログ記録を停止して、後でオプトインするように選択すると、証明書は更新されるまでログに記録されません。証明書をすぐにログに記録する場合は、新しい証明書を発行することをお勧めします。 次の例では、新しい証明書をリクエストするときに [request-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) コマンドを使用して証明書の透明性を無効にする方法を示しています。 ``` aws acm request-certificate \ --domain-name www.example.com \ --validation-method DNS \ --options CertificateTransparencyLoggingPreference=DISABLED \ ``` 上記のコマンドは、新しい証明書の ARN を出力します。 ``` { "CertificateArn": "arn:aws:acm:region:account:certificate/certificate_ID" } ``` 証明書がすでにある場合、証明書が更新されたときに記録されないようにするには、[update-certificate-options](https://docs.aws.amazon.com/cli/latest/reference/acm/update-certificate-options.html) コマンドを使用します。このコマンドは値を返しません。 ``` aws acm update-certificate-options \ --certificate-arn arn:aws:acm:region:account:\ certificate/certificate_ID \ --options CertificateTransparencyLoggingPreference=DISABLED ``` ## オンにする AWS CloudTrail ACM の使用を開始する前に、CloudTrail のログ記録を有効にします。CloudTrail を使用すると、 AWS マネジメントコンソール、 AWS SDKs、、および上位レベルの Amazon Web Services を介して行われた AWS API コールなど、アカウントの API コールの履歴を取得して AWS Command Line Interface、 AWS デプロイをモニタリングできます。また、履歴では、ACM API を呼び出したユーザーとアカウント、呼び出し元のソース IP アドレス、および呼び出しの発生日時を特定できます。API を使用して CloudTrail をアプリケーションに統合したり、組織用の証跡作成を自動化したり、証跡の状態を確認したり、CloudTrail のログ記録のオン/オフを管理者が切り替える方法を制御したりすることもできます。詳細については、「[証跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)」を参照してください。ACM アクションの証跡の例については、「[での CloudTrail の使用 AWS Certificate Manager](cloudtrail.md)」を参照してください。