Nube cifrada: criterios para elegir un servicio seguro

Google Drive, OneDrive o Dropbox cifran los archivos almacenados, pero el proveedor conserva las claves y puede acceder al contenido en determinadas circunstancias legales o administrativas.

En un servicio con cifrado de extremo a extremo y arquitectura de conocimiento cero, el archivo se cifra en el dispositivo antes de subirlo. El proveedor recibe datos ilegibles y no conserva la clave necesaria para descifrarlos. Este modelo reduce la exposición frente a accesos internos, requerimientos dirigidos al operador y compromisos de la infraestructura central. No elimina todos los riesgos. La implementación criptográfica, la gestión de cuentas, los dispositivos autorizados y las copias de recuperación siguen formando parte de la superficie de ataque.

La elección de un servicio de almacenamiento en la nube cifrado para datos sensibles exige auditar cinco elementos: modelo de cifrado, control de claves, autenticación, jurisdicción y capacidad de recuperación.

El cifrado en reposo no equivale a privacidad completa

El cifrado aparece en casi todas las plataformas comerciales. Pero el término puede describir dos arquitecturas distintas.

En el primer modelo, el proveedor cifra el archivo cuando llega a sus servidores. También protege la comunicación mediante HTTPS y protocolos TLS con secreto perfecto hacia adelante. El contenido no debería viajar en claro ni permanecer sin protección en los discos. Sin embargo, el operador conserva las claves. Puede descifrar el archivo para ofrecer funciones de búsqueda, previsualización, análisis automatizado, detección de abuso o colaboración en línea.

En el segundo modelo, el cifrado se ejecuta antes de la transferencia. La clave se genera y se administra en el dispositivo del usuario o en una estructura bajo su control. El servidor almacena el resultado cifrado. No necesita conocer el contenido para sincronizarlo entre dispositivos.

La diferencia no es terminológica. Determina quién puede responder a una solicitud de acceso, quién puede reconstruir un archivo y qué ocurre si la base de datos del proveedor queda expuesta.

El dato decisivo no es que el servicio anuncie cifrado. Es saber si el proveedor puede reconstruir la clave sin intervención del usuario.

El almacenamiento tradicional puede ser suficiente para documentos de baja sensibilidad. No ocurre lo mismo con historiales médicos, contratos, credenciales, bases de datos de clientes, investigaciones internas, expedientes jurídicos o información que pueda comprometer a una persona si se divulga.

Cómo funciona una arquitectura de conocimiento cero

La expresión «conocimiento cero» se utiliza para describir un modelo en el que el proveedor no conoce la clave de descifrado ni puede derivarla a partir de la contraseña del usuario. El proceso correcto contiene varias fases.

1. Generación local de la clave. El dispositivo crea o recibe el material criptográfico sin enviarlo al servidor en formato utilizable.

2. Derivación protegida desde la contraseña. La contraseña no debería convertirse directamente en una clave mediante una función débil. Algoritmos como Argon2 se utilizan para elevar el coste computacional de los ataques de diccionario.

3. Cifrado del contenido antes de la transferencia. El archivo se transforma localmente y solo después se sincroniza.

4. Protección del tránsito. La conexión utiliza HTTPS y TLS con secreto perfecto hacia adelante. Esto limita el valor de una eventual captura antigua de tráfico.

5. Almacenamiento de objetos cifrados. El servidor conserva el archivo transformado y los metadatos necesarios para sincronizarlo.

6. Descifrado en el dispositivo autorizado. La operación inversa se ejecuta en el equipo que posee las credenciales o claves válidas.

El uso de AES-256 para datos en reposo puede ser una señal técnica correcta, pero no basta para demostrar que existe cifrado de extremo a extremo. AES-256 protege el contenido solo mientras las claves permanezcan fuera del alcance del atacante y del operador. También hay que revisar cómo se generan, almacenan, rotan y recuperan esas claves.

