后端前端人工智能RAG知识图谱知识管理搜索引擎【免费下载链接】utopiaWorlds first open-source enterprise world model.项目地址https://gitcode.com/gh_mirrors/ont/utopia点击查看免费下载Utopia 是一款面向企业的开源世界模型当前处于 v0.1 阶段。本指南以仓库中的 SECURITY.zh-CN.md 为骨架完整梳理它在部署到公网之前必须处理的风险、已经落地的七层安全机制凭据静态加密、JWT 密钥生成、受限数据库角色、数据源授权、问数只读闸、账号停用、argon2 口令哈希及其对应的源码实现帮助你在上线前完成一次可验证的安全加固。读完本文你将掌握每个安全项的配置变量、底层原理与验证方法。一、先认清现状v0.1 的已知限制不是漏洞报告安全文档开篇就明确了立场下面列出的已知、尚未解决的限制是设计上还没走到的地方而不是待报告的漏洞。对于 v0.1 版本这意味着默认配置刻意偏向开发便利例如数据库默认口令utopia依赖端口只绑回环来兜底部分高级安全能力如受限运行角色、数据源授权是可选启用的需要部署者显式配置备份、密钥轮换等运维环节需要部署者自己承担如备份数据目录时必须连同封印钥匙一起带走。理解这一前提才不会把默认口令误当作安全承诺。接下来的每一节都对应文档中的一条并给出仓库内的实现依据。二、部署到公网之前两个必须先处理的默认风险文档给出了两条硬性提醒这是任何公网部署的起点。1. 数据库默认口令与端口绑定默认数据库口令是utopia。在 docker-compose.yml 中可以看到services: db: environment: POSTGRES_USER: utopia POSTGRES_PASSWORD: ${UTOPIA_DB_PASSWORD:-utopia} ports: - ${UTOPIA_DB_BIND:-127.0.0.1:1517}:5432其中POSTGRES_PASSWORD默认落到utopia端口映射默认只绑回环127.0.0.1:1517宿主机外部连不上compose 里刻意避开 5432 是防本地开发机的 PostgreSQL 撞端口容器内仍是标准 5432应用走 compose 内网连接。如果你改了UTOPIA_DB_BIND把它暴露到外网必须先改掉.env里的UTOPIA_DB_PASSWORD。另外要注意 compose 的一个特性数据库口令只在数据卷首次初始化时生效之后修改.env只改了应用这一侧——这一点在 crates/utopia-server/src/main.rs 的explain_db_error中有明确提示它会直接在日志里给出ALTER USER utopia PASSWORD ...的命令。2. 数据源的安全上限是它的授权文档强调注册数据源是部署级动作而它携带的连接串会到达每一个被授权的工作区。因此只把源授权给该看见那个库的工作区连接串里就要用只读的数据库角色后面提到的 SQL 闸问数只读闸是纵深防御不能替代源头的最小权限。这条原则在 crates/utopia-server/src/api/datasource_routes.rs 的实现中体现为授权与挂载是两层各有各的主人授权由系统管理员决定这个源可以给哪些工作区用挂载时服务端还会再用is_granted二次校验一次——列表过滤不是守卫谁都能自己拼一个 uuid 打过来。三、凭据静态加密AES-256-GCM 封印钥匙不进库文档中这一条是整套安全模型的核心LLM API Key、问数连接串、来源配置里的 token 与推送密钥在进 Postgres 之前用 AES-256-GCM 封印。威胁模型是库泄漏 ≠ 凭据泄漏一份pg_dump、一个只读库账号拿到的都是密文。密钥从哪来钥匙有两个来源且不进数据库环境变量UTOPIA_SECRET_KEY32 字节64 位十六进制或 base64首次启动时在数据目录下生成的secret.keyUnix 下权限0600。加载逻辑在 crates/utopia-server/src/main.rs环境变量优先否则读secret.key读出来解析不了就报错停下——静默生成一把新的会让库里已封的凭据全部打不开。封印格式与幂等性crates/utopia-core/src/secrets.rs 定义了完整格式存储格式enc:v1: base64(12 字节 nonce ‖ 密文tag)封印幂等已封的值再封一次原样返回读路径与写路径都不必先判断没有前缀的值按明文读——这正是升级前落库的旧行会在启动时被补封。从源码看每次封印都会生成全新的随机 nonce测试a_secret_round_trips_and_never_repeats验证了同一明文两次封印结果不同a_tampered_value_does_not_open验证了被篡改的值会直接报错而不是静默回一段乱码——那样会让下游拿乱码去调外部接口错得更远。旧数据补封backfillcrates/utopia-store/src/sealing.rs 的backfill在每次启动时幂等运行覆盖四处凭据存放点llm_settings的四把 keydata_sources.conn_string连接串在 crates/utopia-store/src/datasources.rs 中以secrets::seal落库展示时若开不了则显示(sealed with another key)而不是把密文当 URL 去解析sources.config的凭据键sources.ingest_token。源码注释特别提醒加了新的凭据存放处必须同时加到这里否则那一处会一直是明文而没有任何地方报警。运维要点备份数据目录时把钥匙一起带走——没有它库里的凭据全部读不出来密钥轮换不在这一版换钥匙 用旧钥匙读出、新钥匙写回是一次显式的迁移能同时读到数据目录和库的人登上了服务器不在本层威胁模型内那是服务器访问控制的事。四、JWT 签名密钥首次启动生成没有共用默认密钥文档承诺JWT 签名密钥首次启动生成32 字节 CSPRNG 存入数据库不存在所有部署共用默认密钥这回事。实现上crates/utopia-server/src/main.rsUTOPIA_JWT_SECRET环境变量优先——密钥轮换与多实例显式对齐走这条路未配置时调用ensure_jwt_secret库里没有就现生成一条存进deployment_settings生成函数generate_jwt_secret在 crates/utopia-server/src/auth.rs 中实现取 32 字节是因为 HS256 的 HMAC 块就是 32 字节——再长会被先哈希一遍并不增加强度用 hex 而非 base64是因为这个值会出现在日志、环境变量和运维的复制粘贴里不带/省去一整类转义问题。docker-compose.yml 中UTOPIA_JWT_SECRET:特意只写键名不写值注释解释了原因若给缺省值自动生成就永远走不到所有部署又会共用同一个人人皆知的密钥。同理UTOPIA_MIGRATION_URL、UTOPIA_SECRET_KEY也都采用这种写法——因为${VAR:-}传进容器的是空串而非不传空串会盖掉默认值这是 rc5 起不来的根因 #343。Rust 侧的blank_is_unsetcrates/utopia-core/src/config.rs已经补上了这层防护compose 侧是同一件事的另一半。五、会话 CookieTLS 后面自动打 Secure文档承诺TLS 后面自动给会话 Cookie 打Secure按X-Forwarded-Proto判定本地 HTTP 开发照常。代理不发那个头时用UTOPIA_COOKIE_SECUREtrue强制打开。配置项cookie_secure在 crates/utopia-core/src/config.rs 中默认false由请求的X-Forwarded-Proto判定走 TLS 才打。登录/登出时在 crates/utopia-server/src/api/auth_routes.rs 调用auth::behind_tls(headers, state.cookie_secure)决定 Cookie 是否带Secure。OIDC 流程crates/utopia-server/src/api/oidc_routes.rs还额外使用__Host-前缀的 Cookie 防登录 CSRF——浏览器只接受 Secure、Path/、不带 Domain 的该名字兄弟子域名或明文链路就种不进来。六、最小权限受限运行角色与迁移身份分离文档承诺配置UTOPIA_APP_DB_PASSWORD与UTOPIA_MIGRATION_URL后应用以只读写业务表、对台账只增不改的角色连库迁移另走 owner 身份。角色从哪来docker/init-app-role.sh 在数据库首次初始化时docker-entrypoint-initdb.d约定创建utopia_app角色——注意它可能被 source不是被执行所以脚本里不写exit、不动 shell 选项否则会以 0 退出 entrypoint 导致 db 容器起不来#456。没设UTOPIA_APP_DB_PASSWORD就跳过创建应用继续以 owner 身份运行。权限怎么给权限由迁移 migrations/0010_least_privilege_role.sql 授予而不是在初始化脚本里——那样每次升级都能把新表补进来。要点业务表GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES ... TO utopia_app台账写进、读得到改不动、删不掉——REVOKE UPDATE, DELETE, TRUNCATE ON audit_events未来迁移新建的表/序列/函数通过ALTER DEFAULT PRIVILEGES自动授权否则每加一张表应用就撞权限错误。这段注释点破了此前 owner 连库的隐患ownersuperuser能DROP TRIGGER、改任何表——0026 给台账加的不可变触发器对拿到应用连接串的人形同虚设DISABLE TRIGGER、改记录、ENABLE TRIGGER三条 SQL事后毫无痕迹。受限角色让同样三条 SQL 第一条就报must be owner of table。这一层挡的是应用自身 bug、SQL 注入继承的权限、泄漏出去的连接串挡不住能登进服务器的人容器内 psql 是 trust 认证那个层面属于服务器访问控制。迁移连接串怎么回落crates/utopia-core/src/config.rs 中migration_url()未单独配置时回落为database_url既有部署无需改动即可照常升级。迁移池用完立即释放crates/utopia-server/src/main.rs那个高权限连接不在运行期常驻。七、数据源只到达被授权的工作区文档承诺注册过的库只有在存在明确授权时才能挂进某个知识库。在此之前任何知识库管理员都能挂进任意已注册数据源——多工作区部署下这是跨租户的。实现上是两层crates/utopia-server/src/api/datasource_routes.rs授权登记数据源时登记人所在的每个工作区一并授权要收窄卡片上仍能撤销挂载mountable只列出授权给本工作区的源mount端点再查一次is_granted防止有人直接拼 uuid 绕过列表过滤。这与仓库设计决策 docs/decisions/0014-identity-from-the-person-scope-from-the-token.md身份来自人、范围来自令牌一脉相承也是数据源的安全上限是它的授权的实现注脚。八、问数走只读闸三层防线语句绕过 parser 也写不进去文档承诺问数Ask-the-Data走只读闸——解析白名单、只读事务、强制行数上限三层语句绕过 parser 也写不进去。crates/utopia-server/src/query_engine/mod.rs 的模块注释给出了完整清单sqlparser 解析仅放行单条SELECT/WITH含 CTE拒绝 DML/DDL/多语句/SELECT INTO按引擎选方言PostgreSQL、MySQL、Snowflake、DatabricksTrino 用 Generic 方言作为超集强制外包一层 LIMITROW_CAP 200用 cap1 探测截断第 201 行只用来判断结果是否被截断会话级只读 语句超时PostgreSQL 执行SET default_transaction_read_only onpostgres.rsMySQL 执行SET SESSION TRANSACTION READ ONLYmysql.rsparser 万一漏网也写不进去HTTP 族Trino/Snowflake/Databricks没有会话只有语句超时只读靠第 1 层兜住结果统一为 JSON LinesPG 让库自己转HTTP 族在这里拼列序保留。每类引擎的测试如a_read_only_login_still_sees_the_keys验证了只读角色下 schema 仍可见而写语句被拦在闸外。九、账号是停用不是删除users.deactivated_at文档承诺账号是停用不是删除——users.deactivated_at挡住登录而这个人做过的决定仍可归属地留在台账里。crates/utopia-server/src/api/admin_routes.rs 明确注释不是 DELETE。审计事件、合并日志、改类账本、口径确认的actor_id都指着这个人那些是审计材料——人走了仍然要能回答当时是谁做的。停用只断访问。OIDC 登录查询oidc_routes.rs也以u.deactivated_at IS NULL作为过滤条件。十、口令哈希用 argon2口令以argon2哈希存储实现在 crates/utopia-server/src/auth.rshash_password用SaltString::generate(mut OsRng)生成每用户随机盐verify_password用PasswordHash校验。一个值得注意的对照crates/utopia-store/src/tokens.rs 中个人令牌哈希刻意不用 argon2 而用 SHA-256注释解释了取舍令牌是 244 位高熵随机串不是人选的低熵密码argon2 慢一百万倍也爆不动且 argon2 每行盐不同查不了校验是热路径每次工具调用一次WHERE token_hash $1走唯一索引一次命中。这说明安全设计是按威胁模型分场景选型的并非一律上最慢的算法。十一、报告漏洞文档给出的流程发邮件到 securitydeeplethe.com不要开公开 issue。邮件需写明受影响的版本或提交端点或组件复现步骤。几天内会有回复带修复的版本会在说明中致谢除非你明确不希望。十二、安全加固速查表关注点配置/机制源码依据数据库默认口令utopia暴露端口前改UTOPIA_DB_PASSWORDdocker-compose.yml凭据静态加密UTOPIA_SECRET_KEY或数据目录secret.key0600secrets.rs、main.rsJWT 密钥首次启动 32 字节 CSPRNG 入库UTOPIA_JWT_SECRET覆盖auth.rsCookie Secure按X-Forwarded-Proto自动UTOPIA_COOKIE_SECUREtrue强制auth_routes.rs最小权限角色UTOPIA_APP_DB_PASSWORDUTOPIA_MIGRATION_URLinit-app-role.sh、0010_least_privilege_role.sql数据源授权授权与挂载两层挂载端点二次校验datasource_routes.rs问数只读闸parser 白名单 外包 LIMIT(200) 会话只读query_engine/mod.rs账号生命周期users.deactivated_at软停用admin_routes.rs口令存储argon2 每用户随机盐auth.rs最后回到文档开头的立场v0.1 的默认配置偏向开发便利安全能力大多需要显式启用。上公网之前请把改掉默认口令、检查UTOPIA_DB_BIND、启用受限运行角色、按工作区收紧数据源授权这四件事全部做完再谈其他。仓库是只读的本文只说明查看、安装、运行与配置方式具体加固动作需要你在自己的部署环境中完成。赞分享后端前端人工智能RAG知识图谱知识管理搜索引擎【免费下载链接】utopiaWorlds first open-source enterprise world model.项目地址https://gitcode.com/gh_mirrors/ont/utopia点击查看免费下载相关推荐zk-nvim高级用法自定义命令与API扩展的完整教程zk nvim高级用法自定义命令与API扩展的完整教程 zk nvim是Neovim的终极笔记管理神器专为zk笔记系统打造 如果你已经熟悉了zk nv后端前端人工智能RAG知识图谱知识管理搜索引擎Hyperresearch 16个子代理名册全解每个Agent的角色与模型分配Hyperresearch 16个子代理名册全解每个Agent的角色与模型分配 Hyperresearch 是一个 Agent 驱动的研究知识库agent人工智能深度研究AI AgentMCP 服务wigolo 隐私与安全架构解读本地优先的结构性模型、凭据加密与纵深防御wigolo 隐私与安全架构解读本地优先的结构性模型、凭据加密与纵深防御 wigolo 是一个面向 AI 编码代理的本地优先 Web 情报服务其隐私模型是人工智能AI 应用MCP 服务AI Agent网页爬虫上一篇Hydra Callbacks 事件机制深度指南在 Hydra 配置框架中接入自定义生命周期钩子下一篇MathJax浏览器数学公式渲染的终极解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Utopia 安全模型解读：v0.1 已知边界、凭据静态封印与纵深防御部署指南
后端前端人工智能RAG知识图谱知识管理搜索引擎【免费下载链接】utopiaWorlds first open-source enterprise world model.项目地址https://gitcode.com/gh_mirrors/ont/utopia点击查看免费下载Utopia 是一款面向企业的开源世界模型当前处于 v0.1 阶段。本指南以仓库中的 SECURITY.zh-CN.md 为骨架完整梳理它在部署到公网之前必须处理的风险、已经落地的七层安全机制凭据静态加密、JWT 密钥生成、受限数据库角色、数据源授权、问数只读闸、账号停用、argon2 口令哈希及其对应的源码实现帮助你在上线前完成一次可验证的安全加固。读完本文你将掌握每个安全项的配置变量、底层原理与验证方法。一、先认清现状v0.1 的已知限制不是漏洞报告安全文档开篇就明确了立场下面列出的已知、尚未解决的限制是设计上还没走到的地方而不是待报告的漏洞。对于 v0.1 版本这意味着默认配置刻意偏向开发便利例如数据库默认口令utopia依赖端口只绑回环来兜底部分高级安全能力如受限运行角色、数据源授权是可选启用的需要部署者显式配置备份、密钥轮换等运维环节需要部署者自己承担如备份数据目录时必须连同封印钥匙一起带走。理解这一前提才不会把默认口令误当作安全承诺。接下来的每一节都对应文档中的一条并给出仓库内的实现依据。二、部署到公网之前两个必须先处理的默认风险文档给出了两条硬性提醒这是任何公网部署的起点。1. 数据库默认口令与端口绑定默认数据库口令是utopia。在 docker-compose.yml 中可以看到services: db: environment: POSTGRES_USER: utopia POSTGRES_PASSWORD: ${UTOPIA_DB_PASSWORD:-utopia} ports: - ${UTOPIA_DB_BIND:-127.0.0.1:1517}:5432其中POSTGRES_PASSWORD默认落到utopia端口映射默认只绑回环127.0.0.1:1517宿主机外部连不上compose 里刻意避开 5432 是防本地开发机的 PostgreSQL 撞端口容器内仍是标准 5432应用走 compose 内网连接。如果你改了UTOPIA_DB_BIND把它暴露到外网必须先改掉.env里的UTOPIA_DB_PASSWORD。另外要注意 compose 的一个特性数据库口令只在数据卷首次初始化时生效之后修改.env只改了应用这一侧——这一点在 crates/utopia-server/src/main.rs 的explain_db_error中有明确提示它会直接在日志里给出ALTER USER utopia PASSWORD ...的命令。2. 数据源的安全上限是它的授权文档强调注册数据源是部署级动作而它携带的连接串会到达每一个被授权的工作区。因此只把源授权给该看见那个库的工作区连接串里就要用只读的数据库角色后面提到的 SQL 闸问数只读闸是纵深防御不能替代源头的最小权限。这条原则在 crates/utopia-server/src/api/datasource_routes.rs 的实现中体现为授权与挂载是两层各有各的主人授权由系统管理员决定这个源可以给哪些工作区用挂载时服务端还会再用is_granted二次校验一次——列表过滤不是守卫谁都能自己拼一个 uuid 打过来。三、凭据静态加密AES-256-GCM 封印钥匙不进库文档中这一条是整套安全模型的核心LLM API Key、问数连接串、来源配置里的 token 与推送密钥在进 Postgres 之前用 AES-256-GCM 封印。威胁模型是库泄漏 ≠ 凭据泄漏一份pg_dump、一个只读库账号拿到的都是密文。密钥从哪来钥匙有两个来源且不进数据库环境变量UTOPIA_SECRET_KEY32 字节64 位十六进制或 base64首次启动时在数据目录下生成的secret.keyUnix 下权限0600。加载逻辑在 crates/utopia-server/src/main.rs环境变量优先否则读secret.key读出来解析不了就报错停下——静默生成一把新的会让库里已封的凭据全部打不开。封印格式与幂等性crates/utopia-core/src/secrets.rs 定义了完整格式存储格式enc:v1: base64(12 字节 nonce ‖ 密文tag)封印幂等已封的值再封一次原样返回读路径与写路径都不必先判断没有前缀的值按明文读——这正是升级前落库的旧行会在启动时被补封。从源码看每次封印都会生成全新的随机 nonce测试a_secret_round_trips_and_never_repeats验证了同一明文两次封印结果不同a_tampered_value_does_not_open验证了被篡改的值会直接报错而不是静默回一段乱码——那样会让下游拿乱码去调外部接口错得更远。旧数据补封backfillcrates/utopia-store/src/sealing.rs 的backfill在每次启动时幂等运行覆盖四处凭据存放点llm_settings的四把 keydata_sources.conn_string连接串在 crates/utopia-store/src/datasources.rs 中以secrets::seal落库展示时若开不了则显示(sealed with another key)而不是把密文当 URL 去解析sources.config的凭据键sources.ingest_token。源码注释特别提醒加了新的凭据存放处必须同时加到这里否则那一处会一直是明文而没有任何地方报警。运维要点备份数据目录时把钥匙一起带走——没有它库里的凭据全部读不出来密钥轮换不在这一版换钥匙 用旧钥匙读出、新钥匙写回是一次显式的迁移能同时读到数据目录和库的人登上了服务器不在本层威胁模型内那是服务器访问控制的事。四、JWT 签名密钥首次启动生成没有共用默认密钥文档承诺JWT 签名密钥首次启动生成32 字节 CSPRNG 存入数据库不存在所有部署共用默认密钥这回事。实现上crates/utopia-server/src/main.rsUTOPIA_JWT_SECRET环境变量优先——密钥轮换与多实例显式对齐走这条路未配置时调用ensure_jwt_secret库里没有就现生成一条存进deployment_settings生成函数generate_jwt_secret在 crates/utopia-server/src/auth.rs 中实现取 32 字节是因为 HS256 的 HMAC 块就是 32 字节——再长会被先哈希一遍并不增加强度用 hex 而非 base64是因为这个值会出现在日志、环境变量和运维的复制粘贴里不带/省去一整类转义问题。docker-compose.yml 中UTOPIA_JWT_SECRET:特意只写键名不写值注释解释了原因若给缺省值自动生成就永远走不到所有部署又会共用同一个人人皆知的密钥。同理UTOPIA_MIGRATION_URL、UTOPIA_SECRET_KEY也都采用这种写法——因为${VAR:-}传进容器的是空串而非不传空串会盖掉默认值这是 rc5 起不来的根因 #343。Rust 侧的blank_is_unsetcrates/utopia-core/src/config.rs已经补上了这层防护compose 侧是同一件事的另一半。五、会话 CookieTLS 后面自动打 Secure文档承诺TLS 后面自动给会话 Cookie 打Secure按X-Forwarded-Proto判定本地 HTTP 开发照常。代理不发那个头时用UTOPIA_COOKIE_SECUREtrue强制打开。配置项cookie_secure在 crates/utopia-core/src/config.rs 中默认false由请求的X-Forwarded-Proto判定走 TLS 才打。登录/登出时在 crates/utopia-server/src/api/auth_routes.rs 调用auth::behind_tls(headers, state.cookie_secure)决定 Cookie 是否带Secure。OIDC 流程crates/utopia-server/src/api/oidc_routes.rs还额外使用__Host-前缀的 Cookie 防登录 CSRF——浏览器只接受 Secure、Path/、不带 Domain 的该名字兄弟子域名或明文链路就种不进来。六、最小权限受限运行角色与迁移身份分离文档承诺配置UTOPIA_APP_DB_PASSWORD与UTOPIA_MIGRATION_URL后应用以只读写业务表、对台账只增不改的角色连库迁移另走 owner 身份。角色从哪来docker/init-app-role.sh 在数据库首次初始化时docker-entrypoint-initdb.d约定创建utopia_app角色——注意它可能被 source不是被执行所以脚本里不写exit、不动 shell 选项否则会以 0 退出 entrypoint 导致 db 容器起不来#456。没设UTOPIA_APP_DB_PASSWORD就跳过创建应用继续以 owner 身份运行。权限怎么给权限由迁移 migrations/0010_least_privilege_role.sql 授予而不是在初始化脚本里——那样每次升级都能把新表补进来。要点业务表GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES ... TO utopia_app台账写进、读得到改不动、删不掉——REVOKE UPDATE, DELETE, TRUNCATE ON audit_events未来迁移新建的表/序列/函数通过ALTER DEFAULT PRIVILEGES自动授权否则每加一张表应用就撞权限错误。这段注释点破了此前 owner 连库的隐患ownersuperuser能DROP TRIGGER、改任何表——0026 给台账加的不可变触发器对拿到应用连接串的人形同虚设DISABLE TRIGGER、改记录、ENABLE TRIGGER三条 SQL事后毫无痕迹。受限角色让同样三条 SQL 第一条就报must be owner of table。这一层挡的是应用自身 bug、SQL 注入继承的权限、泄漏出去的连接串挡不住能登进服务器的人容器内 psql 是 trust 认证那个层面属于服务器访问控制。迁移连接串怎么回落crates/utopia-core/src/config.rs 中migration_url()未单独配置时回落为database_url既有部署无需改动即可照常升级。迁移池用完立即释放crates/utopia-server/src/main.rs那个高权限连接不在运行期常驻。七、数据源只到达被授权的工作区文档承诺注册过的库只有在存在明确授权时才能挂进某个知识库。在此之前任何知识库管理员都能挂进任意已注册数据源——多工作区部署下这是跨租户的。实现上是两层crates/utopia-server/src/api/datasource_routes.rs授权登记数据源时登记人所在的每个工作区一并授权要收窄卡片上仍能撤销挂载mountable只列出授权给本工作区的源mount端点再查一次is_granted防止有人直接拼 uuid 绕过列表过滤。这与仓库设计决策 docs/decisions/0014-identity-from-the-person-scope-from-the-token.md身份来自人、范围来自令牌一脉相承也是数据源的安全上限是它的授权的实现注脚。八、问数走只读闸三层防线语句绕过 parser 也写不进去文档承诺问数Ask-the-Data走只读闸——解析白名单、只读事务、强制行数上限三层语句绕过 parser 也写不进去。crates/utopia-server/src/query_engine/mod.rs 的模块注释给出了完整清单sqlparser 解析仅放行单条SELECT/WITH含 CTE拒绝 DML/DDL/多语句/SELECT INTO按引擎选方言PostgreSQL、MySQL、Snowflake、DatabricksTrino 用 Generic 方言作为超集强制外包一层 LIMITROW_CAP 200用 cap1 探测截断第 201 行只用来判断结果是否被截断会话级只读 语句超时PostgreSQL 执行SET default_transaction_read_only onpostgres.rsMySQL 执行SET SESSION TRANSACTION READ ONLYmysql.rsparser 万一漏网也写不进去HTTP 族Trino/Snowflake/Databricks没有会话只有语句超时只读靠第 1 层兜住结果统一为 JSON LinesPG 让库自己转HTTP 族在这里拼列序保留。每类引擎的测试如a_read_only_login_still_sees_the_keys验证了只读角色下 schema 仍可见而写语句被拦在闸外。九、账号是停用不是删除users.deactivated_at文档承诺账号是停用不是删除——users.deactivated_at挡住登录而这个人做过的决定仍可归属地留在台账里。crates/utopia-server/src/api/admin_routes.rs 明确注释不是 DELETE。审计事件、合并日志、改类账本、口径确认的actor_id都指着这个人那些是审计材料——人走了仍然要能回答当时是谁做的。停用只断访问。OIDC 登录查询oidc_routes.rs也以u.deactivated_at IS NULL作为过滤条件。十、口令哈希用 argon2口令以argon2哈希存储实现在 crates/utopia-server/src/auth.rshash_password用SaltString::generate(mut OsRng)生成每用户随机盐verify_password用PasswordHash校验。一个值得注意的对照crates/utopia-store/src/tokens.rs 中个人令牌哈希刻意不用 argon2 而用 SHA-256注释解释了取舍令牌是 244 位高熵随机串不是人选的低熵密码argon2 慢一百万倍也爆不动且 argon2 每行盐不同查不了校验是热路径每次工具调用一次WHERE token_hash $1走唯一索引一次命中。这说明安全设计是按威胁模型分场景选型的并非一律上最慢的算法。十一、报告漏洞文档给出的流程发邮件到 securitydeeplethe.com不要开公开 issue。邮件需写明受影响的版本或提交端点或组件复现步骤。几天内会有回复带修复的版本会在说明中致谢除非你明确不希望。十二、安全加固速查表关注点配置/机制源码依据数据库默认口令utopia暴露端口前改UTOPIA_DB_PASSWORDdocker-compose.yml凭据静态加密UTOPIA_SECRET_KEY或数据目录secret.key0600secrets.rs、main.rsJWT 密钥首次启动 32 字节 CSPRNG 入库UTOPIA_JWT_SECRET覆盖auth.rsCookie Secure按X-Forwarded-Proto自动UTOPIA_COOKIE_SECUREtrue强制auth_routes.rs最小权限角色UTOPIA_APP_DB_PASSWORDUTOPIA_MIGRATION_URLinit-app-role.sh、0010_least_privilege_role.sql数据源授权授权与挂载两层挂载端点二次校验datasource_routes.rs问数只读闸parser 白名单 外包 LIMIT(200) 会话只读query_engine/mod.rs账号生命周期users.deactivated_at软停用admin_routes.rs口令存储argon2 每用户随机盐auth.rs最后回到文档开头的立场v0.1 的默认配置偏向开发便利安全能力大多需要显式启用。上公网之前请把改掉默认口令、检查UTOPIA_DB_BIND、启用受限运行角色、按工作区收紧数据源授权这四件事全部做完再谈其他。仓库是只读的本文只说明查看、安装、运行与配置方式具体加固动作需要你在自己的部署环境中完成。赞分享后端前端人工智能RAG知识图谱知识管理搜索引擎【免费下载链接】utopiaWorlds first open-source enterprise world model.项目地址https://gitcode.com/gh_mirrors/ont/utopia点击查看免费下载相关推荐zk-nvim高级用法自定义命令与API扩展的完整教程zk nvim高级用法自定义命令与API扩展的完整教程 zk nvim是Neovim的终极笔记管理神器专为zk笔记系统打造 如果你已经熟悉了zk nv后端前端人工智能RAG知识图谱知识管理搜索引擎Hyperresearch 16个子代理名册全解每个Agent的角色与模型分配Hyperresearch 16个子代理名册全解每个Agent的角色与模型分配 Hyperresearch 是一个 Agent 驱动的研究知识库agent人工智能深度研究AI AgentMCP 服务wigolo 隐私与安全架构解读本地优先的结构性模型、凭据加密与纵深防御wigolo 隐私与安全架构解读本地优先的结构性模型、凭据加密与纵深防御 wigolo 是一个面向 AI 编码代理的本地优先 Web 情报服务其隐私模型是人工智能AI 应用MCP 服务AI Agent网页爬虫上一篇Hydra Callbacks 事件机制深度指南在 Hydra 配置框架中接入自定义生命周期钩子下一篇MathJax浏览器数学公式渲染的终极解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考