架构师不可能做到全知全能，但是仍然担负着成功交付可用的解决方案的任务。满足安全需求常常是其中不可或缺的一环，而且这一点常常没有明确指出。本演讲从整体上讨论架构的安全性，比如如何撰写安全的代码、部署中的安全、架构层的物理隔离、加密、证书的使用等等方面。
 
▲Coding the Architecture创始人Simon Brown
　　以下是精彩演讲：
　　随着互联网安全形势的日益严峻，对于架构师们来讲，为什么需要一个安全的架构以及怎么建设安全架构成为了迫在眉睫的重要任务。为什么来这里讲安全，很多人没听过泽西岛，在英国的南部，是一个离岸的辖区，金融机构在岛上非常盛行，对安全很重要，要安全维护，要有系统享受低税，很多做JAVA的项目，大部分泽西的工作，离岸的银行小公司对安全特别关注的。
　　纠正系统架构的安全认识
　　肯定是重要的。特别泽西岛有自己交易的信息、银行的信息、养老金的信息，所有的资料在泽西岛里面安全保护起来。离开泽西岛也要保障安全，如果不把安全做好，肯定要有糟糕的事情发生。
　　我讲一些近大家都知道的一些安全的漏洞，比如说Linkedln，有一些密码泄露了。也是近轰动的事情。
　　安全适用于方方面面，我们讲软件架构的时候，并不只是看一个地方来求安全，安全应该在整个完整的软件系统当中，都能渗透在安全中，包括所有的级别层所有的元件都需要做到安全。很多人认为安全是人份认证、授权，很多人认为安全是两个问题，但是安全还有其他的问题，比如说防黑客、防攻击、加密等。
　　安全这个问题很难对现有的代码进行安全的加装或改装。如果安全出现问题，要解决安全问题，从架构的基础上来解决的。如果架构的问题一开始没做好，事后补相当困难。跟性能、扩展性都是很重要的，一开始没有照顾好的话，未来提升很难了。
　　安全在整个软件架构的角色当中是怎样的位置
　　我们需要在整个软件开发过程中都要进行考虑的问题。我曾经讲过一个故事，一个面向公众的互联网网站。这个网站是一个针对当地泽西岛的一个听众，泽西岛10万人，是很小的用户群，是一个全新的互联网系统软件服务。这个互联网服务，可以去登陆获得一个用户名，之后获得这些权限。他们请我去看软件系统，我去看软件系统的时候，假装用户去体验一番。
　　我很快发现我可以做跨站的脚本攻击。比如说创造账户，有名字、地址、电邮、电子卡信息。而在地址这一栏，可以写Java脚本，可以注入Java脚本。这个例子是很小的例子，可以对网站做的攻击远远不止这一点，有很多东西可以做。
　　我只用了五分钟、十分钟发现了这些漏洞。当然，这个网站还没有完全上线，只是进行前期的测试，在这个时候发现问题算是万幸。其实在登陆面可以创建自己的密码，很多网站可以是1位到20位需要多少的标点。有些网站需要密码的强度。这个网站也是一样，列出网站应该这样。登陆账户的时候，我说密码太烦了。前台认证并没有很复杂，随便一个词可以接受了，有些比较弱，有攻击密码。
　　我在做银行互联网的时候，有做一个双重认证。在页面看十分钟，HTTP的对话超时了，为什么超时?这是安全的功能。比如说共享一个电脑，在网吧、咖啡店上网的话，有超时的保护。有不同的安全要求。回到我刚才讲的网站，这个网站肯定不是登陆之后一直在线的，对话的时段是非常短的，因为里面有一些非常机密的个人信息。但是，你登陆了网站之后，登陆永远不超时。把游览器关掉再打开，永远不会中断，算点登出，不会登出，管理有问题的。我们要做安全的策略性平台，如果有这么多的漏洞，是非常危险的。
　　这个项目正在进行用户的接受度检测的过程，还没有上线，他们请我去做了检查。经过了各方面的检查，他们说我们只有四个星期上线了，找了很多问题，项目四个月之后才能上线，很多顾客对这个问题根本不敏感。
　　架构师是“T”型人才 是一个建筑师
　　要有知识的深度，同时也有不同方案的广度，我们面临的软件架构师是一个建筑师，这种解决方案必须要知道不同的解决方案不同的软件开发都需要通才的能力。我们从安全的角度来说，软件架构师的工作非常复杂的，特别是windows的环境有很多学习的地方。广度也很重要，有各种各样的安全问题，在整个架构、编码的过程中，不同地方都会出现漏洞。如果没有足够的经验，甚至不知道哪个地方有可能出问题。比如说我们项目的架构师可能是一个通才，有一定的深度，有技术的专长，必须要知道在哪些地方有可能出现问题。
 
