操作和管理→配置审核

配置审核

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-数据，更改是可控制和可验证的，秘密是锁定的，整个历史是透明和可验证的。因此，建立了一个可持续的，可支持和可预测的平台。