ベストプラクティス

ベストプラクティスは、 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する の値を指定します。次のポリシー例では、特定の証明書の使用を禁止しますが、他の証明書は許可します。

{
   "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 リソースを記述するテンプレートを作成できます。 AWS CloudFormation は、これらのリソースをプロビジョニングして設定します。 AWS CloudFormation は、Elastic Load Balancing 、Amazon 、Amazon API Gateway ACMなど CloudFront、 でサポートされているリソースをプロビジョニングできます。詳細については、「と統合されたサービス AWS Certificate Manager」を参照してください。

AWS CloudFormation を使用して複数のテスト環境をすばやく作成および削除する場合は、環境ごとに個別のACM証明書を作成しないことをお勧めします。これを行うと、証明書のクォータをすぐに使い切ってしまいます。(詳細については、クォータ を参照してください)。代わりに、テストに使用しているすべてのドメイン名をカバーするワイルドカード証明書を作成します。例えば、 などのバージョン番号のみが異なるドメイン名のACM証明書を繰り返し作成する場合などです。<version>.service.example.comの代わりに、 用の 1 つのワイルドカード証明書を作成します。<*>.service.example.com。 がテスト環境の作成 AWS CloudFormation に使用するテンプレートにワイルドカード証明書を含めます。

証明書のピンニング

証明書の固定は、SSL固定とも呼ばれ、アプリケーションでリモートホストを検証するために使用できるプロセスで、そのホストを証明書階層ではなく X.509 証明書またはパブリックキーに直接関連付けます。したがって、アプリケーションは固定を使用して SSL/TLS 証明書チェーンの検証をバイパスします。一般的なSSL検証プロセスでは、ルート認証局 (CA) 証明書から下位 CA 証明書があれば、証明書チェーン全体の署名をチェックします。また、階層の最下位にあるリモートホストの証明書もチェックします。その代わりに、アプリケーションは、証明書をピニングすることにより、リモートホストに、ルート証明書またはチェーン内の他のものではなく、その証明書のみが信頼できるということを伝えられます。リモートホストの証明書またはパブリックキーを開発中にアプリケーションに追加できます。または、最初にホストに接続する際にアプリケーションが証明書またはキーを追加することができます。

警告

アプリケーションはACM証明書を固定しないことをお勧めします。ACM はACM 証明書のマネージド更新、Amazon が発行した SSL/TLS 証明書の有効期限が切れる前に自動的に更新するように を実行します。証明書を更新するために、 は新しいパブリックキーとプライベートキーのペアACMを生成します。アプリケーションがACM証明書をピン留めし、証明書が新しいパブリックキーで正常に更新されると、アプリケーションはドメインに接続できない可能性があります。

証明書をピンすることを決定した場合は、次のオプションを選択しても、アプリケーションのドメインへの接続が妨げられることはありません。

• に独自の証明書をインポートしACM、インポートした証明書にアプリケーションをピン留めします。ACM は、インポートされた証明書の自動更新を試みません。

• パブリック証明書を使用している場合は、アプリケーションを利用可能なすべての Amazon ルート証明書に固定化します。プライベート証明書を使用している場合は、アプリケーションを CA のルート証明書にピンニングします。

ドメイン検証

Amazon 認証局 (CA) がサイトの証明書を発行する前に、 AWS Certificate Manager （ACM) はリクエストで指定したすべてのドメインを所有または制御していることを確認する必要があります。E メールまたは を使用して検証を実行できますDNS。詳細については、「DNS 検証」および「E メール検証」を参照してください。

ドメイン名の追加または削除

既存のACM証明書にドメイン名を追加または削除することはできません。代わりに、修正済みのドメイン名のリストから新しい証明書をリクエストする必要があります。たとえば、証明書に 5 つのドメイン名があり、さらに 4 つを追加する場合は、9 つのドメイン名すべてで新しい証明書をリクエストする必要があります。新しい証明書と同様に、元の証明書に対して事前に検証済みの名前を含むリクエスト内のすべてのドメイン名の所有権を検証する必要があります。

E メール検証を使用する場合、ドメインごとに最大で 8 件の検証 E メールメッセージが送信され、そのうち少なくとも 1 件を 72 時間以内に処理する必要があります。たとえば、5 つのドメイン名で証明書をリクエストすると、最大で 40 件の検証メッセージが送信され、そのうち少なくとも 5 件を 72 時間以内に処理する必要があります。証明書リクエストのドメイン名の数が増えると、E メールを使用してドメインの所有権を検証するために必要な作業も増えます。