　　我们面临的风险是什么呢?
　　攻击、黑客、宕机、拒绝服务、密码泄露、机密信息外泄、安全受损等很多问题都可能来自于安全的问题。这显然是我们从架构角度认真对待不同的风险。这提出一个很有意思的问题，我们是不是可以样样精通呢?我问过“T”型的人才，我们有知识的深度，如果是Java的架构师，必须要真的理解Java，我们要做高性能的系统，这方面的知识，怎么做可扩展性，还有高可靠性。
　　必须要保持这种意识
　　所有不同的领域我们都有一定的宽度和广度，安全是其中一点。我们之前看到编码是整个所有活动当中的中心，是不是所有的知识都可以做编码呢?如果是一个小小的项目可以做自己的编码，同时也应该知道可用性、安全性以及扩展性的种种知识。这是不是意味着样样都精通呢?我给大家讲安全课，但是我不是安全专家。但是安全是我们作为架构师必须有意识、必须有概念，而且要知道安全环境不断的改变，有新的不同攻击、不同黑客，必须要保持这种意识。所以我们必须有安全的意识，而意识是一个关键词。
　　刚才讲了“T”型人才，是一个通才型的专才。做软件团队的时候，可能有一个人来做这个工作，可能有一个专门软件架构师来做技术主管的角色。这个人是我们的通才化的全才。但是你能找到这样一个人吗?我们可能要面试很多人、招聘很多人，是不是能找到通才化的人才呢?不一定的。近我建立一个系统，是一个混合项目，我们可以有多个人进行架构的支撑，共同协同工作，联合起来形成了足够宽度和深度，一方面有通才型的专才，另一方面专家提供深度的支持。
　　一般我做的项目里面可能会请一个专家，专家有相关的经验，有些是没有的。给大家看一个很有意思的博客，在英国看到的。如果系统里面有SQL的出入，有流程或者基础设施的问题。如果你的问题有安全隐患的话，系统安全隐患，是说明现在做错了，要看哪些地方做错了，如果没有这方面的专家怎么办?或者根本没有意识到潜在的安全问题或者已有的安全问题。
　　安全怎么融入到系统当中
　　从根本的角度来看安全有什么要求。像十年之前搞架构的时候，有哪些具体要求，哪些东西要做哪些不要做的。必须要清楚地知道，在建造架构的时候哪些东西需要做，怎么才能高效。我觉得安全也是一样，很多人都是从用户的角度来获取用户的需求。用户的角度确实不错，希望能够找一些好的、简单适用的。他们不是技术性的人才，视角不是特别独特。在编写用户表述的要求时，有不同的模板。所做的一切要清楚在你的系统里面，用系统的人分成哪些类的。
　　去年我做了一个项目的架构分析，大概里面有两到三百个使用者所提供的一些要求，用户扮演着不同的角色。到底这些用户分成哪些?比如说超级用户还是管理员，还是一般性的用户。但是分不出来类。我觉得挺有意思的。
　　如果我设计软件的话，必须要知道软件针对的受众是谁，谁会用。早上给大家看图，第一个是上下文背景，中间是系统，下面还有与之沟通的系统，上面是我们讲的用户。我们知道到底哪些类型的用户在使用我们的系统。为什么这点很重要?从安全角度讲很重要。问这个团队到底懂不懂安全，谁在用我们的系统?这些人用我们的系统，有什么样的功能?我们这些使用者所提供的一些，也从相关来讲比较高端的视角来分析一下类别。
　　对于这方面的信息不是已经过时了，非常适用的。在英国一些咨询管理公司，要求做成文件发给我们，尤其是技术方面的要求。技术要求包括扩展性、安全、性能等。这些从特点来讲比较技术性的，而且非常详实。写这些要求的人，不是技术出身的，是商界出身的，他也不清楚产品规格里面细节多细合适，所以来一句系统是非常安全，对于系统的安全来一句够了。作为架构师这句话牛头不对马嘴，确实要做到安全。
　　用户或者SQL的攻击注入时，怎么样做到安全?
　　很多英国的公司从安全的角度讲，做得很烂，因为团队不知道安全到底意味着什么。可能在网上随便问一些人到底该怎样做。
　　作为架构师要分析需求的话，并不是说做大型的前端设计，而是做一些简单的，获取、捕获使用者的要求，做高级的架构设计，比较要考虑到扩展性、安全，如果没有考虑到这些，在打造架构的时候，可能会丢失非常宝贵的元素。可以开一些研讨会、交换文件，这种工作坊和小型研讨会的形式非常好，知道使用系统的是这部分用户。
　　客户给的要求是系统非常安全，要问他非常安全是有多安全，工作坊可以面对面的交流，谁在用我们系统，哪些方面的内容影响了他们对系统的使用，为什么会这样?这样会有非常具体的用户对系统的要求。除了捕获信息之外，还要置疑他们。我们团队必须要不断的置疑挑战我们一开始所制定出来的具体要求。到底我们开发的时候优先级别会怎样。觉得要求根本没必要，换一种方式行不行，我觉得已经够了，要挑战不同的要求，不仅是功能性的，还有非功能性的，比如说安全，也要跟客户谈一谈。每次在系统里面引入安全的时候，要做一些权衡、妥协、让步。
　　一般来讲，典型的让步、取舍是可用性、易用性和复杂性。也是说，安全的话更复杂了。比如说我去银行要做，ID非常长，记不下来，输入密码登陆，到了第二页，要输入安全代码，有一个小键盘，类似于口令牌，随即生成输入进去。等我通过这么多安全检查进这个网站的时候，对话已经超时了，我输入这么多的密码，已经查不到我账户信息了，这是非常长、非常复杂的过程，用电子安全指令等。确实很安全，但是影响了便捷程度。这时要做取舍，是易用还是复杂安全性。
 
