非本番データベースの更新とTDEに関するベストプラクティス
TDEを使用して暗号化されたいくつかのデータベースと自己生成証明書を備えた本番システムがあるとします。
定期的にこのデータベースを取得し、非本番システムを更新する必要があります。このプロセスには、ソースデータベースのバックアップ、運用前の状態への復元、個人データおよびその他の多くのアイテムの難読化が含まれます。
ここでの重要な事実は本番前のシステムには本番環境からの暗号化証明書のコピーがある
このプロセスをより安全にする方法を探しています-運用前の環境にある証明書に満足していません。別の方法がありますか：
- 暗号化されていないバックアップをどこにも保存しない
- 本番システムから非本番システムへの個人データの伝播を許可しませんか？
ブレントが指摘するように：実際のデータ（たとえその最小部分でもまったく機密である場合）は、開発/テストに含めるべきではありません。[1] 一時的にでも、システム全体。
テスト環境で使用するために実際のデータを個人化解除する場合は、その際にいくつかの注意事項があります。
繰り返しますが、実際のデータはdev/testシステムにあるべきではありません一時的にでも。コピーを復元し、サインオフされた本番環境でデパーソナライズしますthen意味のある完全なセキュリティ対策を使用して、変更されたデータを他の環境に移動します。メインの本番環境でこの余分な負荷をかけたくない場合[2] その場合、このタスクのためだけに、その環境に別個のDBサーバーがあります。[3]。
プロセスが安全に失敗し、ハードに失敗することを確認してくださいそれが頻繁に失敗することを意味する場合でも。新しいテーブルまたは列が存在する場合は、期待される内容の新しいリストを提供するまで、フォールトを作成して、ブレントが一時的なスキーマの変更について説明している問題を軽減します。また、any失敗したステップがプロセス全体を停止することを確認してください。これにより、データを変更するエラーによって本番環境からの移動がブロックされます。
ベストプラクティス[4] 本番環境でテストされたパターンに基づいてテストデータを生成し、データのパターンを変更せずに本番環境を識別不能にすることです。プロセスエラーが原因で実際のデータを誤って使用するリスクを取り除くだけでなく、本番環境で発生していない（まだわかっている）エッジケースをテストデータに含めることができます。
個人化解除が機能しても、クライアントの編成について少し知っていれば、少し決意のある人が部分的に取り消すことができる場合があります。
実動前システムには、実動からの暗号化証明書のコピーがあります
これはあなたの赤い旗です。運用データを非運用環境から遠ざけるための余分な費用や手間を質問する、あなたの上の誰にでもそれを振ってください。不要なキーのコピーにより、攻撃対象領域が大幅に拡大する可能性があります。
[1]いくつかはUATサービスの例外を提案するかもしれませんが、私はとにかくその生産を検討します。
[2]かなり具体的なタイムゾーンのセットを提供しない限り、たとえば、すべての顧客とそのユーザーの大多数は米国にいるため、パフォーマンスの影響が問題にならない夜間に大きなウィンドウを用意します
[3]必ずしも高額な「プロダクショングレード」キット（高性能ドライブ、エンタープライズライセンスのSQLおよびOSなど）である必要はありません。このプロセスが十分に高速であり、並行処理が行われないためです。エンドユーザーのアクティビティですが、もちろんコストがかかります
[4]最近および将来のすべての開発のために移動しました。このような本番データの変更は、完全に廃止される前に再構築する価値がないほどすぐに廃止される特定のレガシーサービスでのみ使用します。
完璧な世界では、個人を特定できるデータを運用環境に保存している場合、データベースを開発環境に復元することはありません。
難読化だけに依存することはできません。たとえば、遅かれ早かれ、誰かが本番環境のテーブルのバックアップコピーを作成しようとしています。変更を加える前に、dbo.Customersテーブルを選択して新しいテーブルに保管し、ドロップするのを忘れます。難読化コードは、個人を特定できるデータを含む新しいランダムテーブルを想定していないため、難読化プロセス後もデータは存在し続けます。
代わりに、開発データが必要な場合は、ゼロから生成します。
（覚えておいてください：あなたは妥協ではなくベストプラクティスを求めました。あなたの回答が「しかし、開発中の本番データが欲しい」の場合、あなたはすでにベストプラクティスを見逃しています。）