Cloud Architecture Security Cheat Sheet / 云架构安全速查表

Introduction / 介绍

This cheat sheet will discuss common and necessary security patterns to follow when creating and reviewing cloud architectures. Each section will cover a specific security guideline or cloud design decision to consider. This sheet is written for a medium to large scale enterprise system, so additional overhead elements will be discussed, which may be unnecessary for smaller organizations.

本速查表将讨论在创建和审查云架构时需要遵循的常见和必要的安全模式。每个部分将涵盖一个特定的安全指南或需要考虑的云设计决策。本表是为中型或大型企业系统编写的，因此将讨论一些额外的开销元素，这些元素对于较小的组织可能是不必要的。

Risk Analysis, Threat Modeling, and Attack Surface Assessments / 风险评估、威胁建模和攻击面评估

See the Secure Product Design Cheat Sheet for application design guidance.

有关应用设计指南，请参阅安全产品设计速查表。

With any application architecture, understanding the risks and threats is extremely important for proper security. No one can spend their entire budget or bandwidth focused on security, so properly allocating security resources is necessary. Therefore, enterprises must perform risk assessments, threat modeling activities, and attack surface assessments to identify the following:

在任何应用架构中，了解风险和威胁对于确保安全至关重要。没有人能够将整个预算或带宽都集中在安全上，因此合理分配安全资源是必要的。因此，企业必须进行风险评估、威胁建模活动和攻击面评估，以确定以下内容：

• What threats an application might face
  中文：应用可能面临哪些威胁
• The likelihood of those threats actualizing as attacks
  中文：这些威胁实际化为攻击的可能性
• The attack surface with which those attacks could be targeted
  中文：这些攻击可能针对的攻击面
• The business impact of losing data or functionality due to said attack
  中文：因该攻击导致数据或功能丢失的业务影响

This is all necessary to properly scope the security of an architecture. However, these are subjects that can/should be discussed in greater detail. Use the resources link below to investigate further as part of a healthy secure architecture conversation.

这些都是为了正确界定架构安全所必需的。然而，这些都是可以/应该进行更详细讨论的主题。请使用下面的资源链接进一步调查，作为健康安全架构对话的一部分。

• Threat Modeling Cheat Sheet) （威胁建模速查表）
• Attack Surface Analysis Cheat Sheet) （攻击面分析备忘单）
• CISA Cyber Risk Assessment) （CISA网络风险评估）

Public and Private Components / 公共和私有组件

Secure Object Storage / 安全对象存储

Object storage usually has the following options for accessing data:

对象存储通常有以下几种访问数据的方式：

• Accessing resources using built-in Identity and Access Management policies
  中文：使用内置的身份和访问管理策略访问资源
• Using cryptographically signed URLs and HTTP requests
  中文：使用具有加密签名的 URL 和 HTTP 请求
• Directly accessing with public storage
  中文：直接访问公共存储

IAM Access / IAM 访问

This method involves indirect access on tooling such as a managed or self-managed service running on ephemeral or persistent infrastructure. Authenticate the service with a workload identity or federated role that obtains short-lived credentials, instead of embedding a persistent access key. For example, AWS recommends temporary credentials from IAM roles or federation for application access. Limit the service's permissions to the required storage operations and resources. The method is best used when the application has other user interfaces or data systems available, when it is important to hide as much of the storage system as possible, or when the information shouldn't/won't be seen by an end user (metadata). It can be used in combination with web authentication and logging to better track and control access to resources. The key security concern for this approach is relying on developed code or policies which could contain weaknesses.

此方法涉及对工具的间接访问，例如在临时或持久基础设施上运行的托管或自托管服务。使用工作负载身份或联合角色对服务进行身份验证，该角色获取短期凭证，而不是嵌入持久访问密钥。例如，AWS 建议使用 IAM 角色或联合的临时凭证进行应用程序访问。限制服务的权限仅限于所需的存储操作和资源。当应用程序具有其他用户界面或数据系统可用时，当需要尽可能隐藏存储系统的大部分内容时，或者当信息不应/不会被最终用户（元数据）看到时，此方法最佳。它可以与网络身份验证和日志记录结合使用，以更好地跟踪和控制对资源的访问。此方法的主要安全问题是依赖于可能包含弱点的开发代码或策略。

