Descripción general de la arquitectura de seguridad de Mandraki

Nota: Este artículo describe la arquitectura y diseño de Mandraki. Algunas características discutidas se están implementando progresivamente y pueden no estar aún disponibles en todos los planes.

La arquitectura de seguridad no es una lista de características. Es el conjunto de decisiones estructurales que determinan cómo se comporta un sistema cuando las cosas salen mal — cuando un atacante obtiene acceso, cuando un gobierno emite una citación, cuando un empleado comete un error, cuando un disco duro es robado. Este artículo proporciona una descripción general integral de la arquitectura de seguridad de Mandraki, incluyendo los principios que guían nuestro diseño, los sistemas criptográficos que empleamos, y los controles operacionales que unen todo.

Principios de diseño

Cuatro principios sustentan cada decisión de seguridad en Mandraki.

Defensa en profundidad. Ningún control simple debe ser la diferencia entre seguridad y compromiso. Cifrado en reposo, cifrado en tránsito, cifrado de extremo a extremo, controles de acceso, logging de auditoría, y segmentación de red trabajan en concierto. Un fallo en una capa debe ser contenido por las otras.

Principio de menor privilegio. Los usuarios, servicios, y componentes de infraestructura tienen el mínimo acceso requerido para su función. El servidor de base de datos no es accesible desde la internet pública. El SFU maneja medios pero no tiene acceso a la base de datos de aplicación. Los endpoints de API requieren autenticación y autorización a nivel de organización.

Transparencia. Los reclamos de seguridad deben ser verificables. Documentamos nuestros formatos de cifrado, prácticas de gestión de claves, y opciones de protocolo en detalle técnico. No confiamos en la oscuridad.

Soberanía por diseño. Cada componente — infraestructura, aplicación, entidad corporativa — cae dentro de la jurisdicción de la UE. Esto no es una configuración de despliegue; es una propiedad estructural del sistema.

La jerarquía de cifrado de tres capas

Mandraki usa cifrado de sobre con tres capas, un patrón comúnmente usado por proveedores de nube e instituciones financieras por su balance de seguridad, rendimiento, y flexibilidad de gestión de claves.

Capa 1: Clave Maestra. La raíz de la jerarquía de claves. En despliegues estándar, esta es una clave AES de 256-bit derivada de la variable de entorno MASTER_KEY. En despliegues BYOK, esto es reemplazado por el material de clave del cliente (AWS KMS ARN, referencia de Azure Key Vault, o clave importada manualmente). La Clave Maestra nunca cifra datos directamente — envuelve Claves de Organización.

Capa 2: Claves de Organización. Una por organización. Cada Clave de Org es una clave AES de 256-bit generada por Mandraki y almacenada en la base de datos envuelta (cifrada) por la Clave Maestra. Para usar una Clave de Org, es desenvuelta en memoria, cacheada en un caché LRU con TTL de cinco minutos, y descartada después del uso. Las claves desenvueltas nunca se escriben a disco o se almacenan en Redis. Las Claves de Org envuelven Claves de Cifrado de Datos.

Capa 3: Claves de Cifrado de Datos (DEKs). Múltiples por organización, una por propósito: mensajes, archivos, grabaciones, transcripciones. Cada DEK es envuelta por la Clave de Org de su organización. Los DEKs realizan el cifrado de datos actual usando AES-256-GCM. El formato de salida cifrada es [version:1B][iv:12B][authTag:16B][ciphertext], empaquetado en un único campo binario.

Esta jerarquía permite rotación eficiente de claves. Rotar una Clave de Org requiere re-envolver los DEKs (una operación de envoltura de clave) pero no re-cifrar todos los datos subyacentes. Rotar un DEK significa que los nuevos datos usan la nueva clave mientras que los datos antiguos permanecen legibles a través del DEK anterior retenido (marcado como ROTATED).

Cifrado de extremo a extremo

La jerarquía de tres capas descrita arriba es cifrado del lado del servidor — protege datos en reposo en la infraestructura de Mandraki. El cifrado de extremo a extremo va más allá asegurando que el servidor nunca ve texto plano.

Mensajería (MLS). Usamos el protocolo Messaging Layer Security (MLS), estandarizado como RFC 9420 por el IETF. MLS fue diseñado específicamente para escenarios de mensajería grupal y ofrece varias ventajas sobre enfoques más antiguos.

MLS usa una estructura de acuerdo de clave basada en árbol llamada TreeKEM, que permite que un grupo de participantes establezca un secreto compartido eficientemente. Cuando un miembro se une o sale de un grupo, el material de clave se actualiza a través de un mensaje de Commit que avanza la época del grupo. Esto proporciona secreto hacia adelante — comprometer las claves de un miembro en un punto en el tiempo no revela mensajes de épocas anteriores — y seguridad post-compromiso — el grupo recupera seguridad después de un compromiso tan pronto como el material de clave del miembro afectado es rotado.

