架构师如何才能够设计一个安全的架构
架构师不可能做到全知全能，但是仍然担负着成功交付可用的解决方案的任务。满足安全需求常常是其中不可或缺的一环，而且这一点常常没有明确指出。下面我们从整体上讨论架构的安全性，比如如何撰写安全的代码、部署中的安全、架构层的物理隔离、加密、证书的使用等等方面。
用户或者SQL的攻击注入时，怎么样做到安全?
很多英国的公司从安全的角度讲，做得很烂，因为团队不知道安全到底意味着什么。可能在网上随便问一些人到底该怎样做。
作为架构师要分析需求的话，并不是说做大型的前端设计，而是做一些简单的，获取、捕获使用者的要求，做高级的架构设计，比较要考虑到扩展性、安全，如果没有考虑到这些，在打造架构的时候，可能会丢失非常宝贵的元素。可以开一些研讨会、交换文件，这种工作坊和小型研讨会的形式非常好，知道使用系统的是这部分用户。
客户给的要求是系统非常安全，就要问他非常安全是有多安全，工作坊可以面对面的交流，谁在用我们系统，哪些方面的内容影响了他们对系统的使用，为什么会这样?这样会有非常具体的用户对系统的要求。除了捕获信息之外，还要置疑他们。我们团队必须要不断的置疑挑战我们一开始所制定出来的具体要求。到底我们开发的时候优先级别会怎样。觉得要求根本没必要，换一种方式行不行，我觉得就已经够了，要挑战不同的要求，不仅是功能性的，还有非功能性的，比如说安全，也要跟客户谈一谈。每次在系统里面引入安全的时候，要做一些权衡、妥协、让步。
一般来讲，典型的让步、取舍是可用性、易用性和复杂性。也就是说，安全的话更复杂了。比如说我去银行要做，ID非常长，记不下来，输入密码登陆，到了第二页，要输入安全代码，有一个小键盘，类似于口令牌，随即生成输入进去。等我通过这么多安全检查进这个网站的时候，对话已经超时了，我输入这么多的密码，已经查不到我账户信息了，这是非常长、非常复杂的过程，用电子安全指令等。确实很安全，但是影响了便捷程度。这时要做取舍，是易用还是复杂安全性。
安全问题怎么样能够在架构里面得到诠释
安全可以融入到所有领域的，现在看到的有三级显示，Web服务器、应用服务器、数据库。在Web服务器上避免攻击，应用服务器获得授权的人才能进入，数据库是确保数据安全保存在这里。中间部分是保障基础设施的安全，包括防火墙等。稍候会讲怎么有效获得授权。
这是一种非常常见也是非常传统打造安全的方式。可能在服务器上放很小的代码，数据库里面放很多数据，中间应用服务器获取这些相关信息。因为肯定关注安全，信息存储是否安全。
稍候看一看这些架构，看到Web服务器使用了相关安全服务，这是很常见的，但是这些所谓的Web服务非常不安全，比如输入ID开发工具，你的Web服务创建了一些本地的组建，你发现这里不需要授权，随便什么人都可以进来，因此在这个领域我觉得安全是可以发挥重要的作用的。
我们在做架构的时候，如果把服务器从物理上分得开，不一定真正安全了。物理分开的话，中间信息传输出现影响。每个层级有安全，不同的层级间的安全很重要的。如果从物理上分割开来，中间的联系也会成为攻击的对象。
千万不要把编码放的到处都是，放在核心中央层
这样的话攻击你就只可能攻击你表面，核心保护很好。这里有非常有意思的问题，为什么用物理上分开来的应用服务器，人们觉得集成实时的，总是搞架构把应用服务器分开来，但是我们也可以找一些其他的方法，现在有很多互联网的创业公司就是这么做的。我想希望大家好好想想你干吗这么做，做一件事情必须事出有因才行。这实际上就是我们讲得做出取舍。安全得到保障，复杂性获得一些影响。在我们的安全因素的话，讲到最小的特权原则。只有必须要发生的事情才能发生，不能把所有的东西全部部署到服务器上从来都不用。
许可一个进程操作的话，要确保进程必须要操作的，其他不需要操作不要放在这里。这点是所有软件架构师在系统里面必须要牢记的。
怎么通过不同的方式来把安全引入到系统里面
现在讲验证、授权、审核是三个比较常见的方法。首先，验证。我是用户，是谁呢?权力是什么?用什么东西?这很重要，可以帮助你了解到用户的需求以及不同类型的用户在系统里面扮演不同的角色该怎样具体做呢?有这样的系统怎样能够做好本地的验证和授权。其实很多方法都可以。
先来看看一个简单的两级的方式，Web服务器和数据库直接进行对换。讲到安全、认证、授权最简单的方法，系统认出你的用户，在系统里面有一个用户的名单，有他们使用的权力，通过映射的方式，客户来了映射能做什么，是不是最高效能，不一定。
早上说过我们有不同的选择，要解决这样的问题，选择很多的，还有另外一个方法，比如说设计自己的架构，不把你的数据放在数据库里，大的企业会有一种主动的目录和一些算法，是包含了用户和他的一些资格说明，这样的话就可以加以利用了。你不会把用户放在你的数据库里，可以把用户放在别的地方，这样的话管理的负担也小了。有新的用户在中间的注册器里面注册新用户就可以了。
但也许它的角色放在数据库，因为不同角色有不同的授权。所以用户和他的资历放在外面，但是角色放在数据库里，这也是很好分解的办法。或者甚至把授权也放在主动的目录当中，形成不同的群组，这是可以选择的方法。但是会不会比之前的方法更好呢?同样，这并不是我能回答的问题。有些企业、有些组织很愿意做这种，觉得这个够了，可以对于用户的目录专门存放用户的信息。但是其他的一些企业、一些组织并不喜欢把你自己的群组放在自己的服务器上。有些时候可以，有些时候不愿意使用。
还有其他的方法，可以用安全令牌的服务，有人做身份基金会的工作，实际上就是把安全进行集中化，不管是身份验证还是授权都能够集中起来，我两年前做的一个项目，有一个单独的令牌的系统，这里面给我们带来的复杂性是不可想象的，本来只有一个人做这个项目，压力非常大，非常复杂。这也是一种选择。对某一种企业来说，也许是最好的选择。
哪一个方案是最“好”的?其实没有所谓的最好的方案，永远只能对你来说最好，对这个环境来说最好，所以哪个是最好呢?还是回到今天早上讲过的，从高层的角度上了解我们的需求，了解我们环境的约束性、局限性。如果在大企业工作的话，可能会有一个主动的目录服务器了。可以去找这个有关的部门，可以找你服务器来做验证。可不可以把决策和授权放在目录当中，可以选择最好的解决方案。
有一个大的英国超市，用明文来记密码，密码以明文的形式寄到邮箱，回归到之前的架构，如果数据库是够安全的话，明文也没问题的。对于这篇文章之后，有一个很好的明文建议，如果用明文密码会加密，而且是散列的处理。我不是一个安全专家，但是我知道至少有不同的方法来把密码进行分类散列，比如说用一些随机的数字进行加密和散列，这都是很好的进行密码散列的方法。当然我们也选择一个最适合我们的方法。
审查、审计也是一方面，我们要有一个审计的线索。比如说我们在泽西岛是离岸的环境，做很多交易，必须知道哪些用户做了什么?为什么要这么做?因为有人对这个网站提出一些索赔，丢失了信息我们要追诉回去，看一下他的信息怎么丢的，有没有修改。
怎么能写出安全的代码?
网上有很多信息，主要有两个主流：第一，要避免数字被修改。第二，限制接入。
当然免疫性很好的，如果免疫的话就不能修改。这是一个很好的属性。如果这个数据有一定的对象，而这个对象数据是不能修改的，免疫了就不能修改了，所以从根本上来说是安全的。如果有功能性的语言，用这个数值改变，因为免疫不能改变了。你想象一下，有一定的人、把这个人加入到列表当中。怎么样让他把所有的人列出来呢?也许在下面给一条getPeople的指令。
给一些简单的建议，比如说用一些接入的修订词，特别是对外API的时候，要有各种的假定，比如说接入的修饰词和修饰条件。如果所有的东西都是对外公开，没有安全的问题才怪!
scott/tiger，有人在笑，很多人拿到密码都没有改，用户和密码缺省或者原始的数据密码都不改，这必须要改，改成一个比较有利的密码。
讲到数据的时候，真的希望能够限制消费者对数据的接入，限制消费者对数据的使用，这可以帮我们收载他们的访问范围。不管我们的网站在什么地方，我们用SQL的数据库怎么做呢，我们用特别的一些代码通过SQL进行数据库的接入，有些时候不喜欢这种方法，觉得过程非常复杂。虽然复杂，但是有一个精简、简单、安全的API，很多人用SQL，就是为了安全性。
2000年的时候，我在一个小的电商公司做网站，他们首次在搞商务网站。他们有一个电商网站，而且是一个盒子，只需要拿一个光盘装到系统上就是一个电商网站了。想存储他们的信用卡号码。客户回到电商时，不需要把信用卡再输一遍，这是盒子提供的，总要有一个地方来放信用卡信息吧!他们看一看数据库里面有没有栏目没有用到，他们发现中间名没人用，就把中间名放信用卡了，只用输入(英文)，没有经过加密，对信用卡进行外键的字符串。我们也知道对这样的外键的字符串可以破解的。这种安全只不过是把字符串进行排列，并没有进行任何的安全加密，只不过支付串操作两次就已经万无一失了。
我们讲过数据代码，也应该谈一下配置、部署，所以有数据库。网络服务器要跟数据库进行沟通的话，必须要用户名和密码。数据库的用户名和密码什么地方?往往是在网页服务上，往往都是明文。如果有人攻击网页服务器，必须提取文件系统，提取之后可以看到明文的文件，这个发生了很多。
安全非常重要，但是安全也非常复杂。作为一个软件的开发员、程序员，要做到敏捷、持续的交付、关注模式，非常流行的词汇。但是安全不是热门词汇，要注意安全的重要性。比如说做网银、网络界面不能忽视安全。想学习更多系统架构相关内容，请进入e良师益友网学习相关系统架构教程。