Pros / 优点	Cons / 缺点
No direct access to data 无直接数据访问	Potential use of broad IAM policy 可能使用广泛的IAM策略
No user visibility to object storage 用户无法查看对象存储	Stolen credentials expose permitted resources 被盗凭证暴露允许的资源
Identifiable and loggable access 可识别和可记录的访问	Credentials could be hardcoded 凭证可能被硬编码

This approach is acceptable for sensitive user data, but must follow rigorous coding and cloud best practices, in order to properly secure data.

此方法适用于敏感用户数据，但必须遵循严格的编码和云最佳实践，以正确保护数据。

Signed URLs / 签名 URL

URL Signing for object storage involves using some method or either statically or dynamically generating URLs, which cryptographically guarantee that an entity can access a resource in storage. This is best used when direct access to specific user files is necessary or preferred, as there is no file transfer overhead. It is advisable to only use this method for user data which is not very sensitive. This method can be secure, but has notable cons. Code injection may still be possible if the method of signed URL generation is custom, dynamic and injectable, and anyone can access the resource anonymously, if given the URL. Developers must also consider if and when the signed URL should expire, adding to the complexity of the approach.

对象存储的 URL 签名涉及使用某种方法或静态或动态生成 URL，这些 URL 通过密码学保证实体可以访问存储中的资源。当需要或首选直接访问特定用户文件时，此方法最佳，因为没有文件传输开销。建议仅为此类不太敏感的用户数据使用此方法。此方法可以是安全的，但有一些显著的缺点。如果签名 URL 生成方法是自定义的、动态的和可注入的，则仍然可能发生代码注入，并且如果给出 URL，任何人都可以匿名访问资源。开发人员还必须考虑签名 URL 应何时以及如何过期，这增加了方法的复杂性。

Pros / 优点	Cons / 缺点
Access to only one resource 仅访问一个资源	Anonymous Access 匿名访问
Minimal user visibility to object storage 最小化用户对对象存储的可见性	Anyone can access with URL 任何人都可以通过URL访问
Efficient file transfer 高效的文件传输	Possibility of injection with custom code 存在使用自定义代码注入的可能性

Public Object Storage / 公共对象存储

This is not an advisable method for resource storage and distribution, and should only be used for public, non-sensitive, generic resources. This storage approach will provide threat actors additional reconnaissance into a cloud environment, and any data which is stored in this configuration for any period of time must be considered publicly accessed (leaked to the public).

这不是一种推荐的资源存储和分发方法，仅应用于公共、非敏感、通用资源。这种存储方法将为攻击者提供额外的云环境侦察机会，并且在此配置中存储任何时间的数据都必须被视为公开访问（泄露给公众）。

Pros / 优点	Cons / 缺点
Efficient access to many resources 高效访问大量资源	Anyone can access/No privacy 任何人都可以访问/无隐私
Simple public file share 简单的公共文件共享	Unauthenticated access to objects 未经身份验证的对象访问
	Visibility into full file system 对整个文件系统的可见性
	Accidentally leak stored info 意外泄露存储信息

VPCs and Subnets / VPC和子网

Virtual Private Clouds (VPC) and public/private network subnets allow an application and its network to be segmented into distinct chunks, adding layers of security within a cloud system. Unlike other private vs public trade-offs, an application will likely incorporate most or all of these components in a mature architecture. Each is explained below.

虚拟专用云（VPC）和公共/私有网络子网允许将应用程序及其网络分割成不同的部分，在云系统中增加安全层。与其他私有与公共权衡不同，成熟架构中的应用程序可能会整合这些组件中的大多数或全部。以下将逐一解释。

VPCs / VPC

VPC's are used to create network boundaries within an application, where-in components can talk to each other, much like a physical network in a data center. The VPC will be made up of some number of subnets, both public and private. VPCs can be used to:

VPC用于在应用程序内创建网络边界，其中组件可以相互通信，就像数据中心中的物理网络一样。VPC将由一些子网组成，包括公共和私有。VPC可用于：

