web-dev-qa-db-ja.com

サーバー上のメモリにHSMで保存された対称データ暗号化キー(AES)を保護する

私のプロジェクトでは、対称データ暗号化(AES)を使用して機密のユーザーデータを暗号化する必要があります。 AESキー(DEK)をHSMベースのキー管理サービス(Azure Key Vault/AWS KMS)に保存し、Nodejsサーバーでデータを暗号化/復号化するためのキーを取得します。

私はベストプラクティスについてインターネットを精査しましたが、詳細と説明は、キーをデータベースに保存するか、ハードコードするか、外部に保存するか(つまり、HSM、KMS、env varなど)についてのみです。 )。

以下について十分な説明を見つけることができませんでした。

1)ユーザーごとに異なるAESデータ暗号化キーを作成する必要がありますか?もしそうなら、これの背後にある理由は何ですか?もう1つの複雑さの層ですか?

2)サーバーがハッキングされ、追跡/監視されている場合のように、攻撃に対してキーを安全に保護するにはどうすればよいですか?

3)サーバーの起動時にキーを取得し、サーバーのメモリにキーを格納することをお勧めしますORサーバーがユーザーのデータを暗号化する必要があるたびにキーを取得します?

前もって感謝します。

6
ryd3r

ここでいくつかの質問をしたので、いくつかの回答といくつかの説明を提供します。

AESキー(DEK)をHSMベースのキー管理サービス(Azure Key Vault/AWS KMS)に保存し、Nodejsサーバーでデータを暗号化/復号化するためのキーを取得します。

これは通常、実行したいことではありません。 HSMを使用している場合の目標は、キーがinside HSMにとどまり、決して離れないことです。これを行う一般的な方法の1つは、HSMにキー暗号化キー(KEK)を保存し、別の場所に暗号化されたデータ暗号化キー(DEK)を保存することです。 Azure Key Vaultの場合、これらは取得可能なシークレットである可能性があります。 Amazonにも似たようなものがあると思います。次に、DEKを使用する必要がある場合は、それをHSMに渡し、KEKを使用して復号化してから返します。

1)ユーザーごとに異なるAESデータ暗号化キーを作成する必要がありますか?もしそうなら、これの背後にある理由は何ですか?もう1つの複雑さの層ですか?

はい。その理由は、キーが危険にさらされた場合、すべてのデータが侵害されるわけではなく、このキーで暗号化されたデータだけが侵害されるためです。 (言い換えると、ある顧客のデータです。)さらに、(キーの取得に特に関連する欠陥以外の)多くのアプリケーションの欠陥が排除され、ある顧客が誤って別の顧客のデータにアクセスできるようになります。

2)サーバーがハッキングされ、追跡/監視されている場合のように、攻撃に対してキーを安全に保護するにはどうすればよいですか?

サーバーを保護します。そして、必要なときにだけキーを公開するように、ここにある残りのアドバイスに従ってください。

3)サーバーの起動時にキーを取得し、サーバーのメモリにキーを格納することをお勧めしますORサーバーがユーザーのデータを暗号化する必要があるたびにキーを取得します?

実行する必要がある暗号化または復号化操作を実行するために必要な最小限の時間、キーを公開することをお勧めします。サーバーが起動するたびにそれらを取得することは確かに過度に聞こえます。ユーザーがログインするとき、または実際の暗号化操作を実行する必要があるまで待つなど、それらを取得することが最も理にかなっているかどうかは、あなたの判断次第です。繰り返しになりますが、ウィンドウは小さい方が適切です。

7
Xander

キーが技術的にHSMにある場合、そもそもそれをすぐに取り出すことはできません。

可能であれば、キーを明示的にスローするためにHSMに特別な認証を要求するように要求します。

hSMは、キーを安全に保管するためだけでなく、通常、署名、復号化/暗号化などの暗号化操作も実行できます。

hSMで許可されているかどうかに応じて、キーでのみ操作できる「基本ユーザーレベル」と、実際にキーにアクセスできる「管理レベル」を設定します。

そうすれば、サーバーはそもそもキーを見ることができなくなり、HSMはブラックボックスとして機能します。

0
My1