回顾系列
- 场次 01:现代交易生命周期:从交易到结算
- 场次 02:Goldman Sachs:通过 Fast Track 加速应用程序上云 - AWS FSI Meetup Q1/2023
- 场次 03:Zurich Insurance Group:在 AWS 上构建高效的日志管理解决方案
- 场次 04:FSI Meetup 2025 年第四季度 - Brex 数据库灾难恢复
- 场次 05:FSI Meetup 2025 Q4 - Graviton 迁移成功案例
- 场次 06:FSI Meetup 2025 Q4 - Stifel 现代数据平台
- 场次 07:FSI Meetup 2025 Q4 - PayPal 金融交易数据对账系统
- 场次 08:FSI Meetup 2025 Q4 - 规模化提升韧性
场次笔记
Ragini Lalwani 致开场辞:
- 负责 Goldman Sachs 的公有云接入和迁移。
- 祝大家妇女节和洒红节快乐。
- 已在 Goldman Sachs 工作近 15 年,最初以实习生身份加入。
- 拥有使用多种云平台的经验:私有云、混合云和公有云。
- 探讨 Goldman Sachs 在受监管行业中确保开发者快速、安全使用云的方法。
Aditya 的介绍:
- 负责财务规划工程团队,并担任 Goldman Sachs FP&A 的首席架构师。
- 同样已在公司工作近 15 年,最初从事 Web 应用开发,目前专注于企业系统。
- 探讨公司云接入的独特阶段以及从本地部署向云迁移的转型。
- 将介绍公有云接入体验、安全工具、云接入加速,以及主要亮点和经验。
Goldman Sachs 概览:
- 一家领先的金融机构,提供广泛的服务,包括投资银行、证券、投资管理和个人银行业务。
- 服务于广泛且多元化的客户群,包括企业、金融机构、政府和个人。
- 成立于 1869 年,总部位于纽约,并在全球主要金融中心设有办事处。
- 以安全优先的理念加速 Goldman Sachs 的云之旅。
Fast Track 章节概览:
- 强调以客户为中心的理念,采用 Amazon 的“逆向工作法”。
从客户视角(应用程序开发者)提出的问题:
- 新开发者需要了解公司的安全方法、安全态势和模块。
- 部署需要通过安全审查,而审查可能依靠人工且十分耗时。
- 不仅首次部署需要安全审查,后续变更也需要审查,因此过程可能缓慢且需反复迭代。
- 开发者可能在部署后收到配置错误的告警,这凸显了采用预防性控制而非检测性控制的必要性。
- 擅长应用程序开发的开发者可能不具备云安全专业知识,造成开发能力与安全要求之间的割裂。
解决相关问题的原则:
- 实施防护机制,确保部署在设计上即具备安全性,并实现安全基线自动化。
- 建立清晰的共同责任模型,明确云服务提供商、Goldman Sachs Cloud 团队和应用程序开发者各自的职责。
- 利用云原生技术,尽量减少学习公司专用工具的需求,让开发者能够运用已有的 AWS CDK 或 Kubernetes 知识。
- 以自助服务能力为目标,减少提交工单或人工审查的需要,让更多开发者可以顺畅使用云。
Fast Track 简介:
- Fast Track 是针对上述问题开发的解决方案。
- 内容包括对实施细节的技术深度解析。
- 目标是为开发者提供安全、高效且以自助服务为导向的云接入体验。
Fast Track 概览:
- 一项完全托管式服务,使 Goldman Sachs 开发者能够在 AWS 上快速开发和部署软件。
- 通过防护机制强制执行公司的安全、监管和合规要求。
- 以编程方式主动执行安全策略,增强安全态势。
Fast Track 的主要功能:
- 在后台处理账户创建和流水线管理。
- 用户通过 CLI 或 API 与 Fast Track 交互,以创建、删除或共享流水线。
- 创建流水线会触发账户预置工作流,为 AWS 资源创建服务账户,并创建用于管理的流水线账户。
- 用户推送代码变更后,代码会经过部署流水线并接受防护机制检查。
- 防护机制强制执行公司的安全基线策略,确保资源在部署前满足安全要求。
简化的用户流程:
- 用户创建 Fast Track 流水线,并将其与 GitLab 仓库关联。
- 使用 AWS CDK 编写基础设施即代码。
- 流水线将 CDK 代码合成为 CloudFormation 模板。
- 防护机制针对这些模板执行检查,策略引擎判断是否可以继续部署(“go”或“no go”)。
防护机制详情:
- 防护机制遵循默认拒绝策略。
- 使用 Open Policy Agent (OPA) 编写。
- 针对标准 CloudFormation 模板运行。
- 防护机制示例:确保恶意行为者无法访问未加密的对象。
威胁建模与控制措施定义:
- 使用 NIST 800-53 指南识别特定技术面临的威胁。
- ISO 27001 是信息安全管理体系的国际标准,而 NIST SP 800-53 是美国政府制定的安全与隐私控制标准。2. ISO 27001 侧重信息安全管理,而 NIST SP 800-53 侧重技术安全控制。
- 威胁示例:恶意行为者可以访问未加密的对象。
- 控制措施定义:加密对象。
- 控制措施被定义并用作 OPA 策略,由安全团队进行审查和单元测试。
控制措施的协作与发布:
- Cloud enablement 防护机制开发团队与安全团队开展协作。
- 控制措施以防护机制的形式发布,既能创建安全环境,也可能给开发者带来障碍。
加速器:
- 与防护机制配合使用,使开发者能够快速部署符合所有防护机制要求的资源。
- 示例:可满足全部 10 项 S3 拦截防护机制要求的 Fast Track S3 存储桶。
示例代码与入门项目:
- 用于帮助用户快速开启云之旅。
Fast Track 发布与生产环境使用:
- Fast Track 已发布并可供使用,已有多个应用程序投入生产,另有更多应用程序正在推进。
组织协同与模式:
- Goldman Sachs 认识到,需要在不牺牲安全性的前提下提供一流的开发者体验。
- Fast Track 被确定为旗舰项目,由 Cloud enablement 团队牵头,并与技术风险团队协作开发。
- 防护机制开发团队由开发者、云架构师和安全工程师共同组成。
- 防护机制贡献模式确保特定技术团队(例如存储工程团队)审查相关防护机制并为其作出贡献。
关于组织结构问题的回答:
- 承认大型企业中常见的部门孤岛模式。
- 强调需要采用协作方式,在开发者体验与安全性之间取得平衡。
- 强调管理层授权对于促进跨团队协作的重要性。
- 指出并非 Cloud enablement 团队的所有成员都是各项云服务(例如 S3)的专家这一限制。
- 防护机制开发需要多种技能,并采用贡献模式开展专业审查。
云中所有权与责任的说明:
- 在云中,应用程序团队拥有其全部云资源,包括计算资源和数据库,这些资源均部署在其 VPC 中。
- 数据库团队负责与 Cloud enablement 团队合作,建立访问控制、策略管理和审计相关机制。
- 在本地部署环境中,数据库归数据库团队所有;但在云中,运行于 AWS 的数据库归客户(应用程序团队)所有。
组织模式总结:
- 中央 Cloud 团队建立防护机制框架,并负责云开发相关事务。
- CIO、CTO 和 Tech Risk Office 为新的防护机制开发以及云接入和治理策略提供支持。
- 相关团队(DB 团队、IAM 团队等)与中央 Cloud 团队合作,将其服务和策略接入平台。
- 应用程序开发团队使用 Fast Track 实施应用,并可申请其他服务,之后由相关团队协作完成。
协作模式:
- 多个团队在云接入过程中各司其职,确保以协作方式推进云开发和安全工作。
首个应用程序的实操方法:
- 首个接入 Fast Track 的应用程序需要更多实操支持,因为团队当时仍在了解客户旅程。
- 后续应用程序力求利用现有防护机制,使客户能够独立使用服务。
- 投资建设教程和文档,为自助使用提供支持。
平台团队的角色:
- 平台团队提供指导,并为 Lambda、DynamoDB 和 RDS 等资源构建安全控制措施(防护机制)。
- 开发者可以自由选择所需资源,平台团队则协助构建必要的安全控制措施。
- 提供加速器,让开发者可以更轻松地安全部署资源。
开发环境与生产环境中的防护机制:
- 开发(沙盒)环境和生产环境均应用相同的防护机制。
- 所有环境中的防护机制均以拦截模式运行,以保持一致的安全态势。
- 精细化控制允许按流水线绕过特定防护机制,但须经过技术风险审查。
防护机制的技术实现:
- 流水线通过与 API 交互来检查防护机制。
- 流水线将基础设施即代码(例如 AWS CDK)合成为 CloudFormation 模板。
- 随后针对防护机制检查这些模板,并使用 Open Policy Agent (OPA) 运行检查。
- 策略引擎判断是否可以继续部署(“go”或“no go”)。
防护机制的技术实现(续)
- 此外,还提供 IDE 插件,让开发者无需部署流水线即可更早获得反馈。
- 开发者在 IDE 中开发时便可查看反馈,有助于其在开发流程早期遵循安全标准。
关于 NIST 实施与威胁数据库的问题:
- 项目以 NIST 800-53 为基线启动。
- 公司的网络防御和 Intel 团队会及时向团队通报新威胁。
- 根据漏洞的严重程度(是否为严重漏洞)决定如何管理新威胁,并将其整合到软件开发生命周期 (SDLC) 中。
- 检测性控制对防护机制提供的预防性控制形成补充。
FP&A(财务规划与分析)简介:
- FP&A 负责公司范围内的业务规划、成本分摊和财务洞察。
- FP&A 正在推行云优先战略,目标是在 2024 年底前将 100% 的本地部署应用和新应用迁移上云。
- 采用云的原因包括每月计算使用量存在波峰和波谷、当前本地部署解决方案存在局限(安装并运行在组织自己的物理硬件和服务器上,且这些设备位于组织自己的设施内),以及希望减少工程师用于维护的时间。
- FP&A 积极推进遗留本地基础设施解耦,目前已完成约 70%;过去三年中,在构建新应用程序时也始终考虑云相关因素。
FP&A 的云战略与采用:
- FP&A 一直在构建微服务友好、云就绪的架构,甚至在本地部署环境中也大力投资基础设施即代码 (IaC)。
- 采用云的驱动力包括低廉的计算成本、生产力提升,以及构建和维护周期缩短。
- 在工程领导者的支持下,Fast Track 成为公司的战略平台。
首个应用程序:FBA Central:
- 选择一个简单的网关应用作为首个应用,用于学习 AWS 和 Fast Track。
- 在三到四个月内完成开发,并于 9 月至 10 月期间发布 MVP。
- 这是一个具有代表性的微服务应用,包含 Spring Boot API,使用 ECS Fargate 和 DynamoDB 部署,并配有 React.js UI。
后续应用程序:
- 构建了更复杂的应用程序,包含更多微服务、本地连接和工作流解决方案。
- 将首个应用部署到 FP&A 专用 VPC,这在公司尚属首次。
- 尽管应用程序复杂度增加,Fast Track 仍提高了生产力并缩短了交付时间。
- 随着时间推移,团队技能不断提升,进一步缩短了时间周期。
总结:
- FP&A 的云优先战略与 Fast Track 相结合,成功接入复杂度不断提高的应用程序,提升了生产力并缩短了交付时间。
FP&A 的云之旅与未来重点:
- 部署了三个云原生应用,使用八项以上的服务。
- 学习了如何构建软件、完成云接入、接受技术风险审查和架构标准提升,以及执行 SDLC 流程。
- 培训了约一半的 FP&A 工程师。
- 2023 年的主要重点:高使用量应用和数据密集型计算,每天处理约 60 亿条记录。
- 将探索无服务器产品(Lambda、Step Functions)和数据处理/分析服务(Glue、Athena、S3、Snowflake)。
- 目标是使用 CDK 构造开发以 FP&A 为中心的加速器,进一步加快开发速度。
关键决策与成功因素:
- 组建由来自不同地区的四名开发者构成的核心团队,负责培训 Scrum 团队,从而加快开发。
- 鉴于需要处理敏感数据,选择 Fast Track 进行安全的云接入。
- Fast Track 的防护机制已通过技术风险审批,并在每次流水线执行时持续运行,从而提供安全且保持最新的配置。
- Fast Track 的 CDK 加速器和通用模式帮助提高了开发者生产力。
部署与经验:
- 使用 DynamoDB、ECS Fargate 和 ALB 等 AWS 组件部署了首个简单应用 FBA Central。
- 经历了严格的技术风险审查和架构标准提升。
- 学习了 gold live 机制、环境创建、可观测性、日志记录,以及 CloudWatch 和 PagerDuty 的使用。
- 停用了本地部署应用,使 FP&A 全面实现云原生。
云应用经验:
- 云提供了更广泛、更成熟的选项,可以更准确地匹配应用程序的计算资源消耗需求。
- 建议刚开启云之旅的组织调整实施手册,并借鉴 FP&A 的经验。
设计选择的重要性:
- 工程师必须了解其设计选择带来的后果,因为这些选择会影响运营成本和维护。
- 无服务器方案具有成本更低、易于扩展和维护工作量小等优势。
- 基础设施即代码 (IaC) 支持更快地创新,并可在不同的计算与成本配置之间切换。
IaC 的优势:
- 支持更快地进行创新和云成本优化。
- 可根据架构选择采用不同的成本和计算配置。
- 与本地部署相比,云战略让业务连续性规划 (BCP) 更加简单直接。
开发者生产力提升与成本优化:
- 借助每日管理成本的能力,开发者生产力有所提升。
- 日趋成熟的生态系统和 Fast Track 推动了应用程序接入。
更多学习资源:
- 可通过 Goldman Sachs Engineering 开发者博客了解云及相关构建工作的洞察。
关于 Fast Track 与开源的说明:
- Fast Track 本身尚未开源。
- Goldman Sachs 设有开源团队,并已将多个项目开源。
- Fast Track 的防护机制最初与 AWS 合作构建,并已回馈给 AWS;AWS 正将其作为 CFN Card 的一部分使用。
- Goldman Sachs 不认为这些防护机制构成竞争优势,并愿意与他人共享。
SkyPath:云与本地部署环境的集成:
- SkyPath 是一种连接解决方案,允许不同信任区中的应用程序相互连接。
- 它解决了混合环境中连接本地应用和云应用的挑战。
- SkyPath 利用服务身份框架 (SIF),在每个端点接入 SkyPath 前为其建立唯一身份。
- 这确保只有身份已明确定义的端点才能连接,从而解决集成中潜在的身份问题。
服务身份框架 (SIF):
- SIF 要求每个端点在接入 SkyPath 前都必须定义唯一身份。
- 该身份充当本地服务的准云身份,确保安全且受控的访问。
- 建立服务身份是通过 SkyPath 启用本地 API 访问的先决条件。
结论:
- 讨论强调了在本地部署环境与云环境之间进行安全、受控集成的重要性,而 SkyPath 和服务身份框架等解决方案可为此提供支持。
