数据库安全的这些事
2016-1-21 0:0:0 wondial数据库安全的这些事
数据库安全的这些事第一部分 一段时间 两件泄密“惨案”
一家有着多个分支机构的大型企业，IT信息化建设已是走在同行业的前列。企业的日常费用报销、合同审批等流程均是通过企业自建的工作流系统完成，
其后端核心数据库是Sql Server，同时这家公司的人力资源及财务系统亦是如此，。
某一时间，发生了这样的一件事情，这家公司对一项服务项目进行采购和招标流程后，确定了意向的公司，并且在工作流中进行了相关审批流程。
此事情按公司规定，暂时还处于保密阶段，但是相关信息很快便被泄露出去了。至于如何泄漏的原因不明。
同样是这家公司，公司人员的工资明细莫名其妙的被极个别的人员知道，并在小范围内传播。
虽然暗中进行了调查（从行政和技术的层面），却没有明显的证据表明是哪个人的行为或是究竟什么途径（现在想想，查不到是正常的），只是分析、猜测了可能的原因。
在这样的背景下，公司上了数据库安全审计解决方案，至此没有再发生过类似的泄密事情，而且也反推出了之前泄密事件发生的根源在哪：和数据库相关，而且是内部人员对数据库进行查询操作所为。
通过上述事例，自然引出老方要和大家要交流的一个话题，那就是数据库安全和审计。
第二部分 分类安全风险 探寻安全根源
从上述的事例中可以看出，作为公司核心数据信息的存储载体，数据库的安全和审计尤为重要，一般企业的数据库管理面临如下的风险或挑战：
1. 管理风险
A. 人员的职责、流程有待完善。内部员工的日常操作有待规范，第三方维护人员的操作监控缺失，离职员工可能
留有的后门等等，致使安全事件如果发生，无法追溯并定位真实的操作者。
2. 技术风险
A. 数据库是一个庞大而复杂的系统，出于稳定性的考虑，往往对补丁的跟进非常延后，更主要的是企业内部人员如果通过
应用层注入攻击等将使数据库处于一种受威胁的状态，目前的现实状况很难通过任何网络层设备来阻止攻击的威胁。
B. 对一些重要或敏感的数据的误操作，将会带来较大的风险及损失，如何阻断操作或警告是很大的挑战。
3. 审计风险
A. 现有的依赖于数据库日志文件的审计方法，存在诸多弊端，如数据库审计功能的开启会影响数据库本身的性能。
同时数据库日志文件本身存在被篡改的风险、自己的日志审计也难以体现审计信息的有效性权威性。
B. 通过域组策略等的审计方法，亦不能满足对审计的细粒度要求以及对操作者的记录等。
C. 有效的行为审计分析和灵活的审计策略定制策略缺失等。
再回头来看第一部分的两起泄密“惨案”，或多或少的均和管理风险、技术风险、审计风险有关联：
1. 如果这家公司在数据库方面的操作流程规范，数据库管理人员的职责明确，操作有监控记录的话，就可以实现对
数据库进行操作维护时要审批，且只有相应的权限的管理人员才能完成，同时也会对操作行为进行监控记录，这样是否可以避免以上“惨案”的发生呢？
2. 如果对一些重要的和敏感的数据进行操作时（如查询工资表、如重要人名），有报警或是阻断，是否也可以避免以上“惨案”的发生？
3. 如果有对全部或是部分的操作有记录，且利于查询或回放的，是否可以更好的定位原因及责任人呢，所谓亡羊补牢，也不算太迟吧！
相信，针对以上的风险采取相应的措施的话，不便可以事前预防，事中阻止，还可以事后可查。如此，数据库安全便大大的增加了，也不会出现这“惨案”那“惨案”了。
第三部分 魔高一尺道高一丈 兵来将挡的解决方案
“惨案”发生了，安全风险也分析及对号入座了。下面就要谈谈采取的解决方案了，到底要防些什么，怎么去防呢？
1. 管理制度及流程
制定相关的数据库管理流程，不同的人员对数据库的操作职责不一样，所有人员对数据库的操作均需要事前审批，对一些非常重要的操作需要二级以上审批。
申请操作时，需明确在什么人，什么时间，因为何事，对哪个数据库（或表），进行什么样的操作，可能有什么样的风险及采取的补救措施等。
（图示，为老方测试数据库审计解决方案中截图，下同）
2. 技术手段、审计手段
一般可以采取业界已存在的且比较成熟的数据库审计解决方案来实现：
A. 如实现实时记录用户对数据库系统的所有操作（如：插入、删除、更新、用户自定义操作等），并还原SQL操作命令包括源IP地址、目的IP地址、访问时间、
用户名、数据库操作类型、数据库表名、字段名等，如此，可实现对数据库安全事件准确全程跟踪定位。
B. 实时检查数据库不安全配置、数据库潜在弱点、数据库用户弱口令、数据库软件补丁层次、数据库潜藏木马等。
C. 进行全方位的多层（应用层、中间层、数据库层）的访问审计，通过多层业务审计，实现数据操作原始访问者的精确定位。
D. 针对于数据库的操作行为进行实时检测，并预设置风险控制策略，结合对数据库活动的实时监控信息，进行特征检测，任何尝试
的攻击操作都将被检测到并进行阻断或告警；并支持通过邮件、短信、SYSLOG、SNMP、屏幕等方式告警。
真实生产环境中的数据库安全风险不止这些，同样的针对性解决方案也不少。当然，完全使用自创的解决方案也是一种方法：如数据库系统本身的安全加固等。
但愿，通过此文能给大家一些提示，数据库安全尤为重要，且不仅仅是事后解决，事后诸葛亮，更应当做到事前预防为主。愿通过大家的努力，让承载重要数据信息的数据库更加安全可靠。
如果您的问题还没有解决，可以到 T+搜索>>上找一下答案
相关阅读
- 用友T3用友通系统重装后，没有账套备份，如何恢复账套2019-4-29 8:0:0
- 明细账权限设置时提示“没有操作员”？2019-4-29 8:0:0
- 用友t3用友通填制凭证时报“运行时错误429”2019-4-23 8:0:0
- 用友T3用友通填制凭证带出存货档案2019-4-23 8:0:0
- 用友T3用友通填制凭证中数量单价不符2019-4-23 8:0:0
- 用友T3用友通基金结余结转时报错，错误号为‘运行时错误3021’2019-4-23 8:0:0
- 用友T3用友通基础档案导入2019-4-23 8:0:0
- 用友T3用友通基础信息的删除2019-4-23 8:0:0
- 用友T3用友通基本科目设置和控制科目设置分别是什么-2019-4-23 8:0:0
- 用友T3用友通基本工资参数问题2019-4-23 8:0:0
最新信息
客户端在连接服务器时报ODBC SQL错误 客户端在连接服务器时报ODBC SQL错误
| 问题号: | 10999 |
|---|---|
| 解决状态: | 最终解决方案 |
| 软件版本: | 8.61 |
| 软件模块: | 系统管理 |
| 行业: | 通用 |
| 关键字: | 连接服务器 |
| 适用产品: | U861 |
| 问题名称: | 客户端在连接服务器时报ODBC SQL错误 |
| 问题现象: | 客户端在连接服务器时报ODBC SQL错误。 |
| 问题原因: | 见解决方案。 |
| 解决方案: | 在服务器端将配置服务器参数中的数据库服务器名由“.”改成IP地址，在高级中将超时设置由30改成1000后问题解决。 |
| 补丁编号: | |
| 录入日期: | 2016-03-16 15:23:45 |
| 最后更新时间: |
客户名称一列为空 客户名称一列为空
| 问题号: | 19888 |
|---|---|
| 适用产品: | U6 |
| 软件版本: | U6普及版3.2 |
| 软件模块: | 应收应付 |
| 问题名称: | 客户名称一列为空 |
| 问题现象: | 对销售发票审核时发现有一客户的客户名称一列为空,也就是不显示客户名称 |
| 问题原因: | - |
| 关键字: | |
| 解决方案: | 把cSBVCode列的值在数据库中修改为对应的值即可 |
| 行业: | |
| 补丁编号: | |
| 解决状态: | |
| 录入日期: | 2016-03-16 15:23:45 |
| 最后更新时间: |
