应用软件系统安全性设计

应用软件系统安全性设计(1)

?2006-12-19 10:13 ?陈雄华?IT168 ?我要评论(0)

?摘要：应用系统安全是由多个层面组成的，应用程序系统级安全、功能级安全、数据域安全是业务相关的，需要具体问题具体处理。如何将权限分配给用户，不同的应用系统拥有不同的授权模型，授权模型和组织机构模型有很大的关联性，需要充分考虑应用系统的组织机构特点来决定选择何种授权模型。

?标签：软件??系统??安全??设计

?

Oracle帮您准确洞察各个物流环节引言

应用程序安全涵盖面很广，它类似于OSI网络分层模型也存在不同的安全层面。上层的安全只有在下层的安全得到保障后才有意义，具有一定的传递性。所以当一个应用系统宣称自己是安全的系统之前，必须在不同层都拥有足够的安全性。

图1：安全多层模型

位于安全堆栈最底层的就是传输层和系统认证的安全，考虑不周，将会引入经典的中间人攻击安全问题。再往上，就是借由防火墙，VPN或IP安全等手段保证可信系统或IP进行连接，阻止DoS攻击和过滤某些不受欢迎的IP和数据包。在企业环境下，我们甚至会用DMZ将面向公网的服务器和后端的数据库、支持服务系统隔离。此外，操作系统也扮演着重要的角色，负责进程安全，文件系统安全等安全问题，操作系统一般还会拥有自己的防火墙，也可以在此进行相应的安全配置，此外，还可以部署专业的入侵检测系统用于监测和阻止各种五花八门的攻击，实时地阻止TCP/IP数据包。再往上的安全就是JVM的安全，可以通过各种安全设置限制仅开放足够使用的执行权限。最后，应用程序自身还必须提供特定问题域的安全解决方案。本文就以漫谈的方式聊聊应用系统本身的安全问题。

1、应用系统安全涉及哪些内容

1)系统级安全

如访问IP段的限制，登录时间段的限制，连接数的限制，特定时间段内登录次数的限制等，象是应用系统第一道防护大门。

2)程序资源访问控制安全

对程序资源的访问进行安全控制，在客户端上，为用户提供和其权限相关的用户界面，仅出现和其权限相符的菜单，操作按钮；在服务端则对URL程序资源和业务服务类方法的的调用进行访问控制。

3)功能性安全

功能性安全会对程序流程产生影响，如用户在操作业务记录时，是否需要审核，上传附件不能超过指定大小等。这些安全限制已经不是入口级的限制，而是程序流程内的限制，在一定程度上影响程序流程的运行。

4)数据域安全

数据域安全包括两个层次，其一是行级数据域安全，即用户可以访问哪些业务记录，一般以用户所在单位为条件进行过滤；其二是字段级数据域安全，即用户可以访问业务记录的哪些字段；???????

以上四个层次的安全，按粒度从粗到细的排序是：系统级安全、程序资源访问控制安全、功能性安全、数据域安全。不同的应用系统的系统级安全关注点往往差异很大，有很大部分的业务系统甚至不涉及系统级安全问题。无明显组织机构的系统，如论坛，内容发布系统则一般不涉及数据域安全问题，数据对于所有用户一视同仁。

不同的应用系统数据域安全的需求存在很大的差别，业务相关性比较高。对于行级的数据域安全，大致可以分为以下几种情况：???????

大部分业务系统允许用户访问其所在单位及下级管辖单位的数据。此时，组织机构模型在数据域安全控制中扮演中重要的角色；??????

也有一些系统，允许用户访问多个单位的业务数据，这些单位可能是同级的，也可能是其他行政分支下的单位。对于这样的应用系统，一般通过数据域配置表配置用户所有有权访问的单位，通过这个配置表对数据进行访问控制；

在一些保密性要求比较高系统中，只允许用户访问自己录入或参与协办的业务数据，即按用户ID进行数据安全控制。?????????

还有一种比较特殊情况，除进行按单位过滤之外，数据行本身具有一个安全级别指数，用户本身也拥有一个级别指数，只有用户的级别指数大于等于行级安全级别指数，才能访问到该行数据。如在机场入境应用系统，一些重要人员的出入境数据只有拥有高级别指数的用户才可查看。

一般业务系统都有行级数据域控制的需求，但只有少数业务系统会涉及字段级数据域控制，后者控制粒度更细。字段级数据域安全一般采用以下两种方式：

