AWS Key Management Service (AWS KMS) の外部キーストアが利用可能になったことを発表できることを嬉しく思います。暗号化キーをオンプレミスまたは AWS クラウドの外部に保存して使用する必要がある規制上の必要性があるお客様は、そのようにできるようになりました。この新機能により、AWS KMS カスタマー管理キーを、オンプレミスまたは任意の場所で運用するハードウェアセキュリティモジュール (HSM) に保存できます。
大まかに言うと、AWS KMS は HSM と安全に通信するために API コールを転送します。キーマテリアルが HSM から離れることはありません。このソリューションでは、Amazon EBS、AWS Lambda、Amazon S3、Amazon DynamoDB、その他 100 を超えるサービスなど、AWS KMS カスタマー管理キーをサポートする大部分の AWS サービスのデータを外部キーで暗号化できます。既存の AWS サービスの設定パラメータやコードを変更する必要はありません。
これにより、暗号化キーを AWS データセンター外で保管、使用すべき規制対象ワークロードのごく一部について、ユースケースのブロックを解除することができます。しかし、これはクラウドベースのインフラストラクチャの運用方法に大きな変化をもたらし、責任分担モデルにも大きな変化をもたらします。この機能を有効にするのは、ごく一部のお客様のみであると予想しています。保護されたデータに対する運用上の負担が増え、可用性、パフォーマンス、低レイテンシーの運用に対するリスクが高くなると、ほとんどの場合、AWS KMS External Key Store から得られるセキュリティ上の利点を超えることになります。
詳細を説明します。
キー管理と暗号化についての簡単なまとめ
AWS サービスが保管中のデータを暗号化するように設定されている場合、サービスは AWS KMS に固有の暗号化キーを要求します。これをデータ暗号化キーと呼びます。データ暗号化キーを保護するために、このサービスでは、AWS KMS が特定の KMS カスタマー管理キー (ルートキーとも呼ばれる) を使用してそのキーを暗号化するようにもリクエストします。一度暗号化しておけば、データキーは保護対象のデータと一緒に安全に保存できます。このパターンはエンベロープ暗号化と呼ばれます。暗号化されたデータと、それらのデータの暗号化に使用された暗号化キーの両方を含むエンベロープを想像してみてください。
しかし、ルートキーを保護するにはどうすればよいでしょうか。 ルートキーは、暗号化したすべてのデータキーを復号化できるため、保護が不可欠です。
ルートキーマテリアルは安全に生成され、シークレットを保存するように設計されたハードウェアセキュリティモジュールに保存されます。耐タンパ性を持ち、キーマテリアルがプレーンテキストで保護されたハードウェアを離れることがないように設計されています。AWS KMS では、NIST 140-2 暗号化モジュール認定プログラムで認定された HSM を使用しています。
データ分類に関連するルートキーを作成するか、さまざまな AWS サービスを保護するために一意のルートキーを作成するか、プロジェクトタグごとに作成するか、各データ所有者に関連付けるかを選択できます。各ルートキーは各 AWS リージョンに固有です。
AWS KMS では、お客様が自分でキーを作成および管理するときに、ルートキーをカスタマー管理キーと呼びます。Amazon Elastic Block Store (Amazon EBS)、Amazon Simple Storage Service (Amazon S3)、Amazon リレーショナルデータベースサービス (RDS)、Amazon DynamoDB など、データを暗号化する AWS サービスに代わって作成されたものを AWS マネージドキーと呼びます。わかりやすくするために、これを KMS キーと呼びましょう。これらはルートキーであり、セキュリティで保護された HSM 環境から決して離れることはありません。KMS の暗号化および復号化操作はすべて HSM の安全な環境で行われます。
XKS プロキシソリューション
AWS KMS 外部キーストア (XKS) を設定する場合、KMS キー階層を新しい外部信頼ルートに置き換えることになります。これで、ルートキーはすべて生成され、ユーザーが提供して操作する HSM 内に保存されます。AWS KMS がデータキーを暗号化または復号化する必要がある場合、リクエストはベンダー固有の HSM に転送されます。
AWS KMS と外部 HSM とのやり取りはすべて、外部キーストアプロキシ (XKS プロキシ)、つまりユーザーが提供し管理するプロキシによって仲介されます。プロキシは、一般的な AWS KMS リクエストをベンダー固有の HSM が理解できる形式に変換します。
XKS が通信する HSM は AWS データセンターにはありません。
お客様にさまざまな外部キーマネージャーオプションを提供するために、AWS KMS では Atos、Entrust、Fortanix、HashiCorp、Salesforce、Thales、および T-Systems などの複数の HSM、キー管理、および統合サービスプロバイダーからのフィードバックを受けて XKS 仕様を開発しました。入手可能性、価格、およびこれらのベンダーのソリューションで XKS を使用する方法については、ベンダーに直接お問い合わせください。
さらに、SoftHSM または PKCS #11 インターフェイスをサポートする任意の HSM で使用できる XKS プロキシのリファレンス実装も提供します。このリファレンス実装の XKS プロキシはコンテナとして実行でき、Rust でビルドされており、今後数週間以内に GitHub 経由で利用できるようになる予定です。
XKS プロキシと HSM の設定が完了すると、対応する外部キーストアリソースを KMS に作成できます。HSM でキーを作成し、そのキーを KMS の外部キーストアリソースにマップします。その後、これらのキーをカスタマーキーをサポートする AWS サービスまたは独自のアプリケーションで使用してデータを暗号化できます。
AWS KMS から XKS プロキシへの各リクエストには、KMS API を呼び出した AWS プリンシパルや KMS キー ARN などのメタデータが含まれます。これにより、AWS アカウントの IAM ポリシーによって既に提供されているもの以外に、XKS プロキシレベルで追加の認証制御レイヤーを作成できます。
XKS プロキシは実質的にユーザーが制御できるキルスイッチです。XKS プロキシを無効にすると、XKS キーを使用する新しい暗号化および復号化操作はすべて機能しなくなります。リソースのいずれかのデータキーをメモリにすでにプロビジョニングしている AWS サービスは、リソースを非アクティブ化するか、サービスキーキャッシュの有効期限が切れるまで機能し続けます。たとえば、Amazon S3 ではバケットキーが有効になっている場合、データキーを数分間キャッシュします。
責任分担の変化
標準的なクラウド運用手順では、クラウドインフラストラクチャを運用状態に維持する責任は AWS にあります。これには、システムのパッチ適用、ネットワークの監視、高可用性を実現するシステムの設計などが含まれますが、これらに限定されません。
XKS を使用することを選択すると、責任分担モデルに根本的な変化が生じます。このモデルでは、XKS プロキシと HSM を運用可能な状態に維持する責任は、ユーザー側にあることになります。セキュリティと可用性が高いだけでなく、予測される数の AWS KMS リクエストに対応できるサイズも必要です。これは、物理設備、電源、冷却システム、ネットワーク、サーバー、オペレーティングシステムなど、関連するすべてのコンポーネントに当てはまります。
ワークロードによっては、クラウドに保管中のデータの暗号化を必要とするサービスを運用する上で、AWS KMS の運用が重要になる場合があります。通常の運用を AWS KMS に依存する一般的なサービスには、Amazon Elastic Block Store (Amazon EBS)、Lambda、Amazon S3、Amazon RDS、DynamoDB などがあります。つまり、ユーザーの責任下にあるインフラストラクチャの一部が利用できない場合や、レイテンシーが高い (通常は 250 ミリ秒以上) 場合、AWS KMS が動作しなくなり、ユーザーが他の AWS サービスに対して行ったリクエストの失敗が連鎖的に発生することになります。EC2 インスタンスの起動、Lambda 関数の呼び出し、S3 からのオブジェクトの保存または取得、RDS または DynamoDB データベース、または管理するインフラストラクチャに保存されている AWS KMS XKS キーに依存するその他のサービスへの接続はできなくなるのです。
このブログ記事の準備中に、XKS に関わったプロダクトマネージャーの 1 人が、「非常にもろい経路を通って、酸素がある場所に向かうトンネルを自分で走っているんだよ」と言っていたことを思い出しました。
この機能は、暗号化キーを AWS データセンターの外部で管理する必要がある規制またはコンプライアンス上の必要性がある場合にのみ使用することをお勧めします。最も重要なワークロードをサポートするルートキーに対してのみ XKS を有効にしてください。すべてのデータ分類カテゴリがルートキーの外部ストレージを必要とするわけではありません。規制要件を満たすため、XKS によるデータセットの保護は最小限に抑え、それ以外の場合は AWS KMS カスタマー管理キーを引き続き完全に管理下で使用してください。
過去に、外部キーストレージがコンプライアンス要件ではないお客様も過去にこの機能を求めていたことがありましたが、XKS のようなソリューションのセキュリティ上の利点が運用コストを上回らないことに気付いた後、すべてのお客様はクラウドベースのキーストレージと使用に関する既存の AWS KMS オプションの 1 つを受け入れることになりました。
何が変わり、何が変わらない？
変更点をまとめてみました。
| 標準的な AWS KMS キーと 同一なもの |
変わっているもの |
|
サポートされている AWS KMS API とキー識別子 (ARN) は同じです。カスタマー管理キーをサポートする AWS サービスは XKS と連携します。 AWS 側からのアクセスを保護し、アクセスを監視する方法に変更はありません。XKS は同じ IAM ポリシーと同じキーポリシーを使用します。API コールは AWS CloudTrail に記録され、AWS CloudWatch には使用状況のメトリックスがあります。 料金は、他の AWS KMS キーと API オペレーションと同じです。 |
XKS は、提供した HSM で管理される非対称キーや HMAC キーをサポートしていません。 これで、暗号化キー操作の可用性、耐久性、パフォーマンス、およびレイテンシーの限界に関する懸念はお客様次第となります。 XKS プロキシレベルでは、別のレイヤーの承認、監査、監視を実装できます。XKS はネットワーク内にあります。 KMS の価格は変わりませんが、HSM の調達や XKS 関連インフラストラクチャの運用状態を維持するための費用は大幅に高くなる可能性があります。 |
オープン仕様
これらの厳しく規制されたワークロード向けに、オープンな相互運用性仕様として XKS を開発しています。すでに述べた主要ベンダーとのコラボレーションだけでなく、以下の資料を含む GitHub リポジトリも開設しました。
- XKS プロキシ API の仕様。ここでは、KMS が XKS プロキシに送信する汎用リクエストの形式と、想定される応答について説明します。どの HSM ベンダーも、この仕様を使用して自社の HSM 用の XKS プロキシを作成することができます。
- 仕様を実装する XKS プロキシのリファレンス実装。HSM ベンダーは、このコードを使用して HSM のプロキシを作成できます。
- XKS プロキシが XKS プロキシ API 仕様の要件に準拠しているかどうかを確認するために使用できる XKS プロキシテストクライアント。
料金と可用性
外部キーストアは AWS KMS に加えて追加費用なしで提供されます。AWS KMS は、キーマテリアルが KMS、CloudHSM、または独自のオンプレミスの HSM のどこに保存されているかにかかわらず、ルートキーごとに 1 か月あたり 1 USD の料金が課金されます。
AWS KMS XKS が現在利用可能なリージョンの全リストについては、テクニカルドキュメントをご覧ください。
XKS が規制要件を満たすのに役立つと思われる場合は、技術文書と XKS FAQ をご覧ください。
原文はこちらです。
からの記事と詳細 ( AWS KMS 外部キーストア (XKS) の発表 | Amazon Web Services - amazon.com )
https://ift.tt/eOJ7F6U
No comments:
Post a Comment