4.1 安全基础与文化

概述与动机

安全不是在最后阶段附加上去的一项功能，也不是独立于工程之外、由某个专职团队承担的工作。在大型组织中，安全是整个系统被设计、构建、运营和治理方式的一种属性。当数千名工程师在数百项服务中交付代码时，最薄弱的环节决定了一次事件能造成多大的破坏。一个配置错误的存储桶、一个未打补丁的依赖项，或者一个权限过大的服务账号，都可能暴露数百万条记录。基础与文化，正是防止这种情况在大规模场景下发生的关键。

对企业而言，风险是财务和声誉层面的：数据泄露成本、监管罚款、客户流失，以及估值下滑。对政府而言，风险还延伸到国家安全、公众信任，以及基本服务的连续性。这两种场景都面对一个严酷的事实：你无法仅靠控制措施和关卡来强制推行安全。它必须被实际做这项工作的人内化。一种让工程师理解威胁、感受到主人翁意识，并因提出担忧而受到鼓励的文化，其产生的结果，会远远好于依赖一个疲于奔命、扮演守门员角色的安全团队。

本章阐述了支撑本指南其他每一个安全章节的思维模型和文化实践。内容涵盖：使安全成为每个人的职责、威胁建模、安全开发生命周期、诸如纵深防御和零信任之类的基础架构原则，以及如何按真实风险而不是恐惧或潮流来排定安全工作的优先级。

另见： 第 4.2 章（应用安全）、第 4.3 章（基础设施与云安全）、第 4.4 章（安全运营），以及第 4.6 章（合规与治理），均建立在这些基础之上。

关键原则

安全是每个人的职责。 每一位工程师、产品经理和运维人员，都对自己所构建之物的安全负有责任。安全团队负责赋能、提供建议和审计；它不会、也不可能独自完成这项工作。
假设已被攻破。 按照攻击者已经在内部的假设来设计。最小化一个被攻破的组件所能触及的范围。
纵深防御。 没有任何单一控制措施是充分的。分层部署相互独立的控制措施，使一项失效不会意味着全盘失效。
最小权限。 只授予所需的最小访问权限，持续最短的必要时间，并在不再需要时自动撤销。
左移。 尽可能早地发现并修复问题，此时的修复成本最低。
基于风险的优先级排定。 把精力用在可能性与影响力结合起来最高的地方，以 CIA 三元组（机密性、完整性和可用性）为指引，而不是用在本周新闻上热搜的那个话题上。
无责学习。 把安全事件和未遂事件当作学习机会，而不是惩罚的场合。

建议

建立安全倡导者计划

在每个工程团队中安插一名指定的安全倡导者（security champion）。倡导者不是全职的安全专家。他们是接受过额外培训、并与中央安全团队保持直接联系的工程师。他们评审设计、对发现的问题进行分诊、回答队友的问题，并把安全方面的考量带入规划过程。这样就能在不为每个团队都招聘一名专家的情况下，把安全专长扩展到整个组织，而且由于建议来自真正了解代码库的同行，也更能建立信任。

给倡导者提供真正的支持：一个定期分享所学的论坛、用于培训和参会的预算、在绩效评审中给予认可，以及从他们的交付承诺中专门划出的时间。一个只存在于纸面上的倡导者计划产生不了任何效果。

定期开展威胁建模

威胁建模是在构建之前，有纪律地反复追问”什么可能出错”的习惯。要针对新服务、重大功能，以及任何涉及信任边界的变更来做这件事。保持它足够轻量，使其真正能够频繁进行。

STRIDE 是一份对应安全属性的实用清单：欺骗（认证）、篡改（完整性）、抵赖（不可抵赖性）、信息泄露（机密性）、拒绝服务（可用性），以及权限提升（授权）。逐一走查每条数据流，问一问每个类别如何适用。
PASTA（攻击模拟与威胁分析流程）是一种更重量级、以风险为中心的七阶段方法，把技术威胁与业务影响联系起来；应把它用于高价值系统。
攻击树 把一个目标（“窃取客户数据”）分解成攻击者会采取的分支步骤，帮助你发现并剪除攻击路径。

把威胁模型当作与代码放在一起的活文档，并在架构发生变化时重新审视它们。

构建安全的软件开发生命周期

