tonghuaroot 2025-02-21 08:45 北京
摘要
安全平台工程团队通过构建默认安全的工具链与协作机制，将安全能力无缝融入企业安全建设核心流程中，在降低员工认知负担的同时，规模化解决商业安全产品无法解决的独特安全风险。
要点总结
团队定位：安全平台工程团队聚焦于解决企业特有的安全挑战，优先开发无现成解决方案的定制化工具，而非重复构建通用型商品化产品。
核心任务：构建默认安全的系统框架，并通过与工程团队协作，将安全能力嵌入开发工具、内部访问、客户支持等高风险场景。
发展路径：需评估组织独特需求与资源能力，避免单角色兼任开发与安全的低效模式，优先采用专业化团队并适配企业技术栈。
组建时机：当安全团队规模接近 30 人且面临复杂定制化需求时，建议配置专职工程经理、软件工程师及产品经理，形成可持续迭代的技术闭环。
价值取舍：在供应商方案成熟时主动切换，将资源转向新兴领域，平衡短期防护与长期技术前瞻性。
前言
前Netflix首席信息安全官Jason Chan提出，将安全性融入现有流程中，称为secure paved roads。其核心理念是，安全应该尽可能地不被用户感知。普通员工不应对高风险的安全领域过于担忧，他们只需使用那些有良好用户体验的工具集，而这些工具默认就具备安全性。当然，他们可以偏离这条铺好的道路，但通常会体验得更糟。我们的目标是让95%的人都留在这条铺好的路上，只有在面对特殊需求或障碍时，才会有人员偏离这条安全路径。
在过去五年中，越来越多的安全工程师和专门团队开始开发这类工具以解决相关问题。
在这篇文章中，我们主要讨论如下4个话题：
什么是安全平台工程团队？
他们的工作内容是什么？
如何发展这一职能？
何时应该组建团队？
为什么要建立安全平台工程团队？
你的组织很可能会面临两类安全问题。一类是特有的公司问题，另一类是可以作为商品出售的问题。
一个典型的例子是员工单点登录（SSO），这是一个商品（即市面上可以购买的成熟解决方案）；很少有公司会自行构建单点登录平台。大多数公司选择使用Okta、Microsoft和Ping Identity等供应商。在这一关键的可用性和安全性问题上，人人都不应再去重新发明轮子。如果没有非常独特的情况，几乎没有公司应该将资源投入到构建SSO平台上，而应该专注于能够带来收入的产品功能。
另一方面，你可能会面临一些无法轻易商品化的内部定制问题。在许多软件公司中，客户支持工具是一个典型的例子，这些工具帮助工程师与客户实例进行交互。这些工具需要安全且易用，但这并不是供应商能够轻易解决的问题，因为它们确实是独特于你的产品。
一般来说，你应该将精力集中在没有现成解决方案的问题上。当然，也有一些例外情况，例如：
你能以低于供应商报价的价格自行构建。
对于供应商的安全态度存在问题，希望将其保留在内部。
唯一的供应商是你不想给钱的竞争对手。
避免供应商锁定，因为你认为他们会提高价格或不再开发你所需的未来功能。
提供的解决方案无法满足你的规模需求。
他们解决什么问题？
安全平台工程团队专注于解决上述问题。他们的任务主要有两个：
构建新工具和服务以扩展安全性。
与其他工程团队合作，构建默认安全的系统。
我曾在Shopify领导多个平台工程团队，并与行业内的一些团队进行了交流。在各个行业和领域，通常会出现一些共同的主题：
内部访问： 身份和访问管理（IAM）、特权访问管理（PAM）、零信任等领域，尽管供应商正在快速改善，但这一直是这些团队过去几年的共同任务。
开发工具： 确保开发人员构建安全的服务，通常表现为加密服务、密钥管理、身份验证等。
客户支持： 超越标准帮助台的客户支持工具在每个软件公司中都通常是独特的。这也是风险最高的领域之一，因为客户支持每天都直接与未知实体互动。
扩展安全性： 漏洞管理、安全审查、风险评估等。这个团队可以构建工具，帮助安全团队在不增加人员的情况下实现扩展。
每个安全平台工程团队都应明白，偶尔需要放弃某些项目是必要的。我愿意分享一个来自我过去的明确案例。在Shopify，我们构建了一个零信任解决方案，该方案检查设备状态，并在未从受管理的安全设备访问应用程序时拒绝访问。这在几年内运行良好，但最终供应商赶上并超越了我们的解决方案。现实是，我们只有少数几名工程师，而安全供应商则有数百名，因此我们始终知道最终会替换掉其中的某些组件。
安全平台工程团队的宗旨是解决独特的问题。如果这些问题不再独特，团队应毫不犹豫地切换到供应商。这样并不算浪费；你在那段时间内保护了公司，现在可以专注于一些新而令人兴奋的事情。
这正是我喜欢这个领域的原因之一：你一直在进行安全研究和开发的前沿工作。
如何发展这一职能
在评估安全开发职能时，你需要问自己两个问题：
你的组织是否有无法通过现成工具解决的独特需求？
你是否有足够大的团队，可以在不立即产生价值的情况下，投入大量时间进行战略性投资？
如果两个问题的答案都是“是”，那么你可以直接请求增加人员，从第一天起就尝试组建这一职能，这正是Atlassian团队的做法。
如果第一个问题的答案是“是”，但第二个问题的答案是“否”，那么你可以选择雇用一名软件工程师，或者让安全工程师将其作为职责的一部分来处理。不过，我不建议这种长期的做法。这可能是检验这一职能是否适合你的组织的好方法，但还有更有效的操作方式。
如果你雇用安全工程师，你希望他们专注于解决安全问题，而不是在开发和安全工程师的角色之间产生冲突。这样的安排可能在短期内奏效，但也有一些缺点，包括：
工程师的职业倦怠。如果你是某个关键Tier-0服务的唯一负责人，轮休就会变得困难。
缺乏成长，因为没有人可以学习或讨论想法。
上下文切换导致在两个领域的进展缓慢。
如果那个人离开，就没有冗余，寻找另一个独特人才填补空缺并不是可持续的做法。
将工作交接给专门的工程团队可能会很困难。工程团队通常不乐意接手由单一人员创建的服务，因为他们可能不得不在项目推进时妥协。
我过去曾因资源不足而不得不使用这种模式，我的经验是，这种做法行之有效，直到它不再有效。要小心大型企业项目的处理，避免工程师倦怠、离开，最后没有人愿意接手他们留下的工作。这种工作往往会被抛弃，因此更好的是让工程师处理更有持久性的项目。
这个组织还应遵循公司的工程流程。许多安全工程师通常会使用Python或Go；如果你是一个基于Java或C#的公司，你希望安全平台工程团队使用相同的语言、框架和方法来构建软件。不要成为那个在Java公司中使用Rust构建所有内容的团队。
何时创建团队
大多数安全团队规模较小，通常只有少数几个人，实际规模因行业而异。安全团队的规模可以从一个人到一些最大的公司数千人不等。关于团队的构成，你几乎肯定会在构建任何其他功能之前，先招聘应用安全、检测与响应、治理、风险与合规（GRC）和IT安全职能。
超出这一规模的组织必须认真考虑如何在确保安全的前提下扩展运营，以应对日益复杂的安全挑战。认为安全团队会继续膨胀至不切实际，手动逐个处理任务是不合理的。相反，我们需要某种方式来为大众构建安全性。安全开发团队可以通过创建平台，减少整个组织的安全问题，从而减轻安全团队的整体负担。这意味着当公司增长时，该团队的效益将会提升，与其他安全团队不同。我的建议是，如果你的安全团队接近30人，并且面临独特问题需要通过自定义代码解决，同时至少有三个人的hc（一个工程经理和两个工程师），那么你应该考虑组建一个专门团队。这将为你提供启动所需的最低配置。
一个真正有效的安全开发职能应由一名工程经理、多个软件工程师（前端和后端）以及理想情况下的产品经理组成。你可能还会有专注于不同元素的专家，比如专注于AI问题的AI工程师。这些专家当然也可以是专门的安全工程师，而你会发现这些团队中有不少是从安全工程师转型为开发者的人。这个团队应能够管理Tier-0服务，具备oncall功能，并且主要像其他软件工程团队一样运作，而不仅仅是安全团队。最重要的是，他们大部分的时间都是花在研发上。这个团队的核心价值在于专注，而不是在安全、开发和其他任务之间频繁切换。
总结
最近，从我的调查结果来看，许多安全团队中的安全工程师还从事开发工作来解决此类问题，也有一些参与调查的安全团队有资源专门组建团队，但选择了不这样做。我鼓励安全工程师进行探索和构建，但我建议他们专注于成为非实全职的研发人员。他们可以构建有趣的工具来帮助解决问题，但应避免涉及任何可能变成企业级的内容，或可能阻碍产品的事情。例如，DFIR分析师应专注于构建帮助其团队的工具，而不是整个公司。
安全平台工程团队是帮助在整个组织中扩展安全的绝佳选择，但它们仍将是仅供大型企业使用的细分领域。然而，我鼓励较小的组织考虑这方面；如果你的安全团队超过30人并且面临我们讨论过的独特问题，那么就可以开始考虑未来的人员配置。
事实上，将安全防护措施嵌入到增加用户体验的工具集中更为有效。另一个选择是进行手动安全审查或让人们遵循设定的流程。这些都有其存在的价值，其有效性取决于你试图解决的问题及所需的修复成本，但这类企业级问题几乎总是更适合通过用户喜爱的专门解决方案来解决。应采用激励措施而非惩罚手段。
以上内容编译自 Kane Narraway
关于 安全村
安全村始终致力于为安全人服务，通过博客、文集、专刊、沙龙等形态，交流最新的技术和资讯，增强互动与合作，与行业人员共同建设协同生态。
投稿邮箱：info@sec-un.org
