给“金税”数据加把锁

江苏省“金税工程”自1994年开始立项以来，紧跟国家税务总局，从基本的电算化报表录入，到今天大数据支撑供给侧的营改增全行业覆盖，已经走过了二十多年的历程。

随着财税体制改革步入蓝海，税务核心以及关联业务系统也是呈爆发性增长。

截止到2015年10月，各级关联子系统超过230余个，已经基本完成了集约型向分布式、集中化并存的过渡。税务行业的数据库系统作为存放数据的关键聚集体，其安全性关系到全省税务各级税收业务的流转，如何有效地保证核心业务数据的安全，防止敏感数据被窃取、被篡改，实现数据的保密性、完整性、可用性，已经成为我们必须直面且迫切需要解决的问题。

税务数据

面临三项安全风险

现阶段，税务数据面临的安全风险包括PMI权限分散、用户细化认知度不足和高等级业务难以快速溯源等。PMI（授权管理基础设施）权限分散， 现阶段税务CA（认证授权）体系构建基本成熟。但是现有业务系统侧重点差别大，关联流程复杂，PMI基本属于各自为政，而且随着人事管理体系的新要求，处室人员的交叉轮岗成为新常态，系统管理员稍有不慎就会发生张冠李戴的现象。税务每天和数字0到9打交道，但牵动的却是国计民生，缺少统一的PMI配置已对我省税务数据安全构成隐患。

用户细化认知度不足，征收、稽核、票据管理等核心系统基本采用典型三层架构部署，但对用户身份识别普遍采用扁平式单元化方式进行校验，多年前应用系统考虑兼容性和倒金字塔架构，在后续区域划分和角色的细化方面弱势明显，导致数据库认证用户缺乏辨识度，很难直观列出异常的访问和操作。

高等级业务难以快速溯源。随着管理精细化和税收科学化的要求，税务执行细粒度是今后发展的趋势，各业务处室的工作量也日益攀升，数据稽核、项目审批等一系列环节都增加了发生差错的可能性。目前对于高等级用户，由于行政权利的划分弱化了审核与制衡的职能，使得可控机制在某种程度上门户虚掩，存在着误操作抵赖，越权访问等安全风险，高等级业务难以快速溯源。

税务数据库防护总体设计原则

设计税务数据安全的三权分立机制，实现对管理员、审计员、操作员的权限划分，各角色用户只能在其权限范围内进行操作，同时对整个操作进行自身审计。

税务的核心业务需要7×24小时运行，网络架构不能随意变动。因此，税务数据库防护的设计必须适应多样化、复杂化的环境，防护设备的部署，除拦截模式外，需尽可能采用网络监听和预解码技术，部署过程中不能对原有系统造成影响，即无需在客户端或服务器端安装，也无需在整个通信链路中串联设备改变原有通信方式。

对于核心数据库的操作，防护规则需要细化到指令、表名、视图、字段等粒度，同时要能够探测数据库返回的错误代码和响应时间，这样一方面能够对诸如税务执行、收入预测等关键数值进行重点关注，另一方面也能够在数据库出现错误时及时响应，避免由于逻辑故障而造成业务损失。

省级税务应用系统繁多，需要数据库防护符合SQL-92标准，满足对Oracle、DB2、Microsoft SQL-Server、Sybase、Mysql等常见数据库系统的审计；同时由于业务系统对数据库的I/O不均衡，突发性、集中性操作非常多，这就要求数据库应用防护系统需要具备较高的性能。

税务数据库防护建设的效果和意义

要直观掌握税务核心业务系统运行的安全状况。税务业务系统的正常运行需要一个安全、稳定的环境。对信息管理部门来说，数据库防护能够直观地提供业务流量监控与审计事件统计分析数据，能够切实反映数据库的安全状况，为核心数据守好第一关。追踪溯源，便于事后追查原因与界定责任。而统一集中式可以进行扩展管理，可满足合规性要求，生成审计规范文档随着政务公开、预算决算公开，作为省级税务部门，已经面临一种或者几种合规性要求。