Visión general de la seguridad
Cómo protege TeselaDB los datos en la red, en disco y frente a los usuarios.
TeselaDB arranca seguro: TLS en todos los puertos, usuarios obligatorios y autorización en cada comando. Aquí tienes cada capa y dónde se configura.
Cómo funciona
Cada petición pasa por varias capas de seguridad, desde que llega por la red hasta que queda anotada en el registro de auditoría. Cada capa se configura por separado, con sus propias opciones.
Red
El puerto de clientes solo admite TLS. Entre nodos se habla TLS 1.3 con certificado en los dos extremos, y los dos certificados tienen que estar firmados por la CA del clúster, así que una máquina sin ese certificado no puede unirse ni leer el tráfico.
Identidad
Los drivers se autentican con los mecanismos de MongoDB, de SCRAM a OIDC. La API REST y el servidor MCP usan claves de API, que llevan como mucho los roles del usuario que las creó.
Autorización
Antes de leer los campos de un comando, el nodo comprueba que el usuario tiene los privilegios que ese comando pide sobre esa base y esa colección.
Disco
Arranca el nodo con --enableEncryption y todo lo que guarda en disco va cifrado: los documentos, los índices y el
registro de escritura.
Campos sensibles
Con Queryable Encryption, el driver cifra los campos que marcas antes de enviarlos, y el servidor no ve nunca su valor en claro, ni siquiera al buscar por ellos.
Registro
La auditoría anota cada autenticación y cada autorización denegada. También anota los cambios del catálogo y los de los usuarios y sus roles.
Qué implica para tu aplicación
Tu aplicación necesita un usuario propio con los roles justos y la CA del clúster. Las contraseñas y las claves privadas no aparecen nunca en los logs ni en las métricas.
Límites
--insecure quita TLS y usuarios para pruebas locales y solo escucha en 127.0.0.1. No hay forma de quitar la autorización en un nodo seguro.