近年来，各行业用户对于数据安全的建设目标，正在逐渐从“单纯防外部攻击”转向“内外部环境下的数据安全使用”，这种视角的转变代表企业和组织更加重视数据流转过程中各个环节的管控，对于企业核心数据的访问来自应用和运维两方面，而运维人员具有更高操作权限。

目前在信息化建设较为成熟的大型集团或组织，已经形成了详细的运维工作管理要求，以某运营商行业的信息安全管理规范为参考，能够梳理出组织和企业对于数据运维安全，应当重点考虑的几个角度和可参照的标准，同时将我们在此方面的技术思路呈现出来，供参考。

规范中的重点运维要求可归纳为以下四点：

权限明确、职责分离、最小特权

运维账户的权限分配应当遵循“权限明确、职责分离、最小特权”的原则。原则上一个账号对应一个用户，而一个账号拥有的权限是由其被赋于的岗位角色所决定的，应按照角色或用户组进行授权，而不是将单个权限直接赋予一个账号。对权限相近的岗位角色进行合并，并对岗位角色的权限进行规范。在涉及客户信息的系统中，岗位角色应当根据企业、部门的组织结构和职责分配而设定；同时，应当根据岗位角色的需要对相关人员进行授权，不能根据人员需求或变更而设定岗位角色。不同的岗位角色拥有不同的权限。

角色定位、岗位职责、权限要求

规范中界定的运维角色有主机管理员、网络管理员、数据库管理员、应用管理员、配置管理、服务监控、安全管理等，于各省公司负责涉及客户敏感信息的系统的维护管理和服务监控的人员。其中：

l  主机管理员、网络管理员、数据库管理员、配置管理员等超级管理员无权查询客户信息；

l  应用管理员有查询权限，按照最小授权原则授权，可授予增加、删除、修改、批量导入与导出、批量开通与取消、批量下载等针对客户敏感信息操作的部分权限，但必须有严格的日志记录；

l  具有批量操作权限的人员应指定专人，人员范围应尽量小。

关于登录及操作审批的规定

l  运维支撑人员对业务系统应用层的访问权限必须经过业务管理部门审批，对系统层访问权限必须经过本部门领导审批。

l  运维支撑人员因统计取数、批量业务操作对客户敏感信息查询、变更操作时必须有业务管理部门的相关公文，并经过部门领导审批。

l  支撑人员因系统维护进行客户敏感信息的数据迁移（数据导入、导出、备份）必须填写操作申请，并经过部门主管审批。

关于敏感数据运维操作流程的规定：审批要求

运维支撑人员因业务投诉、统计取数、批量业务操作、批量数据修复等进行的客户敏感信息查询、变更必须提交操作申请，按照要求进行操作，不得扩大操作范围，在工单中保留操作原因和来源的工单（公文）编号，并由专人负责审核。

当前运维管理工作需求与现状

以上管理规范中对于数据库运维侧的相关规定，对高细粒度的运维管控提出了要求：涉及到了运维人员身份鉴别，登录及操作审批、运维操作流程准确审计以及集中的事中管控等方面。

传统的数据库运维工作的管理模式重在事前审批，审批通过后则由运维人员自行安排操作执行，也可能由其他人员代操作，整个操作过程不定因素很多：

l 实际操作人是谁？

l 运维人员实际操作是否与申请一致？

l 出现误操作，如何追溯？

l 如何管控来自内部或第三方运维人员有意无意的高危操作？

目前，堡垒机是大多数企业的普遍解决方案。而事实上，由于缺乏对数据库通讯协议的准确解析能力，堡垒机只能实现对操作人身份、操作目标库等最基本的身份识别，这其中差了最关键的一环：对操作内容、操作过程的有效管控。因此，对执行过程进行透明化管控是数据库安全运维系统的重要使命。另外，堡垒机对于图形化操作只能进行录屏，无法作到有效事中控制，未来风险分析时也无法完成快速的检索和定位。

数据库安全运维细粒度管控技术分析 

安华金和的数据库安全运维系统DBController正是凭借着细粒度的运维管控优势，帮助众多用户实现了对数据库的日常运维管理，有效提升运维管理的精细度和安全性。

运维身份认证细粒度控制

用户风险

某集团运维工作中，存在运维人员小张、小王、小李共享主机和数据库账户的情况，一旦发生运维事故，怎么定位追责？

解决方案

通过双因素认证机制，解决数据库账户共享、运维主机共享场景下的运维人员精准身份鉴别及权限划分问题。认证机制包括：

动态令牌：运维人员在登录数据库后，需要输入动态令牌显示的数字校验身份，通过后方可执行与身份相符的运维操作。

审批口令码：运维人员提交申请并通过后获得审批码，运维人员登录数据库需提交审批码，方可继续执行获准的运维操作。

DBController可设置普通用户、审批人、安全管理员、系统管理员、审计管理员五种角色，对应不同操作权限。

l  普通用户即一线运维人员，其权限是可以对执行的语句进行申请并根据申请结果执行操作；