代わりにDNS検証を使用する場合は、検証する のデータベースに新しいDNSレコードを 1 FQDN つ書き込む必要があります。ACM は、レコードを作成して後でデータベースにクエリを実行して、レコードが追加されたかどうかを判断します。レコードの追加によって、お客様がドメインの所有者または管理者であることがアサートされます。前の例では、5 つのドメイン名を持つ証明書をリクエストする場合、5 つのDNSレコードを作成する必要があります。可能な場合はDNS検証を使用することをお勧めします。

証明書の透明性ログ記録のオプトアウト

重要

証明書の透明性のログ記録を無効にするために実行するアクションにかかわらず、証明書のバインド先のパブリックエンドポイントまたはプライベートエンドポイントにアクセスできるクライアントまたは個人によって、証明書が引き続きログに記録される場合があります。ただし、証明書には署名付き証明書のタイムスタンプ () は含まれませんSCT。証明書に を埋め込むことができるのは、発行元の CA SCT のみです。

2018 年 4 月 30 日以降、Google Chrome は、証明書の透明性ログに記録されていないパブリックSSL/TLS証明書を信頼しなくなります。したがって、2018 年 4 月 24 日から Amazon CA は、すべての新しい証明書と更新を少なくとも 2 つの公開ログに公開するようになりました。証明書がログに記録されると、削除することはできません。(詳細については、証明書の透明性ログ記録 を参照してください)。

ログ記録は、証明書をリクエストするとき、または証明書が更新されたときに自動的に実行されますが、オプトアウトすることもできます。その一般的な理由には、セキュリティとプライバシーに関する懸念があります。たとえば、内部ホストドメイン名のログ記録により、それ以外の場合には公開されない内部ネットワークについての情報が潜在的な攻撃者に提供されます。さらに、ログ記録により、新規または未リリース製品やウェブサイトの名前が漏洩する可能性があります。

証明書のリクエスト時に透明性ログ記録をオプトアウトするには、request-certificate AWS CLI コマンドの optionsパラメータまたは RequestCertificateAPIオペレーションを使用します。証明書が 2018 年 4 月 24 日より前に発行され、更新中にログに記録されないようにしたい場合は、 update-certificate-options コマンドまたは UpdateCertificateOptionsAPIオペレーションを使用してオプトアウトできます。

制限事項

• コンソールを使用して、透明性ログを有効または無効にすることはできません。

• 証明書が更新期間に入った後 (通常は証明書の有効期限が切れる 60 日前) にロギング状態を変更することはできません。ステータスの変更が失敗しても、エラーメッセージは生成されません。

証明書がログに記録されると、ログから削除することはできません。その時点でオプトアウトしても効果はありません。証明書をリクエストしたときにログ記録を停止して、後でオプトインするように選択すると、証明書は更新されるまでログに記録されません。証明書をすぐにログに記録する場合は、新しい証明書を発行することをお勧めします。

次の例では、新しい証明書をリクエストするときに request-certificate コマンドを使用して証明書の透明性を無効にする方法を示しています。

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 コマンドを使用します。このコマンドは値を返しません。

aws acm update-certificate-options \
--certificate-arn arn:aws:acm:region:account:\
certificate/certificate_ID \
--options CertificateTransparencyLoggingPreference=DISABLED

オンにする AWS CloudTrail

の使用を開始する前に CloudTrail ログ記録を有効にするACMと CloudTrail 、 AWS マネジメントコンソール、、、および上位レベルの Amazon Web Services を介した呼び出しを含む、アカウントのAPI呼び出しの AWS API履歴を取得して AWS SDKs AWS Command Line Interface、 AWS デプロイをモニタリングできます。また、 を呼び出したユーザーとアカウントACMAPIs、呼び出し元の IP アドレス、呼び出しが発生した日時を特定することもできます。を使用してアプリケーション CloudTrail に統合したりAPI、組織の証跡作成を自動化したり、証跡のステータスを確認したり、管理者が CloudTrail ログ記録をオンまたはオフにする方法を制御したりできます。詳細については、「証跡の作成」を参照してください。アクションの証跡の例を確認するにはとの併用 CloudTrail AWS Certificate Manager、ACM「」を参照してください。