《设计模式--基于C#的工程化实现及扩展》 Security Design Pattern 系列 1 公钥体系与分布式环境要求

本文是《设计模式--基于C#的工程化实现及扩展》的Security Design Pattern系列第一篇,探讨了公钥体系在分布式环境中的应用,强调了信息安全设计模式中的信任、控制隔离和价值因素。作者指出,信息安全模式需要解决信任问题,并介绍了控制隔离的概念,以应对分布式系统中的安全挑战。文章还讨论了信息安全模式的价值因素,如认证、授权、审计和日志系统等,并阐述了AOP(面向方面编程)在信息安全模式中的重要性。
摘要由CSDN通过智能技术生成

版权申明
本博客注明为原创的文章均出自王翔本人,如需转载、引用其中的部分文字,请在转载(引用)的内容开始添加王翔署名,并提供本博客中相应文章的链接。如你的作品为非电子读物或纯文本,请给出链接的url。转载请勿用于商业用途,谢谢。


《设计模式--基于C#的工程化实现及扩展》 Security Design Pattern 系列 1 公钥体系与分布式环境要求

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

 

 

 

公钥体系与分布式环境要求

 

王翔 (Vision Wang)

 2009-02-11


 

概要

       作为《设计模式--基于C#的工程化实现及扩展》第一版的延续,计划陆续推出信息安全设计模式(Security Design Patterns)系列,集成模式(Integration Pattern)、数据模式(Data Pattern)、数据访问模式(Data Access Pattern)、XML应用模式(XML Pattern)以及随着Web 2.0出现的用户体验模式(UX Pattern User Experience Pattern)由于国内社区已经有不少现成的资料,因此暂时延后推出。

 

       作信息安全的同行往往强调“三分技术、七分管理”,管理非常重要,尤其是对人员的管理、培训、教育更加如此,不过本系列着重在那“三分”,而且仅仅是“三分”中涉及到应用开发、设计的部分。

 

       正如我们在《设计模式--基于C#的工程化实现及扩展》GOF23经典部分介绍的那样,GOF23中绝大部分模式给开发人员的感觉往往集中在解决类型关系上,大量的实例也主要针对一个“系统”/“子系统”内部的变化关系上,但随着内容的展开,我们发现很多模式也被广泛应用于分布式系统中,成为架构模式的关键部分,例如:代理模式(Proxy Pattern)、观察者模式(Observer Pattern)、外观模式(Façade Pattern),同样在完成常见信息安全开发方面我们也有很多类似的变化要处理,由于专门针对该领域的开发人员数量相对较小,即便在项目组内部往往也是“少数派”,因此信息安全设计模式并不像设计模式GOF23及其它分支发展脉络那么清晰,但经过软件行业几十年积累也有些“套路”可循,尤其针对开发中常见的认证、授权、访问控制已经有一些模式方法,本系列主要针对这些内容结合自身项目经验介绍。

信息安全模式自身面临的主要问题

       信息安全系统/子系统首先是个信息系统/子系统,因此它与GOF23设计模式中描述的内容有共通处,其思想一样可以用于解决信息安全系统/子系统相应的变化问题。区别于设计模式的其他分支关于变化的控制需求,信息安全模式首先要解决一个问题——信任

 

       也就是说无论我们提供何种信息安全功能/服务,总要基于一个相对可信的环境,比如:我们验证用户密码,但用户凭证信息保存的这个库往往首先由认证程序假定是可信的,否则其他都免谈了。项目中,随着参与方的不断增多(用户、软件、系统、服务、信息源),我们必须提供一套大家都认为可信赖的环境,那么这种分布是公共信任环境与我们经常“手口相传”的信任体系有什么区别呢?

 

       前者,我们经常用对称密钥,而后者往往还需要借助证书为凭证的非对称密钥体系,然后借助一些公共信任的机制/服务,形成一套以公钥为基础的环境。

 

(对于“对称密钥”、“ 非对称密钥”的概念,请参考密码学教材,一般都有较为详细的说明)

 

       另一个关键因素就是“控制隔离”,参考其他设计原则的描述方法,我们不妨暂称之为——Control Isolation,也就是说当你想控制某个对象/服务访问另一个对象/服务的时候,为了体现控制往往要借助一个第三方对象/服务把两者隔开。

01-01:通过控制隔离关系实现信息安全控制

 

       这其中我们不难发现,GOF23部分的结构型模式中的代理模式、外观模式以及构造型模式中的工厂方法(/抽象工厂方法)单独个体都难于满足这里的需要。因此从某种程度看,由于信息安全开发中对象角色的复杂性,实际项目中安全模式往往需要组合多种手段才可以较有效的隔离变化。

信息安全模式中的价值因素

       区别于GOF23中大部分变化要求,信息安全模式还有一个明显的特征就是他的价值因素,以桥模式(Bridge Pattern)为例,我们在《设计模式--基于C#的工程化实现及扩展》的章节中提到,之所以称之为“桥”,是因为它把客户程序可能导致变化的对多个因素变成依赖一个抽象的“桥板”,而每个变化对象的实现类型则被作为桥墩。

01-02:桥模式解决多因素变化的思路

 

       通过这个过程,如果出现更多维度变化的情况,我们可以统一用一套模式思路解决相关问题。

 

而在信息安全开发的一个典型操作——“授权”中我们却不能简单的提供一个解决方案,其中一个关键考虑就是不同对象实体的价值因素,例如,典型的授权方式如下:

l         Role Based Security:适合我们常规的业务性系统;

l         Identity Based Security:适合高安全等级,需要精细颗粒度控制用户访问的系统,例如:审计系统;

l         Claims Based Security:适合对于不确定的环境部署的应用,安全性依据客户端提交访问时声明的内容进行检查;

l

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值