• Separate entire applications within the same cloud account.
  中文：在同一云账户内将整个应用程序分开。
• Separate large components of application into distinct VPCs with isolated networks.
  中文：将应用程序的大组件分离到不同的VPC中，并使用隔离的网络。
• Create separations between duplicate applications used for different customers or data sets.
  中文：在不同客户或数据集使用的重复应用程序之间创建分隔。

Public Subnets / 公共子网

Public subnets house components which will have an internet facing presence. The subnet will contain network routing elements to allow components within the subnet to connect directly to the internet. Some use cases include:

公共子网包含将具有互联网访问组件。该子网将包含网络路由元素，以允许子网内的组件直接连接到互联网。以下是一些用例：

• Public facing resources, like front-end web applications.
  中文：面向公众的资源，如前端Web应用程序。
• Initial touch points for applications, like load balancers and routers.
  中文：应用程序的初始接触点，如负载均衡器和路由器。
• Developer access points, like bastions (note, these can be very insecure if engineered/deployed incorrectly).
  中文：开发者访问点，例如 堡垒机（注意，如果设计/部署不当，这些可能非常不安全）

Private Subnets / 私有子网

Private subnets house components which should not have direct internet access. The subnet will likely contain network routing to connect it to public subnets, to receive internet traffic in a structured and protected way. Private subnets are great for:

私有子网用于存放不应直接访问互联网的组件。该子网可能包含网络路由，以将其连接到公共子网，以结构化和受保护的方式接收互联网流量。私有子网非常适合于：

• Databases and data stores.
  中文：数据库和数据存储。
• Backend servers and associated file systems.
  中文：后端服务器及其关联的文件系统。
• Anything deemed too sensitive for direct internet access.
  中文：任何被认为对直接互联网访问过于敏感的内容。

Simple Architecture Example / 简单架构示例

Consider the simple architecture diagram below. A VPC will house all of the components for the application, but elements will be in a specific subnet depending on its role within the system. The normal flow for interacting with this application might look like:

考虑以下简单的架构图。VPC 将包含应用程序的所有组件，但元素将根据其在系统中的角色位于特定的子网中。与应用程序交互的正常流程可能如下所示：

1. Accessing the application through some sort of internet gateway, API gateway or other internet facing component.
   中文：通过某种形式的互联网网关、API 网关或其他面向互联网的组件访问应用程序。
2. This gateway connects to a load balancer or a web server in a public subnet. Both components provide public facing functions and are secured accordingly.
   中文：此网关连接到公共子网中的负载均衡器或网页服务器。这两个组件都提供面向公众的功能，并相应地得到保护。
3. These components then interact with their appropriate backend counterparts, a database or backend server, contained in a private VPC. This connections are more limited, preventing extraneous access to the possibly "soft" backend systems.

Note: This diagram intentionally skips routing and IAM elements for subnet interfacing, for simplicity and to be service provider agnostic.

This architecture prevents less hardened backend components or higher risk services like databases from being exposed to the internet directly. It also provides common, public functionality access to the internet to avoid additional routing overhead. This architecture can be secured more easily by focusing on security at the entry points and separating functionality, putting non-public or sensitive information inside a private subnet where it will be harder to access by external parties.

Trust Boundaries

Trust boundaries are connections between components within a system where a trust decision has to be made by the components. Another way to phrase it, this boundary is a point where two components with potentially different trust levels meet. These boundaries can range in scale, from the degrees of trust given to users interacting with an application, to trusting or verifying specific claims between code functions or components within a cloud architecture. Do not grant access merely because a component is internal or owned by the same organization. NIST SP 800-207 requires explicit authentication and authorization for protected resources rather than trust based solely on network location or ownership. Identify these checks between cloud components as well as at connections to end users and other vendors.

As an example, consider the architecture below. An API gateway connects to a compute instance (ephemeral or persistent), which then accesses a persistent storage resource. Separately, there exists a server which can verify the authentication, authorization and/or identity of the caller. This is a generic representation of an OAuth, IAM or directory system, which controls access to these resources. Additionally, there exists an Ephemeral IAM server which controls access for the stored resources (using an approach like the IAM Access section above). As shown by the dotted lines, trust boundaries exist between each compute component, the API gateway and the auth/identity server, even though many or all of the elements could be in the same application.