La auditoría debe incluir los metadatos. El nombre del archivo, el tamaño, las fechas de creación y modificación, las direcciones de conexión, la estructura de carpetas y los destinatarios de un enlace pueden quedar visibles aunque el contenido esté cifrado. Un servicio no puede presentarse como completamente privado si protege el documento pero expone de forma amplia su contexto operativo.

El problema de la sincronización

La sincronización añade complejidad. Un archivo cifrado en un ordenador debe abrirse también en un teléfono, una tableta o un segundo equipo. Para ello, el sistema tiene que distribuir claves, autorizar dispositivos y gestionar sesiones.

Cada punto adicional puede introducir una vulnerabilidad:

• Una aplicación modificada puede capturar el archivo antes de cifrarlo.
• Un dispositivo infectado puede leer el contenido después del descifrado.
• Una sesión abierta permite acceder a todos los documentos autorizados.
• Un sistema de recuperación mal diseñado puede dar al proveedor una vía indirecta hacia las claves.
• Una función de previsualización puede crear copias temporales sin el mismo nivel de protección.
• Un enlace compartido puede convertir un documento protegido en un recurso accesible para cualquiera que lo obtenga.

Por este motivo, el análisis no termina en la arquitectura del servidor. Hay que revisar las aplicaciones de escritorio y móviles, el comportamiento del navegador, la gestión de sesiones y el alcance de los permisos.

Qué debe comprobar una organización antes de contratar

La selección debe comenzar por la clasificación de la información. No todos los archivos necesitan la misma arquitectura ni el mismo coste operativo.

Una clasificación básica puede separar:

• Información pública: documentos que pueden difundirse sin impacto relevante.
• Información interna: procedimientos, comunicaciones y material de trabajo no destinado a terceros.
• Información confidencial: contratos, datos financieros, expedientes de personal y documentación comercial.
• Información restringida: datos personales de alto riesgo, credenciales, secretos profesionales, investigaciones o información cuya pérdida pueda generar daño operativo o legal.

El almacenamiento en la nube cifrado para datos sensibles debe reservarse para las dos últimas categorías, salvo que el análisis de riesgos establezca otra cosa. La clasificación permite aplicar el principio de mínimos privilegios: cada persona, aplicación o dispositivo obtiene únicamente el acceso necesario.

Después conviene auditar el servicio con una secuencia concreta.

1. Identificar quién controla las claves

La documentación comercial debe responder sin ambigüedad a estas preguntas:

• ¿El proveedor puede descifrar los archivos?
• ¿Las claves se generan en el dispositivo?
• ¿Existe una clave maestra bajo control del operador?
• ¿La recuperación de contraseña permite recuperar también el contenido?
• ¿El servicio puede entregar archivos legibles ante un requerimiento legal?
• ¿El contenido se descifra en los servidores para habilitar búsqueda o edición?

Si las respuestas no son claras, no debe asumirse que existe conocimiento cero. La ausencia de una explicación técnica es un dato de riesgo.

2. Revisar los algoritmos y la gestión criptográfica

AES-256 es un estándar habitual para el cifrado de datos almacenados. Argon2 puede utilizarse como función de derivación de claves. TLS con secreto perfecto hacia adelante protege la transferencia. HTTPS debe cubrir la totalidad de la sesión web y de las interfaces de programación.

Estos nombres no validan por sí solos el diseño. Hay que comprobar:

• Qué algoritmo protege cada capa.
• Cómo se generan las claves.
• Si las claves se reutilizan entre usuarios o archivos.
• Cómo se rotan tras una incidencia.
• Qué ocurre al revocar un dispositivo.
• Si las copias de seguridad mantienen el mismo cifrado.
• Si las miniaturas, índices y archivos temporales quedan protegidos.
• Si el servicio publica auditorías independientes o informes de seguridad.

