北京
第一次讀GDPR第32條時，我犯了大多數工程師都會犯的錯——把它當成了法律文件。實際上它更像一份基礎設施技術規范，只是用立法語言寫成了條文。
“適當的技術措施”這個詞組是全文最模糊、也最讓人不安的地方。什么叫“適當”？什么算“技術措施”？誰來判斷你做夠了沒有？合規顧問會給你一份50頁的政策文檔，而審計師會直接跳過文檔，要求看你的數據庫結構。你有沒有證據能證明那些措施確實在運行？這才是審計師真正關心的。
我幫12家SaaS公司落地過第32條的技術控制項，每次都會冒出相同的九個控制項，也每次都會被問到相同的三個審計問題。這份指南就是針對這些反復出現的共性需求：九個你必須實現的技術控制項、每項的具體代碼和命令、以及審計師會揪著你不放的五個問題。
先明確范圍問題：在動手之前你要先搞清楚哪些數據受第32條管轄。GDPR第32條全稱是“處理的安全性”，要求控制者和處理者根據風險等級采取適當的技術和組織措施。但多數團隊漏掉了一個關鍵區別——第32條不是政策清單。政策只是說“我們會加密個人數據”，而證據要求的是“這是帶自動輪換的KMS密鑰、這是應用層加密代碼、這是記錄每次解密嘗試的CloudTrail日志”。審計師要的是證據，不是文檔。
四個核心要求覆蓋了假名化與加密、持續保密性/完整性/可用性/韌性、事件后恢復能力，以及定期測試評估。聽起來很抽象，但翻譯成工程語言就很具體了：你要能證明數據落盤時是加密的、傳輸時是加密的、訪問是有審計記錄的、沒被篡改過。
這套控制項在PostgreSQL上可以直接落地，比如用pgcrypto做字段級加密、配置自動空閑會話斷開、用應用級日志補足CloudTrail覆蓋不到的操作上下文。傳輸安全部分要求mTLS和TLS 1.3，完整性校驗需要你能證明數據從寫入后就沒被動過。
如果你從零開始搭，整套控制項預計需要兩到四周，單個控制項從30分鐘（KMS密鑰配置）到五天（全應用層加密改造）不等。前提條件也不復雜：熟悉PostgreSQL和基礎SQL、了解AWS的KMS/RDS/CloudTrail、能讀Python和Node.js代碼、對GDPR有基本認知。工具上需要PostgreSQL 14+、有IAM管理員權限的AWS賬號、Python 3.8及以上配合cryptography庫，Node.js 16+。至于Vanta或OneTrust這類合規自動化工具，不是必需但建議配合使用，用來收集和整理證據。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
