セキュリティ

ハードウェアセキュリティモジュール - AWS CloudHSM による暗号鍵の専有管理

AWS CloudHSM を使った暗号鍵の専有管理を解説。KMS との使い分け、FIPS 140-2 Level 3 準拠、TLS オフロード、Oracle TDE 統合など高度なユースケースを紹介します。

約 3 分で読めます

暗号鍵管理の要件と CloudHSM の位置づけ

暗号鍵の管理は情報セキュリティの根幹です。AWS KMS (Key Management Service) はほとんどのユースケースで十分な暗号鍵管理を提供しますが、一部の規制要件やセキュリティポリシーでは、暗号鍵を専有のハードウェアで管理し、AWS を含む第三者がアクセスできない状態を求められます。AWS CloudHSM は FIPS 140-2 Level 3 認証済みの専有 HSM (Hardware Security Module) をクラウド上で提供するサービスです。HSM はユーザーの VPC 内にデプロイされ、暗号鍵の生成・保存・使用がすべて HSM 内部で完結します。AWS は HSM のハードウェア管理 (プロビジョニング、パッチ適用、バックアップ) を担当しますが、HSM 内部の暗号鍵にはアクセスできません。鍵の管理権限はユーザーが完全に保持します。KMS もバックエンドで HSM を使用していますが、マルチテナントの共有 HSM であり、鍵の管理は AWS と共同で行う形です。コンプライアンス要件で「鍵の専有管理」が求められる場合に CloudHSM が必要になります。

クラスター構成と標準 API

CloudHSM はクラスター単位で管理します。クラスターは 1 つ以上の HSM で構成され、高可用性のために 2 つ以上の AZ に HSM を配置することが推奨されます。クラスター内の HSM 間で暗号鍵が自動的に同期されるため、1 台の HSM が障害を起こしても鍵へのアクセスが継続します。CloudHSM は業界標準の暗号 API をサポートします。PKCS#11 は C/C++ アプリケーションや OpenSSL との統合に使用します。JCE (Java Cryptography Extension) は Java アプリケーションとの統合に使用します。CNG/KSP (Cryptography API: Next Generation / Key Storage Provider) は Windows アプリケーションとの統合に使用します。これらの標準 API に対応しているため、既存のアプリケーションコードの変更は最小限で済みます。HSM クライアントソフトウェアを EC2 インスタンスにインストールし、VPC 内のプライベートネットワーク経由で HSM と通信します。

KMS との使い分け

CloudHSM と KMS の選択は、セキュリティ要件とコストのバランスで判断します。 KMS を選ぶべきケースは、 AWS サービス (S3 、 EBS 、 RDS 、 Lambda など) の暗号化、一般的なアプリケーションの暗号化、コストを抑えたい場合です。 KMS は API 呼び出し 1 万件あたり 0.03 USD と低コストで、 AWS サービスとのネイティブ統合が豊富です。 CloudHSM を選ぶべきケースは、 FIPS 140-2 Level 3 の認証が必要な場合 (KMS は Level 2)、暗号鍵の専有管理が規制で求められる場合、 TLS/SSL オフロードで秘密鍵を HSM 内に保持したい場合、 PKCS#11 や JCE などの標準暗号 API が必要な場合、 Oracle TDE や Microsoft SQL Server の暗号化鍵を HSM で管理したい場合です。 KMS のカスタムキーストア機能を使えば、 CloudHSM クラスターを KMS のバックエンドとして使用でき、 KMS の使いやすさと CloudHSM のセキュリティを両立できます。 HSM 暗号化のベストプラクティスを網羅的に学ぶなら、技術書 (Amazon)を参照してください。

TLS オフロードとデータベース暗号化

CloudHSM の代表的なユースケースが TLS/SSL オフロードです。Web サーバー (Nginx、Apache) の TLS 秘密鍵を CloudHSM 内に保持し、TLS ハンドシェイク時の秘密鍵操作を HSM 内で実行します。秘密鍵がサーバーのメモリやディスクに展開されないため、サーバーが侵害されても秘密鍵が漏洩するリスクを排除できます。OpenSSL エンジンとして CloudHSM を設定することで、Nginx や Apache の設定変更のみで TLS オフロードを実現できます。データベース暗号化では、Oracle TDE (Transparent Data Encryption) の暗号化マスターキーを CloudHSM で管理できます。Oracle Database の設定で PKCS#11 ライブラリとして CloudHSM クライアントを指定するだけで、データベースの暗号化鍵が HSM で保護されます。Microsoft SQL Server の EKM (Extensible Key Management) との統合も同様にサポートされています。料金は 1 HSM あたり 1.60 USD/時で、2 台構成の場合は月額約 2,336 USD です。

CloudHSM の料金

CloudHSM は 1 インスタンスあたり約 1.60 ドル/時 (月額約 1,152 ドル) です。高可用性構成で 2 AZ に配置すると月額約 2,304 ドルです。KMS (月額 1 ドル/キー) と比較して大幅に高コストのため、FIPS 140-2 Level 3 の要件や専有 HSM の要件がある場合に限定して使用します。KMS カスタムキーストアで CloudHSM をバックエンドとして使用すると、KMS の API で CloudHSM の鍵を操作できます。

まとめ - CloudHSM の活用指針

AWS CloudHSM は、暗号鍵の専有管理が求められるエンタープライズ向けのサービスです。FIPS 140-2 Level 3 認証、標準暗号 API (PKCS#11、JCE、CNG)、TLS オフロード、データベース暗号化統合が主な強みです。ほとんどのユースケースでは KMS で十分ですが、規制要件で鍵の専有管理が求められる場合や、TLS 秘密鍵を HSM 内に保持したい場合に CloudHSM を検討してください。月額約 2,336 USD〜のコストが発生するため、要件を慎重に評価した上で導入を判断することを推奨します。

関連するサービス

AWS CloudHSM専用のハードウェアセキュリティモジュールで暗号鍵を管理するサービスAWS KMSデータの暗号化に使う鍵を安全に作成・管理できるマネージド暗号鍵サービスAWS IAMAWS リソースへのアクセスを安全に管理するための認証・認可サービス

関連する記事

機密コンピューティング - AWS Nitro Enclaves で処理中のデータを隔離保護するAWS Nitro Enclaves を使った機密データの隔離処理を解説。暗号化アテステーション、KMS 統合、PII 処理・暗号鍵管理のユースケースを紹介します。AWS CloudHSM で実現する専用鍵管理 - FIPS 140-2 Level 3 準拠の暗号化専有の HSM インスタンスで FIPS 140-2 Level 3 準拠の鍵管理を実現する。KMS との使い分けと、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 の活用まで紹介します。AWS CloudHSM で実現する専用鍵管理 - FIPS 140-2 Level 3 準拠の暗号化専有の HSM インスタンスで FIPS 140-2 Level 3 準拠の鍵管理を実現する。KMS との使い分けと、KMS カスタムキーストアによる両者の統合を紹介します。

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

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