安全软件开发生命周期
安全的 SDLC 为交付的每个阶段分配一项安全活动，使缺陷在修复成本最低的地方被发现。我们把安全需求与功能需求一同定义，在设计阶段进行威胁建模，在流水线中自动化分析，并在发布前完成验证。每项活动都会留下一份可以向评审者出示的记录。
- 安全需求与滥用场景
- 基于 STRIDE 与数据流图的威胁建模
- 安全编码规范与评审清单
- CI 中的 SAST、DAST 与软件成分分析
- 纳入“完成的定义”的安全验收标准
- 对齐 OWASP SAMM 与 NIST SSDF 的实践
概览
安全是系统构建方式所带来的一种属性。它体现在信任边界划在哪里，身份如何建立与传递，哪个组件被允许访问哪些数据，以及攻击者攻陷任何单一部分之后能得到什么。工具与评审有助于发现缺陷，但它们无法补上一条架构中从未存在过的边界。
我们把网络安全视为一门贯穿整个生命周期的工程学科。需求中带有数据分级与滥用场景。设计要经过威胁建模。代码依据安全的默认配置编写，并被自动检查。基础设施按最小权限与分段网络来定义。生产环境针对威胁模型所预测的行为进行监控，事件响应则在需要它之前就已规划妥当。
我们的工作范围，是我们所设计和构建的系统的安全，以及支撑组织合规计划的工程工作。我们设计控制措施与证据采集机制，以支持 ISO 27001、SOC 2 与 PCI DSS 等框架。正式的认证与鉴证由具备资质的审计机构执行；独立的渗透测试则被纳入交付计划，作为我们工程工作的一项输入。
我们构建什么
技术领域
应用与 API 安全
针对定制软件的入侵，大多利用的是授权、输入处理或会话管理中的缺陷。我们设计的 API 在边缘完成认证，在资源处完成授权，依据 schema 校验每一项输入，并按身份实施限流。OWASP Top 10 与 OWASP API Security Top 10 被用作最低限度的检查清单，而不是设计本身。
- 对象级与功能级的授权检查
- OAuth 2.0 与 OpenID Connect，配合短时效令牌
- schema 校验与输出编码
- 限流、配额与滥用检测
- 面向服务间与合作方 API 的双向 TLS 与请求签名
- 防范注入、SSRF、CSRF 与反序列化缺陷
身份与访问管理
身份是现代系统的控制平面。我们为企业员工、客户与工作负载设计身份与访问管理：各自如何被认证，权限如何建模，访问如何被复核与撤销。默认执行最小权限，权限提升则是临时的、经过审批的，并且留有日志。
- 基于 OIDC 与 SAML 联邦的单点登录
- 多因素认证，以及基于 WebAuthn 的 passkey
- 用 RBAC 处理粗粒度权限，用 ABAC 处理依赖上下文的规则
- 不使用静态密钥的工作负载身份与服务账号
- 带会话录制的即时（just-in-time）特权访问
- 基于 SCIM 的入职、转岗与离职自动化
云、基础设施与容器安全
云上的安全事故通常由配置错误引起：公开的存储、过于宽泛的角色，或暴露在外的管理接口。我们通过组织级防护栏、私有网络、默认加密与持续的安全态势检查来防止这些问题。容器基于最小化镜像构建，不以 root 运行，并受到准入策略与网络策略的约束。
- 网络分段与私有服务端点
- 云安全态势管理与 CIS 基准检查
- 使用托管密钥服务实现静态与传输加密
- 最小化与 distroless 基础镜像，并进行镜像扫描
- Pod 安全标准、seccomp profile 与网络策略
- 使用 Falco 进行运行时威胁检测
密钥、依赖与漏洞管理
凭证与第三方代码，是攻击者最常重复利用的两类资产。密钥保存在托管的存储中，在运行时注入并自动轮换，同时对任何被提交到源码仓库的密钥进行检测。漏洞则作为一个受管理的 backlog 来处理：持续发现，依据可利用性与暴露面排定优先级，并按商定的时限完成修复。
- HashiCorp Vault 与云原生密钥管理服务
- 动态、短时效的数据库与云凭证
- 代码仓库与流水线中的密钥扫描
- 依赖锁定、SBOM 与自动更新
- 基于 CVSS、EPSS 与可达性的风险优先级排序
- 补丁修复时限等级与有跟踪的例外
监控、审计日志与事件响应
预防终有失效的时候，因此系统必须记录发生了什么，并在要紧时发出告警。我们设计的审计日志能够记录谁对哪个资源做了什么，把它们送入防篡改的存储，并依据威胁模型构建检测规则。事件响应则事先准备好，包括角色、runbook、沟通路径与演练。
- 包含操作者、操作、资源与结果的结构化审计日志
- 汇入 SIEM 的集中式日志管道
- 带保留策略的不可变日志存储
- 映射到 MITRE ATT&CK 技术的检测规则
- 事件 runbook、严重级别与 on-call 升级机制
- 桌面推演与事后复盘
安全源于架构
安全无法在开发完成之后再附加到应用上。一个以单一扁平网络、单一数据库用户和单一隐含的“已认证调用方”概念设计出来的系统，无论在它周围摆上多少扫描器和防火墙，这些特性都不会改变。到了那个阶段，真正管用的整改都是结构性的，而项目后期的结构性变更代价高昂，通常会被一再推迟。
四项设计决策决定了一个系统安全态势的绝大部分。信任边界界定了数据在何处从一个信任级别跨入另一个信任级别，因而也界定了校验与认证必须在何处发生。身份界定了每个用户与工作负载如何证明自己是谁，以及这份证明如何沿调用链传递。数据分级界定了哪些数据需要加密、脱敏、访问限制或驻留管控。爆炸半径界定了攻击者在攻陷单一组件之后能够触及什么。
尽早把这些事情做对，后续的控制措施就会简单而局部。一个只持有窄范围凭证的服务，不可能泄露一个它从来读不到的数据库。在数据层强制执行的租户标识，不会因为某个 handler 里漏掉一次检查而被绕过。我们把这些视为与可用性和延迟同等地位的架构需求。
- 信任边界：在每一次跨越时都进行认证与校验，内部的跨越也不例外
- 身份：每个用户、每个工作负载各有一个可验证的身份，并端到端传递
- 数据分级：控制措施跟随数据的敏感度，无论数据被复制到哪里
- 爆炸半径：对网络、账号、凭证与租户进行分段，使单点失效被控制在局部
架构
安全架构：纵深防御
身份
每个请求都经过认证与授权
- SSO 与 MFA
- 基于角色的访问控制
- 服务身份
- 会话策略
边缘
- WAF
- DDoS 防护
- TLS 终止
- 限流
应用
- 输入校验
- 授权检查
- 安全 SDLC
- 依赖扫描
数据
- 静态加密
- 传输加密
- 密钥管理
- 数据分类
基础设施
- 网络分段
- 加固镜像
- 机密管理
- 补丁管理
检测与响应
假定某项控制会失效，并为此做好预案
- 集中审计日志
- 告警规则
- 事件响应手册
- 取证留存
把威胁建模当作一项设计活动
威胁建模针对一份设计回答四个问题：正在构建什么，可能出什么问题，将如何应对，以及这些应对是否足够。它从一张数据流图出发，图中标出进程、数据存储、外部参与者以及它们之间的信任边界。每个元素都要从仿冒、篡改、抵赖、信息泄露、拒绝服务与权限提升这几个方面加以检视。
产出是一份排好优先级的威胁清单，每一项都有一个决定：缓解、接受、转移，或通过修改设计来消除。缓解措施成为 backlog 条目与测试用例，而残留的威胁则指明生产监控应当检测什么。当架构发生变化时，例如新增一个集成、一个数据存储或一个可从外部访问的接口，就要重新审视威胁模型。
这项实践在由工程师自己于设计阶段完成、由安全专家从旁引导时最有价值。针对一项新功能开一个小时的会，经常就会改变某个授权模型，或去掉一条不必要的数据流，而此时改动的代价只是修改一张图。
零信任的落地方式
零信任抛弃了“网络内部的一切都是安全的”这一假设，代之以这样的要求：每一个请求，无论来自何处，都要经过认证、授权并加密。网络位置不再是一种凭证。访问决策针对每个请求做出，依据是调用方的身份、设备或工作负载的状态，以及资源的敏感度。
落到应用架构上，这意味着服务之间使用双向 TLS，工作负载身份由 SPIFFE 这类框架签发；授权策略在每个服务处评估；用户上下文通过签名令牌传递，而不是信任上游传来的某个 header。对于员工访问，这意味着在内部工具前面放置身份感知代理，取代扁平的 VPN。落地是渐进的：从最敏感的数据路径入手，建立强身份，然后随着可见性的提升逐步收紧策略。
面向合规框架的工程
ISO 27001、SOC 2 与 PCI DSS 等框架描述的是控制目标：访问受到限制，变更经过授权，数据得到保护，事件被记录，事故得到处置。其中大多数可以直接对应到工程机制上。带有强制评审的基础设施即代码，为变更控制提供证据。带有访问复核的集中式身份管理，为访问管理提供证据。不可变的审计日志，为监控提供证据。
我们在设计系统时，让这些证据成为日常运行的副产品，从流水线、云 API 与身份提供方自动采集。这降低了审计的成本，而更有意义的是，它意味着控制措施是在持续运行，而不是在评估之前临时拼凑。这些系统的设计目标是支持上述框架；评估以及任何认证，则是具备资质的第三方的职责。
我们如何构建
我们的方法
安全工作按风险排序：先弄清需要保护什么，再修正结构，然后把检查自动化，最后为失效做好准备。
- 01
识别资产并对数据分级
我们盘点系统、数据存储与数据流，并按敏感度与监管义务对数据分级。这决定了控制措施所保护的对象，以及它们需要达到的强度。
- 02
建立威胁模型并确定安全架构
我们划定信任边界，针对设计进行威胁建模，并确定身份、网络分段、加密与租户模型。产出是一组可以追溯到具体威胁的安全需求。
- 03
把控制措施构建进代码与基础设施
认证、授权、输入校验、密钥处理与审计日志被实现为共享且经过测试的组件。云防护栏与最小权限角色则以基础设施代码的形式编写。
- 04
在流水线中自动化验证
静态分析、依赖与容器扫描、密钥检测与策略检查在每一次变更时运行，并采用商定的阻断阈值。由威胁模型推导出的安全测试用例与功能测试一同运行。
- 05
独立验证
由独立第三方执行的渗透测试安排在一个稳定的构建版本上进行，其范围参考威胁模型确定。发现的问题与其他缺陷进入同一个 backlog，按严重级别设定修复时限并进行复测。
- 06
检测、响应与改进
审计日志与安全遥测数据为检测规则和仪表盘提供输入，事件 runbook 则经过演练。每一次事件或险情都会促成一次不追究个人责任的复盘，以及对设计、代码或流程的一项具体改动。
取舍
决定设计走向的决策
在确定架构之前，我们会与您的团队逐一厘清的问题。
- RBAC、ABAC，还是基于关系的访问控制？
- 当权限跟随岗位职能、并且角色数量保持在可管理的范围内时，使用 RBAC。当决策取决于租户、区域、数据分级或时间等上下文，否则就会导致角色爆炸时，加入 ABAC。当访问权限源自所有权、共享与嵌套群组这类对象关系时，使用 Google Zanzibar 风格的基于关系的模型，配合 OpenFGA 或 SpiceDB 等工具。许多系统用 RBAC 处理粗粒度的权限，再用更细的模型处理资源级的检查。
- 自己构建认证，还是使用身份提供方？
- 几乎在所有情况下，都应使用成熟的身份提供方，或 Keycloak 这样成熟的开源服务器。凭证存储、多因素流程、联邦、账号恢复与会话管理，都很容易在细微之处出错，而且不会带来任何差异化。只自行构建与你的业务领域相关的部分，通常是授权模型，并让它们建立在标准的 OIDC 令牌之上。
- 授权应该在 API 网关处执行，还是在每个服务内部执行？
- 两处都要，但各管各的事。网关是处理认证、令牌校验、限流与粗粒度 scope 检查的合适位置，因为这些在各服务之间是一致的。资源级的决策，例如这个用户能否读取这条记录，需要领域数据，应当放在服务内部，或由服务调用的策略引擎来完成。只依赖网关的做法，在服务被另一条路径访问到的那一刻就会失效。
- 服务网格的双向 TLS，还是仅靠网络策略？
- 网络策略限制哪些 Pod 之间可以通信，但既不认证调用方，也不加密流量。Istio 或 Linkerd 这样的网格增加了工作负载身份、双向 TLS 与按服务的授权，代价是多出需要运维的组件和一定的延迟。当你处理受监管的数据、运行多租户集群，或需要服务之间的零信任保证时，选择网格；对于一个小型、单团队的集群，网络策略就足够了。
- 租户数据应如何隔离：共享 schema、每租户一个 schema，还是每租户一个数据库？
- 共享 schema 加上由行级安全强制执行的租户标识，效率最高，适合大量小租户，前提是强制执行位于数据库之中，而不只是在应用代码里。每租户一个 schema 或一个数据库，能提供更强的隔离、按租户独立的加密密钥以及更简单的数据驻留，但运维成本更高。受监管的租户或大型企业租户往往值得单独设置一个专属层级，而长尾租户仍保留在共享池中。
- 云托管密钥、客户自管密钥，还是专用 HSM？
- 由云厂商托管的加密对大多数数据来说已经足够，而且没有运维负担。云 KMS 中的客户自管密钥增加了对轮换、访问策略与吊销的控制，通常是受监管数据的预期做法。当某项标准强制要求单租户且经过验证的硬件，或密钥用于签署高价值交易时，才有理由使用专用 HSM；它会带来必须事先规划的可用性与运维责任。
生产就绪
怎样才算生产就绪
如何保障安全
每一个请求都经过认证，授权在资源处强制执行，凭证时效短且只限于单一用途。数据在传输中和静态存储时均加密，管理访问采用即时授权并留有记录，网络路径与权限一律默认拒绝。
如何扩展
安全控制措施被设计为能够随系统一同扩展：令牌校验是无状态的，策略决策以较短的有效期缓存，限流是分布式的。共享库与平台级防护栏意味着新增一个服务时，不需要重新实现它的安全机制。
如何监控
审计日志为每一个与安全相关的事件记录操作者、操作、资源、结果与来源，并存放在产生这些日志的系统无法篡改的位置。由威胁模型推导出的检测规则，会对异常认证、权限变更、数据访问模式与策略违规发出告警。
如何部署
变更在发布之前要通过自动化安全检查与策略关卡，制品经过签名并在准入时验证，基础设施权限只能通过经过评审的代码来变更。紧急补丁走同一条流水线上的加急通道，这样速度不会以省掉验证为代价。
如何集成
系统通过 OIDC 与 SAML 与企业身份提供方联邦，把日志转发到组织的 SIEM，并向治理与合规工具提供证据。第三方与合作方的集成逐一认证、收窄权限范围，并作为不可信输入加以监控。
技术
根据工作负载和您现有的技术资产来选择。
- OAuth 2.0 and OpenID Connect
- Keycloak
- HashiCorp Vault
- AWS KMS
- Open Policy Agent
- OWASP ZAP
- Semgrep
- Trivy
- Falco
- Istio
- SPIFFE and SPIRE
- Cloudflare WAF
- Wazuh
- Elastic Security
从零到生产
工程生命周期
- 01
想法
- 02
探索
- 03
系统架构
- 04
UX / 产品设计
- 05
应用工程
- 06
AI / 数据层
- 07
云基础设施
- 08
安全
- 09
质量保证与性能
- 10
部署
- 11
可观测性
- 12
持续演进
常见问题
常见问题
Starone 是认证机构或审计公司吗？
不是。我们是一家工程公司。我们设计并构建具备 ISO 27001、SOC 2 与 PCI DSS 等框架所期望的控制措施与证据的系统，并与组织所委任的、具备资质的审计师和评估机构协同工作。认证与鉴证的决定权属于这些机构。
你们执行渗透测试吗？
我们把渗透测试整合进交付过程：依据威胁模型界定范围，准备环境，对发现的问题进行分级研判，并以工程手段完成修复。出于独立性的考虑，测试本身最好由一家与系统构建团队相互独立的专业机构来执行，我们会与组织选定的测试方协调配合。
安全应该在项目的什么阶段介入？
在架构阶段。对安全影响最大的那些决策，包括信任边界、身份、租户模型与数据放置，都是在这个阶段做出的，事后推翻的代价很高。更晚介入仍然有价值，但可选的方案就只剩下补偿性控制了。
你们能提升一个已经在生产环境中运行的系统的安全性吗？
可以。我们从架构与威胁评审入手，找出结构性风险，然后按可利用性与影响程度安排整改顺序。早期的典型工作是凭证与密钥的规范治理、授权缺口、网络暴露面以及缺失的审计日志，随后才是对身份与分段更深层的改造。
你们如何保护 AI 功能与 LLM 集成的安全？
把模型的输入与输出都视为不可信。我们限制模型能够触及的工具与数据，在模型之外强制执行授权，在输出触发动作之前对其进行过滤与校验，并记录交互以供审查。提示注入被当作一项需要加以遏制的架构风险来处理，因为它无法靠过滤可靠地消除。