共用方式為

安全性框架：密碼編譯 |緩解

產品/服務 文章
Web 應用程式
資料庫
IoT 裝置
IoT 雲端閘道
Dynamics CRM 移動用戶端
Dynamics CRM Outlook 用戶端
身分識別伺服器

僅使用已核准的對稱區塊加密和金鑰長度

標題 詳細資訊
元件 Web 應用程式
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 N/A
步驟

產品只能使用貴組織中 Crypto Advisor 明確核准的對稱區塊加密和相關聯的密鑰長度。 Microsoft核准的對稱演算法包含下列區塊密碼：

  • 對於新的程式代碼 AES-128、AES-192 和 AES-256 是可接受的
  • 對於現有程式碼的回溯相容性，可接受三金鑰 3DES
  • 對於使用對稱區塊加密的產品：
    • 新程式代碼需要進階加密標準 （AES）
    • 在現有的程式碼中，允許使用三鍵三重數據加密標準（3DES）以確保向後相容性。
    • 所有其他區塊加密，包括 RC2、DES、2 Key 3DES、DESX 和 Skipjack，只能用於解密舊數據，而且若用於加密，則必須取代
  • 針對對稱區塊加密演算法，需要最小密鑰長度 128 位。 建議用於新程式代碼的唯一區塊加密演算法是 AES（AES-128、AES-192 和 AES-256 都是可接受的）
  • 如果已在現有程序代碼中使用，則目前可接受三鍵 3DES;建議轉換至 AES。 DES、DESX、RC2 和 Skipjack 不再被視為安全。 為了回溯相容性，這些演算法只能用於解密現有數據，而且應該使用建議的區塊加密重新加密數據

請注意，所有對稱區塊加密都必須與已核准的加密模式搭配使用，這需要使用適當的初始化向量 （IV）。 適當的IV，通常是隨機數，絕不是常數值

在貴組織的密碼編譯委員會檢閱之後，可能會允許使用舊版或其他未經核准的加密演算法和較小的密鑰長度來讀取現有數據（而不是寫入新數據）。 不過，您必須針對這項需求申請例外。 此外，在企業部署中，當弱式加密用來讀取數據時，產品應考慮警告系統管理員。 這類警告應具有說明性和可作性。 在某些情況下，群組原則可能會控管弱加密技術的使用。

為了實現受控密碼編譯靈活性所允許的 .NET 演算法 (依偏好順序)

  • AesCng （FIPS 相容）
  • AuthenticatedAesCng （FIPS 兼容）
  • AESCryptoServiceProvider （FIPS 相容）
  • AESManaged （不符合 FIPS 規範）

請注意，這些演算法都無法透過 SymmetricAlgorithm.Create 或 CryptoConfig.CreateFromName 方法來指定，而不需變更 machine.config 檔案。 此外，請注意，在 .NET 3.5 之前的 .NET 版本中，AES 的名稱為 RijndaelManaged，而 AesCng 和 AuthenticatedAesCng 可以透過 CodePlex 取得，但需要基礎 OS 中的 CNG。

針對對稱加密使用已核准的區塊加密模式和初始化向量

標題 詳細資訊
元件 Web 應用程式
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 N/A
步驟 所有對稱區塊加密都必須與已核准的對稱加密模式搭配使用。 唯一核准的模式是 CBC 和 CTS。 特別是，應避免電子代碼簿（ECB）的運作模式：使用 ECB 需要貴組織的密碼編譯委員會審查。 貴組織的加密委員會必須檢閱 OFB、CFB、CTR、CCM 和 GCM 或任何其他加密模式的所有使用方式。 在 CTR 等「串流加密模式」中重複使用相同的初始化向量 （IV），可能會顯示加密的數據。 所有對稱區塊加密也必須搭配適當的初始化向量 （IV） 使用。 適當的 IV 是密碼編譯強式隨機數，絕不是常數值。

使用核准的非對稱演算法、金鑰長度和填補

標題 詳細資訊
元件 Web 應用程式
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 N/A
步驟

