Oracle数据库网络加密传输配置实战：从原理到生产环境加固

1. 为什么数据库网络传输必须加密

很多团队在数据库安全上舍得花大价钱买审计设备、做权限隔离、搞脱敏系统，但偏偏忽略了最基础的一环——数据在网络传输过程中是明文还是密文。我见过不少生产环境，应用服务器和数据库服务器之间跑的就是明文传输，只要有人在链路上做流量镜像，账号密码、业务数据一览无余。Oracle网络加密传输配置这件事，说大不大，说小也绝对不小，它直接决定了你的数据在"路上"是否安全。

Oracle数据库默认的监听通信是不加密的，客户端和数据库之间的SQL语句、返回结果集、登录凭据全部以明文形式在网络中传输。这意味着任何能够接触到网络链路的人，都有可能截获这些信息。尤其是在混合云、跨机房、多租户环境下，网络边界变得模糊，明文传输的风险被进一步放大。

这篇文章面向的是需要负责Oracle数据库安全加固的DBA、运维工程师和后端开发人员。不管你是刚接手一套Oracle环境，还是已经在做等保合规整改，网络加密传输配置都是绕不过去的一环。我会把整个配置过程拆开揉碎，从原理到实操、从参数选择到踩坑排查，全部讲清楚，让你看完就能动手配。

2. 核心原理与方案选型拆解

2.1 Oracle网络加密的底层机制

Oracle的网络加密依赖的是Oracle Advanced Security（OAS）选项中的网络加密组件。它的工作方式是在客户端和数据库服务端之间建立一个加密通道，所有经过Oracle Net层的数据都会被加密后再传输。这个过程对应用是透明的，不需要改一行代码，只要两端配置正确，加密就会自动生效。

加密的核心流程大致是这样的：客户端发起连接请求时，会在连接描述符中声明自己支持的加密算法列表；服务端收到后，从双方都支持的算法中选一个，同时协商加密密钥；协商完成后，后续所有的SQL通信都走加密通道。整个过程基于行业标准的加密算法，Oracle本身不发明加密算法，而是调用底层安全库来实现。

这里有一个关键点需要理解：Oracle网络加密是端到端的，也就是说加密发生在Oracle Net层，而不是依赖底层的网络层加密。这意味着即使你的网络层没有任何加密措施，Oracle层面的加密依然能保护数据安全。当然，两者可以叠加使用，并不冲突。

2.2 加密算法与完整性算法的选择逻辑

Oracle支持多种加密算法和完整性算法，不同版本支持的算法集合略有差异。常见的加密算法包括AES128、AES192、AES256、3DES168等。完整性算法则包括SHA1、SHA256、SHA384、SHA512等。

选择算法时需要考虑三个维度：安全性、性能开销、兼容性。AES256安全性最高，但加解密带来的CPU开销也最大；AES128在安全性和性能之间取得了较好的平衡，是大多数场景下的推荐选择。3DES168虽然兼容性好，但性能较差，除非有特殊兼容需求，否则不建议使用。

完整性算法方面，SHA1已经不再推荐使用，SHA256及以上是当前的主流选择。完整性算法的作用是防止数据在传输过程中被篡改，它和加密算法是配合使用的，两者缺一不可。

2.3 服务端与客户端配置的职责划分

Oracle网络加密的配置分为服务端和客户端两部分，两者的职责不同但必须匹配。

服务端负责定义"我支持哪些加密算法"以及"我是否强制要求加密"。服务端的配置写在sqlnet.ora文件中，通过SQLNET.ENCRYPTION_SERVER参数控制加密行为，通过SQLNET.ENCRYPTION_TYPES_SERVER参数指定支持的算法列表。

客户端负责定义"我支持哪些加密算法"以及"我是否要求加密"。客户端的配置同样写在sqlnet.ora文件中，通过SQLNET.ENCRYPTION_CLIENT参数控制加密行为，通过SQLNET.ENCRYPTION_TYPES_CLIENT参数指定支持的算法列表。

两端的行为模式需要匹配才能正常工作。如果服务端设置为REQUIRED，那么客户端必须至少设置为REQUESTED或REQUIRED，否则连接会被拒绝。如果服务端设置为REQUESTED，客户端设置为ACCEPTED，那么加密不会生效，因为双方都没有强制要求。

