《设计模式--基于C#的工程化实现及扩展》 Security Design Pattern 系列 3 检查点模式(Check Point)

信息安全设计模式系列 3 (转载请注明出处)

 

Check Point

检查点模式

王翔 (Vision Wang)

2009-02-13

 

分类

       信息安全行为型模式

动机、问题、影响因素

       不知道您是否和我一样,每天上班要打卡。

因为对人员进出管的比较严,如果不出示工作证并打卡,我进入不了办公区,更出不来。以进门为例,过程如下:


03-01:进门的流程

      

       从上面的过程看,上述“门卫”、“门禁 系统”的目标都是防止非法用户进入敏感区域,有效保护其中的敏感信息系统和数据。上章我们介绍了单一访问点模式(Single Access Point Pattern),它的主要任务是尽量缩小访问接触面,但并不能对用户“尝试进入”的行为进行控制。

       例如:上面的示例,门卫总会下班、换 岗,门禁系统也会因为一些原因被暂时关闭,相信您看过很多大片也知道,如果火警报警器被击碎会出现什么情况,因此即便如上面“层层设防”,但如果不能尽早 “切断”这些“尝试进入”进行清理,非法用户或程序只要有“恒心”突破只是早晚的事情。

一个更直观的例子就是我们的windows登录密码,“1qaz2wsx?——不对,“123456”——还不对?不过没关系,我遍历就结了,磨杵成针么。

 

总结一下,我们的目标是阻断重复出现的Break in 行为,并采取适当的行为“惩罚”发起Break in行为的主体。这些内容对于大部分企业而言,本身就属于各种安全策略、安全使用规范要求内的。从设计上本着“组合优于继承”的原则,我们沿用《设计模式——基于C#的工程化实现及扩展》的方法,把它设计为一个独立的机制。

 

现实中,实施这种控制有一些限制:

l         这个控制要求最常见的集中在认证、授权,如果“惩罚”措施不当,会招致用户反感;

l         这些行为都是非法的么?想想您是否记得自己父母的生日,尽管只是两个Date数据。同样,我们的很多用户记忆这么多密码确实也不容易,如何认定是Break in还是无意的对于复杂的系统而言也是必要的;

l         不同的“尝试”行为可能要进行不同的反馈,比如:上班的那个例子,用斧子砍门和一遍遍刷卡可能就要用不同的手段处置;

解决方案

       综上分析,我们对于这些行为可能有很多要求,但抽象而言,表示为:

“用一个对象/子系统封装对于上述‘尝试’的安全策略”。

 

       回想现实中的项目如何做的呢?以认证为例,我们经常看到一个登录界面,让用户输入UserNamePassword,如果错误超过35次就要暂时请您歇会;而授权也是,如果您总是在浏览器输入本不该执行功能的地址,可能就看到一个很不友好的界面,告诉您“您的IP/账号已经被锁定,请联系管理员为您解锁”。

       现实中项目对于“尝试”的定义不同,而且如何定义“尝试”失败也不同,例如:

l         用户名/口令不匹配

l         认证过程超时

l         同一账号已经在其他地方登录,而且并没有退出

l         越权访问

l         在不恰当的时间登录企业的信息系统

l         … …

 

考虑到这部分变化很大,所以因此按照GOF23部分的处理方式,我们把它“切开”,专门为管理“尝试”的对象/子系统提供判断算法,也就是说用策略模式把判断“尝试”是否成功以及多少次“尝试”失败就采取行动统一抽象为一个个独立的策略,允许以插件方式动态配置。

这样,我们抽象出检查点模式的静态结构:


03-02:检查点模式的静态结构

 

       说明:

l         IHandler:借鉴命令模式的方式,定义多次“非法尝试”后应该执行的惩罚性措施;

l         IStrategy:借鉴策略模式,定义判断尝试后的执行是否成功的判断算法;

l         IDirectorStrategy:是企业安全策略的主要体现,他表示最终实施惩罚性措施的算法;

l         Context:用于表示判断算法所以来的全部环境及用户参数;

l         CheckPoint:用来管理众多“尝试“控制的调度、响应机制的入口;

 

上面的Director Strategy虽然大部分情况下是唯一的,但对于大型企业而言,信息安全策略往往来自于不同部门,针对该情况参考我们在《设计模式——基于C#的工程化实现及扩展》GOF23部分的介绍,您可以借助组合模式组织相关的策略为一个统一的Director Strategy

 

       检查点模式的执行时序如下:


03-03:检查点模式的执行时序

 

       其中,决定性作用的是CheckPointIDirectorStrategy,至于IHandler执行的措施是需要反馈回界面告知用户,还是直接在后台拿个小账本记小账,或者是拉响警报之类的,这就已经与CheckPoint系统无关了,因为检查点的关键目标是这个前期的决策过程,至于后续的措施则完全依赖抽象的IHandler定义完成。

示例

       下面我们举一个最常见的例子,就是做网站登录次数的检查。假设企业安全策略非常宽松:

l         密码错误5次,则暂时挂起登录请求20s

l         同一账号严禁同时在线;

分析

这里,我们先将各项职责进行分解:

l         Director Strategy增加记录活动会话中每个账号登录的计数器;

l         增加一个挂起请求20s的管控机制;

设计

       根据细化后的分工,结合前面检查点模式的静态结构,我们设计了一个TimesDirectorStrategy


03-04:示例要求的Director Strategy结构

 

       具体执行时序与一般的处理类似,只不过需要TimesDirectorStrategy根据调用请求的来源,确定其“尝试”次数。

相关模式

       从设计看,由于不同企业对于“非法尝试”的认定策略不同,因此策略模式成为封装相关算法的首选。

       为了建立一个面向企业的全面系统,我们需要把相关“尝试”错误的检查工作交给一个认证逻辑之外的第三方机制完成。因此有必要采用观察者模式,借助不同开发平台的特征从旁边“瞅着”不同的“尝试”行为。

行业案例

大家最熟悉的Windows XPVista之类都又类似的检查点措施,每当我们连续数次输入错误的口令后,就会暂时挂起登陆界面。

众多网站的的“忘记密码”也是在对多次失败后,响应的自然提示。

其他

       如上示例,对于检查点模式的典型应用——授权和认证而言,如何抽象请求主体(对于很多情况,还需要区分同一主体的不同行为,甚至于同一行为的行为特征模式),这些内容并非检查点模式的操作内容,相关讨论需要在认证器模式(Authenticator Pattern,也称作“认证子”等名称)和授权器模式(Authorizator Pattern 也称作“授权子”等名称)部分介绍。
posted @ 2009-02-15 18:50  蜡笔小王  阅读(1955)  评论(0编辑  收藏  举报