数据库安全问题

虽然许多数据库安全专家担心内部威胁和特权访问，但如果一个端点感染了恶意软件，就会对敏感数据的存储带来威胁。看似平常的端点有可能成为黑客入侵敏感数据库的入口。黑客可依赖简单的社交工程在端点上建立立足点，从而为进一步的数据库攻击找到出路。
例如，一位粗心的员工访问了一个不该访问的网站或收到了一个看似来自某个朋友的邮件，单击了其中的一个链接，然后该链接又引导他下载了一个恶意的恶意程序或间谍软件。
此后，恶意软件包分几个不同的阶段被安装到电脑上，并且是从Web的多个位置组装的。员工先下载了某个并不了解的恶意程序组件，然后此组件又通过访问Web，进一步从其它服务器下载其它不同组件，重新组合，甚至在受害者电脑中重新编译，最终形成极危险的恶意软件。危险的恶意软件可以先从网络内部进行探测，查找易受攻击的数据库和信息存储。
为对付这种攻击，数据库活动的行为分析在检测端点的异常行为方面更有效，因为一般情况下这种端点访问数据库信息的数量是有限的。
但是，今天的黑客都有一套自动化的方法来慢慢地透露信息，所以其行为与普通用户非常类似。
当心第三方带来的数据损害
云计算似乎无所不能，并日益流行，而作为外包服务的用户却应当对安全感到忧心忡忡。如果一家公司要与另一家在线服务供应商进行贸易，它应该检查对方的安全。
许多公司对于将认证交给云仍感到不踏实，除非公司对于供应商及其安全性感到非常满意。不幸的是，关于供应商是否安全，并没有什么权威性或学术性的标准，所以公司需要自己努力。
虽然要求处理信用card和金融数据的公司都要遵循支付卡行业数据安全标准（PCI DSS），但我们却没有一套保护个人身份信息的标准。即使是使用与PCI相同标准的公司也未必能保证真正的安全。
如何应对这种风险？关键的一点是，维持客户数据的公司应当使用WEB应用防火墙，并使用安全方法来开发软件，对于关键服务器还要坚决使用白名单技术。
此外，处理信用card数据和个人信息的公司还应当限制能够接触数据的服务器和雇员的数量。通过将关键信息存储到自己的服务器上，而不是将其交给第三方，公司就可以控制数据的保护。这里涉及的是Web2.0模式和整个云模式的问题，也许最佳的做法就是要把“好钢用在刀刃上”，要减少控制范围。
我们应该学到什么？
为什么数据库的安全损害常常一波未平，一波又起？原因很多，没有打补丁、启用不必要的数据库功能、失效的配置管理、缓冲区溢出、特权升级、错误的加密策略、选择了错误的第三方厂商等等。根据近年来的案例，我在这里总结几个典型的数据库安全教训
第一关、对用户安全管理

  Web数据库是个极为复杂的系统，因此很难进行正确的配置和安全维护，当然，必须首先要保证的就是数据库用户的权限的安全性。

  当用户通过Web方式要对数据库中的对象(表、视图、触发器、存储过程等)进行操作时，必须通过数据库访问的身份认证。多数数据库系统还有众所周知的默认账号和密码，可支持对数据库资源的各级访问。因此，很多重要的数据库系统很可能受到威协。

  用户存取权限是指不同的用户对于不同的数据对象有不同的操作权限。存取权限由两个要素组成：数据对象和操作类型。定义一个用户的存取权限就是要定义这个用户可以在哪些数据对象上进行哪些类型的操作。

  权限分系统权限和对象权限两种。系统权限由DBA授予某些数据库用户，只有得到系统权限，才能成为数据库用户。对象权限是授予数据库用户对某些数据对象进行某些操作的权限，它既可由DBA授权，也可由数据对象的创建者授予。

  第二关、定义视图

  为不同的用户定义不同的视图，可以限制用户的访问范围。通过视图机制把需要保密的数据对无权存取这些数据的用户隐藏起来，可以对数据库提供一定程度的安全保护。实际应用中常将视图机制与授权机制结合起来使用，首先用视图机制屏蔽一部分保密数据，然后在视图上进一步进行授权。

  第三关、数据加密

  数据安全隐患无处不在。一些机密数据库、商业数据等必须防止它人非法访问、修改、拷贝。如何保证数据安全?数据加密是应用最广、成本最低廉而相对最可靠的方法。数据加密是保护数据在存储和传递过程中不被窃取或修改的有效手段。

  数据加密系统包括对系统的不同部分要选择何种加密算法、需要多高的安全级别、各算法之间如何协作等因素。在系统的不同部分要综合考虑执行效率与安全性之间的平衡。因为一般来讲安全性总是以牺牲系统效率为代价的。

  如果要在Internet上的两个客户端传递安全数据，这就要求客户端之间可以彼此判断对方的身份，传递的数据必须加密，当数据在传输中被更改时可以被发觉。

  第四关、事务管理和故障恢复

  事务管理和故障恢复主要是对付系统内发生的自然因素故障，保证数据和事务的一致性和完整性。

  故障恢复的主要措施是进行日志记录和数据复制。在网络数据库系统中，分布事务首先要分解为多个子事务到各个站点上去执行，各个服务器之间还必须采取合理的算法进行分布式并发控制和提交，以保证事务的完整性。

  事务运行的每一步结果都记录在系统日志文件中，并且对重要数据进行复制，发生故障时根据日志文件利用数据副本准确地完成事务的恢复。

  第五关、数据库备份与恢复

  计算机同其他设备一样，都可能发生故障。计算机故障的原因多种多样，包括磁盘故障、电源故障、软件故障、灾害故障以及人为破坏等。一旦发生这种情况，就可能造成数据库的数据丢失。

  因此数据库系统必须采取必要的措施，以保证发生故障时，可以恢复数据库。数据库管理系统的备份和恢复机制就是保证在数据库系统出故障时，能够将数据库系统还原到正常状态。

  加强数据备份非常重要，数据库拥有很多关键的数据，这些数据一旦遭到破坏后果不堪设想，而这往往是入侵者真正关心的东西。不少管理员在这点上作得并不好，不是备份不完全，就是备份不及时。

  数据备份需要仔细计划，制定出一个策略测试后再去实施，备份计划也需要不断地调整。

  第六关、审计追踪机制

  审计追踪机制是指系统设置相应的日志记录，特别是对数据更新、删除、修改的记录，以便日后查证。日志记录的内容可以包括操作人员的名称、使用的密码、用户的IP地址、登录时间、操作内容等。若发现系统的数据遭到破坏，可以根据日志记录追究责任，或者从日志记录中判断密码是否被盗，以便修改密码，重新分配权限，确保系统的安全。