许可一个进程操作的话，要确保进程必须要操作的，其他不需要操作不要放在这里。这点是所有软件架构师在系统里面必须要牢记的。
　　怎么通过不同的方式来把安全引入到系统里面
　　现在讲验证、授权、审核是三个比较常见的方法。首先，验证。我是用户，是谁呢?权力是什么?用什么东西?这很重要，可以帮助你了解到用户的需求以及不同类型的用户在系统里面扮演不同的角色该怎样具体做呢?有这样的系统怎样能够做好本地的验证和授权。其实很多方法都可以。
　　先来看看一个简单的两级的方式，Web服务器和数据库直接进行对换。讲到安全、认证、授权简单的方法，系统认出你的用户，在系统里面有一个用户的名单，有他们使用的权力，通过映射的方式，客户来了映射能做什么，是不是高效能，不一定。
　　早上说过我们有不同的选择，要解决这样的问题，选择很多的，还有另外一个方法，比如说设计自己的架构，不把你的数据放在数据库里，大的企业会有一种主动的目录和一些算法，是包含了用户和他的一些资格说明，这样的话可以加以利用了。你不会把用户放在你的数据库里，可以把用户放在别的地方，这样的话管理的负担也小了。有新的用户在中间的注册器里面注册新用户可以了。
　　但也许它的角色放在数据库，因为不同角色有不同的授权。所以用户和他的资历放在外面，但是角色放在数据库里，这也是很好分解的办法。或者甚至把授权也放在主动的目录当中，形成不同的群组，这是可以选择的方法。但是会不会比之前的方法更好呢?同样，这并不是我能回答的问题。有些企业、有些组织很愿意做这种，觉得这个够了，可以对于用户的目录专门存放用户的信息。但是其他的一些企业、一些组织并不喜欢把你自己的群组放在自己的服务器上。有些时候可以，有些时候不愿意使用。
　　还有其他的方法，可以用安全令牌的服务，有人做身份基金会的工作，实际上是把安全进行集中化，不管是身份验证还是授权都能够集中起来，我两年前做的一个项目，有一个单独的令牌的系统，这里面给我们带来的复杂性是不可想象的，本来只有一个人做这个项目，压力非常大，非常复杂。这也是一种选择。对某一种企业来说，也许是好的选择。
　　哪一个方案是“好”的?其实没有所谓的好的方案，永远只能对你来说好，对这个环境来说好，所以哪个是好呢?还是回到早上讲过的，从高层的角度上了解我们的需求，了解我们环境的约束性、局限性。如果在大企业工作的话，可能会有一个主动的目录服务器了。可以去找这个有关的部门，可以找你服务器来做验证。可不可以把决策和授权放在目录当中，可以选择好的解决方案。
　　有一个大的英国超市，用明文来记密码，密码以明文的形式寄到邮箱，回归到之前的架构，如果数据库是够安全的话，明文也没问题的。对于这篇文章之后，有一个很好的明文建议，如果用明文密码会加密，而且是散列的处理。我不是一个安全专家，但是我知道至少有不同的方法来把密码进行分类散列，比如说用一些随机的数字进行加密和散列，这都是很好的进行密码散列的方法。当然我们也选择一个适合我们的方法。
　　审查、审计也是一方面，我们要有一个审计的线索。比如说我们在泽西岛是离岸的环境，做很多交易，必须知道哪些用户做了什么?为什么要这么做?因为有人对这个网站提出一些索赔，丢失了信息我们要追诉回去，看一下他的信息怎么丢的，有没有修改。
 
