两位一体：论信息化中的应用安全和数据库安全

应用安全和数据库的安全就像是拼图中的拼图块，它们虽然不同，却彼此之间需要对方，缺少任何一个，都不能形成一个安全整体。如果其中一方出现安全隐患就会令整个安全防御彻底失效，如WEB应用程序存在SQL注入的时候，就会对整个系统和数据库产生更大的影响。为了减小攻击范围，开发人员和数据库管理员必须明晰他们在这个过程中的角色，共同工作，以避免WEB应用暴露任何敏感数据库。

如今，许多行业用户将大量有价值的客户数据存储于在线数据库，通过网络应用与外界交互。不论是通信、金融、电子政务、电子商务抑或是小小的个人博客，前端应用程序和后台数据库都不可避免地结合在我们现在的模型中，任何一个都不可离开另一个而单独存在。

但是由于那些应用程序在设计时是允许任何人、从任何地方登陆进入访问，因而也成为了通往隐藏在深处的重要数据的桥梁。比如在去年十二月，国内最大的程序员社区网站CSDN就遭到了黑客从WEB应用层的攻击，使得包含用户密码的数据库泄密。

那么如何才能使这个模型更安全呢?安恒信息专家将为您做详细的解读：使模型更安全的解决方法是让应用程序作为人与数据互动的唯一接口，应用程序界面是机器与数据互动的唯一接口。如果不是这样，那么数据交互就有可能不能被充分控制好，这将会是一个非常基本的潜在漏洞。即使访问方式定义明确，实际上应用程序依然有无数种方式令防护数据库失败，最终导致整个系统被黑客窃取或破坏。

安恒信息专家表示，安全管理人员和开发人员经常忽视或者错误地理解数据库，常仅仅关注于保护网络应用程序不受风险的威胁--比如说跨站脚本攻击或者注入攻击，而忘记了留意数据库本身的安全隐患。很明显，用户需要有专门的工具和策略来帮助网络应用程序开发人员保护后台数据库的安全性，而数据库开发人员必须确保他们的网络接口尽可能地安全。

同时安恒信息专家还指出，现在大多数用户都是凭感觉在运行数据库安全。绝大多数用户根本没有监控他们的数据库。更令人不安的是，大多数用户甚至不知道他们的重要数据的位置，很多管理员在调查中承认他们并不能肯定数据库中包含着重要信息。

在多数情况下，关键点在于网络应用程序本身对于攻击者而言没什么价值，他们只是利用应用程序作为窃取或破坏数据的一种手段，第一个防范措施便是确保不仅仅是数据库管理员了解重要数据在哪里存放、如何访问到，以及面临的实际威胁。我们通常将数据库看作是一个黑盒子，只向需要的人和应用程序提供访问的方法，当选取、更新或者插入操作成功后，人们会忘记还有一些事情会发生，所以说团队合作是关键，必须要把应用安全和数据安全做到两位一体。

我们所面临的网络威胁

数据库除了有与生俱来的安全隐患以外，当应用程序访问数据库时，还要考虑到更多的威胁。数据库打补丁、权限管理和连接管理都是典型的数据库安全防范措施，常见的由网络应用程序引发的安全威胁有SQL注入式攻击，XSS跨站攻击、不安全的会话处理和权限升级、目录遍历漏洞和敏感信息泄露等漏洞。我们会深入挖掘每一种模型，但是考虑到这些风险的存在，我们最重要的是尽可能少的给予特权，通过监控输入数据和建立安全连接来加强读取方式的安全性，同时还要限制数据库服务器对外暴露的机率。SQL注入、跨站脚本漏洞、目录遍历漏洞、敏感信息泄露等漏洞

SQL注入攻击SQL注入漏洞的产生原因是网站程序在编写时，没有对用户输入数据的合法性进行判断，导致应用程序存在安全隐患。SQL注入漏洞攻击的就是利用现有应用程序没有对用户输入数据的合法性进行判断，将恶意的SQL命令注入到后台数据库引擎执行的黑客攻击手段。

XSS跨站攻击跨站脚本攻击简称为XSS又叫CSS 是指服务器端的CGI程序没有对用户提交的变量中的HTML代码进行有效的过滤或转换，允许攻击者往WEB页面里插入对终端用户造成影响或损失的HTML代码。