Exploring Different Levels of Trust

Architects have to select a trust configuration between components, using quantitative factors like risk score/tolerance, velocity of project, as well as subjective security goals. Each example below details trust boundary relationships to better explain the implications of trusting a certain resource. The threat level of a specific resource as a color from green (safe) to red (dangerous) will outline which resources shouldn't be trusted.

1. No trust example

As shown in the diagram below, this example outlines a model where no component trusts any other component, regardless of criticality or threat level. This type of trust configuration would likely be used for incredibly high risk applications, where either very personal data or important business data is contained, or where the application as a whole has an extremely high business criticality.

Notice that both the API gateway and compute components call out to the auth/identity server. This implies that no data passing between these components, even when right next to each other "inside" the application, is considered trusted. The compute instance must then assume an ephemeral identity to access the storage, as the compute instance isn't trusted to a specific resource even if the user is trusted to the instance.

Also note the lack of trust between the auth/identity server and ephemeral IAM server and each component. While not displayed in the diagram, this would have additional impacts, like more rigorous checks before authentication, and possibly more overhead dedicated to cryptographic operations.

This could be a necessary approach for applications found in financial, military or critical infrastructure systems. However, security must be careful when advocating for this model, as it will have significant performance and maintenance drawbacks.

Pros / 优点	Cons / 缺点
High assurance of data integrity 数据完整性的高保证	Slow and inefficient 缓慢且低效
Defense in depth 深度防御	Complicated 复杂
	Likely more expensive 可能更昂贵

2. High trust example

Next, consider the opposite approach, where everything is trusted. In this instance, the "dangerous" user input is trusted and essentially handed directly to a high criticality business component. The auth/identity resource is not used at all. In this instance, there is higher likelihood of a successful attack against the system, because there are no controls in place to prevent it. Additionally, this setup could be considered wasteful, as both the auth/identity and ephemeral IAM servers are not necessarily performing their intended function. (These could be shared corporate resources that aren't being used to their full potential).

This is an unlikely architecture for all but the simplest and lowest risk applications. Do not use this trust boundary configuration unless there is no sensitive content to protect or efficiency is the only metric for success. Trusting user input is never recommended, even in low risk applications.

这是一种除最简单和风险最低的应用外不太可能使用的架构。除非没有敏感内容需要保护或效率是成功的唯一指标，否则不要使用这种信任边界配置。即使在低风险应用中，也不建议信任用户输入。

Pros / 优点	Cons / 缺点
Efficient 高效	Insecure 不安全
Simple 简单	Potentially Wasteful 可能造成浪费
	High risk of compromise 高安全风险

3. Some trust example / 3. 一些信任示例

Use risk analysis to place and configure access controls, rather than to omit verification of internal requests. A gateway can perform shared authentication checks, while services enforce authorization that requires resource or business context. See gateway and service-level authorization.

使用风险评估来放置和配置访问控制，而不是省略内部请求的验证。网关可以执行共享身份验证检查，而服务则执行需要资源或业务上下文的授权。参见网关和服务级别授权。

In this example, the compute instance must authenticate the calling gateway, validate propagated user context, and enforce permissions for the requested operation. Prevent direct access that bypasses gateway checks. The instance uses its own least-privileged identity to access storage; an authenticated user does not automatically authorize every storage operation.

在这个示例中，计算实例必须验证调用网关，验证传播的用户上下文，并执行请求操作所需的权限。防止绕过网关检查的直接访问。实例使用其自己的最低权限身份来访问存储；已认证的用户不会自动授权每个存储操作。

By nature, this approach limits the pros and cons of both previous examples. This model will likely be used for most applications, unless the benefits of the above examples are necessary to meet business requirements.

本质上，这种方法限制了前两个示例的优缺点。除非上述示例的好处是满足业务需求的必要条件，否则此模型可能会被用于大多数应用。

Pros / 优点	Cons / 缺点
Secured based on risk 基于风险进行安全保护	Known gaps in security 已知的安全漏洞
Cost/Efficiency derived from criticality 成本/效率取决于关键性

Note: This trust methodology diverges from Zero Trust. For a more in depth look at that topic, check out CISA's Zero Trust Maturity Model.

注意：此信任方法与零信任不同。要深入了解该主题，请参阅CISA的零信任成熟度模型.

Security Tooling / 安全工具

Web Application Firewall / Web 应用防火墙

Web Application Firewalls (WAF) are used to monitor or block common attack payloads (like XSS and SQLi), or allow only specific request types and patterns. Applications should use them as a first line of defense, attaching them to entry points like load balancers or API gateways, to handle potentially malicious content before it reaches application code. Cloud service providers curate base rule sets which will block or monitor common malicious payloads:

Web 应用防火墙（WAF）用于监控或阻止常见的攻击载荷（如 XSS 和 SQLi），或者仅允许特定的请求类型和模式。应用程序应将其作为第一道防线，将其附加到入口点，如负载均衡器或 API 网关，以在恶意内容到达应用程序代码之前进行处理。云服务提供商整理了基础规则集，这些规则集将阻止或监控常见的恶意载荷：

• AWS Managed Rules) （AWS 管理规则）
• GCP WAF Rules) （GCP WAF 规则）
• Azure Core Rule Sets) （Azure 核心规则集）

