关于数据库安全的五点思考
对电信企业而言，数据库安全至关重要。试想充值系统出了问题会怎样?手机用户在月末查询账单的时候系统出现问题会怎样?下面是某电信企业数据库运维人员在数据库安全方面的一些心得，以及多备份安全专家给出的建议，希望对大家有所启迪和借鉴。
一、数据库版本与组件选择
1. 对数据库使用较高、较稳定的数据库版本，避免一些BUG触发引发的业务影响，比如一个ORA-04031，引发了结算系统share_pool的错，导致应用程序链接失败。
2. 建库的时候，明确生产数据库所需要使用的Oracle组件，只选择满足使用环境的最小组件集。
二、表管理
1. 备份表、临时表，规范化模式管理。
2. 使用独立的模式存储独立的业务对象。
3. DDL创建备份或临时对象说明变更管理存在风险，需要强化变更管理。
4. 一个schema中，存储的都是为完成某一个系统或模块而设计的表，不能将其他用途的数据表混合存储在该schema下。
5. 将临时表、备份表进行独立的schema存储管理，分离备份表和临时表，同时能够避免对业务数据存储造成空间碎片和性能影响，从而能够有效的降低数据备份和清理操作对业务运行的影响。
三、用户权限安全
1. 对于绝无必要的用户，清理出数据库。如用户Scott为Oracle的测试用户，在生产环境中，应该删除该用户及其相关对象，或者将其转移到测试环境中。
2. 对于已经被 LOCKED 的Oracle内置用户，我们需要评估是否在生产环境中使用，如果不需要使用，则可删除相关组件和用户。
3. 严格用户角色管理，防止权限授予过高，收回用户所具有的 resource 角色，创建权限限制更加严格的自定义角色。
4. 收回用户中不需要的角色。
四、访问安全
1. 规范数据库管理软件，实现管理软件的标准、统一化。
2. 为了防止连入数据库的应用程序存在后门，造成数据库安全隐患，检查所有连接数据库程序的安全性。通过使用门户监控登录数据库，禁止对数据库的直接操作。
3. 对已经连接的IP网段进行规范化、统一化的管理，每季度进行权限复核操作，对系统所属IP、用户进行权限梳理工作。对员工进行安全培训，增强员工的系统安全观念，做到细心操作。
4. 确认访问数据库的主机是否为已知用户，使用专门进行维护用的主机与数据库进行连接，禁止使用公用dblink对数据库直接操作。系统维护人员在某一天接到投诉，发现一个表下面的列少了，还好是一个状态列，先手动insert进去，随后找原因，发现是因为应用人员用dblink链接测试库时候，链接到了生产库中。由此可见数据库安全是多么重要。
5.审计 SYSDBA 的操作行为。
6.对重要业务表的查询等行为，全部进行审计。
五、备份安全
1.建立备份机制，对于关键业务的系统搭建NBU、DP、DSG等备份管理软件，针对业务情况、系统压力、带库资源等创建合适的备份策略，本单位都是在闲时每周做一次全备，一天一个增备，且操作系统有crontab或者是自带磁带备份主要目录。
2.对于关键业务系统可以使用当前主流容灾软件技术Oracle Goldengate、DG、Quest Shareplex等，在业务高峰期，比如我们系统账期业务较忙，CPU idle每天1%或者0%。那么这个时候就有必要考虑使用同步复制创建备机，将账期业务迁移至备库，不影响主库的业务。
多备份安全专家点评
可见这名运维人员数据库安全的思考很全面，不仅有版本管理、库表管理、权限限制等数据库自身管理，还有对外部访问的安全考虑，包括客户端程序管理、应用系统安全检查、客户端IP控制，甚至有DBA及重要操作的审计以及数据备份。当然，数据库安全涵盖的范围很广，入侵防御、访问身份认证、数据加密等其他安全措施也应考虑，如果一个安全管理人员从数据库建设伊始就考虑到这些因素，数据泄露或者篡改的风险就会大大降低。
数据库的风险主要来源于两个方面，一个是外部攻击，另一个是内部人员(有权限人员)的违规操作(故意或者无意)，本文中的案例，就是有权限人员的误操作。要消除此类操作带来的风险，除了要进行严格的权限控制外，对于高权限用户的操作审计也非常重要，同时要做好数据备份，一旦发生问题可以有补救措施。
值得注意的是，数据库安全措施要兼顾性能影响和安全效果两个方面。例如，很多单位采购独立数据库审计产品而非简单开启数据库自身审计功能，除了符合第三方审计要求外，也是为了保护数据库性能不受自身审计模块开启的影响。
多备份是国内一家云备份产品，可以实现企业、APP、网站数据的一键备份、恢复和迁移。所有数据资料都进行了国际通行的AES高强度加密算法加密，数据加密密钥由用户自由生成，除了用户自己外，没人能够解密数据。并且其基于Cloud 5技术实现多个云平台的数据互通，帮助企业或个人进行数据保护和管理。当出现任何问题时，立刻一键恢复，即可把原来的数据都恢复，做到‘原地满血复活’。