本主题介绍减少复制拓扑所面临威胁的技术。
加密
加密是把数据转换成没有特殊密钥就不能读取、而只有特定的接收者能够读取的数据格式的过程。 复制并不加密存储在表中或通过网络连接发送的数据。 这是有意设计的，因为在传输层有多种加密技术可以使用，其中包括下列行业标准技术：虚拟专用网络 (VPN)、传输层安全性 (TLS)（原名为安全套接字层 (SSL)）和 IP 安全 (IPSEC)。 建议对复制拓扑中各计算机之间的连接，使用这些加密方法之一。 有关详细信息，请参阅启用数据库引擎的加密连接（SQL Server 配置管理器）。 若要了解如何使用 VPN 和 TLS 通过 Internet 复制数据，请参阅保护通过 Internet 进行的复制。
如果使用 TLS 来保护复制拓扑中计算机间的连接，请为每个复制代理的 -EncryptionLevel 参数指定值 1 或 2（建议指定值 2）。 值 1 指定使用加密，但代理不验证 TLS/SSL 服务器证书是否由受信任的颁发者进行签名；值 2 指定验证证书。 代理参数可以在代理配置文件和命令行中指定。 有关详细信息，请参阅：
就数据库主密钥（用于加密数据）而言，复制具有以下行为：
如果复制所涉及的数据库（发布数据库、订阅数据库或分发数据库）中有主密钥，则复制使用 SQL Server 2012 (11.x) 数据库对称密钥对该数据库中的代理密码进行加密和解密。 如果使用主密钥，则应在复制所涉及的每个数据库中都创建主密钥。 有关创建主密钥的详细信息，请参阅CREATE MASTER KEY（Transact-SQL）。
复制不会复制主密钥。 如果需要订阅服务器上的主密钥，则必须使用 BACKUPBACKUP MASTER KEY 从发布数据库导出主密钥，然后使用它将其导入订阅数据库 RESTORERESTORE MASTER KEY。 有关详细信息，请参阅BACKUP MASTER KEY（Transact-SQL）和RESTORE MASTER KEY（Transact-SQL）。
如果为可附加订阅数据库定义了主密钥，请使用 sp_attachsubscription (Transact-SQL) 的
@db_master_key_password参数指定主密钥密码。 这样便可将数据库附加到订阅服务器上。
有关加密以及主密钥的详细信息，请参阅 Encryption Hierarchy。
通过使用复制，您可以发布加密的列数据。 若要在订阅服务器上解密并使用此数据，则订阅服务器上也必须有用于在发布服务器上加密该数据的密钥。 复制并不提供安全机制来传输加密密钥。 您必须在订阅服务器上手动重新创建加密密钥。 有关详细信息，请参阅复制加密列中的数据 (SQL Server Management Studio)。
TLS 1.3 支持
SQL Server 2025 （17.x） 及更高版本支持 TLS 1.3 ，用于配置为在 SQL Server 2025 上运行的代理初始化的复制连接。 这适用于包含 SQL Server 和 SQL 托管实例的复制拓扑。
如果使用 TLS 1.3 来保护复制拓扑中实例之间的连接，请为每个复制代理指定值 3 或 4 参数 -EncryptionLevel ：
值 3 强制实施与 SQL 托管实例的 TLS 1.3 连接，但不会影响到 SQL Server 实例的连接。 为 SQL 托管实例或 SQL Server 2025 (17.x) 及更高版本启动的出站连接启用 TLS 1.3 的值为 4 ，以连接到其他 SQL Server 或 SQL 托管实例。 对于面向 SQL Server（任何受支持的版本）的连接，必须在目标 SQL Server 主机上安装相应的证书。
注释
对于具有远程分发器的复制拓扑：