Los marcos ISO 27017, PCI DSS, RGPD, FedRAMP, FIPS 140-3, NIST 800-171 e HIPAA pueden aportar referencias útiles. No significan exactamente lo mismo ni cubren el mismo riesgo. Una certificación de cumplimiento no demuestra que el usuario controle las claves. Acredita el cumplimiento de determinados controles, dentro de un alcance concreto.

3. Examinar la autenticación

El cifrado no protege una cuenta cuyo acceso se obtiene mediante una contraseña robada. La autenticación de doble factor debe ser obligatoria para cuentas con información restringida.

Las opciones no tienen la misma resistencia:

• Las aplicaciones basadas en códigos temporales ofrecen una protección superior a la contraseña única.
• Las llaves físicas de seguridad reducen la exposición frente a campañas de suplantación.
• Los códigos enviados por mensaje de texto dependen de la seguridad del número de teléfono y de la operadora.
• Los códigos de recuperación deben almacenarse fuera del dispositivo principal.
• Las sesiones antiguas y los dispositivos perdidos deben poder revocarse de forma inmediata.

Una cuenta corporativa también necesita una política de acceso. El administrador no debería disponer automáticamente de la capacidad de leer todos los archivos. Debe existir separación entre facturación, administración técnica y acceso al contenido. Esta separación reduce el riesgo interno y facilita una auditoría posterior.

4. Analizar la ubicación y la jurisdicción

La localización de los centros de datos afecta a la disponibilidad, la latencia y el marco legal aplicable. También importa la residencia jurídica de la empresa matriz y la cadena de subcontratación.

La ubicación no convierte por sí sola un servicio en seguro. Pero sí determina:

• Qué autoridades pueden solicitar información.
• Qué normas de protección de datos intervienen.
• Dónde se almacenan las copias de respaldo.
• Qué procedimiento se aplica a una transferencia internacional.
• Qué obligaciones contractuales asume el proveedor.
• Cuánto tarda la respuesta ante un incidente.

Una entidad nicaragüense que almacena datos de residentes en otros países debe analizar las obligaciones asociadas a esas personas y a esos territorios. El criterio no puede reducirse a buscar un centro de datos próximo. La latencia es relevante para la operación; la jurisdicción lo es para la gobernanza del dato.

Los servicios cifrados también pueden fallar

El cifrado de extremo a extremo reduce una categoría de riesgos. No transforma una plataforma en invulnerable.

Investigadores del Grupo de Criptografía Aplicada de ETH Zurich detectaron vulnerabilidades en implementaciones criptográficas de varios servicios comerciales, entre ellos Sync.com, pCloud, Icedrive, Seafile, Tresorit, MEGA y Nextcloud. Los problemas analizados podían permitir manipulación o acceso parcial en escenarios con un servidor malicioso o comprometido.

Este dato modifica la forma de evaluar una plataforma. La pregunta no es si el proveedor utiliza una etiqueta correcta. Hay que estudiar la implementación concreta, el código cliente, el protocolo de intercambio de claves y la respuesta ante vulnerabilidades.

La revisión técnica debería cubrir cuatro capas:

1. Cliente. La aplicación que cifra y descifra debe actualizarse con rapidez y distribuirse por canales verificables.

2. Protocolo. El intercambio de claves debe resistir la manipulación del servidor y la suplantación de dispositivos.

3. Servidor. La infraestructura no debería poder sustituir silenciosamente un archivo o una clave sin que el cliente lo detecte.

4. Respuesta. El proveedor debe comunicar vulnerabilidades, publicar correcciones y permitir revocar sesiones o dispositivos afectados.

No se debe afirmar que un servicio es seguro únicamente porque anuncia cifrado de extremo a extremo. Tampoco debe descartarse automáticamente toda plataforma comercial. La evaluación depende del modelo de amenazas, de la sensibilidad del contenido y de las obligaciones legales de la organización.

El cifrado protege el dato. La gobernanza determina quién puede acceder a él, durante cuánto tiempo y con qué trazabilidad.

