安全设计十大原则.docx

CISSP （ Certified Information Systems Security Professional）相关资料有统计：通过合适的十大设计原则可以避免90%的问题。1、简单易懂越复杂越容易出错。越复杂，越难审查得透彻，也越难测试得比较全面，从而使得一些安全缺陷遗留在系统中。随着系统复杂度的增加，系统的安全风险也在变高。减少冗余、提高组件重用度。经验构筑了保证，特别当那些经验是成功的经验时。瓶颈是至系统的一个狭窄接口，您通过它强制所有流量通过该接口，因此您可以方便地进行 控制。您应该避免在系统中分布安全性代码，因为这会使维护更加困难。另外，如果强制您的所有用户通过几条小通道，则监控用户行为会简便得多。这与只有几个 入口的体育馆是同一个道理；如果入口有很多，检票就困难多了。为了达到相同的效果，您需要多得多的员工。可用性与安全：1）用户不会阅读文档。如果用户需要做任何特别的事情才能获取您所提供的全部安全性好处，那么用户未必接受那些好处。因此，您应该在缺 省情况下提供安全性。用户应该不需要了解关于安全性的任何事情以及不需要做一些特别的事情就能安全地使用您的产品。当然，安全性是一个相对的术语；您必须 作出一些关于用户安全性需求的决定。考虑缺省情况下关闭了加密的企业应用程序服务器。通常，您可以使用管理工具上某处的某些菜单选项来打开它。即使系统管理员不再考虑安全性，那个人也可能认为“缺省情况下他们必定打开了加密。”我们已经看见了许多服务器并未这样做。2）与用户交谈以弄清其安全性需求。正如 Nielson 喜欢说的那样，副总裁 不是用户。您不应该假设您知道这条信息；直接转至源头。尝试为用户提供比他们想象所需的安全性更多的安全性。 3）认识到用户未必总是正确的。大部分用户不是博识的。他们可能不理解安全性问题，因此您仍应该尝试预见他们的需要。这是个好主意，但 在安全性方面可能出错。如果您对他们需要作出的评估多于他们所需要的安全性，则使用您的（实际上，尝试提供比您想象他们所需的安全性更多的安全性）。如果 他们提供的更多，则干脆相信他们。例如，考虑一个诸如 Web 门户网站的系统，您提供的一种服务是股票报价。您的用户可能从不认为有好的理由来保护那些资料。毕竟股票报价是用于公共消费的。但有一个好的理由 一个攻击者可能篡改用户得到的报价。然后用户可能根据伪造信息来确定股票买卖，结果倾家荡产。您确实不必加密数据 您可以使用消息认证码（MAC） 但大多数用户未必预见到这一风险。4）用户是懒惰的。他们是如此懒惰，以至于实际上即使当您抛出用大的鲜红字母显示的“警告”对话框时，他们也不愿停下来考虑安全性。对 于用户来说，对话框是一种讨厌的东西，它阻止他们完成想做的事。例如，许多移动式代码系统（例如，那些当使用 Internet Explorer 浏览 Web 时运行 Active X 控件的系统）将显示一个对话框，告诉您代码是谁编写的，并询问您是否确实想信任那个人。您认为实际上有人阅读这些东西吗？没有。用户只是想通过阻力最少的 途径马上运行代码，而不考虑后果。2、最小特权最小特权原则规定：只授予执行操作所必需的最少访问权，并且对于该访问权只准许使用所需的最少时间。当您给出了对系统某些部分的访问权时，一般会出现滥用与那个访问权相关的特权的风险。例如，我们假设您出去度假并把您家的钥匙给了您的 朋友，好让他来喂养您的宠物、收集邮件等等。尽管您可能信任那位朋友，但总是存在这样的可能：您的朋友未经您同意就在您的房子里开派对或发生其它您不喜欢 的事情。不管您是否信任您的朋友，一般不必冒险给予其必要的访问权以外的权利。例如，如果您没养宠物，只需要一位朋友偶尔收取您的邮件，那么您 应当只给他邮箱钥匙。即使您的朋友可能找到滥用那个特权的好方法，但至少您不必担心出现其它滥用的可能性。如果您不必要地给出了房门钥匙，那么所有一切都 可能发生。同样，如果您在度假时确实雇佣了一位房子看管人，那么您不可能在没有度假时还让他保留您的钥匙。如果您这样做了，那么您使自己陷入额外 的风险之中。只要当您的房门钥匙不受您的控制，就存在钥匙被复制的风险。如果有一把钥匙不受您的控制，而且您不在家，那么就存在有人使用钥匙进入您房子的 风险。当有人拿了您的钥匙，而您又没有留意他们，那么任何这样的一段时间都会构成一个时间漏洞，在此段时间内您就很容易受到攻击。为了将您的风险降到最 低，您要使这段易受攻击的时间漏洞尽可能的短。现实生活中的另一个好的示例是美国政府的忠诚调查系统 “需要知道”政策。即使您有权查看任何机密文档，您仍不能看到您知道其存在的 任何机密文档。如果可以的话，就很容易滥用该忠诚调查级别。实际上，人们只被允许访问与那些交给他们的任务相关的文档。 UNIX 系统中出现过一些违反最小特权原则的最著名情况。例如，在 UNIX 系统上，您一般需要 root 特权才能在小于 1024 的端口号上运行服务。所以，要在端口 25（传统的 SMTP 端口）上运行邮件服务器，程序需要 root 用户的特权。不过，一旦程序在端口 25 上运行了，就没有强制性要求再对它使用 root 特权了。具有安全性意识的程序会放弃 root 特权并让操作系统知道它不应再需要那些特权（至少在程序下一次运行之前）。某些电子邮件服务器中存在的一个大问题是它们在获取邮件端口之后没有放弃它们的 root 权限（Sendmail 是个经典示例）。因此，如果有人找到某种方法来欺骗这样一个邮件服务器去完成某些恶意任务时，它会成功。例如，如果一位怀有恶意的攻击者要在 Sendmail 中找到合适的栈溢出（请参阅 参考资料），则那个溢出可以用来欺骗程序去运行任意代码。因为 Sendmail 在 root 权限之下运行，所以攻击者进行的任何有效尝试都会成功。 另一种常见情况是：一位程序员可能希望访问某种数据对象，但只需要从该对象上进行读。不过，不管出于什么原因，通常该程序员实际需要的 不仅是必需的特权。通常，该程序员是在试图使编程更容易一些。例如，他可能在想，“有一天，我可能需要写这个对象，而我又讨厌回过头来更改这个请求。”3、故障安全化任何十分复杂的系统都会有故障方式。这是很难避免的。可以避免的是同故障有关的安全性问题。问题是：许多系统以各种形式出现故障时，它们都归结为不安全行为。在这样的系统中，攻击者只需造成恰当类型的故障，或者等待恰当类型的故障发生。我们听说过的最好的现实示例是将现实世界同电子世界连接起来的示例 信用卡认证。诸如 Visa 和 MasterCard 这样的大型信用卡公司在认证技术上花费巨资以防止信用卡欺诈。最明显地，无论您什么时候去商店购物，供应商都会在连接到信用卡公司的设备上刷您的卡。信用 卡公司检查以确定该卡是否属被盗。更令人惊讶的是，信用卡公司在您最近购物的环境下分析您的购物请求，并将该模式同您消费习惯的总体趋势进行比较。如果其引擎察觉到任何十分值得怀疑的情况，它就会拒绝这笔交易。系统出现故障时，系统的行为没有通常的行为安全。遗憾的是，系统故障很容易引起。例如，很容易通过将偷来的信用卡在一块大的磁铁上扫一下来毁坏其磁条。这么做，只要小偷将卡用于小额购买（大额购买经常要求更好的验证），他们就或多或少地生出了任意数目的金钱。从小偷的角度看，这一方案的优点是：故障很少会 导致他们被抓获。有人可以长期用这种方法使用同一张卡，几乎没有什么风险。为什么信用卡公司使用这种愚蠢落后的方案呢？答案是：这些公司善于风险管理。只要他们能够不停地大把赚钱，他们就可以承受相当大数量的欺诈。他们也知道阻止这种欺诈的成本是不值得的，因为实际发生的欺诈的数目相对较低。（包括成本和公关问题在内的许多因素影响这一决定。）确保如果系统出现故障，那么它将以安全方式失败，例如，自动关闭。由于故障引起DoS攻击安全与可用性：单点故障，例如认证授权模块出现故障会影响所有人的使用。在设计时，需要考虑系统的可用性需求，设计一定的冗余度。当一个组件出现故障时，可以无缝切换到备用组件。4、保护最薄弱环节安全性社区中最常见的比喻之一是：安全性是根链条；系统的安全程度只与最脆弱的环节一样。结论是系统最薄弱部分就是最易受攻击影响的部分。攻击者往往设法攻击最易攻击的环节，这对于您来说可能并不奇怪。如果他们无论因为什么原因将您的系统作为攻击目标，那么他们将沿阻力最小的路线采取行动。这意味着他们将试图攻击系统中看起来最薄弱的部分，而不是看起来坚固的部分。即便他们在您系统各部分上花费相同的精力，他们也更可能在系统最需要改进的部分中发现问题。这一直觉是广泛适用的。银行里的钱通常比便利店里的钱多，但是它们哪一个更易遭到抢劫呢？当然是便利店。为什么？因为银行往往有更强大的安全性防范措施；便利店则是一个容易得多的目标。这一原则显然也适用于软件世界，但大多数人并没有给予任何重视。特别地，密码术不太会是系统最薄弱的部分。即使使用具有 512 位 RSA 密钥和 40 位 RC4 密钥的 SSL-1，这种被认为是难以置信的薄弱的密码术，攻击者仍有可能找到容易得多的方法进入。的确，它是可攻破的，但是攻破它仍然需要大量的计算工作。如果攻击者想访问通过网络传输的数据，那么他们可能将其中一个端点作为目标，试图找到诸如缓冲区溢出之类的缺陷，然后在数据加密之前或在数据解密之后查看数据。如果存在可利用的缓冲区溢出，那么世界上所有的密码术都帮不了您。如果执行一个好的风险分析，则标识出您觉得是系统最薄弱的组件应该非常容易。您应该首先消除看起来好象是最严重的风险，而不是看起来最容易减轻的风险。一旦一些其它组件很明显是更大的风险时，您就应该将精力集中到别的地方。当然，可以永远使用这一策略，因为安全性从来就不是一个保证。您需要某些停止点。根据您在软件工程过程中定义的任何量度，在所有组件都似乎在可接受的风险阈值以内时，您应该停下来。5、提供纵深防御纵深防御背后的思想是：使用多重防御策略来管理风险，以便在一层防御不够时，在理想情况下，另一层防御将会阻止完全的破坏。即便是在安全领域以外，这一原则也是众所周知的；例如，这是编程语言设计的著名原则：纵深防御：采取一系列防御，以便在一层防御不能抓住错误时，另一层防御将可能抓住它。（摘自 Bruce MacLennan 的 Principles of Programming Languages。参阅 参考资料。） 为什么典型的银行比典型的便利店更安全？因为有许多冗余的安全性措施保护银行 措施越多，它就越安全。单单安全摄像机通常就足以成为一种威慑。但如果攻击者并不在乎这些摄像机，那么安全保卫就将在那儿实际保护银行。两名安全保卫甚至 将提供更多的保护。但如果两名保卫都被蒙面匪徒枪杀，那么至少还有一层防弹玻璃以及电子门锁来保护银行出纳员。如果强盗碰巧砸开了这些门或者猜出了PIN，起码强盗将只能容易抢劫现金出纳机，因为我们有保险库来保护余下部分。理想情况下，保险库由几个锁保护，没有两个很少同时在银行的人在场是不能被打开的。至于现金出纳机，可以为其装备使钞票留下印记的喷色装置。DMZ（De Militarized Zone）非军事区大部分公司建立企业级的防火墙来阻止入侵者侵入。 然后这些公司假定防火墙已经足够，并且让其应用程序服务器不受阻碍地同数据库“交谈”。如果数据非常重要，那么如果攻击者设法穿透了防火墙会发生什么呢？ 如果对数据也进行了加密，那么攻击者在不破解加密，或者（更可能是）侵入存储未加密形式的数据的服务器之一的情况下，将不能获取数据。如果我们正好在应用 程序周围建立另一道防火墙，我们就能够保护我们免遭穿透了企业防火墙的人攻击。那么他们就不得不在应用程序网络显式输出的一些服务中寻找缺陷；我们要紧紧掌握那些信息。2011年轰动全国的各大网站数据泄漏事件。6、分隔分隔背后的基本思想是如果我们将系统分成尽可能多的独立单元，那么我们可以将对系统可能造成损害的量降到最低。当将潜水艇构造成拥有许 多不同的船舱，每个船舱都是独立密封，就应用了同样原则；如果船体裂开了一个口子而导致一个船舱中充满了水，其它船舱不受影响。船只的其余部分可以保持其 完整性，人们就可以逃往潜水艇未进水的部分而幸免于难。分隔原则的另一个常见示例是监狱，那里大批罪犯集中在一起的能力降到了最低。囚犯们不是居住在营房中，而是在单人或双人牢房里。即使他们聚集在一起 假定，在食堂里 也可以加强其它安全性措施来协助控制人员大量增加带来的风险。假设您在度假，而你需要一位宠物看管人。您希望看管人只能进出您的车库（您不在时将宠物留在那里）但是如果您的车库没有一把单独的锁，那么您别无选择而只能让看管人进出整幢房子。在计算机世界里，要举出糟糕分隔的示例比找出合理分隔容易得多。标准 UNIX 特权模型，其中安全性是关键的操作是以“完全访问或根本不准访问”为基础的。如果您拥有 root 特权，那么您基本上可以执行您想要的任何操作。如果您没有 root 访问权，那么就会受到限制。例如，您在没有 root 访问权时不能绑定到 1024 以下的端口。不要把所有鸡蛋放在一个篮子里。例如Web服务、数据库服务、文件服务都放到一台服务器上。分隔的使用必须适度，许多其它原则也是如此。如果您对每一个功能都进行分隔，那么您的系统将很难管理。7、总体调节每次访问一个对象时，都要检查访问是否授权，特别是对安全来说很关键的对象。在一个网站的注册页面上，需要输入Captcha，当用户提交注册时，会首先发送一个请求检查Captcha的有效性，然后再发送注册的用户信息。但是，在第二步请求处理时没有验证前一次检查的Captcha的结果，导致可以直接绕过验证Captcha的请求，直接发送注册用户的请求。这里虽然做了验证，但是没有使用验证的结果，等于没有做验证。8、默认不信任直接对象引用、缺乏访问控制的URL等问题都是由于默认信任导致的。勉强相信您自己的服务器， 以防止数据窃取（请参阅 参考资料 中提到的“原则 3：划分”）。 这种犹豫应该渗透到安全性过程的各个方面。 例如，虽然现成的软件的确可以帮助您简化您的设计和实现，但您怎么知道相信现成组件是安全的呢？ 您真的认为开发人员就是安全性方面的专家吗？ 即使他们是，您期望他们确实可靠吗？许多有安全性漏洞的产品都来自安全性供应商。 许多从事安全性业务的人实际上并不太了解有关编写安全代码方面的知识。 通常很容易扩展信任的另一个地方是客户支持。 毫无戒心的客户支持代理（他们有相信的倾向）非常容易遭到社会工程攻击，因为它会使他们的工作变得更加容易。 您还应该注意一下“随大流”。仅仅因为一个特殊的安全性功能是标准的并不意味着您应该提供同样低级的保护。 例如，我们曾经常听到人们选择不加密敏感数据，仅仅是因为他们的竞争对手没有对数据进行加密。 当客户遭到攻击，于是责备某人疏忽安全性时，这就不是充足的理由。勉强相信您自己和您的组织。当涉及您自己的主意和您自己的代码时很容易目光短浅。 尽管您可能喜欢完美，但您应该容许不完美，并且对正在做的事情定期获取高质量的、客观的外部观点。信任是可转移的。一旦您信任某个实体， 就会暗中将它扩展给该实体可能信任的任何人。出于这个原因，可信的程序决不应该调用不可信的程序。 当确定要信任哪些程序时，也应该十分小心；程序可能已经隐藏了您不想要的功能。 例如，在 90 年代早期，我们有一个具有极受限制的、菜单驱动功能的 UNIX 帐户。 当您登录时从菜单开始，并且只能执行一些简单操作，如读写邮件和新闻。 菜单程序信任邮件程序。当用户编写邮件时，邮件程序将调出到一个外部编辑器（在这种情况下，是“vi”编辑器）。 当编写邮件时，用户可以做一些 vi 戏法来运行任意命令。当它关闭时， 很容易利用对 vi 编辑器的这种隐含的、间接的信任完全摆脱菜单系统，而支持正规的旧的不受限的命令行 shell。 信任公众虽然盲目随大流不是一个好主意， 但从数字上讲还是有一点实力。无失败地重复使用会增进信任。公众的监督也可增进信任。 （这是应用这个原则的唯一时机；其它情况下，原则 9 是正确应用的一个原则，您应该忽略这个原则。） 例如，在密码术中，信任公众不知道的且未受广泛监督的任何算法被认为是一个坏想法。 大多数密码算法在安全性方面都没有真正可靠的数学证明； 仅当一群聪明人花大量时间来尝试破解它们并且都没有实质性进展时才信任它们。 许多人发现编写他们自己的密码算法很有吸引力， 希望如果这些算法不牢靠，含糊的安全性将用作安全网络。 重申一遍，这种希望将破灭（例如，前面提到的 Netscape 和 E*Trade 破坏）。 争论结果通常是，秘密算法比公众知道的算法好。 我们已经讨论了您应该如何期望您的算法秘密不会保持太久。 例如，RC4 加密算法应该是 RSA Data Security 的商业秘密。然而，在其引入后不久， 它被进行逆向工程并在因特网上以匿名方式张帖出来。 事实上，加密者设计他们的算法，使算法知识对安全性无关紧要。 好的密码算法能起作用是因为您保守了一个称为“密钥”的小秘密，而不是因为算法是秘密的。 即，您需要唯一保守秘密的东西就是密钥。如果您可以做到这一点， 并且算法真的很好（且密钥足够长），那么即使是非常熟悉该算法的攻击者也无法攻击您。 同样，最好信任已被广泛使用并且被广泛监督的安全性库。 当然，它们可能包含尚未被发现的错误 但至少您可以利用其他人的经验。 仅当您有理由相信公众正在尽力提升您要使用的组件的安全性时，才应用这个原则。 一个常见的误解是相信“开放源码”软件极有可能是安全的，因为源代码可用性将导致人们执行安全性审计。 有一些强有力的证据表明：源代码可用性没有为人们审阅源代码提供强大的动机， 即使许多人愿意相信那个动机存在。例如，多年来，广泛使用、自由软件程序中的许多安全性错误没有引起人们注意。 对于最流行的 FTP 服务器（WU-FTPD），有几个安全性错误被忽视已有十多年！ 9、保护隐私用户通常认为隐私是安全性问题。您不应该做任何可能泄露用户隐私的事情。并且在保护用户给您的任何个人信息方面，您应该尽可能地认真。您可能听说过恶意的黑客能够从 Web 访问整个客户数据库。还经常听说攻击者能够截获其它用户的购物会话，并因此获得对私有信息的访问。您应该竭尽所能避免陷入这种窘境；如果客户认为您不善处理隐私问题，则您可能很快失去他们的尊重。维护隐私可能经常要与可用性作折衷。例如，最好一使用信用卡就删除卡号。那样，即使您的网站被闯入，您也没有长期存储任何有价值的信息。可是，用户讨厌该解决方案，因为它意味着每次他们想买东西时都必须输入其信用卡数据。这使“一次单击购物”的便利性不可能实现。这里唯一的解决方案是存储信用卡信息，但重要的是务必十分小心。您应该永远不要向用户显示其自己的信用卡号，以免有人设法获取未授权的 访问。常见的一种解决方案是显示部分信用卡号，而隐藏某些数字。这也不是一种完美的解决方案。最好的方法总是对信用卡号加锁；没有理由向用户显示。在服务器端，您应该加密信用卡号，然后将它输入数据库。在另一台机器上保存信用卡号的密钥。那样，如果您的数据库被泄露，攻击者仍然需要找到密钥，这需要闯入另一台机器。任何您可以提高的障碍设置都将有所帮助。秘密和谎言 用户隐私不是您应该考虑的唯一的隐私类型。恶意的黑客往往根据容易从您的系统中收集的信息发起攻击。您机器上的服务往往会给出有关它们自身的信息，这些信息可能有助于攻击者弄清如何闯入。例如，Telnet 服务往往会给出操作系统名称和版本。那么，您如何避免给出更多不必要给出的信息呢？首先，您应该使用防火墙以阻挡不必要的服务，这样攻击者就无法从它们获取附加信息了。其 次，无论您是否受防火墙保护（记得吗，深度防御？），您都应该尝试从软件中除去所有关于这种特性的信息。您可以更改 Telnet 登录以隐藏操作系统规格。实际上，为什么不对这类信息撒谎呢？它可以通过将 Linux 机器说成 Solaris 机器而毫不费劲地让潜在攻击者白费力气；远程 Solaris 利用通常将不会让某人登录到 Linux 机器上。在弄清您欺骗了他之前，攻击者很早就可能因受挫而放弃。把任何类型的信息留在系统上都可能帮助潜在攻击者。相反，您要做的是尽可能阻止他们。如果您正在使用 Rijndael 作为加密算法，则可以毫不费力地声明您实际上在使用 Twofish。两种算法被认为提供相似级别的密码安全性，因此不会有任何损害。从您的环境中收集信息的攻击者可能获取各种细微信息。例如，不同 Web 服务器软件的已知特性可以很快告诉您系统运行的是什么软件，即使该软件被修改成不报告其版本。这种信息通道称为 秘密通道，因为他们不是明显的。通常，关闭系统中的每个秘密通道是不可能的。这可能是系统中最难以识别的安全性问题。对于隐私，您的最佳策略是尝试找出看起来最秘密的通道，然后通过让潜在攻击者白费力气来使用它们以获得好处。10、公开设计，不要假设隐藏秘密就是安全安全性通常是有关保守秘密的。用户不想让其个人数据泄漏出去，所以您必需加密密钥以避免窃听或篡改。 您还要保护您的绝秘算法免遭竞争者破坏。这些类型的需求很重要， 但是与一般用户猜疑相比较，很难满足这些需求。 很多人以为用二进制表示的秘密也许能保守秘密，因为要抽取它们太困难了。 的确，二进制是复杂的，但要对“秘密”保密实在是太困难了。 一个问题就是某些人实际上相当擅长对二进制进行逆向工程 即，将它们拆开，并断定它们是做什么的。 这就是软件复制保护方案越来越不适用的原因。熟练的黑客通常可以避开公司尝试硬编码到其软件中的任何保护， 然后发行“破译的”副本。很长时间以来，使用的技术越来越多； 供应商为阻止人们发现“解锁”软件的秘密所投入的精力越多，软件破解者在破解软件上花的力气也越多。 在极大程度上，都是破解者达到目的。人们已经知道有趣的软件会在正式发布之日被破解 有时候会更早。 如果软件都在您自己网络的服务器端运行，您可能会判定您的秘密是安全的。 实际上，它比隐藏秘密难得多。如果您可以避免它