AWS Certificate Manager実装とデプロイ - 効果的な証明書運用

AWS Certificate Managerの基本概念を理解したら、次は実際の実装とデプロイです。この記事では、ACMを使用した証明書の取得から各種AWSサービスへのデプロイまで、具体的な手順と実用的な設定方法を詳しく解説します。効率的な証明書運用を実現するための実践的な知識を身につけましょう。

証明書の取得と検証

パブリック証明書の取得手順

ACMでのパブリック証明書取得は、シンプルなウィザード形式で進められます。ドメイン名の入力から検証まで、段階的なプロセスで確実に証明書を取得できます。

基本的な取得手順

ACMコンソールで「証明書をリクエスト」を選択
ドメイン名の入力（単一ドメイン、ワイルドカード、複数ドメイン）
検証方法の選択（DNS検証またはEmail検証）
検証の実行
証明書の発行

DNS検証の実装

DNS検証は、最も推奨される検証方法です。特にRoute 53を使用している場合は、検証プロセスが完全に自動化されます。

外部DNSプロバイダーでの設定例 Route 53以外のDNSプロバイダーを使用している場合は、指定されたCNAMEレコードを手動で追加する必要があります。

ワイルドカード証明書の取得

ワイルドカード証明書（*.example.com）は、サブドメインすべてをカバーする便利な証明書です。DNS検証でのみ利用可能で、Email検証では対応していません。

ワイルドカード証明書の利点

複数のサブドメインを単一証明書でカバー
新しいサブドメイン追加時の証明書取得が不要
管理する証明書数の削減
コスト効率性（無料提供）

主要AWSサービスとの統合

Application Load Balancer（ALB）での実装

ALBでのACM証明書の設定は、HTTPS通信の最も一般的な実装パターンです。証明書の自動更新も含めて、完全に自動化された運用が可能です。

ALBでの設定手順

ALBのリスナー設定でHTTPS（443）を追加
ACMから取得した証明書を選択
セキュリティポリシーの設定
HTTP to HTTPSリダイレクトの設定

セキュリティポリシーの選択

ELBSecurityPolicy-TLS-1-2-2019-07: TLS 1.2以降をサポート
ELBSecurityPolicy-FS-1-2-Res-2020-10: Perfect Forward Secrecyを重視
ELBSecurityPolicy-TLS-1-2-Ext-2018-06: 互換性を重視

CloudFrontでの実装

CloudFrontでのACM証明書使用には、特別な考慮事項があります。証明書は必ずus-east-1リージョンで取得する必要があります。

CloudFront固有の設定

証明書はus-east-1リージョンで取得
Viewer Protocol Policyの設定
Origin Protocol Policyの設定
セキュリティポリシーの選択

API Gatewayでの実装

API GatewayでのカスタムドメインとACM証明書の組み合わせにより、独自ドメインでのAPI提供が可能になります。

設定手順

API Gatewayでカスタムドメイン名を作成
ACM証明書を選択
Route 53でエイリアスレコードを設定
APIマッピングの設定

自動更新の設定と監視

更新プロセスの理解

ACMの自動更新は、証明書の有効期限60日前から開始されます。更新プロセスは段階的に実行され、失敗した場合は複数回のリトライが行われます。

更新スケジュール

60日前: 最初の更新試行
45日前: 2回目の試行
30日前: 3回目の試行
15日前: 4回目の試行
1日前: 最終試行

更新監視の実装

証明書の更新状況を監視し、問題が発生した場合に適切な通知を設定することが重要です。

CloudWatch アラーム設定

証明書の有効期限監視
更新失敗時のアラート
ドメイン検証失敗の通知

Infrastructure as Code（IaC）での実装

Terraformでの実装例

ACM証明書の取得と関連リソースの設定をTerraformで自動化することで、一貫性のある環境構築が可能です。

hcl

# ACM証明書の取得
resource "aws_acm_certificate" "main" {
  domain_name       = "example.com"
  subject_alternative_names = ["*.example.com"]
  validation_method = "DNS"
  
  lifecycle {
    create_before_destroy = true
  }
}