使用禁用的密碼編譯演算法會對產品安全性造成重大風險，必須避免。 產品只能使用貴組織的加密委員會明確核准的加密演算法和相關的密鑰長度及填充。

  • RSA - 可用於加密、金鑰交換和簽章。 RSA 加密只能使用 OAEP 或 RSA-KEM 填補模式。 現有的程式碼可能僅為相容性而使用 PKCS #1 v1.5 填充模式。 明確禁止使用 null 填補。 新程式碼需要密鑰>= 2048 位元。 在經過貴組織的密碼編譯委員會檢閱之後，現有程式碼也可支援 < 2048 位元的金鑰，但只能用於實現回溯相容性。 密鑰 < 1024 位只能用於解密/驗證舊數據，而且若用於加密或簽署作業，則必須取代密鑰 1024 位
  • ECDSA - 只能用於簽章。 新的程式碼需要金鑰位元數 >= 256 的 ECDSA。 ECDSA 型簽章必須使用三個 NIST 核准曲線之一（P-256、P-384 或 P521）。 經過徹底分析的曲線只有在與貴組織的密碼編譯委員會進行檢閱之後才能使用。
  • ECDH - 只能用於金鑰交換。 新程式需要具有 >=256 位密鑰的 ECDH。 ECDH 型密鑰交換必須使用三個 NIST 核准的曲線之一（P-256、P-384 或 P521）。 經過徹底分析的曲線只有在與貴組織的密碼編譯委員會進行檢閱之後才能使用。
  • DSA- 在經過貴組織的密碼編譯委員會審核並核准之後即可接受。 請連絡您的安全性顧問來安排貴組織的密碼編譯委員會進行審核。 如果您已核准使用 DSA，請注意，您必須禁止使用長度小於 2048 位的密鑰。 CNG 支援從 Windows 8 起的 2048 位和更大的密鑰長度。
  • Diffie-Hellman- 只能用於會話密鑰管理。 新程式代碼需要金鑰長度 >= 2048 位。 在經過貴組織的密碼編譯委員會審核之後，現有程式碼也可支援長度 < 2048 位元的金鑰，但只能用於實現回溯相容性。 無法使用 1024 位元的金鑰。

    使用已核准的隨機數產生器

    標題 詳細資訊
    元件 Web 應用程式
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 N/A
    步驟

    產品必須使用已核准的隨機數產生器。 因此，虛擬隨機函式 (例如 C 執行階段函式 rand)、.NET Framework 類別 System.Random 或系統函式 (例如 GetTickCount) 絕不會用於這類程式碼中。 禁止使用雙橢圓曲線隨機數產生器 （DUAL_EC_DRBG） 演算法

    • CNG- BCryptGenRandom (建議使用 BCRYPT_USE_SYSTEM_PREFERRED_RNG 旗標，除非呼叫端可能執行於任何大於 0 的 IRQL [也就是 PASSIVE_LEVEL])
    • CAPI- cryptGenRandom
    • Win32/64- RtlGenRandom （新的實作應使用 BCryptGenRandom 或 CryptGenRandom） * rand_s * SystemPrng （核心模式）
    • 。NET- RNGCryptoServiceProvider 或 RNGCng
    • Windows 市集應用程式- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom 或 .GenerateRandomNumber
    • Apple OS X （10.7+）/iOS （2.0+）- int SecRandomCopyBytes （SecRandomRef 隨機，size_t計數，uint8_t *位元節）
    • Apple OS X （<10.7）- 使用 /dev/random 來擷取隨機數位
    • Java（包括 Google Android Java 程式代碼）- java.security.SecureRandom 類別。 請注意，在 Android 4.3 (Jelly Bean) 中，開發人員必須遵循 Android 建議的因應措施，並將其應用程式更新為使用來自 /dev/urandom 或 /dev/random 的 Entropy 明確初始化 PRNG

    請勿使用對稱數據流加密

    標題 詳細資訊
    元件 Web 應用程式
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 N/A
    步驟 對稱數據流加密，例如 RC4，不得使用。 產品應該使用區塊加密，特別是密鑰長度至少為128位的AES，而不是對稱數據流加密。

    使用已核准的 MAC/HMAC/金鑰哈希演算法

    標題 詳細資訊
    元件 Web 應用程式
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 N/A
    步驟

    產品只能使用核准的訊息驗證碼 （MAC） 或哈希式訊息驗證碼 （HMAC） 演算法。

    郵件驗證碼 （MAC） 是附加至郵件的一部分資訊，可讓收件者使用秘密密鑰來驗證寄件者的真實性和郵件的完整性。 只要所有基礎哈希或對稱加密演算法也都經過核准，才能使用哈希式 MAC（HMAC） 或 區塊式加密式 MAC ;目前這包括 HMAC-SHA2 函式（HMAC-SHA256、HMAC-SHA384 和 HMAC-SHA512），以及 CMAC/OMAC1 和 OMAC2 區塊加密式 MAC（這些以 AES 為基礎）。

    使用 HMAC-SHA1 可能會因平臺相容性而被允許，但您需要為此流程提出例外申請，並接受貴組織的加密檢閱。 不允許將 HMAC 截斷為小於 128 位。 未核准使用客戶方法來哈希密鑰和數據，且必須先經過貴組織的 Crypto Board 檢閱，才能使用。

    僅使用核准的密碼編譯哈希函式

    標題 詳細資訊
    元件 Web 應用程式
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 N/A
    步驟

    產品必須使用 SHA-2 系列哈希演算法（SHA256、SHA384 和 SHA512）。 如果需要較短的哈希，例如128位的輸出長度，以符合以較短的 MD5 哈希設計的數據結構，產品小組可能會截斷其中一個SHA2哈希（通常是SHA256）。 請注意，SHA384 是 SHA512 的截斷版本。 不允許基於安全性目的截斷密碼編譯哈希到小於128位。 新的程式代碼不得使用 MD2、MD4、MD5、SHA-0、SHA-1 或 RIPEMD 哈希演算法。 這些演算法在計算時可能會發生雜湊衝突，而結果便是打斷演算法。

    .NET 允許的哈希演算法，用於管理加密靈活性（依優先順序排列）：

    • SHA512Cng （FIPS 相容）
    • SHA384Cng （FIPS 相容）
    • SHA256Cng （FIPS 相容）
    • SHA512Managed （不符合 FIPS 規範） （在 HashAlgorithm.Create 或 CryptoConfig.CreateFromName 的呼叫中使用 SHA512 作為演算法名稱）
    • SHA384Managed （不符合 FIPS 規範） （在呼叫 HashAlgorithm.Create 或 CryptoConfig.CreateFromName 時，使用 SHA384 作為演算法名稱）
    • SHA256Managed （不符合 FIPS 規範） （在 HashAlgorithm.Create 或 CryptoConfig.CreateFromName 的呼叫中使用 SHA256 作為演算法名稱）
    • SHA512CryptoServiceProvider （FIPS 相容）
    • SHA256CryptoServiceProvider （FIPS 相容）
    • SHA384CryptoServiceProvider （FIPS 相容）

    使用強式加密演算法來加密資料庫中的數據

    標題 詳細資訊
    元件 資料庫
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 選擇加密演算法
    步驟 加密演算法會定義未經授權的使用者無法輕易反轉的數據轉換。 SQL Server 可讓系統管理員和開發人員從數種演算法中選擇，包括 DES、Triple DES、TRIPLE_DES_3KEY、RC2、RC4、128 位 RC4、DESX、128 位 AES、192 位 AES 和 256 位 AES

    SSIS 套件應加密並經過數字簽署

    標題 詳細資訊
    元件 資料庫
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 識別具備數位簽名的套件來源，威脅和弱點緩解（整合服務）
    步驟 套件的來源是建立封裝的個人或組織。 從未知或不受信任的來源執行套件可能會有風險。 若要防止未經授權竄改 SSIS 套件，應使用數字簽名。 此外，為了確保儲存/傳輸期間套件的機密性，必須加密 SSIS 套件

    在重要的資料庫安全性實體中新增數位簽章

    標題 詳細資訊
    元件 資料庫
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 新增簽名（Transact-SQL）
    步驟 在必須驗證重要資料庫安全性實體完整性的情況下，應該使用數字簽名。 資料庫安全性實體，例如預存程式、函式、元件或觸發程式，都可以以數位方式簽署。 以下是當這很有用的範例：假設ISV（獨立軟體廠商）已為提供給其中一個客戶的軟體提供支援。 在進行支援之前，ISV 會想要確保資料庫中的安全元素未被錯誤或惡意行為竄改。 如果安全性實體經過數字簽署，ISV 可以驗證其數位簽名並驗證其完整性。

    使用 SQL Server EKM 來保護加密金鑰

    標題 詳細資訊
    元件 資料庫
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 SQL Server 可延伸金鑰管理 （EKM）、 使用 Azure Key Vault 的可延伸金鑰管理 （SQL Server）
    步驟 SQL Server 可延伸金鑰管理可讓加密金鑰保護資料庫檔案儲存在現成的裝置中，例如智慧卡、USB 裝置或 EKM/HSM 模組。 這也會啟用資料庫管理員的數據保護（系統管理員群組的成員除外）。 數據可以使用只有資料庫用戶可存取外部 EKM/HSM 模組的加密密鑰來加密。

    如果不應向資料庫引擎顯示加密密鑰，請使用 AlwaysEncrypted 功能

    標題 詳細資訊
    元件 資料庫
    SDL 階段 建造
    適用的技術 SQL Azure、OnPrem
    屬性 SQL 版本 - V12、MsSQL2016
    引用 Always Encrypted （Database Engine）
    步驟 Always Encrypted 是一項旨在保護敏感數據的功能，例如信用卡號碼或國家/地區標識符（例如美國社會安全號碼），儲存在 Azure SQL Database 或 SQL Server 資料庫中。 Always Encrypted 可讓用戶端加密用戶端應用程式內的敏感數據，且永遠不會向 Database Engine （SQL Database 或 SQL Server） 顯示加密密鑰。 因此，Always Encrypted 會在擁有數據（且可檢視數據）和管理數據的人員（但不應該存取權）之間提供分隔。

    安全地將密碼編譯金鑰儲存在IoT裝置上

    標題 詳細資訊
    元件 IoT 裝置
    SDL 階段 建造
    適用的技術 一般的
    屬性 裝置 OS - Windows IoT 核心版、裝置連線能力 - Azure IoT 裝置 SDK
    引用 Windows IoT 核心版上的 TPM、 在 Windows IoT 核心版上設定 TPM、 Azure IoT 裝置 SDK TPM
    步驟 在受硬體保護的儲存空間中安全地儲存對稱金鑰或憑證私鑰，例如 TPM 或智能卡晶片。 Windows 10 IoT 核心版支援 TPM 的使用者，而且有數個相容的 TPM 可供使用：離散 TPM （dTPM）。 建議您使用韌體或離散 TPM。 軟體 TPM 只能用於開發和測試用途。 一旦 TPM 可供使用，且密鑰已佈建於其中，就應該撰寫產生令牌的程式代碼，而不需將其中的任何敏感性資訊硬式編碼。

    範例

    TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM 
