来自另一侧的调度：从脚本到软件

Source: Dev.to

Introduction

在我作为安全工程师职业生涯的起步阶段，我为安全运营中心（SOC）内的 Web 网关构建了一个白名单管理系统。它不仅仅是一个简单的脚本，而是一个核心安全组件依赖的实时系统。一次失误——把 /3 当成 /32 IP 段进行阻断——导致所有 40,000 名员工的三分之一互联网访问被切断。此事件让我清楚地认识到，我创建的系统必须防止此类灾难性错误。

SOC 分析员经理、我的上司以及我之间的定期讨论，凸显了我的代码对他人工作的影响。这是我第一次感受到对软件本身负责，而不仅仅是自动化脚本。

Crossing Over: From Security to Platform Engineering

本系列分享我从安全工程转向平台工程过程中学到的经验。我会告诉过去的自己该怎么做，以及现在我如何以软件与平台工程师的视角来解决问题。

• 面向安全从业者： 一瞥另一端的工作内容。
• 面向与安全团队合作的开发者： 揭示我们思考方式的背后原因。

Managing Growing Vulnerabilities

在安全组织内部，我注意到漏洞数量的增长速度超过了我们能够修复的速度，即使我们频繁打补丁。随着云平台的出现，配置错误的发现进一步增加了负担。为避免再次出现同样的结果，我改变了方法。

Preventative Platform Controls

我没有继续创建更多的发现来追踪，而是确定了所有相关方都能接受的平台控制。公共 S3 桶是数据泄露的常见来源，于是我实现了一项预防性控制，直接禁止公共桶的存在。这一措施消除了开发团队和漏洞管理团队面临的此类问题。

Collaboration and Rollbacks

安全团队并不拥有并运营企业中的每一个系统，但与单一平台或基础设施团队合作——而不是 50‑100 个团队——可以大幅缩短修复时间。偶尔我们需要回滚某项控制，因为它对某团队的系统运营产生了负面影响。

• Lesson: 渐进式发布是必不可少的，这在软件工程中已经是常见实践。
• Policy‑as‑Code: 让我们能够在几分钟内恢复到旧的策略版本。

Transferable Skillsets

许多安全技能的可迁移性超出预期：

• Security reviews 为我参与系统设计讨论和运维故障排查奠定了基础。
• Incident response 经验——追踪攻击者的足迹——帮助我通过拼接日志和追踪的时间线来调试实时系统。

Building Effective Controls

我构建的最有效控制源自对开发团队工作方式的理解，以及寻找在不增加摩擦的前提下消除风险的方法。并非每个人都必须成为软件工程师，但掌握核心概念和工作方式能够让我们提出既不拖慢团队又能解决问题的方案。

Next Topic

在下一篇文章中，我们将探讨 CI/CD，以及如何在有效控制、默认设置和例外之间取得平衡。