# Route 53での検証レコード自動追加
resource "aws_route53_record" "cert_validation" {
  for_each = {
    for dvo in aws_acm_certificate.main.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = data.aws_route53_zone.main.zone_id
}

# 証明書検証の完了待ち
resource "aws_acm_certificate_validation" "main" {
  certificate_arn         = aws_acm_certificate.main.arn
  validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

CloudFormationでの実装

CloudFormationテンプレートを使用した証明書管理も、再現可能なインフラストラクチャ構築に有効です。

yaml

Parameters:
  DomainName:
    Type: String
    Description: Domain name for the certificate
    Default: example.com
  HostedZone:
    Type: AWS::Route53::HostedZone::Id
    Description: Hosted Zone ID for the domain, required for DNS validation.
  PublicSubnets:
    Type: List<AWS::EC2::Subnet::Id>
    Description: A list of public subnets for the Application Load Balancer.
  LoadBalancerSecurityGroup:
    Type: AWS::EC2::SecurityGroup::Id
    Description: The security group ID for the Application Load Balancer.
  TargetGroup:
    Type: String
    Description: The ARN of the target group for the HTTPS listener.

Resources:
  Certificate:
    Type: AWS::CertificateManager::Certificate
    Properties:
      DomainName: !Ref DomainName
      SubjectAlternativeNames:
        - !Sub "*.${DomainName}"
      ValidationMethod: DNS
      DomainValidationOptions:
        - DomainName: !Ref DomainName
          HostedZoneId: !Ref HostedZone
        - DomainName: !Sub "*.${DomainName}"
          HostedZoneId: !Ref HostedZone

  LoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Type: application
      Subnets: !Ref PublicSubnets
      SecurityGroups: [!Ref LoadBalancerSecurityGroup]

  HTTPSListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref LoadBalancer
      Port: 443
      Protocol: HTTPS
      Certificates:
        - CertificateArn: !Ref Certificate
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref TargetGroup

セキュリティ最適化

セキュリティポリシーの選択

適切なセキュリティポリシーの選択により、セキュリティとパフォーマンスのバランスを最適化できます。

推奨設定

新規システム: ELBSecurityPolicy-TLS-1-2-2019-07
レガシー対応: ELBSecurityPolicy-2016-08
高セキュリティ: ELBSecurityPolicy-FS-1-2-Res-2020-10

Perfect Forward Secrecy（PFS）

PFSは、秘密鍵が漏洩した場合でも過去の通信内容を保護する重要なセキュリティ機能です。

PFS対応の利点

長期的なセキュリティ保護
規制要件への対応
セキュリティ監査での評価向上

トラブルシューティング

一般的な問題と解決策

証明書の取得や更新で発生する一般的な問題と、その解決策を理解しておくことが重要です。

DNS検証の失敗

CNAMEレコードの設定確認
TTL値の適切な設定
DNSプロパゲーションの待機

証明書更新の失敗

ドメイン所有権の再確認
DNS設定の変更検出
Email検証の場合は管理者メールの確認

ログとモニタリング

CloudTrailとCloudWatchを活用して、証明書関連の操作と状態を監視します。

パフォーマンス考慮事項

証明書の配布最適化

大規模環境では、証明書の配布とキャッシュ戦略が重要になります。

最適化手法

適切なTTL設定
証明書チェーンの最適化
OCSPステープリングの活用

リージョン間での考慮事項

グローバルアプリケーションでは、リージョン間での証明書管理戦略が重要です。

戦略的考慮点

CloudFrontでのグローバル配布
リージョナルエンドポイントでの個別証明書
災害復旧時の証明書可用性

まとめ

AWS Certificate Managerの効果的な実装には、適切な検証方法の選択、各種AWSサービスとの統合、自動更新の監視、セキュリティポリシーの最適化が重要です。IaCでのコード化により、一貫性のある運用を実現できます。

次のステップでは、より高度な運用シナリオと最適化手法について学習しましょう。

AWS Certificate Manager実装とデプロイ - 効果的な証明書運用 ​

証明書の取得と検証 ​

パブリック証明書の取得手順 ​

DNS検証の実装 ​

ワイルドカード証明書の取得 ​

主要AWSサービスとの統合 ​

Application Load Balancer（ALB）での実装 ​

CloudFrontでの実装 ​

API Gatewayでの実装 ​

自動更新の設定と監視 ​

更新プロセスの理解 ​

更新監視の実装 ​

Infrastructure as Code（IaC）での実装 ​

Terraformでの実装例 ​

CloudFormationでの実装 ​

セキュリティ最適化 ​

セキュリティポリシーの選択 ​

Perfect Forward Secrecy（PFS） ​

トラブルシューティング ​

一般的な問題と解決策 ​

ログとモニタリング ​

パフォーマンス考慮事項 ​

証明書の配布最適化 ​

リージョン間での考慮事項 ​

まとめ ​