通过配置表指定用户可以访问业务记录哪些字段，在运行期，通过配置表进行过滤。

业务表的业务字段指定一个安全级别指数，通过和用户级别指数的比较来判断是否开放访问。

程序资源访问控制安全的粒度大小界于系统级安全和功能性安全两者之间，是最常见的应用系统安全问题，几乎所有的应用系统都会涉及到这个安全问题。此外，程序资源访问控

制安全的业务相关性很小，容易总结出通用的模型，甚至可以通过的框架解决，如最近开始流行的Acegi安全框架就为解决该问题提供了通用的方案。

2、程序资源访问控制分为客户端和服务端两个层面

类似于表单数据校验分为服务端和客户端校验两个层面，程序资源访问控制也可分为服务端和客户端访问控制两个层面。

客户端程序资源访问控制是对用户界面操作入口进行控制：即用户的操作界面是否出现某一功能菜单，在具体业务功能页面中，是否包含某一功能按钮等。客户端程序资源访问控制保证用户仅看到有权执行的界面功能组件，或者让无权执行的功能组件呈不可操作状态。简言之，就是为不同权限的用户提供不同的操作界面。

服务端程序资源访问控制是指会话在调用某一具体的程序资源（如业务接口方法，URL 资源等）之前，判断会话用户是否有权执行目标程序资源，若无权，调用被拒绝，请求定向到出错页面，反之，目标程序资源被成功调用。

服务端的控制是最重要和最可靠的保障方式，而客户端的控制仅仅是貌似安全，实则存在隐患，不过它提高了用户界面的清洁度和友好性，否则需要等到用户点击了界面操作组件后，服务端才返回一个“您无权访问该功能”之类的报错信息，未免有“误导犯错”的嫌疑。所以，一个完善而友好的程序资源访问控制最好同时包括服务端和客户端两个层面的控制，如下图所示：

图2：完善的程序资源访问控制模型

假设，某一用户直接通过输入URL试图绕过客户端的控制直接发起对目标程序资源的调用，服务端作为最后的防线，将成功阻止用户的越权行为。

3、程序资源访问控制模型包括哪些概念

程序资源要进行访问控制，必须先回答以下四个问题：

1) 程序资源如何描述自己

前面已有提及，程序资源分为两种，其一为URL资源，其二为服务接口业务方法。资源要实现控制必须事先描述自己，以便进行后续的管理和动作。根据应用系统复杂程度的不同，一般有以下几种描述方法：

通过属性描述

如应用系统中需控制的程序资源数量不大，则可用对象属性描述，论坛系统一般就采取这种方式。如着名的Jforum开源论坛，用户组对象拥有是否可收藏贴子，是否可添加书签等若干个程序资源访问控制属性。但当需管理的程序资源数量很大时，这种方式在扩展性上的不足马上就暴露出来了。

通过编码描述

为需安全控制的程序资源提供编码，用户通过授权体系获取其可访问的资源编码列表。在展现层的程序中（如Struts的Action）判断目标程序资源对应的编码是否位于用户授权列表中。

这种方式需要在Action中通过硬编码来识别目标程序资源，硬编码必须和数据库中描述的一致。访问控制逻辑和业务程序代码耦合较紧，在一定程度上增加了编码的工作量，维护性也稍差些。

通过编码和程序资源描述串

为了避免通过硬编码识别目标程序资源的缺点，在进行程序资源编码时，提供一个程序资源的描述串这一额外的配置项。可以在运行期通过反射的方式得到目标程序资源对应的描述串，再通过描述串获取对应的编码，而用户的权限即由资源编码组成，因此就可以判断用户是否拥有访问程序资源了。