　　如果要胜任软件架构师的角色，需要多种能力
　　理解要求非常重要，作为架构师必须理解要求是什么，比如说不能只做前期的设计，交给后期去实施，这不是我们做的，但我们必须要知道安全的要求，安全的要求必须要吃透。安全是一个非常关键，从架构师的角度来说，认真对待安全的要求。特别是项目的技术主管，要教练和指导你的员工，作为技术主管来说，必须有这个能力。而且安全搞不好是一个大风险。
　　安全问题怎么样能够在架构里面得到诠释
　　安全可以融入到所有领域的，现在看到的有三级显示，Web服务器、应用服务器、数据库。在Web服务器上避免攻击，应用服务器获得授权的人才能进入，数据库是确保数据安全保存在这里。中间部分是保障基础设施的安全，包括防火墙等。稍候会讲怎么有效获得授权。
　　这是一种非常常见也是非常传统打造安全的方式。可能在服务器上放很小的代码，数据库里面放很多数据，中间应用服务器获取这些相关信息。因为肯定关注安全，信息存储是否安全。
　　稍候看一看这些架构，看到Web服务器使用了相关安全服务，这是很常见的，但是这些所谓的Web服务非常不安全，比如输入ID开发工具，你的Web服务创建了一些本地的组建，你发现这里不需要授权，随便什么人都可以进来，因此在这个领域我觉得安全是可以发挥重要的作用的。
　　我们在做架构的时候，如果把服务器从物理上分得开，不一定真正安全了。物理分开的话，中间信息传输出现影响。每个层级有安全，不同的层级间的安全很重要的。如果从物理上分割开来，中间的联系也会成为攻击的对象。
　　千万不要把编码放的到处都是，放在核心中央层
　　这样的话攻击你只可能攻击你表面，核心保护很好。这里有非常有意思的问题，为什么用物理上分开来的应用服务器，人们觉得集成实时的，总是搞架构把应用服务器分开来，但是我们也可以找一些其他的方法，现在有很多互联网的创业公司是这么做的。我想希望大家好好想想你干吗这么做，做一件事情必须事出有因才行。这实际上是我们讲得做出取舍。安全得到保障，复杂性获得一些影响。在我们的安全因素的话，讲到小的特权原则。只有必须要发生的事情才能发生，不能把所有的东西全部部署到服务器上从来都不用。