数据库运维管理的5条技术路线-k8凯发游戏

在数据库运维场景中，“公用”是一种很常见的事情，包括：公用数据库账号、公用运维主机、公用操作系统账号等等。然而这种“公用”行为带来的问题，则是无法准确识别运维人员的身份，无法合理分配每个自然人的权限，且对于一些明显的误操作或恶意操作也无法溯源到自然人本身；而另一个由“公用”带来的弊端是数据库的账号被散发出去，导致本来不应对该数据具备运维权限的人也可能获取到账号，从而威胁到相关k8凯发游戏。

面对以上问题，单纯通过提高密码的复杂度或定期更改密码都不足以保障数据的安全。企业该采取怎样的密码管理方式，才能适应这种“公用”运维场景下的数据安全管理与控制要求？

从上文提及的诸多“公用”场景可以发现，唯一不公用的，大概就是运维人员的“自然人身份”。如果可以通过一些技术手段明确表征自然人的身份，让安全设备能够根据自然人的身份及权限自动的为其建立合理的数据库连接，那么无论其他条件因数如何被“公用”，都可以清晰定位访问数据的自然人身份；同时，这种自动建立连接的机制令数据库账号和密码不会被暴露在运维人员或公用环境之中，从而减少数据泄露的风险和隐患。

负责数据库运维的dba和安全管理人员，常会碰到以下问题：

问题一：多个运维人员在运维过程中使用相同的高权限数据库账号，无法区分控制和审计；

问题二：高权限账号的安全性无法保障，密码几乎是公开的，而定期变更密码所产生的高维护成本也令相关工作难以实际落地；

问题三：由于应用系统和运维侧使用相同的账号，造成无法区分权限，无法进行细粒度控制；

问题四：运维过程中，同一运维人员对不同内容进行运维时，需要不同的账号分别登陆数据库完成，不仅令人员的操作和记忆十分繁琐，也进一步提高了运维的成本。

想要对运维工作进行准确、有效的管控，着眼于“自然人身份”是更为有效的手段。针对“自然人”的识别与控制，安华金和运维管理系统（doms）综合以下5条技术路线和手段，k8凯发游戏的解决方案可由外及内、由浅入深的满足客户在不同场景下的实际需求：

k8凯发游戏的解决方案

1、web认证方案

先将运维人员账号录入到doms运维管理系统，并创建对应的运维人员web管理账号；当通过运维终端所在pc浏览器打开doms系统时，使用运维人员web账号进行登陆，以申明当前是哪位运维人员在登录系统；之后，在运维终端上使用数据库客户端工具，通过代理地址登陆数据库；doms将通过客户端ip判定当前是哪位运维人员在访问数据库。

通过上述方式，客户能够准确识别出是谁在使用终端设备，是谁在操作数据库，并对人为操作进行控制；但无法解决密码共用、定期更改密码等在维护和操作上造成的麻烦。

2、堡垒机环境下的应对方案

在“堡垒机 跳板机”的环境下，经过堡垒机连接数据库的方式大体分为两种：

· 数据库登录密码“代填”方式

大致流程为：运维终端->堡垒机->跳板机->堡垒机->数据库（如图1中的1->4->2->3）；

· 数据库登录密码“非代填”方式

有别于代填方式，是在跳板机上打开运维工具登陆数据库，流程相对简单：运维终端->堡垒机->跳板机->数据库（如图1中的1->4->5）。

图1：堡垒机和跳板机交互流程

堡垒机的引入对于获取“自然人身份”增加了难度，用非代填方式比较简单。如果堡垒机登录跳板机使用运维账号作为操作系统账号，以oracle数据库为例，可以通过协议解析的方式获取运维人员账号；如果多个运维人员在打开跳板机时用的都是同一数据库账号，或者是数据库通信协议中没有操作系统账号标识，则需要在跳板机上安装插件，通过插件获取当前的运维账号并发送给doms运维管理系统，从而实现关联。

