セキュリティ

AWS CloudHSM で実現する専用鍵管理 - FIPS 140-2 Level 3 準拠の暗号化

専有の HSM インスタンスで FIPS 140-2 Level 3 準拠の鍵管理を実現する。KMS との使い分けと、KMS カスタムキーストアによる両者の統合を紹介します。

約 3 分で読めます

CloudHSM の概要

CloudHSM は専用のハードウェアセキュリティモジュール (HSM) で暗号鍵を管理するサービスです。KMS がマルチテナントの共有 HSM を使用するのに対し、CloudHSM は専有の HSM インスタンスを提供します。FIPS 140-2 Level 3 認証を取得しており、金融、医療、政府機関のコンプライアンス要件に対応します。HSM 内で鍵が生成・保管され、鍵素材は HSM の外部に平文でエクスポートされることはありません。AWS スタッフも鍵にアクセスできない設計であり、鍵の完全な所有権はユーザーに帰属します。

KMS との使い分け

KMS は大半のユースケースに適しており、運用負荷が低く、AWS サービスとの統合が豊富です。CloudHSM は FIPS 140-2 Level 3 が必須の場合、鍵を専有 HSM で管理する必要がある場合、PKCS#11 や JCE インターフェースが必要な場合に選択します。KMS カスタムキーストアは両者の利点を組み合わせ、KMS の API と統合性を維持しながら、鍵の保管先を CloudHSM にします。KMS は FIPS 140-2 Level 2 (一部エンドポイントは Level 3) で認証されているため、Level 3 が監査上必須でなければ KMS で十分です。暗号処理のスループットが重要な場合、CloudHSM は単一インスタンスで毎秒数千回の RSA 署名や AES 暗号化を処理でき、KMS のリクエストレートクォータ (デフォルト毎秒数千リクエスト、リージョン依存) を超える処理量が必要な場面で有利です。

クラスター設計と高可用性

CloudHSM クラスターは複数の AZ に HSM インスタンスを配置し、鍵の自動同期で高可用性を確保します。最低 2 つの AZ に HSM を配置する構成が推奨され、1 つの HSM が障害を起こしても別の AZ の HSM で処理を継続します。クライアント SDK はクラスター内の HSM にラウンドロビンでリクエストを分散し、障害時は自動的にフェイルオーバーします。HSM のバックアップは自動的に暗号化されて S3 に保存され、クラスターの復元やリージョン間のコピーに使用します。PKCS#11、JCE、OpenSSL の標準インターフェースでアプリケーションから暗号化操作を実行でき、既存のアプリケーションコードの変更を最小限に抑えられます。 暗号鍵管理のベストプラクティスを網羅的に学ぶなら、技術書 (Amazon)を参照してください。

代表的なユースケース

CloudHSM の主要なユースケースとして、SSL/TLS オフロード、データベース暗号化 (TDE)、コード署名とドキュメント署名、プライベート認証局 (CA) の鍵保管、金融トランザクションの署名 (PCI DSS 準拠)、トークナイゼーションがあります。SSL/TLS オフロードでは Web サーバーの秘密鍵を HSM に格納し、OpenSSL エンジン経由で署名処理を委譲することで、EC2 インスタンスのメモリから秘密鍵を排除します。Oracle TDE や Microsoft SQL Server TDE と統合し、データベースの暗号化鍵を HSM で保護する構成も一般的です。AWS Private CA と連携して CA の秘密鍵を CloudHSM に保管し、証明書発行時の署名処理を HSM で実行する構成により、CA 鍵の漏洩リスクを低減できます。

CloudHSM の料金と運用上の注意点

CloudHSM は HSM インスタンスの時間課金で、1 インスタンスあたり約 1.60 ドル/時 (約 1,152 ドル/月) です。高可用性構成で 2 AZ に配置すると月額約 2,304 ドルになります。KMS (月額 1 ドル/キー) と比較して大幅に高コストのため、FIPS 140-2 Level 3 の要件や専有 HSM の要件がある場合に限定して使用します。運用上の注意点として、Crypto Officer (CO) の認証情報を紛失するとクラスター内の鍵に永久にアクセスできなくなるため、認証情報の安全な保管が不可欠です。HSM ユーザーの管理 (CU: Crypto User、CO: Crypto Officer) は AWS IAM とは独立した仕組みであり、HSM 内部のユーザー管理コマンドで行います。クラスターの初期化手順として、最初の HSM 作成後に CloudHSM Management Utility (CMU) で CO を作成し、その後 CU を作成してアプリケーションに鍵操作を許可する流れになります。

専用 HSM が必要になる場面

多くの暗号化の用途は、マネージドな鍵管理サービスで十分に対応できます。それでも専用の HSM が必要になるのは、特定の要件がある場合です。規制やコンプライアンスで、定められた認証水準を満たす専用のハードウェアでの鍵管理が求められるケースが代表的です。また、鍵を自社が完全に占有・管理し、クラウド事業者を含む第三者が一切触れられない状態を保証したい場合にも、専用 HSM が選択肢になります。独自の暗号処理や、特定の業界標準への準拠が必要な場面もあります。こうした厳格な要件がある部分に絞って専用 HSM を使い、それ以外は managed なサービスで賄う、という使い分けが現実的です。

