FoxPro 數據庫連接字符串加密：中間層架構才是正解

誤區分析

嘗試通過代碼混淆、加密配置文件、加殼等手段隱藏客戶端直連數據庫的連接字符串（含 IP、用戶名、密碼）。但：

• 混淆器僅增加逆向難度，無法阻止內存掃描、網絡抓包獲取明文。
• 客戶端直連意味著數據庫端口對外暴露，極易遭受注入、暴力破解、數據竊取。
• 任何客戶端可執行代碼最終都在用戶可控環境運行，絕對安全不存在。

正確架構：三層 + WebService / WebAPI

┌─────────────┐     HTTPS/JSON      ┌──────────────┐     內網/加密連接      ┌────────────┐
│  客戶端      │ ◄─────────────────► │  應用服務器   │ ◄─────────────────────► │  數據庫     │
│  (FoxPro/    │     RESTful API     │  (C#/Java/   │     受信任連接          │  (SQL Server/
│   .NET/其他) │                     │   Node.js)    │                         │  Oracle)    │
└─────────────┘                     └──────────────┘                         └────────────┘

關鍵優勢

1. 憑證隔離：數據庫賬號密碼僅存在於服務器配置，客戶端完全不可見。
2. 權限最小化：服務器 API 只暴露業務所需操作（增刪改查特定表），而非直接 SQL 權限。
3. 審計與限流：服務器層可記錄操作日志、限制頻率、實現行級權限控制。
4. 協議安全：HTTPS + Token (JWT/OAuth2) 防止竄改與重放攻擊。

遷移路徑建議

1. 梳理現有 FoxPro 直接 SQL 調用點，抽象為業務接口（如 GetStudentList, SubmitGrade）。
2. 選擇技術棧構建中間層：ASP.NET Core WebAPI / Spring Boot / Node.js Express 均可。
3. 逐步重寫客戶端調用：將 SQLExec 替換為 HttpClient.GetAsync / PostAsync。
4. 部署階段：服務器與數據庫置於同一 VPC，安全組僅放行服務器 IP 訪問 1433/1521 端口。

補充：若必須客戶端直連

• 使用 Windows 認證 / 集成安全性，避免密碼硬編碼。
• 連接字符串存儲於受保護的配置節，運行時用 DPAPI 解密（ProtectedConfigurationProvider）。
• 強制 SSL 加密連接（Encrypt=True;TrustServerCertificate=False）。