企業資料加密與金鑰管理政策怎麼訂？
企業的加密政策要回答四件事：哪些資料必須加密、傳輸與儲存各用什麼方式、允許哪些演算法與金鑰長度，以及金鑰從產生到銷毀由誰管、怎麼管。ISO/IEC 27001:2022 附錄 A 的 8.24「使用密碼技術」，要求的就是把這些規則寫清楚並落實。
很多公司其實已經在加密：網站有 HTTPS、筆電開了 BitLocker、雲端資料庫預設加密。缺的是一份把這些做法串起來的政策，以及金鑰遺失或外洩時的處理方式。下面依序說明訂定步驟，最後附一份可以直接改寫的政策架構；若正在準備 ISO 27001 驗證輔導，這份政策也是稽核時會被調閱的文件。
第一步：先決定哪些資料要加密
要加密的資料，應該由資料分級決定，而不是由「哪個系統剛好有加密功能」決定。這是加密政策的起點。先把資料分成公開、內部、機密、個資等級別，再為每一級訂出傳輸與儲存的最低加密要求，政策才有判斷依據。
| 資料等級 | 例子 | 傳輸 | 儲存 |
|---|---|---|---|
| 公開 | 官網內容、產品型錄 | 對外網站一律 HTTPS | 不要求 |
| 內部 | 內部公告、一般會議紀錄 | 公司網路或加密連線 | 依系統預設 |
| 機密 | 合約、財務報表、原始碼 | 必須加密 | 必須加密，金鑰與資料分開存放 |
| 個資與敏感個資 | 會員資料、員工健康檢查 | 必須加密 | 必須加密，限制可解密人員 |
台灣法規也有明確要求。以數位發展部的《數位經濟相關產業個人資料檔案安全維護管理辦法》第 11 條為例，個人資料有加密必要者，業者應於蒐集、處理或利用時採取適當的加密措施，傳輸時也要依不同傳輸方式採取安全措施。等級怎麼分，可以回到 ISO 27001 風險評鑑 的結果來決定。
第二步：傳輸加密與儲存加密分開規定
傳輸加密保護的是資料在網路上移動的過程，儲存加密保護的是資料靜置在硬碟、資料庫或備份媒體上的狀態。兩者擋的威脅不同。加密政策要分開寫，不能只寫一句「機密資料應加密」。
傳輸部分，美國國家標準與技術研究院（NIST）SP 800-52 第 2 版要求政府系統使用 TLS 1.2，並於 2024 年 1 月 1 日前支援 TLS 1.3，不得使用 TLS 1.0 與 SSL；企業可以直接比照。儲存部分，筆電與隨身碟的全碟加密、資料庫欄位加密、備份檔加密，是稽核最常抽查的三項。
台灣《資通安全責任等級分級辦法》附表十「資通系統防護基準」對防護需求等級「高」的系統，也要求傳輸採用加密機制、使用公開且經國際機構驗證未遭破解的演算法、定期更換加密金鑰或憑證，並為伺服器端的金鑰保管訂定管理規範。即使公司不受資通安全管理法規範，這份基準也很適合拿來當內部標準的參考。
第三步：演算法與金鑰長度怎麼選？
演算法的原則只有一句：使用公開、經國際機構驗證、尚未被破解的演算法，並明列禁止使用的舊演算法。自行設計或來源不明的加密方式，一律不應出現在政策裡。
| 用途 | 建議使用 | 應淘汰 | 依據 |
|---|---|---|---|
| 資料加密 | AES-128、AES-256 | 3TDEA（三金鑰 3DES）加密 | NIST SP 800-131A 第 2 版：3TDEA 加密 2023 年後不允許 |
| 傳輸協定 | TLS 1.2、TLS 1.3 | SSL、TLS 1.0 | NIST SP 800-52 第 2 版 |
| 公開金鑰 | RSA 2048 位元以上、ECC P-256 以上 | RSA 1024 | 至少 112 位元安全強度（SP 800-57、800-131A） |
| 後量子密碼 | 關注 ML-KEM、ML-DSA | — | NIST FIPS 203、204 於 2024 年 8 月發布 |
RSA 2048 屬 112 位元安全強度，目前仍可使用。問題在未來。但 NIST IR 8547 草案提出，112 位元的 RSA 與 ECC 在 2030 年後列為不建議使用，所有 RSA 與 ECC 在 2035 年後全面不允許，改由後量子密碼取代。資料若需要保密十年以上，現在選的演算法就要把這個時程算進去，加密政策的演算法附件也應每年檢視。
第四步：管好金鑰的生命週期
加密的強度最終取決於金鑰：金鑰外洩，加密等於沒做；金鑰遺失，資料就再也打不開。ISO/IEC 27002:2022 對 8.24 的指引，要求金鑰管理涵蓋從產生到銷毀的完整生命週期，並保留每把金鑰的活動紀錄。
- 產生：使用安全的亂數來源，由系統或金鑰管理服務產生，不由人員自行設定。
- 分發與儲存：金鑰與被保護的資料分開存放，存取限授權人員，敏感金鑰放在 HSM 或雲端金鑰管理服務。
- 更換：依 NIST SP 800-57 第 1 部分第 5 版的建議，對稱資料加密金鑰的使用期少於 2 年；憑證到期或人員異動時提前更換。
- 撤銷與事故處理：懷疑金鑰外洩時立即撤銷，並啟動 資安事件處理流程。
- 備份與銷毀：金鑰要有受保護的備份，資料不再需要時，安全銷毀對應的金鑰並留下紀錄。
實務上最常見的缺口是第 5 項。很多公司開了全碟加密，復原金鑰卻只存在員工自己的帳號裡；員工離職或電腦故障時，公司的資料就跟著鎖死。
加密政策範例：可直接改寫的 7 個章節
一份可用的加密政策不需要很長。3 到 5 頁，就能涵蓋 ISO 27001 稽核會看的重點。下表是我們輔導時常用的架構，條文需依公司的資料分級與系統現況調整。
| 章節 | 範例條文 |
|---|---|
| 1. 目的與範圍 | 本政策適用於本公司所有處理機密資料與個人資料之系統、設備及委外服務。 |
| 2. 角色與權責 | 資訊部門負責核定演算法與金鑰管理程序；金鑰保管人負責金鑰之產生、備份與銷毀紀錄。 |
| 3. 加密要求 | 機密及個人資料於傳輸與儲存時均應加密；可攜式設備應啟用全碟加密。 |
| 4. 核准演算法 | 僅得使用附件所列演算法與金鑰長度；附件每年檢視一次。 |
| 5. 金鑰管理 | 金鑰應與資料分開存放；對稱資料加密金鑰使用期不超過 2 年；金鑰外洩時立即撤銷並通報。 |
| 6. 雲端與委外 | 由第三方代管金鑰時，應於契約中約定金鑰保護、存取與終止時之處理方式。 |
| 7. 例外與檢視 | 無法符合本政策之系統，應經核准並記錄補償措施；本政策每年至少檢視一次。 |
這份政策要放進 ISO 27001 的文件體系，並在適用性聲明中說明 8.24 為何適用。稽核員通常會進一步抽查金鑰更換、銷毀紀錄與全碟加密的啟用狀態，政策寫了卻沒有紀錄，會直接被開不符合事項。
加密政策寫完，下一步先盤點哪三件事？
政策核定後，先做三件事：列出所有用到加密的系統與憑證、確認每把重要金鑰的存放位置與保管人、找出仍在使用 TLS 1.0 或舊演算法的系統。這三份清單決定了政策能不能真正落地，也是 資訊安全三要素 中機密性最直接的證據。
若想確認現有的加密與金鑰管理做法能否通過 ISO 27001 稽核，可以 預約一次免費諮詢，由顧問協助檢視。
加密政策常見問題
雲端加密要自己管金鑰嗎？
不一定，取決於資料等級與客戶要求。一般資料使用雲端服務商代管的金鑰即可；機密或受法規約束的資料，建議使用客戶自管金鑰（CMK），由公司控制金鑰的權限、更換與停用。不論哪一種，都應在契約中約定金鑰保護、存取紀錄與服務終止時的處理方式。
筆電要全碟加密嗎？
要。筆電與隨身碟最容易遺失，只要存放公司機密或個人資料，就應啟用全碟加密，例如 Windows 的 BitLocker 或 macOS 的 FileVault。同時要把復原金鑰集中保存在公司控管的系統，不要只留在員工個人帳號，否則員工離職或設備故障時，資料會無法還原。
加密後還要備份金鑰嗎？
要。金鑰遺失等於資料遺失，ISO/IEC 27002:2022 也把金鑰的備份與封存列為金鑰管理的一環。金鑰備份必須和被加密的資料分開存放，並以同等或更高的方式保護；備份檔與金鑰放在同一個位置，一旦外洩就等於沒有加密。
參考資料
- 數位經濟相關產業個人資料檔案安全維護管理辦法 – 第 11 條：個資加密與傳輸安全措施。數位發展部
- 資通安全責任等級分級辦法 – 附表十「資通系統防護基準」：傳輸加密與金鑰保管。數位發展部 · 民國 115 年 1 月 7 日修正
- NIST SP 800-57 Part 1 Rev. 5 – 金鑰管理建議，含金鑰使用期與安全強度對照。NIST · 2020 年 5 月
- NIST SP 800-131A Rev. 2 – 演算法與金鑰長度的轉換時程。NIST · 2019 年 3 月
- NIST SP 800-52 Rev. 2 – TLS 實作指引。NIST · 2019 年 8 月
- NIST IR 8547（初稿） – 轉換至後量子密碼標準的時程草案。NIST · 2024 年 11 月
