C4：从一开始就考虑安全

描述

在设计新应用程序时，创建安全的架构可防止漏洞在成为应用程序一部分之前就出现。这可以避免昂贵的修复和声誉问题。

有一些设计原则可以导向安全的架构

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

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

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

“复杂性是安全的敌人”这一座右铭贯穿于本实现指南中。

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

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

这意味着系统管理员必须做出明确的选择才能在系统中引入不安全的配置。相反，最省力的路径应始终导致一个安全的系统。

当专注于最终用户交互时，这个方面对于设计用户界面和流程很重要。当专注于开发人员交互时，开发人员面对的设施，如框架、API、网络API，都应该被设计成在使用默认值时，只发生安全操作。在设计您的配置文件时也应考虑这一点。

明确阐明哪些被信任可以做什么，并确保这些关系得到执行，例如，信任边界划分了影响范围，并通过防火墙或网关等控制措施强制执行。

通过每一步的仔细验证来削弱允许的内容。通过威胁建模助记符（如STRIDE）或方法论（如按元素划分的STRIDE）进行更深入的分析。

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

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

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

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

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

实施