远程访问一直是企业安全架构中最脆弱的环节之一。传统的 VPN 方案虽然提供了网络连通性，却将访问决策权完全交给了身份凭证 —— 一旦凭证泄露，攻击者即可在目标网络内横向移动。近年来兴起的零信任架构试图通过持续验证来缓解这一问题，但多数方案仍依赖于预配置的访问策略，缺乏对每次连接请求的实时人工确认。
Tessera 作为开源的同意门控远程访问代理（consent-gated remote access broker），提出了一种更具侵入性控制能力的方案：访问请求必须经过目标主机用户的显式批准，且隧道对中继节点的流量内容保持 "盲态"。这种设计将人的判断重新纳入安全决策链条，同时通过技术手段确保中介无法窥探传输内容。
同意门控的三阶段流程
Tessera 的核心交互遵循 "请求 - 批准 - 隧道" 的三阶段模型。当外部用户需要访问某台主机上的服务时，首先向 Tessera 代理发送连接请求。该请求被推送至主机端的用户界面 —— 可能是一个桌面通知、移动应用或 Web 面板。主机用户查看请求详情后，通过点击 "批准" 操作触发隧道的建立。只有在获得明确同意之后，有作用域的隧道（scoped tunnel）才会在请求者与目标服务之间建立。
这种设计的关键在于将授权决策从自动化策略引擎转移到人工确认环节。相比基于角色或属性的预配置访问控制，同意门控能够应对策略无法覆盖的边界情况。例如，当敏感数据仅在特定时段需要被访问时，主机用户可以基于当前情境判断是否放行，而非依赖静态的 "工作时间" 规则。
盲路由与流量无感知架构
Tessera 的另一核心特性是对流量内容的 "无感知"（blind to your traffic）。这意味着中继节点在转发数据包时，无法解析或记录应用层的内容。实现这一目标的典型技术路径包括端到端加密与盲签名路由。
在端到端加密层面，请求者与目标服务之间建立 TLS 或 Noise 协议隧道，Tessera 代理仅作为传输层的中继，处理的是已加密的流量。代理节点无法获取解密密钥，因此即使被攻破，泄露的也只是连接元数据（如源 IP、目标端口、流量大小和时间模式），而非业务数据本身。
更激进的盲路由方案可能引入类似洋葱路由的多层封装，或采用零知识证明技术验证访问权限而不暴露请求内容。虽然 Tessera 的具体实现细节尚待代码层面的深入分析，但其架构宣言明确将 "流量盲态" 作为核心隐私保证，这要求中继节点在协议设计上就被排除在信任边界之外。
工程实践参数与部署建议
对于希望评估或部署 Tessera 的团队，以下参数值得重点关注：
会话作用域控制：隧道应当被严格限定在批准时声明的目标服务范围内。建议配置细粒度的端口白名单，避免一旦隧道建立后请求者扫描主机上的其他开放服务。
批准超时与撤销机制：为防止用户批准后离开设备导致的安全空窗，应设置合理的会话有效期（如 30 分钟）和空闲超时（如 5 分钟无流量自动断开）。同时需要支持实时撤销，允许主机用户在会话进行中随时终止连接。
元数据最小化：虽然 Tessera 对流量内容无感知，但仍可能收集连接元数据。部署时应配置日志保留策略，仅记录必要的审计信息（如连接时间、双方标识），并设置自动轮转和加密存储。
身份绑定与防重放：批准操作应当与已认证的身份强绑定，防止请求者伪造主机用户身份进行自批准。同时需要防范重放攻击，确保每个批准令牌仅能使用一次且有时效限制。
局限性与风险考量
作为一项新兴开源项目，Tessera 在生产环境的验证尚不充分。其安全边界依赖于代码实现的正确性，而同意门控机制本身也引入了可用性与安全性的权衡 —— 频繁的人工确认可能影响自动化运维场景的效率，而过于宽松的批准流程则可能削弱安全收益。
此外，流量盲态虽然保护了内容隐私，但无法隐藏流量模式。攻击者仍可能通过时序分析和流量指纹推断用户行为，这在高敏感场景中需要额外的混淆措施。
参考来源
- Tessera GitHub 仓库：github.com/emmayusufu/tessera — "Consent-gated remote access broker. One person asks, the host taps Approve, a scoped tunnel opens."
- Hacker News 讨论：news.ycombinator.com/from?site=github.com/emmayusufu
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。