安全概览

Pier 的威胁模型假设：

• 运维人员控制服务器和 Pier 二进制文件。
• 即使 SQLite 文件泄露，运维人员也希望密钥保持安全。
• 仪表盘部署在公共互联网上，位于 Traefik TLS 之后。

Pier 的做法

• 静态加密 —— 每个环境变量在存储之前都使用 AES-256-GCM 加密。密钥来自 PIER_SECRET（systemd 从 /opt/pier/.env 中读取）；如果该变量未设置，Pier 会在数据目录中持久化并复用一个 .pier-secret 文件。无论哪种方式，密钥都与数据库分开存放。
• 基于 bcrypt 密码的不透明 Cookie 会话 —— 登录时会签发一个随机的不透明会话 ID，存储在 SQLite 的 sessions 表中（而非 JWT），因此登出和吊销可以在服务端使其失效。密码使用 bcrypt 哈希处理。不依赖任何第三方认证组件。
• 双因素认证（TOTP） —— 可选的基于 TOTP 的双因素认证，配有一次性恢复码。
• 会话加固 —— 会话在空闲超时（默认 8 小时）和绝对最大生命周期（72 小时）后过期，并且可以单独或一次性全部吊销。
• 不回显密钥 —— 除了通过显式的 GET /env 端点之外，API 响应从不返回解密后的环境变量。
• 后端依赖检测 —— Canvas 视图在服务端计算服务之间的关系，因此浏览器永远看不到环境变量的值。
• 权限 —— .env 和 pier.db 均设置为 chmod 600。
• 每日备份 —— 数据库和密钥会被快照到 data/backups/system/；保留 7 份滚动副本。

运维人员必须做的事

• 仅在防火墙上开放 80、443 和 8443 端口。
• 首次设置时使用强管理员密码。
• 将 /opt/pier/.env 文件（以及数据目录中的 .pier-secret 回退文件，如果存在）排除在任何代码仓库之外。单独备份它们。
• 仅在旧密钥已泄露时才轮换 PIER_SECRET —— 轮换需要对所有行重新加密。
• 考虑将仪表盘运行在 VPN 之后，而非公开暴露 8443 端口。Pier 支持这种方式（将仪表盘绑定到 127.0.0.1，并通过 SSH 隧道或 WireGuard/AmneziaWG 链路访问）。

报告漏洞

请将详细信息发送至 /.well-known/security.txt 中的地址。我们会在 72 小时内回复，并在每次发布时公布致谢。