現在、Webアプリケーションの暗号化にAES 256を使用しており、セキュリティポリシーコンテキストでは、暗号化キーを数か月に1回交換する必要があると指定されています。
それが発生した場合、特にどのような処理を行う必要がありますか?オンラインで読んだところ、既存の暗号化されたデータを古いキーで復号化してから、新しいキーで再び復号化する必要があることが示唆されています。私のWebアプリケーションは大量のデータを処理する必要があり、上記のプロセスにはかなり時間がかかるため、このアプローチは私にとって理想的なソリューションではない可能性があります。これを回避するより良い解決策はありますか?
ありがとう
暗号化キーには暗号化期間を設定できます。この期間が過ぎると、それらのキーは暗号化に引き続き使用されません。これは、セキュリティポリシー、ビジネスを離れるキーコンポーネントを知っている個人、暗号化キーの侵害の疑いなどが原因である可能性があります。
多くの場合、企業はX期間の暗号化に暗号化キー(これをkeyAと呼びます)を使用します。その期間の後、新しい暗号化キー(これをkeyBと呼びます)が生成され、暗号化に使用されます。暗号化されたデータは、暗号化されたキーへの参照とともに保存されるため、アプリケーションは復号化に使用するキーを認識します。上記の名前を使用すると、keyAは新しいデータの暗号化には無効と見なされますが、そのキーを使用して暗号化されたデータの復号化に使用できます。 KeyBは現在、データの暗号化と復号化の両方に有効です。
データはおそらく定義されたデータ保持期間に従って保存されるため、レガシーデータが削除されると、データの復号化に不要になる古いキーも削除される可能性があります。
投稿ごとに、大量のデータの復号化と再暗号化には時間がかかり、処理にコストがかかる可能性があります。
オンデマンドで復号化暗号化を行わないのはなぜですか?
それがあなたのケースでうまくいくかどうかはわかりませんが、ここに私の考えがあります。データは元々プレーンデータとしてWebアプリケーションに送信されますよね?次に、データを暗号化して保存します。次のシナリオを想定してみましょう
これにより、格納されているすべてのデータに対して巨大な暗号化/復号化プロセスを同時に実行する必要がなくなります。
別のオプション
最後に、このリクエストの背後にあるセキュリティ要件は何ですか。集中的な復号化/暗号化を回避するためのより良いソリューションを提案できる場合があります
データを復号化および再暗号化するという比較的困難なタスクを実行するのは、1つの理由だけです。暗号鍵が危険にさらされていると信じているが、データはそうではないまたはその逆です。
データとキーの両方が侵害された場合。あなたは乾杯です。鍵の交換の量はあなたを救うことはありません。
キーまたはデータのいずれかが侵害された場合、攻撃者がパズルの残りの半分をどうにか入手できるように、キーを変更してデータを再暗号化することは理にかなっています。ただし、これは「念のため、30日ごとにパスワードを変更してください」のようなにおいがします。
復号化と再暗号化の1つのリスク、つまりプロセスの途中での失敗について説明しました。新しいメディアに暗号化することにより、そのリスクを軽減します。ただし、もちろん、古いメディアは残り、古いキーで暗号化されます。プロセスが完了したら、古いデータと古いキーの両方を酸、火、強力な磁石で破壊する必要があります。そうしないと、リスクを軽減することはできません。これがオンラインシステムの場合、再暗号化プロセス中にダウンタイムまたは読み取り専用期間が発生します。他のリスクがあるかもしれません。
別の回答で提案されているように、暗号鍵を何らかの方法でローテーションして、いつでもデータの一部が古い鍵で暗号化され、一部が新しい鍵で暗号化される場合、データの一部は侵害の際に公開されます。
Gillesがすでに書いているように、これはセキュリティシアターです。ポリシーの責任者は誰でも、ポリシーの実装によって軽減されるリスクについて説明する必要があります。次に、コストと導入されたnewリスクを調べて、情報に基づいた決定を行うことができます。