注意：服务端和客户端的算法列表不需要完全一致，但必须至少有一个交集，否则协商会失败，连接无法建立。

3. 服务端加密配置实操

3.1 定位并备份sqlnet.ora文件

服务端的sqlnet.ora文件通常位于$ORACLE_HOME/network/admin/目录下。在动手修改之前，必须先备份原文件，这是铁律。我见过太多因为改错一个参数导致整个数据库连不上的案例，有备份就能快速回滚，没备份就只能干着急。

# 切换到Oracle用户 su - oracle # 进入网络配置目录 cd $ORACLE_HOME/network/admin/ # 备份原文件，带上时间戳 cp sqlnet.ora sqlnet.ora.bak.$(date +%Y%m%d%H%M%S) # 确认备份文件存在 ls -l sqlnet.ora*

如果sqlnet.ora文件不存在，可以直接创建一个新文件。有些环境默认没有这个文件，所有参数都走默认值，这种情况下创建文件并写入配置即可。

3.2 配置加密参数

服务端需要配置的核心参数有四个：加密行为、加密算法列表、完整性行为、完整性算法列表。下面是一份推荐的生产环境配置：

# 服务端加密行为：REQUIRED表示强制要求加密 SQLNET.ENCRYPTION_SERVER = REQUIRED # 服务端支持的加密算法列表，按优先级排列 SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128) # 服务端完整性校验行为：REQUIRED表示强制要求校验 SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED # 服务端支持的完整性算法列表 SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

这里解释一下SQLNET.ENCRYPTION_SERVER的四个可选值：

• ACCEPTED：如果客户端要求加密，则加密；如果客户端不要求，则不加密。这是默认值，等于不强制。
• REJECTED：拒绝所有加密连接，只接受非加密连接。这个值一般只在排查问题时临时使用。
• REQUESTED：如果客户端支持加密，则加密；如果客户端不支持，则允许非加密连接。
• REQUIRED：强制要求加密，如果客户端不支持加密，连接直接被拒绝。

生产环境建议直接上REQUIRED，不给明文连接留任何口子。完整性校验同理，用REQUIRED强制开启。

3.3 重启监听使配置生效

修改sqlnet.ora后，需要重启监听器才能让配置生效。注意，重启监听不会影响已经建立的连接，但新连接会走新的配置。

# 停止监听 lsnrctl stop # 启动监听 lsnrctl start # 查看监听状态，确认服务已注册 lsnrctl status

重启完成后，建议立即用客户端测试连接，确认加密配置是否生效。如果连接失败，第一时间检查sqlnet.ora的语法是否正确，特别是括号和逗号，Oracle对格式要求很严格。

实操心得：如果数据库是RAC集群，每个节点都要修改sqlnet.ora并重启各自的监听器。漏掉任何一个节点，通过该节点连接时加密策略就会不一致。

4. 客户端加密配置与验证

4.1 客户端sqlnet.ora配置

客户端的配置逻辑和服务端类似，但参数名不同。客户端使用SQLNET.ENCRYPTION_CLIENT和SQLNET.CRYPTO_CHECKSUM_CLIENT参数。

# 客户端加密行为：REQUESTED表示请求加密，但不强制 SQLNET.ENCRYPTION_CLIENT = REQUESTED # 客户端支持的加密算法列表 SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256, AES192, AES128) # 客户端完整性校验行为 SQLNET.CRYPTO_CHECKSUM_CLIENT = REQUESTED # 客户端支持的完整性算法列表 SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (SHA256, SHA384, SHA512)

客户端设置为REQUESTED的好处是：如果服务端支持加密，就加密；如果服务端不支持，连接依然可以建立，只是不加密。这样在过渡期比较灵活。但如果服务端已经设置为REQUIRED，客户端其实设成REQUESTED就够了，因为服务端会强制要求加密。

如果客户端也设置为REQUIRED，那么当服务端不支持加密时，客户端会主动拒绝连接。这种配置适合安全要求极高的场景，但灵活性较差。

4.2 验证加密是否生效

