2.7.1　绕过架构

多层应用程序中问题的一大来源是，一层中某个组件绕过要求的架构组件直接访问另一层中某个组件，而它所绕过的组件是用于管理被访问组件的数据流的关键角色。图2-5给出了两个这样的影响应用程序健壮性的实例。

例如，逻辑层可能被架构来分离管理业务逻辑的组件和管理数据的访问的组件。在路径1中，接口层的开发人员直接访问了对数据层进行查询的组件，绕过了逻辑层的一个或多个组件，而这些逻辑层的组件原本被设计为唯一能够访问数据查询组件的组件。

架构中的这种违例所造成的问题是，数据访问组件的开发人员仅知道他们的组件是如何被逻辑层访问的，因为架构没有提供来自其他层组件的访问。如果对数据访问组件作了改动，他们可能只会和逻辑层的开发人员沟通，并对改动和他们所在层的组件进行测试，这里假定改动和架构是一致的。这些改动可能会引起故障，因为来自用户接口层的直接调用没有修改以与数据访问组件保证一致，而且也不是测试的一部分。

在路径2中，管理业务逻辑的组件的开发人员直接访问了一张数据表，而不是通过架构中提供的数据访问组件来访问。类似于路径1中的问题，如果表的结构有变动，那么变动信息可能只会传达给数据访问组件，假定它们是被允许的访问机制。除非改变表结构的人明确测试了架构认可的路径之外的许多通过数据的其他可能路径，否则这种违例不会被发现。因此，路径2将会开始遭遇失效和错误输出，因为它不知道自己所访问的表发生的变动。

路径2中问题的另一个实例是，开发人员实现一个存储过程，这个存储过程绕过被允许的数据访问组件来修改或操作数据。对于敏感或复杂的信息而言，数据更新往往是技术和业务逻辑问题的复杂混合体。因此，架构师和数据库管理员通常会定义一套组件（所谓持久层中的SQL更新存储过程或组件），这些组件对写代码来修改现有数据的开发人员而言是必须要使用的。

绕过这些数据访问组件会导致应用程序出现古怪行为。事实上，数据访问组件通常会被慎重地设计，用来检索大量的数据。当被绕过时，原本高效的过程马上会降低性能甚至引起故障。开发人员经常不清楚查询操作的完整上下文。例如，他们可能不清楚数据库表索引是如何建立的。根据这些细节的不同，同样的SQL查询执行起来差别可能非常大。结果是非常缓慢的响应、不可预知的行为、硬件资源的浪费和商业损失。

绕过这些数据访问组件也会削弱确保数据完整性所需的控制和协调。结果就是数据损坏不被察觉，直到在不一致的报告中被发现。不被允许的数据访问可以不被察觉地通过功能测试，要发现它的最好方式是根据有良好定义的数据访问规则来跟踪数据流。

绕过架构的一种特别严重的形式向黑客提供了对敏感或保密数据的未授权访问。通常，需要对用户在系统中的访问层次进行授权。如果允许来自用户接口的入口通过一条绕过用户认证流程的路径来访问功能或数据，正如路径3那样，那么安全性就很容易被破坏。功能和数据库通常被设计为假定用户请求已经由认证过程审查通过，该认证过程可以保护数据免于未经授权的访问。因此，应当检测到这种安全弱点，方法是跟踪来自用户接口的数据流，确保所有的入口路径在访问应用程序的其他层时都能被适当地认证。