API 安全性的最佳做法

為了協助開發安全的軟體，建議您在開發應用程式時使用下列最佳做法。 如需詳細資訊，請參閱 Microsoft 安全性開發生命週期。

安全性開發生命週期

安全性 開發生命週期 （SDL） 是一個程式，可將一系列以安全性為中心的活動和交付專案對應到軟體開發的每個階段。 這些活動和交付專案包括：

• 開發威脅模型
• 使用程式代碼掃描工具
• 進行程式代碼檢閱和安全性測試

欲了解更多SDL資訊，請參閱Microsoft 安全性開發週期。

威脅模型

進行威脅模型分析可協助您探索程式代碼中潛在的攻擊點。 欲了解更多威脅模型分析資訊，請參閱 Howard， Michael 與 LeBlanc， David [2003]，Writing Secure Code，第二版，ISBN 0-7356-1722-8，Microsoft Press，華盛頓州雷德蒙德。 （某些語言和國家/地區可能無法使用此資源。

服務包和安全性更新

建置和測試環境應該對應到目標使用者基底相同層級的服務包和安全性更新。 我們建議您安裝任何屬於 Microsoft 建置與測試環境的平台或應用程式的最新服務包與安全更新，並鼓勵使用者對完成的應用程式環境也這麼做。 關於服務包與安全更新的更多資訊，請參見 Update Windows 及 Microsoft 安全性。

授權

您應該建立需要最低許可權的應用程式。 使用最少的許可權可降低惡意代碼危害計算機系統的風險。 如需以最低可能的許可權等級執行程式碼的詳細資訊，請參閱 以特殊許可權執行。

密碼學最佳實務

在 Windows 應用程式中實作密碼學時：

• 所有新開發皆請使用 Cryptography API: Next Generation (CNG)。 CryptoAPI 僅為了回溯相容性而維護。
• 為密碼敏捷性而設計，並規劃後量子時代。 不要把硬編碼的演算法識別碼或鍵大小散布在程式碼中——要將它們隔離出來，這樣演算法就能在不重寫的情況下互換。 該平台正轉向 NIST 後量子標準，ML-KEM（FIPS 203）用於金鑰建立，ML-DSA（FIPS 204）用於簽章，因此現在偏好敏捷設計——尤其是對於具有長機密性壽命的資料，以抵抗「先收穫，後解密」的攻擊。
• 偏好認證加密（AEAD）。 使用 AES-GCM 讓加密也能偵測到竄改。 如果你必須使用像 CBC 這類未認證的模式，請搭配獨立的完整性檢查（先加密再存取 MAC）——僅靠機密性無法防止被修改。
• 在 AES-GCM 中，千萬不要重複使用同一金鑰的 nonce（IV）。 在 GCM 中 Nonce 重用是災難性的：它可能暴露認證金鑰並促成訊息偽造。 為每次加密作業產生唯一的 nonce——例如遞增計數器或新的 96 位元隨機值。
• 切勿使用 ECB 區塊密碼模式。 ECB 會分別加密各個區塊，因而洩露明文資料中的模式。
• 千萬不要在原始碼裡硬編碼密碼學金鑰 。 使用 DPAPI 進行本地金鑰保護，或使用 CNG金鑰儲存提供者 用於持久金鑰。
• 使用完機密資料後，請將其從記憶體中清除。 用 SecureZeroMemory 覆蓋金鑰資料、密碼及其他敏感緩衝區。 與 memset不同，編譯器不會將它優化去除。
• AES 鍵長為 256 位元，RSA 為 2048+ 位元（偏好 3072+ 位元），ECDSA 為 256+ 位元。
• 使用 SHA-256 或更強的演算法進行雜湊。 請勿使用MD5或SHA-1作為安全考量。
• 務必檢查密碼學函數的回傳值。 加密呼叫若無聲失敗，可能會將資料儲存在明文中。
• 產生亂數時，請使用 BCryptGenRandom（CNG）— 而非 rand() 或其他非密碼學用途的 PRNG。 傳入 BCRYPT_USE_SYSTEM_PREFERRED_RNG 即可使用系統偏好的產生器，而無須管理演算法控制代碼。

相關資訊

如需最佳做法的詳細資訊，請參閱下列主題。

主題	說明
以特殊權限運行	討論許可權的安全性影響。
避免緩衝區溢位	提供避免緩衝區滿溢的資訊。
控制流程防護 （CFG）	討論記憶體損毀弱點。
建立 DACL	示範如何使用安全性描述元定義語言 （SDDL） 建立任意訪問控制清單 （DACL）。
處理密碼	討論使用密碼的安全性影響。
動態存取控制開發人員可擴充性	針對新動態存取控制解決方案中的一些開發者擴展點進行基本介紹。