你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
安全团队、角色和功能
本文介绍云安全性所需的安全角色及其与云基础结构和平台相关的功能。 这些角色有助于确保安全是云生命周期的每个阶段的一部分，从开发到运营和持续改进。
注意
Azure 云采用框架侧重于支持多个工作负荷的云基础结构和平台。 有关单个工作负荷的安全指南，请参阅 Azure 架构良好的框架中的安全指南 。
根据组织的规模和其他因素，本文中讨论的角色和职能可能由执行多个职能（角色）而不是由单个人员或团队完成。 企业和大型组织往往拥有具有更专业角色的大型团队，而较小的组织往往在少数人中整合多个角色和职能。 具体安全责任也因组织使用的技术平台和服务而异。
某些安全任务将由技术和云团队直接执行。 其他安全团队可能由与技术团队协作运营的专用安全团队执行。 无论组织的规模和结构如何，利益干系人都必须清楚地了解需要完成的安全作业。 每个人都必须了解组织的业务要求和安全风险容忍度，以便他们可以做出有关将安全作为关键要求考虑和平衡的云服务的良好决策。
使用本文中的指南来帮助了解团队和角色执行的特定功能，以及不同团队如何交互，以涵盖整个云安全组织。
安全角色的转换
安全体系结构、工程和运营角色正在对其职责和流程进行重大转换。 （此转换类似于基础结构和平台角色的云驱动转换。此安全角色转换由多种因素驱动：
随着安全工具日益成为基于 SaaS 的安全工具，无需设计、实现、测试和操作安全工具基础结构。 这些角色仍需要支持配置云服务和解决方案（包括持续改进）的完整生命周期，以确保它们满足安全要求。
认识到安全性是每个人的工作，正推动一种更具协作性和成熟性的方法，使安全和技术团队能够协同工作：
技术工程团队负责确保将安全措施有效地应用于其工作负荷。 此更改增加了安全团队对如何有效高效地履行这些义务的上下文和专业知识的需求。
安全团队正从（略有对抗）的质量控制角色转变为一个支持技术团队的角色：使安全路径成为最简单的路径。 安全团队通过使用自动化、文档、培训和其他策略来减少摩擦和障碍。
安全团队越来越多地扩大其技能，以跨多种技术和系统查看安全问题。 例如，它们解决了完整的攻击者生命周期问题，而不是专注于狭窄的技术领域（例如网络安全、终结点安全性、应用程序安全性和云安全性）。 云平台将不同技术紧密集成在一起，这大大放大了这种技能开发需求。
技术和安全云服务的更改率提高要求不断更新安全流程，以保持同步和管理风险。
安全威胁现在可靠地绕过基于网络的安全控制，因此安全团队需要采用零信任方法，包括标识、应用程序安全、终结点安全性、云安全、CI/CD、用户教育和其他控制措施。
采用 DevOps/DevSecOps 流程需要安全角色更加敏捷，以本机方式将安全性集成到生成的加速解决方案开发生命周期中。
角色和团队概述
以下部分提供有关哪些团队和角色通常执行关键云安全功能（当组织中存在这些功能时）的指导。 你应该制定现有方法，寻找差距，并评估你的组织是否可以和应该投资来解决这些差距。
执行安全任务的角色包括以下角色。
云服务提供商
基础结构/平台团队（体系结构、工程和运营）
安全体系结构、工程和状况管理团队：
安全架构师和工程师（数据安全、标识和访问管理（IAM）、网络安全、服务器和容器安全性、应用程序安全性和 DevSecOps）
软件安全工程师（应用程序安全性）
姿势管理（漏洞管理/攻击面管理）
安全操作（SecOps/SOC）：
会审分析师（第 1 层）
调查分析员（第 2 层）
威胁搜寻
威胁情报
检测工程
安全治理、风险和合规性（GRC）
安全培训和意识
必须确保每个人都了解他们在安全性中的作用以及如何与其他团队合作。 可以通过记录跨团队的安全流程和技术团队的共同责任模型来实现此目标。 这样做有助于避免覆盖差距和重叠工作的风险和浪费。 它还有助于避免常见错误（反模式），如团队选择弱身份验证和加密解决方案，甚至尝试创建自己的解决方案。
注意
共同责任模型类似于负责任的、责任、咨询、通知（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），类似于软件工程师通常充当应用程序开发团队的安全 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） 角色。
安全教育和政策
组织必须确保所有角色都有基本的安全素养和指导，这些角色应针对安全性及其操作方法执行哪些操作。 若要实现此目标，需要结合书面政策和教育。 云团队的教育可由直接与他们合作的安全专业人员进行非正式指导，也可以是具有记录课程和指定安全冠军的正式计划。
在更大的组织中，安全团队与组织准备/培训和安全教育和参与角色合作，正式安全培训，并在技术团队中设置安全拥护者，以宣传和教育其同行的安全。
安全教育和策略必须帮助每个角色了解：
为什么。 显示每个角色，为什么安全对他们很重要，以及他们在角色责任上下文中的目标。 如果人们不清楚为什么安全对他们很重要，他们会判断这是不重要的，并前进到别的东西。
什么。 总结他们需要用他们已经理解的语言执行哪些安全任务。 如果人们不知道他们被要求做什么，他们会假设安全性不重要或与其相关，并转到其他内容。
如何。 确保每个角色都有有关如何在其角色中应用安全指南的明确说明。 如果人们不知道如何实际执行他们被要求执行的操作（例如修补服务器、确定链接是网络钓鱼链接、正确报告消息、查看代码或执行威胁模型），他们将失败并转到其他内容。
示例方案：团队之间的典型互操作性
当组织部署和操作 WAF 时，多个安全团队必须进行协作，以确保其有效的部署、管理和集成到现有安全基础结构中。 下面是团队之间的互操作性在企业安全组织中的外观：
- 规划和设计
- 治理团队确定增强的 Web 应用程序安全性需求，并为 WAF 分配预算。
- 网络安全架构师设计 WAF 部署策略，确保它与现有安全控制无缝集成，并与组织的安全体系结构保持一致。
- 实现
- 网络安全工程师根据架构师的设计部署 WAF，将其配置为保护特定的 Web 应用程序，并启用监视。
- IAM 工程师设置访问控制，确保只有经过授权的人员才能管理 WAF。
- 监视和管理
- 状态管理团队提供有关 SOC 配置 WAF 监视和警报以及设置仪表板以跟踪 WAF 活动的说明。
- 威胁情报和检测工程团队有助于制定涉及 WAF 的事件的响应计划，并执行模拟来测试这些计划。
- 合规性和风险管理
- 合规性和风险管理官员会审查 WAF 部署，以确保其满足法规要求并定期进行审核。
- 数据安全工程师确保 WAF 的日志记录和数据保护措施符合数据隐私法规。
- 持续改进和培训
- DevSecOps 工程师将 WAF 管理集成到 CI/CD 管道中，确保更新和配置自动化且一致。
- 安全教育和参与专家制定和交付培训计划，以确保所有相关人员了解如何有效使用和管理 WAF。
- 云治理团队成员评审 WAF 部署和管理流程，以确保它们符合组织策略和标准。
通过有效地协作，这些角色可确保 WAF 正确部署，并持续监视、管理和改进，以保护组织的 Web 应用程序免受不断演变的威胁。