Anssi tiene publicado La guía está dirigida a los equipos responsables de implementar una IaaS basada en la plataforma de nube de código abierto OpenStack que cumpla con los requisitos de cumplimiento del estándar SecNumCloud 3.2. “Dado que los elementos de configuración necesarios para implementar estas características pueden variar según la solución de implementación elegida, no se presentarán los detalles de la configuración del servicio”, advierte la agencia. Cabe señalar que esta guía cubre los requisitos relacionados con las API de administración, la autenticación de administradores, el cifrado de datos y flujos, así como la partición entre patrocinadores (también conocidos como clientes).

Las recomendaciones emitidas por Anssi se dividen en varias categorías: partición de datos de acceso y autenticación entre proveedores de servicios y clientes, autenticación multifactor, protección de flujos y datos, protección de datos de clientes e implementación de registro en servicios OpenStack.

Índice
  1. Partición de datos de acceso y autenticación entre proveedores y clientes
  2. Autenticación multifactor
  3. Protección de flujos y datos
  4. Protección de datos de clientes
  5. Implementación del registro en los servicios OpenStack

Partición de datos de acceso y autenticación entre proveedores y clientes

El objetivo es proteger contra el robo de datos de autenticación de un administrador de un proveedor de servicios tras un ataque a las API utilizadas por los clientes. Este robo puede dar lugar a un uso ilegítimo de las interfaces dedicadas a los administradores de proveedores de servicios. Para contrarrestarlo, será necesario estar especialmente atento al servicio OpenStack Keystone encargado de la gestión de identidades y roles. Se recomienda configurarlo para que delegue la autenticación de los usuarios en un directorio LDAP gestionado por un servidor LDAP cuyos mecanismos de seguridad sean de última generación.

Anssi también recomienda dividir la implementación de OpenStack en dominios. El dominio raíz predeterminado utilizado por los administradores del proveedor de servicios se configurará para utilizar un directorio LDAP dedicado. El resto de dominios se configurarán para utilizar uno o más directorios dedicados a los patrocinadores. Otras recomendaciones incluyen: utilizar puertos TCP separados para los puntos de entrada públicos y de administración de los servicios, colocar las API públicas y de administración en redes separadas, configurar un servidor proxy inverso aguas arriba de las API destinadas a los patrocinadores y un filtrado de aplicaciones aguas arriba. Sin olvidar un mecanismo para bloquear tokens de administración para API destinadas a clientes y tokens públicos para proveedores de servicios.

Autenticación multifactor

Para protegerse contra el uso fraudulento de los datos de autenticación de un administrador que puedan haber sido robados previamente, la agencia favorece la implementación de una autenticación mutua basada en certificados X.509 entre el cliente OpenStack y el servidor proxy inverso colocado aguas arriba de las API públicas. Pero también una comprobación de la coherencia entre el campo Distinguished Name de los certificados X.509 recibidos y la identidad del usuario proporcionada al directorio LDAP, y la memorización de pares formados por el campo Distinguished Name de los certificados X.509 recibidos y la huella digital de los tokens devueltos por la API Keystone. También se avanza en la verificación de las asociaciones de los tokens enviados por los clientes OpenStack y los certificados X.509 utilizados.

Protección de flujos y datos

Anssi también tiene sus recetas contra el robo o la modificación de software o datos implementados por los patrocinadores en sus infraestructuras virtualizadas. A saber: activar el cifrado de volúmenes del servicio Nova (control de hipervisores que ejecutan VM), Swift (servicio de almacenamiento de objetos), intercambios entre los servicios Swift y Glance (servicio de almacenamiento global y provisión de imágenes utilizadas por las VM), y entre Glance y Nova. Sin olvidar proteger las claves de cifrado mediante un mecanismo ad hoc. "Se recomienda configurar todas las API de OpenStack para que implementen el cifrado TLS de última generación", afirma también Anssi. "Se recomienda configurar el servicio de cola de mensajes y el servicio de base de datos para que implementen el cifrado TLS con autenticación mutua". Implementar túneles IPsec entre el caché de tokens y los servicios OpenStack, configurar el servicio Glance para que se apoye en el servicio Cinder (servicio de almacenamiento en bloque) y asegurar también su cifrado TLS.

