架构师如何才能够设计一个安全的架构(3)

　　如果要胜任软件架构师的角色，需要多种能力

　　理解要求非常重要，作为架构师必须理解要求是什么，比如说不能只做前期的设计，交给后期去实施，这不是我们做的，但我们必须要知道安全的要求，安全的要求必须要吃透。安全是一个非常关键，从架构师的角度来说，认真对待安全的要求。特别是项目的技术主管，要教练和指导你的员工，作为技术主管来说，必须有这个能力。而且安全搞不好是一个大风险。

　　安全问题怎么样能够在架构里面得到诠释

　　安全可以融入到所有领域的，现在看到的有三级显示，Web服务器、应用服务器、数据库。在Web服务器上避免攻击，应用服务器获得授权的人才能进入，数据库是确保数据安全保存在这里。中间部分是保障基础设施的安全，包括防火墙等。稍候会讲怎么有效获得授权。

　　这是一种非常常见也是非常传统打造安全的方式。可能在服务器上放很小的代码，数据库里面放很多数据，中间应用服务器获取这些相关信息。因为肯定关注安全，信息存储是否安全。

　　稍候看一看这些架构，看到Web服务器使用了相关安全服务，这是很常见的，但是这些所谓的Web服务非常不安全，比如输入ID开发工具，你的Web服务创建了一些本地的组建，你发现这里不需要授权，随便什么人都可以进来，因此在这个领域我觉得安全是可以发挥重要的作用的。

　　我们在做架构的时候，如果把服务器从物理上分得开，不一定真正安全了。物理分开的话，中间信息传输出现影响。每个层级有安全，不同的层级间的安全很重要的。如果从物理上分割开来，中间的联系也会成为攻击的对象。

　　千万不要把编码放的到处都是，放在核心中央层

　　这样的话攻击你就只可能攻击你表面，核心保护很好。这里有非常有意思的问题，为什么用物理上分开来的应用服务器，人们觉得集成实时的，总是搞架构把应用服务器分开来，但是我们也可以找一些其他的方法，现在有很多互联网的创业公司就是这么做的。我想希望大家好好想想你干吗这么做，做一件事情必须事出有因才行。这实际上就是我们讲得做出取舍。安全得到保障，复杂性获得一些影响。在我们的安全因素的话，讲到最小的特权原则。只有必须要发生的事情才能发生，不能把所有的东西全部部署到服务器上从来都不用。

　　许可一个进程操作的话，要确保进程必须要操作的，其他不需要操作不要放在这里。这点是所有软件架构师在系统里面必须要牢记的。

　　怎么通过不同的方式来把安全引入到系统里面

　　现在讲验证、授权、审核是三个比较常见的方法。首先，验证。我是用户，是谁呢?权力是什么?用什么东西?这很重要，可以帮助你了解到用户的需求以及不同类型的用户在系统里面扮演不同的角色该怎样具体做呢?有这样的系统怎样能够做好本地的验证和授权。其实很多方法都可以。

　　先来看看一个简单的两级的方式，Web服务器和数据库直接进行对换。讲到安全、认证、授权最简单的方法，系统认出你的用户，在系统里面有一个用户的名单，有他们使用的权力，通过映射的方式，客户来了映射能做什么，是不是最高效能，不一定。

　　早上说过我们有不同的选择，要解决这样的问题，选择很多的，还有另外一个方法，比如说设计自己的架构，不把你的数据放在数据库里，大的企业会有一种主动的目录和一些算法，是包含了用户和他的一些资格说明，这样的话就可以加以利用了。你不会把用户放在你的数据库里，可以把用户放在别的地方，这样的话管理的负担也小了。有新的用户在中间的注册器里面注册新用户就可以了。

　　但也许它的角色放在数据库，因为不同角色有不同的授权。所以用户和他的资历放在外面，但是角色放在数据库里，这也是很好分解的办法。或者甚至把授权也放在主动的目录当中，形成不同的群组，这是可以选择的方法。但是会不会比之前的方法更好呢?同样，这并不是我能回答的问题。有些企业、有些组织很愿意做这种，觉得这个够了，可以对于用户的目录专门存放用户的信息。但是其他的一些企业、一些组织并不喜欢把你自己的群组放在自己的服务器上。有些时候可以，有些时候不愿意使用。

　　还有其他的方法，可以用安全令牌的服务，有人做身份基金会的工作，实际上就是把安全进行集中化，不管是身份验证还是授权都能够集中起来，我两年前做的一个项目，有一个单独的令牌的系统，这里面给我们带来的复杂性是不可想象的，本来只有一个人做这个项目，压力非常大，非常复杂。这也是一种选择。对某一种企业来说，也许是最好的选择。

　　哪一个方案是最“好”的?其实没有所谓的最好的方案，永远只能对你来说最好，对这个环境来说最好，所以哪个是最好呢?还是回到今天早上讲过的，从高层的角度上了解我们的需求，了解我们环境的约束性、局限性。如果在大企业工作的话，可能会有一个主动的目录服务器了。可以去找这个有关的部门，可以找你服务器来做验证。可不可以把决策和授权放在目录当中，可以选择最好的解决方案。

　　有一个大的英国超市，用明文来记密码，密码以明文的形式寄到邮箱，回归到之前的架构，如果数据库是够安全的话，明文也没问题的。对于这篇文章之后，有一个很好的明文建议，如果用明文密码会加密，而且是散列的处理。我不是一个安全专家，但是我知道至少有不同的方法来把密码进行分类散列，比如说用一些随机的数字进行加密和散列，这都是很好的进行密码散列的方法。当然我们也选择一个最适合我们的方法。

　　审查、审计也是一方面，我们要有一个审计的线索。比如说我们在泽西岛是离岸的环境，做很多交易，必须知道哪些用户做了什么?为什么要这么做?因为有人对这个网站提出一些索赔，丢失了信息我们要追诉回去，看一下他的信息怎么丢的，有没有修改。

（编辑：ASP站长网）