在设计和开发生命周期后期才向解决方案添加安全性，通常会导致成本高昂的返工和可用性上的牺牲，从而削弱解决方案的功能和用户体验。从一开始就将解决方案设计为安全的，有助于确保最终解决方案在可用性、互操作性、弹性和安全性之间达到适当的平衡。

设计安全 是一项原则，即项目的设计、开发和交付实践必须包含由经验丰富的熟练团队所提供的安全与合规实践。下文将介绍的安全设计原则，用于指导架构思维实践。

设计过程需要从运用 企业设计思维 开始，聚焦于组织内外部风险、合规和安全利益相关者所需的用户成果。外部利益相关者包括客户、政府和监管机构。内部利益相关者包括负责管理风险、合规和安全的人员。

设计过程继续进行架构思考，定义架构特征、架构决策、功能架构和云部署模型。随后，完成对安全服务的弹性、性能和可扩展性等特征的定义。

在需求和架构定义之后，可以进行安全功能和基础设施的工程实施，包括遵循默认安全原则。

IBM 在产品开发中长期以来一直采用安全与隐私设计方法。已发布的 IBM 红皮书 《开发中的安全性：IBM 安全工程框架》 值得参考。

当系统中的用户或软件拥有过多权限时，就存在意外或故意滥用的风险。 威胁参与者 可能会入侵内部用户的特权账户，并利用这些权限在网络和系统中横向移动。

最小权限 原则规定，系统应仅赋予用户或软件执行其预期任务所需的最低限度功能。系统应从应用程序的最高层到两个软件组件之间的单个连接，都贯彻实施这一原则。

要实施最小权限原则，您必须了解动态 IT 环境中的资产。特权访问不仅仅是人的问题；您需要知道哪些应用程序可以访问哪些数据。发现、分类和风险评估是一个持续的过程。汇集来自数字资产的风险数据，揭示新的业务层面风险洞察，助您制定正确的策略。

用户或软件在会话的初始识别和身份验证时可能处于安全上下文中，但威胁参与者可能会入侵活动会话并利用它进一步危害系统。

持续验证 是一项原则，即必须不断验证用户或软件，以评估其是否仍处于安全上下文中。持续验证的目的是尽早发现安全问题和漏洞，理想情况下赶在 威胁参与者 之前。

持续验证通过二次身份验证请求等方式，确认实体是否与其声称的身份相符。可能需要更新工作负载，支持使用 零信任网络架构 (ZTNA) 解决方案对用户和软件进行持续验证。专注于提供一流用户体验的组织可能不愿意用不必要的请求打扰用户；然而，这种级别的身份保证对于零信任至关重要。

 威胁参与者 可能已经入侵了组织。如果组织仅关注外部边界的威胁，而不排查那些通过合法机制绕过边界控制的威胁，则可能长期无法发现入侵事件。 假设失陷 原则要求组织假定 威胁参与者已成功入侵。

该方法要求威胁管理应增加主动的内部检测、寻找早期预警信号、进行威胁搜寻，并采用经过验证的应急预案。检测和响应必须与洞察和执行层紧密集成，共享上下文，并根据识别到的威胁动态调整访问控制策略。

信息系统在软件、固件和硬件中会存在漏洞。配置和软件会发生变化，新的漏洞也会出现。如果某一层防御存在漏洞，系统需要保持安全。

纵深防御 是一项原则，即系统拥有多层防御，因此当某一层失效时，另一层仍然存在以保护系统中的敏感数据。对安全策略采用分层方法，可确保组织在某一层防御被突破时，能够在后续层阻止攻击者。

企业安全战略和架构必须包括在传统网络计算模型的后续层提供保护的措施。通常，组织需要从最基本的（系统级安全）到最复杂的（传输级安全）规划安全。

组织的攻击面是 威胁参与者 可用于未经授权访问网络或敏感数据，或执行网络攻击的漏洞、途径或方法的总和——有时称为攻击向量。随着组织越来越多地采用云服务和混合（本地/居家办公）办公模式，其网络和相关攻击面也日益扩大和复杂。

最小化攻击面 是一项原则，即系统应减少攻击向量的范围，从而降低 威胁参与者 可能获得访问的途径数量。安全专家将攻击面分为三个子攻击面：数字攻击面、物理攻击面和社会工程攻击面。

1.  数字攻击面 可能将组织的云和本地基础设施暴露给任何能连接互联网的 威胁参与者 。常见的攻击向量包括网络访问、软件漏洞、未使用资源的启用、影子 IT 和过时软件。

2.  物理攻击面 暴露了通常仅供有权访问组织物理办公室或端点设备的用户访问的资产和信息。这包括恶意内部人员的攻击、设备盗窃和“引诱攻击”—— 威胁参与者 将感染恶意软件的 USB 驱动器留在公共场所，希望诱骗用户将设备插入电脑并无意中下载恶意软件。

