应用软件系统安全性设计

1、应用软件系统安全性设计序应用系统安全是由多个层面组成的，应用程序系统级安全、功能级安全、数据域安全是业务相关的，需要具体问题具体处理。 如何将权限分配给用户， 不同的应用系统拥有不同的授权 模型，授权模型和组织机构模型有很大的关联性，需要充分考虑应用系统的组织机构特点来决定选择何种授权模型。ADAD引言应用程序安全涵盖面很广，它类似于OSIOSI 网络分层模型也存在不同的安全层面。上层的安全只有在下层的安全得到保障后才有意义，具有一定的传递性。所以当一个应用系统宣称自己是安全的系统之前，必须在 不同层都拥有足够的安全性。2，应用系统刊身安全安全椅潮软件图 1 1：安全多层模型位于安全堆栈最底层

2、的就是传输层和系统认证的安全，考虑不周，将会引入经典的中间人攻击安全问题。再往上，就是借由防火墙，VPVP 假 IPIP 安全等手段保证可信系统或 IPIP 进行连接，阻止 DoSDoS 攻击和过滤某些不受欢迎的 IPIP 和数据包。在企业环境下，我们甚至会用 DMZZDMZZ 务面向公网的服务器和后端的数据库、支 持 服务系统隔离。此外，操作系统也扮演着重要的角色，负责进程安全，文件系统安全等安全问题，操作系统 一般还会拥有自己的防火墙，也可以在此进行相应的安全配置，此外，还可以部署专业的入侵检测系统用于监测和阻止各种五花八门的攻击，实时地阻止 TCP/IPTCP/IP 数据包。再往上的安全

3、就是 JVMJVM 的安全，可以通过 各种安全设置限制仅开放足够使用的执行权限。最后，应用程序自身还必须提供特定问题域的安全解决方 案。本文就以漫谈的方式聊聊应用系统本身的安全问题。1 1、应用系统安全涉及哪些内容1 1）系统级安全如访问 IPIP 段的限制，登录时间段的限制，连接数的限制，特定时间段内登录次数的限制等，象是应用系统 第一道防护大门。2 2）程序资源访问控制安全对程序资源的访问进行安全控制，在客户端上，为用户提供和其权限相关的用户界面，仅出现和其权限相 符的菜单，操作按钮；在服务端则对URLURL 程序资源和业务服务类方法的的调用进行访问控制。3 3）功能性安全功能性安全会对程

4、序流程产生影响，如用户在操作业务记录时，是否需要审核，上传附件不能超过指定大小等。这些安全限制已经不是入口级的限制，而是程序流程内的限制， 在一定程度上影响程序流程的运行。4 4） 数据域安全数据域安全包括两个层次，其一是行级数据域安全，即用户可以访问哪些业务记录，一般以用户所在单位 为条件进行过滤；其二是字段级数据域安全，即用户可以访问业务记录的哪些字段；以上四个层次的安全，按粒度从粗到细的排序是：系统级安全、程序资源访问控制安全、功能性安全、数 据域安全。不同的应用系统的系统级安全关注点往往差异很大，有很大部分的业务系统甚至不涉及系统级 安全问题。无明显组织机构的系统，如论坛，内容发布系统

5、则一般不涉及数据域安全问题，数据对于所有 用户一视同仁。不同的应用系统数据域安全的需求存在很大的差别，业务相关性比较高。对于行级的数据域安全，大致可 以分为以下几种情况：大部分业务系统允许用户访问其所在单位及下级管辖单位的数据。此时，组织机构模型在数据域安全控制 中扮演中重要的角色；也有一些系统，允许用户访问多个单位的业务数据，这些单位可能是同级的，也可能是其他行政分支下的 单位。对于这样的应用系统，一般通过数据域配置表配置用户所有有权访问的单位，通过这个配置表对数据进行访问控制；在一些保密性要求比较高系统中，只允许用户访问自己录入或参与协办的业务数据，即按用户 IDID 进行数据安全控制。还

