很久以前，Jerry Saltzer和Michael Schroeder发表了一篇论文，题为“计算机系统中的信息保护”，该论文的第三部分提供了信息安全的一些基本设计原则。人们都说，他们给安全界带来启发式的影响，其实不仅如此，在近40年后的今天，他们早在1975年提出的原则仍然实用。

    在新年开始之际，笔者建议你在设计新系统时采用这13个原则。虽然13并不认为是吉利的数字，但笔者相信，当你将这些原则在企业中付诸实践时，将会给你带来好运气。

    13条安全设计原则

    1）保护最薄弱环节–-Spaf（即备受推崇的普渡大学安全专家Gene Spafford）通过一个有趣的故事来说明这个原则。试想一下，你需要负责把睡在公园长椅上的无家可归的人（我们称他为Linux）的财产运送给另一个无家可归的女人（我们称她为Android），你租用了一辆装甲卡车来运送，运输公司的名称是“Applied Crypto, Inc.”。现在，假设你是准备窃取财产的攻击者，你是会攻击Applied Crypto卡车、无家可归的人Linux还是无家可归的女人Android？很容易做出选择吧？（提示：答案是，“除了卡车以外”）

    笔者及其合著者John Viega在2001年撰写的《构建安全软件》一书中写道，“安全从业者经常指出，安全就像一根链条，链条的强弱取决于其最薄弱的环节，同样的道理，软件安全系统的安全性也取决于其最薄弱的组件。”攻击者往往会寻找系统中最薄弱的地方，而最薄弱的地方很少会是某个安全功能或特性。当涉及到安全设计时，一定要考虑你的系统中最薄弱的环节，确保它是足够安全的。

    2）深度防御–笔者和Kenneth van Wyk喜欢将这个称为“腰带和吊袜带”的方法。在安全领域，冗余和分层通常是好事。不要指望你的防火墙来阻止所有恶意流量；同时还应该使用入侵检测系统。如果你正在设计一个应用，通过安全冗余和防御层来防止单点故障。《构建安全软件》中提到：“深度防御背后的概念是管理不同防御策略的风险，这样的话，即使某个防御层无法提供足够的安全性，另一个防御层将有可能防止数据泄露。”这是信息安全专家普遍认同的概念，理由很简单：它有用。

    3）保证失效后的安全性—请确保你设计的系统不会在失效后保持“开放”。关于这个原则，笔者最喜欢的故事是命运多舛的Microsoft Bob产品（Bob是Clippy回形针的前身），据传说，如果你三次尝试输入用户名和密码失败后，Bob将会询问你是否要选择使用一个新密码，感谢Bob（攻击者说）！很显然，在这种情况下，更好的默认设置应该是拒绝访问。

    《构建安全软件》中提到：“任何足够复杂的系统都会失效，失效是不可避免的，企业应该提前做好准备。可以避免的是与失效相关的安全问题。但问题是，当很多系统以任何方式失效时，它们都会表现出不安全行为。”

    4）最小特权—当你需要为用户或进程授予权限来完成一些操作，尽可能授予最小的权限。想想你的Outlook联系人列表，如果你需要别人访问你的联系人列表来查看一些数据，授予他们读者权限，但不要授予编辑权限。这有一个更专业的例子：系统的大多数用户的日常工作并不需要根级权限，所以不要授予他们根级权限。底线是，避免无意的、不必要的或不正确的权限使用，以“吝啬”的方式来授予权限。

    5）独立权限—笔者曾经看到一个系统将其认证前端划分成大量角色，这些角色对系统有不同程度的访问。问题是，当任何角色的用户需要执行后端数据库操作时，该软件会临时授予每个用户管理员权限。这样做并不好，即使是最底层的实习生也可以侵入数据库。要知道，如果攻击者可以骗取一个权限，而无法得到第二个权限时，他将无法成功发起攻击。所以保持权限的分离。

