Traiga su propia llave: ¿un placebo?



Comencemos con algunos conceptos básicos: sus datos pueden y deben cifrarse en reposo y en movimiento.

Los datos se pueden cifrar en el lado del cliente o en el lado del servidor. En el ámbito de la seguridad, contamos con mejores prácticas bien conocidas, que incluyen defensa en profundidad (es decir, no depender de una única medida de protección de seguridad) y seguridad por oscuridad, que en realidad no es seguridad.

Esto es lo que está haciendo la industria de la nube, junto con algunas brechas subyacentes. La mayoría de los proveedores de servicios en la nube (CSP) ofrecen traer su propia clave (BYOK) de una forma u otra. Amazon World-wide-web Expert services, por ejemplo, admite las siguientes opciones del servicio de administración de claves (KMS):

  • Solo KMS: Claves administradas por el cliente (CMK) almacenadas en el KMS.
  • KMS con almacén de claves de cliente y CMK: De nuevo, gestionado por el cliente y almacenado en el módulo de seguridad de hardware en la nube (HSM).
  • KMS con HSM de terceros: KMS proporcionado por el cliente con una conexión directa al KMS.

Las claves se retienen en la memoria KMS volátil, lo que significa que una vez que se descifran las claves de cifrado de datos (DEK), se puede acceder a ellas dentro del entorno CSP sin requerir la clave de cifrado de claves (KEK) para cada descifrado o cifrado.

En todas las opciones de implementación enumeradas, las claves de cifrado de datos son generadas por el KMS del CSP y pueden o no ser exportables. La DEK se utiliza para cifrar alcances definidos de datos (por ejemplo, por depósito, día, archivo, etc.) y estas DEK se cifran con la KEK.

Beneficios y riesgos de BYOK

BYOK está destinado a proporcionar a los clientes de la nube más command sobre sus datos alojados. En realidad, cuando se united states of america BYOK, en realidad funciona más como compartir su propia clave (SYOK), ya que una vez que se proporciona la clave al CSP, los clientes no tienen control sobre el uso de la clave. El único beneficio de SYOK, en mi opinión, es garantizar la aleatoriedad clave si no confía en su generador de números aleatorios. De lo contrario, también puede dejar que el CSP genere la clave.

Algunos CSP también ofrecen BYOK en otro modelo y se conecta al hardware del cliente, que almacena y controla la KEK. Hay varios problemas pendientes con este modelo.

Las DEK aún pueden ser accesibles para el proveedor de servicios, a propósito o no, además de un actor malicioso capaz de lograr violar las medidas de protección del CSP técnicamente o mediante ingeniería social, obteniendo así acceso a las DEK, ya sea en memoria, caché, archivos de registro o una foundation de código malicioso. Retener el KEK en la memoria es una espada de doble filo, ya que está realizando SYOK de manera efectiva para un mejor rendimiento. Pero entonces, ¿por qué no simplemente realizar SYOK, en ese caso?

Otro problema es que el proveedor de servicios no puede usar la KEK del cliente para asegurar la DEK. Y la arquitectura, el código y varias ofertas de CSP pueden tener fallas de seguridad que permiten puntos de intercepción. Incluso si los DEK se descifran sobre la marcha, lo que generalmente no se admite ni se recomienda, un problema de comunicación podría paralizar su negocio, impidiendo que se descifren los datos existentes y que se cifren los nuevos DEK.

La confianza también es un elemento clave cuando se trabaja con un CSP. La confianza debe provenir de certificaciones y auditorías de terceros. Los clientes de referencia que utilizan el CSP para sus datos confidenciales o su producción también pueden ser un aspect importante para fortalecer esta confianza. También debe decidir si confía en la seguridad de autenticación y autorización del CSP. Incluso con la seguridad federada, eso no significa que no haya medios adicionales de autenticación y escalada de privilegios.

En resumen: ¡BYOK no resuelve el problema ni reduce el riesgo!

¿Qué más podemos hacer?

La mayoría de los CSP ofrecen a los clientes capacidades de autoservicio para revocar, rotar y controlar la KEK. Se puede lograr una seguridad mejorada protegiendo los datos antes de moverlos o otorgarles acceso al CSP. Pero esto rara vez es beneficioso y se recomienda principalmente para proteger PII/PHI u otros datos fuertemente regulados.

El issue más importante es considerar todas las rutas de entrada y salida, incluidas las API y las transferencias de archivos, así como varias necesidades de acceso privilegiado. Esto también se extiende a la autenticación y autorización que utiliza management de acceso basado en roles o atributos para garantizar el no repudio, el saneamiento de datos y las mejores prácticas de la industria como confianza cero..

La línea de fondo

Mi objetivo aquí es crear conciencia, no reflexionar negativamente sobre los CSP. Pero BYOK, en su mayor parte, es aceite de serpiente. A menudo se malinterpreta como una panacea para trabajar en la nube y no requiere confianza para el CSP.

SYOK no vale nada. Si supone que el CSP no puede generar suficientes claves aleatorias para la KEK, ¿por qué confiar en él para la DEK? Es importante asegurarse de que exista una arquitectura de seguridad bien diseñada que se reevalúe, pruebe y supervise constantemente.



Enlace a la noticia initial