l  审批人即运维主管或安全主管，对申请人申请的语句进行审批，也可以申请语句并执行；

l  安全管理员可以制定管控对象和操作规则，对运维数据实时监控，审计检查；

l  系统管理员主要权限是对主机管理、内存管理、网络管理，管理数据库，管理用户。

l  审计管理员主要负责监督普通用户、审批人、安全管理员及系统管理员在系统中的操作。

应用场景举例

运维人员小张和小李共享主机和数据库账户，DBController进行管控后，运维小张对数据库进行访问操作，当执行操作对象涉及敏感数据时，触发DBController控制规则被拦截，于是小张登录DBController对访问对象和操作进行申请审批流程，审批通过后获得审批口令码；小张即便和小李共享主机和数据库账户，由于操作前进行动态口令和审批口令码认证，系统即可识别出操作人的真实身份，对小张审批通过后的语句可以合法放行；而小李没有动态口令和审批口令码认证，所以无法连接数据库进行操作。 

访问对象细粒度控制

用户风险

公司运维人员（第三方运维人员A、内部运维人员B、运维部门领导C）均可以访问数据库任意对象，敏感数据面临更多泄露风险。

解决方案

DBController系统可以对访问数据库对象进行细粒度管控，控制对象可以是库，可以是表，也可以精细到列；管控对象可以包括用户、登录IP、客户端工具、时间。

同时，系统可对运维人员访问的敏感对象做细粒度控制，根据不同运维人员访问敏感数据权限，能够通过内置的敏感数据访问规则，对其访问数据中的身份证号、银行卡号、电话号码、姓名、住址等敏感数据信息进行掩码处理，实现敏感数据动态遮蔽，防止内部运维人员泄露敏感数据。

应用场景举例

通过数据库安全运维工具，安全管理员小张可以对公司内部运维人员（运维人员A、B、C）运维访问对象进行管控规则设置；

Ø  第三方运维人员A只能访问公司数据库里不涉及敏感信息的数据，而敏感数据则不能访问

Ø  公司内部运维人员B可以访问数据库很多对象，而访问的敏感数据被遮蔽处理，看不到真实信息

Ø  公司运维部门领导C可以访问数据库任意对象，涉及敏感数据也能看到真实数据。 

申请审批流程细粒度控制

用户风险

运维小张对数据库中敏感字段进行修改操作，小张一不留神造成了误操作，从而导致前端相关的业务访问中止或出错，造成企业直接损失。

解决方案

DBController可对运维人员提供运维审批细粒度控制，敏感数据操作行为需要经过审批；审批通过后配发唯一口令码，确保操作执行者为信任用户，执行行为属获批行为。

系统支持设置多个审批员，避免审批人员出差或不在岗影响运维人员工作，只要有一个审批通过即可；同时系统也支持多级审批，提高运维审批强度和规范运维流程。

用户可以通过第三方工具登录数据库进行操作，简单口令认证，不改变原有工作习惯，口令通过者只能执行其申请的操作内容，杜绝误操作及违规操作。未经口令认证者无法操作敏感对象，防止越权操作。

应用场景举例

运维小张对数据库进行访问操作，当执行操作对象涉及敏感数据时，触发DBController控制规则被拦截，于是小张登录DBController对访问对象和操作进行申请审批流程，审批人看到小张的申请工单详情后给予了通过，小张获得审批口令码，完成登录认证后成功执行申请的操作，后又执行非审批语句系统判为违规操作拦截，小张随即又一次申请审批通过成功执行该操作。运维登录、操作细粒度控制

用户风险

由于未对运维人员操作时间、登录IP加以限制，导致第三方运维人员小张通过其他IP在非工作时间进行运维操作，带来运维安全隐患。

解决方案

DBController系统可对运维人员的IP、客户端工具、账号、时间等进行细粒度的登录控制。 

系统可以对于运维人员的执行操作进行细粒度控制，涉及数据库风险行为SQL注入、漏洞攻击、批量数据下载、危险SQL语句（如No where 、truncate）等，提供拦截、阻断、实时告警等管控模式。

系统针对数据库数据表，可按照受影响数据行数（阀值）进行精细管控，包括查询、更新和删除动作，超出阀值的行为进行阻断或拦截，防止高危操作或大批量数据泄露。

应用场景举例

运维人员小张提交的操作审批中会有一个针对操作对象的时间控制，即需要规定时间内完成所申请的操作内容，不在规定时间范围内操作则操作申请无效。对于审批后的定时任务，DBController可以在制定时间和周期完成规定脚本，并将执行结果告知申请人和审批人。

结语

目前，由于数据资产的敏感度高，运维人员工作强度大以及运维外包形式普遍等原因，政府、金融、社保、运营商、能源、大型企业等用户已经开始越发重视数据运维安全的建设，技术手段的引入能够更好的实现规范制度的落地，数据库安全运维系统的功能开发和演进全部基于用户侧的真实需求。在整个数据安全治理的技术框架下，作为内部访问安全的重要一环，运维行为的细粒度管控效果，正在逐渐显现出来，并能够为用户提供一种高效不出错的安全方案。