应用软件系统安全性设计
软件安全设计
3. 软件安全设计原则
3）权限分离原则 权限分离原则在软件设计中是指，将软件功能设
计为需要在两个或更多条件下才能实现，以防止 一旦出现问题，整个软件都可能面临风险。
实际上这一原则也是最小权限原则的一种体现。
问，锁定账户。
3. 软件安全设计原则
7）开放设计原则
软件的开放设计原则是指，软件设计本身应该是 开放的，安全防御机制的实现应该不依赖于设计 本身。
举例：
软件的安全性不应该依赖于设计的保密。
保护机制的设计应该对团队成员的审查工作开放，让 一个团队成员发现系统漏洞总比让攻击者发现要好。
8）要有应对失败的计划（Plan on failure）。
9）系统失效时进入安全模式（Fail to a secure mode）。
10）安全特性不等于安全的特性（Security features != Secure features）。
11）绝不要将安全仅维系于隐匿（Never depend on security through obscurity alone）。
应用于加密设计的柯克霍夫（Kerckhoff）原则，即密 码的安全性不依赖于对加密系统或算法的保密，而依 赖于密钥。利用经过公开审查的、已经证明的、经过 测试的行业标准，而不是仅采用用户自己开发的保护 机制是值得推荐的做法。
3. 软件安全设计原则
8）保护最弱一环原则
是指保护软件系统中的最弱组件。
从工程管理的角度，软件设计可以分为总体设计 和详细设计两个子阶段。
1. 软件设计阶段的主要工作
应用软件开发安全
不要以明文形式存储数据库连接字符串或密码等敏感信息，应该进行加密，并存储经过加密的字符串。
如果通过网络传输敏感数据，禁止明文传输，应对数据进行加密。同时确保通信通道的安全，通常的做法是使用SSL/TLS、HTTPS、SFTP 和 IPSec 等安全协议进行通信。
16
异常处理
不要向客户端泄漏应用程序内部信息：发生故障时，不要在出错消息中暴露应用系统内部的敏感信息。例如，不要暴露包括函数名以及调试信息（出问题的行数，堆栈信息等）。应向客户端返回一般性错误消息。
不在网络上以明文方式传输密码：以明文方式在网络上传输的密码容易被窃听，为了解决这一问题，应确保通信通道的安全，例如，使用 SSL 对数据流加密。
保护身份认证的凭据：身份认证的凭据（如 Cookie）被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护认证的凭据。此外，还应限制认证凭据的有效期，以减少攻击的威胁。
7
访问控制和授权
应用系统的认证、授权尽量使用统一的认证、授权平台来进行。如果因为某种原因需要建立应用系统自己的认证、授权体系，整个认证过程需要进行加密，密钥长度不能低于 128 位。
8
访问控制和授权
应用系统的设计应包含用户权限分配和管理功能：
系统读、写、执行权限设计
系统查看、配置、修改、删除、登录、运行等权限设计
6
应用系统上线投产的安全要求
规划应用系统上线所需要的资源需求和准备工作，包括但不限于以下内容：
应用系统上线对软件、硬件资源和网络的要求。
应用程序的安全性和保密性设计
应用程序的安全性和保密性设计1.认证和授权：在应用程序中，必须确保用户身份的真实性，并根据用户的权限授予合适的访问权限。
为了实现这一点，可以采用多种方法，例如密码登录、指纹识别、双因素身份认证等。
同时，还应该采用访问控制策略，仅允许授权用户访问其需要的数据和功能。
2.数据加密：为了保护敏感数据的机密性，应该对数据进行加密。
对于存储在数据库中的数据，可以使用对称加密或非对称加密的方式进行加密。
对于传输过程中的数据，可以使用安全套接层（SSL）或传输层安全（TLS）协议来加密通信通道。
通过使用加密技术，即使数据被泄露也难以解密，保护用户的隐私和敏感信息。
3.安全漏洞和弱点分析：在应用程序设计阶段和发布后，需要进行安全漏洞和弱点分析。
通过对应用程序进行渗透测试、代码审查和漏洞扫描，可以及时发现和修复潜在的安全漏洞和弱点。
此外，还应密切关注和及时更新应用程序所使用的组件和库的安全补丁，以防止已知的攻击手法和漏洞被利用。
4.安全日志和监控：应用程序应该记录安全事件和用户访问日志，以便进行安全审计和故障排除。
通过监控用户行为和异常活动，可以及时发现潜在的安全威胁和攻击，并采取相应的措施进行应对。
此外，还可以使用入侵检测系统（IDS）和入侵防御系统（IPS）等安全工具来监测和阻止恶意行为。
5.安全更新和管理：对于应用程序的安全性和保密性，持续的更新和管理是必要的。
应该及时修复已知的安全漏洞，并发布安全补丁。
同时，在设计应用程序时应考虑到后续的维护和更新，并制定相应的安全更新策略，以确保应用程序的安全性和保密性能够持续得到保障。
总之，应用程序的安全性和保密性设计是一项重要的工作。
通过认证和授权、数据加密、安全漏洞和弱点分析、安全日志和监控、安全更新和管理等措施，可以提高应用程序的安全性和保密性，保护用户的隐私和数据安全。
软件安全性评估模型及评估工具设计与实现
软件安全性评估模型及评估工具设计与实现随着互联网的普及，软件的发展和应用越来越广泛，软件安全性问题日益凸显。
软件安全性评估模型及评估工具的设计与实现已成为一种急切需求。
本文将从软件安全性评估模型的概念、类型以及评估工具的设计与实现等多个方面探讨该主题。
一、软件安全性评估模型的概念及类型软件安全性评估模型是通过对软件系统的安全性方面进行评估，以获取和分析安全性情况的一种方法。
一般来说，软件安全性评估模型主要由安全性要求、评估标准和评估方法构成。
1. 安全性要求：如机密性、完整性、可用性等，作为软件安全性的基本指标，是对软件系统评估的第一步。
2. 评估标准：基于安全性要求，定义了一些具体的、可衡量的指标，用于评估软件系统的安全性。
3. 评估方法：根据评估标准，采用一些具体的方法，分析软件系统的安全性，发现安全性问题，并提出相应的改进措施。
基于以上三个方面，软件安全性评估模型可以分为多种类型，如下所述。
1. 静态评估模型：主要针对程序的源代码、二进制文件、文档等进行评估。
其优点是能够在软件构建之前对软件安全问题进行分析和发现。
2. 动态评估模型：主要针对软件系统在运行时的行为进行评估。
其优点是可以检测到软件系统实际运行中存在的安全隐患。
3. 混合评估模型：综合了静态评估模型和动态评估模型的优点，并在其基础上进行评估。
二、软件安全性评估工具的设计与实现软件安全性评估工具是基于特定的软件安全性评估模型构建的。
下面将从几个方面探讨软件安全性评估工具设计和实现。
1. 工具构建平台的选择：主流的软件安全性评估工具开发平台有Java、Python、C/C++等，需要结合具体的开发需求和特点进行选择。
2. 开发环境搭建：基于选择的开发平台，需要进行相应的环境搭建。
如在Java平台下，需要安装JDK、Eclipse等开发环境。
3. 工具功能设计：根据安全性评估模型的类型和要求，设计相应的工具功能。
如对于动态评估模型，需要设计相应的测试用例和测试代码。
基于软件代理的应用系统安全性设计与实现
摘 要 文 章 以 国 际 结 算 应 用 信 息 系统 ＩＤ １ 中 的 安 全 系统 为 应 用 背 景 ， 析 了信 息 系统 的 安 全 性 问 题 ， 调 了 Ｓ ＭＳ ｖ ． ０ 分 强
系统 的 网络 安 全 管 理 问 题 ， 计 并 实现 了 一 种 基 于软 件 代 理 和 安 全 套 接 层 协 议 Ｓ Ｌ Ｓ ｃ ｒ ｏ ｋ ｔＬ ｙ ｒ 的 数 据 安 全 传 设 Ｓ （ ｅｕｅ Ｓｃ ｅ ａ ｅ）
ｌ 前 言
在 计 算 机 技 术 和 网络 通 信 技 术 飞 速 发 展 的 今 天 ， 息 系 统 信 日益 庞 大 ， 成 信 息 系 统 的 实 体 数 量 、 体 类 型 、 络 结 构 、 构 实 网 信
息 流 方 式 、 息 处 理 方 式 等 都 发 生 了 非 常 大 的 变 化 ， 息 系 统 信 信 成 为 一 个 庞 大 的 复 杂 系 统 。目前 ， 息 已 作 为 一 种 战 略 资 源 ， 信 从 原 来 的 军 事 、 技 、 化 和 商 业 渗 透 到 社 会 的 各 个 领 域 。 传 播 科 文
ｔ ｃ ｎ ｑ ｅ ｓ ｃ ａ ｔ ｅ ｅ ｏ ｉ ｔ ｎ ｆ ｅ ｒ ｔ ｅ ｓ ｔ ｅ ｒ ｇ ｎ ａ ｉ ｎ ｎ ｐ ｄ ｉ ｇ ｆ ｒ ｃ ｒ ｌｙ ｒ ｅｃ Ｔ ｉ ｅ ｈ ｉ ｕ ｓ ｕ ｈ ｓ ｈ ｎ ｇ ｔ ｉ ｏ ｓ ｃ ｋ ｙ ， ｆａ ｍｅ ｔ ｔ ａ ｄ ａ ｄ ｎ ｏ ｅ ｏ ｄ ａ ｅ ｓ ｔ ． ｈ ｓ ａｏ ｅ ｈ ｏ ｍｅ ｈ ｄ ｓ ｔ ｏ ｉ
输 系统 。对 该 系统 的 两 个 主 要 组 成 部 分 ： 户 方 安 全 代 理 Ｎ — ｇ ｎ 和 服 务 器 端 安 全 网 关 Ｎ — ａｅ ｙ 进 行 了详 细 介 绍 ， 客 Ｓ Ａ ｅｔ ＳＧｔ ｗａ ， 并 分 析 了 实 现 中 的 若 干 关 键 技 术 。 该 方 法 被 证 明较 好 地 解 决 了信 息 系统 网 络 环 境 中 的 安 全 问题 。
交通管理信息系统软件安全设计与应用
6收稿日期：2009-11-17作者介绍：包勇强(1970-)，男，安徽巢湖人，公安部交通管理科学研究所所长助理，副研究员，从事交通管理信息系统建设和应用技术研究；江海龙(1978-)，男，江苏无锡人，公安部交通管理科学研究所助理研究员，从事交通管理信息系统软件设计和开发；邵志骅(1980-)，男，江苏无锡人，公安部交通管理科学研究所研究实习员，从事交通管理信息系统软件开发；是建荣()，男，江苏无锡人，公安部交通管理科学研究所助理研究员，从事交通管理信息系统软件开发。
【摘要】随着公安交通管理信息化建设和应用的深入，信息安全防范面临巨大压力。
本文首先从系统架构设计方面提出了对软件安全管理系统的总体设计思路，然后分别着重从软件发布安全管理和系统运行安全管理两个方面详细阐述了交通管理业务系统软件的安全设计方法，最后从实际应用出发，介绍了软件安全管理系统的建立和实施应用情况，分析了存在的问题，并就下一步完善提出了建议。
【关键词】交通管理；信息系统；软件安全；密钥管理；安全监测【中图分类号】D631.5 【文献标识码】A 【文章编号】16722396[2009]17-0106-05交通管理信息系统软件安全设计与应用包勇强江海龙邵志骅是建荣(公安部交通管理科学研究所，无锡214151)Application and Designing of Software Security inTraf c MIS SystemBAO Yong-qiang JIANG Hai-long SHAO Zhi-hua SHI Jian-rong(Traf c Management Research Institute of Public Security Ministry,Wuxi 214151,China )Abstr act :With the application of traf c MIS system,software security becomes to be an important topic.From system architect ure,the author offers a general concept to software security.In this article,the designing methods of software security are introduced from two points:software publishing and running management.An example of system building and application was also presented.In general,this system can keep traf c MIS system secure,but still has some problems to be solved in the fut ure with suggestions which was proposed at the end of this article.Key words:traf c management;information system;soft ware security;key management;security detection0引言近年来，全国公安机关交通管理部门以“金盾工程”建设为契机，大力加强交通管理信息化建设和应用，取得显著成效。
企业应用软件通用安全规范
企业应用软件通用安全规范Application Software Common Security Requirements of SGCC目录前言 (II)1目的和范围 (1)2规范性引用文件 (1)3术语和定义 (2)4适用对象 (3)5信息系统安全目标 (3)6应用软件通用安全管理要求 (4)7应用软件通用安全技术要求 (5)8 附则 (13)1目的和范围《国家电网公司应用软件通用安全要求》（以下简称《通用安全要求》）作为一个指导框架，列出了国家电网公司系统内应用软件在全生命周期各阶段需要满足的信息安全要求。
通过遵循和使用《通用安全要求》，达到以下目的：1)明确应用软件的安全目标；2)指导应用软件前期设计中的安全考虑；3)指导应用软件开发阶段的安全实现；4)指导应用软件安全性测评的实施和评定；5)指导应用软件安全部署，以及制定运维和废弃阶段的管理要求。
《通用安全要求》应用到具体的应用软件时，应根据其业务使命、运行环境和安全等级等因素进行综合考虑，抽取一个能够保证其安全目标的子集，并予以实现。
抽取安全要求的子集时必须给出充分的依据，没有充分依据证明应用软件不需要或者不涉及某安全要求时，应用软件应该实现该安全要求。
《通用安全要求》适用于国家电网公司范围内信息系统中所有承载业务的应用软件，不包括这些应用软件运行所依赖的网络、主机和操作系统。
《通用安全要求》可作为：1)信息安全风险评估结果符合性的参考；2)软件安全性测评结果符合性的参考；3)应用软件安全设计评价的依据。
《通用安全要求》不包括密码算法固有质量评价准则。
2规范性引用文件下列标准所包含的条文，通过在《通用安全要求》中引用而成为《通用安全要求》的条文。
《通用安全要求》正式实施时，所示版本均为有效。
《GB/T 18336-2001 信息技术安全技术信息技术安全性评估指南》《GB/T 17544-1998 信息技术软件包质量要求和测试》《ISO/IEC 17799:2000 信息安全管理体系》3术语和定义3.1应用软件Application Software本标准中声明的应用软件，专指国家电网公司范围内各单位信息系统中借助网络和计算机系统实现特定业务功能的软件。
系统安全方面的设计
第1章•系统安全设计本章将从系统安全风险分析着手，从物理安全风险，网络安全风险、应用安全风险三个方面进行分析，并同时针对三种风险给出相应的解决方案，最后从系统故障处理和系统安全管理两方面对系统安全管理和运行提供参考意见。
1.1.系统安全风险分析城建档案馆综合业务网络络系统的安全可靠运行是此次设计的重中之重，安全不单是单点的安全，而是整个系统的安全，需要从物理、网络、系统、应用与管理等方面进行详细考虑和分析，设计保障全馆系统安全运行的方案。
下面各节将针对各种综合业务网络络中可能出现的风险进行详细分析，便于针对出现的网络风险进行针对性设计。
1.1.1.物理安全风险物理安全是整个全馆系统安全的前提。
安全以人为本，如果管理不善或一些不可抗力的因数的存在，城建档案馆网络的物理环境可能存在如下的风险：•地震、水灾、火灾等环境事故造成整个系统毁灭；•设备被盗、被毁造成数据丢失或信息泄漏；•电磁辐射可能造成数据信息被窃取或偷阅；1.1.2.网络安全风险在综合业务网络络化系统设计中，信息在局域网和广域网中传输，而在网络中进行传输的数据和信息，都存在被窃听和篡改的危险，这也是在综合业务网络络设计中需要着重考虑的一点。
另外当从一个安全区域（子网）访问另一个安全保护要求不同的区域（子网）时，存在对不应访问的数据、交易与系统服务操作的危险。
所以在综合业务网络络安全设计中，需要考虑对网络入侵行为的探测、报警、取证等机制，尽量减少已知网络安全危险的攻击。
下文将从三个方面对网络安全风险进行详细分析。
1.121.来自与广域网的安全威胁城建档案馆的办公网是与广域网连接的，在本次设计中，办公网与专业网进行了物理隔离，而两个网络间的数据传输，通过收录系统的高安全区进行数据传输，所以对于广域网的威胁近期可能主要考虑高安全区的设置。
但从整体规划来看，办公网由于业务需要，今后可能需要与主干平台的核心交换机进行连接，所以来自广域网的安全如果内部网络系统设计考虑不够全面，防护隔离措施设计不够强壮，就极有可能导致通过主干交换机进入各个业务系统，从而直接危险生产系统和生产管理系统，导致节目的正常制播业务无法开展。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
应用软件系统安全性设计Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】应用软件系统安全性设计(1)2006-12-19 10:13 陈雄华•摘要：应用系统安全是由多个层面组成的，应用程序系统级安全、功能级安全、数据域安全是业务相关的，需要具体问题具体处理。
如何将权限分配给用户，不同的应用系统拥有不同的授权模型，授权模型和组织机构模型有很大的关联性，需要充分考虑应用系统的组织机构特点来决定选择何种授权模型。
•标签：•引言应用程序安全涵盖面很广，它类似于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/”等；而业务接口方法，可以通过方法的完全签名串作为描述串，如，等。
2) 如何对用户进行授权一般不会直接通过分配程序资源的方式进行授权，因为程序资源是面向开发人员的术语；授权由系统管理员操作面向业务层面的东西，因此必须将程序资源封装成面向业务的权限再进行分配。
如将这个程序资源封装成“删除用户”权限，当系统管理员将“删除用户”权限分配给某一用户时，用户即间接拥有了访问该程序资源的权力了。
角色是权限的集合，如建立一个“用户维护”的角色，该角色包含了新增用户、更改用户、查看用户、删除用户等权限。
通过角色进行授权可以免除单独分配权限的繁琐操作。
如果组织机构具有严格的业务分工，用户的权限由职位确定，这时，一般会引入“岗位”的概念，岗位对应一组权限集合，如“派出所所长”这个岗位，对应案件审批，案件查看等权限。
岗位和角色二者并不完全相同，岗位具有确定的行政意义，而“角色”仅是权限的逻辑集合。
角色，岗位是为了避免单独逐个分配权限而提出的概念，而“用户组”则是为了避免重复为拥有相同权限的多个用户分别授权而提出的。
可以直接对用户组进行授权，用户组中的用户直接拥有用户组的权限。
3) 如何在运行期对程序资源的访问进行控制用户登录系统后，其权限加载到Session中，在访问某个程序资源之前，程序判断资源所对应的权限是否在用户的权限列表中。
下面是一个用描述串描述程序资源，在运行期通过反射机制获知程序资源对应的权限，进行访问控制的流程图：图3：通过程序资源描述串进行权限控制4)如何获取用户的菜单和功能按钮很多应用系统在设置用户访问控制权限时，仅将系统所有的菜单列出，通过为用户分配菜单的方式分配权限，如着名的shopex网上商城系统就采用这种方式。
其实这种方式仅仅实现了客户端的访问控制，没有真实实现程序资源的访问控制，应该说是一种初级的，简略的解决方案。
菜单和功能按钮是调用程序资源的界面入口，访问控制最终要保护的是执行业务操作的程序资源，而非界面上的入口。
虽然有些应用系统通过菜单分配权限，在服务端也对程序资源进行控制，但这种权限分配的方式有点本末倒置。
比较好的做法是，在建立程序资源和权限的关联关系的同时建立程序资源和界面功能组件（菜单，功能按钮）的关联关系。
这样，就可以通过用户权限间接获取可操作的界面组件。
下面是这种模型的实现的ER图：图4：客户端服务端程序资源访问控制安全的关联对象ER图从以上分析中，我们可以得到访问模型可能包含的以下一些概念，罗列如下：◆程序资源：受控的程序资源，包括URL或业务接口方法；◆界面功能组件：菜单，按钮等界面操作入口元素；◆权限：程序资源的业务抽象，一个权限可包含多个程序资源；◆角色：权限的集合，一个角色可包含多个权限；◆岗位：一个岗位包含多个权限，可看成是特殊的角色，岗位具有行政的上意义，表示一个职位对应的所有权限。
◆用户：系统的操作者，拥有若干个权限。
◆用户组：用户组是用户的集合，在很多应用系统中，用户组是为完成某项临时性的任务而组建的，有别于行政意义的单位，在另外一些应用系统中，用户组仅是为方便授权管理而建立的逻辑意义上的组织。