Goldman Sachs：透過 Fast Track 將應用程式移至雲端 - AWS FSI Meetup Q1/2023

場次筆記

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 範本。
• 防護機制會依據這些範本執行，而政策引擎會判斷部署可否繼續（「通過」或「不通過」）。

防護機制詳細資訊：

• 防護機制遵循預設拒絕政策。
• 使用 Open Policy Agent (OPA) 撰寫。
• 依據標準 CloudFormation 範本執行。
• 防護機制範例：確保惡意行為者無法存取未加密的物件。

威脅建模與控制措施定義：

• 使用 NIST 800-53 指引識別特定技術的威脅。
• ISO 27001 是資訊安全管理系統的國際標準，而 NIST SP 800-53 則是美國政府的安全與隱私控制標準。2. ISO 27001 著重資訊安全管理，而 NIST SP 800-53 則著重技術性安全控制。
• 威脅範例：惡意行為者可以存取未加密的物件。
• 控制措施定義：將物件加密。
• 控制措施會定義為 OPA 政策並加以使用，且由安全團隊審查及進行單元測試。

控制措施的協作與發布：

• Cloud Enablement 防護機制開發團隊與安全團隊共同協作。
• 控制措施會以防護機制的形式發布，以建立安全環境，但也可能對開發人員造成阻礙。

加速器：

• 建構為能與防護機制搭配運作，讓開發人員快速部署符合所有防護機制的資源。
• 範例：符合封鎖 S3 之全部 10 項防護機制的 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) 執行。
• 政策引擎會判斷部署可否繼續（「通過」或「不通過」）。

防護機制的技術實作（續）

• 此外，另提供 IDE 外掛程式，讓開發人員不必部署管線就能更早收到意見回饋。
• 開發人員可在 IDE 中進行開發時查看意見回饋，協助他們從開發流程早期便遵循安全標準。

NIST 實作與威脅資料庫相關問題：

• 專案以 NIST 800-53 作為初始基準。
• 公司的網路防禦與情報團隊會向團隊通報新威脅。
• 團隊根據漏洞等級（是否為重大漏洞）決定如何管理新威脅，並將處理方式整合至軟體開發生命週期 (SDLC)。
• 偵測性控制可補強防護機制所提供的預防性控制。

FP&A（財務規劃與分析）介紹：

• FP&A 負責全公司的業務規劃、成本分攤，以及推動財務洞察。
• FP&A 正採行雲端優先策略，目標是在 2024 年底前，將 100% 的內部部署應用程式及新應用程式移至雲端。
• 採用雲端的原因包括每月運算用量的高峰與低谷、目前內部部署解決方案的限制（安裝並執行於組織自身的實體硬體及伺服器上，且位於其自有設施內），以及希望減少工程人員投入維護的時間。
• FP&A 已積極將舊有內部部署基礎設施解耦，目前約完成 70%；過去三年建構新應用程式時，也已將雲端需求納入考量。

FP&A 的雲端策略與採用情形：

• FP&A 一直在建構適合微服務且支援雲端的架構，即使在內部部署環境中，也大力投資基礎設施即程式碼 (IaC)。
• 採用雲端的動力來自低廉的運算成本、生產力提升，以及建置與維護週期縮短。
• 在工程主管的支持下，Fast Track 成為公司的策略平台。

首個應用程式：FBA Central：

• 選擇一個簡單的閘道應用程式作為首個應用程式，以學習 AWS 與 Fast Track。
• 歷時三至四個月開發，並於九月至十月以 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 constructs 建構以 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 運用 Service Identity Framework (SIF)，在每個端點導入 SkyPath 前，先為其建立唯一身分。
• 這可確保只有身分定義清楚的端點能夠連線，解決整合時可能發生的身分識別挑戰。

Service Identity Framework (SIF)：

• SIF 要求每個端點在導入 SkyPath 前，必須先定義唯一身分。
• 這個身分如同內部部署服務的類雲端身分，可確保存取安全且受到控制。
• 若要透過 SkyPath 存取內部部署 API，必須先建立服務身分。

結論：

• 本次討論強調內部部署與雲端環境之間安全且受控整合的重要性，而 SkyPath 與 Service Identity Framework 等解決方案可促成這類整合。