这是从软件开发人员和项目经理的角度编写的，他们经常需要处理我参与创建的应用程序中的敏感数据。

纵深防御不一定与简单原则相悖。 简单是困难的，它不是你想的那样。简单并不一定意味着缺乏努力。

它可以（在这种情况下，我认为这通常意味着）在存在既定实践/工具时不使用复杂的本土机制。

这也可能意味着让您的系统保持简单以减少攻击面，或者通过不存储人们想要窃取的数据类型来降低它们的吸引力。

在简单性与功能性之间找到正确的平衡是一门真正的艺术和科学，但根据我的经验，当涉及到简单性时，某些方面的简单性是纵深防御的关键之一。

我将在这里尝试了解的本质是，您花费在保护应用程序上的时间应该与其中包含的数据的敏感性以及攻击面区域的大小成正比。

这里有两种简单的方法可以通过减去一些东西来增加深度防御。

1. 仔细决定是否应该首先存储敏感数据
   • 关于保护敏感数据的最明显的事实之一是，如果您没有敏感数据，则不需要保护它。
   • 在开发系统/软件时，为了提高系统的相对安全性，您可以做的最基本的事情就是首先限制敏感数据。
   • 通过决定不存储不必要的敏感数据，您可以使其变得更简单，但通过将防御视为初始需求收集阶段的一部分来进行深度防御
2. 减少攻击面
   • 与上面类似，但这次是看特性。每一个用户输入控件——文本框、下拉列表等，都是一个潜在的“窗口”，如果不受保护，可能成为攻击者的入口点。如果您未能验证输入或未能清理输出，则该控件可能容易受到许多众所周知的攻击。作为一名开发人员，我可以告诉你，在创建大型、复杂的网站/表单时，很容易在此处错过验证控件或在此处错误地验证某些内容。
   • 企业可能想要一个具有各种花里胡哨的精美界面，但是应该权衡拥有该界面/功能的好处与保护它的成本以及增加的攻击面区域的不利因素。

此外，保持简单的安全性并不一定意味着将您的防御限制为更少的防御。保持简单的安全性只是意味着不要让它变得比必要的更难。保持安全性简单且仍具有纵深防御的方法包括：

• 具有安全的默认值。建立你的正常防御。你可以有五十层防御，但如果你知道你的底线是什么，你仍然可以通过遵循正常的程序来保持简单。
• 使用已建立的最佳实践。与上述类似，对于几乎每种类型的 IT 活动，已经有一套既定的最佳实践。简单地遵循这些而不是想出你自己的疯狂计划会让事情变得简单。
• 使用成熟的、值得信赖的工具。当然，没有任何工具是万无一失的，但如果您要添加防御层，使用已建立的工具而不是自己提出或使用鲜为人知、不受支持的工具，从长远来看可以让事情变得更简单。您将拥有更好的文档、更广泛的用户社区来获得支持，并且更有可能在出现问题时迅速对其进行修补。

纵深防御是关于安全层的。保持每一层尽可能简单是将保持简单原则应用于纵深防御策略的关键。

“纵深防御”通常是出于一种偏执的感觉。您实施层层防御，以应对高层管理人员的恐慌咆哮。

通常提倡“低复杂性”以降低成本和交付时间。您可以降低复杂性，以满足高层管理人员规定的最后期限。

很多时候，“上层管理”会同时坚持这两个方面。然后，您的工作就是通知他们诸如物理定律之类的令人讨厌和讨厌的细节如何阻止或减慢两个目标的同时实现。

归根结底，这不是技术决定。这是关于经济学的。风险分析应该为入侵定价，从而评估深度防御通过遏制成功攻击造成的损害，从长远来看可以节省多少资金。同样，增加的开发成本和延迟将由他们自己的财务估算。由决策者来平衡这些成本，因为它最适合他们的战略；重要的是这是一个政策问题，而不是技术问题。

深度防御和简单防御并不矛盾，只要每一层都简单独立。每一层都不应该依赖于其他层，否则它确实不是很好的纵深防御。（因为那时它实际上只是一个复杂的层。）如果每一层都可以单独使用，并以简单、可验证和可维护的方式实现，那么真的没有什么矛盾的。