3.  社会工程攻击面 操纵人们分享不应分享的信息、下载不应下载的软件、访问不应访问的网站、向犯罪分子汇款或犯下其他危及个人或组织资产或安全的错误。

组织应通过检查每个攻击面，评估系统处理的敏感数据所面临的风险。

用户可能能够访问高度敏感的数据（如加密密钥），从而绕过控制，或者有权执行高度特权的操作，如转移大额资金。即使系统监控用户，他们仍可能滥用其权限，导致灾难性的业务后果。

职责分离 是一项原则，即对数据或操作拥有强大访问权限的用户，需要多个用户共同完成该操作。它为组织提供了将管理职能分配给不同个人且职责不重叠的能力，从而确保单一用户不拥有无限权力。

对于管理加密密钥等活动，组织将要求加密密钥管理员管理密钥的不同部分，以便没有单个管理员了解整个密钥。对于业务交易，应用程序可能要求请求交易的人有一个或多个审批人才能完成交易。

对于某些行业，监管机构可能要求对强大功能进行职责分离，作为监管指导的一部分。职责分离有助于企业遵守政府法规，并简化权限管理。

产品或服务包含许多不同的配置点，并且人们希望使其尽可能易于使用。因此，产品可能存在不安全的配置，例如开放网络端口或允许使用易于记忆的密码。

默认安全 是一项原则，即组织收到的产品或服务在开箱时即配置为安全状态。这些产品的设置旨在防范最普遍的威胁和漏洞，而无需最终用户采取额外步骤来保护它们。

系统可能在初始时配置安全，但开发人员后续可能进行更改而修改了配置，或者 威胁参与者 可能通过漏洞进行更改，从而危及系统安全。

持续合规 是一项原则，即从系统开发到持续运行的系统，不断检查系统的安全配置。持续合规的目的是在 威胁参与者 之前发现安全问题和漏洞。

理想情况下，合规检查应全部自动化，并涵盖所有安全配置，包括云平台、容器平台、中间件以及计算映像（如虚拟服务器和容器）。对于计算映像，更好的方法可能是使用基础设施即代码  (IaC)  定期替换整个映像。

在混合云环境中，安全与合规交付的共担责任取决于工作负载或应用程序所使用的服务模型、计算平台和云服务提供商。安全架构师必须记录并传达涵盖安全服务设计、构建和运行的责任。责任不清晰可能导致解决方案的安全性出现漏洞。

每个维度对共担责任都有不同的影响：

• 云服务模型 —— 根据 NIST 对云计算的定义 ，责任范围因云服务模型（如 IaaS、PaaS、SaaS 或分布式云）而异。安全服务是共担责任的一部分。例如， IBM Cloud 的共担责任 包括身份和访问管理、安全与法规遵从。这些类别的共担责任根据云服务模型而有所不同。
   

• 计算平台 ——工作负载可能托管在一个或多个计算平台上，例如裸机服务器、虚拟服务器、容器平台和无服务器计算。每个计算平台都有一组不同的共担责任。例如，Bare Metal Servers 要求工作负载所有者负责平台上除物理硬件和网络集成之外的所有安全控制。
   

• 云服务提供商 ——责任也因云服务提供商而异。例如，每个云服务提供商的 Kubernetes 平台都不同（除非使用 Red Hat OpenShift），因为它们各自包含一组不同的精选开源软件包。

那么，为什么安全架构师要关注服务所有权的差异呢？提供安全运维的团队可能已预定义了支持服务运行的安全服务。这些安全服务可能是云平台的一部分，也可能是需要大量集成的本地部署服务。

例如，内部安全运维团队可能使用与全球系统集成商 (GSI)（如 IBM Consulting）不同的技术。对于内部安全团队而言，托管安全服务的控制平面可能位于本地，而 GSI 可能使用由另一家云服务提供商提供的云安全服务。

对于软件即服务云服务 (SaaS) 模型，云服务消费者只能进行应用程序安全管理。安全性通常作为服务的一部分内置在应用程序中，控制安全配置的范围有限。在这种情况下，SaaS 提供商承担了大部分的安全运维责任。

如果没有记录在案的责任，可能就没有指定的负责人来设计、构建和运行作为工作负载运行依赖项的安全组件。理解安全服务的共担责任，可以使解决方案架构满足运维需求，并避免在项目后期对解决方案进行返工。

混合云架构中的安全服务使用不同的云服务模型、计算平台和云服务提供商。这些服务需要一个商定的控制平面架构，以便对安全与合规进行一致的管理和监督。

对于拥有本地数据中心工作负载的企业，控制平面可能驻留在本地数据中心，以抵御云服务提供商的故障。然而，本地安全服务不一定具备完全管理云平台的能力。因此，需要设计一种控制平面架构，以报告跨不同云服务提供商的安全状态并识别风险。

