使用英语阅读

通过

安全帧：加密 |缓解

  • 项目
  • 2025/05/16
产品/服务 文章
Web 应用程序
数据库
IoT 设备
IoT 云网关
Dynamics CRM 移动客户端
Dynamics CRM Outlook 客户端
标识服务器

仅使用批准的对称块密码和密钥长度

标题 详细信息
组件 Web 应用程序
SDL 阶段 建造
适用的技术 常规
属性 无
参考 无
步骤

产品须仅使用那些已由您所在组织的加密顾问显式批准的对称块密码及其关联的密钥长度。 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 阶段 建造
适用的技术 常规
属性 无
参考 无
步骤 所有对称块密码都必须与批准的对称密码模式一起使用。 唯一批准的模式是 CBC 和 CTS。 特别是，应避免使用电子代码簿（ECB）操作模式；使用 ECB 需要组织的加密委员会审查。 组织加密委员会必须审查 OFB、CFB、CTR、CCM 和 GCM 或任何其他加密模式的所有使用情况。 在“流式加密模式”（如 CTR）中使用相同的初始化向量（IV）可能会导致加密数据被揭示。 所有对称块密码也必须与适当的初始化向量（IV）一起使用。 适当的 IV 是一个加密强、随机数，永远不会是常量值。

使用批准的非对称算法、密钥长度和填充

标题 详细信息
组件 Web 应用程序
SDL 阶段 建造
适用的技术 常规
属性 无
参考 无
步骤

