云环境中数据窃取方面的挑战
云计算革命彻底改变了应用程序的开发与部署方式。然而，传统的网络安全模式（即“城堡与护城河”方式）在云原生架构中就显得力不从心了。在云环境中，资源是分布式的、短暂的，并且可以从任何地方进行访问。
对于迁移到公有云的企业来说，通过内部威胁、凭据盗取和服务配置错误所导致的数据窃取已成为一个重要的问题。行业报告显示，涉及云配置错误的数据泄露事件，每次给组织造成的平均损失为 445 万美元。在金融服务、医疗保健和受监管的行业，客户数据保护不仅仅是安全问题，更是合规性和法律的强制要求。
虽然本文主要关注 Google Cloud Platform 的 VPC Service Controls (VPC-SC)，但其原则、挑战和最佳实践广泛适用于各大云服务商。
AWS 通过 VPC Endpoints 和 Service Control Policies 提供了类似的功能，而 Azure 则提供了 Service Endpoints 和 Private Link。虽然实现细节不同，但防止数据窃取的战略方法（全面发现、分阶段推出、组织协调和分层安全）是超越任何特定平台而共通的。
在 Google Cloud Platform 中，VPC-SC在敏感云资源周围创建安全边界，防止未经授权的数据窃取，同时保持云的敏捷性和可扩展性。然而，在企业规模上实施 VPC-SC（跨越数百个项目、多个区域和多样化的应用程序）需要战略级的规划、组织协调，并且要对安全需求和操作限制有着深刻的理解。
本文分享了在大型金融科技组织的 Google Cloud Platform (GCP)环境中实施 VPC-SC 的经验教训，以保护支付处理工作负载、客户数据分析和多区域部署。
本文不会提供分步骤的配置指南，而是分享战略决策、组织挑战和来之不易的经验教训，这些因素决定了安全实施是否能够成功。
深入理解 VPC Service Controls：超越基础的周边安全性
VPC Service Controls 会在 GCP 服务周围创建安全边界，强制执行基于资源位置、身份和网络来源的上下文感知访问策略。与在网络层操作的 VPC 防火墙不同，VPC-SC 在服务 API 层进行操作，无论网络路径如何，都能控制对 Google Cloud Storage、BigQuery、Vertex AI 和 Compute Engine 的访问。
它的三大核心构建块包括：
服务边界 (Service Perimeters)：在受保护的 GCP 项目和资源周围定义逻辑边界。边界内的资源可以自由通信，来自外部的访问则需要通过访问级别或入站/出站策略进行明确授权。
访问级别 (Access Levels)：基于 IP 地址、设备状态、用户身份或地理位置定义访问边界内资源的条件，从而能够超越简单的允许/拒绝规则，实现上下文感知的安全性。
入站和出站策略 (Ingress and Egress Policies)：指定哪些身份可以访问边界内的资源，以及边界内可以访问哪些外部资源。
有一个常见的误解，那就是 VPC-SC 并不会取代网络安全，而是它的补充。实际上，如果 VPC-SC 配置得当，即使攻击者攻陷了 VPC 网络内的虚拟机，也无法将数据窃取到外部云存储桶中，无论网络连接情况如何，API 调用都会被阻止。
另一个关键区别是，VPC-SC 保护的是受支持的 GCP 服务，而不是任意的网络流量。Google Cloud Storage、BigQuery、Compute Engine、Vertex AI、BigTable、GKE 等都能得到保护，但 VPC-SC 并不控制虚拟机的出站互联网流量，也不检查应用程序协议。与虚拟防火墙和 Cloud Armor 的集成对于全面安全性仍然至关重要。
架构图
设计 VPC-SC 架构：重要的战略决策
规划期间所做的关键设计决策决定了实施的成功或失败。
从数据分类开始
并不是所有的数据都需要相同的保护。根据敏感性对数据进行分类，例如需要符合 PCI-DSS 的支付卡数据、受 GDPR（General Data Protection Regulation）或 CCPA（California Consumer Privacy Act）约束的个人身份信息 (personally identifiable information，PII)、机密业务数据和非敏感运营数据。这种分类会驱动边界的规划。高敏感的数据需要严格控制边界，允许的例外情况最少，而较低敏感的数据则允许更宽松的策略。
建议分为三个边界层级：高安全性，用于支付处理，无出站策略；中安全性，用于客户分析，对出站访问受控的服务进行限制； 低安全性，用于开发/测试，策略较为宽松。这种方法在安全严谨性和运营灵活性之间取得了平衡。
彻底映射依赖关系
依赖关系映射不完整是 VPC-SC 实施失败的头号原因。现代云应用程序依赖于共享服务、跨项目通信、CI/CD 流水线、监控工具和第三方集成。在执行之前，必须记录每一个依赖关系。
我们建议使用 Cloud Asset Inventory 进行资源发现，并分析 Cloud Logging 以获取服务到服务之间的通信模式。同时，采访应用程序团队以了解日志中看不到的外部依赖关系。对于大型组织，建议为发现阶段预留四到六周的时间，过于匆忙容易引发生产事故。
服务账户是隐藏的依赖噩梦：在多个项目中共享的某个服务账户会引发意想不到的跨边界依赖关系。在为我所在的组织实施 VPC-SC 期间，我发现了散布在遗留系统、批处理作业和第三方集成中的数十个未记录的服务账户。其中许多可以追溯到多年以前，而维护它们的团队早已离职。每次发现都需要进行仔细评估，以确定该账号的使用是代表合法的业务需求，还是需要补救的安全漏洞。这一经验强化了服务账户发现必须与资源发现需要一样严格的观点，忽略某几个身份标识可能会破坏你的整个边界策略。
边界拓扑：一个大边界还是多个小边界？
应该创建一个大的边界，还是按应用程序、业务部门或数据分类组织的多个较小的边界呢？答案取决于具体的组织结构和安全要求。
多个边界会提供更强的隔离性，某个边界的违规不会危及其他边界。然而，它们增加了复杂性，因为跨边界通信需要显式策略或边界桥接。我发现混合方法效果最好：按安全层级（高/中/低）组织的广泛边界，以及用于共享服务（如集中日志记录、监控和 CI/CD）或多个边界之间入站/出站策略的边界桥接。
对于多区域部署，要避免为每个区域创建单独的边界。区域边界会带来不必要的复杂性，而不会增加额外的安全价值。VPC-SC 策略是全局应用的。建议将所有区域资源包含在单个逻辑边界内，并在需要时使用 IAM 策略或访问级别进行特定于区域的访问控制。
实施：从设计到生产的三个阶段
第一阶段：发现与基线（四到六周）
发现工作不仅仅涉及技术资产盘点，还需要理解团队的工作方式、应用程序的通信模式以及安全漏洞的位置。为此，我组建了一个跨职能的工作组，成员包括安全工程师、基础设施团队、应用程序开发人员和业务利益相关者，我们每周开会，以审查发现结果、解决依赖性问题，并就边界范围达成共识。
技术发现会利用多个来源：Google 的 Cloud Asset Inventory 用于资源发现，Cloud Logging 用于 API 模式，并且要采用团队访谈的方式来获取 GCP 日志无法捕获的上下文。我创建了可视化工具来映射服务的依赖关系，使得识别应该在边界内分组的资源集群变得更容易。
第二阶段：演练模式实施（至少六到八周）
VPC-SC 的演练模式（Dry-run Mode）使安全实施成为可能。在演练模式下，会评估边界策略，违规行为会被记录，但 API 调用不会被阻止。这种方法允许我们在生产环境中测试边界配置，而不会产生服务中断的风险。我的建议是，将初始的边界配置以演练模式部署至少 30 天。
每日分析违规日志，按服务、方法和主体对违规行为进行分组，以识别模式。特定服务账户产生的大量违规可能表明存在未被发现的合法用例，或者需要限制权限过高的凭证。
区分违规的性质：并非所有违规都是同等重要的。例如，被 VPC-SC 阻止的 BigQuery 读取操作可能会破坏关键的分析仪表板；而服务向外部存储桶写入数据的行为，可能正是我们要防止的数据窃取。建立违规分类（比如，需要调整策略的合法用例、可接受的已记录风险、需要补救的安全漏洞），并通过这个框架处理每一个违规行为。
建立自动化仪表盘，显示违规趋势。违规数量的下降表明针对合法用例的政策调整取得了成功，而稳定或增加的违规行为则表明持续有依赖关系被发现，或者团队正在寻找绕过（尚未强制执行）控制措施的解决方法。
第三阶段：强制执行与运维管理
强制执行的决策应该以数据为驱动：违规行为应该被分类和批准，测试并记录回滚程序，并获得受影响团队的利益相关者签字。强制执行是逐步进行的：首先是开发环境，然后是预发布环境，最后是生产环境。每个环境强制执行两周，然后再进入下一个环境，以确保意外问题会首先在风险较低的环境中出现。
强制执行后，应该建立明确的例外请求流程：开发人员会遇到被边界策略阻止的合法场景。例外流程必须在安全性（不能授予破坏控制措施的全面例外权限）与敏捷（避免创建官僚式的冗长申请机制）之间取得平衡。在我的项目中，我创建了分层的例外机制：临时（72 小时，由安全团队批准）、永久（需要安全架构审查）和书面申请。
现实世界中的挑战与解决方案
BigQuery 分析中断事件
在强制执行数据分析边界三周后，我们的商业智能仪表板停止了更新。调查发现，边界外的服务账户正在访问 BigQuery 数据集。这个依赖关系在演练测试中被遗漏了，因为相关的批处理作业每月才运行一次。
我们的紧急修复是创建一个临时的出站策略，允许特定的 BigQuery 进行操作，而长期解决方案则涉及重构批处理作业以使用边界内的服务账户，并更新依赖关系的文档。这一样例再次向我们重申，演练周期必须跨越完整的业务周期，并且自动化的依赖关系发现应该补充而不是替代人类的知识。
平衡安全性与开发人员的生产力
最大的挑战并非技术层面，而是在组织层面。起初，开发人员将 VPC-SC 视为阻碍工作且无明显收益的障碍。一些人甚至试图通过在服务前使用Private Service Connect (PSC) 来绕过边界。
解决方案需要改变我对安全性的沟通方式。我不再将 VPC-SC 呈现为一种限制，而是将其框架化为一种工具，保护他们的应用程序免受数据泄露，保护公司免受监管处罚，并保护他们的团队免受与安全事件相关联的风险。我的团队在自助工具上投入了大量资源，建立了一个网络门户，开发人员可以在其中检查服务账户访问权限、请求具有明确承诺的例外，并查看政策违规的解释和建议的补救措施。
当开发人员看到安全团队迅速响应合法需求，同时在不必要的例外方面保持坚定的边界时，他们的情绪也从抵制转变为接受。
传统应用重构
针对本地环境设计的遗留应用程序通常会假定对存储和数据库都能够无限制地进行访问。一个从本地迁移过来的支付处理应用程序，几乎没有做任何更改，就试图将日志写入另一个 GCP 组织中的云存储桶，这在本地环境中是合理的模式，但在云安全边界中却是违规的。
我们并没有为这个应用程序创建一个例外来允许跨组织的数据传输，而是与应用程序团队合作重构了日志记录。现在，日志写入边界内的一个桶中，并且一个授权的导出过程将经过清理的日志移动到另一个组织中的桶中进行合规归档。这种重构花了六周时间，但提高了安全态势并减少了运营复杂性。
当 VPC-SC 阻止操作时，首先问一下自己，“这应该是被允许吗？”而不是问，“我们该如何允许它？”有时候被阻止的操作代表了需要补救的技术债务，而不是需要适应的现状。
将 VPC-SC 融入更广泛的云安全架构中
采用 VPC Service Controls 是全面云安全架构的一部分，而非独立的解决方案。
分层的防御模型
将云安全视为一个同心层，需要在不同的层次提供保护。VPC-SC 在服务 API 层运行，控制对 GCP 服务的访问。虚拟防火墙（例如 Palo Alto Networks VM-Series）在网络层运行，控制 IP 流量并检查应用程序协议。Cloud Armor 在应用程序层提供分布式拒绝服务（DDoS）保护和 Web 应用程序防火墙（WAF）功能。身份和访问管理（IAM）在资源级别控制基于身份的访问。
每个层次都会捕捉不同的威胁向量。攻击者攻陷虚拟机后，即使他们已经绕过了网络级防火墙规则，可能也会被 VPC-SC 阻止通过云存储 API 进行数据窃取。DDoS 攻击可能会在压垮虚拟防火墙之前被 Cloud Armor 缓解。即使攻击者已经进入了 VPC 网络和边界内，被盗凭据可能会被 IAM 的上下文感知访问策略检测到。
VPC-SC 为敏感资源定义了广泛的安全边界，虚拟防火墙提供了细粒度的网络流量控制和协议检查，Cloud Armor 保护面向互联网的应用程序，而 IAM 在边界内强制执行最小权限访问。单一的控制措施是不够的，安全性来自它们的相互作用。
监控与事件响应
VPC-SC 会为每次策略评估生成审计日志，从而为安全监控创建了丰富的数据。这些日志可以流式传输到 Splunk 等安全信息和事件管理（Security Information and Event Management，SIEM）平台进行分析和警报，或者使用原生 GCP 日志进行分析。关键的监控场景包括：
策略违规异常激增表明可能存在攻击或配置错误。
同一主体重复违规可能表明存在合法的访问问题或侦察行为。
出站违规访问敏感数据或外部存储桶可能表明正在尝试进行数据窃取。
VPC-SC 配置的变更应该仅通过批准的基础设施即代码流程进行。
针对 VPC-SC 检测到的数据窃取尝试的事件响应剧本包括：立即调查源主体和目的地，如果确认攻击则暂时收紧边界政策，进行 Cloud Logging 的取证分析以确定访问的数据，进行事后审查以确定事件是由安全漏洞还是成功攻击引起的。
衡量是否成功：指标与 KPI
量化 VPC-SC 的影响需要定义业务、安全和运营指标。我们项目中的测量指标包括：
安全指标
在前六个月内阻止了 847 次尝试进行数据窃取。
通过逻辑隔离，PCI-DSS 审计范围减少了 40%。
数据访问异常检测时间减少了 45%。
运维指标
在稳定后，部署时间增加不到 5%。
标准例外的平均处理时间为四小时。
通过自动化，策略管理时间减少了 60%。
业务指标
预计每年因为避免数据泄露减少了 450 万美元的损失
每年合规成本节约 20 万美元
实施成本为 80 万美元（12 名工程师耗时 6 个月）
在 18 个月内实现了正投资回报率（ROI）
最佳实践与经验教训
服务发现永无止境，即便采用穷举式的发现方法，也要预期会有意料之外的依赖关系。将服务发现过程视为持续进行的行为，维护依赖关系待办事项列表，安排季度审查，并要求对所有新部署进行依赖关系文档编制。
演练时长至关重要，30 天的演练测试是最低要求，而不是目标。对于具有每月批处理作业、季度报告周期或季节性流量模式的应用程序，要延长演练时间以捕获完整的业务周期。一周的强制执行延迟与生产中断的成本相比是微不足道的。
例外流程决定了成败，你的例外流程决定了 VPC-SC 是增强还是阻碍。明确的时间承诺、透明的批准标准和自助式请求提交，能够使开发人员将安全视为合作伙伴而非障碍。
全面自动化，手工化的策略管理难以为继。对于所有的 VPC-SC 配置均应使用基础设施即代码（例如 Terraform），或者构建一个自助工具，可以使用 Cloud Functions 添加策略。在生产部署之前实施自动化验证测试策略更改。自动化的预部署验证可以在生产之前捕获策略冲突。
沟通能够消除阻力，技术卓越并不意味着能够被采用。我在沟通和利益相关者管理方面花的时间和技术实施一样多。制定定期的办公时间解释为什么 VPC-SC 能够保护每个人，带有示例和故障排除指南的清晰文档，对被 VPC-SC 阻止的开发人员积极进行响应，将组织文化从抵制转变为支持。
未来改进的方向
VPC Service Controls 代表了当前 GCP 数据窃取预防的最佳实践，但威胁和技术仍在不断发展。
将 VPC-SC 与零信任原则对齐，明确验证的合规性，使用最小权限进行访问，并假定存在漏洞。未来的演进应该加强基于实时风险评分的动态访问级别，与身份威胁检测进行集成，在检测到可疑行为时及时撤销访问，以及基于威胁情报自动进行边界策略调整。
当前的 IaC 方式将安全策略视为静态配置。下一代的方法会将策略视为可测试、版本化的代码，并进行自动验证和部署。我们正在朝着策略测试、针对模拟攻击场景验证边界有效性、策略漂移检测（当部署的配置与批准的基线发生偏离时发出警报）以及策略影响分析（在部署之前预测对开发人员生产力的影响）的方向演进。
结论
在企业级规模上实施 VPC Service Controls 表明，成功的安全不仅仅是技术，更关乎人员、流程和组织文化。VPC-SC 在技术方面有着良好的口碑，并且相对简单。困难之处在于理解组织的独特需求，驾驭复杂的依赖关系，获得利益相关者的支持，并在实现业务敏捷性的同时保持安全严谨性。
核心原则超越了任何特定技术。安全的作用应该是促进而不是阻碍；严重损害生产力的控制措施需要规避。你应该设计避免不必要摩擦的安全防护，自动化可以进行大规模扩展，而手工过程难以做到这一点，因此要投资工具，使安全实践成为最简单的路径。
指标很重要。无法衡量就难以改进：跟踪安全和运营的影响。完美是完成的敌人，请现在就部署有效的安全控制，而不是等待永远不会实现的完美控制。采用持续改进的方式，而非试图毕其功于一役。安全不是目的地，而是一种不断适应和完善的持续实践。
VPC Service Controls 为 GCP 环境提供了强大的数据窃取预防机制，但其有效性取决于详尽的设计、分阶段实施、组织协调以及与更广泛安全架构的集成。愿意投资于全面规划、接受迭代改进，并在安全与可用性之间取得平衡的组织，将发现 VPC-SC 是云安全战略中非常有价值组成部分。
威胁环境将继续演变，防御措施必须相应地发展。最重要的不是任何单一的技术，而是建立组织能力来评估风险、实施适当的控制措施、衡量效果，并持续改进能力，以服务于采用任意云平台或安全技术的组织。
原文链接：
