安全框架：加密 | 缓解措施
| 产品/服务 |
项目 |
| Web 应用程序 |
|
| Database |
|
| IoT 设备 |
|
| IoT 云网关 |
|
| Dynamics CRM 移动客户端 |
|
| Dynamics CRM Outlook 客户端 |
|
| 标识服务器 |
|
只使用批准的对称块加密法和密钥长度
| 标题 |
详细信息 |
| 组件 |
Web 应用程序 |
| SDL 阶段 |
构建 |
| 适用的技术 |
泛型 |
| 属性 |
空值 |
| 参考 |
空值 |
| 步骤 |
产品必须只使用已由组织中加密顾问明确批准的对称块加密法和关联的密钥长度。 Microsoft 批准的对称算法包括以下块加密法： - 对于新代码，可接受 AES-128、AES-192 和 AES-256
- 为了与现有代码向后兼容，可接受三重密钥 3DES
- 使用对称块加密法的产品：
- 新代码需要使用高级加密标准 (AES)
- 为了向后兼容，允许在现有代码中使用三重数据加密标准 (3DES)
- 其他所有块加密法，包括 RC2、DES、双重密钥 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）
请注意，在未对 machine.config 文件做出更改的情况下，不能通过 SymmetricAlgorithm.Create 或 CryptoConfig.CreateFromName 方法指定其中的任何算法。 另请注意，在低于 .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 位的密钥只能用于解密/验证旧数据，对于加密或签名操作，必须改用其他密钥
- 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，但需要对此过程申请例外处理，并接受组织加密委员会的评审。 不允许截断小于 128 位的 HMAC。 使用客户方法来哈希处理密钥和数据的措施未获批准，在使用之前必须接受组织加密委员会的评审。 |
只使用批准的加密哈希函数
| 标题 |
详细信息 |
| 组件 |
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、三重 DES、TRIPLE_DES_3KEY、RC2、RC4、128 位 RC4、DESX、128 位 AES、192 位 AES 和 256 位 AES |
应该对 SSIS 包进行加密和数字签名
| 标题 |
详细信息 |
| 组件 |
数据库 |
| SDL 阶段 |
构建 |
| 适用的技术 |
泛型 |
| 属性 |
空值 |
| 参考 |
使用数字签名标识包源、威胁和漏洞缓解措施（集成服务） |
| 步骤 |
包的源是创建包的个人或组织。 运行来自未知或不可信的源的包可能存在风险。 为了防止有人未经授权篡改 SSIS 包，应使用数字签名。 此外，为确保在存储/传输过程中包的机密性，必须将 SSIS 包加密 |
将数字签名添加到关键的数据库安全对象
| 标题 |
详细信息 |
| 组件 |
数据库 |
| SDL 阶段 |
构建 |
| 适用的技术 |
泛型 |
| 属性 |
空值 |
| 参考 |
ADD SIGNATURE (Transact-SQL) |
| 步骤 |
如果必须验证关键数据库安全对象的完整性，应使用数字签名。 可将数据库安全对象（例如存储过程、函数、程序集或触发器）数字签名。 下面是数字签名的一个用例：假设某家 ISV（独立软件供应商）需要向其一个客户提供软件支持。 在提供支持之前，该 ISV 想要确保软件中的数据库安全对象不会因为人为失误或恶意入侵而遭到篡改。 如果将安全对象数字签名，该 ISV 就可以验证其数字签名和完整性。 |
使用 SQL Server EKM 保护加密密钥
如果不应向数据库引擎透露加密密钥，请使用 AlwaysEncrypted 功能
| 标题 |
详细信息 |
| 组件 |
数据库 |
| SDL 阶段 |
构建 |
| 适用的技术 |
SQL Azure、OnPrem |
| 属性 |
SQL 版本 - V12、MsSQL2016 |
| 参考 |
Always Encrypted（数据库引擎） |
| 步骤 |
Always Encrypted 功能旨在保护 Azure SQL 数据库或 SQL Server 数据库中存储的敏感数据，例如信用卡号或国民身份证号（如美国社会安全号码）。 通过 Always Encrypted，客户可在客户端应用程序中加密敏感数据，永远不会向数据库引擎（SQL 数据库或 SQL Server）透露加密密钥。 因此，Always Encrypted 将数据所有者与数据管理者区分开来，前者可查看数据，而后者无权访问数据。 |
在 IoT 设备上安全存储加密密钥
示例
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 设备生成一个用于连接到 IoT 中心的短期生存的 SAS 令牌。
生成足够长的随机对称密钥用于向 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 位密钥
|