使用受禁加密算法对产品安全性带来了重大风险，必须避免。 产品必须仅使用那些已由您的组织的加密委员会明确批准的加密算法以及关联的密钥长度和填充。

  • 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 位的密钥。 从 Windows 8 起，CNG 支持 2048 位和更大的密钥长度。
  • Diffie-Hellman- 只能用于会话密钥管理。 新代码需要密钥长度 >= 2048 位。 在组织的加密委员会审查后，现有代码可能仅支持 2048 位的密钥长度 < 以实现向后兼容性。 不能使用密钥 < 1024 位。

    使用批准的随机数生成器

    标题 详细信息
    组件 Web 应用程序
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 无
    步骤

    产品必须使用批准的随机数生成器。 伪随机函数（如 C 运行时函数 rand、.NET Framework 类 System.Random）或 GetTickCount 等系统函数必须不能用于此类代码。 禁止使用双椭圆曲线随机数生成器 （DUAL_EC_DRBG） 算法

    • CNG- BCryptGenRandom（除非调用方能够以大于 0 [即 PASSIVE_LEVEL] 的任何 IRQL 运行，否则建议使用 BCRYPT_USE_SYSTEM_PREFERRED_RNG 标志）
    • 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 random， size_t count， uint8_t *bytes）
    • Apple OS X （<10.7）- 使用 /dev/random 检索随机数
    • Java（包括 Google Android Java 代码）- java.security.SecureRandom 类。 请注意，对于 Android 4.3（Jelly Bean），开发人员必须遵循 Android 推荐的解决方法，并更新他们的应用程序，以显式地利用 /dev/urandom 或 /dev/random 中的熵来初始化 PRNG。

    请勿使用对称流密码

    标题 详细信息
    组件 Web 应用程序
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 无
    步骤 不得使用对称流密码（如 RC4）。 产品应使用块密码，尤其是密钥长度至少为 128 位的 AES，而不是对称流密码。

    使用批准的 MAC/HMAC/键控哈希算法

    标题 详细信息
    组件 Web 应用程序
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 无
    步骤

    产品只能使用批准的消息身份验证代码（MAC）或基于哈希的消息身份验证代码（HMAC）算法。

    消息身份验证代码（MAC）是附加到邮件的一段信息，允许其收件人使用密钥验证发件人的真实性和邮件的完整性。 只要所有基础哈希或对称加密算法也都获准使用基于哈希的 MAC（HMAC）或 基于块密码的 MAC ：目前，这包括 HMAC-SHA2 函数（HMAC-SHA256、HMAC-SHA384 和 HMAC-SHA512）和 CMAC/OMAC1 和基于 OMAC2 块密码的 MAC（这些基于 AES）。

    出于平台兼容性，可能允许使用 HMAC-SHA1，但需要提交例外申请，并接受组织的加密审查。 不允许将 HMAC 截断为小于 128 位。 使用客户方法对密钥和数据进行哈希处理未获得批准，并且必须在使用之前接受组织的加密委员会评审。

    仅使用批准的加密哈希函数

    标题 详细信息
    组件 Web 应用程序
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 无
    步骤

    产品必须使用 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 阶段 建造
    适用的技术 常规
    属性 无
    参考 选择加密算法
    步骤 加密算法定义未经授权的用户无法轻松逆转的数据转换。 SQL Server 允许管理员和开发人员从多个算法中进行选择，包括 DES、Triple DES、TRIPLE_DES_3KEY、RC2、RC4、128 位 RC4、DESX、128 位 AES、192 位 AES 和 256 位 AES

    应对 SSIS 包进行加密和数字签名

    标题 详细信息
    组件 数据库
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 使用数字签名标识包源、威胁和漏洞缓解措施（集成服务）
    步骤 包的源是创建包的个人或组织。 运行来自未知或不可信的源的包可能存在风险。 为防止未经授权的篡改 SSIS 包，应使用数字签名。 此外，为了确保存储/传输期间包的机密性，必须加密 SSIS 包

    将数字签名添加到关键数据库安全对象

    标题 详细信息
    组件 数据库
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 添加签名（Transact-SQL）
    步骤 如果必须验证关键数据库安全对象的完整性，则应使用数字签名。 可以对存储过程、函数、程序集或触发器等数据库安全对象进行数字签名。 下面是一个示例，说明何时有用：假设 ISV（独立软件供应商）已为交付给其中一个客户的软件提供支持。 在提供支持之前，ISV 希望确保软件中的数据库安全对象不会被错误或恶意尝试篡改。 如果安全对象经过数字签名，ISV 可以验证其数字签名并验证其完整性。

    使用 SQL Server EKM 保护加密密钥

    标题 详细信息
    组件 数据库
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 SQL Server 可扩展密钥管理（EKM）、 使用 Azure Key Vault 的可扩展密钥管理（SQL Server）
    步骤 SQL Server 可扩展密钥管理使保护数据库文件的加密密钥可以存储在现成设备（如智能卡、USB 设备或 EKM/HSM 模块）中。 这还允许数据库管理员提供数据保护（sysadmin 组的成员除外）。 可以使用只有数据库用户有权访问外部 EKM/HSM 模块的加密密钥来加密数据。

    如果不应向数据库引擎显示加密密钥，请使用 AlwaysEncrypted 功能

    标题 详细信息
    组件 数据库
    SDL 阶段 建造
    适用的技术 SQL Azure、OnPrem
    属性 SQL 版本 - V12、MsSQL2016
    参考 Always Encrypted（数据库引擎）
    步骤 Always Encrypted 是一项旨在保护敏感数据的功能，例如信用卡号或国家/地区标识号（例如美国社会安全号码），存储在 Azure SQL 数据库或 SQL Server 数据库中。 Always Encrypted 允许客户端加密客户端应用程序内的敏感数据，并且永远不会向数据库引擎（SQL 数据库或 SQL Server）显示加密密钥。 因此，Always Encrypted 实现了数据所有者（可以查看数据）和数据管理者（但不应具有访问权限）之间的彻底分离。

    在 IoT 设备上安全地存储加密密钥

    标题 详细信息
    组件 IoT 设备
    SDL 阶段 建造
    适用的技术 常规
    属性 设备 OS - Windows IoT 核心版、设备连接性 - Azure IoT 设备 SDK
    参考 Windows IoT Core 上的 TPM、在 Windows IoT Core 上设置 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);

    如前所述，设备主键不在代码中。 而是存储在 TPM 的槽 0 中。 TPM 设备生成生存期较短的 SAS 令牌，然后用于连接到 IoT 中心。

    生成长度足够长的随机对称密钥，以便向 IoT 中心进行身份验证

    标题 详细信息
    组件 IoT 云网关
    SDL 阶段 建造
    适用的技术 常规
    属性 网关选项 - Azure IoT 中心
    参考 无
    步骤 IoT 中心包含设备标识注册表，在预配设备时，自动生成随机对称密钥。 建议使用 Azure IoT 中心标识注册表的此功能来生成用于身份验证的密钥。 IoT 中心还允许在创建设备时指定密钥。 如果在设备预配期间在 IoT 中心外部生成密钥，建议创建随机对称密钥或至少 256 位。

    确保设备管理策略已到位，要求使用 PIN 并允许远程擦除

    标题 详细信息
    组件 Dynamics CRM 移动客户端
    SDL 阶段 部署
    适用的技术 常规
    属性 无
    参考 无
    步骤 确保设备管理策略已到位，要求使用 PIN 并允许远程擦除

    确保设备管理策略已到位，需要 PIN/密码/自动锁定并加密所有数据（例如 BitLocker）

    标题 详细信息
    组件 Dynamics CRM Outlook 客户端
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 无
    步骤 确保设备管理策略已到位，需要 PIN/密码/自动锁定并加密所有数据（例如 BitLocker）

    使用标识服务器时确保滚动更新签名密钥

    标题 详细信息
    组件 标识服务器
    SDL 阶段 部署
    适用的技术 常规
    属性 无
    参考 无
    步骤 使用标识服务器时，请确保更新签名密钥。 参考部分中的链接介绍了如何在不造成依赖于标识服务器的应用程序发生中断的情况下规划此计划。

    确保在标识服务器中使用加密强的客户端 ID 和客户端密钥

    标题 详细信息
    组件 标识服务器
    SDL 阶段 建造
    适用的技术 常规
    属性 无
    参考 无
    步骤

    确保在标识服务器中使用强加密型客户端 ID 和客户端密码。 生成客户端 ID 和机密时，应使用以下准则：

    • 以客户端 ID 形式生成随机 GUID
    • 生成以加密方式随机的 256 位密钥作为机密