一個(gè)管理數(shù)十萬(wàn)退休賬戶的系統(tǒng)，產(chǎn)品團(tuán)隊(duì)還在用Excel導(dǎo)數(shù)據(jù)做分析，合規(guī)報(bào)告靠手工攢三天，每次SOC 2審計(jì)都讓工程師集體失眠——這不是什么初創(chuàng)公司，是一家正經(jīng)的退休計(jì)劃服務(wù)商。

我的任務(wù)：建一個(gè)統(tǒng)一的云原生數(shù)據(jù)平臺(tái)，過(guò)SOC 2 Type II，還不能拖慢開(kāi)發(fā)速度。聽(tīng)起來(lái)像既要又要？我把信任服務(wù)標(biāo)準(zhǔn)（Trust Services Criteria）當(dāng)成威脅模型來(lái)用，反而找到了解法。

第一層： ingestion， custody從第一行數(shù)據(jù)開(kāi)始

數(shù)據(jù)血緣不是事后補(bǔ)的，是管道自帶的屬性。

批量抽取用AWS Glue，變更數(shù)據(jù)捕獲用AWS數(shù)據(jù)庫(kù)遷移服務(wù)（DMS）。每個(gè)Glue作業(yè)跑完，先往獨(dú)立的審計(jì)日志桶寫(xiě)一條結(jié)構(gòu)化記錄：來(lái)源系統(tǒng)身份、作業(yè)運(yùn)行ID、抽取時(shí)間戳、行數(shù)——然后才是原始數(shù)據(jù)落盤(pán)。

原始數(shù)據(jù)進(jìn)Amazon S3，Object Lock開(kāi)合規(guī)模式。這不是可選項(xiàng)：合規(guī)模式下，連桶主人和AWS支持團(tuán)隊(duì)都改不了刪不了。審計(jì)員要驗(yàn)歷史數(shù)據(jù)有沒(méi)有被篡改，這是地基。

傳統(tǒng)做法是先跑數(shù)據(jù)，再補(bǔ)審計(jì)證據(jù)。這里反過(guò)來(lái)的：管道設(shè)計(jì)就是讓證據(jù)自動(dòng)生成。

第二層：編排，狀態(tài)機(jī)即審計(jì)軌跡

沒(méi)選傳統(tǒng)工作流編排器，選了AWS Step Functions。就一個(gè)原因：執(zhí)行歷史。

Step Functions保留每一步的完整輸入輸出狀態(tài)。審計(jì)員想看某年某月某日某條數(shù)據(jù)進(jìn)了管道的哪個(gè)階段、變成了什么樣，直接調(diào)執(zhí)行歷史就行。不用翻日志、不用猜、不用寫(xiě)額外文檔。

四個(gè)威脅場(chǎng)景里的第一個(gè)——未授權(quán)橫向移動(dòng)——在這里被卡死。每個(gè)Step Functions執(zhí)行都有IAM角色邊界，跨賬戶訪問(wèn)通過(guò)AWS Security Token Service（安全令牌服務(wù)）臨時(shí)憑證，15分鐘過(guò)期。

橫向移動(dòng)不是"很難"，是"需要同時(shí)攻破多個(gè)獨(dú)立憑證體系"。

第三層：轉(zhuǎn)換，schema漂移的自動(dòng)剎車

上游業(yè)務(wù)系統(tǒng)改表結(jié)構(gòu)，下游管道默默崩掉——這是數(shù)據(jù)工程的老噩夢(mèng)。我把它當(dāng)成SOC 2的可用性威脅來(lái)處理。

用AWS Glue Data Catalog做集中schema注冊(cè)，但加了一層：Great Expectations（一個(gè)數(shù)據(jù)驗(yàn)證框架）在每次轉(zhuǎn)換前跑斷言。schema不匹配，管道停，告警發(fā)，人介入。不是"盡量別崩"，是"崩了必須立刻知道"。