未验证输入web请求信息在被Web应用使用之前都是未验证的，攻击者能够利用其中的弱点攻击服务器;攻击者通过伪造HTTP请求的各个部分，例如URL，查询字符串，头，cookies，表单域，隐藏域等绕过站点的安全机制。这些常见的伪造输入攻击通常包括：强制浏览，命令插入，跨站脚本，缓冲区溢出，格式化字符串，SQL注入，cookie中毒，隐藏域操作等等。

网络钓鱼网络钓鱼是通过大量发送声称来自于银行或其他知名机构的欺骗性垃圾邮件，意图引诱收信人给出敏感信息(如用户名、口令、帐号 ID 、 ATM PIN 码或信用卡详细信息)的一种攻击方式。最典型的网络钓鱼攻击将收信人引诱到一个通过精心设计与目标组织的网站非常相似的钓鱼网站上，并获取收信人在此网站上输入的个人敏感信息，通常这个攻击过程不会让受害者警觉。这些个人信息对黑客们具有非常大的吸引力，因为这些信息使得他们可以假冒受害者进行欺诈性金融交易，从而获得经济利益。受害者经常遭受显著的经济损失或全部个人信息被窃取并用于犯罪的目的。

通过应用程序造成隐私泄漏个人或团体的信息被其他不应获得者获取。如攻击者通过入侵大型网络社区、交友网站、免费邮箱等网络应用程序获取数据库用户信息，并利用获取到的个人用户信息进行欺骗获取更多的利益。

我们需要共同协作

安全问题不是某个个人的职责，关键需要团队的协作。这对于应用程序的安全问题来说更是如此，信息安全人员、开发人员、系统和数据库管理员都包括在内，这就是团队协作。除非你所在的单位已经拥有了一个成熟的安全环境，而且已经使用安全类库来处理数据库调用和数据验证，在数据库和应用程序之间有一层数据访问层，并确保所有的数据库权限都受到了严格的限制，在这种情况下应当让所有团队成员参与并且了解高层次的应用程序。通过共同协作，所有人都可以了解到这些安全威胁，随后可以共同想出更好的解决方案来应对。所有参与网络应用和数据库开发维护管理的人员都应该对目前存在的安全威胁有一个充分的认识和理解，这是非常重要的。我们必须要确保所有人员都理解应用程序的所有技术通信原理和数据流，了解数据从哪里来，如何到那里去的，以及数据是否和多个应用程序进行通信。这就是关于数据库保护的第一层措施。

数据库保护的第二层措施是安全架构。安全设计的基础有时候也被称作为安全架构，也就是说当我们以安全的方式设计数据库环境时，应减少安全威胁。如果攻击者无法直接访问数据库，这样就降低了他们攻击的灵活性。我们为攻击者提供的活动空间越大，他们就越容易得手。同样的，从相反的角度来看，我们就需要在后续做更多的工作，也就是说你必须确保对数据库的访问仅限于在需要的情况下进行系统访问，而且所有的访问都经过认证和加密的，而且不能影响到会话池。保证网络和系统设计的安全将会对保护数据库大有帮助，添加了数据库访问路径的限制能够大大地降低风险。

数据库保护的第三层措施是威胁建模。确定威胁的过程被称为是威胁建模，过去威胁建模是用在应用程序安全方面，用于确定应用程序的最高风险，这样安全人员就可以重点关注在这一领域。这个概念开始延用到安全的其它领域中。应注意的是这不是一个新的理念，实际上保险行业已经采用此理念有数百年的历史了，我们互联网行业只是最近几年才吸纳这一理念，并开始就此主题发表了许多文章。

威胁建模包括将那些了解此应用程序的人以及相关领域的专家召集在一起，大家共同理解应用程序的不同部分、功能性和固有的威胁。花一定的时间来全面理解此应用程序以及相关的威胁，可以定制出相对应的保护和测试方案，可以节省时间或者在有限的时间和预算范围内最大程度地降低威胁。威胁建模对于安全人员来说可以提供一种很好的手段来掌握全局、分解风险区域并与各小组单独协作，确保保护措施落到实处。

在对多个应用程序或开发项目进行威胁建模时，应作好记录，找到应用程序的共通性。这些共通性可以用于审查内部数据库访问标准、授权访问以及优化访问过程。

在编写策略时应当涵盖常见情况，并且明确地为开发人员和数据库管理人员提供指导，确保人人手中都有一份参考资料。一旦这些步骤执行到位后，可以开始从基础做起向数据库环境添加安全措施。

虽然各个系统环境都不相同，但是数据库配置对于保护数据是最为重要的部分之一，应当实现的常见配置有：