By design these rule sets are generic and will not cover every attack type an application will face. Consider creating custom rules which will fit the application's specific security needs, like:

按照设计，这些规则集是通用的，不会涵盖应用程序可能面临的每种攻击类型。考虑创建自定义规则，以满足应用程序特定的安全需求，如：

• Filtering routes to acceptable endpoints (block web scraping)
  中文：过滤路由到可接受端点（阻止网络爬虫）
• Adding specific protections for chosen technologies and key application endpoints
  中文：为选定的技术和关键应用端点添加特定保护
• Rate limiting sensitive APIs
  中文：限制敏感API的访问频率

Logging & Monitoring / 日志记录与监控

Logging and monitoring is required for a truly secure application. Developers should know exactly what is going on in their environment, making use of alerting mechanisms to warn engineers when systems are not working as expected. Additionally, in the event of a security incident, logging should be verbose enough to track a threat actor through an entire application, and provide enough knowledge for respondents to understand what actions were taken against what resources. Note that proper logging and monitoring can be expensive, and risk/cost trade-offs should be discussed when putting logging in place.

日志记录与监控对于真正安全的应用至关重要。开发者应该确切了解其环境中的情况，利用警报机制在系统未按预期工作时代码工程师发出警告。此外，在发生安全事件时，日志应该足够详细，以便追踪威胁行为者整个应用程序的活动，并为响应者提供足够的信息来理解针对哪些资源采取了哪些行动。请注意，适当的日志记录和监控可能成本高昂，因此在实施日志记录时应讨论风险/成本权衡。

Logging / 日志记录

For proper logging, consider:

为了进行适当的日志记录，请考虑以下方面：

• Logging HTTP request outcomes using an allow-listed event schema, such as method, route template, status, correlation ID, and a non-secret actor identifier
  中文：使用允许的事件模式（如方法、路由模板、状态、关联ID和公开的参与者标识符）记录HTTP请求结果
  • Exclude credentials, session cookies, access tokens, and sensitive request or response content before collection. HTTP authentication fields contain credentials; do not capture all headers or bodies by default. Follow the Logging Cheat Sheet data exclusions.
    中文：在收集之前排除凭证、会话cookie、访问令牌以及敏感的请求或响应内容。HTTP认证字段包含凭证；默认情况下不要捕获所有头或体。遵循日志记录作弊表数据排除项。
• Logging internal actions with actor and permission information
  中文：记录内部操作，包括参与者信息和权限信息
• Sending trace IDs through the entire request lifecycle to track errors or malicious actions
  中文：在整个请求生命周期中发送跟踪ID以跟踪错误或恶意行为
• Masking or removing sensitive data
  中文：对敏感数据进行掩码或移除
  • SSNs, sensitive health information, and other PII should not be stored in logs
    中文：社会安全号码、敏感健康信息以及其他个人身份信息（PII）不应存储在日志中