配置完成后，怎么确认加密真的生效了？有两种方法。

方法一：查看会话视图

连接数据库后，查询V$SESSION_CONNECT_INFO视图：

SELECT sid, serial#, network_service_banner FROM v$session_connect_info WHERE sid = SYS_CONTEXT('USERENV', 'SID');

在NETWORK_SERVICE_BANNER字段中，如果看到类似AES256 encryption service adapter for Linux和SHA256 crypto-checksumming service adapter的内容，说明加密和完整性校验都已生效。

方法二：查看监听日志

监听器日志中会记录加密协商的结果。查看$ORACLE_HOME/network/log/listener.log，搜索encryption关键字，可以看到类似Encryption service negotiated: AES256的记录。

grep -i "encryption" $ORACLE_HOME/network/log/listener.log | tail -20

两种方法结合使用，基本可以确认加密状态。如果视图中没有加密相关的banner，说明加密没有生效，需要回头检查配置。

4.3 不同客户端的配置差异

Oracle客户端有多种形态：完整客户端、即时客户端（Instant Client）、JDBC Thin驱动、OCI驱动等。不同形态的配置方式略有差异。

完整客户端和即时客户端：都读取sqlnet.ora文件，配置方式一致。即时客户端的sqlnet.ora放在即时客户端目录下，或者通过TNS_ADMIN环境变量指定。

JDBC Thin驱动：不读取sqlnet.ora文件，加密配置通过连接属性传递。需要在JDBC URL或Properties中设置oracle.net.encryption_client和oracle.net.encryption_types_client等属性。

Properties props = new Properties(); props.setProperty("oracle.net.encryption_client", "REQUIRED"); props.setProperty("oracle.net.encryption_types_client", "(AES256, AES128)"); props.setProperty("oracle.net.crypto_checksum_client", "REQUIRED"); props.setProperty("oracle.net.crypto_checksum_types_client", "(SHA256)"); Connection conn = DriverManager.getConnection(url, props);

OCI驱动：读取sqlnet.ora，和完整客户端行为一致。

注意：JDBC Thin驱动的加密配置容易被忽略，很多团队配了服务端和普通客户端，但Java应用走的是Thin驱动，结果加密根本没生效。排查时一定要覆盖所有客户端类型。

5. 常见问题与排查技巧实录

5.1 连接被拒绝：ORA-12660错误

这是最常见的加密配置问题。错误信息通常是ORA-12660: Encryption or crypto-checksumming parameters incompatible。这个错误的根本原因是服务端和客户端的加密参数不兼容。

排查思路如下：

1. 检查服务端的SQLNET.ENCRYPTION_SERVER值，确认是REQUIRED还是REQUESTED。
2. 检查客户端的SQLNET.ENCRYPTION_CLIENT值，确认是否满足服务端的要求。
3. 检查两端的算法列表是否有交集。如果服务端只支持AES256，客户端只支持3DES168，那就没有交集，协商必然失败。
4. 检查sqlnet.ora的语法，括号、逗号、空格都可能导致解析失败。

一个容易被忽略的点是：sqlnet.ora中的参数名是大小写不敏感的，但参数值中的算法名是大小写敏感的。写aes256可能不被识别，必须写AES256。

5.2 加密生效但性能明显下降

开启加密后，如果发现数据库响应变慢，大概率是加密算法选择不当。AES256的CPU开销比AES128高不少，在高并发场景下差异会被放大。

排查方法：在测试环境分别用AES256和AES128做压测，对比QPS和响应时间。如果AES128能满足安全要求，就没必要上AES256。另外，完整性算法也会带来开销，SHA512比SHA256慢，如果安全要求不是极高，SHA256足够用。

还有一个隐藏的性能杀手是加密和压缩同时开启。Oracle的网络压缩和加密都会消耗CPU，两者叠加可能导致性能急剧下降。如果必须同时使用，建议在测试环境充分压测后再上生产。

5.3 部分客户端加密不生效

这种情况通常是因为客户端类型不统一。比如应用服务器用的是JDBC Thin驱动，但DBA只配了sqlnet.ora，Thin驱动根本不读这个文件，加密自然不生效。

排查步骤：

