措施6-1. 傳輸之機密性與完整性
措施6-2. 資料儲存之安全
這個構面應該是6-1比較需要提供符合技術面考量的設計實施方式之佐證，所以我們以此舉例建議系統開發人員提供到什麼程度的陳述。
傳輸機密性與完整性管理SOP)》
確保資通系統在傳輸過程中的機密性與完整性，避免未經授權的資訊揭露和不當修改，並遵守資通系統防護基準的6-1要求。
此文件適用於所有涉及機敏資料的系統傳輸過程，無論是內部系統傳輸、外部系統對接，還是遠端存取作業。
(1) 加密機制實施方案
產出目標：明確描述系統內部的加密機制，包括採用的加密協定、傳輸方式、部署方案及相應的控制措施。
重點內容：
採用的傳輸協定（如HTTPS、TLS 1.2或以上版本）
強制加密的配置文件範例（如HTTP Strict Transport Security, HSTS）
加密傳輸的部署步驟及測試報告
(2) 加密算法與密碼學實施指南
產出目標：定義資通系統中允許使用的加密算法及其具體配置方式。
重點內容：
國際標準演算法（如AES、RSA、SHA-256等）
演算法的金鑰長度要求（如AES-256、RSA-2048等）
不建議的加密方法和演算法清單（如MD5、SHA-1等）
(3) 金鑰管理操作手冊
產出目標：規範金鑰的產生、儲存、管理及銷毀的操作流程。
重點內容：
金鑰生成與管理系統的操作指引（如AWS KMS、Azure Key Vault的使用說明）
金鑰儲存的加密方案（如HSM、KMS等）
金鑰更換週期及自動化更換腳本範例
(4) 憑證管理操作手冊
產出目標：規範HTTPS憑證的申請、部署、更換及到期提醒流程。
重點內容：
憑證申請與安裝步驟
憑證續約提醒系統的設計（如設置自動提醒通知）
憑證撤銷（CRL）及OCSP驗證的實施方案
(5) 系統安全標準作業程序（SOP）
產出目標：將技術操作流程文件化，提供清晰的指導，確保運維人員按照標準程序進行操作。
重點內容：
加密協定的配置操作步驟
定期金鑰更換的操作流程
不符合要求的舊協定（如SSL、TLS 1.0和1.1）禁用指引
(1) 加密機制管理
作業步驟：
確認系統內傳輸的數據類型（例如機敏數據、用戶憑證、API請求）。
確認採用的加密協定，僅允許使用TLS 1.2或以上版本。
檢查伺服器是否啟用了HSTS（HTTP Strict Transport Security）。
禁止使用SSL、TLS 1.0及TLS 1.1。
(2) 加密算法與金鑰管理
作業步驟：
僅允許使用AES-256、RSA-2048及SHA-256等國際標準演算法。
禁止使用不安全的加密算法，如MD5、SHA-1等。
每12個月更換金鑰，並使用版本控制記錄金鑰的使用狀態。
(3) 憑證管理
作業步驟：
申請公開信任的憑證（例如Let's Encrypt、DigiCert）。
設定自動提醒機制，於憑證到期前30天發送通知給運維人員。
定期檢查網站的SSL/TLS憑證，並確保未過期及未遭撤銷（CRL和OCSP驗證）。
(4) 金鑰保管規範
作業步驟：
金鑰需儲存在硬體安全模組（HSM）中，並加以限制訪問。
嚴禁將金鑰與加密資料儲存在同一伺服器中。
每12個月對金鑰存儲的安全性進行審查，並形成審查報告。
將金鑰變更及異常情境記錄於操作日誌中。
(1) 加密協定的技術要求
僅允許TLS 1.2及TLS 1.3協定，禁用TLS 1.0、1.1及SSL。
伺服器必須啟用HSTS，強制所有HTTP請求自動跳轉至HTTPS。
(2) 金鑰長度和演算法的技術要求
AES加密必須使用256位金鑰，RSA加密必須使用2048位或更高的金鑰長度。
伺服器和數據庫的密鑰生成工具（如OpenSSL）須符合如下指令：
openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
(3) 憑證更新的技術實作
系統需實現自動檢測到期憑證並通知運維人員，使用cron任務發送到期通知：
0 0 * * * /usr/bin/ssl-checker.sh
嚴禁使用不安全的協定（如TLS 1.0、1.1）及不安全的加密算法（如SHA-1、MD5）。
禁止開發人員自行設計加密演算法，僅允許採用國際機構驗證之演算法。
將敏感數據的加密/解密操作與業務邏輯分離，避免不必要的暴露風險。
以上範例是詢問ChatGPT後再稍加整理而成的，其中或許有部分不容易落實，或者在專案執行時某些考量下不夠充分，所以在參考引用這些內容仍應仔細斟酌合宜性。