访问与审计

数据编辑器交出的是对数据库的直接访问权，因此它被有意地用 RBAC、审计以及仅限服务器端的连接模型加以围护。

RBAC — 读取与写入

访问由 Pier 基于角色的访问控制 按资源 强制执行：

操作	所需最低角色
浏览数据库 / 模式 / 表 / 集合 / 键	Viewer
查看结构、行、文档、键值	Viewer
SQL Runner（任意语句）	Editor
Mongo Shell（任意脚本）	Editor
Redis 命令（任意命令）	Editor

这种划分是有意为之：可以给一位队友 只读 的生产数据洞察权，而不赋予其改动数据的能力。任何 可能 写入的操作 — 每一个运行器，无论具体语句是否恰好是一条 SELECT — 都需要 Editor。

审计日志

每次运行器执行都会被记录到 db_query_log 表中，无论成功还是失败。每一行都记录：

• 谁 — 用户 id 和用户名。
• 何处 — 服务以及目标数据库。
• 何事 — SQL / 命令 / 脚本文本，及其种类（read、write、redis、mongo）。
• 结果 — 状态（ok / error）、行数、耗时，以及失败时的错误消息。

日志记录是尽力而为的，绝不会阻塞查询 — 一次审计写入失败不会掩盖一条成功（或失败）的语句。浏览读取不会被记录；审计轨迹聚焦于运行器，因为它们才是可能改变数据的操作。

凭据

连接凭据来自服务的 加密环境（env_json，静态加密采用 AES-256-GCM），并且只在请求时在内存中解密。它们：

• 绝不在 UI 中显示，
• 绝不写入日志，
• 从标准镜像变量中读取 — POSTGRES_USER / POSTGRES_PASSWORD、MYSQL_ROOT_PASSWORD（或 MARIADB_ROOT_PASSWORD）、MONGO_INITDB_ROOT_USERNAME / MONGO_INITDB_ROOT_PASSWORD、REDIS_PASSWORD。

连接模型

Pier core 运行在主机上，并通过 pier-net Docker 网络 触达每个数据库 — 即容器的内部 IP 和端口 — 仅当某个端口被发布时才回退到 127.0.0.1:{host_port}。这意味着：

• 一个私有数据库 永远无需为了让你检视它而暴露到互联网。
• 流量始终停留在主机进程与容器之间的内部 Docker 网桥上。

注入安全（SQL）

对于 SQL 浏览器，标识符（模式/表/列名）以参数形式到达，但绝不会被盲目信任：

• (schema, table) 这一对会先经由 information_schema 确认存在，任何以字符串拼接构建的 SQL 才会触及它，
• 每个标识符和字面量都会按引擎进行引用转义，
• 列名始终来自目录，绝不来自客户端。

SQL Runner 本身会原样执行操作者的语句 — 这正是运行器的意义所在 — 也正因如此，它被置于 Editor 之后并接受完整审计。

后续步骤

• 概览 — 支持的引擎以及在哪里找到数据标签页。
• SQL Runner — SQL 运行器的限制与行为。