轉(zhuǎn)換層用Apache Spark跑在AWS Glue上，但作業(yè)配置強(qiáng)制要求輸出到加密的目標(biāo)路徑，密鑰由AWS Key Management Service（密鑰管理服務(wù)）托管，輪換策略寫(xiě)死90天。PII暴露的第二個(gè)威脅場(chǎng)景，在這里被加密和訪問(wèn)控制雙重鎖住。

審計(jì)證據(jù)同樣自動(dòng)產(chǎn)生：每次密鑰輪換、每次加密操作，CloudTrail（云軌跡服務(wù)）都記一筆。

第四層：消費(fèi)，分析師和審計(jì)員各取所需

產(chǎn)品團(tuán)隊(duì)要跑分析，合規(guī)團(tuán)隊(duì)要出報(bào)告，風(fēng)險(xiǎn)團(tuán)隊(duì)要實(shí)時(shí)監(jiān)控——三類消費(fèi)者，三類訪問(wèn)模式，不能互相踩腳。

建了三個(gè)邏輯數(shù)據(jù)區(qū)：原始區(qū)（Raw）、凈化區(qū)（Curated）、分析區(qū)（Analytics）。原始區(qū)只有管道服務(wù)賬號(hào)能寫(xiě)，合規(guī)團(tuán)隊(duì)只讀。凈化區(qū)做脫敏和聚合，分析師能碰。分析區(qū)放聚合指標(biāo)，BI工具直連。

Amazon Athena（交互式查詢服務(wù)）做即席查詢，但每個(gè)查詢都通過(guò)Lake Formation（數(shù)據(jù)湖構(gòu)建服務(wù)）做列級(jí)授權(quán)。分析師能看到"某年齡段賬戶的平均余額"，看不到"張三的余額"。

審計(jì)報(bào)告以前是三天手工活，現(xiàn)在Athena查詢模板一鍵出數(shù)，CloudWatch（監(jiān)控服務(wù)）儀表盤(pán)實(shí)時(shí)刷新。SOC 2審計(jì)從"翻箱倒柜找證據(jù)"變成"打開(kāi)控制臺(tái)演示"。

如果重來(lái)，我會(huì)改什么

Object Lock的合規(guī)模式選對(duì)了，但恢復(fù)策略 underestimated 了。有次誤操作刪了非鎖定對(duì)象，從備份恢復(fù)花了6小時(shí)。現(xiàn)在所有桶開(kāi)版本控制+跨區(qū)域復(fù)制，RTO（恢復(fù)時(shí)間目標(biāo)）壓到30分鐘。

Step Functions的執(zhí)行歷史保留90天，但SOC 2要求部分證據(jù)存7年。早期沒(méi)做自動(dòng)歸檔到Amazon S3 Glacier（歸檔存儲(chǔ)），后來(lái)補(bǔ)了Lambda（無(wú)服務(wù)器計(jì)算）定時(shí)任務(wù)。應(yīng)該一開(kāi)始就想清楚數(shù)據(jù)生命周期。

Great Expectations的斷言寫(xiě)太激進(jìn)，初期誤報(bào)率30%，分析師罵街。后來(lái)改成分層：阻斷級(jí)斷言（schema、非空）必須過(guò)，警告級(jí)斷言（分布漂移）只發(fā)通知。合規(guī)和效率的 trade-off，需要產(chǎn)品判斷力，不是純技術(shù)問(wèn)題。

最大的教訓(xùn)：把合規(guī)當(dāng)威脅模型來(lái)做，架構(gòu)會(huì)自然偏向"可審計(jì)"。但"可審計(jì)"不等于"易用"，中間的產(chǎn)品化工作——查詢模板、告警分級(jí)、文檔自動(dòng)化——花的功夫不比架構(gòu)設(shè)計(jì)少。

現(xiàn)在每次審計(jì)，工程師不再失眠。不是因?yàn)闆](méi)問(wèn)題，是因?yàn)橛袉?wèn)題能立刻定位、舉證、修復(fù)。這種底氣，比任何合規(guī)證書(shū)都值錢(qián)。

你現(xiàn)在的數(shù)據(jù)管道，是"先跑起來(lái)再補(bǔ)證據(jù)"，還是"證據(jù)隨管道一起流動(dòng)"？