描述串是程序资源动态查找其对应编码的桥梁，URL资源可以通过Ant模式匹配串作为描述串，如“/images/**.gif”，“/action/UserManager.do”等；而业务接口方法，可以通过方法的完全签名串作为描述串，如，等。

2) 如何对用户进行授权

一般不会直接通过分配程序资源的方式进行授权，因为程序资源是面向开发人员的术语；授权由系统管理员操作面向业务层面的东西，因此必须将程序资源封装成面向业务的权限再进行分配。如将这个程序资源封装成“删除用户”权限，当系统管理员将“删除用户”权限分配给某一用户时，用户即间接拥有了访问该程序资源的权力了。

角色是权限的集合，如建立一个“用户维护”的角色，该角色包含了新增用户、更改用户、查看用户、删除用户等权限。通过角色进行授权可以免除单独分配权限的繁琐操作。

如果组织机构具有严格的业务分工，用户的权限由职位确定，这时，一般会引入“岗位”的概念，岗位对应一组权限集合，如“派出所所长”这个岗位，对应案件审批，案件查看等权限。岗位和角色二者并不完全相同，岗位具有确定的行政意义，而“角色”仅是权限的逻辑集合。

角色，岗位是为了避免单独逐个分配权限而提出的概念，而“用户组”则是为了避免重复为拥有相同权限的多个用户分别授权而提出的。可以直接对用户组进行授权，用户组中的用户直接拥有用户组的权限。

3) 如何在运行期对程序资源的访问进行控制

用户登录系统后，其权限加载到Session中，在访问某个程序资源之前，程序判断资源所对应的权限是否在用户的权限列表中。下面是一个用描述串描述程序资源，在运行期通过反射机制获知程序资源对应的权限，进行访问控制的流程图：

图3：通过程序资源描述串进行权限控制

?

4)如何获取用户的菜单和功能按钮

很多应用系统在设置用户访问控制权限时，仅将系统所有的菜单列出，通过为用户分配菜单的方式分配权限，如着名的shopex网上商城系统就采用这种方式。其实这种方式仅仅实现了客户端的访问控制，没有真实实现程序资源的访问控制，应该说是一种初级的，简略的解决方案。

菜单和功能按钮是调用程序资源的界面入口，访问控制最终要保护的是执行业务操作的程序资源，而非界面上的入口。虽然有些应用系统通过菜单分配权限，在服务端也对程序资源进行控制，但这种权限分配的方式有点本末倒置。

比较好的做法是，在建立程序资源和权限的关联关系的同时建立程序资源和界面功能组件（菜单，功能按钮）的关联关系。这样，就可以通过用户权限间接获取可操作的界面组件。下面是这种模型的实现的ER图：

图4：客户端服务端程序资源访问控制安全的关联对象ER图

从以上分析中，我们可以得到访问模型可能包含的以下一些概念，罗列如下：

◆程序资源：受控的程序资源，包括URL或业务接口方法；

◆界面功能组件：菜单，按钮等界面操作入口元素；

◆权限：程序资源的业务抽象，一个权限可包含多个程序资源；

◆角色：权限的集合，一个角色可包含多个权限；

◆岗位：一个岗位包含多个权限，可看成是特殊的角色，岗位具有行政的上意义，表示一个职位对应的所有权限。

◆用户：系统的操作者，拥有若干个权限。

◆用户组：用户组是用户的集合，在很多应用系统中，用户组是为完成某项临时性的任务而组建的，有别于行政意义的单位，在另外一些应用系统中，用户组仅是为方便授权管理而建立的逻辑意义上的组织。

◆组织机构：行政体系的上下级单位构成了组织机构，用户是组织机构的成员，在进行授权时，组织机构扮演着重要的角色。

4、授权模型

授权是权限管理层面的问题，其目的是如何通过方便，灵活的方式为系统用户分配适合的权限。

根据应用系统的权限规模的大小及组织机构层级体系的复杂性，有不同的授权模型。为了避免将这一问题变得过于理论化，下面，我们选取几个具有典型代表性的应用系统，通过分析这些应用系统的授权模型来总结常见授权的解决思路，希望能为您解决此类问题时提供参考。

直接分配权限的授权模型

对于论坛型的系统，我们前面有提到过，它的特点是没有组织机构的概念，也没有岗位的概念，授权方式比较简单。为了划分不同用户的权限，一般会引入用户组的概念，如管理员组，一般用户组等。对用户组进行授权，用户通过其所属的用户组获取权限。

图5：简单型授权模型

下面是Jforum论坛用户组授权的部分界面截图：

图6：Jforum论坛授权界面

用户的权限信息通过若干个开关属性或列表属性表示。所以这种类型的系统往往权限数量小且相对稳定。

通过角色进行授权的授权模型

强调权限仅能通过角色的方式授予用户，而不能将权限直接授予用户是这一授权模型的特点，其中典型的代表就是RBAC模型，RBAC是目前比较流行的授权模型。它强制在用户和权限之间添加一个间接的隔离层，防止用户直接和权限关联。虽然通过这种方式可以防止权限的分配过于零散的问题，但也降低了权限分配的灵活性。如某一部门主管希望临时将交由副主管代理，在RBAC授权模型中，这种需求就变得比较棘手了。

岗位＋组织机构的授权模型