6、有一种比较特殊情况，除进行按单位过滤之外，数据行本身具有一个安全级别指数，用户本身也拥有一 个级别指数，只有用户的级别指数大于等于行级安全级别指数，才能访问到该行数据。如在机场入境应用 系统，一些重要人员的出入境数据只有拥有高级别指数的用户才可查看。一般业务系统都有行级数据域控制的需求，但只有少数业务系统会涉及字段级数据域控制，后者控制粒度 更细。字段级数据域安全一般采用以下两种方式：通过配置表指定用户可以访问业务记录哪些字段，在运行期，通过配置表进行过滤。业务表的业务字段指定一个安全级别指数，通过和用户级别指数的比较来判断是否开放访问。程序资源访问控制安全的粒度大小界于系统级安全和功能性安全

7、两者之间，是最常见的应用系统安全问题，几乎所有的应用系统都会涉及到这个安全问题。此外，程序资源访问控制安全的业务相关性很小，容易总结出通用的模型，甚至可以通过的框架解决，如最近开始流行的 AcegiAcegi 安全框架就为解决该问题提供了通 用的方案。2 2、程序资源访问控制分为客户端和服务端两个层面类似于表单数据校验分为服务端和客户端校验两个层面，程序资源访问控制也可分为服务端和客户端访问 控制两个层面。客户端程序资源访问控制是对用户界面操作入口进行控制：即用户的操作界面是否出现某一功能菜单，在 具体业务功能页面中，是否包含某一功能按钮等。客户端程序资源访问控制保证用户仅看到有权执行的界 面

8、功能组件，或者让无权执行的功能组件呈不可操作状态。简言之，就是为不同权限的用户提供不同的操 作界面。服务端程序资源访问控制是指会话在调用某一具体的程序资源（如业务接口方法，URLURL 资源等）之前，判断会话用户是否有权执行目标程序资源，若无权，调用被拒绝，请求定向到出错页面，反之，目标程序资 源被成功调用。服务端的控制是最重要和最可靠的保障方式，而客户端的控制仅仅是貌似安全，实则存在隐患，不过它提高了用户界面的清洁度和友好性，否则需要等到用户点击了界面操作组件后，服务端才返回一个“您无权 访问该功能”之类的报错信息，未免有“误导犯错”的嫌疑。所以，一个完善而友好的程序资源访问控制 最好同时包

9、括服务端和客户端两个层面的控制，如下图所示：服务端入口缓安全访问控制程序资源耳业劳服务接皿役恍- url图 2:2:完善的程序资源访问控制模型假设，某一用户直接通过输入 URLURL 试图绕过客户端的控制直接发起对目标程序资源的调用，服务端作为最 后的防线，将成功阻止用户的越权行为。3 3、程序资源访问控制模型包括哪些概念程序资源要进行访问控制，必须先回答以下四个问题：1 1）程序资源如何描述自己前面已有提及，程序资源分为两种，其一为URLURL 资源，其二为服务接口业务方法。资源要实现控制必须事先描述自己，以便进行后续的管理和动作。根据应用系统复杂程度的不同，一般有以下几种描述方法：通过属性

10、描述 如应用系统中需控制的程序资源数量不大， 则可用对象属性描述， 论坛系统一般就采取这种方式。 如著名 的 JforuJforum m开源论坛，用户组对象拥有是否可收藏贴子，是否可添加书签等若干个程序资源访问控制属性。R 牌 N-厂立蜜引L 订净修押但当需管理的程序资源数量很大时，这种方式在扩展性上的不足马上就暴露出来了。通过编码描述为需安全控制的程序资源提供编码，用户通过授权体系获取其可访问的资源编码列表。在展现层的程序中（如 StrutsStruts 的 ActionAction ）判断目标程序资源对应的编码是否位于用户授权列表中。这种方式需要在 ActionAction 中通过硬编码来