相比之下，用代填方式进行关联会比较复杂。这与不同堡垒机的实现机制也有关系，需要一定的流程对接，比如在堡垒机设备上做一个运维账号操作的关联，再将信息推送给doms运维管理系统实现关联。

3、动态令牌、ukey和证书方案

动态令牌和ukey大家并不陌生，是一种常用的双因素校验工具。doms运维管理系统可将令牌种子（或ukey特征值）同运维管理的web账号进行关联。

其中，动态令牌的实现方式另辟蹊径，是在运维工具已登录数据库之后，通过特定的语句发送当前的令牌码，doms截获到令牌码后会进行正确性的校验，并获取关联的运维账号。

ukey则是在客户端主机上安装小工具，用来读取ukey和证书信息，并将信息内容发送给doms；同时，该小工具可以读取操作系统账号和mac地址，从而弥补了有些数据库通信协议没有操作系统账号的空白。但ukey毕竟是物理设备，需要实际插入到运维所使用的客户端主机上，而对于虚拟化或堡垒机等无法插入ukey的环境则只能使用证书的方式。

证书的方式同ukey类似，只是将硬件ukey设备缓存文件证书，运维终端上利用客户端小工具选择运维人员的证书进行登陆，证书会标识“自然人”信息。

4、密码桥方案

为了真正做到运维账号一人一密，数据库账号的密码不暴露，数据库密码可定期更换，以及在同一运维账号关联多个数据库账号的情况下可对运维人员进行权限控制，doms引入“密码桥”方案。

什么是密码桥？概括来讲就是“运维管理web账号 密码”和“数据库账号 密码”在doms运维管理系统上已提前配置完成并形成映射关系，此时运维账号通过数据库连接工具（如sqlplus、pl/sql等）登录数据库，doms会在数据库连接过程中对用户密码进行替换（两套账号密码的映射关系），达到使用该数据库实际账号对应的运维账号登录数据库的目的；同时，能对运维账号和密码匹配的正确与否进行校验，也可以对数据库账号和密码的正确性进行校验。

doms运维管理系统配置如下：

例一：指定数据库账号

username：zhangsan:crm（zhangsan为运维管理web账号；crm为数据库账号）

password：运维账号密码

此时，zhangsan这个运维账号经过doms运维管理系统映射，使用crm这个数据库账号访问数据库，仅需要输入运维账号的密码，无需输入数据库账号crm的真实密码，从而达到数据库密码不对运维人员暴露的效果。

例二：不指定数据库账号

以sqlplus为例：此时，只输入了运维账号，doms系统会根据运维账号找到与其关联的唯一一个数据库账号进行替换并登录。

5、防绕过方案

针对某些c/s架构的业务系统，特别是医疗行业，会涉及到大量的客户端设备且有大量的动态ip情况存在。此时，无法通过客户端ip的方式定位到客户端主机，对于安装ukey的插件来说工作量也比较大。如果安装插件，能保障所有设备都被安装到么？即使安装了插件，如果不通过代理地址（doms运维管理系统）访问数据库又该如何防护？此外，在数据库本地操作数据库又要怎样应对？

对于以上场景，k8凯发游戏提出“运维访问防绕过”方案，即利用在数据库的logon触发器进行数据库访问白名单控制：想要访问数据库的主机设备，必须到doms系统上进行注册（包含ip、user、客户端主机名等）；注册后doms会对触发器的内容进行调整，实现对客户端与数据库建立连接时的控制。此时，即使没有经过代理地址（经过doms的还会有代理层面的控制）的登录行为，也会被认定为非授信的异常登录，从而真正达到只有在授信终端上使用授信客户端运维工具、运维账号、通过合规的访问通道，才可以正常对数据库进行运维操作的目的。

文中介绍的五种技术路线及k8凯发游戏的解决方案，是在doms运维管理系统中对自然人进行识别、控制，以及对密码安全性的思考；在引进权控方案后，不会对日常运维工具带来影响和附加工作，从而让doms运维管理系统成为企业运维安全可靠的帮手。