安全架构设计Skill 用法详解

安全架构设计Skill：把防御深度与零信任前置到系统设计阶段

它是什么：architecting-security（安全架构设计）是一个面向“战略层”的 AI 技能，围绕防御深度、零信任原则、威胁建模与控制框架映射，帮你系统性设计安全架构，而不是零散地配置某一台防火墙。
解决什么问题：安全常常是上线前才“补作业”——架构阶段缺少方法论、威胁识别靠个人经验、合规要求难以落到具体控制项。这个技能把方法论、框架和落地模式一次性打包。
核心能力：9 层防御深度模型、零信任架构组件与落地路线、STRIDE / PASTA / DREAD / 攻击树威胁建模、NIST CSF 2.0 / CIS Controls v8 / ISO 27001 / OWASP Top 10 控制映射，以及 AWS / GCP / Azure 云安全架构与 SLSA + SBOM 供应链安全。
怎么用：以自然语言对话方式调用，你把系统上下文（数据流、技术栈、合规目标）说清楚，它输出分层控制建议、威胁清单、框架映射表与实施优先级。
适合谁：安全架构师、云平台与后端工程师、技术负责人、合规与风控人员，以及需要给新系统做安全设计的团队。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

这个技能的中文名是 安全架构设计Skill，英文名是 architecting-security，技能 ID 为 13446。在支持 Skills 的 AI 环境里，技能 ID 可以用来精确检索定位，避免同名混淆。

它要解决的问题很具体：安全架构设计长期依赖“资深专家 + 大量文档”。一个团队要在新系统上落地零信任，得先读 NIST SP 800-207；要做威胁建模，得先统一 STRIDE 的六类威胁口径；要过合规，得把控制项一条条映射到 NIST CSF 或 CIS Controls。这些工作本身不难，但极其费时，且容易因人员流动而断层。安全架构设计Skill 把这些方法论固化成可复用的“技能包”，让 AI 在对话中按你的系统上下文直接给出结构化产出。

“一键安装”为什么能提升开发效率？ 因为技能是“一次安装、长期复用”的知识载体。传统做法是每次提问都把方法论背景粘进对话框，或者让 AI 自由发挥导致口径不一；安装技能后，AI 默认按防御深度、零信任、STRIDE 等标准方法论组织答案，输出格式稳定，团队多人使用时结论可比。

安装与生效的一般步骤（具体命令、入口与支持的客户端，以官方说明为准）：

确认环境：你的 AI 客户端 / IDE 插件 / 命令行工具需要支持 Skills 能力，并已登录可用账号。
打开技能入口：进入技能市场、技能目录或本地技能管理页面。
检索技能：用英文名 architecting-security、中文名“安全架构设计”或技能 ID 13446 搜索。
安装 / 启用：点击安装或启用开关，部分环境需确认权限与作用范围（个人级或项目级）。
验证是否生效：发起一个可判别的问题，例如“对一个对外提供 REST API 的订单系统用 STRIDE 做威胁建模，输出威胁清单、DREAD 评分和缓解措施”。如果回答中出现数据流图（DFD）建模说明、按 S（欺骗）/T（篡改）/R（否认）/I（信息泄露）/D（拒绝服务）/E（权限提升）分类的威胁清单，并给出分层缓解建议，说明技能已正常加载；若回答泛泛而谈、没有框架结构，则需检查是否启用成功。
团队共享（可选）：在支持项目级配置的环境中，把技能写入项目配置，让团队成员共享同一套安全架构方法论。

2. 该技能的主要功能和特点