string hubUri = myDevice.GetHostName(); 
string deviceId = myDevice.GetDeviceId(); 
string sasToken = myDevice.GetSASToken(); 

var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);

    如所見，裝置主鍵不存在於程序代碼中。 而是儲存在插槽 0 的 TPM 中。 TPM 裝置會產生短期 SAS 權杖，然後用來連線到 IoT 中樞。

    產生長度足以向IoT中樞驗證的隨機對稱金鑰

    標題 詳細資訊
    元件 IoT 雲端閘道
    SDL 階段 建造
    適用的技術 一般的
    屬性 閘道選擇 - Azure IoT 中樞
    引用 N/A
    步驟 IoT 中樞包含裝置身分識別登錄，而在佈建裝置時，會自動產生隨機的對稱密鑰。 建議您使用 Azure IoT 中樞身分識別登錄的這項功能來產生用於驗證的金鑰。 IoT 中樞也允許在建立裝置時指定金鑰。 如果在裝置佈建期間於 IoT 中樞外部產生金鑰，建議您建立隨機對稱金鑰或至少 256 位。

    確保裝置管理原則的到位，要求使用 PIN 並允許遠端抹除

    標題 詳細資訊
    元件 Dynamics CRM 移動用戶端
    SDL 階段 部署
    適用的技術 一般的
    屬性 N/A
    引用 N/A
    步驟 確保裝置管理原則的到位，要求使用 PIN 並允許遠端抹除

    確定裝置管理原則已就緒，需要 PIN/密碼/自動鎖定並加密所有數據（例如 BitLocker）

    標題 詳細資訊
    元件 Dynamics CRM Outlook 用戶端
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 N/A
    步驟 確定裝置管理原則已就緒，需要 PIN/密碼/自動鎖定並加密所有數據（例如 BitLocker）

    使用身分識別伺服器時，請確定簽署金鑰已變換

    標題 詳細資訊
    元件 身分識別伺服器
    SDL 階段 部署
    適用的技術 一般的
    屬性 N/A
    引用 N/A
    步驟 使用身分識別伺服器時，請確定簽署金鑰已變換。 參考一節中的鏈接說明應該如何規劃此專案，而不會對依賴 Identity Server 的應用程式造成中斷。

    確定身分識別伺服器中使用密碼編譯強式用戶端標識碼、客戶端密碼

    標題 詳細資訊
    元件 身分識別伺服器
    SDL 階段 建造
    適用的技術 一般的
    屬性 N/A
    引用 N/A
    步驟

    請確定身分識別伺服器中使用密碼編譯強式用戶端標識碼、客戶端密碼。 產生用戶端識別碼和秘密時，應該使用下列指導方針：

    • 產生隨機 GUID 做為用戶端識別碼
    • 生成加密隨機的 256 位密鑰作為密秘
    • Last updated on