Seguridad y servidor multiusuario

Este capítulo reúne lo que hace OmniDB para proteger las credenciales guardadas y un servidor compartido y multiusuario, y lo que eso significa para usted como administrador o usuario. Para instalar y exponer el servidor, consulte Despliegue de omnidb-server; para la gestión de contraseñas desde la línea de comandos, consulte Herramienta de configuración de OmniDB.

En lo sucesivo, «modo servidor» significa omnidb-server iniciado sin -A: una instancia multiusuario en la que las personas inician sesión desde un navegador, tanto si escucha solo en loopback como en una dirección de red (-H). La aplicación de escritorio es siempre monousuario.

Las contraseñas guardadas están cifradas

Las contraseñas de base de datos guardadas en una conexión, las contraseñas/frases de contraseña SSH y las claves privadas SSH se cifran (AES-256-GCM) antes de escribirse en la base de datos de usuario de OmniDB, omnidb.db. La clave de cifrado no se guarda en ese archivo: se conserva en el almacén de secretos del sistema operativo (el llavero de macOS, el Administrador de credenciales de Windows o Secret Service en Linux), de modo que una copia de omnidb.db por sí sola no las revela.

Cuando no hay ningún almacén de secretos accesible (normalmente, un servidor Linux sin entorno gráfico), OmniDB guarda en su lugar la clave en un archivo llamado .connection_secret_key (legible solo por su propietario) en el directorio home de OmniDB; una vez que ese archivo existe, se usa siempre. En ese caso:

• haga una copia de seguridad del archivo de clave junto con omnidb.db y proteja ambos por igual;
• si se pierde la clave, los secretos almacenados no se pueden recuperar: las conexiones siguen existiendo, pero hay que volver a introducir sus contraseñas y claves SSH.

Las entradas sin cifrar existentes de versiones anteriores se cifran automáticamente la primera vez que se inicia una versión más reciente. Si prefiere no guardar ninguna contraseña, déjela vacía en el formulario de la conexión: OmniDB se la pide cuando la necesita y la mantiene solo en memoria, durante 30 minutos, para su sesión (consulte Creación de usuarios y conexiones).

La cuenta inicial admin

Una instalación nueva en modo servidor crea un superusuario, admin, con una contraseña aleatoria que se muestra una sola vez en la salida de registro del servidor:

omnidb-server: initialized a new app database — initial login: admin / <password> (shown only once; change it under Settings, or run: omnidb-server --set-password admin)

Inicie sesión con ella y cámbiela en Configuración > Contraseña, o establezca de antemano la contraseña que prefiera desde la línea de comandos:

omnidb-server --set-password admin [-d /path/to/homedir]

La aplicación de escritorio nunca muestra una página de inicio de sesión; inicia sesión automáticamente en su propio servidor local, que solo escucha en loopback.

Protección del inicio de sesión y sesiones

• Tras 10 intentos fallidos de inicio de sesión para el mismo nombre de usuario, o desde la misma dirección de cliente, en 15 minutos, los intentos siguientes se rechazan con Demasiados intentos fallidos de inicio de sesión. Inténtelo de nuevo en 15 minutos. Los contadores se mantienen en memoria y se restablecen al reiniciar el servidor. Detrás de un proxy inverso, la dirección del cliente es la dirección del proxy.
• Eliminar un usuario finaliza de inmediato todas sus sesiones, y retirar la condición de superusuario surte efecto de inmediato. Cambiar una contraseña (en Configuración o con --set-password) se aplica al instante a los nuevos inicios de sesión; una contraseña cambiada en Configuración cierra además las demás sesiones de ese usuario.

Restricciones en modo servidor

Como todas las conexiones de un servidor multiusuario las abre el proceso del servidor, en la máquina del servidor, se restringen algunas opciones de conexión que leerían archivos del propio servidor:

• Las conexiones SQLite (una base de datos SQLite es un archivo en el servidor) solo pueden crearlas y usarlas los superusuarios de OmniDB. No pueden apuntar al interior del propio directorio home de OmniDB, y se rechazan las URI file:.
• Las cadenas de conexión de PostgreSQL no pueden usar los parámetros passfile, servicefile, service, sslkey, sslcert, sslrootcert, sslcrl ni sslcrldir.

Estas restricciones no se aplican a la aplicación de escritorio, donde los archivos son suyos.

Conexiones públicas

Una conexión marcada como ¿Conexión pública? puede usarla cualquier usuario de OmniDB del servidor, pero solo su propietario puede editarla. Para todos los demás:

• la contraseña guardada nunca se envía a su navegador, y una contraseña incluida en la cadena de conexión se muestra enmascarada;
• Probar conexión siempre prueba el servidor, el puerto y la base de datos almacenados: cambiar antes esos campos en el formulario no redirige la contraseña almacenada a otro lugar.

Archivos exportados

Las exportaciones de consultas y de DBML se escriben en la carpeta temp del servidor con nombres aleatorios, y solo puede descargarlas el usuario que las creó. Se eliminan automáticamente pasadas 24 horas.

Claves de host SSH

Los túneles SSH y las conexiones de terminal SSH verifican la clave de host del servidor con el archivo ~/.ssh/known_hosts del usuario del sistema operativo que ejecuta omnidb-server. Una clave de host desconocida o modificada se rechaza: OmniDB no confía en silencio en un host en el primer uso. Añada el host una vez desde esa cuenta, por ejemplo:

ssh [email protected]        # accept the key once
# or
ssh-keyscan ssh-server.example.com >> ~/.ssh/known_hosts

Exposición en la red

No hay TLS integrado. Mantenga omnidb-server en 127.0.0.1 (el valor predeterminado) detrás de un proxy inverso con terminación TLS, en lugar de exponer HTTP sin cifrar con -H 0.0.0.0; consulte Despliegue de omnidb-server. Mientras está vinculado a loopback, el servidor solo responde a solicitudes dirigidas a 127.0.0.1, localhost o [::1] con su propio puerto, lo que lo protege frente a ataques de DNS rebinding desde páginas web. Las cookies de sesión se marcan como Secure cuando la solicitud llega por TLS o con X-Forwarded-Proto: https, y todas las solicitudes que modifican el estado están protegidas contra la falsificación de solicitudes entre sitios (CSRF).