欄位級加密：只給會動真錢的祕密

資料庫裡有一類欄位外洩即災難：交易所的 API secret、後台填的 SMTP 密碼。整庫加密太重、也解決不了「DB dump 流出」的場景——我要的是欄位級對稱加密，而且只給真正高敏感的欄位用。

設計上的幾個定案

• AES-256-GCM——authenticated encryption，密文被竄改會在解密時直接炸，不會安靜地回傳垃圾。
• 密文自帶版本前綴（v1:iv:tag:ct）——金鑰輪替日先寫進格式裡。到時候 v2 金鑰上線，舊資料照 v1 解、新資料寫 v2，滾動遷移不停機。
• 金鑰無預設值。CREDENTIAL_ENC_KEY 沒設定時，不碰加密的功能一切照常；真的要加密卻沒金鑰——fail loud，直接拋錯。給加密金鑰一個「開發用預設值」等於在所有沒改設定的部署裡裸奔，這種便利是毒藥。

分層歸屬：加解密只在 application 層

domain 層零框架依賴的原則在這裡受了一次考驗：加密屬於哪一層？答案是 application——祕密欄位以「已加密的不透明字串」進出 domain。領域邏輯不需要知道明文（它又不會拿 API secret 做業務判斷），加解密是「進出系統邊界時的翻譯」，跟 mapper 是同一族的關注點。

範圍紀律：不是所有敏感資料都要加密

密碼用 bcrypt（單向雜湊，不需要解回來）；一般個資靠存取控制與稽核。欄位級加密只給「必須解得回明文、且外洩會直接造成金錢損失」的欄位——加密範圍越大，金鑰管理的爆炸半徑越大，安全設計的第一課是誠實面對威脅模型，而不是把所有東西都鎖起來求心安。