短的：由于 GDPR 法規(guī)，從純文本數(shù)據(jù)庫值遷移到完全/完全加密值的最佳方法？解釋器：我剛剛收到一個“提示”，由于 GDPR（歐盟通用數(shù)據(jù)保護條例）法律要求的新“設(shè)計隱私”概念，所有“敏感”信息都需要加密。這包括姓名、地址、社交媒體資料、..我們目前正在為 2000 多個用戶運行一個完整的生產(chǎn)數(shù)據(jù)庫，只能通過我們的 PHP REST API 訪問，該 API 用作所有 Web 和移動應(yīng)用程序的入口點（還沒有第三方開發(fā)人員）。該數(shù)據(jù)庫包含當(dāng)前以純文本形式存儲的電子郵件地址、地址、社交媒體句柄、姓名、IP 地址……（除了基于安全的敏感信息，如密碼、令牌……或用于身份驗證的任何其他值） /鑒別）。我不是這個（開發(fā)方面）的忠實粉絲，因為市長對性能、搜索算法、整個 PHP API 等的影響（感覺就像整個優(yōu)化和“完美設(shè)置數(shù)據(jù)庫”的結(jié)束），但因為它是必需的因為它是額外的保護層，所以我全力以赴。現(xiàn)在，我主要關(guān)心的是......一切都在積極運行，我們不能只是說“好的，關(guān)閉服務(wù)器，加密一切，部署新的 API 版本并重新打開它?！?。此外，我認(rèn)為這種遷移不能“一步一步”完成，所有事情都必須一次完成。如果 API 未準(zhǔn)備好在所有查詢中處理解密，則無法加密數(shù)據(jù)庫值，反之亦然，如果 API 期望所有內(nèi)容都被加密，則數(shù)據(jù)庫不能是純文本。（我很高興我將整個 API 類型的交易作為數(shù)據(jù)庫的唯一入口/讀取點，沒有自定義腳本/連接，所以這是一種解脫）我們正在運行一個功能強大的 VPS 服務(wù)器，因此由于冗余檢查和諸如此類的東西會導(dǎo)致一些性能損失，而且我們也在運行 staging/dev 環(huán)境，所以測試沒有問題。我會讓 MySQL 為每條記錄使用唯一鍵處理 AES，該鍵基于 ID（主鍵）和創(chuàng)建時間戳的組合，例如（這兩個值永遠不會改變）（這可能不是那么聰明萬一“出于某種原因”這個值確實發(fā)生了變化，數(shù)據(jù)已經(jīng)消失了..所以不確定），這樣我的 PHP 應(yīng)用程序在運行查詢時不需要以純文本形式傳遞密鑰，但是又一次， “創(chuàng)建解密密鑰”在查詢?nèi)罩镜戎腥匀豢梢姡虼恕白畎踩钡姆椒ㄊ亲?PHP 應(yīng)用程序加密和解密所有傳入/傳出數(shù)據(jù)，但這會導(dǎo)致無法例如運行“搜索查詢”（除非我在這些特定查詢中發(fā)送密鑰..）。我的問題：怎么會這樣..？我應(yīng)該讓 PHP 處理加密/解密還是更好的 MySQL？當(dāng)記錄被請求時，是否有一種可用的方法可以遷移到加密值？..？我的想法是不觸及任何數(shù)據(jù)庫值（除了更新每個非整數(shù)列以處理當(dāng)前指定的字符數(shù)量的 2-3 倍），這可以在不影響生產(chǎn)的情況下完成。然后逐步更新所有 API 查詢，以檢查所選值是否已加密。當(dāng)一個部分運行正常時，更新該部分的表以加密所有值。作為一個（簡單的）例子MySQL方式；每個 SELECT 查詢：SELECT IF_AES_ENCRYPTED(first_name, AES_DECRYPT(first_name), first_name) AS first_name FROM contacts WHERE id = 1;（或）PHP 方式：檢索數(shù)據(jù)：while ($row = $result->fetch_assoc()) {  $contact->setFirstName((IS_AES_ENCRYPTED($row['first_name']) ? AES_DECRYPT($row['first_name']) : $row['first_name']);}在部署結(jié)束時：UPDATE contacts SET first_name = AES_ENCRYPT(first_name);肯定有辦法做到這一點，但由于我是目前唯一的開發(fā)人員，我只是不確定什么是最實用/最有效的方法，或者我是否過度或考慮不足或不。只是在尋找其他執(zhí)行過這樣的遷移/更新的開發(fā)人員。謝謝，伯特。