Web系统因为是面向Internet/Intranet的，所以其安全性比常规的应用程序系统更难以保证。
在谈到其安全性的时候，很多的都是从“网络安全”的角度去看待问题，殊不知，堡垒
的内部是最最不安全的。对付“黑客攻击”是系统管理员所要面对的问题，而如何更好的
加强堡垒内部自身的安全，是在Web程序的设计中就需要考虑的问题。
系统管理员所要面对的网络攻击、操作系统 安全不是我所考虑的问题，如何加强Web系统
自身的健康是我所最最关心的事情。
从“构造URL”攻击到“注入SQL文”攻击，都是属于过分信任用户输入，而造成的安全问题。
这恰恰应该是由应用程序自身加以重视、解决的问题。
基于角色的安全控制已经逐渐的被大家逐渐的接受，每个用户被分配为不同的角色，不同的角色
具有不同的操作权限。 但是如何划分角色、用户、操作权限，则是需要认真对待的问题。
举例：
一个MIS系统中，员工有查询工资的权限，但是某个员工是否具有查询其他员工的权限呢？
不能深入的追问问题，详细的分辨清楚系统中到底有多少角色、每个用户所在的角色，是不能完成安全控制的。
btw: 以上的问题，大家不妨在自己的类似系统中自己去检查一下，有此问题的占绝大多数吧。
看过此文的，愿意回答“是”“否”的，可以留言， 也当作一个调查吧。
上面的这个例子，就是一个很成熟的办公系统中存在的问题。使用客户端script脚本，控制了用户的界面操作，殊不知maxthon就可以解除这个限制。此系统中，用户的请求都被整理为URL（get方式提交），虽然URL中的键值含义并不是很明显，但是还是可以尝试着去攻击，获取秘密。
认真的核查用户的输入，利用AOP部署，细密的对用户的输入进行核查，是很有必要的事情。
某个人、某个资源、某个操作，这三个要素组织在一起则是：某个人对某个资源进行某项操作
实际情况下，许多人、许多资源、对每个资源冰存在着多个操作。
将人、资源、操作进行划分，可以得到：
具体的某一类人，可以对某些资源，进行某些的操作＝》 这就是具体的某项权限限制。
某一类人，则可以归纳为角色。
对某些资源的某些操作，则可以归纳为工作任务。
也就是说，整个系统是“某个角色去完成某些工作任务，而具体的一个帐户属于某个角色，某项工作则具体的是指对某个资源进行某个操作”。
相对来说，系统中的人员是最容易辨认的，系统中的资源也是可以在系统的功能调查时分清楚的，系统中的操作则是最复杂、最难分清晰，甚至在系统完成时都会变化的。
只有分辨清楚了系统中的人、资源、操作，才能辨别清楚系统中的具体的权限限制。
“基于角色的安全控制”这样的提法，只提及了人，未能强调将资源、操作进行规类，这是很不充分的一种提法。
在Web系统中，系统在设计的过程中，就分清楚资源，分清楚操作，极大缩小每个页面的功能、提高页面功能的原子性，这也是权限控制对系统设计提出的一项要求。
前面提及使用AOP进行权限控制，现在简述一下各部件的功能：
业务模块－－完成具体的对某个资源的操作；
前台页面模块－－ 完成整体页面的整合；
安全控制模块－－实现安全控制功能，完成人员、角色、工作的逻辑判断；
AOP配置整合模块－－粘合安全控制模块和业务模块；
在于如何去解决，而是如何去发现。隐藏起来的问题更是危险。
而如何发现问题，则完全是一个素质、能力的事情，也许这是下一个话题。