1. 确认所有客户端类型：完整客户端、即时客户端、JDBC Thin、JDBC OCI、.NET驱动等。
2. 针对每种类型分别检查配置方式。
3. 在数据库端查询V$SESSION_CONNECT_INFO，按PROGRAM和MACHINE字段分组，看哪些客户端的连接没有加密banner。

SELECT machine, program, network_service_banner FROM v$session_connect_info WHERE network_service_banner LIKE '%encryption%' OR network_service_banner LIKE '%checksum%';

如果某个客户端的连接没有加密banner，就针对该客户端类型排查配置。

5.4 常见问题速查表

实操心得：每次修改sqlnet.ora后，不要急着在生产环境重启监听。先在测试环境验证，确认连接正常、加密生效、性能可接受，再上生产。生产环境重启监听虽然不影响已有连接，但新连接会有短暂中断，最好在业务低峰期操作。

6. 生产环境加固建议与经验总结

6.1 分阶段推进加密改造

如果你的环境中有大量客户端，一次性把所有客户端都改成REQUIRED风险很大。建议分三个阶段推进：

第一阶段：服务端设为REQUESTED，客户端设为ACCEPTED。这个阶段加密不会强制生效，但双方都具备了加密能力。目的是验证配置语法正确，不影响现有连接。

第二阶段：服务端设为REQUESTED，客户端设为REQUESTED。这个阶段加密开始生效，但不强制。如果某个客户端配置有问题，连接依然可以建立，只是不加密。通过V$SESSION_CONNECT_INFO找出没有加密的连接，逐个修复。

第三阶段：服务端设为REQUIRED，客户端设为REQUESTED。这个阶段服务端强制要求加密，所有不支持的客户端都会被拒绝。在第二阶段已经修复了所有客户端的前提下，这个阶段可以平滑过渡。

6.2 算法选择的经验法则

根据我实际踩坑的经验，算法选择可以遵循以下法则：

• 如果没有特殊合规要求，AES128 + SHA256是性价比最高的组合，安全性和性能兼顾。
• 如果有等保三级或类似合规要求，用AES256 + SHA256，安全性更高，性能开销在可接受范围内。
• 如果数据库服务器CPU资源紧张，可以考虑AES128 + SHA1，但SHA1安全性较低，需要评估风险。
• 3DES168只在极老的系统上使用，新环境不要选。

另外，算法列表的顺序是有意义的。Oracle会按照列表顺序优先选择第一个双方都支持的算法。所以把安全性高的算法放在前面，安全性低的放在后面作为兜底。

6.3 监控与持续验证

加密配置不是配完就完事了，需要持续监控。建议把以下检查纳入日常巡检：

• 定期查询V$SESSION_CONNECT_INFO，确认所有连接都走了加密。
• 监控监听器日志，关注是否有加密协商失败的记录。
• 在变更管理流程中，把sqlnet.ora的修改纳入审批范围，避免有人误改导致加密失效。
• 定期回顾加密算法列表，及时淘汰不安全的算法。

我在实际运维中遇到过一种情况：某次应用发布后，新版本的应用使用了不同的数据库驱动，导致加密没有生效。因为发布流程中没有检查加密状态，这个问题隐藏了两周才被发现。后来我们把加密状态检查加入了发布后的验证清单，类似问题再也没有出现过。

6.4 与其他安全措施的配合

网络加密传输只是数据库安全的一个环节，它解决的是"传输中"的安全问题。完整的安全体系还需要覆盖"存储中"和"使用中"的安全。

• 传输中：Oracle网络加密，就是本文讲的内容。
• 存储中：透明数据加密（TDE），对数据文件进行加密。
• 使用中：数据脱敏、访问控制、审计日志。

这三者相互配合，才能构建完整的数据库安全防线。网络加密不能替代TDE，TDE也不能替代网络加密，它们各自解决不同层面的问题。

最后分享一个小技巧：在配置加密之前，先用tnsping测试客户端和服务端的连通性，确认基础网络没有问题。然后在配置加密后，再用tnsping测试一次，如果tnsping正常但SQL连接失败，问题大概率出在加密协商上，而不是网络层。这个排查思路可以帮你快速定位问题边界，少走弯路。