防御深度（9 层模型）：覆盖物理安全、网络边界、网络分段、终端保护、应用层、数据层、身份与访问管理、行为分析、安全运营九层，强调“每层独立保护，一层失效不危及全局”，并可做失效影响分析。
零信任架构设计：落实“永不信任、始终验证”，包含持续验证、最小权限（JIT 访问）、假设被入侵、显式验证、微分段五大原则，以及策略引擎、身份提供者、设备姿态服务、上下文 / 风险引擎、策略执行点等组件划分。
多方法学威胁建模：内置 STRIDE（威胁识别，适合开发团队快速分析）、PASTA（风险为中心，适合企业风险管理）、DREAD（风险评分与排序）、攻击树（可视化架构评审），并给出 STRIDE 的标准应用流程：DFD 建模 → 逐组件识别威胁 → 分类记录 → 优先级排序 → 设计缓解控制。
控制框架映射：把安全控制映射到 NIST CSF 2.0（治理、识别、保护、检测、响应、恢复六大功能）、CIS Controls v8（18 个控制、IG1/IG2/IG3 分组的成熟度路径）、ISO 27001、OWASP Top 10（含注入、失效的身份验证、敏感数据泄露等风险的对应控制与框架编号）。
架构选择决策框架：按系统特征给出差异化路线——绿场（新系统）身份优先 + 默认微分段；棕场（存量系统）保留边界控制并逐步叠加零信任；合规驱动按 PCI DSS / HIPAA / FedRAMP 等要求映射控制；云原生对齐 AWS 良好架构安全支柱、GCP 安全最佳实践、Azure 安全基准。
云安全架构模式：给出 AWS 多账户策略（安全 OU 与工作负载 OU、服务控制策略 SCP 护栏）、GCP 组织 → 文件夹 → 项目的层级与 VPC Service Controls、Azure 中心-辐条着陆区与管理组策略层次，并列出各云的关键安全服务清单。
供应链安全：SLSA 四个等级的实施路径、SBOM 三大标准（CycloneDX、SPDX、SWID）与依赖管理最佳实践（CI/CD 自动生成 SBOM、持续扫描、锁定依赖版本、最小化依赖）。
身份与访问管理模式：MFA（TOTP、推送、生物识别、FIDO2 硬件令牌）、无密码演进、SSO 协议选型，以及 RBAC / ABAC / PBAC 的适用边界和 PAM（JIT 访问、凭证库、会话审计）。
安全监控与运营架构：SIEM 的日志采集 → 规范化 → 关联 → 告警 → 调查链路，SOAR 剧本化响应降低 MTTR，UEBA 与威胁情报（MITRE ATT&CK）驱动的主动狩猎。
可直接落地的配套资产：提供威胁建模模板脚本、控制差距分析脚本、SBOM 生成脚本与安全架构检查表脚本，把“建议”变成“可执行动作”。

和普通工具比强在哪？ 普通工具的定位是“战术执行”——配防火墙、写鉴权、扫漏洞；这个技能的定位是“战略规划”——先确定防护分层、信任边界、控制框架和优先级，再交给具体工具执行。它还提供与 infrastructure-as-code、kubernetes-operations、secret-management、building-ci-pipelines、configuring-firewalls、vulnerability-management、auth-security、siem-logging、compliance-frameworks 等技能的衔接说明，形成“设计 → 实施 → 监控 → 合规”的闭环。

3. 如何使用该技能？

第 1 步：明确你的场景类型。 先自问属于哪一类：新系统设计（绿场）、存量系统审计（棕场）、合规驱动（如 SOC 2、PCI DSS、HIPAA）、云迁移或多云治理、供应链安全建设。场景决定了技能会走哪条决策路径。

第 2 步：准备系统上下文。 输入质量决定输出质量。建议准备：系统架构图或数据流说明、技术栈与部署形态（自建 / 云 / 容器）、用户与角色、敏感数据种类与流向、已有安全措施、合规目标、团队规模与安全成熟度。

第 3 步：发起调用（自然语言即可）。 示例提示词：

“我们有一个面向 C 端的支付类 API 服务，部署在 AWS 多账户环境，团队 8 人，需要通过 PCI DSS。请按绿场思路设计安全架构：给出防御深度分层控制、零信任关键组件、STRIDE 威胁清单及优先级，并映射到 CIS Controls v8 的实施组。”

第 4 步：读取并校验输出。 典型输出包含：分层控制清单（网络、终端、应用、数据、IAM、监控）、威胁清单与 DREAD 排序、控制框架映射表、实施优先级与里程碑、需要进一步细化的待办项。重点校验两点——威胁是否覆盖了你的关键数据流；控制项是否能落到具体团队与工具。

