威脅建模和風險控制
1）原則
1.Architectural First.我們從上下文、信任邊界和數據流開始。
2.Risk ≈ Likelihood × Impact.測量而不是感覺。
3.Defense in Depth.每層控制器：代碼→協議→平臺→人員。
4.Shift Left/Right.PR+監視和銷售反應中的早期門。
5.Privacy by Design.我們不僅模擬安全威脅，而且模擬隱私風險。
6.Automate Where Possible.策略作為代碼，自動反駁，「紅線」。
2）庫存： 資產、實體、信托界限
資產：數據（PII，財務，秘密），計算資源，密鑰，可用性，業務流程。
受試者：用戶，服務，管理人員，合作夥伴，外部提供商。
信任邊界：用戶↔前端、API網關↔服務↔ DB/緩存/隊列、區域/雲。
攻擊面：輸入點（API, webhook, UI, network, CI/CD, supply chain）。
mermaid flowchart LR
U[Пользователь] -- TLS --> WAF[WAF/CDN]
WAF --> GW[API Gateway]
GW --> Svc[Service A]
Svc --> DB[(Postgres)]
Svc --> MQ[[Kafka]]
MQ --> SvcB[Service B]
subgraph Trust Boundary
GW; Svc; SvcB end3）威脅框架
STRIDE (безопасность): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA（流程）：從業務目標和威脅行為者→技術細節→測試場景。
表（片段、STRIDE ×組件）：4）風險評估
針對漏洞的DREAD/OWASP風險評級或CVSS。
概率（L）：攻擊者的動機/能力，復雜性，表面曝光。
影響（I）：金融，侏羅紀，停機，PD泄漏。
風險（R=L × I）→優先級和臨界值：Avoid/Reduce/Transfer/Accept。
Impact
Low Med High Critical
Lik Low L L M H
Med L M H H
High M H High Crit風險寄存器（最小字段）：'id，腳本，STRIDE，資產，L，I，R，所有者，控制者，狀態，修訂日期'。
5）主計長： Prevent/Detect/Respond
預防（預防）：- 身份驗證/授權：OIDC/OAuth2，PoLP，RBAC/ABAC，短期服務信用。
- 秘密/密鑰：KMS/HSM,旋轉,「不知情」原則,FPE/字段加密。
- 安全協議：TLS1。2+，mTLS，webhook簽名，等效性和反重播。
- 驗證/衛生：計劃（JSON 計劃/Proto），限制，正常化。
- 隔離：網絡政策，細分，sandbox，namespaces，bulkheads。
- 審核邏輯（不可響應），在SIEM中重播，異常異常。
- 監視簽名和完整性（導出工件哈希,attestation）。
- Honeytokens/金絲雀用於早期密鑰泄漏檢測。
- Runbook IR：分類,隔離,召回密鑰,警報,forenzika.
- 自動殺手開關/功能旗，令牌的「黑名單」。
- 在PD事件中通知用戶/監管機構。
6） SDL和安全門
在想法/設計中：威脅模型（RFC/ADR），控制檢查表。
在開發中：SAST/秘密掃描，依存掃描（SCA），依存策略。
在裝配中：SBOM、工件簽名、漏洞策略（CVSS閾值）。
Deply： OPA/Kyverno-IaC/清單 （securityContext、網絡策略、秘密漏洞）策略。
銷售：IDS/WAF，匿名檢測，金絲雀檢查，混沌安全（例如，過期證書）。
rego package policy.cicd deny[msg] {
some v input.sbom.vulns[v].cvss >= 7.0 msg:= sprintf("High vuln blocked: %s %s", [v.package, v.id])
}
deny[msg] {
input.k8s.pod.spec.securityContext.runAsRoot == true msg:= "RunAsRoot forbidden"
}7）供應鏈供應和人工制品信任
每個映像/軟件包的SBOM；依存關系更新-通過機器人/策略。
SLSA/Provenance：可重現的組件、簽名、狀態。
容器：最小外觀，rootless，下降capabilities，只讀FS。
IaC掃描：Terraform/Helm是加密政策，開放端口，網絡規則。
8）隱私和合規性
LINDDUN隱私威脅卡，數據最小化，別名/匿名化。
保留策略：TTL/重建,「刪除權限」,對PD訪問進行審核。
本地化：地理限制，「數據保留在該地區」。
透明度：處理、通知和同意記錄。
9）雲層和外圍
零信任：驗證每個請求，服務之間的mTLS/OPA。
分段：VPC/子網/SG，私人端口，egress控制。
鑰匙/秘密：KMS，rotation，CI（OIDC聯合會）中的短信。
備份/DR：加密備份，單獨密鑰，恢復排練。
10）紅色/紫色團隊和平板運動
紅色團隊：威脅假設驗證，社會工程，鏈條操作。
紫色團隊：聯合調試探測器/警報器，改進IR的劇本。
Tabletop：「證書到期」、「密鑰泄漏」、「供應鏈損害」腳本。結果-更新控制和指標。
11）成熟度量與管理
覆蓋：具有當前威脅模型和DFD的服務百分比。
MTTD/MTTR安全，控制者捕獲的事件比例。
CI中的Policy pass-rate（策略通票率）,按臨界值關閉漏洞的時間。
隱私：具有TTL/ILM的dataset的百分比，具有合理性的可用性份額。
審計：定期審查風險登記冊（季度）。
12）工件模板
12.1個風險卡（示例）
Risk ID: SEC-API-012
Сценарий: SSRF через изображение в профиле
STRIDE: Tampering/Info Disclosure
Актив: API / файловый прокси
Likelihood: High Impact: High Risk: Critical
Контроли: denylist схем, egress-прокси, URL-fetcher в изолированном рантайме,
DNS-resolv только через прокси, время/размер-лимиты, allowlist.
Владелец: team-accounts Статус: Reduce (в работе)
Дата пересмотра: 2025-12-0112.2設計支票清單
DFD/數據輪廓是組成並綁定到 ADR的?
STRIDE/LINDDUN是通過每個DFD箭頭嗎?
如何添加代碼（OPA/Kyverno/CI門）策略?
監視/警報計劃和IR-runbook是否更新?
已確定資產和PII？信任界限是標記的嗎？
選擇風險臨界點；有所有者/截止日期/國防部？
隱私： 最小化、加密、TTL/還原、本地化?
12.3 Webhook策略（偽代碼）
python def verify_webhook(req, keys):
ts = int(req.h["X-Timestamp"])
if abs(now_utc()-ts) > 300: return 401 if not hmac_ok(req.body, ts, keys.active_or_prev(), req.h["X-Signature"]):
return 401 if replay_cache.seen(req.h["X-Event-ID"]): return 200
PoLP: в обработчике — только нужные скоупы handle(json.loads(req.body))
replay_cache.mark(req.h["X-Event-ID"])
return 20013）反模式
沒有DFD/不變量的威脅模型「用於打勾」。
「超級外圍」無需內部驗證服務。
環境/回購變量中的長期秘密。
未作為代碼實施的策略→手動「忘記」。
帶有PD的徽標沒有偽裝，也沒有重生/TTL。
忽略供應鏈（無SBOM/簽名/掃描）。
接受風險（接受）沒有所有者和審查日期。
14）流程整合
RFC/ADR：每個有意義的解決方案都包含「威脅和控制」部分。
Docs-as-Code：威脅模型，DFD，代碼旁邊的版本中的風險寄存器。
Release gates：當SAST/SCA/SBOM策略失敗或缺少高臨界性控制時,該發布被阻止。
培訓：面向開發人員的花花公子（秘密，簽名，PoLP），常規平板電腦。
二.結論
威脅建模是風險管理的工程實踐，不是一次性文檔。通過應用STRIDE/LINDDUN定義資產和信任界限,測量風險,將其記錄在寄存器中,並通過將其嵌入到CI/CD和操作中來實現控制作為代碼。隨著成熟度指標和定期修訂，您將將安全性轉變為可預測的體系結構能力-價格、效果和速度是可以理解的。