1.应当有恰当的人员维护和更新用户名单，其中这些用户可以访问受管理的应用服务环境中数据库。

2.系统管理员和其他相关的IT人员应该有充分的知识、技能并理解所有的关键的数据库安全要求。

3. 当部署数据库到受管服务环境中时，应该采用行业领先的配置标准和配套的内部文档。

4. 对于数据库功能不需要的默认用户帐户，应该锁定或是做过期处理。

5. 对于所有仍在使用中的默认用户帐户，应该主动地变更密码以采用强密码措施。

6. 应该给数据库内的管理员帐户分配不同的密码，这些帐户不应使用共享密码或组密码。

7. 措施要到位，用于保护数据字典以及描述数据库中所有对象的支持性元数据。

8. 对于任何访问数据库的基于主机的认证措施，应当有足够的适当的过程来确保这种访问类型的整体安全。

9. 数据库监控应到位，由能够根据需要对相关的人员进行告警的工具组成。

10. 保证数据库应用了所有相关的和关键的安全补丁。

我们需要保护重要的数据

“一定要保护好数据库的重要数据”，因为数据库对于IT行业来说就好像是保管金银珠宝的保险库。如果保险库不安全，财宝就很容易失窃，那主人就不会开心。

保护数据库服务器的方式有网络分段、系统分离，并将数据库服务器放置在一层或多层保护网的后面。

有许多新的技术，包括数据库活动监控软件、数据丢失防护(DLP)、将数据库分割，放到依据数据分类或风险模型的系统中，还有确保低安全性的应用程序无法访问到高安全程度的数据库等。

根据访问权限和账号，如果有多个部门的用户因同一事件需要登陆进入同一应用程序,应该采取保护措施，以确保一个部门的人员无法访问另一个部门的数据。这可以在数据库层面上完成,方法是让各个部门分别创建各自的数据库或桌面;这样的话可以实现数据分离，而且可以使用不同的数据库账号来加以保护。应用程序可以使用单一账号用于非认证请求服务，比如说用户登录;一旦发生此类情况，应用程序可以将数据库账号切换至同用户部门相关联的另一个账号。在设定许可权限时要防止通用账户访问任何公司数据。

除此之外，部门A的数据库账号不能访问部门B的数据。这样就阻止了攻击者越过公司的安全防线并扩大其接触范围。在进行应用程序数据库账号转换时必须非常小心，因为攻击者可能通过SQL注入攻击来迫使应用程序改变其连接。在某些单位，开发人员会写下他们自己的SQL查询命令，而对于其它一些单位，查询命令是由数据库管理员来编写和优化，然后再提供给开发者。

在最安全的环境下，这些查询命令由数据库管理员编写和执行，作为存储过程。存储过程是由应用程序执行的预定义语句。这样就使得SQL注入攻击更加难于得到利用。在这种特殊情况下，如果没有存储过程的话，攻击者可能已经作为管理员登录进入此应用程序并且取得此数据库完全控制权，而且只需要得到管理员用户名称即可实现。

同时还需要建立敏感数据的安全边界。通过采取相应的技术措施，为用户的各种数据库建立一个关于数据的安全边界。我们可以将数据库服务器置于标准的网络防火墙后面，并限制访问，以确保我们了解什么系统能够访问你的数据库，从而降低风险。但是千万不要以为简单的配备一些防火墙就可以防范这些安全威胁，可能还会有其他我们未发现的未知风险存在!

安全人员在开发新的安全数据安全模型时，安全人员应该进行测试，以确保他们提供了需要的保护级别，并且没有引入新风险。最后关于实现数据基于策略的自动管理问题，它包括数据的分类、备份、迁移、删除等，实现全面的数据存储管理自动化，这样不但减少了人为出错的可能性，也提高了数据库的安全性和可用性。使用一套优质的解决方案按照标准的规范进行设计和部署，提供充分的灵活性、扩展性和安全性，满足数据库安全保管方面当前和今后的法规要求。

回到源头，WEB安全刻不容缓

最小权限原则、保护数据库连接、分段服务器和网络、安全验证、安全边界和数据库安全配置对保护数据很有用处，但是这些不会解决攻击者所有的攻击企图。从广义上讲，数据库的安全首先依赖于网络系统。网络系统的安全是数据库安全的第一道屏障，外部入侵首先就是从入侵网络系统开始的。所以现在需要关注最普遍存在的威胁;WEB应用安全。

