Acceso y auditoría

El editor de datos otorga acceso directo a la base de datos, así que está deliberadamente acotado con RBAC, auditoría y un modelo de conexión exclusivamente del lado del servidor.

RBAC — lectura frente a escritura

El acceso se aplica por recurso mediante el control de acceso basado en roles de Pier:

Acción	Rol mínimo
Explorar bases de datos / esquemas / tablas / colecciones / claves	Viewer
Ver estructura, filas, documentos, valores de claves	Viewer
SQL Runner (cualquier sentencia)	Editor
Mongo Shell (cualquier script)	Editor
Comando Redis (cualquier comando)	Editor

La separación es intencional: a un compañero de equipo se le puede dar visibilidad de solo lectura sobre los datos de producción sin la capacidad de modificarlos. Cualquier cosa que pudiera escribir — cada runner, sin importar si la sentencia concreta resulta ser un SELECT — requiere Editor.

Log de auditoría

Cada ejecución del runner se registra en la tabla db_query_log, tenga éxito o falle. Cada fila captura:

• Quién — id de usuario y nombre de usuario.
• Dónde — el servicio y la base de datos de destino.
• Qué — el texto del SQL / comando / script, y su tipo (read, write, redis, mongo).
• Resultado — estado (ok / error), recuento de filas, duración y el mensaje de error en caso de fallo.

El registro es de mejor esfuerzo y nunca bloquea una consulta — un fallo al escribir la auditoría no enmascarará una sentencia exitosa (o fallida). Las lecturas de exploración no se registran; el rastro de auditoría se centra en los runners, que son las acciones que pueden cambiar datos.

Credenciales

Las credenciales de conexión provienen del entorno cifrado del servicio (env_json, AES-256-GCM en reposo) y se descifran en memoria solo en el momento de la petición. Estas:

• nunca se muestran en la interfaz,
• nunca se escriben en los logs,
• se leen de las variables estándar de la imagen — POSTGRES_USER / POSTGRES_PASSWORD, MYSQL_ROOT_PASSWORD (o MARIADB_ROOT_PASSWORD), MONGO_INITDB_ROOT_USERNAME / MONGO_INITDB_ROOT_PASSWORD, REDIS_PASSWORD.

Modelo de conexión

Pier core se ejecuta en el host y alcanza cada base de datos a través de la red Docker pier-net — la IP y el puerto internos del contenedor — recurriendo a 127.0.0.1:{host_port} solo cuando un puerto está publicado. Esto significa que:

• Una base de datos privada nunca tiene que exponerse a internet para que la inspecciones.
• El tráfico permanece en el bridge interno de Docker entre el proceso del host y el contenedor.

Seguridad frente a inyección (SQL)

Para el explorador SQL, los identificadores (nombres de esquema/tabla/columna) llegan como parámetros pero nunca se confía en ellos a ciegas:

• se confirma que el par (schema, table) existe vía information_schema antes de que ningún SQL construido como cadena lo toque,
• cada identificador y literal se entrecomilla según el motor,
• los nombres de columna provienen siempre del catálogo, nunca del cliente.

El SQL Runner en sí ejecuta la sentencia del operador tal cual — ese es el sentido de un runner — que es exactamente por lo que está protegido tras Editor y completamente auditado.

Próximos pasos

• Resumen — motores compatibles y dónde encontrar la pestaña Data.
• SQL Runner — límites y comportamiento del runner de SQL.