Cada dispositivo de usuario sube paquetes de clave MLS al servidor. Estos son haces criptográficos de uso único que permiten a otros dispositivos agregarlos a un grupo sin requerir que el dispositivo esté en línea en ese momento. Cuando un paquete de clave es consumido, el dispositivo debe subir nuevos. El servidor almacena y distribuye estos paquetes pero nunca tiene acceso al material de clave privada que contienen.

Los grupos de MLS en Mandraki se mapean a canales e hilos de mensaje directo. Cuando envías un mensaje en un canal cifrado, tu cliente lo cifra usando la clave de época actual del grupo. El servidor recibe el cifrado, lo almacena, y lo distribuye a miembros del grupo. Sus clientes lo descifran localmente.

Cifrado de medios (SFrame)

Cifrar medios en tiempo real — audio y vídeo en una llamada grupal — presenta desafíos diferentes de la mensajería. La tolerancia de latencia se mide en milisegundos, no segundos. Las tasas de datos son órdenes de magnitud más altas. Y los medios pasan a través de una Unidad de Reenvío Selectivo (SFU), que necesita enrutar paquetes a los participantes correctos sin poder ver el contenido.

Usamos SFrame (RFC 9605) para cifrado de medios, aplicado vía la WebRTC Encoded Transform API. Esta API permite que código JavaScript intercepte fotogramas de medios codificados después de la codificación pero antes de la empaquetización, los cifre, y pase el cifrado a la capa de transporte. En el extremo receptor, los fotogramas se descifran después de la reensamblaje pero antes de la decodificación.

La ventaja clave de SFrame en una arquitectura de SFU es que el SFU aún puede realizar su función de enrutamiento — reenviando paquetes de un participante a otros, tomando decisiones adaptativas de ancho de banda sobre qué capas reenviar — sin jamás tener acceso a los medios de texto plano. El SFU ve fotogramas cifrados y los reenvía como blobs opacos.

Los intercambios sobre los que somos honestos

El cifrado de extremo a extremo no es gratis. Introduce restricciones reales que creemos valen la pena reconocer.

La búsqueda del lado del servidor no es posible en contenido E2EE. Si los mensajes se cifran con claves que el servidor no sostiene, el servidor no puede indexarlos para búsqueda. Mandraki aborda esto manteniendo un índice de búsqueda cifrado local en el cliente usando IndexedDB. Esto proporciona búsqueda por-dispositivo pero no soporta búsqueda de historial entre dispositivos para mensajes recibidos antes de que un dispositivo fuera agregado al grupo.

Las características de IA del lado del servidor son mutuamente exclusivas con E2EE. Nuestras características de transcripción de IA y resumen requieren acceso del lado del servidor a audio de texto plano. Una llamada o canal no puede tener tanto E2EE como características de IA habilitadas simultáneamente. Esto se hace cumplir arquitectónicamente, no solo por política. Las organizaciones eligen a nivel de llamada o canal qué modelo prefieren.

Los nuevos dispositivos ven mensajes solo desde el punto de unión en adelante. Cuando agregas un nuevo dispositivo a tu cuenta, puede descifrar mensajes desde el momento en que se une al grupo de MLS en adelante. Los mensajes históricos cifrados bajo épocas anteriores no son accesibles en el nuevo dispositivo. Esta es una propiedad fundamental del secreto hacia adelante. Estamos explorando mecanismos de respaldo seguro que permitirían a los usuarios exportar historial de mensajes cifrados a un nuevo dispositivo, pero esto permanece en progreso.

La gestión de claves añade complejidad. Cada dispositivo debe mantener material de clave, subir paquetes de clave frescos, y procesar actualizaciones de estado de grupo. Invertimos esfuerzo de ingeniería significativo en hacer esto invisible para los usuarios. El objetivo es que el cifrado no sea algo que configures o pienses — simplemente sucede.

E2EE y cifrado del lado del servidor coexisten

Vale la pena notar que la capa E2EE de Mandraki y nuestro cifrado del lado del servidor (la jerarquía de claves de tres capas descrita en nuestra arquitectura de seguridad) sirven propósitos complementarios. El cifrado del lado del servidor protege datos en reposo en nuestra infraestructura — si un disco es robado o una copia de seguridad de base de datos es comprometida, los datos son ilegibles sin las claves de cifrado. E2EE va más allá asegurando que el servidor nunca vea texto plano en primer lugar.

Para organizaciones que habilitan E2EE, ambas capas están activas simultáneamente. Los datos se cifran de extremo a extremo por los clientes y también se cifran en reposo en el servidor. Cinturón y tirantes.

Creemos que el cifrado de extremo a extremo debería ser el predeterminado para comunicaciones sensibles, no un add-on premium o una casilla que la mayoría de usuarios nunca encuentran. Mandraki lo hace directo de habilitar, transparente en sus limitaciones, y robusto en su implementación.