操作和管理→配置審核

配置審核

1）目的和價值

配置審核確保了可證明的問責制和變更的可重復性：誰，何時以及發生了什麼變化；什麼是合理的；經核實；如何回滾。這減少了發生事件，泄露秘密，合規性不一致以及銷售「隱藏」編輯的風險。

• Configs的單一真相來源（SoT）。
• 完整的更改跟蹤（端到端）。
• 可預測的發行版和快速回滾。
• 遵守監管和安全政策。

2）覆蓋範圍

基礎架構：Terraform/Helm/Ansible/K8s清單，網絡ACL/WAF/CDN。
應用configs：「yaml/json/properties」文件，幻燈片，限制/配額。
秘密和密鑰：vault/kms,證書,代幣,密碼。
數據管道：模式、轉換、ETL/流時間表。
集成：PSP/KYC/提供商，webhooks，retry/timeout策略。
可觀察性：等分規則，dashbords，SLO/SLA。

3）原則

Config as Data：聲明性、可轉換、可測試的工件。
不可移動性和冪等性：介質的可重復性來自代碼。
方案和合同：嚴格的驗證（JSON-Schema/Protobuf），後方/前向兼容性。
最小化手動編輯：僅通過MR/PR進行更改。
職責分工（SoD）和4-eyes：作者！=deploer；強制性的咆哮。
歸屬和簽名：commites/發行版簽名，工件插件。

4）審核體系結構

1.SCM（Git）作為SoT：存儲庫中的所有configs，「主」分支受到保護。

• Config Registry（Config目錄，所有權，SLA，隨行人員），
• Schema Registry（configs/events方案的版本），
• 策略引擎（OPA/Conftest）-一組檢查。
• 3.CI/CD門：格式/圖形→靜態檢查→策略檢查→秘密掃描→ dry-run →更改計劃。
• 4.交付：GitOps（例如ArgoCD/Flux）帶有漂移檢測器和應用審計日誌。
• 5.Evidence Store：審計工件存儲（計劃、日誌、簽名、賬單、SBOM）。
• 6.活動日誌：「CREATE/APPROVE/APPLY/ROLLBACK/ACCESS」事件的不變日誌。

5）審核數據模型（最低）

Сущности: `ConfigItem(id, env, service, owner, schema_version, sensitivity)`

События: `change_id, actor, action, ts, diff_hash, reason, approvals[]`

Артефакты: `plan_url, test_report_url, policy_report, signature, release_tag`

鏈接：RFC/tiket ↔ PR ↔ deploy（sha）↔發布記錄↔監視SLO。

6）更改過程（端到端）

1.RFC/滴答聲 →目標，風險，後退。
2.PR/MR → linting,示意圖驗證,策略驗證,秘密掃描。
3.計劃/預覽→ dry-run/plan，diff資源，價值評估/影響。
4.Approve（4-eyes/SoD，高風險的CAB標簽）。
5.Deploy（通過窗口/日歷）→ GitOps應用；啟用drift alerting。
6.驗證→ smoke/SLO gardrail,結果確認。
7.證據存檔→ evidence store；更新字典。

7）政策和規則（示例）

SoD：PR作者不會在口袋裏亂七八糟。
時間限制：禁止在「freeze」 之外的prod deploy。
Scope：更改敏感密鑰需要2 x安全性/法規遵從性。
秘密：禁止保存在回購中；僅指向vault路徑+訪問角色的鏈接。
網絡：ingress從'0。0.0.0/0'被禁止，沒有臨時豁免和TTL。
Alerts：禁止在沒有CAB的情況下降低P1的臨界值。

8）秘密控制

存儲在Vault/KMS、短TTL、自動旋轉。
秘密掃描到CI（鍵模式，高輸入）。
根據環境/角色隔離秘密；最低要求的特權。
加密「在電線上」和「靜止」；密封的秘密訪問審核日誌。

9）工具（可變）

Lint/Schema: `yamllint`, `jsonschema`, `ajv`, `cue`.

Policy: OPA/Conftest, Checkov/tfsec/kube-policies.

GitOps: ArgoCD/Flux (drift detection, audit, RBAC).

秘密：HashiCorp Vault，雲端KMS，證書經理。
掃描儀：trufflehog，gitleaks（秘密）；OPA/Regula（規則）。
報告：DWH/BI的期刊出口，事件和變更系統捆綁在一起。

10）規則和工件示例

用於極限配置的JSON-Schema

json
{
"$schema": "http://json-schema. org/draft-07/schema#",
"title": "limits",
"type": "object",
"required": ["service", "region", "rate_limit_qps"],
"properties": {
"service": {"type":"string", "pattern":"^[a-z0-9-]+$"},
"region": {"type":"string", "enum":["eu","us","latam","apac"]},
"rate_limit_qps": {"type":"integer","minimum":1,"maximum":5000},
"timeouts_ms": {"type":"integer","minimum":50,"maximum":10000}
},
"additionalProperties": false
}

