在昨天的文章當中，我們說明了一個資料流程：使用者輸入資料之後，資料儲存在地端，再同步到雲端，之後讓具有查看資格的醫護人員查看。而在系統中，還會有系統管理員，負責確認系統是否正常運作；前面所說的操作紀錄，則會為了稽核需求保存部分資訊。系統提供了身分驗證以及授權，藉由正確管理這兩個部分，資料就可以說已經被正確管理了嗎？

回到我們的流程當中，處理資料可能的點如下：

1. 資料儲存在本地的資料庫中
2. 透過 API 將資料上雲

在這些資料儲存及傳送的位置，資料可能洩漏或遭竊。因此，我們要以授權控制資料存取，並對傳輸中與儲存中的資料採取適當加密。呼叫 API 時，可以使用 HTTPS（以 TLS 保護的 HTTP）傳送資料；其他通訊協定則依其支援方式使用 TLS 保護連線。若資料庫檔案存放於啟用全磁碟加密的裝置，且磁碟遭竊時未解鎖，磁碟加密可降低資料被直接讀取的風險。

加密保護範圍

前面提到，我們可以將硬碟加密來保護資料。那麼我們來想想看：當硬碟已經加密，系統管理員登入之後，是否就能看到裡面的資料？

這要分成兩件事看。全磁碟加密保護的是未解鎖磁碟中的資料；磁碟解鎖後，系統才能依讀取需求解密資料。它不負責判斷某位醫護人員能不能查看某位病人的紀錄。OWASP 也提醒，硬體層加密能降低實體竊取風險，但不能防止主機遭遠端入侵。

紀錄能否被查看，通常由作業系統、資料庫與應用程式各自的權限設計決定。例如，負責維護伺服器的管理員可能需要更新系統或重啟服務，卻不一定需要在醫療 App 中查看病人的血壓紀錄。不過，如果管理員帳號另有作業系統或資料庫的高權限，依系統架構仍可能接觸資料。因此，權限應依工作職責授予必要範圍，並記錄高權限操作。這種作法符合最小權限原則：帳號只取得完成工作所需的權限。

日誌也可能留下健康資料

假設血壓紀錄同步失敗，工程師把整份 API 請求寫進除錯日誌。日誌可能因此留下血壓值、量測時間或存取權杖；送到外部錯誤追蹤平台後，又多一份資料副本。

稽核紀錄和除錯日誌用途不同，記錄欄位也應不同：

欄位須依追查需求決定；若紀錄識別碼能連回病人，也要保護。OWASP 建議避免直接記錄健康資料、密碼、權杖、資料庫連線字串和金鑰；限制日誌讀取及保存期限，並防止未授權修改或刪除。

備份也是資料副本

備份能協助系統復原，也可能包含主資料庫的健康紀錄。NIST 建議定義備份頻率、保存期限、加密與金鑰管理方式，並定期測試完整性和還原能力。備份完成不代表一定能成功還原。

從主資料庫刪除紀錄後，舊備份可能仍保留一段時間；需定義到期刪除方式，並確認還原時不會讓已刪除紀錄意外復現。加密備份也必須保留可用金鑰，否則檔案存在仍無法讀取。

祕密與金鑰要分開管理

資料庫憑證、外部服務 API key 和加密金鑰都屬於祕密，但用途不同：它們分別授予資料庫存取、服務呼叫和資料解密能力。不要把祕密寫進原始碼、版控或日誌；應限制取得權限，並準備輪替與撤銷流程。更換加密金鑰時，也要安排舊資料與備份如何解密或重新加密。金鑰盡量與資料分開存放，可降低單一位置外洩的影響。

沿著資料流完成盤點

盤點表列出示範案例待確認的設計項目：

用合成資料觸發同步錯誤，確認日誌沒有血壓值或權杖；檢查無權限帳號讀不到日誌；還原備份確認金鑰可用。這些檢查只涵蓋指定情境，不代表整體資安驗證。

小結

要安全地處理資料，除了有效的權限管理之外，如本文介紹的，資料儲存與傳送時也需要特別注意。
同時，刪除資料庫的資料也要注意舊備份資料仍有可能恢復資料，以免在資料被刪除之後，還可以被恢復成可用的資料。

另外，在開發、正式環境的金鑰的管理之上，我們需要妥善地維護、保存，並設下最小權限以及權限的授權時間，避免給予太多權限、未撤銷已不需使用的金鑰、憑證。