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

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之类都又类似的检查点措施，每当我们连续数次输入错误的口令后，就会暂时挂起登陆界面。

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

其他

如上示例，对于检查点模式的典型应用——授权和认证而言，如何抽象请求主体（对于很多情况，还需要区分同一主体的不同行为，甚至于同一行为的行为特征模式），这些内容并非检查点模式的操作内容，相关讨论需要在认证器模式（Authenticator Pattern，也称作“认证子”等名称）和授权器模式(Authorizator Pattern，也称作“授权子”等名称)部分介绍。

更多关注：