縱深防禦 (Defense in Depth)¶
安全性不是一個功能——而是架構本身。交易平台處理的是真實資金和券商憑證。一個漏洞就可能導致未經授權的交易、API 金鑰被盜或帳戶被掏空。4pass 實作了五層縱深防禦架構，確保單一層級的失效不會危及整個系統。每一層都假設上方的層級已經被突破。
五層安全架構¶
攻擊者必須突破全部五層才能觸及交易操作。每一層獨立運作——突破 WAF 不代表能繞過身份驗證，竊取 JWT 也無法解密券商憑證。
安全概覽¶
| 層級 | 防護 | 實作方式 | 涵蓋的攻擊向量 |
|---|---|---|---|
| 網路層 | WAF 規則、速率限制、IP 過濾 | AWS WAFv2 搭配 7 條規則（管理員 IP 限制、TradingView 白名單、登入速率限制、全域速率限制、3 組受管理規則集） | DDoS、暴力破解、SQL 注入、XSS、已知漏洞利用、機器人流量 |
| 傳輸層 | TLS 加密、嚴格傳輸安全、安全 Cookie | ALB + ACM 自動續期憑證、HSTS 1 年加預載入、SameSite=strict |
中間人攻擊 (MITM)、Session 劫持、Cookie 竊取、協定降級 |
| 身份驗證層 | 多重驗證、Session 管理 | JWT (HS256) + Argon2id + Cloudflare Turnstile CAPTCHA + 每個 Session 獨立的 CSRF Token | 撞庫攻擊 (Credential Stuffing)、暴力破解、Session 固定攻擊、CSRF |
| 加密層 | 端對端憑證保護 | RSA-4096 (KMS HSM) + AES-256-GCM + 每位使用者獨立隔離金鑰 | 資料外洩、憑證竊取、內部威脅、記憶體傾印 |
| 應用層 | Webhook 驗證、稽核軌跡、攻擊偵測 | 四層 Webhook 防禦、Redis 重放偵測、即時電子郵件警報 | 重放攻擊 (Replay Attack)、未授權交易、Webhook 偽造 |
關鍵安全特性¶
憑證絕不以明文儲存
券商 API 金鑰和密鑰在寫入資料庫前，會以每位使用者獨立的 AES-256-GCM 金鑰加密。即使資料庫被完整傾印，在沒有對應加密金鑰的情況下也無法還原任何資料。
RSA 私鑰永遠不離開硬體
用於前端到後端加密的 RSA-4096 私鑰由 AWS KMS 管理，儲存在 FIPS 140-2 Level 3 硬體安全模組 (HSM) 中。此金鑰無法被匯出、擷取或以軟體方式存取——所有解密操作都在 HSM 內部完成。
- 每位使用者獨立加密金鑰 —— 攻擊一位使用者的金鑰不會影響其他使用者。每個交易帳戶都有獨一無二的 32 位元組加密金鑰，且此金鑰本身也以主金鑰加密。
- 所有安全事件都可被稽核與告警 ——
audit_logs資料表記錄每一次身份驗證嘗試、Webhook 請求、攻擊偵測和管理操作，包含完整的請求上下文。 - 常數時間比對防止計時攻擊 (Timing Attack) —— 所有密鑰比對（Webhook 密鑰、CSRF Token、API 金鑰）都使用
hmac.compare_digest()以消除計時側通道。 - 基於 Redis 的去重機制偵測重放攻擊 —— Webhook 請求內容的 SHA-256 雜湊值儲存在 Redis 中，搭配 TTL 自動過期，防止擷取的請求被重放。
- 速率限制採故障開放 (Fail-Open) 設計 —— 應用層速率限制使用 Redis 有序集合滑動視窗，但在 Redis 錯誤時採故障開放策略，確保交易操作不會因快取故障而被阻斷。
合規性考量¶
給安全意識評估者
4pass 實作 FIPS 140-2 Level 3 HSM 支援加密、OWASP 推薦的密碼雜湊，以及全面稽核日誌。要解密單一使用者的券商憑證，攻擊者必須同時擁有：(1) 資料庫存取權限、(2) KMS Decrypt IAM 權限、以及 (3) 該帳戶的特定加密金鑰。僅取得其中任何一項不會暴露任何資訊。
| 標準 | 實作方式 |
|---|---|
| FIPS 140-2 Level 3 | AWS KMS HSM 用於 RSA-4096 金鑰儲存及所有非對稱解密操作 |
| OWASP 密碼準則 | 透過 pwdlib 使用 Argon2id（記憶體密集型、抗 GPU 攻擊）——OWASP 推薦的密碼雜湊演算法 |
| 安全標頭 | HSTS（1 年 + includeSubDomains + preload）、CSP、X-Frame-Options SAMEORIGIN、X-Content-Type-Options nosniff、COOP、CORP、Referrer-Policy、Permissions-Policy |
| 稽核軌跡 | 所有狀態變更操作的完整稽核日誌——使用者 ID、IP 位址、User-Agent、請求路徑、成功/失敗、錯誤訊息及任意中繼資料 JSON |
| 靜態加密 | AES-256-GCM 用於憑證儲存，信封加密 (Envelope Encryption) 搭配 KMS 進行金鑰管理 |
| 傳輸加密 | 透過 ALB + ACM 的 TLS 1.2+，加上應用層 RSA+AES 混合加密用於憑證提交 |
| 常數時間比較 | 所有密鑰比較（Webhook 密鑰、CSRF 令牌、API 金鑰）均使用 hmac.compare_digest() 以消除時序旁路攻擊。 |
章節概覽¶
本安全章節詳細涵蓋每一層的內容：
身份驗證¶
JWT Token、Argon2id 密碼、Session 管理、CSRF 防護、Cloudflare Turnstile CAPTCHA、API 金鑰、IP 白名單，以及完整的中介層堆疊。
Webhook 安全¶
TradingView Webhook 的四層強制驗證——唯一 URL Token、時間戳記驗證、常數時間密鑰認證，以及基於 Redis 的重放偵測。