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

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

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

　　你可以通过保护最薄弱环节、深度防御、最小特权等方法确保系统安全，但仅此就够了吗？《确保企业系统安全的13条原则（二）》将继续为你介绍其余7种方法。