把安全编织进每一个阶段，而不是把它当作最后一道关卡：

需求： 与功能性需求一起捕捉安全和隐私需求。
设计： 威胁建模并评审信任边界。
实现： 强制执行安全编码标准、代码评审，以及提交前的密钥扫描。
测试： 在流水线中运行 SAST（静态应用安全测试）、DAST（动态应用安全测试），以及依赖项扫描（见第 4.4 章）。
发布： 验证来源、对工件签名，并检查配置。
运营： 监控、打补丁并响应。

左移的意义并不在于把所有工作都堆到更早的阶段、压垮工程师，而在于捕获那些越早修复越便宜的缺陷类型。

采用零信任架构原则

传统的边界安全假设网络内部的一切都是可信的。这一假设在攻击者一旦获得立足点的那一刻就会失效。零信任用显式的、持续的验证取代了隐性的网络信任：无论请求来自网络中的哪个位置，都要基于身份、设备状态和上下文对其进行认证和授权。把强身份、最小权限授权、微分段和无处不在的加密结合起来。零信任是一段旅程，不是一款产品，因此应一步一步地推进。

使用 CIA 三元组按风险排定优先级

围绕机密性、完整性和可用性来构建每一项资产和控制措施。并非所有数据都需要相同程度的保护：一个公开的营销页面和一个健康记录数据库，对机密性的需求截然不同。对你的资产进行分类，估算被攻破的可能性和影响，并把稀缺的安全精力集中在风险最高的组合上。把你的风险决策记录下来，以便日后他人能够评审并为其辩护。

权衡：优点与缺点

方式	优点	缺点
由中央安全团队拥有全部安全职责	专业深厚，标准一致	成为瓶颈，工程师脱离参与，难以规模化
分布式安全（倡导者）	可规模化，建立主人翁意识，反馈更快	需要投入，技能参差不齐，需要协调
对一切都进行重量级的前期威胁建模	全面，能发现设计缺陷	拖慢交付，可能沦为打勾走过场
轻量、以风险为目标的威胁建模	快速，聚焦真正重要之处	可能遗漏”低风险”系统中的威胁
阻断发布的严格关卡	强制推行合规	产生摩擦，诱发绕行行为

核心张力存在于速度与保障之间。若过度偏向关卡和中央控制，就会产生摩擦，工程师会绕过它，滋生影子 IT 和怨恨情绪。若过度偏向自主而不加支持，就会得到不一致、未经审计的安全状况。可持续的答案，是一种带有赋能型护栏的强文化：能自动化的地方就自动化，需要判断力的地方交给人，并且始终是被解释清楚的，而不仅仅是被强加的。

与团队讨论的问题

