C4：从一开始就考虑安全

描述

在设计新应用程序时，创建安全的架构可以在漏洞成为应用程序的一部分之前就进行预防。这可以避免高昂的修复成本和否认问题。

有一些设计原则可以带来安全的架构

越简单越好 (KISS)：应用程序越容易理解，就越容易推断其组件及其交互。这有助于推断应用程序的安全行为。
让正确的事情变得简单：不要指望用户阅读文档或花费时间“以正确的方式做事”。默认情况下，应用程序应该以安全的方式运行。要使其不安全，用户必须采取明确的行动。
不要依赖模糊性：如果唯一的安全性是由于应用程序或其源代码的不透明性，那么应用程序根本不安全。
识别并最小化暴露的组件（“攻击面”）：攻击者无法攻击不存在的东西。
设计深度防御：考虑如果某个组件被攻破会发生什么，以及攻击可能造成的潜在影响范围。

虽然可能手动实现所有要求，但强烈建议将架构建立在成熟且维护良好的第三方组件之上。这有诸多好处

如果应用程序仅通过模糊性安全进行保护，则一旦混淆被清除，逆向工程应用程序的攻击者将拥有完全权限。此外，攻击者能够监控网络流量：虽然混淆可能在代码层面执行，但网络层面的操作可以轻易被分析。
部署了一个具有复杂授权方案的Web应用程序。一名新的软件开发人员负责扩展其中一个组件。由于复杂性，他们错误地配置了授权方案，攻击者能够利用IDOR。
部署了一个具有复杂授权方案的Web应用程序。一名新的软件开发人员向系统添加了一个新插件。该系统使得正确操作变得困难，所有安全配置都必须手动添加到插件中，默认情况下未采取任何安全措施。新开发人员未进行任何配置，因此新插件给系统引入了IDOR。
一个Web应用程序有许多组件，所有这些组件都暴露在公共互联网上。由此产生的攻击面巨大。例如，部署了一个数据库管理工具（例如，phpmyadmin）。在mysqladmin中发现一个零日漏洞后，整个数据库被提取。在正常使用中，没有人使用phpmyadmin。

“复杂性是安全的敌人”这一理念贯穿于本实施指南中。

架构应注重简洁性：所设计的软件应仅与预期用户需求所要求的复杂程度相符。注重简洁性为所创建的软件带来多重好处

经常听到的两个术语是“设计安全”（security by design）和“默认安全”（security by default）。前者意味着软件系统应以安全的方式可用，而后者意味着软件系统的初始配置是安全的。

这意味着系统管理员必须明确选择将不安全配置引入系统。相反，阻力最小的路径应始终导致一个安全的系统。

在关注最终用户交互时，这一方面对于设计用户界面和流程很重要。在关注开发人员交互时，面向开发人员的设施，如框架、API、网络API，应设计为在使用默认值时只执行安全操作。在设计配置文件时也要考虑到这一点

清楚地阐明什么被信任做什么，并确保这些关系得到强制执行，例如，信任边界划定爆炸半径，并通过防火墙或网关等控制措施强制执行。

通过每一步的仔细验证来削弱允许的行为。使用像 STRIDE 这样的威胁建模助记符或像每个元素 STRIDE 这样的方法进行更深入的分析。

识别攻击者可以访问的所有区域，审查它们并尽量最小化：攻击者无法攻击不存在的东西。

此外，只暴露最少的操作集可使长期维护更容易。

专家们以易于理解的“安全架构模式”形式分享了关于最佳实践的智慧。架构模式是可重用的，可应用于多个应用程序。

一个解决方案要被视为模式，必须具备以下特点

架构模式是使用标准解决方案解决问题而非创建自定义解决方案的一种方式。安全架构模式是经过审查并针对已知安全威胁进行强化的标准解决方案。

实施