有很多安全建议告诉程序员不要做什么。您认为在编写良好安全性时应该遵循的最佳做法是什么？
请在下面添加您建议的安全控制/设计模式。建议的格式是一个大胆的标题，总结了这个想法，然后是描述和例子，例如：
默认拒绝
拒绝未明确允许的所有内容...
请投票或评论改进，而不是复制现有答案。请在自己的答案中加入不同的模式和控件，而不是在3或4个首选控件中添加答案。
编辑：我正在制作一个社区维基以鼓励投票。
答案 0 :(得分：4)
人们列出的所有这些想法（隔离，最小特权，白名单）都是工具。
但您首先必须知道“安全”对您的应用程序意味着什么。通常它意味着类似
一旦你知道你的应用程序的安全意味着什么，那么你可以开始围绕它进行设计。
一种不经常提及的设计实践是 Object Capabilities 。
许多安全系统需要做出授权决策 - 如果这段代码能够访问此文件或打开该机器的套接字。
访问控制列表是一种方法 - 指定可以访问的文件。这样的系统虽然需要大量的维护费用。它们适用于人们有许可的安全机构，它们适用于部署数据库的公司雇用数据库管理员的数据库。但是它们对于安全的最终用户软件来说效果不佳，因为用户通常既没有技能也没有将列表保持最新的倾向。
对象功能通过对对象引用进行捎带访问决策来解决这个问题 - 通过使用程序员在精心设计的面向对象系统中已经完成的所有工作来最小化任何单个代码段的权限。有关这在实践中如何运作的示例，请参阅CapDesk。
DARPA开展了一项名为DARPA浏览器项目的安全系统设计实验，该项目发现以这种方式设计的系统 - 尽管它与其他面向对象系统具有相同的错误率 - 具有低得多的可利用漏洞率。由于设计师使用对象功能跟踪POLA，因此攻击者更难找到使用bug来破坏系统的方法。答案 1 :(得分：4)
最小权限原则 - 进程应该只保留它实际需要的权限，并且只应在最短时间内保留这些权限。因此，例如，最好使用sudo make install而不是su来打开shell，然后以超级用户身份工作。
答案 2 :(得分：3)
白名单
选择您所知道的接受
（是的，我知道，它与“默认拒绝”非常相似，但我喜欢用积极的思考。）
答案 3 :(得分：2)
记住物理安全。如果有人可以拿走你的硬盘，这可能是最有效的攻击。</ p>
（我记得一次入侵红色团队演习，其中我们出现了一个剪贴板和一个官方形式的表格，然后走开了整个“安全”系统。）
答案 4 :(得分：2)
隔离。代码应该在例如进程之间具有很强的隔离性，以便一个组件中的故障不会轻易损害其他组件。
答案 5 :(得分：2)
从头开始设计安全性
当您将安全性添加到现有系统时，安全性会更加容易。
答案 6 :(得分：2)
聘请安全专业人员
安全是一项专业技能。不要试图自己做。如果您无法承担保险合同的费用，那么至少聘请专业人员来测试您的实施。
答案 7 :(得分：2)
重用经过验证的代码
使用经过验证的加密算法，加密随机数生成器，哈希函数，身份验证方案，访问控制系统，而不是自己编写。
答案 8 :(得分：2)
加密≠安全。
答案 9 :(得分：2)
限制“攻击面”。通过防火墙，限制访问等方式将您的系统暴露给尽可能少的攻击
答案 10 :(得分：2)
在制定安全设计决策之前对威胁进行建模 - 考虑可能存在的威胁以及它们的可能性。例如，有人使用笔记本电脑而非使用台式机窃取计算机的可能性更大。然后首先担心这些更可能的威胁。
答案 11 :(得分：1)
熟悉加密构建块的基本假设非常重要。例如，诸如RC4的流密码非常有用，但是可以容易地用于构建不安全的系统（即，WEP等）。
答案 12 :(得分：1)
如果为了安全起见加密数据，企业中风险最高的数据就成了您的关键。丢失密钥，数据丢失;妥协密钥，所有数据都受到损害。
答案 13 :(得分：1)
在成本方面表达风险和危险。钱。它非常集中精神。
答案 14 :(得分：0)
分开关注。构建您的系统并设计代码，以便将安全关键组件保持在一起。
答案 15 :(得分：0)
使用风险做出安全决策。一旦确定了不同威胁的概率，就要考虑每种威胁可能造成的伤害。根据定义，风险是
R = P e ×H
其中 P e 是欠效事件的概率， H 是危险，或者可能来自不受欢迎的事件的伤害量。
答案 16 :(得分：0)
KISS（保持简单，愚蠢）
如果您需要制定一个非常复杂且难以理解的关于系统安全的原因，那么它可能并不安全。
正式的安全设计有时指的是一种称为TCB（可信计算基础）的东西。但即使是非正式的设计也有类似的东西 - 代码的安全执行部分，你无法避免依赖的部分。这需要很好地封装，并尽可能简单和小。