由于某些开发人员犯了非常低级的编程错误，比如：应用ID只能被应用使用，而不能被单独的用户或是其它进程使用。但是开发人员不这么做，他们给予了应用程序更多的数据访问权限。这就类似于医生因没有洗手而传播了传染病，从而导致各种漏洞的出现。

我们必须接受已经存在的应用缺陷和漏洞。通过发挥数据库管理员的安全职责去阻止因为应用缺陷和漏洞所造成的不良后果。比如如果开发人员不重视应用与数据交互的安全性，坚持最小权限原则，数据库管理员则有权在这场互动中占取主动，不给开发人员全权委托，数据库管理员可以不允许那么多的交互被授权;为了阻止黑客的渗透攻击从不可避免的网络程序应用漏洞中占便宜，数据库管理员也有权进行其他有效的安全控制。并且数据库管理员应对数据库进行加密保护，如密码不能使用明文保存;对所有应用层和数据层通信的审计监控将有助于快速识别和解决问题以及准确的判断任何安全事件的范围，直到实现安全风险最小化的目标。

假如出现数据外泄事件(如2011年年底的CSDN等网站的用户数据信息泄密事件)，责任也不止是在数据库管理员身上，开发人员也需要共同承担责任。其中一个非常重要的方面，开发人员能做的就是在用户能输入的地方最好过滤危险字符，这样可以防止黑客通过诸如SQL注入攻击获取到数据库的敏感信息。目前在各类行业网站上，各种WEB应用漏洞随处可见，可以被黑客们检测到(他们一般会用软件同时扫描数千个网站)。

开发人员在完成一套新的应用程序后应使用安全检测工具对其进行反复白盒测试，有条件的情况下可以请信息安全人员模拟黑客进行黑盒渗透测试，尽可能的发现应用程序的弱点并进行修补。如果想实现更完整的解决方案，更多有关的保护数据和数据库是应当实施源代码分析。这是一项冗长的处理过程，可以请安全服务提供商用专业的源码审计软件对应用程序代码进行详细的分析处理，这些工具会直接查找出更精确的缺陷结果。

同时应该与开发商或者安全厂商合作并确保能提供安全解决方案，这对于任何致力于部署网络应用数据库正常安全访问的用户都至关重要，WEB应用安全测试对于确保数据库的安全性有至关重要的作用。

一款好的工具可以有助于加快进度并且提供更好的检测结果和解决方案，以提供应用程序更好的的安全性，关键是进行反复评估以确保管理工作正常，对结果实施验证并加固，确保风险一经发现立即补救，并保证管理人员能够了解到相关问题的存在。

黑盒测试 黑盒测试是一种把软件产品当成是一个黑箱的测试技术，这个黑箱有入口和出口，测试过程中只需要了解黑箱的输入和输出结果，不需要了解黑箱里面具体是怎样操作的。这当然很好，因为测试人员不用费神去理解软件里面的具体构成和原理，测试人员只需要像用户一样看待软件产品就行了。

例如，银行转账系统提供给用户转账的功能，则测试人员在使用黑盒测试方法时，不需要知道转账的具体实现代码是怎样工作的，只需要把自己当成用户，模拟尽可能多的转账情况来检查这个软件系统能否按要求正常实现转账功能即可。

如果只像用户使用和操作软件一样去测试软件黑盒测试可能存在一定的风险。例如，某个安全性要求比较高的软件系统，开发人员在设计程序时考虑到记录系统日志的必要性，把软件运行过程中的很多信息都记录到了客户端的系统日志中，甚至把客户端连接服务器端的数据库连接请求字符串也记录到了系统日志中，像下面的一段字符串：

"Data Source=192.168.100.99;Initial Catalog=AcoDB;User ID=sa;PassWord=123456;

那么按照黑盒测试的观点，这是程序内部的行为，用户不会直接操作数据库的连接行为，因此检查系统日志方面的测试是不会做的。这明显构成了一个Bug，尤其是对于安全性要求高的软件系统，因为它暴露了后台数据库账号信息。

有人把黑盒测试比喻成中医，做黑盒测试的测试人员应该像一位老中医一样，通过“望、闻、问、切”的方法，来判断程序是否“有病”。这比单纯的操作黑箱的方式进了一步，这种比喻给测试人员一个启示，不要只是简单地看和听，还要积极地去问，积极地去发现、搜索相关的信息。应该综合应用中医看病的各种“技术”和理念来达到找出软件“病症”的目的，具体作法如下：

