尧图网站建设 
零信任微隔离落地实践基于 Anthropic-Cybersecurity-Skills 的微隔离实施计划模板与策略设计指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills在零信任架构NIST SP 800-207中微隔离Microsegmentation是把网络划分为细粒度安全区域、在应用层而非传统 VLAN 层面实施工作负载间最小权限访问的关键能力其直接价值在于即便攻击者获得初始访问权限也无法在同一网段内横向移动。本文以本仓库 skills/configuring-microsegmentation-for-zero-trust 技能下的 微隔离实施计划模板 为主体结合该技能的 工作流参考、标准框架参考、API 参考 以及两个可执行的 Python 脚本agent.py、process.py完整讲解从项目立项、工作负载盘点、区域设计、策略编排到分阶段强制的实施全过程。读完本文你将掌握一套可直接复制、可交付给安全架构评审与合规审计的微隔离实施计划骨架以及与之配套的自动化审计与策略验证方法。一、模板定位把零信任微隔离工程化本仓库将微隔离能力封装为一个结构化技能其 frontmatter 声明了适用的框架映射NIST CSF 2.0 控制项PR.AA-01、PR.AA-05、PR.IR-01、GV.PO-01MITRE ATTCK 技术T1021远程服务、T1210利用远程服务、T1570横向工具传输、T1046网络服务发现、T1018远程系统发现。而 template.md 是这份技能中把方法论落成交付物的载体——一份实施计划模板Implementation Plan Template。它与技能主体 SKILL.md 的四阶段工作流发现与映射 → 策略设计 → 强制执行 → 运维维护一一对应将流程拆解为 8 张可直接填写的表格Project Information项目信息Workload Inventory工作负载盘点Segmentation Zone Design区域设计含 Zone Definitions 与 Inter-Zone Communication MatrixPolicy Rules策略规则含 Allow Rules 与 Default DenyEnforcement Schedule强制执行时间表Validation Tests验证测试清单Sign-Off干系人签字使用方式将该模板作为实施项目的主控文档配合 workflows.md 中的流程图理解每一步的输入输出配合 standards.md 引用合规依据配合 api-reference.md 中的 API 实现自动化。二、项目信息与工作负载盘点一切从清单开始2.1 Project Information模板开篇要求登记项目元数据这是后续所有决策的溯源基础FieldValueProject NameOrganizationProject LeadStart DateSegmentation Tool[Illumio / VMware NSX / Guardicore / Cisco ACI]其中Segmentation Tool的选型直接决定强制点Enforcement Point的实现方式。根据 SKILL.md 的架构模型可选路径包括网络型VMware NSX、Cisco ACI在虚拟化层或网络矩阵层强制分布式防火墙规则无需改动物理拓扑详见 standards.md 对 NSX Distributed Firewall 的描述有状态 L4-7 防火墙内嵌于 Hypervisor 内核策略在 vNIC 层面即被评估。主机型Illumio、Guardicore通过 Agent 在 OS 层强制Linux 用 iptablesWindows 用 WFPIllumio 的 VENVirtual Enforcement Node采集遥测PCEPolicy Compute Engine集中策略与可视化。容器型Calico、Cilium在 Kubernetes 的 Pod/容器级执行网络策略。应用型Zscaler Workload Segmentation基于软件身份而非 IP 的分段。2.2 Workload InventoryWorkloadIP AddressOSRoleApplicationEnvironmentLocationwebprodappproddbprod这张表是发现阶段的核心输出。模板预设了典型三层架构web/app/db每个字段都与后续标签体系Label直接对应Role、Application、Environment、Location 正是现代微隔离基于标签Label-Based Policy策略模型的四个维度。标签化策略相比 IP 规则的最大优势在于跨环境可移植、迁移时不受 IP 变化影响——这也是 SKILL.md 中强调的设计原则。从仓库脚本看盘点结果还可以通过 process.py 中的identify_segmentation_zones()自动验证该函数依据workload_labels按 IP 映射到 application 标签统计每个区域的内外流量并计算隔离率isolation_ratio量化某个应用区域的流量有多少是内部自产自销从而发现哪些区域其实高度依赖外部通信、不宜直接 ring-fence。三、区域设计与跨区通信矩阵定义允许谁碰谁3.1 Zone DefinitionsZone NameDescriptionWorkloadsDefault PolicyPCI-CDECardholder data environment[list]Deny-allHR-SystemsHR applications[list]Deny-allDMZInternet-facing services[list]Deny-allManagementAdmin/monitoring[list]Restricted区域划分直接对应 SKILL.md Phase 2 的第 4 步Define Segmentation Zones四条典型的隔离动机环境隔离生产环境不得与开发环境通信层级隔离数据库层只接受应用层发起的连接应用 ring-fencingPCI 应用与非 PCI 工作负载物理/逻辑隔离管理面收敛Jump Server 是唯一管理通道。注意模板为每个区域预设了Deny-all默认策略——这正是零信任默认拒绝、按例放行的体现只有 Management 区域是Restricted部分受限。这一默认值也出现在 process.py 的generate_segmentation_rules()中所有从依赖图推导出的规则均为allow但末尾必追加一条action: deny, src: any, dst: any, port: any, protocol: any的默认拒绝兜底规则其 justification 为 Default deny - zero trust baseline。3.2 Inter-Zone Communication MatrixSource ZoneDestination ZonePorts/ProtocolsJustificationDMZApp-Tier8080/tcpWeb application trafficApp-TierDB-Tier3306/tcpDatabase queriesManagementAll Zones22/tcp, 9090/tcpSSH and monitoring通信矩阵的价值在于把每条跨区路径写清楚为什么——Justification 列是后续应用负责人签字、合规审计时最重要的证据。矩阵数据应来自应用依赖映射Application Dependency Map而非直觉SKILL.md 要求先部署可见性 Agent 采集 2-4 周实时流量遥测再在管理控制台构建依赖图。仓库提供了自动构建依赖图的能力process.py 的build_dependency_map()会读取 CSV/JSON 格式的流量数据字段含 src_ip/dst_ip、src_port/dst_port、protocol、bytes、packets、timestamp、src_label/dst_label按源 → 目标聚合成端口集合、协议集合、总字节数、总包数与流计数直接输出可序列化的依赖图 JSON——这正是填写本矩阵的自动化数据源。四、策略规则白名单放行 默认拒绝4.1 Allow RulesRule IDSourceDestinationPortProtocolProcessJustification1tcp2tcp每条允许规则都应尽可能带上Process进程级限制例如仅允许 httpd 访问 443 端口。进程级限制是主机型方案Illumio、Guardicore相对传统防火墙的关键优势——standards.md 中 Guardicore 一节明确轻量级 Agent 提供进程级可见性与强制。如果设备不支持进程级控制模板中该列可留空但应在理由列注明。规则生成可由 process.py 的generate_segmentation_rules()完成它遍历依赖图中每个 源→目标 的端口与协议组合逐条生成带status: proposed提案态的 allow 规则每条规则的 justification 自动记录观测到的流计数与字节数如 Observed 120 flows, 4521000 bytes——为应用负责人评审提供量化依据。4.2 Default Deny模板对默认拒绝的定义极其明确所有未被显式允许的流量一律拒绝拒绝规则必须记录日志并产生告警。从实现上看generate_segmentation_rules()自动追加的兜底 deny 规则与模板完全一致。而告警能力则依赖 agent.py 与 Illumio PCE 的集成其check_illumio_workloads()通过GET /api/v2/orgs/{org_id}/workloads拉取工作负载列表返回 hostname、enforcement_mode、visibility_level、online 状态用于确认强制模式是否正确下发详见 api-reference.md。4.3 三种强制模式Enforcement Modes设计策略前必须理解设备支持的强制模式api-reference.md 给出三种标准模式ModeDescriptionVisibility Only仅监控流量不阻断Selective阻断特定流量其余放行Full默认拒绝全部仅按策略放行零信任实施路径即先 Visibility Only对应模板的测试模式阶段再 Selective最终收敛到 Full。这种渐进式收敛在下一节的 Enforcement Schedule 中有明确的时间安排。五、强制执行时间表按风险分阶段推进WeekActivityApplicationsRisk Level1-2Agent deployment and discoveryAllLow3-4Label assignment and validationAllLow5-6Policy design and test modeAllLow7Enforce: Dev/Test environmentsDev appsLow8Enforce: Low-risk productionNon-criticalMedium9-10Enforce: Business-critical appsERP, CRMHigh11-12Enforce: Regulated environmentsPCI, HIPAAHigh这张 12 周时间表体现了微隔离实施的核心方法论先发现、后建模、再按风险从低到高逐步强制。对应 workflows.md 的 Workflow 1Microsegmentation Deployment Lifecycle完整生命周期为Discovery部署 Agent采集 2-4 周遥测构建流量图→ Classification打标签与 CMDB 校验按应用层分组→ Policy Design定义区域、创建白名单、设默认拒绝、记录例外→ Test Mode可见性模式观察 1-2 周将被阻断事件优化规则→ Enforcement按应用逐个切换监控 24-48 小时再推进下一个→ Continuous Ops每周违规评审、季度审计、CI/CD 集成、应急响应。值得强调的是时间表中的三个阶段保障测试模式窗口第 5-6 周策略在可见性模式下运行观察 would-block 事件要求连续 1-2 周无误报24-48 小时观察窗每次切换强制模式后监控应用异常验证通过才进入下一应用风险递进Dev/Test低风险→ 非关键生产中风险→ ERP/CRM 等业务关键高风险→ PCI/HIPAA 等受监管环境高风险。六、验证测试强制之后必须证明有效模板给出 6 项验证测试清单Legitimate traffic flows uninterrupted after enforcement合法流量在强制后不受影响Unauthorized cross-zone traffic is blocked未授权跨区流量被阻断Lateral movement from compromised workload is contained被攻陷工作负载的横向移动被遏制Policy violation alerts appear in SIEM策略违规告警出现在 SIEM 中Break-glass procedure works for emergency access紧急访问的破窗流程可用Application dependency map matches actual flows应用依赖图与实际流量一致这 6 项可以借助仓库脚本实现自动化验证。策略违反与横向移动检测是其中的技术难点process.py 提供了两个直接可用的能力validate_policy_against_flows()将策略规则allow 规则集合 是否有默认 deny与观测流量逐一比对输出 allowed_flows / blocked_flows / unmatched_flows 及明细量化策略会误伤多少合法流量、能拦住多少违规流量detect_anomalous_flows()找出未被任何 allow 规则覆盖的流量并按目的端口自动定级——高危端口22/3389/445/135即 SSH/RDP/SMB/RPC典型的横向移动目标标记为severity: high其余为medium输出理由 Flow not covered by any allow rule。这与 SKILL.md 中 Phase 3 的验证步骤完全对应执行渗透测试尝试跨区横向移动、确认控制台出现阻断告警、测试破窗覆盖流程、记录每个应用区域的强制状态。对应 workflows.md 的 Workflow 4Incident Response with Microsegmentation一旦出现异常东西向流量告警应急流程为调查控制台查流、溯源源工作负载、交叉 SIEM→ 遏制立即应用隔离策略 deny-all except forensic瞬间隔离被攻陷工作负载→ 评估影响检查横向移动是否被策略阻断、确定爆炸半径→ 修复补丁/重镜像、强化策略、解除隔离、事后复盘。七、签字与交付以合规收尾StakeholderRoleApprovalDateSecurity ArchitectureNetwork OperationsApplication OwnersCompliance/Audit签字表是实施计划从技术方案变为受控变更的最后一环。模板明确要求四类干系人背书安全架构策略正确性、网络运维可运维性、应用负责人白名单不误伤业务、合规/审计满足监管要求。对于受监管环境standards.md 提供了签字时的合规依据PCI DSS v4.0Requirement 1.3网络控制限制进出 CDE 的访问、Requirement 1.4可信与不可信网络间连接受控微隔离可将 CDE 工作负载与非 CDE 系统隔离从而缩减 PCI 审计范围主机型微隔离经 QSA 验证后可作为网络分段的对等补偿控制NIST SP 800-207将微隔离列为三种 ZTA 部署模式之一对应 AC-4信息流强制、SC-7边界保护、SI-4监控等控制项CISA Zero Trust Maturity Model v2.0网络支柱从 Traditional宏分段、静态 ACL→ Initial初始工作负载隔离→ Advanced工作负载级微隔离、基于身份的策略→ Optimal全微隔离、自适应策略的成熟度路径Forrester ZTX策略应基于工作负载身份与上下文而非网络位置并与 DevOps 流水线集成实现策略自动化。八、配套自动化工具的使用方式本技能附带两个可直接运行的 Python 脚本用于把模板中的表格从手填升级为自动生成/验证。8.1 微隔离审计 Agentagent.py依赖boto3与requestspip install boto3 requests提供三个能力audit_aws_security_groups()审计 AWS 安全组中0.0.0.0/0开放规则标记 HIGH以及前缀小于 /24 的过宽 CIDR标记 MEDIUM并给出收敛建议——这是云环境微隔离合规的起点check_illumio_workloads()调用 Illumio PCE APIGET /api/v2/orgs/{org_id}/workloads核对每个工作负载的 enforcement_mode 与 visibility_level确认强制模式已正确下发实验室自签名证书场景可设置环境变量SKIP_TLS_VERIFYtruegenerate_segmentation_policy()输出零信任原则下的分层策略示例如 web 仅允许来自 load-balancer 的 443、app 仅允许来自 web 的 8080、db 仅允许来自 app 的 5432。运行方式python agent.py --audit --profile aws-profile --region us-east-1 --output audit_report.json8.2 策略分析与流量验证器process.py接受 CSV/JSON 格式的流量数据提供 5 种 action# 构建应用依赖图 python process.py --flows flows.csv --action map --output dep_map.json # 从依赖图生成提案态策略规则含默认拒绝兜底 python process.py --flows flows.csv --action rules --output rules.json # 用策略验证流量统计放行/阻断/未匹配 python process.py --flows flows.csv --policy rules.json --action validate # 检测违反策略的异常流量横向移动信号 python process.py --flows flows.csv --policy rules.json --action anomalies # 生成综合报告区域、验证、异常、依赖图摘要 python process.py --flows flows.csv --policy rules.json --labels labels.json --action report其中report输出的 summary 字段total_flows、segmentation_zones、blocked_flows、anomalies_detected 等可直接作为 template.md 验证测试与签字阶段的量化附件。九、模板使用建议与注意前提工具能力差异本模板为厂商无关设计但 Zone Definitions 中的Restricted模式、Allow Rules 中的 Process 列、enforcement_mode 的三种取值均依赖具体平台能力落地前务必核对所选工具NSX/Illumio/Guardicore/ACI/Calico 等的文档流程纪律模板的时间表假设2-4 周发现 1-2 周测试的理想节奏若组织内 CMDB 不准确、应用负责人响应慢应拉长对应阶段而非压缩测试窗口破窗流程Break-glass 必须在强制前设计并实测否则强制阶段出现业务中断时无法应急合规语境本技能映射的 NIST CSF 2.0 控制项PR.AA-01、PR.AA-05、PR.IR-01、GV.PO-01与 ATTCK 技术T1021/T1210/T1570/T1046/T1018可作为安全架构评审的框架对齐依据。延伸阅读完整的四阶段方法论见 SKILL.md四个配套流程图部署生命周期、策略创建、关键资产 ring-fencing、应急响应见 workflows.md合规框架与控制项映射见 standards.md平台 API 与强制模式见 api-reference.md。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 零信任微隔离落地实践：基于 Anthropic-Cybersecurity-Skills 的微隔离实施计划模板与策略设计指南
零信任微隔离落地实践基于 Anthropic-Cybersecurity-Skills 的微隔离实施计划模板与策略设计指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills在零信任架构NIST SP 800-207中微隔离Microsegmentation是把网络划分为细粒度安全区域、在应用层而非传统 VLAN 层面实施工作负载间最小权限访问的关键能力其直接价值在于即便攻击者获得初始访问权限也无法在同一网段内横向移动。本文以本仓库 skills/configuring-microsegmentation-for-zero-trust 技能下的 微隔离实施计划模板 为主体结合该技能的 工作流参考、标准框架参考、API 参考 以及两个可执行的 Python 脚本agent.py、process.py完整讲解从项目立项、工作负载盘点、区域设计、策略编排到分阶段强制的实施全过程。读完本文你将掌握一套可直接复制、可交付给安全架构评审与合规审计的微隔离实施计划骨架以及与之配套的自动化审计与策略验证方法。一、模板定位把零信任微隔离工程化本仓库将微隔离能力封装为一个结构化技能其 frontmatter 声明了适用的框架映射NIST CSF 2.0 控制项PR.AA-01、PR.AA-05、PR.IR-01、GV.PO-01MITRE ATTCK 技术T1021远程服务、T1210利用远程服务、T1570横向工具传输、T1046网络服务发现、T1018远程系统发现。而 template.md 是这份技能中把方法论落成交付物的载体——一份实施计划模板Implementation Plan Template。它与技能主体 SKILL.md 的四阶段工作流发现与映射 → 策略设计 → 强制执行 → 运维维护一一对应将流程拆解为 8 张可直接填写的表格Project Information项目信息Workload Inventory工作负载盘点Segmentation Zone Design区域设计含 Zone Definitions 与 Inter-Zone Communication MatrixPolicy Rules策略规则含 Allow Rules 与 Default DenyEnforcement Schedule强制执行时间表Validation Tests验证测试清单Sign-Off干系人签字使用方式将该模板作为实施项目的主控文档配合 workflows.md 中的流程图理解每一步的输入输出配合 standards.md 引用合规依据配合 api-reference.md 中的 API 实现自动化。二、项目信息与工作负载盘点一切从清单开始2.1 Project Information模板开篇要求登记项目元数据这是后续所有决策的溯源基础FieldValueProject NameOrganizationProject LeadStart DateSegmentation Tool[Illumio / VMware NSX / Guardicore / Cisco ACI]其中Segmentation Tool的选型直接决定强制点Enforcement Point的实现方式。根据 SKILL.md 的架构模型可选路径包括网络型VMware NSX、Cisco ACI在虚拟化层或网络矩阵层强制分布式防火墙规则无需改动物理拓扑详见 standards.md 对 NSX Distributed Firewall 的描述有状态 L4-7 防火墙内嵌于 Hypervisor 内核策略在 vNIC 层面即被评估。主机型Illumio、Guardicore通过 Agent 在 OS 层强制Linux 用 iptablesWindows 用 WFPIllumio 的 VENVirtual Enforcement Node采集遥测PCEPolicy Compute Engine集中策略与可视化。容器型Calico、Cilium在 Kubernetes 的 Pod/容器级执行网络策略。应用型Zscaler Workload Segmentation基于软件身份而非 IP 的分段。2.2 Workload InventoryWorkloadIP AddressOSRoleApplicationEnvironmentLocationwebprodappproddbprod这张表是发现阶段的核心输出。模板预设了典型三层架构web/app/db每个字段都与后续标签体系Label直接对应Role、Application、Environment、Location 正是现代微隔离基于标签Label-Based Policy策略模型的四个维度。标签化策略相比 IP 规则的最大优势在于跨环境可移植、迁移时不受 IP 变化影响——这也是 SKILL.md 中强调的设计原则。从仓库脚本看盘点结果还可以通过 process.py 中的identify_segmentation_zones()自动验证该函数依据workload_labels按 IP 映射到 application 标签统计每个区域的内外流量并计算隔离率isolation_ratio量化某个应用区域的流量有多少是内部自产自销从而发现哪些区域其实高度依赖外部通信、不宜直接 ring-fence。三、区域设计与跨区通信矩阵定义允许谁碰谁3.1 Zone DefinitionsZone NameDescriptionWorkloadsDefault PolicyPCI-CDECardholder data environment[list]Deny-allHR-SystemsHR applications[list]Deny-allDMZInternet-facing services[list]Deny-allManagementAdmin/monitoring[list]Restricted区域划分直接对应 SKILL.md Phase 2 的第 4 步Define Segmentation Zones四条典型的隔离动机环境隔离生产环境不得与开发环境通信层级隔离数据库层只接受应用层发起的连接应用 ring-fencingPCI 应用与非 PCI 工作负载物理/逻辑隔离管理面收敛Jump Server 是唯一管理通道。注意模板为每个区域预设了Deny-all默认策略——这正是零信任默认拒绝、按例放行的体现只有 Management 区域是Restricted部分受限。这一默认值也出现在 process.py 的generate_segmentation_rules()中所有从依赖图推导出的规则均为allow但末尾必追加一条action: deny, src: any, dst: any, port: any, protocol: any的默认拒绝兜底规则其 justification 为 Default deny - zero trust baseline。3.2 Inter-Zone Communication MatrixSource ZoneDestination ZonePorts/ProtocolsJustificationDMZApp-Tier8080/tcpWeb application trafficApp-TierDB-Tier3306/tcpDatabase queriesManagementAll Zones22/tcp, 9090/tcpSSH and monitoring通信矩阵的价值在于把每条跨区路径写清楚为什么——Justification 列是后续应用负责人签字、合规审计时最重要的证据。矩阵数据应来自应用依赖映射Application Dependency Map而非直觉SKILL.md 要求先部署可见性 Agent 采集 2-4 周实时流量遥测再在管理控制台构建依赖图。仓库提供了自动构建依赖图的能力process.py 的build_dependency_map()会读取 CSV/JSON 格式的流量数据字段含 src_ip/dst_ip、src_port/dst_port、protocol、bytes、packets、timestamp、src_label/dst_label按源 → 目标聚合成端口集合、协议集合、总字节数、总包数与流计数直接输出可序列化的依赖图 JSON——这正是填写本矩阵的自动化数据源。四、策略规则白名单放行 默认拒绝4.1 Allow RulesRule IDSourceDestinationPortProtocolProcessJustification1tcp2tcp每条允许规则都应尽可能带上Process进程级限制例如仅允许 httpd 访问 443 端口。进程级限制是主机型方案Illumio、Guardicore相对传统防火墙的关键优势——standards.md 中 Guardicore 一节明确轻量级 Agent 提供进程级可见性与强制。如果设备不支持进程级控制模板中该列可留空但应在理由列注明。规则生成可由 process.py 的generate_segmentation_rules()完成它遍历依赖图中每个 源→目标 的端口与协议组合逐条生成带status: proposed提案态的 allow 规则每条规则的 justification 自动记录观测到的流计数与字节数如 Observed 120 flows, 4521000 bytes——为应用负责人评审提供量化依据。4.2 Default Deny模板对默认拒绝的定义极其明确所有未被显式允许的流量一律拒绝拒绝规则必须记录日志并产生告警。从实现上看generate_segmentation_rules()自动追加的兜底 deny 规则与模板完全一致。而告警能力则依赖 agent.py 与 Illumio PCE 的集成其check_illumio_workloads()通过GET /api/v2/orgs/{org_id}/workloads拉取工作负载列表返回 hostname、enforcement_mode、visibility_level、online 状态用于确认强制模式是否正确下发详见 api-reference.md。4.3 三种强制模式Enforcement Modes设计策略前必须理解设备支持的强制模式api-reference.md 给出三种标准模式ModeDescriptionVisibility Only仅监控流量不阻断Selective阻断特定流量其余放行Full默认拒绝全部仅按策略放行零信任实施路径即先 Visibility Only对应模板的测试模式阶段再 Selective最终收敛到 Full。这种渐进式收敛在下一节的 Enforcement Schedule 中有明确的时间安排。五、强制执行时间表按风险分阶段推进WeekActivityApplicationsRisk Level1-2Agent deployment and discoveryAllLow3-4Label assignment and validationAllLow5-6Policy design and test modeAllLow7Enforce: Dev/Test environmentsDev appsLow8Enforce: Low-risk productionNon-criticalMedium9-10Enforce: Business-critical appsERP, CRMHigh11-12Enforce: Regulated environmentsPCI, HIPAAHigh这张 12 周时间表体现了微隔离实施的核心方法论先发现、后建模、再按风险从低到高逐步强制。对应 workflows.md 的 Workflow 1Microsegmentation Deployment Lifecycle完整生命周期为Discovery部署 Agent采集 2-4 周遥测构建流量图→ Classification打标签与 CMDB 校验按应用层分组→ Policy Design定义区域、创建白名单、设默认拒绝、记录例外→ Test Mode可见性模式观察 1-2 周将被阻断事件优化规则→ Enforcement按应用逐个切换监控 24-48 小时再推进下一个→ Continuous Ops每周违规评审、季度审计、CI/CD 集成、应急响应。值得强调的是时间表中的三个阶段保障测试模式窗口第 5-6 周策略在可见性模式下运行观察 would-block 事件要求连续 1-2 周无误报24-48 小时观察窗每次切换强制模式后监控应用异常验证通过才进入下一应用风险递进Dev/Test低风险→ 非关键生产中风险→ ERP/CRM 等业务关键高风险→ PCI/HIPAA 等受监管环境高风险。六、验证测试强制之后必须证明有效模板给出 6 项验证测试清单Legitimate traffic flows uninterrupted after enforcement合法流量在强制后不受影响Unauthorized cross-zone traffic is blocked未授权跨区流量被阻断Lateral movement from compromised workload is contained被攻陷工作负载的横向移动被遏制Policy violation alerts appear in SIEM策略违规告警出现在 SIEM 中Break-glass procedure works for emergency access紧急访问的破窗流程可用Application dependency map matches actual flows应用依赖图与实际流量一致这 6 项可以借助仓库脚本实现自动化验证。策略违反与横向移动检测是其中的技术难点process.py 提供了两个直接可用的能力validate_policy_against_flows()将策略规则allow 规则集合 是否有默认 deny与观测流量逐一比对输出 allowed_flows / blocked_flows / unmatched_flows 及明细量化策略会误伤多少合法流量、能拦住多少违规流量detect_anomalous_flows()找出未被任何 allow 规则覆盖的流量并按目的端口自动定级——高危端口22/3389/445/135即 SSH/RDP/SMB/RPC典型的横向移动目标标记为severity: high其余为medium输出理由 Flow not covered by any allow rule。这与 SKILL.md 中 Phase 3 的验证步骤完全对应执行渗透测试尝试跨区横向移动、确认控制台出现阻断告警、测试破窗覆盖流程、记录每个应用区域的强制状态。对应 workflows.md 的 Workflow 4Incident Response with Microsegmentation一旦出现异常东西向流量告警应急流程为调查控制台查流、溯源源工作负载、交叉 SIEM→ 遏制立即应用隔离策略 deny-all except forensic瞬间隔离被攻陷工作负载→ 评估影响检查横向移动是否被策略阻断、确定爆炸半径→ 修复补丁/重镜像、强化策略、解除隔离、事后复盘。七、签字与交付以合规收尾StakeholderRoleApprovalDateSecurity ArchitectureNetwork OperationsApplication OwnersCompliance/Audit签字表是实施计划从技术方案变为受控变更的最后一环。模板明确要求四类干系人背书安全架构策略正确性、网络运维可运维性、应用负责人白名单不误伤业务、合规/审计满足监管要求。对于受监管环境standards.md 提供了签字时的合规依据PCI DSS v4.0Requirement 1.3网络控制限制进出 CDE 的访问、Requirement 1.4可信与不可信网络间连接受控微隔离可将 CDE 工作负载与非 CDE 系统隔离从而缩减 PCI 审计范围主机型微隔离经 QSA 验证后可作为网络分段的对等补偿控制NIST SP 800-207将微隔离列为三种 ZTA 部署模式之一对应 AC-4信息流强制、SC-7边界保护、SI-4监控等控制项CISA Zero Trust Maturity Model v2.0网络支柱从 Traditional宏分段、静态 ACL→ Initial初始工作负载隔离→ Advanced工作负载级微隔离、基于身份的策略→ Optimal全微隔离、自适应策略的成熟度路径Forrester ZTX策略应基于工作负载身份与上下文而非网络位置并与 DevOps 流水线集成实现策略自动化。八、配套自动化工具的使用方式本技能附带两个可直接运行的 Python 脚本用于把模板中的表格从手填升级为自动生成/验证。8.1 微隔离审计 Agentagent.py依赖boto3与requestspip install boto3 requests提供三个能力audit_aws_security_groups()审计 AWS 安全组中0.0.0.0/0开放规则标记 HIGH以及前缀小于 /24 的过宽 CIDR标记 MEDIUM并给出收敛建议——这是云环境微隔离合规的起点check_illumio_workloads()调用 Illumio PCE APIGET /api/v2/orgs/{org_id}/workloads核对每个工作负载的 enforcement_mode 与 visibility_level确认强制模式已正确下发实验室自签名证书场景可设置环境变量SKIP_TLS_VERIFYtruegenerate_segmentation_policy()输出零信任原则下的分层策略示例如 web 仅允许来自 load-balancer 的 443、app 仅允许来自 web 的 8080、db 仅允许来自 app 的 5432。运行方式python agent.py --audit --profile aws-profile --region us-east-1 --output audit_report.json8.2 策略分析与流量验证器process.py接受 CSV/JSON 格式的流量数据提供 5 种 action# 构建应用依赖图 python process.py --flows flows.csv --action map --output dep_map.json # 从依赖图生成提案态策略规则含默认拒绝兜底 python process.py --flows flows.csv --action rules --output rules.json # 用策略验证流量统计放行/阻断/未匹配 python process.py --flows flows.csv --policy rules.json --action validate # 检测违反策略的异常流量横向移动信号 python process.py --flows flows.csv --policy rules.json --action anomalies # 生成综合报告区域、验证、异常、依赖图摘要 python process.py --flows flows.csv --policy rules.json --labels labels.json --action report其中report输出的 summary 字段total_flows、segmentation_zones、blocked_flows、anomalies_detected 等可直接作为 template.md 验证测试与签字阶段的量化附件。九、模板使用建议与注意前提工具能力差异本模板为厂商无关设计但 Zone Definitions 中的Restricted模式、Allow Rules 中的 Process 列、enforcement_mode 的三种取值均依赖具体平台能力落地前务必核对所选工具NSX/Illumio/Guardicore/ACI/Calico 等的文档流程纪律模板的时间表假设2-4 周发现 1-2 周测试的理想节奏若组织内 CMDB 不准确、应用负责人响应慢应拉长对应阶段而非压缩测试窗口破窗流程Break-glass 必须在强制前设计并实测否则强制阶段出现业务中断时无法应急合规语境本技能映射的 NIST CSF 2.0 控制项PR.AA-01、PR.AA-05、PR.IR-01、GV.PO-01与 ATTCK 技术T1021/T1210/T1570/T1046/T1018可作为安全架构评审的框架对齐依据。延伸阅读完整的四阶段方法论见 SKILL.md四个配套流程图部署生命周期、策略创建、关键资产 ring-fencing、应急响应见 workflows.md合规框架与控制项映射见 standards.md平台 API 与强制模式见 api-reference.md。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考