　　怎么能写出安全的代码?
　　网上有很多信息，主要有两个主流：第一，要避免数字被修改。第二，限制接入。
　　当然免疫性很好的，如果免疫的话不能修改。这是一个很好的属性。如果这个数据有一定的对象，而这个对象数据是不能修改的，免疫了不能修改了，所以从根本上来说是安全的。如果有功能性的语言，用这个数值改变，因为免疫不能改变了。你想象一下，有一定的人、把这个人加入到列表当中。怎么样让他把所有的人列出来呢?也许在下面给一条getPeople的指令。
　　给一些简单的建议，比如说用一些接入的修订词，特别是对外API的时候，要有各种的假定，比如说接入的修饰词和修饰条件。如果所有的东西都是对外公开，没有安全的问题才怪!
　　scott/tiger，有人在笑，很多人拿到密码都没有改，用户和密码缺省或者原始的数据密码都不改，这必须要改，改成一个比较有利的密码。
　　讲到数据的时候，真的希望能够限制消费者对数据的接入，限制消费者对数据的使用，这可以帮我们收载他们的访问范围。不管我们的网站在什么地方，我们用SQL的数据库怎么做呢，我们用特别的一些代码通过SQL进行数据库的接入，有些时候不喜欢这种方法，觉得过程非常复杂。虽然复杂，但是有一个精简、简单、安全的API，很多人用SQL，是为了安全性。
　　2000年的时候，我在一个小的电商公司做网站，他们首次在搞商务网站。他们有一个电商网站，而且是一个盒子，只需要拿一个光盘装到系统上是一个电商网站了。想存储他们的信用卡号码。客户回到电商时，不需要把信用卡再输一遍，这是盒子提供的，总要有一个地方来放信用卡信息吧!他们看一看数据库里面有没有栏目没有用到，他们发现中间名没人用，把中间名放信用卡了，只用输入(英文)，没有经过加密，对信用卡进行外键的字符串。我们也知道对这样的外键的字符串可以破解的。这种安全只不过是把字符串进行排列，并没有进行任何的安全加密，只不过支付串操作两次已经万无一失了。
　　我们讲过数据代码，也应该谈一下配置、部署，所以有数据库。网络服务器要跟数据库进行沟通的话，必须要用户名和密码。数据库的用户名和密码什么地方?往往是在网页服务上，往往都是明文。如果有人攻击网页服务器，必须提取文件系统，提取之后可以看到明文的文件，这个发生了很多。
　　怎么样解决这些问题呢?
　　要确保这个信息加密。用Java系统也有加密的配置办法，这都有办法，只是有没有这个意识。我们可以用一些CQL服务器受信任的连接可以避免了。
　　之前我在泽西岛做的项目是离岸银行，他们很重视，我们做自己的虚拟机、手提电脑来写代码，但是要部署到银行系统，我们要用一些连续的工具放入U盘上，把U盘交给银行的人，接入另外一个网络，装入软件当中。这里我们的开发团队和部署团队是物理隔离的，避免了开发团队能够染指生产的系统。
　　问题在做部署的人根本不太理解做开发的原意，不是一个技术人员。所以我们在自己废寝忘食的写了这么多代码，交给他之后，不懂怎么部署，物理隔离不能保障安全，这个过程或者流程肯定有漏洞的。不是说一定能解决这样的问题。
　　生产的资质、资格也是一个问题。比如说有一个经过测试的环境，这个环境把它放入生产的系统当中，当中有这个隔离。把生产的用户名和密码放在什么地方呢?也许你可以放在配置服务器的一个地点，但这个要看多么看重安全性，如果连续交付很有意思了，连续交付有关的资质要考虑怎么存放。
　　运行时间方面和安全有什么关系呢?
　　这里说到重要的原则“小特权原则”，我们看一看这个模型。在Java应用里面可以用Java2的安全模型，允许你做一部分的工作，比如说只能进入到这方面的网络或者只能用这部分的接口，这是Java的安全模型。如果网站被黑的话，肯定会直接攻击里面用户。一般不会这么做，会密码也不改，不限制账户的使用，导致黑客很轻易获取信息。
　　之前我在电商工作过，有一些信息方面的问题，找到他们的日志文件，发现有很多的错误信息，成千上万的错误信息。人们要输入信用卡信息，信用卡信息也都在日志文件里面。在日志文件里面，地址、名字、信用卡信息以及信用卡盗窃事件都有。
　　我们还要有效监控管理界面方面的安全，不能把东西放在云端上觉得什么事都搞定了，还要看监控确保运行合理合适。我在做顾问的时候，曾经帮一个电商的网站做很短的项目。如果我打开我的浏览器连上网，完全可以看想看的页面，没有基本的二进制密码保护。
　　架构师要知道基础结构
　　我是项目上的软件架构师，不做基础设施的设计，但是不必须要了解到防火墙的设置等。因为确保基础的设施才能支持我们软件的架构。另外，从软件的角度来讲，也非常的重要。早不是我做的，我做的很多系统都是在泽西岛，因为很多的数据都有地域限制，必须要用本地的服务器，要把服务器信息拿出去的话，第一件事情是把原来的安全保护、防火墙没有用的东西都拿走，这样可以减少空间内容。要和基础设施团队DMZ来谈一谈防火墙等。从软件架构师角度来讲，要使用web服务或者RMI等不同服务，软件架构团队和基础设施团队必须要有沟通才行。
　　攻击者、黑客以及我们的漏洞
　　我在伦敦工作的时候，很多是做公司内部的，回到泽西岛的时候，做了很多互联网的界面，影响到数据安全性。如果大家觉得讲得这些内容比较陌生的话，希望大家能够好好地看一看开源的应用安全项目。
　　列出了10个主要的，注入、跨站脚本攻击、验证、对话管理等。从安全角度讲是值得一看的东西。有一次看了CQL的注入，我不是一个安全专家，但是我看了CQL注入知道成为安全隐患，因为电击链接可以看到很多信息。
　　现在看到的是中文版，叫做OWASP，中文版的，喜欢网站是因为告诉我们主要的攻击方式，给一些例子，该怎样修复这些漏洞，避免这些攻击再次发生。
　　近经历一件事是很多系统都要做深度测试。找一些外部第三方的团队或者公司来看不看能不能黑你的系统，看系统到底多牢固。我们会发现他们攻击的时候，很多之前没有注意到的漏洞浮出水面。这些团队给一些例子，既然找到漏洞，告诉我们该怎样把漏洞一个个补好。非常建议第三方来做测试。
　　后总结
　　安全非常重要，但是安全也非常复杂。作为一个软件的开发员、程序员，要做到敏捷、持续的交付、关注模式，非常流行的词汇。但是安全不是热门词汇，要注意安全的重要性。比如说做网银、网络界面不能忽视安全。上午讲了文本介入，搞文本轻一点行了，不能太复杂，做一个软件的架构，给别人用，不给文件不知道安全怎么做，不知道安全怎么做，可能会加一些编码，这些编码反而让你的安全系统安全用不上了，可能一两年之后安全彻底失明了。因此我们提供不太厚的文件，里面有关键信息。
　　刚才讲了怎么样收集用户的一些要求，把它进行排序。当然不能完全依赖他的想法，但是要让他知道安全方面哪些重要的。安全很重要，而且适用于整个软件架构的所有环节。从外部端到数据库端，从跨件的脚本到注入等，都要确保里面内容是安全的。上下文非常关键，这里有一些安全方面的佳实践。如果之是照搬别人的非常复杂，所以要知道哪些是需要取舍的，做这些风险会带来什么影响，会泄露什么数据?这些数据有价值还是没价值的?用这些为什么而用，提高应用性和复杂性。
　　一个人不可能样样精通，我对安全不是专家，但是对安全要了解一些情况。我们知道行业不断变化，速度非常快。既然不可能把所有的知识都学的很透彻，至少我们能够粗浅的像蜻蜓点水了解一些东西。另外，千万别做一个不负责任的软件架构师。因为我们架构师像一个一样，确保所有的工作都能有效。