你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
了解 Azure NetApp 文件中的数据加密
Azure NetApp 文件通过两种不同方法加密数据：
- 静态加密：使用符合 FIPS 140-2 的标准就地加密数据。
- 传输中加密：在传输中加密数据，或在客户端和服务器之间传输时通过网络加密数据。
了解静态加密
Azure NetApp 文件中的静态数据可通过两种方式进行加密：
- 单一加密对 Azure NetApp 文件卷使用基于软件的加密。
- 双重加密在物理存储设备层添加硬件级加密。
Azure NetApp 文件使用标准 CryptoMod 生成 AES-256 加密密钥。 CryptoMod 列在 CMVP FIPS 140-2 验证的模块列表中；有关详细信息，请参阅 FIPS 140-2 证书 #4144。 加密密钥与卷相关联，可以是 Microsoft 平台管理的密钥或客户管理的密钥。
了解传输中的数据加密
除了保护静态数据外，Azure NetApp 文件还可以保护在终结点之间传输的数据。 使用的加密方法取决于协议或功能。 Azure NetApp 文件中的 DNS 不会在传输中加密。 继续阅读以了解 Azure NetApp 文件中的 SMB 和 NFS 加密、LDAP 和数据复制。
SMB 加密
使用 SMB3.x 协议版本的 Windows SMB 客户端本机支持 SMB 加密。 SMB 加密是端到端的，且使用 AES-256-GCM/AES-128-GCM 和 AES-256-CCM/AES-128-CCM 加密套件来加密整个 SMB 会话。
Azure NetApp 文件卷不需要 SMB 加密，但可将其用于提高安全性。 SMB 加密会增加性能开销。 若要详细了解 SMB 加密的性能注意事项，请参阅 Azure NetApp 文件的 SMB 性能最佳做法。
要求对 SMB 连接进行加密
Azure NetApp 文件提供一个选项，用于强制加密所有 SMB 连接。 强制加密会禁止未加密的 SMB 通信，并会使用 SMB3 及更高版本进行 SMB 连接。 将使用 AES 加密执行加密，并加密所有 SMB 数据包。 若要使此功能正常运行，SMB 客户端必须支持 SMB 加密。 如果 SMB 客户端不支持加密和 SMB3，则会禁止 SMB 连接。 如果启用此选项，则具有相同 IP 地址的所有共享都需要加密，因此需要重写用于加密的 SMB 共享属性设置。
SMB 共享级加密
或者，可以在 Azure NetApp 文件卷的单个共享级别设置加密。
UNC 强化
Microsoft 在 2015 年引入了 UNC 强化（MS15-011 和 MS15-014），以解决可能允许跨 SMB 共享执行远程代码的远程网络路径漏洞。 有关详细信息，请参阅 MS15-011 和 MS15-014：强化组策略。
UNC 强化提供了三个选项来保护 UNC 路径：
RequireMutualAuthentication– 阻止欺骗攻击所需/不需要的标识身份验证。RequireIntegrity– 阻止篡改攻击所需/不需要的完整性检查。RequirePrivacy– 为防止流量嗅探而启用/禁用的隐私（SMB 数据包的完全加密）。
Azure NetApp 文件支持全部三种形式的 UNC 强化。
NFS Kerberos
Azure NetApp 文件还提供使用 AES-256-GCM/AES-128-GCM 和 AES-256-CCM/AES-128-CCM/AES-128-CCM 加密套件通过 Kerberos 身份验证来加密 NFSv4.1 会话的功能。
借助 NFS Kerberos，Azure NetApp 文件支持三种不同的安全风格：
- Kerberos 5（
krb5） - 仅初始身份验证；需要 Kerberos 票证交换/用户登录才能访问 NFS 导出。 NFS 数据包未加密。 - Kerberos 5i（
krb5i） - 初始身份验证和完整性检查；需要 Kerberos 票证交换/用户登录才能访问 NFS 导出，并向每个 NFS 数据包添加完整性检查，以防止中间人攻击（MITM）。 - Kerberos 5p（
krb5p） - 初始身份验证、完整性检查和隐私；需要 Kerberos 票证交换/用户登录才能访问 NFS 导出，执行完整性检查，并将 GSS 包装器应用于每个 NFS 数据包以加密其内容。
每个 Kerberos 加密级别都会影响性能。 随着加密类型和安全风格包含更安全的方法，性能效果也会随之提高。 例如，krb5 性能优于 krb5i，krb5i 的性能优于 krb5p，AES-128 的性能优于 AES-256。 有关 Azure NetApp 文件中 NFS Kerberos 的性能影响的详细信息，请参阅 Kerberos 对 Azure NetApp 文件 NFSv4.1 卷的性能影响。
注意
仅 Azure NetApp 文件中的 NFSv4.1 支持 NFS Kerberos。
下图中使用了 Kerberos 5（krb5）；仅加密了初始身份验证请求（登录/票证获取）。 所有其他 NFS 流量以纯文本形式到达。
使用 Kerberos 5i （krb5i；完整性检查）时，跟踪显示 NFS 数据包未加密，但数据包中添加了一个 GSS/Kerberos 包装器，要求客户端和服务器使用校验和来确保传输的数据的完整性。
Kerberos 5p（隐私；krb5p）使用 GSS/Kerberos 包装器提供所有 NFS 流量的端到端加密，如跟踪图像中所示。 由于需要处理每个 NFS 数据包的加密，此方法产生的性能开销最大。
数据复制
在 Azure NetApp 文件中，可以跨 Azure 中的区域或地区复制整个卷以提供数据保护。 由于复制流量驻留在 Azure 云中，因此传输发生在安全的 Azure 网络基础结构中，这种传输在访问方面受到限制，以防止数据包嗅探和中间人攻击（通信终结点之间的窃听或模拟）。 此外，复制流量使用符合 FIPS 140-2 标准的 TLS 1.2 标准进行加密。 有关详细信息，请参见安全性常见问题解答。
LDAP 加密
LDAP 搜索和绑定流量通常以纯文本方式通过网络传递，这意味着任何有权探查网络数据包的人都可以从 LDAP 服务器获取信息（例如用户名、数字 ID、组成员身份等）。然后，此信息可用于欺骗用户、发送电子邮件进行钓鱼攻击等。
为了防止 LDAP 通信被截获和读取，LDAP 流量可以通过 LDAP 签名和 LDAP over TLS 分别利用 AES 和 TLS 1.2 进行网络加密。 有关配置这些选项的详细信息，请参阅创建和管理 Active Directory 连接。
LDAP 签名
LDAP 签名特定于托管用户和组 UNIX 标识的 Microsoft Active Directory 服务器上的连接。 此功能允许对托管 LDAP 连接的 AD 服务器之间的简单身份验证和安全层 (SASL) LDAP 绑定进行完整性验证。 签名不需要配置安全证书，因为它使用 GSS-API 通信与 Active Directory 的 Kerberos 密钥分发中心 (KDC) 服务。 LDAP 签名仅检查 LDAP 数据包的完整性；它不会加密数据包的有效负载。
还可以通过组策略从 Windows 服务器端配置 LDAP 签名，以使用 LDAP 签名（无 - 客户端请求时支持）或强制实施 LDAP 签名（要求）。 LDAP 签名可能会给 LDAP 流量增加一些性能开销，但对最终用户来说通常可忽略不计。
Windows Active Directory 还允许使用 LDAP 签名和密封（LDAP 数据包的端到端加密）。 Azure NetApp 文件不支持此功能。
LDAP 通道绑定
由于在 Windows Active Directory 域控制器中发现了安全漏洞，Windows 服务器已更改默认设置。 有关详细信息，请参阅 Microsoft 安全公告 ADV190023。
从根本上讲，Microsoft 建议管理员启用 LDAP 签名以及通道绑定。 如果 LDAP 客户端支持通道绑定令牌和 LDAP 签名，则需要通道绑定和签名，并且注册表选项由新的 Microsoft 修补程序设置。
Azure NetApp 文件默认适时支持 LDAP 通道绑定，也就是说，当客户端支持 LDAP 通道绑定时，就会使用 LDAP 通道绑定。 如果不支持/发送通道绑定，仍会允许通信，并且不会强制实施通道绑定。
LDAP over SSL（端口 636）
Azure NetApp 文件中的 LDAP 流量总是通过端口 389 进行传递。 此端口无法修改。 不支持 LDAP over SSL (LDAPS)，大多数 LDAP 服务器供应商视其为旧版（RFC 1777 发布于 1995 年）。 如果要将 LDAP 加密与 Azure NetApp 文件配合使用，请使用 LDAP over TLS。
LDAP over StartTLS
LDAP over StartTLS 于 2000 年通过 RFC 2830 推出，并在 2006 年与 RFC 4511 合并为 LDAPv3 标准。 StartTLS 成为标准后，LDAP 供应商开始将 LDAPS 称作弃用。
LDAP over StartTLS 使用端口 389 进行 LDAP 连接。 建立初始 LDAP 连接后，将交换 StartTLS OID 并比较证书；然后，使用 TLS 进行加密所有 LDAP 流量。 下面的数据包捕获显示了 LDAP 绑定、StartTLS 握手和后续 TLS 加密的 LDAP 流量。
LDAPS 和 StartTLS 之间存在两个主要区别：
- StartTLS 是 LDAP 标准的一部分，而 LDAPS 不是。 因此，LDAP 服务器或客户端上的 LDAP 库支持可能会有所不同，并且功能不一定在所有情况下都有效。
- 如果加密失败，StartTLS 允许配置回退到常规 LDAP。 LDAPS 不允许。 因此，StartTLS 更灵活性且复原能力更强，但如果配置不当，也会带来安全风险。
使用 LDAP over StartTLS 的安全注意事项
StartTLS 使管理员能够回退到常规 LDAP 流量（如果需要）。 出于安全考虑，大多数 LDAP 管理员不允许此操作。 以下 StartTLS 建议可帮助保护 LDAP 通信：
- 确保已启用 StartTLS 并配置证书。
- 对于内部环境，可以使用自签名证书，但对于外部 LDAP，请使用证书颁发机构。 有关证书的详细信息，请参阅自签名 SSL 与证书颁发机构之间的差异。
- 阻止不使用 StartTLS 的 LDAP 查询和绑定。 Active Directory 默认禁用匿名绑定。
Active Directory 安全连接
可将 Azure NetApp 文件卷的 Active Directory 连接配置为首先尝试可用的最强 Kerberos 加密类型：AES-256。 启用 AES 加密后，域控制器通信（如计划的 SMB 服务器密码重置）会使用域控制器上支持的最高可用加密类型。 Azure NetApp 文件支持域控制器通信的以下加密类型，按尝试身份验证顺序排列：AES-256、AES-128、RC4-HMAC、DES
注意
无法在 Azure NetApp 文件中禁用较弱的身份验证类型（如 RC4-HMAC 和 DES）。 如果需要的话，应从域控制器中禁用这些类型，这样身份验证请求就不会尝试使用它们。 如果在域控制器上禁用 RC4-HMAC，则必须在 Azure NetApp 文件中启用 AES 加密才能正常运行。