Compartir archivos sin romper el modelo de seguridad

La colaboración es uno de los puntos más débiles del almacenamiento cifrado. Un sistema puede proteger correctamente los archivos privados y perder esa protección cuando se genera un enlace público.

Antes de compartir un documento, hay que establecer:

• Identidad concreta del destinatario.
• Fecha de caducidad del enlace.
• Permiso de lectura, edición o descarga.
• Posibilidad de retirar el acceso.
• Registro de accesos y modificaciones.
• Prohibición de reenvío cuando el servicio la soporte.
• Protección adicional mediante contraseña independiente.
• Desactivación automática tras completar la operación.

Los enlaces sin autenticación deben reservarse para documentos de baja sensibilidad. La combinación de enlace y contraseña no equivale siempre a una identidad verificada. Cualquiera que obtenga ambos elementos puede acceder al contenido.

En equipos de trabajo, los grupos deben definirse por función y no por comodidad. Un departamento puede necesitar editar una carpeta sin acceder a los expedientes de otra área. Las cuentas compartidas dificultan la trazabilidad y deben evitarse. Cada usuario necesita una identidad individual, autenticación multifactor y permisos revisables.

La auditoría debe registrar quién creó el enlace, quién lo utilizó, cuándo se descargó el archivo y si hubo cambios posteriores. Sin esos datos, una filtración resulta difícil de reconstruir.

Recuperación, copias y pérdida de claves

El conocimiento cero introduce una consecuencia operativa que no debe ocultarse: si el usuario pierde las claves y no existe un mecanismo de recuperación bajo su control, el proveedor puede no tener capacidad para restaurar el contenido.

Esto exige separar tres elementos:

• Contraseña de acceso: permite iniciar sesión.
• Clave de cifrado: permite descifrar los archivos.
• Código o mecanismo de recuperación: permite recuperar la cuenta o reconstruir el acceso según el diseño del servicio.

No todos los servicios mantienen esta separación. En algunos, el restablecimiento de la contraseña puede inutilizar la capacidad de descifrar los archivos antiguos. En otros, existe una clave de recuperación que debe custodiar la organización.

La política interna debe definir:

• Quién custodia la clave de recuperación.
• Cuántas copias existen.
• En qué soportes se almacenan.
• Qué personas pueden utilizarlas.
• Cómo se comprueba que siguen siendo válidas.
• Qué procedimiento se aplica si una persona abandona la organización.
• Cómo se recuperan los datos durante una interrupción del proveedor.

Las copias de seguridad deben probarse mediante restauraciones controladas. Tener una copia no demuestra que sea utilizable. También hay que comprobar si la copia conserva el cifrado, si incluye versiones anteriores y si permite recuperar archivos borrados por error o modificados por un atacante.

Un servicio de sincronización tampoco es una copia de seguridad completa. Si un archivo se elimina o se cifra de forma maliciosa en un equipo, el cambio puede propagarse a otros dispositivos. La organización necesita una estrategia independiente de respaldo, con versiones históricas y acceso restringido.

Errores habituales al elegir una nube segura

La mayoría de los fallos no procede de un algoritmo roto. Procede de una interpretación incorrecta del servicio o de una configuración débil.

Confundir HTTPS con cifrado de extremo a extremo

HTTPS protege el trayecto entre el navegador y el servidor. No determina quién puede leer el archivo una vez almacenado. Es necesario para la seguridad en tránsito, pero no sustituye al cifrado controlado por el usuario.

Dar por válida cualquier mención al cifrado

Una página comercial puede utilizar «cifrado avanzado», «seguridad bancaria» o «protección de grado militar» sin explicar las claves, el cliente ni el proceso de recuperación. Esas expresiones no permiten auditar la arquitectura.

Activar el segundo factor solo después de un incidente