“望”，观察软件的行为是否正常;

“闻”，检查输出的结果是否正确;

“问”，输入各种信息，结合“望”、“闻”来观察软件的响应程度;

“切”，像中医一样给软件“把脉”，敲击一下软件的某些“关节”。

白盒测试如果把黑盒测试比喻成中医看病，那么白盒测试无疑就是西医看病了。测试人员采用各种仪器和设备对软件进行检测，甚至把软件摆上手术台解剖来看个究竟。白盒测试是一种以理解软件内部结构和程序运行方式为基础的软件测试技术，通常需要跟踪一个输入经过了哪些处理，这些处理方式是否正确。

在很多测试人员，尤其是初级测试人员看来，白盒测试是一种只有非常了解程序代码的高级测试人员才能做的测试。熟悉代码结构和功能实现的过程当然对测试有很大的帮助，但是从黑盒测试与白盒测试的区别可以看出，有些白盒测试是不需要测试人员懂得每一行程序代码的。

如果把软件看成一个黑箱，那么白盒测试的关键是给测试人员戴上一副X光透视眼镜，测试人员通过这副X光透视眼镜可以看清楚输入到黑箱中的数据是怎样流转的。

一些测试工具就像医院的检测仪器一样，可以帮助了解程序的内部运转过程。例如，对于一个与SQL Server数据库连接的软件系统，可以简单地把程序的作用理解为：把用户输入的数据通过SQL命令请求后台数据库，数据库把请求的数据返回给程序的界面层展示给用户。可以把SQL Server自带的工具事件探查器当成是一个检查SQL数据传输的精密仪器，它可以记录软件客户端与服务器数据库之间交互的一举一动，从而让测试人员可以洞悉软件究竟做了哪些动作。

在测试过程中，应该综合应用黑盒测试方法和白盒测试方法，按需要采用不同的技术组合。不要用黑盒测试方法和白盒测试方法来划分自己属于哪一类测试人员，一名优秀的测试人员应该懂得各种各样的测试技术和查找Bug的手段。

最后我们谈谈新的防火墙问题。到目前为止，我们都是侧重于预防措施。但在现实世界中，我们不可能总是改编程序和环境，所以我们必须采用其他技术措施。这就是为什么会产生新的防火墙。

防火墙用于应用程序或者监控流量的运行监控，也可以在执行运行时进行分析。防火墙可以找出攻击，并阻止尝试或修改的要求，来确保WEB服务器和数据库服务器的安全运行。

目前不光有WEB应用防火墙和网络防火墙能防范攻击者透过应用层和网络层的攻击;“数据库防火墙”也于这两年在不断的数据库泄密事件中出现在公众的视线里，国内称之为“数据库审计”产品，这些产品能给数据库提供实时的网络存储与访问的安全。

任何一个好的数据库安全策略都应包括监控和审计，以确保保护对象正常运行，并且运行在正确的位置上，这也是个非常耗时的过程。由于缺乏时间和工具，大多数用户对于数据库配置的检查往往也仅是抽查而已。

这里还需要指出的是目前多数人认为“数据库审计”等同于数据库安全，事实上，数据库安全远远不是数据库审计可以搞定的，数据库审计只是数据库安全的一个很小的方面，之所以有时候对等起来，一方面是由于市场宣传导致的误导，另一方面的确是这个部分的问题比较容易产品化/工具化，技术实现相对比较成熟。数据库安全应该包括：数据库资产管理、数据库配置加固、职责分离、特权用户控制、数据库弱点扫描和补丁管理、数据库加密、数据库审计。

最后，我们还是回到应用程序的安全以及与数据库之间的相互作用问题上。即我们必须要考虑到的问题是应用程序的安全以及与数据库之间的相互作用，尤其是对于当今流行的高度动态的和互动的网络应用程序而言。理解数据库与应用程序和系统环境之间的作用可以更加提升数据的安全性。

有问题是客观情况，其实我们需要的不是过多的责难，而是不断改进问题本身，当我们被迫把安全做的简单时，我们就被迫直接面对真正的问题。当我们不能用表面的装饰交差时，我们就不得不做好真正的本质部分。希望本文可以让读者了解到一系列管理和风险降低方面的策略，不论你是否愿意配置数据库防火墙、进行源代码审记或者严格地控制数据库管理系统，其目的都是相同的：做好应用安全和数据安全的两位一体，保护好重要数据。