你的哪些系统值得进行重量级的威胁建模？由谁来决定分级？ 在一个庞大的资产体系中，你不可能对每一项服务都运行一次七阶段的 PASTA 分析，因此你需要一条明确的规则，说明什么时候一次 30 分钟的 STRIDE 走查就够了，什么时候一个高价值系统值得进行深入的、以业务影响为导向的建模。把这个决定锚定在你的 CIA 分类上：持有受监管记录、支付流程或认证逻辑的系统位于顶层，而一个公开的营销页面则不在此列。在企业和政府工作中，审计人员会要求你为某个系统为何以某种方式被建模而辩护，因此要把分级标准写下来，并指定执行它们的负责人。把你当前的资产分类和一份没有威胁模型的服务清单带到会议上，因为两者之间的差距正是你真正的风险所在。如果你们无法就这条标准达成一致，你们就会默认要么对一切都做轻量建模，要么什么都不深入建模，而这两种情况都会让你们失望。
当一名安全倡导者与交付截止日期发生冲突时，谁真正有权叫停发布？ 只有当倡导者拥有真正的权威（）而不仅仅是额外的培训和良好的意图（）倡导者计划才能改变结果。要提前决定：一名倡导者能否叫停发布？他们会升级给中央应用安全团队吗？什么严重程度的发现足以证明暂停交付是合理的，什么程度只需要跟踪记录？这一点在压力之下最为重要（）当一位产品经理想在发布前一周豁免某个设计缺陷时，而这恰恰是未处理的缺陷代价最高昂的时刻。带上一个近期的例子，说明某次安全担忧与截止日期相遇时，是谁做出了决定、又是如何决定的，因为这个故事揭示了你真正的升级路径。如果诚实的答案是交付永远获胜，那么你的倡导者只是装饰品，你应该先修复这个激励机制，再增加更多的倡导者。
“假设已被攻破”在你下一次设计评审中具体会改变什么？ 这项原则容易点头认同，却难以真正落地，因此应把它钉在具体的承诺上：你将收紧哪些信任边界，在哪里增加微分段，以及你将如何缩小一个被攻破的单一服务账号所能触及的范围。对大型团队而言，回报是波及半径的缩小，使一个攻陷了某项服务的攻击者无法横向渗透到其背后的数据存储。在企业和政府场景中，这也塑造着你在最小权限和短期凭证方面的决策（）这些在设计阶段成本很低，事后改造却十分痛苦。带上一份真实的服务图，问一问攻击者在拿下 Web 层之后会做什么，然后承诺在本季度落实两项遏制改动。对”攻破会发生”这句话的含糊认同毫无价值，除非它真正改变了某项权限、某条网络规则，或某个凭证的生命周期。
你如何知道你的安全文化是否真正在改善？你会向董事会捍卫哪一项指标？ 培训完成率和工单数量容易收集，却几乎毫无用处，因为它们衡量的是活动量，而不是风险的降低，而大型组织会被这些数据淹没。选择你真正愿意押上预算的结果性指标：高严重度发现的修复中位时间、拥有最新威胁模型的服务占比、在进入生产环境之前被拦截的事件比例，以及自我报告的未遂事件比率（）随着信任的增长，这个比率应当上升而不是下降。相互制约的考量在于，任何好的指标都可能被操纵，因此要为每一个指标配一个反向指标，并审视趋势而不是某一时刻的快照。带上你当前的仪表盘，问一问如果安全状况真的变糟了，哪些数字会发生变化；任何不会变化的数字都只是装饰。在企业和政府场景中，监管机构或审计委员会会要求提供控制措施确实有效的证据，因此要选择那些能经得起审视的指标，而不是仅仅看起来是绿色的指标。
下一次工程师报告失误时，实际会发生什么？你们的流程在实践中是无责的，还是只体现在幻灯片上？ 无责学习是被最常挂在嘴边、却最少被真正践行的原则，因为第一次严重事件才是真正检验领导层是否当真的时刻。要提前决定：如何把修复问题的问责，与因造成问题而受到的惩罚区分开来，以及由谁来主持事件复盘，使其聚焦于失效的系统，而不是指名道姓的个人。这种张力是真实存在的：利益相关方希望有人为此负责，然而惩罚举报者，只会保证下一次失误会被隐藏，直到它演变成一次数据泄露。带上你最近两次事件复盘，检查它们究竟是在指责某个人，还是在指责某个控制措施，以及那位拉响警报的工程师是被感谢了，还是被悄悄边缘化了。对政府和受监管的企业而言，强制性的泄露披露规则进一步提高了风险，因为一种隐藏失误的文化，也会错过那些附带法律处罚的报告截止日期。
你的左移工具所带来的摩擦由谁负责？你们是在购买它、构建它，还是被它淹没了？ 自动化的静态和动态分析、依赖项扫描和密钥扫描，是安全开发生命周期的支柱，但一条用大量误报淹没工程师的流水线，只会教会他们忽视安全输出，这比根本不扫描还糟糕。要决定谁来调优这些工具、谁来对发现的问题进行分诊，以及你们是购买一个集成平台，还是自行组装一堆之后不得不自己维护的开源扫描器。相互制约的考量是覆盖面与噪音之间的取舍，以及控制力与成本之间的取舍：一个动辄误报的廉价扫描器，会烧掉倡导者计划花费数年才建立起来的信任。带上你当前的误报率、工程师等待一次阻断性检查的平均时间，以及那些悄悄禁用了某道关卡的团队清单。在大型企业和政府场景中，还要加上采购和工具泛滥这个角度，因为十个团队各自购买自己的扫描器，会产生一种没有任何审计人员能够协调一致的不一致覆盖面。

行业视角