La gestión de secretos no se deja de lado, y en este caso también se recomiendan varias recomendaciones: configurar el servicio Barbican (gestor de claves) para utilizar el módulo p11_crypto_plugin para interactuar con un HSM a través de una biblioteca PKCS#11, utilizar un HSM que haya sido certificado en materia de seguridad, así como un mecanismo de control de acceso oslo.policy para restringir el acceso a los secretos de acuerdo con el principio del mínimo privilegio. "Se recomienda permitir el acceso a las interfaces del HSM únicamente a las máquinas que alojan el servicio Barbican y establecer procedimientos basados ​​en llamadas a las API de OpenStack para automatizar el ciclo de vida de los secretos", sugiere también la agencia. También se recomienda proporcionar a los clientes procedimientos de auditoría y gestión de derechos de acceso a secretos, registrar el acceso a los secretos y proporcionarles procedimientos para eliminar los secretos cuando ya no se utilizan o al final del contrato. Se recomienda no compartir servicios de bases de datos para diferentes componentes dentro del mismo servidor o dentro del mismo clúster de servidores, ni cachés para diferentes componentes dentro del mismo servidor o dentro del mismo clúster de servidores. Sin olvidarnos de crear una red específica para servicios de terceros (hosting, datos, cachés y mensajería) y una red dedicada para servicios de terceros utilizando protocolos multicast como Pacemaker y Corosync.

Protección de datos de clientes

Se prefiere el uso de filtros para el servicio Nova con el fin de permitir la creación de agregados de nodos de cómputo dedicados para los clientes. Y también para integrar en los modelos de VM ofrecidos a los clientes, metadatos utilizables por los filtros Nova para seleccionar los agregados de nodos de cómputo en los que instanciar las máquinas virtuales. Sin olvidar configurar los siguientes aspectos:

- Migración en vivo de máquinas virtuales para confiar en QEMU;
- QEMU implementará encriptación TLS de última generación al migrar máquinas virtuales;
- Servicio rápido para que disponga de múltiples conjuntos de almacenamiento;
- El servicio Cinder para asociar un backend con cada conjunto de almacenamiento;
- Cuotas de Cinder para restringir el acceso del proyecto a los backends.

En cuanto al particionamiento de la red, Anssi recomienda configurar el servicio Neutron (red como servicio) para encapsular los intercambios entre nodos informáticos en túneles IPSec, implementar una política de renovación periódica de las claves maestras del HSM y un procedimiento de borrado seguro de los datos de los clientes presentes en el servidor LDAP. "Se recomienda implementar un módulo de seguridad Linux en los hipervisores o un sistema de particionamiento similar [...] Para eliminar la cuenta de administrador predeterminada (guest). En caso de que sea necesaria una cuenta de administrador, el nombre de esta cuenta debe ser diferente. Por último, se debe crear una ACL de acceso restrictivo para controlar el acceso de la cuenta a los “temas”, recomienda la agencia.

Implementación del registro en los servicios OpenStack

Configurar un nivel de registro correcto es un paso importante a la hora de configurar un entorno OpenStack. Tanto para la detección de comportamientos maliciosos como para monitorizar el correcto funcionamiento de los distintos servicios, es necesario configurar un sistema de registro. Los puntos de vigilancia a seguir serán los siguientes:

- Asegurar la sincronización del reloj;
- Auditar el acceso a los archivos de configuración del servicio OpenStack;
- Habilitar el registro esencial para la detección de compromisos;
- Habilitar el registro importante para la detección de compromisos;
- Habilitar todos los sistemas de registro.