11、识别目标程序资源，硬编码必须和数据库中描述的一致。访问控制逻辑和业务程序代码耦合较紧，在一定程度上增加了编码的工作量，维护性也稍差些。通过编码和程序资源描述串为了避免通过硬编码识别目标程序资源的缺点，在进行程序资源编码时，提供一个程序资源的描述串这一 额外的配置项。可以在运行期通过反射的方式得到目标程序资源对应的描述串，再通过描述串获取对应的 编码，而用户的权限即由资源编码组成，因此就可以判断用户是否拥有访问程序资源了。描述串是程序资源动态查找其对应编码的桥梁，URLURL 资源可以通过 AntAnt 模式匹配串作为描述串，如/images/*.gif/images/*.gif”, , /ac

12、tion/UserManager.do/action/UserManager.do ”等；而业务接口方法，可以通过方法的完全签名串作为才苗述串，如 com.ibm.userManager.addUsercom.ibm.userManager.addUser , , com.ibm.userManager.removeUsercom.ibm.userManager.removeUser 等。2 2）如何对用户进行授权一般不会直接通过分配程序资源的方式进行授权，因为程序资源是面向开发人员的术语；授权由系统管理员操作面向业务层面的东西，因此必须将程序资源封装成面向业务的权限再进行分配。如将com.i

13、bm.userManager.removeUsercom.ibm.userManager.removeUser 这个程序资源封装成删除用户”权限，当系统管理员将删除用户”权限分配给某一用户时，用户即间接拥有了访问该程序资源的权力了。角色是权限的集合，如建立一个“用户维护”的角色，该角色包含了新增用户、更改用户、查看用户、删 除用户等权限。通过角色进行授权可以免除单独分配权限的繁琐操作。如果组织机构具有严格的业务分工，用户的权限由职位确定，这时，一般会引入“岗位”的概念，岗位对 应一组权限集合，如“派出所所长”这个岗位，对应案件审批，案件查看等权限。岗位和角色二者并不完 全相同，岗位具有确定的行

14、政意义，而“角色”仅是权限的逻辑集合。角色，岗位是为了避免单独逐个分配权限而提出的概念，而“用户组”则是为了避免重复为拥有相同权限的多个用户分别授权而提出的。可以直接对用户组进行授权，用户组中的用户直接拥有用户组的权限。3 3）如何在运行期对程序资源的访问进行控制用户登录系统后，其权限加载到SessionSession 中，在访问某个程序资源之前，程序判断资源所对应的权限是否在用户的权限列表中。下面是一个用描述串描述程序资源，在运行期通过反射机制获知程序资源对应的权限，进行访问控制的流程图：图 3:3:通过程序资源描述串进行权限控制4 4）如何获取用户的菜单和功能按钮很多应用系统在设置用户访问

15、控制权限时，仅将系统所有的菜单列出，通过为用户分配菜单的方式分配权限，如著名的 shopexshopex 网上商城系统就采用这种方式。其实这种方式仅仅实现了客户端的访问控制，没有真实实现程序资源的访问控制，应该说是一种初级的，简略的解决方案。菜单和功能按钮是调用程序资源的界面入口，访问控制最终要保护的是执行业务操作的程序资源，而非界面上的入口。虽然有些应用系统通过菜单分配权限，在服务端也对程序资源进行控制，但这种权限分配的 方式有点本末倒置。业务服务接口OA!.l MAUTH kAU III ?ATrri i i,XUHl】iTII%Idin I 14mAUTH II -. A1 iirr r

16、 f ! IH 比较好的做法是，在建立程序资源和权限的关联关系的同时建立程序资源和界面功能组件（菜单，功能按钮）的关联关系。这样，就可以通过用户权限间接获取可操作的界面组件。下面是这种模型的实现的 ERER 图:图 4:4:客户端服务端程序资源访问控制安全的关联对象ERER 图从以上分析中，我们可以得到访问模型可能包含的以下一些概念，罗列如下：程序资源：受控的程序资源，包括 URLURL 或业务接口方法；界面功能组件：菜单，按钮等界面操作入口元素；权限：程序资源的业务抽象，一个权限可包含多个程序资源；角色：权限的集合，一个角色可包含多个权限；岗位：一个岗位包含多个权限，可看成是特殊的角色，岗位

17、具有行政的上意义，表示一个职位对应的所 有权限。用户：系统的操作者，拥有若干个权限。用户组：用户组是用户的集合，在很多应用系统中，用户组是为完成某项临时性的任务而组建的，有另 U U 于行政意义的单位，在另外一些应用系统中，用户组仅是为方便授权管理而建立的逻辑意义上的组织。组织机构：行政体系的上下级单位构成了组织机构，用户是组织机构的成员，在进行授权时，组织机构 扮演着重要的角色。4 4、授权模型功按钮芯程序资海关系用尸和t啷关系用尸名Characters (30)密码Character? (32)父莱单编号Character(30) Uri地址Chgct邱jlQQ)囹标Characteri

18、(WO)序号Integer功能按能用户用尸名 Character (30)弯码 Characters (32)用户名 Characters (30) 密吗Charact&rs (32)程序资源(SO)(SO)CharactersCharacters (32(32CharactersCharacters (1(1 00)00)Integer授权是权限管理层面的问题，其目的是如何通过方便，灵活的方式为系统用户分配适合的权限。根据应用系统的权限规模的大小及组织机构层级体系的复杂性，有不同的授权模型。为了避免将这一问题 变得过于理论化，下面，我们选取几个具有典型代表性的应用系统，通过分析这些应

19、用系统的授权模型来 总结常见授权的解决思路，希望能为您解决此类问题时提供参考。直接分配权限的授权模型对于论坛型的系统，我们前面有提到过，它的特点是没有组织机构的概念，也没有岗位的概念，授权方式 比较简单。为了划分不同用户的权限，一般会引入用户组的概念，如管理员组，一般用户组等。对用户组进行授权，用户通过其所属的用户组获取权限。图 5:5:简单型授权模型下面是 JforumJforum 论坛用户组授权的部分界面截图:ModeratiohYes w3n apprcua / deny rnsin mcdaratad f onjimsCan re mov e postsCan editCan imou

20、e messages between forumsCan lock and unl&ck topi图 6 6： JforumJforum 论坛授权界面用户的权限信息通过若干个开关属性或列表属性表示。所以这种类型的系统往往权限数量小且相对稳定。通过角色进行授权的授权模型 强调权限仅能通过角色的方式授予用户，而不能将权限直接授予用户是这一授权模型的特点，其中典型的代表就是 RBACRBAC型，RBACRBAC 目前比较流行的授权模型。它强制在用户和权限之间添加一个间接的隔离层， 防止用户直接和权限NOCannot moderate these forums:全部允许耋美妈蚂入二手市场工作日

21、志 v用户关联。虽然通过这种方式可以防止权限的分配过于零散的问题，但也降低了权限分配 的灵活性。如某一部门主管希望临时将交由副主管代理，在 RBARBA 版权模型中，这种需求就变得比较棘手了。岗位+组织机构的授权模型对于拥有组织机构且用户岗位职责明确的应用系统，可以在系统层面建立组织机构中的各个岗位，并为这 些岗位分配好权限，然后将岗位分配给部门，新增部门员工时，必须选择部门内的一个岗位。近几年以思维加速、普元和科诺为代表的面向业务的快速开发平台概念比较走俏。思维加速所用的授权模 型就是岗位+组织机构授权模型的代表者。该模型非常强调组织机构在授权模型所起的作用，所以对组织机构进行了更多的定义：

22、1 1） 组织：组织是一个虚拟的机构，它的存在只是为了连接上下级机构的行政关系，组织下级可以包括组织或部门，职员不直接隶属于组织，岗位也不能直接分配给组织。2 2） 部门：是一个具体的机构，职员可以直接隶属于部门，部门下可以包含若干用户组，岗位可以分配给部 门或用户组，部门和用户组内的职员拥有其中的一个岗位；3 3） 用户组：为完成临时任务而组建的团队，非正规的行政建制，可以包括若干个成员。下图就是用思维加速平台设计的一个组织机构授权模型:图 7:7:思维加速的授权模型首先将岗位分配给部门或用户组，如将“产品经理”，“产品技术经理”，“部门经理”和“开发工程师”这 4 4 个岗位分配给研发部下的 3.03.0 产品组，然后在部门添加新职员时，必须为职员选择所属的用户组，并 分配一个用户组的岗位。此外，系统管理员也可以直接将权限分配给用户，让用户拥有岗位之外的权限，以增加授权的灵活性。在 授权体系之外，还拥有权限的转移功能，即用户可以临时将其所有或部分权限转移给某个用户代理。