Legal and compliance representatives should weigh in on log retention times for the specific application.

法律和合规代表应就特定应用程序的日志保留时间提出意见。

Monitoring / 监控

For proper monitoring consider adding:

为了进行适当的监控，请考虑添加：

• Anomaly alerts:
  中文：异常警报：
  • HTTP 4xx and 5xx errors above a percent of normal
    中文：HTTP 4xx 和 5xx 错误超过正常百分比
  • Memory, storage or CPU usage above/below percent of normal
    中文：内存、存储或CPU使用率高于/低于正常百分比
  • Database writes/reads above/below percent of normal
    中文：数据库写入/读取高于/低于正常百分比
  • Serverless compute invocations above percent of normal
    中文：无服务器计算调用超过正常百分比
• Alerting for failed health checks
  中文：健康检查失败警报
• Alerting for deployment errors or container on/off cycling
  中文：部署错误或容器开关循环警报
• Alerts or cutoffs for cost limits
  中文：成本限制警报或截止值

Anomalies by count and type can vary wildly from app to app. A proper understanding of what qualifies as an anomaly requires an environment specific baseline. Therefore, the percentages mentioned above should be chosen based off that baseline, in addition to considerations like risk and team response capacity.

异常情况的数量和类型可能因应用程序而异。了解何为异常需要特定环境的基线。因此，上述百分比应根据该基线选择，同时考虑风险和团队响应能力。

WAFs can also have monitoring or alerting attached to them for counting malicious payloads or (in some cases) anomalous activity detection.

WAFs也可以附加监控或警报，用于计数恶意有效载荷或（在某些情况下）异常活动检测。

DDoS Protection / DDoS防护

Cloud service providers offer a range of DDoS protection products, from simple to advanced, depending on application needs. Simple DDoS protection can often be implemented using WAFs with rate limits and route blocking rules. More advanced protection may require specific managed tools offered by the cloud service provider. Examples include:

云服务提供商提供一系列DDoS防护产品，从简单到高级，取决于应用需求。简单的DDoS防护通常可以通过使用带有速率限制和路由阻塞规则的WAF来实现。更高级的防护可能需要云服务提供商提供的特定托管工具。例如包括：

• AWS Shield
• GCP Cloud Armor Managed Protection) （GCP Cloud Armor托管保护）
• Azure DDoS Protection) （Azure DDoS防护）

The decision to enable advanced DDoS protections for a specific application should be based off risk and business criticality of application, taking into account mitigating factors and cost (these services can be very inexpensive compared to large company budgets).

为特定应用程序启用高级DDoS防护的决定应基于应用程序的风险和业务关键性，考虑缓解因素和成本（与大型公司预算相比，这些服务可能非常便宜）。

Shared Responsibility Model / 共享责任模型

The Shared Responsibility Model is a framework for cloud service providers (CSPs) and those selling cloud based services to properly identify and segment the responsibilities of the developer and the provider. This is broken down into different levels of control, corresponding to different elements/layers of the technology stack. Generally, components like physical computing devices and data center space are the responsibility of the CSP. Depending on the level of management, the developer could be responsible for the entire stack from operating system on up, or only for some ancillary functionality, code or administration.

共享责任模型是云服务提供商（CSP）和销售基于云服务的企业正确识别和划分开发者和提供商责任的一个框架。这被细分为不同级别的控制，对应于技术堆栈的不同元素/层。通常，物理计算设备和数据中心空间是CSP的责任。根据管理级别，开发者可能负责整个堆栈，从操作系统开始，或者只负责一些辅助功能、代码或管理。

This responsibility model is often categorized into three levels of service called:

这种责任模型通常分为三个服务级别，称为：

• Infrastructure as a Service (IaaS)
  中文：基础设施即服务(IaaS)
• Platform as a Service (PaaS)
  中文：平台即服务(PaaS)
• Software as a Service (SaaS)
  中文：软件即服务(SaaS)

Many other service classifications exist, but aren't listed for simplicity and brevity.

许多其他服务分类存在，但出于简洁性并未列出。

