|
一、前言 本篇文章主要说一说SQLServer数据库中身份鉴别控制点的中c、d测评项相关内容和理解。 二、测评项
c)当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听； d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。
c)当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听； 以前我一直以为SQLServer的鉴别信息（数据库连接字符串）如果不经过特殊处理在网络传输过程中是明文传输的。 后来上网查了下，网上提到说：联机从书上提到过从SQL Server 2005开始，SQL Server和客户端的连接是自动加密的 我去翻了下SQLServer 2008 R2的联机丛书，上面确实提到，SQL Server 始终对与登录关联的网络数据包加密：
那么以网上的那篇文章内容来说的话，SQLServer 2005开始，SQLServer默认会对与登录关联的网络数据包加密，具体网址如下：SQL Server 连接加密 (1) — SQL Server connection encyption 但是，要注意：SQLServer自动生成的证书是一种自签名的证书，而通过自签名证书实现的SSL并不能提供很强的安全性。 同时，虽然默认会对与登录关联的网络数据包加密，但是对与登录无关的网络数据包是默认不加密的：SQL Server 连接加密 (2) — SQL Server connection encyption。 不过该测评项也仅仅只是要求防止鉴别信息在网络传输过程中被窃听，所以与登录无关的网络数据包是否加密，不在这里考虑。 3.2. 强制加密 那么，原初级教程里提到的强制加密是用来干什么的呢？ 这个强制加密在SQL Server Configuration Manager中有两个地方，一个是SHTECSQLEXPRESS的协议的属性中进行设置：
一个在SQL Native Client配置的属性中进行设置：
这两个有什么不同呢？ SHTECSQLEXPRESS的协议属性中的强制加密，默认为否：
当把该选项设置为是之后，SQL Server就会要求对所有它和客户端之间的数据包传送进行加密，无论客户端是否配置为要求加密。此时用来加密的密钥仍旧是之前在建立连接阶段使用的证书。 如果SHTECSQLEXPRESS的协议属性中的强制加密未设置为是：
那么是否对某客户端的所有传输过来的数据进行加密就完全取决于客户端的配置，也就是客户端的数据库连接驱动的配置。在Configuration Manager中，可以设置SQL Native Client配置。当SQL Native Client配置属性中的强制加密为是的话，就表明客户端要求加密数据包。此时客户一定要信任SQL Server端的证书（也就是信任服务器证书为是），否则连接无法建立。另外，需要注意的是，此处的配置只对使用Native Client的客户端程序有效果。其他驱动程序也会有相应的方法分别作配置。如ODBC驱动就可以通过Cliconfg控制台来配置，等等 具体的原文在这：SQL Server 连接加密 (2) — SQL Server connection encyption。 SQLServer 2008 R2的联机丛书中也有说到这部分的内容：
所以强制加密的第一个作用是可以使用自己配置的证书，第二个作用就对多所有的网络传输数据进行加密。 对于这个测评项而言，第二个作用没有意义，而手动配置证书有意义，因为它可以提高安全性：
使用自签名证书加密的 SSL 连接不提供强安全性。它们容易在传输中途受到攻击。在生产环境中或在连接到 Internet 的服务器上，不应依赖使用自签名证书的 SSL。 如果要判定为符合，应该不使用自签名证书（也即SQLServer自动生成的证书）。 手动 配置SQLServer的过程如下：
3.4. ipsec 使用IPSec也可以实现传输数据的加密：
3.5. 测评项c总结一 该测评项对于默认状态下的SQLServer应该属于部分符合，因为默认情况下SQLServer对于网络传输过程中的鉴别信息是加密的，只不过安全性不高。 如果要判定为符合，应该使用手动配置的证书或者使用IPSec。 3.6. 测评项c总结二 对于这个测评项也要从该数据库的使用模式来进行判断（以下是个人理解）。 比如中间件和数据库处于同一台服务器A上，客户端或者浏览器不会直连数据，而是发送请求到http接口到A，A再连接处于本地的数据库获取数据，未发生过数据库鉴别信息的网络传输，那么这个测评项应判定为不适用或者符合。 又或者中间件所在服务器A和数据库所在服务器B处于同一内网中，服务器A接收到请求后，发送数据库的鉴别信息到服务器B，外网的设备比较难获取到鉴别信息（更别说鉴别信息也不是明文传输的），应该判定为部分符合或者符合。 又或者，虽然数据库本身没有进行什么配置，但是客户端是直连数据库的（某一些C/S架构的软件确实会这样），但是客户端使用了SSL等协议进行了网络传输数据的加密，那么也应该是部分符合或者符合。 好吧，由于等级保护2.0去掉了0-5分的分数制，所以虽然有很多种情况，但是判定结果只有符合、部分符合、不符合、不适用，所以区分得这么细在判定结果处差别不大。 但是，在结果记录处还是有区别的，要根据实际情况进行记录嘛。 哦，对了，最后说一句，要记得查看SQLServer的版本，默认加密是从2005版开始的。 四、测评项d
d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。 好吧，直接实现SQLServer数据库双因素认证的方法我没找到，顶多也就是可以使用证书对存储过程进行访问控制：使用证书为存储过程签名。 绝大部分的被测评单位在SQLServer数据库的这一个测评项处，只能得0分，不过也不用过于在意。 该测评项属于安全计算环境这个安全类，其测评对象包括了数据库、服务器和终端的操作系统、应用系统、安全设备、网络设备等等，按照等级保护2.0的标准，对于3级和以上的系统，只要其中一个设备在该测评项处得0分，那么就可能属于高风险项，测评结论瞬间就变成差了。 从现实的角度而言，这么多设备统统都要实现双因素认证，既无可能，也没必要。 所以制定等级保护标准的专家们考虑到这一点，在网络安全等级保护测评高风险判定指引（2019定稿）中留下了很多的口子（个人理解）。 举个例子，对于该测评项而言：
满足条件中指明，属于3级和3级以上系统，且被测评对象属于重要核心设备等通过不可控网络环境远程进行管理，然后同时未实现双因素认证的，可判定为高风险项。 分析一下，3级和3级以上系统这个条件不用多说，3级以下系统不存在这个测评项。 被测评项对象属于重要核心设备，这个也不用多说，被抽选出来的测评项对象，其重要性一般都不低（否则你选它干嘛）。 通过不可控网络环境远程进行管理，这个有些用，对于数据库，不一定存在远程连接的行为，这一点我上面的文章有说。就算存在远程连接的行为，是否就处于不可控网络环境呢？也不一定的。 注意，不可控网络在判定指引中有明确定义： 到这里，就算条件都满足了，属于高风险项，也存在很多的补偿措施，对该高风险项目进行修正，这些补偿措施都是现实可行的，绝不是无法实行的，这里就不具体的分析了。 总而言之，虽然高风险项存在着一票否决的特性，但需要满足特定条件且不能被修正。 在实际工作中，给测评师们降低了实施的难度，也减少了和被测评单位扯皮的概率，也算是等级保护2.0的一种进步吧。 *本文原创作者：起于凡而非于凡，本文属于FreeBuf原创奖励计划，未经许可禁止转载 |
名表回收网手机版