初创企业。 没有安全团队，跑道也很短，文化是你唯一负担得起的控制手段。在任何涉及认证或支付的功能之前，养成一个 30 分钟白板威胁建模的习惯，在所有地方开启最小权限和多因素认证（MFA），因为它们不花一分钱，并维护一个无责的渠道，让任何人都能提出担忧。跳过重量级的流程和工具；创始工程师维护不了它们，而你现在建立的这份纪律，正是日后让企业买家信任你的关键。

小型企业。 你没有专职的安全专家，预算也很紧张，因此应依靠你已经购买的工具所自带的安全默认设置，而不是自行搭建流水线。优先选择能为你强制执行多因素认证、打补丁和最小权限的托管平台，并把安全当作一个数据卫生问题来对待：清楚知道你持有哪些敏感数据、谁能够访问它们。当你必须在自建和购买之间做选择时，选购买，因为一个你能保持更新的托管控制措施，胜过一个你放任其腐烂的定制方案。

企业。 在数百项服务、数千名工程师的规模上，挑战在于跨众多团队的一致性和治理。运行一个安全倡导者计划，把与 CIA 分类挂钩的威胁建模分级标准化，并提供铺好的标准化模板和自动化流水线检查，使每个团队都能继承良好的默认设置。对照基准跟踪修复和覆盖率指标，并保留一份审计记录，说明每个系统为何以某种方式被建模和控制。

政府。 采购法规、透明度义务和公共问责制塑造着每一个选择。零信任原则和短期凭证往往由行政政策强制要求，你必须能够向审计人员展示一份文档记录、基于风险的理由，说明加固预算花在了哪里。优先保护持有最敏感公民记录的系统，在公众有知情权的地方公开相关防护措施，并要求供应商披露其局限性，而不是接受不透明的黑箱。

示例

初创企业。 一家十人的初创企业没有安全团队，也没有为此设立预算，因此两位创始工程师养成了一个习惯：在任何涉及认证或支付的功能之前，进行一次 30 分钟的白板威胁建模，问一问什么可能出错、谁会想要它出错。他们采纳了几个不花钱的基础性习惯：每个云端角色都实行最小权限，每个账号都开启多因素认证，并维护一个无责的渠道，让任何人都能在不担心被责怪的情况下提出担忧。当他们后来进行一轮融资、企业买家询问他们如何处理安全问题时，这种早期建立的文化让他们能够诚实地回答，而不是临时手忙脚乱地编造一个答案。

企业。 一家拥有 6000 名工程师的全球性银行运行着一个安全倡导者计划，每个分队配备一名受过培训的倡导者。倡导者参加每月的公会活动、完成季度培训，并使用 STRIDE 为每一项新服务主持威胁建模。中央应用安全团队维护着铺好的标准化模板和自动化流水线检查。两年间，高严重度发现的修复中位时间从 45 天降到了 9 天，设计阶段的威胁建模在一个支付 API 到达生产环境之前，发现了其中的一个授权缺陷，避免了一次很可能需要上报的事件。

政府。 一家正在对旧有系统进行现代化改造的国家税务机关，采纳了由行政政策强制要求的零信任原则。每一次内部服务调用都通过短期凭证进行认证，并按请求逐一授权；网络分段不再自动赋予信任。该机构针对每一项面向公民的服务，围绕”窃取纳税人记录”和”篡改一份申报”这两个根节点建立攻击树进行威胁建模。与 CIA 影响等级对齐的基于风险的优先级排定，把加固预算优先集中在持有最敏感记录的系统上。

商业论证：动机、投资回报率与总拥有成本

构建安全文化的成本是真实存在的：倡导者的时间、培训、工具，以及开展威胁建模和评审所带来的些许拖累。但与不这样做的代价相比，这份成本是微不足道的。一旦把调查、通知、修复、监管罚款、法律风险敞口和业务损失都计算在内，一次重大数据泄露的平均成本可达数百万美元。政府场景中的泄露事件，还会额外带来使命中断和公众信任的侵蚀，这是任何账单都无法完全体现的。

安全投资的回报来自三个方面：避免的事件（永远不会发生的那次泄露）、降低的修复成本（在设计阶段修复的缺陷，其成本只是在生产环境中修复的一小部分），以及更快的交付（铺好的标准化道路和自动化检查让团队能够放心交付，而不必等待人工评审）。在向领导层论证时，应把安全构建为一种带有价格标签的风险管理，而不是一种抽象的好事。展示排名靠前的风险的预期损失（可能性乘以影响），降低这些风险的成本，以及依然残留的风险。高管们愿意为他们能够衡量的风险降低买单。