As each name indicates, the level of responsibility the CSP assumes is the level of "service" they provide. Each level provides its own set of pros and cons, discussed below.

正如每个名称所指示的，云服务提供商（CSP）承担的责任级别就是他们提供的服务级别。每个级别都有其自身的优缺点，以下将进行讨论。

IaaS

In the case of IaaS, the infrastructure is maintained by the CSP, while everything else is maintained by the developer. This includes:

在IaaS的情况下，基础设施由CSP维护，而其他一切则由开发者维护。这包括：

• Authentication and authorization
  中文：身份验证和授权
• Data storage, access and management
  中文：数据存储、访问和管理
• Certain networking tasks (ports, NACLs, etc)
  中文：某些网络任务（端口、NACL等）
• Application software
  中文：应用程序软件

This model favors developer configurability and flexibility, while being more complex and generally higher cost than other service models. It also most closely resembles on premise models which are waning in favor with large companies. Because of this, it may be easier to migrate certain applications to cloud IaaS, than to re-architect with a more cloud native architecture.

此模型有利于开发者的可配置性和灵活性，但相较于其他服务模型，它更为复杂且通常成本更高。它也与逐渐失去大型公司青睐的本地化模型最为相似。因此，将某些应用程序迁移到云IaaS可能比重新架构为更原生云架构要容易一些。

Pros / 优点	Cons / 缺点
Control over most components 对大多数组件的控制	Highest cost 最高成本
High level of flexilibity 高度灵活性	More required maintenance 需要更多维护
Easy transition from on-prem 从本地化部署到云端的过渡简单	High level of complexity 高度复杂性

Responsibility is held almost exclusively by the developer, and must be secured as such. Everything, from network access control, operating system vulnerabilities, application vulnerabilities, data access, and authentication/authorization must be considered when developing an IaaS security strategy. Like described above, this offers a high level of control across almost everything in the technology stack, but can be very difficult to maintain without adequate resources going to tasks like version upgrades or end of life migrations. (Self-managed security updates are discussed in greater detail below.)

PaaS

Platform as a Service is in the middle between IaaS and SaaS. The developer controls:

• Application authentication and authorization
• Application software
  中文：应用程序软件
• External data storage

It provides neatly packaged code hosting and containerized options, which allow smaller development teams or less experienced developers a way to get started with their applications while ignoring more complex or superfluous computing tasks. It is generally less expensive than IaaS, while still retaining some control over elements that a SaaS system does not provide. However, developers could have problems with the specific limitations of the offering used, or issues with compatibility, as the code must work with the correct container, framework or language version.

Also, while scalability is very dependent on provider and setup, PaaS usually provides higher scalability due to containerization options and common, repeatable base OS systems. Compared to IaaS, where scalability must be built by the developer, and SaaS, where the performance is very platform specific.

Pros / 优点	Cons / 缺点
Easier to onboard and maintain 更容易上线和维护	Potential compatibility issues 潜在的兼容性问题
Better scalability 更好的可扩展性	Offering specific limitations 提供特定的限制

Manual security in PaaS solutions is similarly less extensive (compared to IaaS). Application specific authentication and authorization must still be handled by the developer, along with any access to external data systems. However, the CSP is responsible for securing containerized instances, operating systems, ephemeral files systems, and certain networking controls.

PaaS解决方案中的手动安全性与IaaS相比要少得多。应用程序特定的身份验证和授权必须由开发者处理，以及对外部数据系统的任何访问。然而，CSP负责保护容器化实例、操作系统、临时文件系统以及某些网络控制。

SaaS

The Software as a Service model is identified by a nearly complete product, where the end user only has to configure or customize small details in order to meet their needs. The user generally controls:

软件即服务（SaaS）模式的特点是产品几乎完整，最终用户只需配置或自定义少量细节以满足需求。用户通常控制：

• Configuration, administration and/or code within the product's boundaries
  中文：在产品边界内的配置、管理及/或代码
• Some user access, such as designating administrators
  中文：一些用户访问，如指定管理员
• High level connections to other products, through permissions or integrations
  中文：与其他产品的连接，通过权限或集成实现高级连接