对于云原生组织而言，控制平面的托管可能位于其他云端、网络接入点 (POP) 或托管数据中心内。即使云服务提供商出现故障，安全控制平面仍需保持可用。

作为安全架构师，记录并商定架构决策以确保整个组织在安全控制平面架构上保持一致非常重要。在项目早期做出此决策，以确保解决方案符合组织的战略。

安全性主要不在于部署安全功能，而在于保护业务数据和流程免受威胁。采用系统化的方法追踪通过系统的数据流，以识别保护传输中、静态和使用中数据的安全控制措施。

架构师必须首先使用 系统上下文图 来识别需要保护的敏感数据，该图确定了系统边界和发起通过系统数据流的外部交互。然后使用描述功能组件（如 组件图）的图表来检查应用程序的内部数据流。

当架构师进入实施阶段时，他们使用 云架构图来检查部署在云基础设施上的组件之间的数据流。IBM 创建了一种 技术图表设计语言 ，可以实现独立于云服务提供商的设计。

为了识别这些数据流面临的威胁，需对工作负载功能组件和工作负载基础设施进行威胁建模。

这些技术和工件共同为安全和合规的架构思考提供了一种可重复且一致的方法。

在处理最敏感的数据时，考虑使用 机密计算 和 同态加密增加另一层保护。

系统需要满足许多不同的控制要求，清单可能会变得冗长且难以管理。与其处理许多单个要求，不如将要求分组到流程、服务或功能中，形成交付功能。例如， 身份生命周期管理 或 未授权组件检测 都是潜在的交付功能。

按照以下步骤更有效地管理合规性：

1. 创建一个单一的合规框架，并可追溯到原始来源。
2. 将合规框架中的要求映射到一组交付功能
3. 确保在设计、构建、测试和运营的所有阶段都具备合规的功能。
4. 在生产中持续遵守要求。

安全架构师必须确保安全功能关联有相应的服务级别目标 (SLO)、责任协议等。

通常需要确保来自一个客户、业务线或环境的数据不会泄露给另一个。需要在工作负载运行和数据存储方面进行隔离。这可能简单到数据库中的不同表，也可能复杂到使用独立的物理服务器。

混合云提供了多种选项来实施数据处理隔离。应在以下方面之间进行隔离：

1. 工作负载或应用程序——例如，会计应用与人力资源应用
2. 环境——例如，开发、测试和生产环境
3. 客户——例如，客户 A 与客户 B
4. 地理位置——例如，英国与美国

在混合云环境中，有许多不同的隔离选项，它们提供不同的功能和保障级别：

1. 企业账户
2. 云账户
3. 资源组
4. 虚拟私有云
5. 执行域——例如，容器或服务器映像
6. 项目
7. 密钥管理域
8. 物理设备

组织政策必须定义何种隔离类型适合处理数据的工作负载。例如，政策可能要求生产客户数据的托管环境不得与非生产环境混用。所需的最低隔离级别是使用不同的云账户，因为身份和访问管理是在账户级别进行的。

与数据隔离相关的另一个主题是数据主权。某些国家对数据的处理和访问地点施加了限制。《通过主权云应对法规与推动创新博文》 深入讨论了数据主权的需求层次结构。

威胁建模通常被认为是一种识别和验证流经系统的数据的安全控制措施的技术。

然而，威胁建模还有第二个目的——为威胁监控系统识别需要监控的威胁。安全架构师必须致力于识别一个按优先级排序的威胁列表。然后为威胁检测功能定义所需的威胁检测用例。使用事件响应应急预案实施和测试检测用例，以便能够有效响应威胁。

确保威胁、威胁检测用例和事件响应应急预案之间有文档化的追溯关系，以保证项目的完整设计和交付。

在过去的本地数据中心时代，安全运维团队完成任务可能需要数天或数小时，且无需严格的服务级别要求。随着基础设施即代码 (IaC) 自动化的普及，集中式安全服务（如密钥或证书管理）的丧失会立即影响应用程序的可用性。因此，安全服务需要定义服务级别，并设计相应的架构来满足可用性要求。

为每个安全功能或服务定义：

1. 服务时间
2. 事件、问题和变更的响应时间
3. 运维人员的技能和经验
4. 与服务要求相匹配的详细测试流程
5. 与服务要求相匹配的自动化

如果内部安全运维团队无法满足云原生工作负载的需求，应考虑是否适合采用 托管安全服务提供商 。

仔细想想，如今许多安全服务所需的弹性和服务级别至少应与它们所支持的工作负载相当。

传统工作方式意味着安全是事后才考虑的事情，导致安全配置和补丁难以完成，因为它没有融入开发生命周期的早期阶段。在开发运维工作方式下，安全构建标准需要：

1. 被纳入开发和测试环境。
2. 从初始开发到全面生产保持一致。
3. 持续测试以确保持续合规。

构建流程必须在开发和运维的所有阶段防止工作负载的不安全部署，确保安全不是事后才考虑的事情。