第 5 步：借助配套脚本把结论工程化。 用威胁模型模板脚本生成 STRIDE 模板并填入业务信息；用控制差距分析脚本比对“当前控制”与目标框架的缺口；用 SBOM 生成脚本产出 CycloneDX 格式物料清单；用安全架构检查表脚本做交付前自查。

第 6 步：拆解到实施环节。 把架构结论分派给对应的战术技能或工具链：基础设施即代码落实安全默认值、Kubernetes 侧落实 RBAC 与网络策略、密钥管理体系化、CI/CD 中集成 SAST/DAST 与制品签名、SIEM 侧完成日志接入与检测规则。

第 7 步：迭代复盘。 上线后按“持续验证”原则回看：控制是否生效、告警是否可运营、缺口是否收敛，再把结论喂回下一轮设计。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
安全架构设计Skill（`architecting-security`）	战略层安全架构设计助手	防御深度 9 层、零信任、STRIDE/PASTA/DREAD 威胁建模、NIST CSF / CIS / ISO 27001 / OWASP 映射、云与供应链安全模式	在支持 Skills 的环境安装启用，自然语言调用；无需额外账号与部署	新系统安全设计、架构审计、合规映射、威胁建模工作坊	优势：方法论完整、输出结构化、可与其他技能串联落地；不足：结论需结合真实资产与业务判断，不能替代最终人工评审
通用大模型自由对话	通用问答	无固定方法论，靠提示词引导	极低，打开即用	零散安全概念答疑	优势：门槛最低；不足：口径不稳定、易遗漏框架维度、团队间结论不可比
传统安全咨询 / 第三方架构评审	人力交付的专家服务	深度评估、访谈、报告与整改建议	高：需立项、排期、预算，通常按项目或人天计费（以服务方报价为准）	高风险系统、监管强要求场景	优势：经验与责任背书强；不足：周期长、成本高、知识沉淀依赖文档，难以高频复用
自动化扫描类工具（SAST/DAST/漏洞扫描/CSPM）	战术层检测与合规检查	代码与运行时漏洞发现、云配置基线核查	中：需接入代码库或云账号，配置规则与权限	持续检测、上线前扫描、云配置漂移告警	优势：可自动化、结果客观；不足：只回答“哪里有问题”，不回答“架构该怎么设计”，缺少跨层防御与治理视角

怎么选？ 如果团队缺少安全架构方法论、需要在设计阶段就把防线铺好，优先用安全架构设计Skill 出初稿与框架映射，再用扫描类工具做持续验证，关键系统叠加人工评审。

5. 该技能的典型应用场景与实际体验情况

场景一：新业务系统上线前的安全架构设计。 角色是后端架构师或技术负责人，痛点是“知道要安全，但不知道从哪一层开始设计”，尤其面对对外 API 与多租户数据。使用方式是描述业务与数据流，让技能按绿场路线输出“身份优先 + 默认微分段 + 假设被入侵”的分层方案，并列出每层要落地的具体控制。实际体验上，上手难度低，第一次对话就能拿到可讨论的架构骨架；注意事项是必须把“哪些数据是敏感的、谁访问它”讲清楚，否则威胁清单容易泛化。

场景二：存量系统的安全审计与合规映射。 角色是安全工程师或合规负责人，痛点是把 NIST CSF、CIS Controls、ISO 27001 的要求一条条对照现有控制，表格做到崩溃。使用方式是提供现有控制清单与目标框架，让技能做差距分析并输出映射表与优先级。实际体验上，效率提升最明显的是“框架翻译”环节，原本需要反复查文档的映射工作变成一次对话的初稿；注意事项是框架条目存在版本差异（如 NIST CSF 2.0 与早期版本的功能划分不同），落地前需确认版本口径。

场景三：开发团队的威胁建模工作坊。 角色是研发小组，痛点是威胁建模被视为“安全部门的事”，会议开成形式主义。使用方式是以数据流图为输入，让技能按 STRIDE 逐组件生成威胁清单，再用 DREAD 打分排序，团队只讨论“哪些威胁真的会发生、怎么缓解”。实际体验上，STRIDE 六类威胁给了非安全背景的开发者一个可操作的提问框架，讨论效率明显提高；注意事项是打分带主观性，最好由架构师与业务方共同确认优先级。