まとめ

CloudHSM は専有のハードウェアセキュリティモジュールで暗号鍵を管理し、FIPS 140-2 Level 3 の厳格なコンプライアンス要件に対応するサービスです。KMS カスタムキーストアで KMS API から CloudHSM の鍵を操作でき、PKCS#11 や JCE の標準インターフェースで既存アプリケーションとの統合も容易です。高コストのため要件が明確な場合に限定して採用し、認証情報管理と高可用性設計を慎重に計画することが重要です。

関連するサービス

AWS CloudHSM専用のハードウェアセキュリティモジュールで暗号鍵を管理するサービスAWS KMSデータの暗号化に使う鍵を安全に作成・管理できるマネージド暗号鍵サービスAWS Private Certificate Authorityプライベート証明書の発行・管理を行うマネージド認証局サービス

関連する記事

AWS Private CA で構築するプライベート PKI - 証明書の自動発行とローテーションプライベート認証局を構築し、内部サービス間の mTLS 証明書を自動発行する。証明書のライフサイクル管理と CRL の設計を紹介します。AWS Nitro Enclaves で実現する機密データ処理 - 隔離環境での暗号化と認証Nitro Enclaves の隔離環境で機密データを処理し、KMS との統合とアテステーションで暗号鍵のアクセスを制御する手法を紹介します。AWS Payment Cryptography で実現するクラウド決済処理 - 暗号鍵管理と PIN 検証Payment Cryptography による決済用暗号鍵の管理、PIN ブロックの暗号化・復号、PCI DSS 準拠を解説します。

同じテーマの記事

IAM Access Analyzer で検出する過剰なアクセス権限 - 外部アクセスと未使用権限の分析IAM ロールの未使用権限を CloudTrail ベースで検出し、最小権限ポリシーを自動生成する。外部アクセスの検出と CI/CD へのカスタムポリシーチェック組み込みまでを解説します。AWS Certificate Manager で自動化する SSL/TLS 証明書管理 - 発行からローテーションまでACM によるパブリック証明書の無料発行、DNS 検証、自動更新、ALB ・ CloudFront へのデプロイを解説します。AWS Artifact でコンプライアンスレポートを取得 - 監査対応と契約管理SOC・PCI DSS・ISO の監査レポートをオンデマンドで取得し、BAA や GDPR DPA を Organizations 全体に一括適用する手順を紹介します。監査の自動化 - AWS Audit Manager でコンプライアンス証跡を継続的に収集するAWS Audit Manager を使った監査証跡の自動収集を解説。フレームワーク (SOC 2、PCI DSS、GDPR 等) に基づく自動評価、エビデンスの一元管理、監査レポートの生成を紹介します。AWS アカウント ID の 12 桁に隠された構造 - なぜ 12 桁なのか、何が読み取れるのかAWS アカウント ID が 12 桁の数字である理由、ARN の構造に埋め込まれた設計意図、アカウント ID から推測できる情報とセキュリティ上の注意点を雑学的に解説します。AWS アカウントのルートユーザーはなぜ危険なのか - 権限分離の設計思想と封印の実践AWS ルートユーザーが IAM では制限できない特権を持つ理由、ルートユーザーでしかできない操作の一覧、MFA の設定方法、Organizations のルートアクセス管理による封印戦略を解説します。証明書管理と HTTPS 化 - AWS Certificate Manager による TLS 証明書の自動運用AWS Certificate Manager (ACM) を使った TLS/SSL 証明書の発行・自動更新・デプロイを解説。CloudFront ・ ALB ・ API Gateway との統合、DNS 検証、プライベート CA の活用まで紹介します。CloudTrail はすべてを見ている - API 呼び出しの記録メカニズムとフォレンジック調査の実践CloudTrail が AWS API 呼び出しを記録する仕組み、管理イベントとデータイベントの違い、CloudTrail Lake による SQL 分析、セキュリティインシデント発生時のフォレンジック調査手法を解説します。

内容が近い記事・サービス

AWS CloudHSMFIPS 140-2 Level 3 認証済みのハードウェアセキュリティモジュールを専有利用し、暗号鍵の生成・保管・暗号処理をクラウド上で実行するサービスハードウェアセキュリティモジュール - AWS CloudHSM による暗号鍵の専有管理AWS CloudHSM を使った暗号鍵の専有管理を解説。KMS との使い分け、FIPS 140-2 Level 3 準拠、TLS オフロード、Oracle TDE 統合など高度なユースケースを紹介します。KMS の暗号鍵はどこに保存されているのか - エンベロープ暗号化と HSM の仕組みKMS のマスターキーが FIPS 140-2 認定の HSM 内に保存される仕組み、エンベロープ暗号化でデータキーを二重に保護する設計、キーローテーションの内部動作を解説します。AWS の暗号化とデータ主権 - KMS から Nitro Enclaves までハードウェアレベルの分離を実現AWS KMS、CloudHSM、Nitro Enclaves によるハードウェアレベルの暗号化とデータ主権の確保を解説し、他社クラウドとの設計差異を比較します。