云架构安全备忘录¶
简介¶
本备忘录将讨论在创建和审查云架构时应遵循的常见且必要的安全模式。每个部分都将涵盖一个特定的安全准则或需要考虑的云设计决策。本备忘录是为中大型企业系统编写的，因此将讨论额外的开销要素，这些要素对于小型组织可能不必要。
风险分析、威胁建模和攻击面评估¶
对于任何应用程序架构，了解风险和威胁对于实现适当的安全性至关重要。没有人能将全部预算或带宽都用于安全性，因此有必要合理分配安全资源。因此，企业必须执行风险评估、威胁建模活动和攻击面评估，以识别以下内容：
- 应用程序可能面临哪些威胁
- 这些威胁实际发生为攻击的可能性
- 这些攻击可能针对的攻击面
- 因所述攻击导致数据或功能丢失的业务影响
所有这些对于正确规划架构的安全性都是必要的。然而，这些主题可以/应该更详细地讨论。作为健康的云架构对话的一部分，请使用下面的资源链接进行进一步研究。
公共和私有组件¶
安全对象存储¶
对象存储通常有以下访问数据选项：
- 使用内置身份和访问管理策略访问资源
- 使用加密签名的 URL 和 HTTP 请求
- 直接访问公共存储
IAM 访问¶
此方法涉及对托管或自管理服务等工具的间接访问，这些服务在临时或持久基础设施上运行。该基础设施包含一个持久的控制平面 IAM 凭证，它代表用户与对象存储进行交互。当应用程序有其他用户界面或数据系统可用时，当尽可能隐藏存储系统很重要时，或当信息不应/不会被最终用户看到（元数据）时，此方法最适用。它可以与 Web 身份验证和日志记录结合使用，以更好地跟踪和控制对资源的访问。此方法的主要安全问题是依赖于可能存在弱点的开发代码或策略。
| 优点 | 缺点 |
|---|---|
| 无法直接访问数据 | 可能使用宽泛的 IAM 策略 |
| 用户对对象存储不可见 | 凭证丢失导致可访问控制平面 API |
| 可识别和可记录的访问 | 凭证可能被硬编码 |
此方法适用于敏感用户数据，但必须遵循严格的编码和云最佳实践，才能正确保护数据。
签名 URL¶
对象存储的 URL 签名涉及使用某种方法静态或动态生成 URL，这些 URL 以加密方式保证实体可以访问存储中的资源。当需要或首选直接访问特定用户文件时，此方法最适用，因为它没有文件传输开销。建议仅将此方法用于不甚敏感的用户数据。此方法可以是安全的，但有明显的缺点。如果签名 URL 的生成方法是自定义的、动态的且可注入的，则仍可能存在代码注入，并且任何人只要获得 URL，就可以匿名访问资源。开发人员还必须考虑签名 URL 何时应该过期，这增加了方法的复杂性。
| 优点 | 缺点 |
|---|---|
| 仅访问一个资源 | 匿名访问 |
| 用户对对象存储的可见性最低 | 任何人都可以通过 URL 访问 |
| 高效的文件传输 | 自定义代码可能存在注入漏洞 |
公共对象存储¶
这不是一种推荐的资源存储和分发方法，应仅用于公共、非敏感、通用资源。这种存储方法将为威胁行为者提供对云环境的额外侦察，并且以这种配置存储的任何数据在任何时间内都必须被视为已公开访问（泄露给公众）。
| 优点 | 缺点 |
|---|---|
| 高效访问多个资源 | 任何人都可以访问/无隐私 |
| 简单的公共文件共享 | 对对象的未经验证访问 |
| 对完整文件系统的可见性 | |
| 意外泄露存储信息 |
VPC 和子网¶
虚拟私有云（VPC）和公共/私有网络子网允许应用程序及其网络被分割成不同的块，在云系统内增加了安全层。与其他私有与公共权衡不同，应用程序在成熟的架构中很可能会包含大部分或所有这些组件。下面将分别解释。
VPC¶
VPC 用于在应用程序内创建网络边界，其中组件可以相互通信，就像数据中心的物理网络一样。VPC 将由数量不等的公共和私有子网组成。VPC 可以用于：
- 在同一云账户内分离整个应用程序。
- 将应用程序的大型组件分离到具有隔离网络的独立 VPC 中。
- 在用于不同客户或数据集的重复应用程序之间创建隔离。
公共子网¶
公共子网容纳将具有互联网面向存在的组件。子网将包含网络路由元素，以允许子网内的组件直接连接到互联网。一些用例包括：
- 面向公众的资源，如前端 Web 应用程序。
- 应用程序的初始接触点，如负载均衡器和路由器。
- 开发人员访问点，如 堡垒机（注意，如果设计/部署不正确，这些可能非常不安全）。
私有子网¶
私有子网容纳不应直接访问互联网的组件。子网可能包含网络路由，将其连接到公共子网，以便以结构化和受保护的方式接收互联网流量。私有子网非常适合：
- 数据库和数据存储。
- 后端服务器和相关文件系统。
- 任何被认为过于敏感而不能直接访问互联网的组件。
简单架构示例¶
考虑下面的简单架构图。一个 VPC 将容纳应用程序的所有组件，但元素将根据其在系统中的角色位于特定的子网中。与此应用程序交互的正常流程可能如下所示：
- 通过某种互联网网关、API 网关或其他面向互联网的组件访问应用程序。
- 此网关连接到公共子网中的负载均衡器或 Web 服务器。这两个组件都提供面向公众的功能，并相应地受到保护。
- 这些组件然后与其在私有 VPC 中包含的相应后端对等体（数据库或后端服务器）进行交互。这种连接受到更多限制，防止对可能“脆弱”的后端系统进行无关访问。
注意：此图为了简化和实现服务提供商无关性，有意省略了子网接口的路由和 IAM 元素。
这种架构防止了安全性较低的后端组件或数据库等高风险服务直接暴露在互联网上。它还为互联网提供了常见的公共功能访问，以避免额外的路由开销。通过将安全性集中在入口点并分离功能，将非公共或敏感信息放置在私有子网中，外部方将更难访问，从而可以更容易地保护此架构。
信任边界¶
信任边界是系统内组件之间的连接，组件必须做出信任决策。换句话说，此边界是两个具有潜在不同信任级别的组件相遇的点。这些边界的范围可以从授予与应用程序交互的用户的信任程度，到信任或验证云架构中代码功能或组件之间的特定声明。然而，一般来说，相信每个组件都能正确且安全地执行其功能就足够了。因此，信任边界很可能出现在云组件之间以及应用程序与第三方元素（如最终用户和其他供应商）之间的连接中。
举例来说，考虑以下架构。一个 API 网关连接到一个计算实例（临时或持久），该实例然后访问一个持久存储资源。另外，存在一个可以验证调用者的身份验证、授权和/或身份的服务器。这是 OAuth、IAM 或目录系统的通用表示，它控制对这些资源的访问。此外，存在一个临时 IAM 服务器，它控制对存储资源的访问（使用上述 IAM 访问部分的方法）。如图中虚线所示，信任边界存在于每个计算组件、API 网关和身份验证/身份服务器之间，即使许多或所有元素可能位于同一应用程序中。
探索不同信任级别¶
架构师必须在组件之间选择信任配置，使用定量因素如风险评分/容忍度、项目速度以及主观安全目标。下面的每个示例都详细说明了信任边界关系，以更好地解释信任特定资源的影响。特定资源的威胁级别将以从绿色（安全）到红色（危险）的颜色表示，以指出不应信任哪些资源。
1. 无信任示例¶
如下图所示，此示例描述了一个模型，其中没有任何组件信任任何其他组件，无论其关键性或威胁级别如何。这种类型的信任配置可能用于风险极高的应用程序，其中包含非常个人或重要的业务数据，或整个应用程序具有极高的业务关键性。
请注意，API 网关和计算组件都调用身份验证/身份服务器。这意味着这些组件之间传输的任何数据，即使它们在应用程序“内部”紧密相邻，也不被视为受信任的。然后，计算实例必须承担一个临时身份才能访问存储，因为即使用户受信任访问实例，计算实例也不受信任访问特定资源。
还要注意身份验证/身份服务器和临时 IAM 服务器与每个组件之间缺乏信任。虽然图中未显示，但这会产生额外影响，例如在身份验证之前进行更严格的检查，并且可能需要为加密操作付出更多开销。
这对于金融、军事或关键基础设施系统中的应用程序可能是必要的方法。然而，安全部门在倡导此模型时必须谨慎，因为它将带来显著的性能和维护缺点。
| 优点 | 缺点 |
|---|---|
| 数据完整性高保障 | 缓慢且低效 |
| 纵深防御 | 复杂 |
| 可能更昂贵 |
2. 高信任示例¶
接下来，考虑一个相反的方法，即一切都被信任。在这种情况下，“危险”的用户输入被信任并实质上直接交给一个高关键性的业务组件。身份验证/身份资源根本不使用。在这种情况下，系统被成功攻击的可能性更高，因为没有设置任何控制来阻止它。此外，这种设置可能被认为是浪费的，因为身份验证/身份服务器和临时 IAM 服务器都不一定执行其预期功能。（这些可能是未充分利用的共享公司资源）。
除了最简单和风险最低的应用程序，这不太可能成为所有应用程序的架构。除非没有敏感内容需要保护或效率是成功的唯一指标，否则不要使用此信任边界配置。即使在低风险应用程序中，也从不建议信任用户输入。
| 优点 | 缺点 |
|---|---|
| 高效 | 不安全 |
| 简单 | 可能浪费 |
| 高风险的泄露 |
3. 部分信任示例¶
大多数应用程序将使用这样的信任边界配置。利用风险和攻击面分析的知识，安全部门可以合理地将信任分配给低风险组件或流程，并仅在必要时进行验证。这可以防止浪费宝贵的安全资源，同时通过额外的安全开销限制复杂性和效率损失。
请注意，在此示例中，API 网关检查用户的身份/身份验证，然后立即将请求传递给计算实例。该实例不需要重新验证，并执行其操作。然而，由于计算实例正在处理不受信任的用户输入（用黄色表示部分信任），因此仍有必要假设一个临时身份来访问存储系统。
从本质上讲，这种方法限制了前两个示例的优缺点。此模型很可能用于大多数应用程序，除非为了满足业务需求而需要上述示例的优点。
| 优点 | 缺点 |
|---|---|
| 基于风险的安全 | 已知的安全漏洞 |
| 根据重要性推导出的成本/效率 |
注意：这种信任方法与零信任有所不同。要更深入地了解该主题，请查看 CISA 的零信任成熟度模型.
安全工具¶
Web 应用程序防火墙¶
Web 应用程序防火墙 (WAF) 用于监控或阻止常见的攻击载荷（如 XSS 和 SQL 注入），或仅允许特定的请求类型和模式。应用程序应将其用作第一道防线，将其附加到负载均衡器或 API 网关等入口点，以在恶意内容到达应用程序代码之前进行处理。云服务提供商会提供基础规则集，用于阻止或监控常见的恶意载荷。
这些规则集是通用设计，不会涵盖应用程序将面临的所有攻击类型。考虑创建适合应用程序特定安全需求的自定义规则，例如：
- 过滤路由到可接受的端点（阻止网络爬取）
- 为选定的技术和关键应用程序端点添加特定保护
- 限制敏感 API 的速率
日志记录与监控¶
日志记录和监控对于真正安全的应用程序是必需的。开发人员应该确切地知道他们的环境中正在发生什么，利用警报机制在系统未按预期工作时警告工程师。此外，在发生安全事件时，日志记录应该足够详细，以便跟踪威胁行为者通过整个应用程序，并提供足够的知识供响应者了解对哪些资源采取了哪些操作。请注意，适当的日志记录和监控可能很昂贵，在实施日志记录时应讨论风险/成本权衡。
日志记录¶
为实现正确的日志记录，请考虑：
- 记录所有 第 7 层 HTTP 调用，包括标头、调用者元数据和响应
- 有效负载可能不会被记录，具体取决于日志记录发生的位置（在 TLS 终止之前）和数据的敏感性
- 记录带有执行者和权限信息的内部操作
- 在整个请求生命周期中发送跟踪 ID，以跟踪错误或恶意行为
- 屏蔽或删除敏感数据
- 社保号、敏感健康信息和其他个人身份信息不应存储在日志中
法律和合规代表应就特定应用程序的日志保留时间发表意见。
监控¶
为了实现适当的监控，请考虑添加：
- 异常警报
- HTTP 4xx 和 5xx 错误高于正常百分比
- 内存、存储或 CPU 使用率高于/低于正常百分比
- 数据库写入/读取高于/低于正常百分比
- 无服务器计算调用高于正常百分比
- 健康检查失败警报
- 部署错误或容器开关循环警报
- 成本限制警报或截止
异常的数量和类型可能因应用程序而异。正确理解什么是异常需要一个特定于环境的基线。因此，上述百分比应基于该基线，并考虑风险和团队响应能力等因素。
WAF 还可以附加监控或警报功能，用于计数恶意负载或（在某些情况下）检测异常活动。
DDoS 防护¶
云服务提供商根据应用程序需求提供从简单到高级的各种 DDoS 防护产品。简单的 DDoS 防护通常可以通过使用带有速率限制和路由阻止规则的 WAF 来实现。更高级的防护可能需要云服务提供商提供的特定托管工具。示例包括：
是否为特定应用程序启用高级 DDoS 防护的决定应基于应用程序的风险和业务关键性，并考虑缓解因素和成本（这些服务与大型公司预算相比可能非常便宜）。
共享责任模型¶
共享责任模型是云服务提供商（CSP）和销售基于云服务的公司用于正确识别和划分开发人员和提供商责任的框架。它分为不同级别的控制，对应于技术堆栈的不同元素/层。通常，物理计算设备和数据中心空间等组件由 CSP 负责。根据 管理级别，开发人员可能负责从操作系统到上层的整个堆栈，或仅负责一些辅助功能、代码或管理。
这种责任模型通常分为三个服务级别，称为：
还有许多其他服务分类，但为求简洁未列出。
顾名思义，CSP 承担的责任级别就是他们提供的“服务”级别。每个级别都有其自身的优缺点，下面将进行讨论。
IaaS¶
在 IaaS 的情况下，基础设施由 CSP 维护，而其他所有内容则由开发人员维护。这包括：
- 身份验证和授权
- 数据存储、访问和管理
- 某些网络任务（端口、NACL 等）
- 应用程序软件
该模型有利于开发人员的可配置性和灵活性，但比其他服务模型更复杂，成本也更高。它也最接近在大型公司中逐渐失去青睐的本地模型。因此，将某些应用程序迁移到云 IaaS 可能比使用更云原生的架构重新设计更容易。
| 优点 | 缺点 |
|---|---|
| 对大多数组件的控制 | 成本最高 |
| 高度灵活性 | 需要更多维护 |
| 从本地轻松过渡 | 高复杂性 |
责任几乎完全由开发人员承担，必须相应地进行安全保障。在制定 IaaS 安全策略时，必须考虑从网络访问控制、操作系统漏洞、应用程序漏洞、数据访问以及身份验证/授权的所有方面。如上所述，这在技术堆栈的几乎所有方面都提供了高度控制，但在没有足够资源用于版本升级或生命周期结束迁移等任务的情况下，可能非常难以维护。（自管理安全更新将在下面更详细地讨论。）
PaaS¶
平台即服务介于 IaaS 和 SaaS 之间。开发人员控制：
- 应用程序身份验证和授权
- 应用程序软件
- 外部数据存储
它提供了整洁的代码托管和容器化选项，允许小型开发团队或经验不足的开发人员开始他们的应用程序，同时忽略更复杂或多余的计算任务。它通常比 IaaS 便宜，同时仍保留 SaaS 系统不提供的一些元素控制。然而，开发人员可能会遇到所用产品的特定限制问题，或兼容性问题，因为代码必须与正确的容器、框架或语言版本一起工作。
此外，虽然可扩展性高度依赖于提供商和设置，但 PaaS 通常由于容器化选项和常见的、可重复的基础操作系统而提供更高的可扩展性。相比之下，IaaS 的可扩展性必须由开发人员构建，而 SaaS 的性能则高度平台特定。
| 优点 | 缺点 |
|---|---|
| 更易于上手和维护 | 潜在的兼容性问题 |
| 更好的可扩展性 | 特定产品限制 |
PaaS 解决方案中的手动安全性也相应地不那么广泛（与 IaaS 相比）。应用程序特定的身份验证和授权仍必须由开发人员处理，以及对外部数据系统的任何访问。然而，CSP 负责保护容器化实例、操作系统、临时文件系统和某些网络控制。
SaaS¶
软件即服务模型是指一个几乎完整的产品，最终用户只需配置或自定义少量细节即可满足其需求。用户通常控制：
- 产品边界内的配置、管理和/或代码
- 一些用户访问，例如指定管理员
- 通过权限或集成与其他产品进行高级连接
整个技术堆栈由提供商（云服务或其他软件公司）控制，开发人员只会进行相对较小的调整以满足自定义需求。这限制了成本和维护，问题通常可以通过提供商的客户支持解决，而无需技术知识来排除整个技术堆栈的故障。
| 优点 | 缺点 |
|---|---|
| 低维护 | 受供应商限制 |
| 价格便宜 | 最小控制 |
| 客户支持/故障排除 | 最小洞察力/监督 |
SaaS 的安全性既最简单也最困难，这归因于上述缺乏控制。开发人员只需管理一小部分安全功能，例如一些访问控制、与集成的信任/共享数据关系以及任何定制的安全影响。所有其他安全层都由提供商控制。这意味着任何安全修复都将超出开发人员的控制范围，因此可能处理不及时，或者未达到最终用户的满意安全水平（取决于安全需求）。然而，此类修复不需要最终用户的参与和资源，从成本和维护负担的角度来看，这使得它们更容易。
注意：在寻找 SaaS 解决方案时，请考虑要求公司提供其证明记录和符合 ISO 27001 等标准的证明。下面列出了每个主要 CSP 的证明网站链接，以供进一步了解。
自管理工具¶
描述这种共享责任模型的另一种更通用的方式是根据“管理”程度对云工具进行分类。完全托管的服务几乎不需要最终开发人员处理，除了某些编码或管理功能（SaaS），而自管理系统则需要更多的开销来维护（IaaS）。
AWS 提供了一个很好的例子来说明这种管理差异，指出了他们的一些不同产品在频谱中的不同位置。
注意：很难精确指出哪些产品属于哪种服务类型（例如：IaaS 与 PaaS）。开发人员应努力理解适用于他们正在使用的特定工具的模型。
自管理服务的更新策略¶
自管理工具将需要开发人员和支持工程师付出额外的开销。根据工具的不同，可能需要进行基本版本更新、对 AMI 或 计算镜像 等镜像的升级，或其他操作系统级别的维护。使用自动化工具定期更新次要版本或 镜像，并在开发周期中安排时间刷新陈旧资源。
避免托管服务安全中的漏洞¶
托管服务将提供一定程度的安全性，例如更新和保护运行应用程序代码的底层硬件。然而，开发团队仍然负责系统中安全性的许多方面。确保开发人员了解根据工具选择，哪些安全责任将由他们承担。以下内容很可能部分或全部由开发人员负责：
- 身份验证和授权
- 日志记录和监控
- 代码安全 (OWASP Top 10)
- 第三方库补丁
请参阅云服务提供商提供的文档，了解根据所选服务，哪些安全方面由各方负责。例如，在无服务器函数的情况下：