La autenticación multifactor debe configurarse antes de cargar información sensible. También debe probarse el procedimiento de recuperación. Un segundo factor mal custodiado puede bloquear al titular o forzar una excepción insegura.

Conceder permisos permanentes

Los permisos deben tener una finalidad y una duración. Las carpetas compartidas durante meses acumulan usuarios, enlaces y dispositivos que ya no son necesarios.

Ignorar los dispositivos finales

Un archivo se puede cifrar correctamente en origen y quedar expuesto en un ordenador infectado, una memoria sin protección o una carpeta temporal. El cifrado de la nube no sustituye a las actualizaciones, al bloqueo de pantalla, al cifrado del disco y a la protección contra programas maliciosos.

Almacenar las claves junto a la contraseña

La clave de recuperación debe mantenerse separada de las credenciales de uso diario. Si un atacante obtiene ambos elementos en el mismo lugar, la arquitectura pierde parte de su utilidad.

No valorar los metadatos

El contenido puede estar protegido mientras la estructura de trabajo permanece visible. Nombres de clientes, fechas, tamaños de archivos y patrones de acceso pueden revelar información operativa.

Procedimiento de selección y puesta en marcha

La elección puede organizarse en seis pasos. El orden reduce decisiones basadas únicamente en precio, espacio o facilidad de uso.

1. Clasificar los datos. Separar información pública, interna, confidencial y restringida.

2. Definir el modelo de amenazas. Identificar si la prioridad es protegerse frente a un robo de credenciales, un servidor comprometido, un empleado interno, una solicitud legal o la pérdida de un dispositivo.

3. Descartar arquitecturas incompatibles. Si el proveedor controla las claves y la organización necesita impedir el acceso del operador, el servicio no cumple el requisito principal.

4. Auditar la implementación. Revisar algoritmos, clientes, gestión de claves, metadatos, copias y proceso de actualización.

5. Configurar el acceso mínimo. Activar autenticación multifactor, separar funciones administrativas, limitar permisos y establecer caducidad para los enlaces.

6. Verificar la recuperación. Ejecutar una restauración de prueba y comprobar el procedimiento de revocación de dispositivos y cuentas.

La decisión final debe documentarse. El registro debe indicar qué datos se almacenan, qué servicio se utiliza, quién administra las claves, qué jurisdicción interviene, qué controles están activos y cuándo se realizará la siguiente revisión.

La revisión no puede ser única. Los proveedores cambian protocolos, clientes, centros de datos y condiciones contractuales. Una actualización puede mejorar la seguridad o modificar la forma de recuperar los datos. La auditoría debe repetirse cuando cambie el servicio, se produzca un incidente o se incorporen nuevas categorías de información.

Evaluación de impacto

A corto plazo, la adopción de una nube cifrada con conocimiento cero puede limitar algunas funciones: búsqueda sobre el contenido, edición simultánea, recuperación automática y administración centralizada. También aumenta la responsabilidad del usuario sobre las claves y los dispositivos autorizados.

A medio plazo, el beneficio principal es estructural. La organización reduce la dependencia de la confianza depositada en el proveedor. Un compromiso del servidor no ofrece automáticamente archivos legibles. Un requerimiento dirigido al operador no equivale necesariamente a una entrega del contenido. La superficie de exposición se desplaza hacia los dispositivos finales, las credenciales y los mecanismos de recuperación, que pueden auditarse de forma directa.

La conclusión técnica es precisa: para datos sensibles, el cifrado de extremo a extremo y el modelo de conocimiento cero son condiciones de partida, no una certificación de seguridad total. La elección correcta combina criptografía verificable, autenticación multifactor, mínimos privilegios, control de metadatos, jurisdicción compatible y copias recuperables.

Una nube segura no es la que acumula más estándares en su página comercial. Es la que permite demostrar, mediante arquitectura y procedimientos, quién puede descifrar cada archivo y qué sucede cuando una cuenta, un dispositivo o un servidor deja de ser confiable.