尝试将云架构（CAF / Zero Trust）与 IaC 验证结合

Source: Dev.to

我们常说架构定义意图，而基础设施即代码（IaC）定义实现。
在实际操作中，它们很快就会出现偏差。

• 架构 存在于文档中（CAF、Zero Trust、内部 HLD）
• IaC 反映了实际部署的内容
• 没有可靠的方法来验证两者是否匹配

问题

IaC 提供了精确性，但缺乏意义。
架构提供了意义，但缺乏验证。

于是我们会陷入以下情况：

• 系统“已正确部署”
• 但在架构上是错误的

我们只能在审查、审计或事故中才发现这种不匹配。

小实验

我构建了一个小型 PoC，探索是否可以将架构表示为结构化模型，并对 Terraform 状态进行验证。

思路：

Risk → Control → Constraint → Implementation → Validation

模型不是验证单个资源，而是允许在多个层级上评估架构。

映射层级

• PASS – 资源符合预期配置
• FAIL – 资源存在但配置错误
• MISSING – 资源不存在

控制层级

• FAILED – 至少有一个映射失败
• INCOMPLETE – 部分实现
• MISSING – 完全未实现

风险层级

• EXPOSED – 控制未完全实现

示例

在演示场景中：

• 一个控制因参数不匹配而失败
• 另一个仅部分实现
• 再一个因标签不匹配而失败
• 还有一个完全缺失

验证器将这些汇总为：

FAILED control → EXPOSED risk

因此不再是问：

“这个资源符合要求吗？”

而是可以问：

“这个架构风险是否已暴露？”

探索目的

这 不是 要取代 IaC 或策略引擎。
而是引入一个额外层：

• 将架构意图（风险 / 控制）
• 与实现（Terraform）关联
• 并持续验证这种关联

未解之问

我仍在探索这种做法在我的使用场景之外是否有意义。感兴趣的几个问题：

• 这种模型在真实环境中真的有帮助吗？
• “控制层级”验证是否有价值，还是过度工程？
• 在大型架构中如何扩展？
• 哪些情况下会失效？

仓库

我已经整理了一个小型可运行的 PoC，包含：

• 一个简单的架构模型（YAML）
• 针对 Terraform 状态的验证器
• 展示不同失败模式的演示

👉

欢迎分享想法，尤其是使用 Terraform、Azure 或安全架构的朋友。