反模式与陷阱

安全剧场。 看起来令人印象深刻、却不降低任何真实风险的控制措施，为满足一次审计而采纳，而不是为了保护任何东西。
把安全团队当作最后的一道关卡。 在发布前一周才发现设计缺陷，此时修复成本最高，也最有可能被豁免放行。
责怪文化。 惩罚报告失误的工程师，只会保证下一次失误被隐藏起来。
打勾式威胁建模。 填一份没人会读的模板，产出的文档与真实架构脱节。
一刀切的控制措施。 对一个公开网站和一个支付系统套用同样重量级的流程，浪费精力并滋生怨恨情绪。
恐惧驱动的优先级排定。 追逐新闻上正在热议的任何漏洞，而不是真正威胁到你资产的东西。
名义上的倡导者。 任命了倡导者，却不给他们时间、培训或权威。

成熟度模型

第一级，启动： 安全是被动响应式的，且高度集中。评审即便发生也为时已晚，并且没有威胁建模。事件驱动临时性的修复。工程师把安全视为别人的问题，也不存在共享标准。

第二级，发展： 存在一个安全团队并制定标准，但各团队的实践并不一致。一些重大项目会做威胁建模，另一些则不做。有基础培训可供选用。安全仍被视为一道关卡，左移只是一种愿景，而非现实。

第三级，标准化： 安全倡导者被嵌入到每一个团队中。威胁建模对新服务而言是常规操作，按 CIA 分类分级，安全开发生命周期在全组织范围内被文档化并强制执行。基于风险的优先级排定指导着工作，安全编码标准和流水线检查是默认的标准化道路，无责的事件后复盘是常态。

第四级，管理： 安全成果被对照基准进行衡量和控制。组织按团队跟踪高严重度发现的修复中位时间、威胁模型覆盖率、在进入生产环境之前被拦截的事件比例，以及未遂事件报告率。倡导者叫停发布的权威被明确定义，并真正被行使。风险决策被量化为可能性乘以影响，被记录下来，并按固定节奏被评审，因此控制缺口是作为数据浮现的，而不是作为意外浮现的。

第五级，编排： 安全真正成为每个人的职责，并与交付、风险和业务规划整合在一起。威胁建模和安全设计已成为习惯，且十分轻量，零信任原则已基本实现。指标驱动持续改进，组织从各团队的未遂事件中汲取教训，控制措施随着威胁态势和架构的变化而自动调整。

讨论议题

除了统计培训完成率之外，你如何衡量一种安全文化是否真正在改善？
安全倡导者所处理的事务与中央团队所拥有的职责之间，正确的边界应该划在哪里？
如何在不让威胁建模沦为官僚式打勾的情况下，保持它的价值？
一个完整的零信任架构对你的旧有资产体系而言现实吗？如果不现实，务实的子集是什么？
当安全工作和功能交付争夺同样的工程师时，应该如何排定安全工作的优先级？
什么样的激励机制才能真正改变工程师对安全所有权的行为？

关键要点

安全是大型组织的一种文化属性，而不是委托给某一个团队的任务。
安全倡导者把专业能力和主人翁意识扩展到整个工程组织。
威胁建模（STRIDE、PASTA、攻击树）能早期、低成本地暴露设计缺陷。
安全的软件开发生命周期和左移思维，能在缺陷成本最低的时候捕获它们。
纵深防御、最小权限和零信任是基础性的架构原则。
CIA 三元组和基于风险的优先级排定，把稀缺的精力引向真正重要的地方。
构建安全文化的成本，远小于它所预防的数据泄露事件的成本。

参考文献与延伸阅读

Adam Shostack, Threat Modeling: Designing for Security
Ross Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems
Michael Howard and Steve Lipner, The Security Development Lifecycle
Betsy Beyer et al. (Google), Building Secure and Reliable Systems
National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
National Institute of Standards and Technology, Secure Software Development Framework (SSDF), SP 800-218
OWASP, Threat Modeling and Security Champions guidance