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 强化
2015 年，Microsoft引入了 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 加密套件通过 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 性能优于 krb5ikrb5i 的性能， krb5pAES-128 的性能优于 AES-256 等。 有关 Azure NetApp 文件中 NFS Kerberos 的性能影响的详细信息，请参阅 Kerberos 对 Azure NetApp 文件 NFSv4.1 卷的性能影响。
注释
NFS Kerberos 仅在 Azure NetApp 文件中支持 NFSv4.1。
在下图中，使用 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 流量可以分别利用 AES 和 TLS 1.2 通过 LDAP 签名和 LDAP 通过 TLS 进行网络加密。 有关配置这些选项的详细信息，请参阅 “创建和管理 Active Directory 连接”。
LDAP 签名
LDAP 签名特定于 Microsoft Active Directory 服务器上的连接，这些服务器为用户和组托管 UNIX 身份。 此功能允许对简单身份验证和安全层 （SASL） LDAP 进行完整性验证，并将其绑定到托管 LDAP 连接的 AD 服务器。 签名不需要配置安全证书，因为它使用 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 通道绑定，这意味着当客户端支持该功能时会使用通道绑定。 如果不支持/发送通道绑定，仍允许通信，并且不会强制实施通道绑定。
通过 SSL 的 LDAP （端口 636）
Azure NetApp 文件中的 LDAP 流量在所有情况下都通过端口 389 进行传递。 无法修改此端口。 大多数 LDAP 服务器供应商不支持基于 SSL 的 LDAP（LDAPS），并将其视为旧版技术（RFC 1777 于 1995 年发布）。 如果要将 LDAP 加密与 Azure NetApp 文件配合使用，请通过 TLS 使用 LDAP。
基于 StartTLS 的 LDAP
LDAP over StartTLS 于 2000 年引入 RFC 2830 ，并在 2006 年与 RFC 4511 合并为 LDAPv3 标准。 启动TLS 成为标准后，LDAP 供应商开始将 LDAPS 称为已弃用。
LDAP over StartTLS 使用端口 389 进行 LDAP 连接。 建立初始 LDAP 连接后，交换 StartTLS OID 并比较证书;然后，所有 LDAP 流量都使用 TLS 进行加密。 下面显示的数据包捕获显示了 LDAP 绑定、StartTLS 握手和后续 TLS 加密的 LDAP 流量。
LDAPS 和 StartTLS 之间存在两个主要区别：
- StartTLS 是 LDAP 标准的一部分;LDAPS 不是。 因此，LDAP 服务器或客户端上的 LDAP 库支持可能会有所不同，并且功能在所有情况下都可能不起作用。
- 如果加密失败，StartTLS 允许配置回退到常规 LDAP。 LDAPS 不会。 因此，StartTLS 提供了一些灵活性和复原能力，但如果配置不当，也会带来安全风险。
使用 StartTLS 协议进行 LDAP 连接时的安全注意事项
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 加密才能获得适当的功能。