场景四：云迁移与多账户安全治理。 角色是云平台工程师，痛点是把单账号环境迁到多账号 / 多云后，权限、日志、网络边界都变得混乱。使用方式是按 AWS Organizations 的安全 OU 与工作负载 OU 划分、SCP 护栏、集中日志与检测服务设计落地路径，或按 Azure 中心-辐条、GCP 组织层级设计。实际体验上，技能给出的服务清单与账户职责划分能直接转成落地清单；注意事项是最终设计仍需结合现有账号结构、成本与团队运维能力做裁剪。

6. 该技能能为用户带来的价值

第一，把方法论成本降到接近零。 防御深度 9 层、STRIDE 六类威胁、NIST CSF 六大功能、CIS 18 个控制——这些知识原本需要资深专家长期积累，现在以对话形式随取随用，新人也能按标准框架产出可评审的设计初稿。

第二，把“事后补救”变成“事前设计”。 在架构阶段就明确信任边界、分段策略、身份体系与加密要求，能显著减少上线后返工改造的代价；越晚补安全，改造成本越高，这是行业共识，也是这个技能最大的杠杆点。

第三，让安全与合规说同一种语言。 通过控制框架映射表，安全团队的技术控制可以直接对应到合规要求的条目，减少“技术做了、合规不认”的反复沟通，也让审计准备从“临时凑材料”变成“常态可追溯”。

第四，输出可比对、可沉淀。 团队多人使用同一技能，威胁分类口径、框架版本、控制描述方式保持一致，历史设计可以复用与对比，长期形成组织自己的安全架构知识资产。

第五，为后续工程化铺路。 技能明确了与基础设施即代码、Kubernetes 运维、密钥管理、CI/CD、防火墙配置、漏洞管理、SIEM 日志等环节的衔接关系，架构结论不会停留在 PPT 上，而是能拆成一条条工程任务。

需要说明的是，具体能节省多少工时取决于系统复杂度、团队既有基础与合规要求强度，建议先用一两个真实系统做小范围试点，再评估推广节奏。

7. 常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认生效？ A：在支持 Skills 的 AI 客户端或工具中，进入技能市场 / 技能目录，用英文名 architecting-security、中文名“安全架构设计”或技能 ID 13446 搜索后安装启用。验证方式是提一个带明确框架的问题（例如用 STRIDE 对某个 API 做威胁建模），若回答呈现数据流建模、六类威胁分类和缓解措施的结构化内容，说明已生效。具体入口、命令与支持的客户端以官方说明为准。

Q2：使用这个技能收费吗？ A：技能本身的获取与计费方式取决于所在平台的规则，可能随订阅方案或调用量变化，请以官方说明为准。建议在安装前先确认所属套餐是否包含 Skills 能力。

Q3：它适合谁用？纯开发背景能用吗？ A：适合安全架构师、云平台与后端工程师、技术负责人、合规与风控人员。纯开发背景同样能用——技能的价值就在于把方法论结构化，你只需要提供系统上下文（数据流、技术栈、合规目标），它负责按框架组织输出；但最终的风险判断与优先级取舍仍需结合业务实际。

Q4：它和漏洞扫描、SAST/DAST 这类工具冲突吗？ A：不冲突，是上下游关系。这个技能做的是战略层设计——分层防御、信任边界、控制框架与优先级；扫描类工具做的是战术层验证——发现具体漏洞与配置偏差。合理做法是先用技能出架构与控制基线，再用扫描工具持续验证是否偏离基线。

Q5：它和传统安全咨询、外部架构评审怎么选？ A：可以组合使用。日常架构设计、威胁建模、框架映射用技能快速出初稿，成本低、迭代快；涉及监管强要求、高风险资金或数据场景，再引入外部专家做评审与背书。技能无法替代专家对业务语境的判断，但能把专家从“写模板、查框架”的重复劳动中解放出来，让评审聚焦在真正的风险决策上。