非生產數據庫刷新和 TDE 的最佳實踐
假設我們有一個生產系統，其中包含多個使用 TDE 加密的數據庫和一個自行生成的證書。
我們經常需要獲取這個數據庫並更新我們的非生產系統。此過程涉及備份源數據庫、將其恢復到預生產、混淆個人數據和許多其他項目。
這裡的關鍵事實是預生產系統具有生產的加密證書副本
我正在尋找使這個過程更安全的方法——我對預生產環境中的證書不滿意。還有另一種方法可以：
- 永遠不要在任何地方保存未加密的備份
- 不允許將個人數據從生產系統傳播到非生產系統？
正如布倫特指出的那樣：真實數據（即使是最小的部分也是敏感的）不應該在開發/測試中$$ 1 $$系統，即使是暫時的。
如果您確實將真實數據去個性化以用於測試環境，那麼我們在這樣做時會採取一些預防措施：
- 同樣：真實數據根本不應該在開發/測試系統上，即使是暫時的。使用暗示的完整安全措施在已簽署的生產環境中恢復副本和去個性化，然後將經過處理的數據移動到您的其他環境。您可能不希望在您的主要生產設置上出現這種額外的負載$$ 2 $$在這種情況下，該環境中有一個單獨的數據庫伺服器僅用於此任務$$ 3 $$.
- 確保您的流程安全失敗並且失敗嚴重，即使這意味著它經常失敗。如果存在任何新表或列，則讓它崩潰，直到你給它一個新的期望列表，以緩解 Brent 討論的臨時模式更改問題。還要確保任何失敗的步驟都會停止整個過程，這樣任何改變數據的錯誤都會阻止生產的轉移。
最佳實踐$$ 4 $$是根據生產中看到的模式生成測試數據，而不是在不改變數據中的任何模式的情況下進行生產並試圖使其無法辨識。除了消除由於流程錯誤而意外使用真實數據的風險外，您還可以在測試數據中包含生產中尚未發生的邊緣案例（但您知道）。
即使您的去個性化工作有效，您可能會發現，只要對客戶的組織有所了解，任何有一點決心的人都可以部分撤消它。
預生產系統具有生產加密證書的副本
這是你的紅旗。如果您對將生產數據遠離非生產環境的額外費用和/或麻煩提出質疑，請向您上方的任何人揮手。不必要的密鑰副本會大大擴大您的攻擊面。
$$ 1 $$有些人可能會建議 UAT 服務例外，但我還是會考慮生產。
$$ 2 $$除非您服務於一組相當具體的時區，例如您的所有客戶及其絕大多數使用者都在美國，否則在晚上有一個大視窗，在此期間性能影響無關緊要
$$ 3 $$它不一定需要昂貴的“生產級”工具包（高性能驅動器、企業許可的 SQL 和 OS，……），只要這個過程足夠快，因為您不會看到並發的最終使用者活動，但當然仍會涉及成本
$$ 4 $$對於所有最近和未來的開發，我們已經轉移到了這一點——我們只在某些即將退役的遺留服務上使用這樣的生產數據，這些遺留服務在完全過時之前不值得重新裝備。