Hola a todos!
Continuamos con el artículo Prácticas seguras de gestión de claves en Azure – cloud-riders.ES (cloudriders.es) que empezamos hace pocos días.
Software como servicio modelo KMS
Cuando se utiliza un modelo de software como servicio (SaaS) para un KMS, los clientes interactúan con la API del KMS de un CSP para realizar solicitudes de administración de claves, firma y verificación, y cifrado/descifrado.
Estas operaciones se realizan en software de propiedad y administrado por el CSP que se ejecuta en el hardware que administra el CSP. Se debe establecer una sesión segura para esta interacción.
Los CSP que ofrecen un KMS modelo SaaS pueden ofrecer la opción entre claves administradas por el proveedor y claves administradas por el cliente. El cliente tiene un mayor control sobre el ciclo de vida de una clave administrada por el cliente.
Por ejemplo, la clave administrada por el cliente se puede crear en el KMS del CSP o generarse localmente y luego importarse al KMS en la nube, un modelo comúnmente conocido como trae tu propia clave (BYOK).
Las claves administradas por el cliente pueden proporcionar potencialmente una mayor flexibilidad sobre los controles de acceso a los datos.
Sin embargo, esto sería a expensas de mayores recursos necesarios para realizar adecuadamente tareas de gestión clave. El CSP también puede restringir los tipos de claves que se pueden importar.
Infraestructura como servicio modelo KMS
Un ejemplo del modelo de infraestructura como servicio (IaaS) para un KMS sería un HSM dedicado validado FIPS 140 nivel 3 que se ejecuta en un enclave virtual, o HSM en la nube, que el cliente posee y administra.
Este modelo minimiza el acceso a CSP.
El CSP aprovisiona el HSM, maneja la seguridad física y de la red, el espacio en rack, la energía y la integración de la red, y lo expone al enclave virtual del cliente.
El cliente debe proporcionar la experiencia para configurar y mantener el HSM.
El uso de IaaS para un KMS es poco común en comparación con su contraparte SaaS.
Generalmente se trata de un servicio altamente especializado utilizado por organizaciones de gran escala para satisfacer los requisitos reglamentarios.
Módulos de seguridad de hardware
Independientemente de la implementación de KMS elegida, utilizar un sistema de administración de claves validado basado en HSM es una práctica recomendada para administrar las claves utilizadas para cifrar datos altamente confidenciales.
Las claves basadas en HSM se generan, utilizan y almacenan en el HSM, por lo que tiene una superficie de ataque menor que otras opciones de administración de claves.
Los HSM suelen estar diseñados con protecciones físicas contra manipulaciones para que sea extremadamente difícil extraer claves que no están configuradas para exportarse.
Sin embargo, el plan de interacción del CSP con el HSM afectará la seguridad del KMS.
Los HSM pueden ser compartidos, particionados lógicamente o dedicados.
Con las ofertas de HSM compartidas, ningún cliente tiene control sobre cómo se asignan o consumen los recursos.
El hardware en sí es un recurso compartido y la separación de datos depende del software CSP.
Esto presenta un riesgo de acceso no autorizado a datos confidenciales de otros inquilinos. Si una MCA encontrara una debilidad en el software del CSP, podría registrarse como cliente y explotar la debilidad para obtener acceso a los datos de otro cliente.
Los HSM particionados proporcionan lógica peronoaislamiento físico de los datos de otros clientes.
Cada partición debe tener acceso administrativo independiente y sus propios datos, controles de acceso y políticas de seguridad.
A medida que varios clientes interactúan con el dispositivo, existe el riesgo de que un cliente pueda explotar una técnica de canal lateral para leer la memoria en el HSM que está fuera de su partición, lo que le permitirá extraer las claves de otros clientes.
Para mitigar el riesgo de una violación del aislamiento de la partición, los HSM deben configurarse para deshabilitar funciones que permiten a los usuarios ejecutar su propio código.
Los HSM dedicados proporcionanfísicoseparación de otros clientes, lo que elimina los riesgos descritos anteriormente. Con los HSM dedicados, el cliente proporciona un dispositivo de hardware y tiene total responsabilidad administrativa sobre el HSM. Este mayor nivel de control puede presentar en sí mismo un riesgo si el cliente no tiene recursos suficientes para gestionar el dispositivo correctamente.
Integrando un KMS
Otra opción para utilizar un KMS con servicios en la nube es un KMS externo a los servicios de alojamiento del CSP.
Puede ser un KMS administrado y de propiedad empresarial o un KMS de CSP secundario integrado con un CSP principal.
Los CSP no tendrán la capacidad de almacenar y administrar claves de cifrado para operaciones criptográficas para los clientes si el cliente utiliza su propio KMS o un KMS independiente y distinto.
Los CSP tienen diferentes mecanismos y estándares para utilizar o gestionar un KMS integrado.
Por ejemplo, además de sus propias API específicas de CSP, o API proporcionadas por los proveedores del HSM alojado, algunos CSP ofrecen compatibilidad con el Protocolo de interoperabilidad de administración de claves (KMIP) o con los Estándares de criptografía de clave pública (PKCS).
Verificar con el proveedor para asegurar que el servicio existente o planificado sea compatible con los protocolos y procedimientos ofrecidos por el CSP.
Proteger la información sensible
Las organizaciones que operan en la nube deben tomar precauciones para proteger la información confidencial. Las organizaciones deben auditar periódicamente el uso de las claves dentro del entorno de la nube para verificar que el uso de las claves se alinee con el propósito previsto, incluido dónde, cómo y quién las utiliza. Los acuerdos de nivel de servicio deben contener un lenguaje que describa las políticas de gestión de claves del CSP, incluido cualquier mecanismo implementado para aislar al CSP de las claves controladas por el cliente.
Los metadatos en entornos de nube frecuentemente se exponen en pistas de auditoría y, en algunos casos, al CSP para operar y mantener los servicios.
Para evitar la exposición de información confidencial, es importante no utilizar información confidencial en estos tipos de datos.
Estos tipos de datos pueden variar según el proveedor, pero un ejemplo común son las etiquetas de claves.
Además, los clientes deben verificar que los CSP ofrezcan los mecanismos adecuados para cifrar las claves de los clientes mientras están en reposo y en tránsito, y tomar precauciones para garantizar que las claves de los clientes siempre estén cifradas en reposo y que se utilicen canales seguros cuando las claves se transmiten entre servicios internos en la nube.
Administrar información confidencial utilizada con aplicaciones (por ejemplo, claves API, cadenas de conexión de bases de datos, claves de cifrado de datos, contraseñas) es especialmente desafiante porque puede almacenarse de manera insegura en el código de la aplicación, archivos de configuración o canales de integración e implementación.
Minimice la exposición de las claves de los clientes mediante el uso de escaneo automatizado para detectar claves expuestas en estos lugares.
Los MCA también pueden intentar adquirir permisos suficientes para extraer estas claves y credenciales directamente del KMS en la nube o de cualquier otro administrador de secretos nativo de la nube que se utilice en el entorno.
Los permisos para leer estos secretos deben ser limitados y las consultas deben monitorearse.
Se debe tener especial cuidado en preservar las claves criptográficas necesarias para acceder a pruebas forenses cifradas.
Cualquier problema que pueda surgir al preservar estas claves criptográficas puede hacer que las organizaciones pierdan la capacidad de descifrar datos forenses almacenados en la nube.
Consideraciones clave sobre la destrucción
Los clientes deben conocer el proceso de destrucción clave de un CSP.
Cuando se elimina una clave, a menudo se mueve a un estado de «eliminación pendiente» durante un período de tiempo específico antes de que realmente se elimine del CSP.
Mientras espera la destrucción, la clave puede ser recuperable; sin embargo, el período de tiempo y si esta acción se puede revertir varía según el proveedor.
Cuando se eliminan las claves, cualquier dato cifrado por la clave destruida puede ya no se puede descifrar.
Las organizaciones deben asegurarse de que existan los controles adecuados para verificar que una clave ya no sea necesaria antes de eliminarla.
Las organizaciones también deben conocer cuáles son los compromisos clave de destrucción del CSP antes de seleccionar una oferta de KMS.
Las ofertas de almacenamiento en la nube no siempre proporcionan un borrado real de datos, sino que se basan en el borrado criptográfico, donde el borrado de las claves de cifrado proporciona la seguridad de que los datos eliminados no son recuperables.
Sin embargo, la destrucción del material clave eliminado a menudo sólo está garantizada después de varios meses.
Las organizaciones deben tener esto en cuenta al decidir qué nivel de sensibilidad de los datos almacenar en la nube protegidos por estas claves de cifrado.
Funcionalidad KMS aplicada a modelos de servicios en la nube
El modelo de servicio KMS puede ser diferente de los servicios en la nube con los que interactúa.
Por ejemplo, un modelo IaaS KMS puede interactuar con el almacenamiento de datos SaaS.
Independientemente del modelo de servicio KMS, las siguientes subsecciones describen la funcionalidad KMS requerida para cada modelo de servicio.
IaaS
Las capacidades de seguridad que involucran un KMS que son esenciales en los servicios en la nube IaaS incluyen la autenticación de imágenes de VM predefinidas, la autenticación de llamadas API a la interfaz de administración de VM y la seguridad de la comunicación de las operaciones administrativas en las instancias de VM.
En el modelo de servicio IaaS, los clientes deben poder administrar de forma segura las máquinas virtuales, las aplicaciones que se ejecutan en las VM, la comunicación del usuario con las VM y el almacenamiento de datos.
Estas operaciones requerirán pares de claves asimétricas para realizar firma digital, comunicación segura y autenticación.
También pueden ser necesarias claves simétricas para el cifrado.
Los clientes deben proteger la clave privada de un par de claves pública/privada en los sistemas del cliente, tanto en reposo como en uso.
En un modelo de servicio IaaS, las claves simétricas utilizadas para el cifrado de archivos se pueden almacenar en el sitio del cliente mediante un KMS empresarial.
El cliente cifra los archivos y luego los almacena en la nube.
PaaS
En el modelo de Plataforma como Servicio (PaaS), los clientes deben poder interactuar de forma segura con aplicaciones y almacenar datos.
Al igual que con IaaS, estas operaciones requerirán pares de claves asimétricas para realizar firma digital, comunicación segura y autenticación.
También pueden ser necesarias claves simétricas para el cifrado.
Los clientes deben proteger la clave privada de un par de claves pública/privada en los sistemas del cliente, tanto en reposo como en uso.
SaaS
En el modelo de servicio SaaS, el CSP es responsable de la interacción segura con la aplicación.
Sin embargo, el almacenamiento seguro de datos puede ser responsabilidad del cliente, dependiendo de las configuraciones del servicio del CSP.
En este caso, es posible que se necesiten claves simétricas para el cifrado.
Las MCA pueden intentar utilizar claves privadas comprometidas y otros secretos para falsificar credenciales, como tokens de sesión o cookies, con el fin de obtener acceso a la aplicación.
Los clientes deben proteger la clave privada del lado del cliente de un par de claves pública/privada en los sistemas del cliente, tanto en reposo como en uso.
El CSP debe gestionar la clave privada del lado del servidor. Todas las claves de cifrado están bajo el control del CSP.
Dependiendo de la escala de los datos de la aplicación que deben cifrarse, es posible que las claves de cifrado deban residir en el CSP.
Si la selección de datos a cifrar varía, es posible que el cifrado deba realizarse por parte del cliente.
Continuaremos hablando de este tema.
Un saludo