[page]    6）经济机制—复杂性是安全工程的敌人，却是攻击者的朋友。无论是从设计的角度来看，还是从部署的角度来看，在复杂的系统中，很容易将事情“搞砸”。具有讽刺意味的是：想看看复杂的东西吗？只要看一看现代企业软件的任何一部分。

    尽可能保持事物简单。《构建安全软件》中提到，“KISS的口头禅众所周知：‘保持简单，保持愚蠢！（Keep It Simple, Stupid!）’这个说法同样适用于安全领域及其他任何领域。复杂性增加了问题的风险，避免复杂性，就是避免问题。”

    7）不要共享机制—你是否应该将面向内部的业务应用放在公共云中？根据这条原则，最好不要。你可以将你的身份验证系统限制为你信任的员工，为什么让你的系统处理随机互联网流量呢？

    还有一个专业的例子：如果你有多个用户使用相同的组件，让你的系统为每个用户创建不同的实例。不共享用户之间的对象和访问机制，可以减少安全故障的可能。

    8）不要轻易信任—假设你的系统运行的环境处于不利条件，不要让所有人都能调用你的API，当然也不要让所有人能够访问你的机密信息。如果你依赖于云组件，你需要对其进行检查，以确保它没有被欺骗或者受到感染。预防命令注入、跨站脚本等攻击。在《构建安全软件》中，“最后一点要记住的是，信任是可传递的，当你给出信任时，你往往会将这种信任扩展到你信任的实体所信任的对象上。”

    9）假设你的机密信息并不安全—安全不能“含糊其辞”，特别是当涉及存储在你的代码中的秘密信息时。假设攻击者能够找出关于你的系统尽可能多的信息，甚至可能超过超级用户。攻击者的工具包有反编译器、反汇编器以及很多分析工具。假设他们瞄准了你的系统，他们怎么查看二进制码中的加密密钥？函数扫描会让加密密钥呼之欲出，毕竟二进制只是一种语言。

    10）彻底检查--企业应该对每次访问和每个对象进行检查。请确保你的访问控制系统是全面的，适应当今这个多线程世界的。不管你做什么，如果更改系统权限，请确保对访问进行了系统化的重复检查。不要缓存授权或使用权的结果。在充满大规模分布式系统和多处理器计算机的世界，这条原则非常重要。

    11）使安全可用—如果你的安全机制太繁琐，你的用户会想尽办法规避或避免它们。请确保你的安全系统足够安全，但也不要“过头”。如果你深深地影响了可用性，没有人会使用你的东西，不管它多么安全。虽然它非常安全，但同时也非常没用。Spaf经常会笑话据称是世界上最安全的系统，即系统硬盘消磁，被埋在填满混泥土的30英尺的围绕法拉第电网的洞里。这样的系统肯定很难使用。

    12）保护隐私--大家都在谈论保护隐私，但大多数人实际上没有做任何相关事情。你可以帮助解决这个问题。当你设计一个系统时，考虑一下最终用户的隐私。你收集个人识别信息（PII）只是因为市场部有人要求这样做吗？这样做好吗？你是将PII存储在可能受到破坏的地方吗？难道不应该对这些信息进行加密吗？信息安全从业人员并不需要提供对这些隐私问题的答案（这是首席信息官的工作），但如果没有其他人提出这类问题，你需要提出。

    13）使用你的资源—正如笔者14岁时在童军领导培养课程中学到的那样，“使用你的资源”这条原则具有令人难以置信的广泛应用范围。如果你不确定你的系统设计是否安全，请寻求帮助。架构风险分析很难，但有些人已经做了几十年。如果你做不到的话，最好不要尝试单独操作。不要羞于寻求帮助，这件事情非常复杂。

    借用别人的好点子

    笔者永远都不会忘记在硅谷的HSARPA会议演示软件安全幻灯片的那天。这个幻灯片是基于笔者的《构建安全软件》一书中的内容，该书有一章是围绕这些安全原则。其中一张幻灯片是Saltzer和Schroeder的图谱，你猜谁正好坐在观众席中？正是Michael Schroeder本人，他赞扬了这个幻灯片，这个世界确实很小。Saltzer和Schroeder在1975年是正确的，当我们在撰写《构建安全软件》的今天仍然是正确的。将他们的原则应用到2013年的安全工作中，不要害怕使用别人想出的好想法。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。