安全与规范

这一页不尝试替代完整安全白皮书，而是聚焦部署和使用时最容易被忽略的边界：哪些端口不该直接暴露、哪些数据不适合直接发往公网模型，以及发现产品问题后应该如何反馈。

公网暴露注意事项

Flocks 默认更偏向本机运行，这本身就是一种安全边界。只有在你显式把监听地址改成 0.0.0.0 时，外部主机才有机会访问服务。

推荐暴露策略

如果必须远程访问，建议优先采用下面的方式：

• 只对外开放 WebUI
• 后端 API 继续保持本机访问
• 配合安全组、防火墙或反向代理做访问控制

相比同时暴露 5173 和 8000，这种方式更适合多数团队的实际风险承受能力。

为什么不要直接把 API 裸露到公网

一旦后端 API 直接暴露到公网，你面对的就不只是页面访问问题，而是：

• 更大的攻击面
• 未授权访问风险
• 接口被直接探测和调用的风险

因此，即便在测试环境中，也不建议长期把后端直接对公网开放。

部署前的最小检查项

建议至少确认：

1. 是否真的需要外网访问
2. 是否只开放了必要端口
3. 是否有防火墙白名单或可信网段限制
4. 是否通过反向代理或统一入口做了收口

数据与脱敏说明

关于“发送给模型之前做了哪些脱敏”，现有公开资料更适合给出原则性说明，而不是承诺一个通用、自动、无例外的脱敏流程。因此在生产环境里，建议你把注意力放在数据边界本身，而不是默认系统一定已经替你处理完全部敏感信息。

推荐原则

• 高敏感数据优先使用内网模型或私有模型
• 对公网模型服务，先审查本组织的数据出站策略
• 对原始日志、告警原文、样本内容等高敏感输入，先判断是否需要做预处理

哪些内容需要特别谨慎

通常需要谨慎评估的包括：

• 含账号、令牌、口令或密钥的配置
• 原始攻击样本或恶意负载
• 带有大量内网资产信息的原始告警
• 需要满足合规约束的业务数据

如果你不确定应该怎样处理，最保守的做法始终是：

• 先减少原始敏感数据外发
• 再评估是否必须使用公网模型
• 最后决定是否在中转流程里增加脱敏或裁剪步骤

治理边界怎么理解

Flocks 更适合作为分析和编排平台，而不是默认承担你组织所有数据治理责任的黑盒系统。真正的安全落地，仍然需要结合你的模型部署位置、网络边界、日志规范和合规要求一起设计。

反馈渠道

如果你发现的是普通功能问题、文档问题或使用疑问，建议优先走公开反馈渠道；如果你发现的是疑似漏洞、安全配置风险或历史版本受影响问题，则应走更明确的安全反馈路径。

常规反馈

适合：

• 文档缺失
• 使用体验问题
• 一般功能异常

这类问题通常可以通过：

• 官方仓库 Issue
• 社区或产品团队的公开沟通渠道

安全相关反馈

适合：

• 疑似产品漏洞
• 未授权访问风险
• 历史版本安全隐患
• 涉及敏感数据处理边界的问题

这类问题更建议直接联系官方安全反馈渠道、产品团队或指定联系人，而不是只在公开讨论区简单留言。

一个实用建议

如果你在升级或部署后怀疑自己受到历史版本问题影响，优先做三件事：

1. 对照官方公告确认受影响版本范围
2. 检查自己的部署时间和运行版本
3. 再决定是否需要升级、回滚或补充防护措施

这样会比一上来就重装系统或大面积改配置更稳妥。