The entire technology stack is controlled by the provider (cloud service or other software company), and the developer will only make relatively small tweaks to meet custom needs. This limits cost and maintenance, and problems can typically be solved with a provider's customer support, as opposed to needing technical knowledge to troubleshoot the whole tech stack.

整个技术栈由提供商（云服务或其他软件公司）控制，开发者只需进行相对较小的调整以满足定制需求。这限制了成本和维护，问题通常可以通过提供商的客户支持来解决，而不是需要技术知识来排查整个技术栈的问题。

Pros / 优点	Cons / 缺点
Low maintenance 低维护成本	Restricted by provider constraints 受供应商限制
Inexpensive 价格低廉	Minimal control 控制最小化
Customer support/troubleshooting 客户支持/故障排除	Minimal insight/oversight 最小化洞察/监管

Security with SaaS is simultaneously the easiest and most difficult, due to the lack of control expressed above. A developer will only have to manage a small set of security functions, like some access controls, the data trust/sharing relationship with integrations, and any security implications of customizations. All other layers of security are controlled by the provider. This means that any security fixes will be out of the developer's hands, and therefore could be handled in a untimely manner, or not to a satisfactory level of security for an end user (depending on security needs). However, such fixes won't require end user involvement and resources, making them easier from the perspective of cost and maintenance burden.

Note: When looking for SaaS solutions, consider asking for a company's attestation records and proof of compliance to standards like ISO 27001. Listed below are links to each of the major CSPs' attestation sites for additional understanding.

• GCP
• AWS
• Azure

Self-managed tooling

Another way to describe this shared responsibility model more generically is by categorizing cloud tooling on a spectrum of "management". Fully managed services leave very little for the end developer to handle besides some coding or administrative functionality (SaaS), while self-managed systems require much more overhead to maintain (IaaS).

AWS provides an excellent example of this difference in management, identifying where some of their different products fall onto different points in the spectrum.

Note: It is hard to indicate exactly which offerings are considered what type of service (Ex: IaaS vs PaaS). Developers should look to understand the model which applies to the specific tool they are using.

Update Strategy for Self-managed Services / 自托管服务的更新策略

Self-managed tooling will require additional overhead by developers and support engineers. Depending on the tool, basic version updates, upgrades to images like AMIs or Compute Images, or other operating system level maintenance will be required. Use automation to regularly update minor versions or images, and schedule time in development cycles for refreshing stale resources.

自托管工具将需要开发人员和支持工程师额外的开销。根据工具的不同，可能需要执行基本版本更新、升级如AMIs或计算镜像，或其他操作系统级别的维护。使用自动化工具定期更新小版本或镜像，并在开发周期中安排时间刷新过时的资源。

Avoid Gaps in Managed Service Security / 避免托管服务安全漏洞

Managed services will offer some level of security, like updating and securing the underlying hardware which runs application code. However, the development team are still responsible for many aspects of security in the system. Ensure developers understand what security will be their responsibility based on tool selection. Likely the following will be partially or wholly the responsibility of the developer:

托管服务将提供一定级别的安全性，例如更新和保障运行应用代码的底层硬件。然而，开发团队仍然负责系统中的许多安全方面。确保开发人员了解根据工具选择他们将承担哪些安全责任。以下内容可能部分或全部由开发人员负责：

• Authentication and authorization
  中文：身份验证和授权
• Logging and monitoring
  中文：日志记录和监控
• Code security (OWASP Top 10)
  中文：代码安全 (OWASP Top 10)
• Third-party library patching
  中文：第三方库补丁

Refer to the documentation provided by the cloud service provider to understand which aspects of security are the responsibility of each party, based on the selected service. For example, in the case of serverless functions:

参考云服务提供商提供的文档，了解根据所选服务，哪方面的安全责任由哪一方承担。例如，在无服务器函数的情况下：

• AWS Lambda
• GCP Cloud Functions) （GCP云函数）
• Azure Functions) （Azure函数）

References / 参考

• CISA: Cloud Security Technical Reference Architecture) （CISA：云安全技术参考架构）
• CISA: Zero Trust Maturity Model Version 2.0) （CISA：零信任成熟度模型版本2.0）