你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文介绍云基础结构和平台所需的安全角色和功能。 使用这些角色将安全性集成到云生命周期的每个阶段，从开发到运营和持续改进。
组织规模决定了如何配置这些岗位。 大型企业通常为每个角色都有专门的团队。 较小的组织通常会将多个功能合并为更少的角色。 技术平台和服务还影响特定的安全责任。
技术和云团队直接执行一些安全任务。 专用安全团队与技术团队协作执行其他任务。 无论组织结构如何，利益干系人都必须了解必要的安全工作。 所有团队都必须了解业务要求和风险容忍度，才能做出有关云服务的明智决策。 使用本指南了解特定团队和角色的功能以及它们如何交互以提供全面的云安全覆盖。
安全角色的转换
随着组织采用云平台和现代开发实践，安全体系结构、工程和运营角色正在经历重大转变。 此转换会影响安全工作的执行方式、团队协作方式以及职责如何分布在技术功能之间。 几个因素正在推动此更改：
转移到基于 SaaS 和云原生的安全工具。 SaaS 平台的采用改变了安全团队从实施到治理的焦点。 安全团队提供策略、标准和配置基线。 它们不会直接配置 SaaS 服务。 拥有 SaaS 应用程序的团队将本指南应用于其特定工具。 这种分离可确保在允许应用程序团队管理其服务的作设置的同时满足安全要求。
安全性是跨工程团队的共同责任。 现在，所有技术团队都直接负责将安全控制应用于他们构建或运营的工作负载和服务。 安全团队提供模式、指导、自动化和防护措施，使安全实现成为默认的，并减少交付过程中的摩擦。
更广泛的跨技术技能要求。 安全团队越来越需要了解各种技术，以及攻击者如何跨系统移动。 由于云平台集成了标识、网络、计算、应用程序和作层，因此安全专业人员必须评估端到端攻击路径，而不是专注于狭窄的技术领域。
云平台和安全功能的持续更改。 云服务发展迅速，新功能经常出现。 安全流程必须持续适应，保持有效，需要体系结构、工程和运营角色的更大敏捷性。
增加了对零信任原则的依赖。 新式攻击者经常绕过网络外围控制，使标识、设备运行状况、应用程序上下文和遥测成为安全决策的核心。 跨工程、运营和安全的角色必须将零信任思维纳入设计、配置和监视活动。
将安全性集成到 DevOps 和平台工程实践中。 加速发布周期要求安全活动在生命周期的早期阶段进行迁移，并通过自动化进行操作。 安全角色越来越多地与工程和平台团队协作，将安全检查、策略实施和验证嵌入 CI/CD 工作流和作流程。
这些更改重塑了现有角色协同工作的方式，而不是创建新角色。 目标是确保安全性成为云服务设计、构建、部署和运营方式的集成、持续部分。
角色和团队概述
以下部分介绍通常执行关键云安全功能的团队和角色。 使用这些说明将当前组织结构映射到标准云安全功能。 确定覆盖范围方面的差距，并确定投资资源的位置。 确保所有利益干系人都了解其安全职责以及如何与其他团队协作。 记录跨团队的安全流程和技术团队的共同责任模型。 共享责任模型的运作方式与责任人、问责人、被咨询者、被通知者（RACI）矩阵一致。 它定义了特定结果的决策授权和协作要求。 本文档可防止覆盖差距和重叠工作。 它还会阻止常见的反模式，例如选择弱身份验证或加密解决方案。 如果你是一个较小的组织，并希望开始使用最小可行安全团队，请参阅 适用于小型组织的最低可行安全团队。 关键安全角色包括：
云服务提供商
云服务提供商实际上是虚拟团队成员，可为基础云平台提供安全功能和功能。 某些云提供商还提供安全特性和功能，你的团队可以使用这些功能来管理安全状况和事件。 有关云服务提供商执行哪些操作的详细信息，请参阅 云共同责任模型。
许多云服务提供商根据请求或通过门户（如 Microsoft服务信任门户）提供有关其安全做法和控制的信息。
基础结构/平台团队（体系结构、工程和运营）
基础结构/平台体系结构、工程和运营团队跨云基础结构和平台环境（跨服务器、容器、网络、标识和其他技术组件）实现和集成云安全、隐私和合规性控制。
工程和运营角色可以主要关注云或持续集成和持续部署（CI/CD）系统，也可以跨各种云、CI/CD、本地和其他基础结构和平台工作。
这些团队负责满足组织托管业务工作负荷的组织云服务的所有可用性、可伸缩性、安全性、隐私和其他要求。 他们与安全、风险、合规性和隐私专家协作，推动混合和平衡所有这些要求的结果。
安全体系结构、工程和态势管理团队
安全团队与基础结构和平台角色（和其他角色）合作，帮助将安全策略、策略和标准转化为可操作的体系结构、解决方案和设计模式。 这些团队专注于实现云团队的安全成功。 它们评估并影响基础结构的安全性以及用于管理它的流程和工具。 下面是安全团队为基础结构执行的一些常见任务：
安全架构师和工程师 调整了云环境的安全策略、标准和准则，以与其基础结构/平台对应人员合作设计和实施控制措施。 安全架构师和工程师负责处理广泛的事项，包括：
租户/订阅。安全架构师和工程师与基础结构架构师和工程师协作，并访问架构师（标识、网络、应用和其他人员），以帮助跨云提供商（由安全状况管理团队监视）建立云租户、订阅和帐户的安全配置。
标识和访问管理（IAM）。访问架构师 （标识、网络、应用和其他人员）与 标识工程师、运营和 基础结构/平台团队协作，设计、实施和作访问管理解决方案。 这些解决方案可防止未经授权的使用组织的业务资产，同时使授权用户能够遵循业务流程，轻松安全地访问组织资源。 这些团队处理标识目录和单一登录（SSO）解决方案、无密码和多重身份验证（MFA）、基于风险的条件访问解决方案、工作负载标识、特权标识/访问管理（PIM/PAM）、云基础结构和权利管理（CIEM）等解决方案。 这些团队还与网络工程师和运营部门协作，设计、实施和运营安全服务边缘（SSE）解决方案。 工作负荷团队可以利用这些功能来无缝、更安全地访问单个工作负荷和应用程序组件。
数据安全性。安全架构师和工程师与数据和 AI 架构师和工程师协作，帮助基础结构/平台团队为所有数据和高级功能建立基础数据安全功能，这些功能可用于对单个工作负荷中的数据进行分类和保护。 有关基础数据安全性的详细信息，请参阅Microsoft安全 数据保护基准。 有关保护单个工作负荷中的数据的详细信息，请参阅精心构建的框架 指南。
网络安全。安全架构师和工程师与网络架构师和工程师协作，帮助基础结构/平台团队建立与云（专用/租用线路）、远程访问策略和解决方案、入口和出口防火墙、Web 应用程序防火墙（WAF）和网络分段等基础网络安全功能。 这些团队还与标识架构师、工程师和运营人员协作，设计、实施和操作 SSE 解决方案。 工作负荷团队可以利用这些功能来提供单独的工作负荷和应用程序组件的离散保护或隔离。
服务器和容器安全性。安全架构师和工程师与基础结构架构师和工程师协作，帮助基础结构/平台团队为服务器、虚拟机（VM）、容器、业务流程/管理、CI/CD 和相关系统建立基础安全功能。 这些团队建立了发现和清单流程、安全基线/基准配置、维护和修补过程、可执行二进制文件、模板映像、管理流程等允许列表。 工作负荷团队还可以利用这些基础基础结构功能，为单个工作负荷和应用程序组件提供服务器和容器的安全性。
软件安全基础（适用于应用程序安全性和 DevSecOps）。安全架构师和工程师与软件安全工程师协作，帮助基础结构/平台团队建立应用程序安全功能，这些安全功能可由单个工作负荷、代码扫描、材料清单（SBOM）工具、WAF 和应用程序扫描使用。 有关如何建立安全开发生命周期（SDL）的详细信息，请参阅 DevSecOps 控件 。 有关工作负荷团队如何使用这些功能的详细信息，请参阅 精心构建的框架中的安全开发生命周期 指南。
软件安全工程师 评估用于管理基础结构的代码、脚本和其他自动化逻辑，包括基础结构即代码（IaC）、CI/CD 工作流以及任何其他自定义构建的工具或应用程序。 这些工程师应参与保护已编译的应用程序、脚本、自动化平台配置中的正式代码。 他们查看任何其他形式的可执行代码或脚本，这些代码或脚本可能会允许攻击者操纵系统的操作。 此评估可能只需对系统执行威胁模型分析，或者它可能涉及代码评审和安全扫描工具。 有关如何建立 SDL 的详细信息，请参阅 SDL 实践指南。
态势管理（漏洞管理/攻击面管理）是专注于为技术运营团队提供安全保障的运营安全团队。 状况管理可帮助这些团队确定优先级并实施控制，以阻止或缓解攻击技术。 状况管理团队在所有技术运营团队（包括云团队）中工作，通常充当了解安全要求、合规性要求和治理流程的主要手段。
态势管理通常作为安全基础设施团队的卓越中心（CoE）运作，这类似于软件工程师在应用程序开发团队中担任安全卓越中心的角色。 这些团队的典型任务包括以下内容。
监视安全状况。 使用姿势管理工具监视所有技术系统，包括 Microsoft 安全暴露管理、Microsoft Entra 权限管理、非 Microsoft 漏洞管理和外部攻击面管理 (EASM) 工具、CIEM 工具，以及自定义安全态势工具和仪表板。 此外，状况管理会执行分析以提供见解，方法是：
预测极有可能的破坏性攻击路径。 攻击者通过跨不同系统将多个资产和漏洞链接在一起，“以图形方式思考”，并寻找业务关键型系统的路径。 例如，破坏用户终结点，然后使用哈希/票证捕获管理员凭据并访问业务关键型数据。 状况管理团队与安全架构师和工程师合作，发现和缓解这些隐藏的风险，这些风险并不总是显示在技术列表和报表中。
执行安全评估 来评审系统配置和操作过程，以便从安全状况工具获取技术数据之外的更深入地了解和见解。 这些评估可以采用非正式发现对话或正式威胁建模练习的形式。
协助确定优先级。 帮助技术团队主动监视其资产并确定安全工作的优先级。 状况管理通过考虑安全风险影响（基于经验、安全运营事件报告、其他威胁情报、商业情报和其他来源）以及安全合规性要求，帮助将风险缓解工作置于合理的上下文中。
培训、指导和支持。 通过培训、指导个人和非正式知识转移，提高技术工程团队的安全知识和技能。 状况管理角色还可以与组织就绪度/培训和安全教育和参与角色合作，开展正式的安全培训，并在技术团队中设置安全系统和机制，以便技术团队对同事进行安全宣传和教育。
确定漏洞并倡导修复。 确定总体趋势、流程差距、工具差距和其他风险和缓解见解。 状况管理角色与安全架构师和工程师沟通协作，开发解决方案，为资金申请构建案例，并协助推出修复程序。
与安全运维（SecOps）协调。 帮助技术团队与 SecOps 角色合作，如检测工程团队和威胁搜寻团队。 跨所有操作角色的这种连续性有助于确保检测已到位并正确实施，安全数据可用于事件调查和威胁搜寻、处理协作等。
提供报表。 向高级管理和利益干系人提供有关安全事件、趋势和性能指标的及时准确报告，以更新组织风险流程。
状况管理团队通常从现有软件漏洞管理角色演变，以解决开放组零信任参考模型中描述的整套功能、配置和操作漏洞类型。 每种类型的漏洞都允许未经授权的用户（包括攻击者）控制软件或系统，使他们能够对业务资产造成损害。
软件设计或实现中存在功能漏洞 。 它们可以允许对受影响的软件进行未经授权的控制。 这些漏洞可能是你自己的团队开发的软件中的缺陷，或者是商业或开源软件中的缺陷（通常由常见漏洞和曝光标识符跟踪）。
配置漏洞 是系统配置不当，允许未经授权的访问系统功能。 这些漏洞可以在正在进行的操作期间引入，也称为配置偏移。 还可以在软件和系统的初始部署和配置期间引入它们，或者由供应商提供的弱安全默认值引入。 一些常见示例包括：
允许未经授权访问 DNS 记录和组成员身份等项的孤立对象。
对资源授予过多的管理角色或权限。
使用具有已知安全问题的较弱身份验证协议或加密算法。
弱的默认配置或默认密码。
操作漏洞 是标准操作流程和允许未经授权访问或控制系统的实践中的弱点。 示例包括：
安全操作 (SecOps/SOC)
SecOps 团队有时称为安全运营中心（SOC）。 SecOps 团队专注于快速查找和删除攻击者对组织资产的访问权限。 他们与技术运营和工程团队密切合作。 SecOps 角色可以跨组织中的所有技术工作，包括传统的 IT、运营技术（OT）和物联网（IoT）。 以下是最常与云团队交互的 SecOps 角色：
会审分析师（第 1 层）。 响应已知攻击技术的事件检测，并遵循记录的程序快速解决它们（或根据需要将其升级为调查分析员）。 根据 SecOps 范围和成熟度级别，这可能包括来自电子邮件、终结点反恶意软件解决方案、云服务、网络检测或其他技术系统的检测和警报。
调查分析员（第 2 层）。 响应需要更多经验和专业知识（超出记录良好的解决程序）的更高复杂性和更高严重性事件调查。 此团队通常调查由真人对手实施的攻击和影响多个系统的攻击。 它与技术运营和工程团队密切合作，调查事件并解决问题。
威胁搜寻。 主动搜索技术领域中通过标准检测机制未被发现的隐藏威胁。 此角色使用高级分析和假设驱动的调查。
威胁情报 收集和传播有关攻击者和威胁的所有利益干系人的信息，包括业务、技术和安全。 威胁情报团队执行研究，分享他们的发现（正式或非正式），并将其传播给各种利益干系人，包括云安全团队。 此安全上下文可帮助这些团队提高云服务对攻击的复原能力，因为它们在设计、实现、测试和操作中使用实际攻击信息，并不断改进。
检测工程。 创建自定义攻击检测，并对供应商和更广泛的社区提供的攻击检测进行自定义调整。 这些自定义攻击检测补充供应商提供的常见攻击检测，这些攻击通常存在于扩展检测和响应（XDR）工具和某些安全信息和事件管理（SIEM）工具中。 检测工程师与云安全团队合作，确定设计和实施检测的机会、支持检测所需的数据以及检测的响应/恢复过程。
安全治理、风险和合规性
安全治理、风险和合规性（GRC）是一组相关的规则，可将安全团队的技术工作与组织目标和期望相集成。 这些角色和团队可以是两个或更多学科的混合，也可以是离散角色。 云团队在云技术生命周期过程中与其中每个学科进行交互：
治理规则是一项基础能力。 治理团队专注于确保组织一致地实现安全的各个方面。 他们建立了决策权限（谁做出哪些决策）和流程框架来连接和指导团队。 如果没有有效的治理，即便组织拥有所有正确的控制、策略和技术，仍可能成为攻击者的受害者，因为这些攻击者会利用那些计划中的防御措施未能良好、充分或完全实施的漏洞。
风险管理规则侧重于评估、理解和缓解组织风险。 风险管理团队在整个组织中工作，以明确表示当前风险并使其保持最新状态。 云和风险团队必须进行协作，以评估和管理云基础结构和平台上托管的关键业务服务的风险。 供应链安全解决了外部供应商、开源组件和合作伙伴的风险。
合规性规则可确保系统和流程符合法规要求和内部策略。 如果没有此规则，组织可能会面临与不符合外部义务相关的风险（罚款、责任、无法在某些市场运营的收入损失等）。 合规性要求通常无法跟上攻击者演变的速度，但它们仍然是一个重要的要求来源。
这三个学科在所有技术和系统中运行，以推动所有团队的组织成果。 这三者也依赖于互相获取的上下文背景信息，并能从当前关于威胁、业务和技术环境的高保真数据中受益显著。 这些学科还依赖于架构来表达一个可行的愿景，该愿景可以实施，并依赖于安全教育和政策来制定规则，指导团队完成许多日常决策。
云工程和运营团队可以处理 状况管理 角色、 合规性和审核 团队、 安全体系结构和工程，或 GRC 主题上的首席信息安全官（CISO） 角色。
安全教育、意识和政策
组织必须确保所有角色都具有在日常工作中有效应用安全性的知识、指导和信心。 教育和意识通常是组织安全状况中最薄弱的环节，因此它们必须持续、具有角色意识，并嵌入到正常作中，而不是被视为一次性培训事件。
一项强有力的计划包括结构化教育、非正式指导和技术团队中的指定安全冠军。 培训应涵盖网络钓鱼意识、标识卫生、安全配置做法，以及工程角色的安全开发思维模式。 这些努力强化了安全优先的文化，其中个人清楚地了解为什么安全很重要、预期哪些作以及如何正确执行这些作。
安全教育和策略必须帮助每个角色了解：
- 为什么。 为什么安全性在职责和目标方面很重要。 如果没有这种理解，个人会降低安全性的优先级，并专注于其他任务。
- 什么。 适用于他们的具体安全任务和期望，使用与他们角色一致的语言进行描述。 没有明确性，人们假设安全性与他们无关。
- 如何使用。 如何正确执行所需的安全任务，例如修补系统、安全地查看代码、完成威胁模型或识别网络钓鱼尝试。 没有实际指导，即使愿意，人们也会失败。
小型组织的最低可行安全团队
小型组织通常缺乏资源来将个人专用于特定的安全功能。 在这些环境中，以最少的角色涵盖基本职责。 将云平台工程和安全责任合并为一个功能，用于管理安全配置、标识卫生、监视和基本事件响应。 将需要专业知识或持续覆盖范围的任务（例如威胁检测优化、渗透测试或合规性评审）外包给托管的安全提供商。 使用云原生工具（如姿势管理、标识保护、配置基线和自动策略强制实施）来保持一致的安全级别，而无需大型团队并降低运营开销。
示例方案：团队之间的典型互操作性
当组织部署并作 Web 应用程序防火墙时，多个安全团队必须进行协作，以确保其有效的部署、管理和集成到现有安全基础结构中。 以下是团队之间的互操作性在企业安全组织中的表现：
-
规划和设计
- 治理团队确定增强的 Web 应用程序安全性需求，并为 WAF 分配预算。
- 网络安全架构师设计 WAF 部署策略，确保它与现有安全控制无缝集成，并与组织的安全体系结构保持一致。
-
实现
- 网络安全工程师根据架构师的设计部署 WAF，将其配置为保护特定的 Web 应用程序，并启用监视。
- IAM 工程师设置访问控制，确保只有经过授权的人员才能管理 WAF。
-
监视和管理
- 姿势管理团队为 SOC 提供说明，以配置 WAF 的监视和警报，并设置仪表板以跟踪 WAF 活动。
- 威胁情报和检测工程团队有助于制定涉及 WAF 的事件的响应计划，并执行模拟来测试这些计划。
-
合规性和风险管理
- 合规性和风险管理官员会审查 WAF 部署，以确保其满足法规要求并定期进行审核。
- 数据安全工程师确保 WAF 的日志记录和数据保护措施符合数据隐私法规。
-
持续改进和培训
- DevSecOps 工程师将 WAF 管理集成到 CI/CD 管道中，确保更新和配置自动化且一致。
- 安全教育和参与专家制定和交付培训计划，以确保所有相关人员了解如何有效使用和管理 WAF。
- 云治理团队成员评审 WAF 部署和管理流程，以确保它们符合组织策略和标准。
这些角色可确保正确部署 Web 应用程序防火墙，并持续监视、托管和改进，以保护组织的 Web 应用程序免受不断演变的威胁。