动态凭证

文章借汽车安全演进类比软件安全，指出在 AI 时代，单纯依赖开发者更谨慎、增加审批流程并不能根治泄露问题。真正的风险在于静态密钥、长期Token和人工审核无法跟上代码生成与供应链攻击的速度。作者主张把安全设计前移，改用短生命周期、按需生成、自动轮换的动态凭证，并尽量采用基于身份的无密钥认证，让“泄露”不再直接等于“失陷”。

文章介绍了 SST v3 的代码化基础设施模型，以及它原生的 secrets 管理方式：通过 stage、fallback 和 Secret 组件在 AWS 中加密存储与注入。随后指出其局限，包括缺乏层级继承、集中可视化、细粒度权限、审计、自动轮转和多环境同步能力。最后提出用 Infisical 作为补充方案，借助统一管理、RBAC、审计日志、动态凭证和自动轮转，提升 SST 项目的安全性与运维成熟度。

文章围绕 Ansible 中的密钥管理展开，先介绍 Ansible Vault 的用途、AES256 加密机制、文件级与变量级加密、vault password 的使用方式，以及在 playbook、环境隔离和执行命令中的典型实践。

文章介绍了 Infisical Gateway：一种部署在私有网络内的轻量组件，通过仅出站连接的方式，把 Infisical Cloud 与数据库等内网资源安全连通，而无需开放入站端口。其核心架构包含 Gateway、Relay Server、TURN、QUIC 和 mTLS，数据经过端到端加密，Relay 也无法解密。文章还以私有 PostgreSQL 动态凭证为例说明了安装、注册、连接项目与自动轮换/吊销权限的流程，并强调其适用于零入站安全模型、多云/混合云、合规审计等场景。

本文围绕 MCP Server 的密钥管理展开，指出随着 LLM 与外部工具通过 MCP 连接，服务器往往会同时接触 API Key、数据库凭证等敏感信息，若采用硬编码、长期凭证或缺乏审计与访问控制，容易放大安全风险。文章给出四类实践：避免把密钥写死在代码里；对自定义服务器优先使用短生命周期的动态凭证；对现成 MCP 服务通过 CLI 在运行时注入密钥；并用策略隔离不同服务器的访问范围。整体强调，MCP 的安全底座不只是协议本身，密钥治理才是关键。