Conftest/OPA （rego）-禁令'0。0.0.0/0` в ingress

rego package policy. network

deny[msg] {
input. kind == "IngressRule"
input. cidr == "0. 0. 0. 0/0"
msg:= "Ingress 0. 0. 0. 0/0 is not allowed. Specify specific CIDRs or throw an exception with TTL"
}

Conftest/OPA-SoD （prod不會幹擾作者）

rego package policy. sod

deny[msg] {
input. env == "prod"
input. pr. author == input. pr. merger msg: = "SoD: PR author cannot hold in prod."
}

SQL （DWH）-誰在一個月內降低了Alert的臨界值

sql
SELECT actor, COUNT() AS cnt
FROM audit_events
WHERE action = 'ALERT_SEVERITY_CHANGED'
AND old_value = 'P1' AND new_value IN ('P2','P3')
AND ts >= date_trunc('month', now())
GROUP BY 1
ORDER BY cnt DESC;

Git commit消息示例（必填字段）

feat(config/payments): raise PSP_B timeout to 800ms in EU

RFC: OPS-3421
Risk: Medium (PSP_B only, EU region)
Backout: revert PR + restore timeout=500ms
Tests: schema ok, conftest ok, e2e ok

11）監視和警報

Drift detection： ≠ Git →集群中的同位素P1/P2信號+自動還原（reconcile）。
高風險更改：更改網絡/秘密/策略-#security-ops中的通知。
Missing evidence：沒有計劃/簽名/報告的deploy-塊或警報。
Expired assets：證書/密鑰有效期→ pro-Active Alertes。

12）度量和KPI

審計覆蓋率％-電路/策略/掃描儀下的configs份額。
Drift MTTR-消除漂移的平均時間。
Policy Compliance%-通過PR的策略。
Secrets Leak MTTR-從泄漏到召回/旋轉。
Backout Rate是config更改回滾的比例。
Mean Change Size是按行/資源劃分的平均diff（更小-更好）。

13）報告和合規性

審核痕跡：1-3年≥存儲（根據要求）,不變存儲。
法規：ISO 27001/27701，類似SOX的SoD，GDPR（PII），行業要求（iGaming：考慮GGR/NGR計算變化，限制，獎金規則）。
月度報告：頂級更改,違反政策,漂移,過期證書,輪換狀態。

14）花花公子

A.在銷售中發現漂移

1.阻止受影響的服務的自動派遣。
2.刪除當前狀態的快照。
3.與Git進行比較，啟動「reconcile」或回滾。
4.創建P2事件,指定漂移源（手動kubectl/控制臺）。
5.包括保護：禁止直接更改（PSP/ABAC），通知所有者。

B. PSP證書逾期

1.切換到備用路徑/PSP，降級taymout/retrai。
2.通過PKI流程發布新證書,通過Git更新證書。
3.煙霧測試，返回流量，關閉事件，進行驗屍。

C.秘密進入公關

1.召回鑰匙/令牌，使用旋轉。
2.重寫歷史記錄/從緩存中刪除工件,正式完成RCA。
3.將規則添加到秘密掃描儀中,訓練命令。

15）反模式

手動「在銷售」編輯沒有痕跡和回滾。
Configs沒有方案，也沒有驗證。
沒有KMS/Vault的Git/CI變量中的秘密。
Monorepo等同於「全球超級權利」。
「無聲」GitOps，沒有漂移濾鏡和應用日誌。
巨大的公關「一勞永逸」是模糊的歸因和高風險。

16）支票單

在merge之前

• 已通過電路和Linters
• OPA/Conftest綠色政策"
• Secret-scan-「幹凈」
• 附有計劃/diff，風險評估，backout準備就緒
• 2 apruva （prod）和SoD遵守

在deploy之前

• 已驗證發布窗口和日歷
• Drift監控處於活動狀態
• SLO Gardrails設置,煙霧測試就緒

每月一次

• 按時間表旋轉密鑰/證書
• 業主和權利清單
• 修訂ORA/例外規則 （TTL）
• 花花公子事件測試（火爆）

17）設計技巧

將更改分解為小誹謗；一個公關是一個目標。
具有RFC/風險/回滾功能的 PR/commit強制模板。
對於動態配對，請使用帶有審核和滾回的「配對中心」。
轉化電路；禁止破裂而不會遷移。
可視化「configs地圖」：什麼，在哪裏，由誰管理。

18）與更改和事件管理集成

PR ↔ RFC ↔發布日歷↔事件/後模擬。
自動匹配度量（SLO/Business）到config版本。
自動創建刪除舊標誌/異常的任務（TTL）。

19）結果

配置審核不是「紙質報告」，而是可靠性的操作機制：configs-數據，更改是可控制和可驗證的，秘密是鎖定的，整個歷史是透明和可驗證的。因此，建立了一個可持續的，可支持和可預測的平臺。