身分與工作階段
密碼採 PHP 安全單向雜湊；登入後輪替 Session ID，Cookie 使用 HttpOnly、SameSite 與正式環境 Secure 屬性。
已實作應用程式內建控制
部署要求正式環境必須設定
可插拔供應商與儲存介面
可追溯敏感操作稽核
DEFENSE IN DEPTH
六層防護，從登入一路到資料庫
每一層各自降低不同風險，即使單一控制失效，也不會直接越過所有邊界。
多租戶隔離
tenant_id 只從已驗證 Session 取得。核心讀寫同時驗證資料主鍵與租戶，禁止用戶端指定租戶。
後端權限控制
擁有者、主管、組長、執行人員與觀察者的權限會在 Controller 與 Service 重新檢查，不只隱藏畫面。
應用程式防護
所有 POST 驗證 CSRF；資料庫使用 PDO 原生預備陳述式；輸出進行 HTML 編碼並設定 CSP 等安全標頭。
私有附件
附件存放於 Web 無法直接存取的目錄，使用隨機檔名、MIME 實測、大小限制與 SHA-256 完整性紀錄。
稽核與偵測
登入、任務、驗收、積分與設定等敏感操作保留使用者、時間、IP、變更前後內容與操作模組。
ENCRYPTION該雜湊的，不拿來解密。
PASSWORDS單向雜湊 SENSITIVE VALUESAES-256-GCM 認證加密
該雜湊的，不拿來解密。
該加密的，每次使用隨機 nonce。
密碼與可還原的機敏資料採用不同保護方式，避免用錯工具造成假安全。
使用 password_hash() 與 password_verify()，應用程式不保存可還原的明文密碼。
機敏設定可使用 256-bit 金鑰、96-bit 隨機 IV、128-bit 驗證標籤與關聯資料，兼顧機密性與完整性。
algorithmAES-256-GCM
key sourceAPP_KEY / process env
noncerandom_bytes(12)
auth tag128 bits
associated datatenant + purpose
v1
J5d2b8Qm...Z9kP4w==DATA IN TRANSIT從瀏覽器到應用程式，
從瀏覽器到應用程式，
再到資料庫的安全通道。
CSRF Token
租戶隔離
原生預備陳述式
部署說明：應用程式會在 HTTPS 連線時送出 HSTS。資料庫 TLS 支援 CA、用戶端憑證及伺服器憑證驗證，但必須由正式環境提供憑證與環境變數後才會啟用；未設定時不應宣稱資料庫連線已加密。
CONTROL MATRIX
控制措施與目前狀態
公開說明已實作與部署時必須完成的項目，不用模糊的「銀行級」字眼掩蓋細節。
已實作密碼單向雜湊、CSRF、CSP、SQL Injection 防護
已實作tenant_id 隔離、角色權限與操作稽核
已實作AES-256-GCM 機敏資料加密服務
部署要求HTTPS、有效 TLS 憑證、HSTS 與安全 Cookie
部署要求APP_KEY 安全保存、輪替程序與資料庫 TLS CA
可插拔Email、Web Push、物件儲存、金流與 AI 供應商
RESPONSIBLE DISCLOSURE
發現安全問題？請負責任地告訴我們。
請提供可重現步驟、受影響範圍與必要證據。我們不建議在未經授權下存取、下載、修改他人資料，或進行可能影響服務可用性的測試。
security@dinglu-t.com設計參考
數位發展部：資通安全檢測技術規範 任序安全設計參考臺灣主管機關公開的資通安全規範與指引；實際適用義務仍取決於營運主體、服務內容與法令。