《设计模式--基于C#的工程化实现及扩展》 Security Design Pattern 系列 3 检查点模式（Check Point)
版权申明
本博客注明为原创的文章均出自王翔本人，如需转载、引用其中的部分文字，请在转载（引用）的内容开始添加王翔署名，并提供本博客中相应文章的链接。如你的作品为非电子读物或纯文本，请给出链接的url。转载请勿用于商业用途，谢谢。
《设计模式--基于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 不同的“尝试”行为可能要进行不同的反馈，比如：上班的那个例子，用斧子砍门和一遍遍刷卡可能就要用不同的手段处置；
解决方案
综上分析，我们对于这些行为可能有很多要求，但抽象而言，表示为：
“用一个对象/子系统封装对于上述‘尝试’的安全策略”。
回想现实中的项目如何做的呢？以认证为例，我们经常看到一个登录界面，让用户输入UserName和Password，如果错误超过3、5次就要暂时请您歇会；而授权也是，如果您总是在浏览器输入本不该执行功能的地址，可能就看到一个很不友好的界面，告诉您“您的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：检查点模式的执行时序
其中，决定性作用的是CheckPoint与IDirectorStrategy，至于IHandler执行的措施是需要反馈回界面告知用户，还是直接在后台拿个小账本记小账，或者是拉响警报之类的，这就已经与CheckPoint系统无关了，因为检查点的关键目标是这个前期的决策过程，至于后续的措施则完全依赖抽象的IHandler定义完成。
示例
下面我们举一个最常见的例子，就是做网站登录次数的检查。假设企业安全策略非常宽松：
l 密码错误5次，则暂时挂起登录请求20s；
l 同一账号严禁同时在线；
分析
这里，我们先将各项职责进行分解：
l 为Director Strategy增加记录活动会话中每个账号登录的计数器；
l 增加一个挂起请求20s的管控机制；
设计
根据细化后的分工，结合前面检查点模式的静态结构，我们设计了一个TimesDirectorStrategy：
图 03-04：示例要求的Director Strategy结构
具体执行时序与一般的处理类似，只不过需要TimesDirectorStrategy根据调用请求的来源，确定其“尝试”次数。
相关模式
从设计看，由于不同企业对于“非法尝试”的认定策略不同，因此策略模式成为封装相关算法的首选。
为了建立一个面向企业的全面系统，我们需要把相关“尝试”错误的检查工作交给一个认证逻辑之外的第三方机制完成。因此有必要采用观察者模式，借助不同开发平台的特征从旁边“瞅着”不同的“尝试”行为。
行业案例
大家最熟悉的Windows XP、Vista之类都又类似的检查点措施，每当我们连续数次输入错误的口令后，就会暂时挂起登陆界面。
众多网站的的“忘记密码”也是在对多次失败后，响应的自然提示。