Seguridad de vCloud Director

VMware Cloud Director 9.5vCloud Director 9.1

Puede encontrar la documentación técnica más actualizada en el sitio web de VMware:

https://docs.vmware.com/es/

Si tiene comentarios relacionados con esta documentación, envíelos a:

docfeedback@vmware.com

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

VMware Spain, S.L.Calle Rafael Boti 262.ª plantaMadrid 28023Tel.: +34 914125000www.vmware.com/es

Copyright © 2010-2020 VMware, Inc. Todos los derechos reservados. Información sobre el copyright y la marca comercial.

Seguridad de vCloud Director

VMware, Inc. 2

Contenido

1 Introducción 4

2 Amenazas 6

3 Arquitectura y funciones de seguridad de vCloud Director 8Aislamiento y seguridad de máquinas virtuales 9

Seguridad y abstracción de vCloud Director 10

Seguridad y la capa de redes virtuales 11

4 Seguridad de la infraestructura 14Seguridad de la base de datos 16

5 Seguridad del sistema 18Requisitos de seguridad de red 18

Certificados 20

Firewalls 23

Equilibradores de carga y terminación SSL 24

Protección de AMQP (RabbitMQ) 25

Protección de Cassandra (base de datos de métricas de máquina virtual) 26

Proteger el acceso a JMX 26

Configuración de la red de administración 28

Auditoría y registro 29

6 Seguridad de tenants 33Seguridad de la red en organizaciones de tenants 33

Aislamiento y asignación de recursos 35

Recomendaciones sobre aislamiento y uso compartido de recursos 39

Administración de cuentas de usuario 43

Control de acceso basado en funciones 45

Configurar proveedores de identidad 46

7 Lista de comprobación 50

VMware, Inc. 3

Introducción 1VMware vCloud Director es un sistema flexible que proporciona servicios de computación de nube. Se beneficia de las tecnologías de administración y virtualización centrales de VMware y las amplía para prestar soporte a los entornos de nube.

Dado que el sistema se desarrolló y se probó teniendo en cuenta los entornos multicliente, la escalabilidad y otros aspectos de la seguridad, el método que se use para su implementación puede influir en gran medida en la seguridad de todo el sistema. En este documento se describen algunas de las posibles amenazas a las que se enfrenta el sistema, así como las funciones de seguridad que proporciona la pila de software general de VMware y los componentes relacionados que emplea, como las bases de datos.

Ningún conjunto de instrucciones puede abarcar todos los casos de uso posibles de los clientes. Cada implementación de vCloud Director puede tener su propio entorno de TI, con diferencias en la topología de la red, las normas y los sistemas de seguridad internos, los requisitos de los clientes y los casos de uso. Por ello, se proporcionarán algunas normas de carácter general enfocadas a aumentar la seguridad general del sistema. Donde se considere oportuno, también se tendrán en cuenta casos de uso más específicos, junto con instrucciones adaptadas a esos casos particulares. No obstante, la decisión de seguir una u otra recomendación específica de esta guía dependerá en última instancia de su entorno de implementación concreto y de las amenazas a las que su organización tenga que enfrentarse y que quiera mitigar.

En general, las amenazas a vCloud Director se dividen en dos grupos independientes: amenazas internas y amenazas externas. En las amenazas internas están involucrados generalmente problemas de varios tenants, y las amenazas externas tienen como objetivo la seguridad del entorno de nube hospedado, pero el límite entre unas y otras no es estricto y puede variar. Puede haber amenazas internas que ataquen a la seguridad del entorno del host, por ejemplo.

Además de seguir las instrucciones de este documento, debe supervisar los avisos de seguridad que se indican en http://www.vmware.com/security/advisories.html y suscribirse a las alertas de correo electrónico mediante el formulario que aparece en esa página. Los avisos de última hora y las instrucciones adicionales de seguridad relacionadas con vCloud Director se publicarán en ese mismo sitio.

VMware, Inc. 4

Ámbito de recomendacionesLas recomendaciones que se proporcionan en esta guía se limitan a la administración de problemas de seguridad específicos de vCloud Director. Al igual que una aplicación web que se hospeda en una plataforma Linux, vCloud Director está sujeto a las vulnerabilidades de seguridad que se presentan en esas dos categorías, las cuales se describen en otros documentos.

También es importante recordar que la implementación segura de software es solo parte de un proceso de seguridad global que se compone de seguridad física, formación, procedimientos operativos, estrategia de revisiones, planes de escalación y respuesta y recuperación ante desastres, entre otros muchos temas. La mayoría de estos temas suplementarios no se describe en esta guía.

Seguridad de vCloud Director

VMware, Inc. 5

Amenazas 2Las amenazas de seguridad a vCloud Director se pueden clasificar básicamente como amenazas internas que se originan dentro del sistema y sus tenants, o amenazas externas que se originan fuera del sistema. Esta última categoría incluye las amenazas a la infraestructura creada para alojar un grupo de servidores de vCloud Director y las amenazas al software de vCloud Director instalado.

Amenazas internas y estructura jerárquicavCloud Director está diseñado para proporcionar a los tenants un acceso administrado a los recursos informáticos, de red y de almacenamiento de VMware vSphere ® . Los usuarios de los tenants pueden iniciar sesión en vCloud Director y, por lo general, se les otorgan derechos para implementar y usar las máquinas virtuales, el almacenamiento, ejecutar aplicaciones y (hasta cierto límite) compartir recursos con otros usuarios.

Una de las principales funciones de vCloud Director es que los usuarios no administrativos no tienen visibilidad o acceso directo a la mayoría de los recursos de nivel de sistema, incluida la información del host físico, como las direcciones IP, las direcciones MAC, el tipo de CPU, el acceso de ESXi, las ubicaciones de almacenamiento físico, etc. Sin embargo, los usuarios sí que pueden intentar acceder a información sobre la infraestructura del sistema en la que se ejecutan sus aplicaciones basadas en nube. Si consiguieran acceder, podrían lanzar ataques más eficaces contra los niveles más bajos del sistema.

Incluso en el nivel de los recursos virtualizados, los usuarios pueden intentar utilizar su acceso legítimo para acceder sin autorización a partes del sistema para las que no tienen derecho, como los recursos que pertenecen a otra organización. Concretamente, podrían intentar una escalación de privilegios para acceder a acciones reservadas a administradores. Es posible que los usuarios también intenten realizar acciones que, de forma intencionada o no, interrumpan la disponibilidad general y el rendimiento del sistema y provocar, en casos extremos, una “denegación de servicio” a otros usuarios.

Además, por lo general, existe una variedad de usuarios administrativos. Entre estos se incluyen el administrador del sistema de un sitio de vCloud Director, los administradores de la organización de tenants, los administradores de bases de datos y redes, los usuarios con derechos de acceso a ESXi, vCenter y los sistemas operativos invitados que ejecutan herramientas de administración. Estos usuarios

VMware, Inc. 6

tienen mayores privilegios que los usuarios normales y, por lo general, disponen de inicio de sesión directo en los sistemas internos. No obstante, sus privilegios no son ilimitados. Existe una posible amenaza de que también intenten realizar una escalación de privilegios o realizar acciones malintencionadas.

Como veremos, la seguridad de vCloud Director frente a estas amenazas se logra mediante la arquitectura, el diseño y la implementación de vCloud Director, vSphere y VMware NSX®, junto con otros sistemas de seguridad, y la infraestructura en la que se implementan estos sistemas. Debido a la flexibilidad y la naturaleza dinámica de estos sistemas, es fundamental seguir las instrucciones de configuración de seguridad correspondientes para todos estos componentes.

Protección frente a amenazas externas y del hostLos orígenes de las amenazas externas son los sistemas y los usuarios fuera de la nube, incluido Internet, los ataques a vCloud Director a través de sus API e interfaces web (la consola web de vCloud Director y el portal para tenants de vCloud Director), así como el servicio de transferencia de vApp y la consola remota de máquina virtual. Un usuario remoto que no tenga derechos de acceso al sistema puede intentar acceder como un usuario autorizado. Los usuarios autenticados de estas interfaces también pueden considerarse como los orígenes de las amenazas externas, ya que pueden intentar aprovechar las vulnerabilidades del sistema que no están disponibles para los usuarios no autenticados.

Por lo general, estos agentes intentan aprovecharse de errores en la implementación del sistema o en su instauración con el fin de obtener información, acceder a los servicios o, simplemente, alterar el funcionamiento de la nube a través de la pérdida de disponibilidad del sistema o de integridad del sistema y su información. Como bien se explica en la descripción de estos ataques, algunos de ellos infringen los límites de los tenants y los niveles de abstracción del hardware que vCloud Director intenta aplicar. Aunque la implementación de las distintas capas del sistema afecta a la reducción de estas amenazas, son especialmente preocupantes las interfaces externas, como los firewall, los enrutadores, VPN, etc.

Seguridad de vCloud Director

VMware, Inc. 7

Arquitectura y funciones de seguridad de vCloud Director 3vCloud Director proporciona la infraestructura de VMware vSphere ® y VMware NSX® como un servicio, lo que permite el aislamiento de tenant necesario en un entorno de nube.

Un grupo de servidores de vCloud Director está formado por uno o más servidores Linux. Cada servidor del grupo ejecuta una colección de servicios denominada celda de vCloud Director. Todas las celdas comparten una sola base de datos de vCloud Director, y se conectan a varios sistemas de vCenter Server, a los hosts ESXi que administran y a las instancias de NSX Manager que proporcionan servicios de red.

Figura 3-1. Diagrama de la arquitectura de vCloud Director

Servidor de vCloud Director

Celda

Instalación de vCloud Director

vCenter

VMware vCloud Director

VMware vSphere

ESXi

ESXi

NSX

Base de datos de vCenter

Base de datos de vCloud Director

En la figura Figura 3-1. Diagrama de la arquitectura de vCloud Director se muestra un solo grupo de servidores de vCloud Director (instalación). Es posible que en dicho grupo de servidores haya varios hosts del servidor de vCloud Director, cada uno con una sola celda en ejecución. El grupo de servidores comparte la base de datos de vCloud Director y un recurso compartido de archivo NFS (no se muestra).

VMware, Inc. 8

La abstracción de nube se ha diseñado con el software vCloud Director y aprovechando las capacidades de vCenter y NSX; en el diagrama se muestra como la conexión con el grupo de servidores. Las organizaciones de vCloud Director y sus usuarios no interactúan directamente con vCenter ni NSX para crear y administrar sus cargas de trabajo. Para cualquier usuario que no sea administrador del sistema, las interacciones con vCenter y NSX se presentan como operaciones de vCloud Director en objetos de vCloud Director. El permiso para acceder a los objetos de vCloud Director y utilizarlos está basado en funciones. Las funciones predefinidas proporcionan acceso de valor de referencia a las tareas comunes. Los administradores de organización también pueden crear funciones personalizadas para sacar el máximo partido a una matriz de derechos detallados.

Las siguientes subsecciones describen la seguridad en la capa de computación virtual, la abstracción de nube y la capa de redes virtuales.

Este capítulo incluye los siguientes temas:

n Aislamiento y seguridad de máquinas virtuales

n Seguridad y abstracción de vCloud Director

n Seguridad y la capa de redes virtuales

Aislamiento y seguridad de máquinas virtualesCuando se examina el aislamiento de red y la seguridad en este documento, el objetivo es evaluar el riesgo de que los controles de aislamiento de tráfico y segregación de red sean insuficientes y elegir las acciones correctivas recomendadas.

Al observar la segmentación de redes, tenemos la noción de una zona de confianza. Las zonas de confianza son un control de seguridad proactivo que permiten controlar el acceso al tráfico de red. En líneas generales, una zona de confianza se define como un segmento de red dentro del cual los datos fluyen con relativa libertad, mientras que el flujo de datos dentro y fuera de la zona de confianza está sujeto a restricciones más seguras. Ejemplos de zonas de confianza:

n Redes perimetrales (también denominadas zonas desmilitarizadas o DMZ)

n Entorno de datos de titulares de tarjetas de la industria de tarjetas de pago (PCI)

n Zonas específicas del sitio, como la segmentación según el departamento o la función

n Zonas definidas por la aplicación, como los tres niveles de una aplicación web

Seguridad y la capa de virtualización subyacenteUna parte importante de la seguridad de vCloud Director, especialmente para proteger los tenants de la nube de amenazas internas, proviene del diseño de seguridad y la configuración específica de la capa de virtualización subyacente. Esto incluye el diseño y la configuración de vSphere, la seguridad adicional de redes definidas por software de vCloud Director, el aprovechamiento de la tecnología de NSX y la seguridad de los propios hosts de ESXi.

Seguridad de vCloud Director

VMware, Inc. 9

Seguridad y abstracción de vCloud DirectorvCloud Director impone una separación estricta entre las operaciones de vSphere y las necesidades operativas diarias de los tenants.

La abstracción de vCloud Director permite que un proveedor de servicios delegue la creación, la administración y el uso de una vApp a las organizaciones de tenants (o que un departamento de TI delegue estas capacidades a los equipos de la línea de negocio). Los usuarios y los administradores de la organización de tenants no utilizan ni administran funciones de vCenter, como vMotion, vSAN, etc. Los tenants solo tratan con la implementación de sus cargas de trabajo (vApp) para grupos de recursos y perfiles de almacenamiento, y su conexión a redes de VDC de la organización que son propiedad de la organización. Debido a que los usuarios y los administradores de la organización nunca inician sesión en vCenter, no existe el peligro de haber configurado mal un permiso de vCenter que conceda demasiados derechos al usuario. Además, el proveedor puede cambiar cuando quiera la composición de los grupos de recursos y los perfiles de almacenamiento sin que la organización tenga que cambiar nada.

Y lo que es más importante, esta abstracción separa diferentes organizaciones entre sí. Aunque se dé el caso de que se le asignen redes, almacenes de datos o grupos de recursos comunes, no podrán modificar ni siquiera ver las vApp de las demás organizaciones (a excepción de las vApp conectadas a la misma red externa, ya que comparten el mismo vSwitch). Si a cada organización de tenants se le proporcionan sus propios almacenes de datos, redes y grupos de recursos exclusivos (aunque no sea un requisito del sistema), permitirá al proveedor de servicios forzar una separación aún mayor entre las organizaciones.

Limitar el acceso de tenants a la información del sistemaA pesar de que vCloud Director está diseñado para ocultar a los tenants las operaciones de nivel del sistema, algunas funciones del sistema pueden estar configuradas para proporcionar información que podría ser aprovechada por un tenant malintencionado.

Deshabilite el envío de datos de rendimiento del host a los sistemas operativos invitados.

vSphere incluye contadores de rendimiento de las máquinas virtuales en sistemas operativos Windows con VMware Tools instalado. De forma predeterminada, vSphere no expone la información del host a la máquina virtual invitada. Debido a que la información sobre el host físico podría ser aprovechada por un tenant malintencionado, debe comprobar que este comportamiento predeterminado se encuentra en su lugar. Para más detalles, consulte Comprobar que está deshabilitado el envío de datos de rendimiento del host a los invitados en Seguridad de vSphere.

Limitar la recopilación de métricas de máquina virtual

vCloud Director puede recopilar métricas que ofrecen información actual e histórica sobre el rendimiento y consumo de recursos de las máquinas virtuales. Debido a que algunas de estas métricas incluyen información sobre el host físico, la cual podría ser aprovechada por un tenant malintencionado, considere la posibilidad de configurar el subsistema de

Seguridad de vCloud Director

VMware, Inc. 10

recopilación de métricas para recopilar solo las métricas que no sean susceptibles de ser utilizadas malintencionadamente. Consulte Configurar recopilación de métricas en Guía del administrador de vCloud Director para obtener más información.

Precaución con las extensionesvCloud Director admite un número de métodos de extensibilidad. Aunque estos métodos están diseñados para evitar que cualquier extensión adquiera derechos que no se han otorgado a usuarios del tenant o aumente los privilegios que se le asignó durante la instalación, una extensión puede proporcionar, ya sea de manera intencionada o no, superficies de ataque adicionales que podrían ser aprovechadas por alguien que tenga conocimiento de la extensión. Los proveedores de servicios y los administradores de tenants deben tener cuidado al ofrecer, revisar o instalar extensiones. Si, además, administran cuidadosamente las extensiones permitidas y el uso de elementos de protección adecuados, como el encabezado de X-Content-Type-Options: nosniff, podrán evitar que los complementos carguen contenido malintencionado.

Seguridad y la capa de redes virtualesLas redes de vCloud Director aprovechan las capacidades de redes definidas por software de vSphere y NSX para proporcionar a los tenants un acceso seguro a los recursos compartidos de red. Las responsabilidades del proveedor de servicios se limitan a proporcionar las conexiones externas y la infraestructura de red necesarias para lograr que los tenants puedan usar esas conexiones, y asignar recursos de red de nivel del sistema a grupos de redes para que puedan ser consumidos por los tenants.

Con esta breve introducción de vCloud Director se pretende establecer el contexto en el que veremos los requisitos de red de nivel de tenant y de nivel de proveedor desde un punto de vista de configuración de seguridad. Estas funciones se describen en detalle en la documentación de vCloud Director en http://docs.vmware.com.

Recursos de red de nivel de proveedorEn el caso típico, un proveedor de servicios es el encargado de crear una o varias conexiones entre vCloud Director y una red externa, como Internet o una red empresarial de un cliente. Este tipo de red es, esencialmente, una conexión de red IP básica. No ofrece confidencialidad en el caso de que se intercepten los paquetes que la atraviesan en el nivel físico y no proporcionan ninguna función de aislamiento de red de VLAN o VXLAN de vCloud Director.

Para habilitar las redes de organización de tenants, el proveedor de servicios debe crear uno o varios grupos de redes que agreguen recursos de DVswitches y grupos de puertos de ESXi de manera que puedan ponerse a disposición de las organizaciones de tenants. (Una red externa no consume recursos de un grupo de redes). Un grupo de redes respaldado mediante VLAN o VXLAN proporciona aislamiento al utilizar VLAN a través de un switch distribuido de vNetwork. Una red VXLAN de vCloud Director

Seguridad de vCloud Director

VMware, Inc. 11

también puede proporcionar aislamiento mediante el encapsulamiento de paquetes de capa 2 en otros paquetes de capa 2 (MAC en MAC) en el kernel de ESXi, lo que permite al kernel, cuando se anula el encapsulamiento de paquetes, enviarlos a las máquinas virtuales invitadas correctas que están conectadas a redes creadas a partir de este tipo de grupo.

El proveedor de servicios se encarga también de crear y administrar la infraestructura de NSX que se encuentra entre las redes que crean los tenants para ellos mismos, y los recursos de nivel del sistema, como switches y grupos de puertos proporcionados por ESXi. A partir de estos recursos, las organizaciones de tenants pueden crear sus propias redes.

Redes de VDC de organizaciónUna red de VDC de organización permite que las máquinas virtuales del VDC de organización se comuniquen entre sí y accedan a otras redes, incluidas las redes de VDC de organización y las redes externas, ya sea directamente o a través de una puerta de enlace Edge que pueda proporcionar servicios NAT y firewall.

n Una red de VDC de organización directa se conecta directamente a una red externa. Solamente los administradores del sistema pueden crear una red de VDC de organización directa.

n Una red de VDC de organización enrutada se conecta a una red externa a través de una puerta de enlace Edge. Una red de VDC de organización enrutada también requiere que el VDC contenedor incluya un grupo de redes. Una vez que el administrador del sistema aprovisiona un VDC de organización con una puerta de enlace Edge y lo asocia con un grupo de redes, los administradores de la organización o del sistema pueden crear redes de VDC de organización enrutadas en ese VDC.

n Una red de VDC de organización aislada no requiere una puerta de enlace Edge o una red externa, pero sí requiere que el VDC contenedor esté asociado a un grupo de redes. Una vez que el administrador del sistema crea un VDC de organización con un grupo de redes, los administradores de la organización o del sistema pueden crear redes de VDC de organización aisladas en ese VDC.

Seguridad de vCloud Director

VMware, Inc. 12

Tabla 3-1. Tipos de redes de VDC de organización y sus requisitos

Conexión de red de VDC de organización Descripción Requisitos

Conexión directa a una red externa.

Proporciona conectividad de capa 2 directa a las máquinas y las redes fuera del VDC de organización. Las máquinas fuera de este VDC de organización pueden conectarse directamente a las máquinas del VDC de organización.

La nube debe contener una red externa.

Conexión enrutada a una red externa.

Proporciona un acceso controlado a máquinas y redes fuera del VDC de organización a través de una puerta de enlace Edge. Los administradores del sistema y los administradores de la organización pueden configurar la traducción de direcciones de red (NAT) y la configuración de firewall en la puerta de enlace para poder acceder a determinadas máquinas virtuales del VDC desde una red externa.

El VDC debe contener una puerta de enlace Edge y un grupo de redes.

Sin conexión a una red externa.

Proporciona una red privada y aislada a la que pueden conectarse las máquinas del VDC de organización. Esta red no proporciona conectividad entrante o saliente con máquinas fuera de este VDC de organización.

El VDC debe contener un grupo de redes.

De forma predeterminada, solo pueden utilizarlas las máquinas virtuales del VDC de organización que contiene la red. Cuando se crea una red de VDC de organización, puede especificar que sea compartida. Una red de VDC de organización compartida puede ser utilizada por todas las máquinas virtuales de la organización.

Redes de vAppCada vApp contiene una red de vApp. Una red de vApp es una red lógica que controla el modo en que las máquinas virtuales de una vApp se conectan entre sí y a las redes de VDC de organización. Los usuarios pueden crear y actualizar redes de vApp y conectarlas a redes de VDC de organización, ya sea directamente o con protección de firewall y NAT.

Seguridad de vCloud Director

VMware, Inc. 13

Seguridad de la infraestructura 4Gran parte de esta guía se dedica a la protección de vCloud Director, si bien la seguridad general del sistema también requiere que se proteja la infraestructura de la que depende vCloud Director, incluidos vSphere, NSX, la plataforma Linux de celdas y la base de datos de vCloud Director.

La aplicación de las revisiones de seguridad actuales a cada uno de estos componentes de infraestructura antes de la instalación es un paso clave, así como resulta crucial supervisar estos componentes de forma continua para conservar su nivel de revisión actual.

Protección de la infraestructura de VMwareUn primer paso que es crítico a la hora de proteger vCloud Director consiste en garantizar la seguridad de vSphere y NSX. Los administradores deben revisar las listas de comprobación que hay disponibles en https://www.vmware.com/security/hardening-guides.html, así como consultar la información de seguridad más detallada que se encuentra en los siguientes documentos:

Seguridad de vSphere Seguridad de vSphere. https://docs.vmware.com/es/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-52188148-C579-4F6A-8335-CFBCE0DD2167.html

Seguridad de NSX Protección de VMware NSX for vSphere. https://communities.vmware.com/docs/DOC-27674 y https://communities.vmware.com/docs/DOC-28142.

Protección de las plataformas de celdasLas celdas de vCloud Director se ejecutan en un sistema operativo basado en Linux como un usuario sin privilegios (vcloud.vcloud) que se crea durante la instalación. En las Notas de la versión de vCloud Director, encontrará la lista de sistemas operativos compatibles con la plataforma de celdas. Proteger la plataforma de celdas, ya sea física o virtual, es una parte clave en la protección de vCloud Director.

Los procedimientos para endurecer la protección estándar se deben aplicar a la plataforma de celdas; entre estos métodos se encuentran los de deshabilitar los servicios de red que no sean necesarios, quitar los paquetes que no hagan falta, restringir el acceso raíz remoto y reforzar las directivas de contraseña segura. Pruebe con un servicio centralizado de autenticación como Kerberos y considere la posibilidad de instalar herramientas de supervisión y detección de intrusiones.

VMware, Inc. 14

También es posible instalar otras aplicaciones y aprovisionar otros usuarios en la instancia de sistema operativo de las celdas, pero se recomienda evitarlo siempre que sea posible. La ampliación del acceso al sistema operativo de las celdas podría significar una reducción de la seguridad.

Protección de los archivos confidenciales tras la instalaciónDurante la instalación, vCloud Director escribe los datos de instalación, incluidas las contraseñas, en los archivos del sistema de archivos local del host Linux de celdas. Estos archivos, global.properties y responses.properties (ambos se encuentran en $VCLOUD_HOME/etc), contienen información confidencial que se volverá a utilizar cuando se agreguen más servidores a un grupo de servidores. El archivo responses.properties contiene las respuestas que proporciona el administrador cuando se ejecuta el script de configuración. Ese archivo contiene una versión cifrada de la contraseña de la base de datos de vCloud Director y las contraseñas del almacén de claves del sistema. El acceso no autorizado a ese archivo podría dar acceso a un atacante a la base de datos de vCloud Director con los mismos permisos que el usuario de la base de datos especificó en el script de configuración. El archivo global.properties también contiene las credenciales cifradas. Estas credenciales no se deben conceder a ninguna otra persona que no sea el administrador de las celdas.

Durante la fase de creación, los archivos responses.properties y global.properties están protegidos mediante controles de acceso sobre la carpeta $VCLOUD_HOME/etc y los archivos mismos. No cambie los permisos de los archivos ni de la carpeta, ya que se podría ampliar demasiado el acceso y se podría provocar una reducción de la seguridad, o se podría restringir demasiado el acceso, lo que provoca que el software de vCloud Director deje de funcionar. Para que los controles de acceso funcionen correctamente, el acceso físico y lógico a los servidores de vCloud Director se debe limitar exclusivamente a aquellos que necesiten iniciar sesión y se producirá únicamente con los niveles mínimos de acceso necesarios. Esto implica que se limite el uso de la cuenta raíz a través de sudo y otras prácticas recomendadas que no se tratan en este documento. Además, las copias de seguridad de los servidores se deben proteger y cifrar de forma estricta, y las claves se deben administrar por separado desde las mismas copias de seguridad.

Para obtener más información, consulte Protección y reutilización del archivo de respuesta en la Guía de instalación y actualización de vCloud Director.

Credenciales administrativasCompruebe que las credenciales que se utilizan para el acceso administrativo a la celda, vSphere, la base de datos de vCloud Director, los firewalls externos y otros dispositivos siguen los criterios de complejidad de contraseñas adecuados. Siempre que sea posible, sopese implantar una directiva de caducidad y rotación para las contraseñas. Tenga en cuenta, sin embargo, que, cuando la contraseña de una base de datos, vSphere o NSX cambia o caduca, parte o toda la infraestructura de nube deja de funcionar hasta que vCloud Director se actualiza con las nuevas contraseñas.

Seguridad de vCloud Director

VMware, Inc. 15

Desde el punto de vista de una estrategia de defensa exhaustiva, es muy importante tener diversas contraseñas administrativas para los distintos servidores del entorno de vCloud Director, incluidos las celdas de vCloud Director, la base de datos de vCloud Director, los servidores de vSphere y NSX Manager. De este modo, en caso de que peligrara la seguridad de un conjunto de credenciales (por ejemplo, por un empleado descontento que deja la organización), la seguridad de los otros sistemas de la infraestructura no se vería comprometida.

Para obtener más información sobre la administración de la cuenta y las credenciales para administradores y tenants, consulte Administración de cuentas de usuario.

Este capítulo incluye los siguientes temas:

n Seguridad de la base de datos

Seguridad de la base de datosEn general, la seguridad de la base de datos está fuera del alcance de este documento. Al igual que ocurre con los demás sistemas utilizados en la implementación de nube, se espera que la base de datos de vCloud Director se proteja adecuadamente según las prácticas recomendadas del sector.

La cuenta de usuario de la base de datos de vCloud Director solo debe tener los privilegios del sistema que aparecen en la guía de configuración de la base de datos correspondiente en la Guía de instalación y actualización de vCloud Director. El usuario de la base de datos de vCloud Director no debe tener privilegios en otras bases de datos de ese servidor, así como tampoco debe tener privilegios de administración del sistema. Esto infringiría el principio de mínimo privilegio en el servidor de la base de datos y otorgaría al usuario más derechos de lo necesario.

Seguridad de vCloud Director

VMware, Inc. 16

Se recomienda consultar los siguientes documentos para obtener información sobre la seguridad de la base de datos.

Microsoft SQL Server Prácticas recomendadas de seguridad para SQL Server en http://download.microsoft.com/download/8/f/a/8fabacd7-803e-40fc-adf8-355e7d218f4c/sql_server_2012_security_best_practice_whitepaper_apr2012.docx.

Nota vCloud Director no admite conexiones SSL a una base de datos de Microsoft SQL Server.

Oracle Guía de seguridad de Oracle Database en https://docs.oracle.com/cd/B28359_01/network.111/b28531.pdf.

Nota vCloud Director 9.5 no admite bases de datos de Oracle.

vCloud Director 9.1 admite bases de datos de Oracle, pero no admite conexiones HTTPS y SSL a una base de datos de Oracle.

PostgreSQL Además de habilitar SSL para conexiones PostgreSQL, se recomienda revisar los documentos Administración del servidor de PostgreSQL y Seguridad total en una base de datos PostgreSQL de IBM developerWorks.

Seguridad de vCloud Director

VMware, Inc. 17

Seguridad del sistema 5El proveedor de servicios y los administradores del sistema se encargan de la seguridad de cada grupo de servidores de vCloud Director.

Para proteger un grupo de servidores de vCloud Director frente a atacantes externos, es necesario tomar medidas defensivas comunes a todos los servicios web, como por ejemplo, proteger los extremos HTTPS con certificados autofirmados y colocar un firewall de aplicación web entre el sistema e Internet. Tampoco hay que olvidar configurar los servicios de los que depende vCloud Director, incluido el broker AMQP RabbitMQ y una base de datos de Apache Cassandra opcional. De este modo, se reducirán al mínimo las oportunidades de que agentes externos puedan poner en peligro estos sistemas.

Este capítulo incluye los siguientes temas:

n Requisitos de seguridad de red

n Certificados

n Firewalls

n Equilibradores de carga y terminación SSL

n Protección de AMQP (RabbitMQ)

n Protección de Cassandra (base de datos de métricas de máquina virtual)

n Proteger el acceso a JMX

n Configuración de la red de administración

n Auditoría y registro

Requisitos de seguridad de redEl funcionamiento seguro de vCloud Director requiere un entorno de red protegido. Configure y pruebe dicho entorno de red antes de empezar a instalar vCloud Director

VMware, Inc. 18

Conecte todos los vCloud Director Servers a una red que esté protegida y que se esté supervisando. Las conexiones de red de vCloud Director tienen varios requisitos adicionales:

n No conecte vCloud Director directamente a la red de Internet pública. Siempre proteja las conexiones de red de vCloud Director con un firewall. Solamente el puerto 443 (HTTPS) debe estar abierto para las conexiones entrantes. Los puertos 22 (SSH) y 80 (HTTP) también se pueden abrir para las conexiones entrantes, de ser necesario. Además, cell-management-tool requiere acceso a la dirección del bucle invertido de la celda. El firewall debe rechazar el resto del tráfico entrante procedente de redes públicas, incluidas las solicitudes realizadas a JMX (puerto 8999).

Tabla 5-1. Puertos que deben permitir paquetes entrantes provenientes de hosts de vCloud Director

Puerto Protocolo Comentarios

111 TCP, UDP Asignador de puertos NFS utilizado por el servicio de transferencia

920 TCP, UDP rpc.statd de NFS utilizado por el servicio de transferencia

61611 TCP AMQP.

61616 TCP AMQP.

n No conecte a la red pública los puertos utilizados con las conexiones salientes.

Tabla 5-2. Puertos que deben permitir paquetes salientes provenientes de hosts de vCloud Director

Puerto Protocolo Comentarios

25 TCP, UDP SMTP

53 TCP, UDP DNS

111 TCP, UDP Asignador de puertos NFS utilizado por el servicio de transferencia

123 TCP, UDP NTP

389 TCP, UDP LDAP

443 TCP Las conexiones de vCenter, NSX Manager y ESXi usan el puerto estándar. Si ha elegido otro puerto para estos servicios, deshabilite la conexión al puerto 443 y habilítelos en el puerto que haya seleccionado.

514 UDP Opcional. Permite el uso de syslog.

902 TCP Conexiones de vCenter y de ESXi.

903 TCP Conexiones de vCenter y de ESXi.

920 TCP, UDP rpc.statd de NFS utilizado por el servicio de transferencia.

1433 TCP Puerto de base de datos de Microsoft SQL Server predeterminado.

Seguridad de vCloud Director

VMware, Inc. 19

Tabla 5-2. Puertos que deben permitir paquetes salientes provenientes de hosts de vCloud Director (continuación)

Puerto Protocolo Comentarios

5672 TCP, UDP Opcional. Mensajes de AMQP para las extensiones de tareas.

61611 TCP AMQP.

61616 TCP AMQP.

n Enrute el tráfico entre los servidores de vCloud Director y los siguientes servidores a través de una red privada dedicada.

n Servidor de la base de datos de vCloud Director

n RabbitMQ

n Cassandra

n Si es posible, enrute el tráfico entre los servidores de vCloud Director, vSphere y NSX a través de una red privada dedicada.

n Los switches virtuales y los switches virtuales distribuidos que admitan redes de proveedor deben estar aislados entre ellos. No pueden compartir el mismo segmento de red física de capa 2.

n Utilice NFSv4 para el almacenamiento del servicio de transferencia. La versión más común de NFS, NFSv3, no ofrece cifrado en tránsito que, en algunas configuraciones, puede permitir pruebas en ejecución o la manipulación de los datos transferidos. Las amenazas inherentes a NFSv3 se describen en el documento técnico acerca de la seguridad de NFS en entornos de confianza y que no son de confianza de SANS. Encontrará información adicional acerca de la configuración y la protección del servicio de transferencia de vCloud Director en el artículo de la base de conocimientos 2086127 de VMware.

CertificadosvCloud Director utiliza HTTPS (TLS o SSL) para proteger el tráfico de red dirigido a los endpoints externos. HTTPS también es compatible con varios endpoints internos, incluidos AMQP y LDAP. Es especialmente importante proporcionar un certificado firmado por una entidad de certificación (CA) conocida a los endpoints externos. Los endpoints internos son menos vulnerables y en la mayoría de los casos se pueden proteger adecuadamente con los certificados de la empresa o incluso con certificados autofirmados.

Todos los certificados deben tener un campo de nombre común (CN) que coincida con el nombre de dominio completo (FQDN) del servidor en el que están instalados. Por lo general, esto implica que el servidor debe estar registrado en el DNS, de modo que tenga un FQDN exclusivo y bien definido; además, también implica que la conexión se realizará mediante el FQDN, no una dirección IP. Si planea conectarse mediante la dirección IP, el certificado debe incluir el campo subjectAltName que coincide con la dirección IP del host.

Seguridad de vCloud Director

VMware, Inc. 20

Podrá encontrar información adicional en (RFC 6125 del grupo) y (RFC 5280). También debe consultar la entidad de certificación.

Certificados de endpoints públicosLos endpoints expuestos a una red empresarial u otra red pública como Internet deben protegerse mediante un certificado firmado por una entidad de certificación raíz conocida. Estos endpoints incluyen:

n La dirección HTTPS de la celda y la dirección del proxy de la consola. Debe configurar ambas direcciones y proporcionar los detalles de su certificado y su almacén de claves durante la instalación.

n Equilibradores de carga que terminan SSL. Consulte Equilibradores de carga y terminación SSL.

En general, no es necesario importar los certificados firmados, ya que cualquier cliente SSL puede verificar la cadena de confianza hasta la raíz. Los certificados de menor nivel (de entidad de certificación empresarial o autofirmados) no se pueden comprobar de esta manera; como a estos los ha creado el equipo de seguridad local, ellos podrán indicar desde dónde importarlos.

Certificados de endpoints privados (internos)Los endpoints de las redes privadas, aquellos a los que no se puede acceder desde redes públicas y que, por lo general, se han creado para su uso específico con componentes de vCloud Director, como la base de datos y AMQP, pueden usar certificados firmados por una CA empresarial, o incluso emplear certificados autofirmados si es necesario. Estos endpoints incluyen:

n Conexiones internas con vSphere y NSX.

n Endpoints de AMQP que se conectan a vCloud Director y RabbitMQ.

n Conexiones con la base de datos PostgreSQL (opcional).

Tener un certificado firmado reduce las posibilidades de que una aplicación maliciosa consiga acceder a una red privada y enmascararse como un componente de vCloud Director legítimo.

Protocolos y conjuntos de cifrado admitidosvCloud Director admite varios protocolos HTTPS, incluidos TLS y SSL. TLS 1.0 no se admite de forma predeterminada, ya que tiene vulnerabilidades conocidas. Tras la instalación, puede usar la herramienta de administración de celdas para configurar el conjunto de protocolos y cifrado que admite el sistema para las conexiones HTTPS. Consulte Notas de la versión de vCloud Director para obtener más detalles.

Configurar certificados de vSphereEn vSphere 6.0 y versiones posteriores, VMware Certificate Authority (VMCA) aprovisiona cada host ESXi y cada servicio de vCenter Server con un certificado firmado por VMCA de forma predeterminada. Es posible reemplazar los certificados existentes por certificados nuevos firmados por VMCA, convertir a VMCA en una entidad de certificación subordinada, o bien, reemplazar todos los certificados por certificados personalizados. Consulte Certificados de seguridad de vSphere en la guía Seguridad de vSphere para obtener más información sobre la creación y la sustitución de los certificados utilizados por vCenter y ESXi.

Seguridad de vCloud Director

VMware, Inc. 21

Configurar vCloud Director para comprobar los certificados de vCenterSi desea configurar vCloud Director para comprobar los certificados de vCenter, cree un almacén de claves de Java en formato JCEKS que contenga los certificados de confianza utilizados para firmar los certificados de vCenter. (Los certificados de los servidores individuales de vCenter no se encuentran en este almacén, solo los certificados de CA que se usan para firmarlos).

Un comando como este importa un certificado con codificación PEM desde /tmp/cacert.pem en un almacén de claves denominado myca.ks:

$ keytool -import -alias default -keystore myca.ks -file /tmp/cacert.pem -storepass password -

storetype JCEKS

Un comando como este agrega otro certificado (/tmp/cacert2.pem en este ejemplo) al mismo almacén de claves:

$ keytool -importcert-keystore myca.ks -storepass password -file /tmp/cacert2.pem -storetype JCEKS

Cuando se haya creado el almacén de claves, inicie sesión en vCloud Director como administrador del sistema. En la sección Configuración del sistema de la pestaña Administración, haga clic en General y desplácese hasta la parte inferior de la página.

Seleccione los certificados Comprobar vCenter y SSO de vSphere y Comprobar certificados de NSX Manager. Haga clic en el botón Examinar para buscar el almacén de claves de Java y, a continuación, haga clic en Abrir. Introduzca la contraseña del almacén de claves y haga clic en Aplicar.

Cuando se complete la operación, los certificados de confianza y otros datos se cargarán en la base de datos de vCloud Director. Por ello, esta operación solo se debe realizar una vez para todas las celdas.

Una vez que esta opción esté habilitada, se comprobarán los certificados de vCenter y NSX Manager, por lo que todas las instancias de vCenter y NSX Manager deben tener una cadena de certificados correcta y un certificado que coincida con su FQDN. Si no es así, se producirá un error en las conexiones con vCenter y NSX.

Importante Si ha cambiado los certificados después de agregar instancias de vCentery NSX Manager a vCloud Director, deberá forzar la reconexión con los servidores.

Actualizar los certificados y las claves de las celdas de vCloud DirectorCada servidor vCloud Director requiere dos certificados SSL, uno para el servicio HTTP y otro para el servicio de proxy de consola en un archivo de almacén de claves Java. Cuando instale vCloud Director, deberá proporcionar el nombre de ruta de estos almacenes de claves. Los certificados firmados ofrecen el nivel más alto de confianza.

Seguridad de vCloud Director

VMware, Inc. 22

El comando certificates de la herramienta de administración de celdas automatiza el proceso de sustitución de los certificados existentes por otros nuevos. Utilice el comando certificates para sustituir certificados autofirmados por certificados firmados, o bien sustituir certificados que estén a punto de caducar por otros nuevos. Para crear un almacén de claves JCEKS que contenga certificados firmados, consulte Crear e importar certificados SSL firmados en la Guía de instalación y actualización de vCloud Director.

Para sustituir los certificados SSL de uno o ambos endpoints, use un comando que tenga el siguiente formato:

cell-management-toolcertificatesoptions

Para obtener más información, consulte Sustituir certificados para los endpoints de HTTP y proxy de la consola en la Guía del administrador de vCloud Director.

FirewallsLas celdas de vCloud Director deben ser accesibles para los tenants y los administradores del sistema que se conectan a ellas desde fuera del perímetro de la red del proveedor de servicios. El enfoque recomendado para hacer que los servicios de vCloud Director estén disponibles en el exterior consiste en colocar un firewall de aplicación web entre Internet (u otra red de la empresa) y cada endpoint de vCloud Director.

Los firewalls de red segmentan las redes físicas o virtuales de modo que solo pueda pasar entre ellos un tráfico limitado y bien definido en puertos y protocolos concretos. Este documento no define la lógica de implementación de firewall en general ni explica los detalles de configuración de firewall. Estos temas no se tratan en esta guía. Por el contrario, esta guía identifica las ubicaciones donde se recomienda colocar los firewalls de red en relación con los distintos componentes de una implementación de vCloud Director.

Nota Las conexiones de administración se pueden limitar más mediante restricciones de dirección IP en la red o las VPN por tenant. Este nivel de protección puede ser apropiado para ciertas implementaciones, pero está fuera del alcance de este documento.

Debido a que las celdas de vCloud Director están en la DMZ, el acceso a los servicios que necesitan debería realizarse mediante un firewall de red. En concreto, se recomienda restringir el acceso a la base de datos de vCloud Director, vCenter Server, los hosts ESXi, AMQP y los servicios de copia de seguridad o similares a una red interna a la que no se puede acceder desde el lado público del firewall. Consulte Requisitos de seguridad de red para obtener la lista de puertos que se deben abrir en dicho firewall.

Bloquear el tráfico malintencionadoSe recomienda aplicar ciertas reglas de firewall para proteger el sistema frente a amenazas de red:

n Descartar los paquetes que se originen en direcciones que no se pueden enrutar (suplantación de direcciones IP)

n Descartar los paquetes TCP con un formato incorrecto

Seguridad de vCloud Director

VMware, Inc. 23

n Limitar la tasa de solicitudes, especialmente las solicitudes SYN para protegerse frente a un ataque "flood" de SYN (un intento de denegación de servicio)

n Tener en cuenta la posibilidad de denegar el tráfico saliente del firewall que no se origine a partir de una solicitud entrante

Estas y otras reglas se suelen aplicar a los firewalls de aplicación web, y es posible que el firewall de red elegido para la implementación las aplique de forma predeterminada. Consulte la documentación del firewall para obtener instrucciones de configuración específicas y saber cuáles son las capacidades predeterminadas.

Equilibradores de carga y terminación SSLLos endpoints públicos de vCloud Director se deben proteger con un firewall de aplicaciones web (WAF). Cuando se utiliza junto con un equilibrador de carga, configure el WAF para permitir la inspección y el bloqueo del tráfico malintencionado mediante la finalización de la conexión HTTPS en el WAF. De este modo se permite que el WAF complete el protocolo de enlace utilizando su propio certificado y reenvíe solicitudes aceptables a la celda con un encabezado de X-Forwarded-For.

Las solicitudes del cliente a vCloud Director se deben realizar en un endpoint HTTPS. (Se admite una conexión HTTP con la celda, pero no es segura). Incluso cuando las comunicaciones entre el cliente remoto y el WAF están protegidas por HTTPS, es necesario que también se pueda realizar la comunicación de WAF a celda a través de HTTPS.

En el siguiente diagrama básico, donde se omite el equilibrador de carga, se muestran las dos conexiones TLS o SSL que existen cuando se utiliza la terminación TLS o SSL: una entre el equipo del usuario y el WAF, y otra entre el firewall y la celda de vCloud Director.

Figura 5-1. Configuración de TLS/SSL con WAF

Terminación TLS/SSL y certificadosAl configurar la terminación TLS o SSL, no solo es importante instalar un certificado firmado por la entidad de certificación en el WAF para que las aplicaciones de ese cliente, como la API de vCloud y la consola web, puedan comprobar la identidad del servidor, sino también usar un certificado firmado por la entidad de certificación en las celdas, incluso cuando solo las vaya a ver el WAF. Aunque el WAF acepta

Seguridad de vCloud Director

VMware, Inc. 24

los certificados autofirmados, solo se recomienda usarlos cuando cada certificado se acepta manualmente durante la instalación; sin embargo, esto limita la flexibilidad del grupo del servidor de vCloud Director, ya que cada celda se debe configurar de forma manual (y se tiene que volver a configurar cuando se renueven los certificados).

Por último, si el equilibrador de carga es independiente del WAF, también se debe utilizar un certificado firmado por la CA. Los procedimientos para agregar rutas de acceso de cadena de certificados para los endpoints del equilibrador de carga se explican en Personalizar endpoints públicos en la Guía del administrador de vCloud Director.

Encabezado X-Forwarded-ForX-Forwarded-For es un encabezado muy utilizado que admiten muchos servidores proxy y firewalls. Se recomienda que, si es posible, habilite la generación de este encabezado en el firewall.

Cuando hay un firewall delante de la celda, esta puede solicitar la dirección IP del cliente para poder iniciar su sesión; sin embargo, por lo general, obtendrá en su lugar la dirección del firewall. No obstante, si el encabezado de X-Forwarded-For está en la solicitud que recibe la celda, registrará esta dirección como la dirección del cliente y registrará la dirección del firewall como un campo de proxyAddress independiente en el log.

Protección de AMQP (RabbitMQ)AMQP, el protocolo de cola de mensajes avanzado, es un estándar abierto para las colas de mensajes que admite mensajería flexible para sistemas corporativos. vCloud Director utiliza el agente AMQP de RabbitMQ para proporcionar el bus de mensajería que utilizan los servicios de extensión, las extensiones de objeto y las notificaciones de tareas de bloqueo.

Los mensajes que se publican en RabbitMQ incluyen información confidencial. La exposición del tráfico de AMQP entre celdas de vCloud Director puede suponer una amenaza de seguridad para el sistema y sus tenants. Los endpoints AMQP se deben configurar para que usen SSL. Los puertos AMQP se deben bloquear en el firewall del sistema. Se debe permitir a los clientes de terceros que consumen mensajes AMQP operar en la DMZ. Cualquier código que consuma mensajes de vCloud Director debe someterse a una auditoría por parte del equipo de seguridad del proveedor de servicios.

Para obtener más información acerca de RabbitMQ y cómo funciona con vCloud Director, consulte la entrada del blog de vCat-SP en https://blogs.vmware.com/vcat/2015/08/vcloud-director-for-service-providers-vcd-sp-and-rabbitmq-security.html.

Proteger el servicio AMQP con SSLPara utilizar SSL con el servicio AMQP de vCloud Director, seleccione Utilizar SSL en la sección Configuración de broker AMQP de la página Extensibilidad de la consola web de vCloud Director y proporcione:

n un nombre de ruta de certificado SSL o

n un nombre de ruta, un nombre de usuario y una contraseña de almacén de confianza de JCEKS

Seguridad de vCloud Director

VMware, Inc. 25

Consulte Configurar un broker AMQP en la Guía del administrador de vCloud Director para ver el procedimiento completo.

Importante Aunque hay disponible una opción Aceptar todos los certificados, no se recomienda seleccionarla cuando la seguridad sea un asunto prioritario. Al aceptar todos los certificados sin comprobarlos, se puede facilitar que se produzcan ataques de intermediarios.

Bloquear los puertos AMQP en el firewall del sistemaComo se indicó en Requisitos de seguridad de red, se debe poder acceder a varios puertos AMQP en la red de administración. No se debe poder acceder, sin embargo, a ningún endpoint AMQP desde las redes públicas o de empresa.

Protección de Cassandra (base de datos de métricas de máquina virtual)Cassandra es una base de datos de código abierto que sirve para proporcionar el almacén de respaldo de una solución escalable y de alto rendimiento para recopilar datos de series temporales como las métricas de máquina virtual. Los datos enviados a Cassandra y almacenados en el clúster de Cassandra podrían ser confidenciales y deben protegerse.

Además de colocarla en una red de administración dedicada, la infraestructura de Cassandra debe protegerse con SSL.

Habilitar el cifrado de cliente a nodo de CassandraConsulte la página Cifrado de cliente a nodo de Cassandra para obtener más información sobre cómo instalar certificados SSL y habilitar el cifrado.

Se recomienda utilizar los certificados que hayan sido firmados por una entidad de certificación conocida. Al hacerlo, no será necesaria ninguna configuración adicional en vCloud Director. Si utiliza certificados autofirmados, debe importarlos manualmente en vCloud Director. Utilice el comando import-trusted-certificates de la herramienta de administración de celdas como se muestra en Importar certificados SSL desde servicios externos en la Guía del administrador de vCloud Director

Proteger el acceso a JMXComo se describe en Guía del administrador de vCloud Director, cada celda de vCloud Director expone varios MBeans a través de JMX para permitir la administración de las operaciones del servidor y proporcionar acceso a estadísticas internas. Debido a que esta interfaz puede exponer información confidencial sobre el sistema que se está ejecutando y afectar su funcionamiento, es fundamental que el acceso a JMX esté estrictamente controlado.

Seguridad de vCloud Director

VMware, Inc. 26

Autenticación de JMXSolamente pueden acceder a la interfaz de JMX los administradores del sistema de vCloud Director, que deben autenticarse en JMX con las mismas credenciales que usen para acceder a vCloud Director. Esta función no se puede configurar.

Limitar conexiones a JMXDado que JMX es una interfaz de administración destinada solo a administradores del sistema, no hay ninguna razón por la que se deba exponer fuera de la red de administración de vCloud Director. Si el sistema tiene asignada una tercera dirección IP exclusivamente para administración, enlace JMX directamente a esta dirección IP. De forma predeterminada, el conector JMX de vCloud Director se enlaza a la dirección IP principal que especificó durante la configuración del sistema. Puede invalidar este valor predeterminado si inserta la siguiente propiedad en /opt/vmware/vcloud-service-director/etc/global.properties:

vcloud.cell.ip.management=Dirección IP o nombre de host para la red de administración a la que debe

enlazarse el conector JMX

La configuración más segura enlaza el conector JMX a la dirección de host local:

vcloud.cell.ip.management=127.0.0.1

Independientemente de los dispositivos de firewall y enrutamiento empleados, las direcciones IP asignadas a esta red de administración y el puerto JMX (el predeterminado es 8999) no deberían permitir que los usuarios de la organización o de Internet atraviesen el límite de la red.

Con este ajuste establecido en global.properties, solamente puede llegarse a JMX desde el sistema de vCloud Director local. Ninguna conexión externa al puerto JMX se realizará correctamente, independientemente de la configuración de enrutamiento de la red.

Proteger las comunicaciones de JMXSi se expone JMX solo a la dirección de host local (127.0.0.1), podrá proteger las comunicaciones de JMX mediante el uso de SSH como mecanismo de túnel para cualquier acceso a JMX.

Si sus necesidades de administración no permiten el uso de esta configuración y JMX debe exponerse fuera de la celda de vCloud Director, será necesario proteger JMX mediante HTTPS. Para hacerlo, configure la siguiente variable de entorno:

# export VCLOUD_JAVA_OPTS="-Dcom.sun.management.jmxremote.ssl=true \

-Djavax.net.keyStore=rutaAlAlmacénDeClaves \

-Djavax.net.sll.keyStorePassword=contraseña \

-Djavax.net.ssl.keyStoreType=tipoDeAlmacén"

Después, debe reiniciar vCloud Director.

Seguridad de vCloud Director

VMware, Inc. 27

Los clientes de JMX ahora deberán conectarse con HTTPS, pero deben tener acceso al certificado de CA. Por ejemplo, para jconsole debe importar el certificado de CA en un almacén de claves en la máquina que ejecutará jconsole. A continuación, inicie jconsole con los siguientes argumentos de la línea de comandos:

# jconsole -J-Djavax.net.ssl.trustStoreType=tipoDeAlmacén \

-J-Djavax.net.ssl.trustStore=rutaAlAlmacénDeClaves \

-J-Djavax.net.ssl.trustStorePassword=contraseña

Los certificados autofirmados (no recomendados para una implementación de producción) convertirían este proceso en algo difícil de manejar, ya que se necesitaría cada certificado autofirmado en un almacén de claves en la máquina que ejecuta el cliente de JMX. Es más fácil que los certificados firmados por una entidad de certificación sean compatibles aquí porque solo se necesita el certificado de la entidad de certificación en la máquina cliente de JMX.

Configuración de la red de administraciónLa red de administración de vCloud Director es una red privada que funciona como la infraestructura de nube y proporciona acceso a los sistemas de cliente que se utilizan para realizar funciones administrativas en vCloud Director.

Los sistemas que se conectan a la red de administración incluyen el servidor de base de datos de vCloud Director, un servidor NFS para el almacenamiento de transferencias, los servidores de vCenter, un directorio LDAPv3 opcional para autenticar a los administradores del proveedor, los directorios LDAPv3 que mantiene el proveedor para autenticar a los usuarios de la organización y los administradores de NSX. Los servidores de vCenter de esta red también tienen que acceder a sus propios servidores de Active Directory.

Requisitos de configuración de la red de administración de la infraestructura virtualPara la red de administración es muy importante ser independiente de las redes de datos de la máquina virtual. Más aún en un entorno de nube donde el proveedor y los tenants pertenezcan a distintas organizaciones. Seguro que no desea exponer la red de administración del proveedor a posibles ataques de vApps de la organización. Del mismo modo, la red de administración debe ser independiente de la DMZ que proporciona acceso a los administradores de la organización. A pesar de que pueden estar accediendo a las mismas interfaces como administradores del sistema del proveedor, el concepto de DMZ es importante a la hora de segmentar el tráfico público del privado y de proporcionar una estrategia de defensa exhaustiva.

Desde una perspectiva de conectividad física, la red de datos de la máquina virtual debe ser independiente de la red de administración. Es la única forma de proteger los sistemas de administración ante máquinas virtuales malintencionadas. Igualmente, las celdas de vCloud Director existen físicamente en la DMZ. En el diagrama de implementación física, los servidores del módulo de administración que se conectan a través de los módulos de nube lo hacen a través de una red física independiente y determinadas reglas del firewall permiten que pase este tráfico.

Seguridad de vCloud Director

VMware, Inc. 28

Desde una perspectiva de arquitectura de red, se requiere el firewall interno que intercede ante las conexiones de vCenter y vCloud Director con vSphere (y otras redes). No se trata de si distintas máquinas virtuales en un solo host se pueden conectar con una zona DMZ y una red privada a la vez. En su lugar, hay máquinas virtuales en ese módulo de administración, las celdas de nube, que se conectan ellas mismas con ambas redes. Si bien el software de vCloud Director se diseñó y se implementó según la política de seguridad de productos de VMware y se cumplieron los requisitos de seguridad, no se trata de un firewall propiamente dicho y, por lo tanto, no debería mediar tráfico por sí mismo entre la DMZ y las redes de administración privadas. Esa es la función del firewall.

Otras redes relacionadasComo se muestra en los diagramas de implementación física y lógica, las redes de almacenamiento también son físicamente independientes. Esto sigue las prácticas recomendadas de vSphere y protege al tenant y al proveedor de almacenamiento ante máquinas virtuales malintencionadas. Lo mismo sucede con la red de copia de seguridad. Técnicamente se trata de una rama de la red de administración. Sus requisitos específicos y su configuración dependen del software de copia de seguridad y la configuración que se esté usando.

vMotion no siempre se coloca en una red independiente de la red de administración; sin embargo, en la nube, es importante desde una perspectiva de separación de tareas. Por lo general, vMotion tiene lugar en una zona segura y, si se coloca en la red de administración, permite que un administrador de proveedores u otro usuario con acceso a esa red "examine" el tráfico de vMotion, infringiendo la privacidad de las organizaciones. Por esta razón, se debe crear una red física independiente para vMotion en las cargas de trabajo de nube.

Auditoría y registroPoder registrar y supervisar las actividades de los usuarios es una parte importante de la seguridad general del sistema. La mayoría de organizaciones tiene normas que rigen quién tiene permiso para acceder al software y los recursos relacionados con el hardware, así como para realizar cambios en ellos. Mantener un registro de auditoría de las actividades importantes permite que la organización compruebe el cumplimiento de las reglas, detecte las infracciones e inicie actividades de corrección. En algunas empresas, se aplican leyes y normativas externas que exigen supervisión continua y comprobación de las reglas de acceso y autorización.

Un registro de auditoría también puede ser útil para la detección de intentos, sean exitosos o no, para obtener acceso no autorizado al sistema, sondear su información o interrumpir su funcionamiento. Si se sabe que se intentó perpetrar un ataque, y se conocen los detalles de dicho ataque, se pueden mitigar los daños y prevenir ataques futuros.

Tanto si es necesario como si no, otra práctica de seguridad recomendada consiste en examinar periódicamente los registros en busca de actividades sospechosas, inusuales o no autorizadas. El análisis rutinario de los registros también permite identificar errores y fallos de configuración del sistema y ayuda a garantizar el cumplimiento de los SLA.

Seguridad de vCloud Director

VMware, Inc. 29

vCloud Director incluye dos tipos de registro:

Registros de diagnóstico

Los registros de diagnóstico que se almacenan en el directorio de registros de cada celda. Estos registros son útiles para la resolución de problemas, pero no están pensados para conservar un historial de auditoría de las interacciones importantes del sistema. Cada celda de vCloud Director crea varios archivos de registro de diagnóstico de los que se describen en Ver los registros de vCloud Director en la Guía del administrador de vCloud Director.

Registros de auditoría Los registros de auditoría registran las acciones significativas, incluidos el inicio y el cierre de la sesión. El registro de auditoría del sistema se almacena en la base de datos de vCloud Director y se puede supervisar en la interfaz de usuario web. Cada administrador de organización y el administrador del sistema visualizan una vista del registro ajustada a su área específica de control.

Se recomienda utilizar la utilidad syslog para conservar estos y otros registros de vCloud Director. Además, se debe considerar el uso de vRealize Log Insight, que admite la recopilación remota de otros registros, como los registros de solicitudes, que no están basados en log4j.

Usar syslog con vCloud DirectorTal como se detalla en la Guía de instalación y actualización de vCloud Director, se puede configurar un servidor de syslog durante la instalación. Se recomienda exportar los registros a un servidor syslog por varias razones:

n Los registros de la base de datos no se conservan después de 90 días, mientras que los registros que se transmiten a través de syslog se pueden conservar todo el tiempo que se desee.

n Permite que los registros de auditoría de las celdas se visualicen juntos en una ubicación central al mismo tiempo.

n Protege los registros de auditoría frente a pérdidas en el sistema local debido a errores, falta de espacio en disco, vulneración, etc.

n Admite operaciones forenses ante problemas como los mencionados anteriormente.

n Es el método mediante el cual muchos sistemas de administración de registros y administración de información y eventos de seguridad (SIEM) se integrarán con vCloud Director. Esto permite:

n Correlación de eventos y actividades en vCloud Director, vSphere, NSX e incluso las capas de hardware físico de la pila.

n Integración de las operaciones de seguridad de nube con el resto de operaciones de seguridad del proveedor de nube o de la empresa, entre infraestructuras físicas, virtuales y de nube.

n El registro en un sistema remoto diferente de aquel en el que se ha implementado la celda impide la adulteración de los registros. Una vulneración de la celda no permite el acceso a ella ni la modificación de la información de registro de auditoría necesariamente.

Seguridad de vCloud Director

VMware, Inc. 30

Si no se ha configurado un destino de syslog para el registro en la instalación inicial, se puede configurar más tarde yendo a cada celda, editando el archivo $VCLOUD_HOME/etc/global.properties y reiniciando la celda.

Consulte Requisitos de seguridad de red para obtener la lista de puertos que deben permanecer abiertos desde el host de vCloud Director hasta el servidor syslog. Los detalles de configuración del servidor syslog son específicos del sistema y están fuera del alcance de este documento. Se recomienda que el servidor syslog se configure con redundancia, para asegurar que los eventos esenciales se registren siempre.

La explicación anterior solo abarca el envío del registro de auditoría a un servidor syslog. Las organizaciones de operaciones de seguridad y operaciones de TI también pueden beneficiarse de la agregación y la administración centralizadas de los registros de diagnóstico mencionados anteriormente. Existen varios métodos para recopilar estos registros, incluidos la programación de una tarea periódica para copiarlos en una ubicación centralizada, la configuración de un registrador adicional en el archivo log4j.properties ($VCLOUD_HOME/etc/log4j.properties) en un servidor syslog central o el uso de una utilidad de recopilación de registros como vRealize Log Insight para supervisar y copiar los archivos de registro en una ubicación centralizada. La configuración de estas opciones depende del sistema que prefiera utilizar en su entorno, y está fuera del alcance de este documento.

Importante Se recomienda utilizar una infraestructura de syslog que admita TLS. El protocolo syslog (UDP) predeterminado no ofrece cifrado en tránsito ni control o confirmación de la transmisión. La falta de cifrado expone los datos de registro al rastreo (la información presente en los registros podría utilizarse para iniciar ataques posteriores), y la falta de control de la transmisión podría permitir que un atacante alterase los datos de registro. Para obtener más información, consulte la sección 4 de RFC 5426.

Registro de diagnóstico y sustitución de registrosEl archivo de registros de solicitud Jetty ($VCLOUD_HOME/logs/yyyy_mm_dd.request.log) está controlado de forma programática por el servidor (HTTP) Jetty, pero no tiene un límite de tamaño máximo. Por este motivo, existe un riesgo de crecimiento del archivo de registro descontrolado. Por cada solicitud HTTP procesada por Jetty, se agrega una entrada de registro al archivo actual. Por este motivo, le recomendamos que utilice logrotate u otros métodos similares para controlar el tamaño de los registros y el número de archivos de registro antiguos que se conservan.

Los demás archivos de registro de diagnóstico tienen un límite total de 400 MB. Asegúrese de tener suficiente espacio en disco para almacenar esos archivos, más el tamaño que permita que consuman los registros de solicitudes Jetty. Tal como se menciona anteriormente, el registro centralizado garantiza que no se pierda información de diagnóstico valiosa al llegar al total de 400 MB del archivo de registro, además los archivos se alternan o se eliminan.

Seguridad de vCloud Director

VMware, Inc. 31

NTP y registrosLa Guía de instalación y actualización de vCloud Director identifica NTP como un requisito para todas las celdas de vCloud Director. Un beneficio adicional del uso de NTP es que los mensajes de registro de las celdas tienen marcas de tiempo sincronizadas. De hecho, las herramientas de administración de registro y los sistemas SIEM incorporan sus propias marcas de tiempo para permitir la coordinación de los registros de varios orígenes, pero estas marcas de tiempo son la hora indicada por esos sistemas, no la hora en la que se registró el evento originalmente.

Registros adicionalesOtros sistemas conectados a vCloud Director y que este utiliza crean registros de auditoría que deben consolidarse en los procesos de auditoría. Estos incluyen los registros de NSX Manager, la base de datos de vCloud Director, vCenter Server y los hosts de vSphere. Los detalles de los archivos de registro de cada sistema y su finalidad están fuera del alcance de este documento y se pueden encontrar en la documentación relacionada con esos productos.

Seguridad de vCloud Director

VMware, Inc. 32

Seguridad de tenants 6El proveedor de servicios, los administradores del sistema y los administradores de la organización son los responsables de la seguridad de cada organización de tenants de vCloud Director.

La protección de una organización de tenants de vCloud Director frente a ataques externos consiste principalmente en proporcionar una buena seguridad de nivel del sistema para que los atacantes externos no puedan acceder a los recursos de los tenants. El proveedor de servicios también debe ser consciente de la posibilidad de que sea un tenant el que realice el ataque o simplemente interfiera con otro tenant. Algunos de los posibles ataques entre tenants incluyen fisgonear detalles a nivel de sistema de los recursos informáticos, de almacenamiento y de red. Las interferencias, ya sean intencionadas o no, surgen cuando los recursos del sistema se comparten entre varios tenants (que pueden sospecharse mutuamente) y un tenant consigue consumir una cantidad suficiente de esos recursos para denegar a los demás tenants el nivel de servicio que esperan recibir. Esta situación a menudo se conoce como el problema del “vecino ruidoso”.

Como se describe en Capítulo 3 Arquitectura y funciones de seguridad de vCloud Director, vCloud Director está diseñado para permitir un uso compartido de recursos del sistema transparente entre un gran número de tenants. En general, un proveedor de servicios tiene libertad para implementar los recursos del sistema de forma que potencie al máximo la eficiencia del sistema a la vez que minimiza los posibles problemas de tiempo de inactividad. Cada vez que se comparten recursos entre organizaciones de tenants, el proveedor de servicios debe plantearse cómo puede afectar este uso compartido a varias operaciones de los tenants y si podría dar lugar a ataques entre tenants.

Este capítulo incluye los siguientes temas:

n Seguridad de la red en organizaciones de tenants

n Aislamiento y asignación de recursos

n Administración de cuentas de usuario

Seguridad de la red en organizaciones de tenantsA pesar de que las organizaciones de vCloud Director son responsables de su propia seguridad de red, el proveedor de servicios debe proteger las redes externas con un firewall.

VMware, Inc. 33

Dentro del sistema de vCloud Director, las redes VXLAN y VLAN exigen que se separe el tráfico de paquetes que equivale a lo que se puede conseguir con redes físicas independientes. También ofrecen una gama de opciones de enrutamiento y de protección con firewall que concede a las organizaciones tener un control detallado sobre el acceso a sus cargas de trabajo desde sistemas externos y los de dentro de la organización. Estas funciones se describen en detalle en la documentación de vCloud Director en http://docs.vmware.com. En su mayor parte, un proveedor de servicios que haya diseñado una protección eficaz para el sistema en sí (incluidos un firewall de aplicaciones web, equilibradores de carga de la terminación SSL y certificados digitales bien firmados) no necesita tomar parte activa para establecer o mantener la seguridad de las redes VDC de la organización.

Acceso externo a las cargas de trabajo de tenantsAl configurar el acceso a las cargas de trabajo de la organización (vApps) desde Internet o una red empresarial, el proveedor de servicios no debe nunca pasar por alto los requisitos de firewall de la infraestructura de vSphere que ha implementado y usado vCloud Director. Lo más probable es que algunas vApps necesiten acceso a Internet o que haya que acceder a ellas de forma remota, ya sea a través de RDP, SSH, etc., para la administración, o a través de HTTP u otros protocolos por parte de los usuarios finales de dichos servicios. Por ese motivo, se recomienda utilizar dos redes de datos de máquina virtual distintas (como se muestra en los diagramas de arquitectura en Aislamiento y asignación de recursos) para diferentes usos, cada uno con su protección de firewall de red.

Las máquinas virtuales que necesitan accesibilidad desde fuera de la nube (por ejemplo, desde Internet) se podrían conectar a una red pública o una red privada con enrutamiento NAT con el enrutamiento de puertos configurado para los servicios expuestos. La red externa a la que se conectan estas redes VDC de la organización requeriría un firewall que la protegiera y que permitiera la entrada del tráfico acordado a esta red de la DMZ. Es decir, el proveedor de servicios tiene que asegurarse de que no todos los puertos y protocolos puedan iniciar una conexión con la red externa de la DMZ. Al mismo tiempo, debe confirmar que se permite suficiente tráfico para que las vApps de esa organización puedan proporcionar los servicios para los que se han creado. Por lo general, esto incluye los puertos 80/TCP y 443/TCP, pero se podrían incluir otros protocolos y puertos. El proveedor de servicios debe determinar cuál es la mejor manera de mantener este equilibrio y debe saber que, desde una perspectiva de seguridad, se deben bloquear los protocolos y puertos innecesarios.

En general, se recomienda que las vApps que necesitan accesibilidad a Internet y desde Internet se conecten a una red VDC de organización enrutada que se configure para permitir únicamente los tipos de conexiones entrantes y salientes que sean necesarios. De este modo se le da a la organización el control del firewall de NSX y las reglas de enrutamiento de puertos. Esta configuración no elimina la necesidad de un firewall de red que separe la red externa que utilizan estas redes VDC de la organización. Esta circunstancia se da porque las redes VDC públicas de la organización no tienen ninguna protección de firewall de vCloud Director. El firewall independiente se necesita para crear una DMZ (no obstante, esta función la podría realizar una instancia independiente de NSX Edge).

Seguridad de vCloud Director

VMware, Inc. 34

Del mismo modo, se utiliza una red VDC privada de organización con enrutamiento NAT en una red de datos de máquina virtual que permita que las máquinas virtuales accedan a Internet. Como se mencionó anteriormente, una instancia de NSX Edge proporciona las capacidades de firewall y NAT para esta red de datos interna para máquinas virtuales. De nuevo, la parte de la red externa de esta red con enrutamiento debe estar en la zona DMZ para que un firewall de red independiente separe la DMZ de la conexión a Internet.

Aislamiento y asignación de recursosLa implementación de un proveedor de servicios estándar de vCloud Director visualiza el uso compartido de recursos de vSphere entre varias organizaciones de tenants. De este modo se proporciona a las organizaciones la máxima flexibilidad y al proveedor, el máximo aprovechamiento de los recursos informáticos, de red y de almacenamiento aprovisionados. A continuación se muestran diagramas de ejemplos de implementaciones físicas y lógicas.

En lo que queda de esta subsección se describen los componentes en un alto nivel, mientras que en las subsecciones posteriores se describen las recomendaciones específicas en torno a los grupos de recursos, los almacenes de datos, la configuración de redes y la de otros componentes.

Implementación de recursos compartidosFigura 6-1. Diagrama de implementación física y Figura 6-2. Diagrama de implementación lógica son dos vistas de la misma instalación de vCloud Director. En estas figuras, utilizamos el término "módulo" para indicar un grupo de recursos (máquinas físicas o virtuales) que se dedica a la administración del sistema ("módulo de administración") o de las cargas de trabajo de los tenants ("módulo de nube").

Seguridad de vCloud Director

VMware, Inc. 35

Figura 6-1. Diagrama de implementación física

Si nos fijamos en Figura 6-2. Diagrama de implementación lógica, la parte izquierda muestra las celdas de vCloud Director en una DMZ con equilibrio de carga. La zona DMZ también contiene un WAF y, opcionalmente, una VPN administrativa por tenant. Un proveedor de servicios puede encargarse de configurar esta VPN para cada organización y así limitar más estrictamente qué usuarios y qué direcciones IP pueden acceder a los servicios que quedan expuestos mediante el WAF. Además, un tenant puede configurar una VPN para conectarse con sus cargas de trabajo en las instalaciones y los datos con las máquinas virtuales en la nube. La configuración de este tipo de VPN no se incluye en este documento.

Seguridad de vCloud Director

VMware, Inc. 36

Figura 6-2. Diagrama de implementación lógica

Detrás de las celdas están los elementos de administración privada que requiere vCloud Director; entre ellos, vCenter, NSX, la base de datos de vCloud Director, etc. A sus conexiones las controlan exclusivamente los firewalls del diagrama, ya que a esos servicios no se puede acceder desde otras máquinas que estén en la DMZ ni directamente desde Internet.

Seguridad de vCloud Director

VMware, Inc. 37

La figura Figura 6-3. Redes del módulo de administración solo se centra en el módulo de administración. Muestra que se necesitan al menos dos, si no tres, redes físicas independientes conectadas a ese módulo. Aquí se incluye la red de DMZ con equilibrio de carga, la red de administración privada y una red opcional de almacenamiento dedicado, con una configuración específica del proveedor.

Figura 6-3. Redes del módulo de administración

Con respecto a los hosts de vSphere, agrupados en distintos dominios de seguridad, cada uno de ellos tiene redes externas que se muestran como una red de datos de DMZ de máquina virtual para que se usen como redes VDC públicas de organización, así como redes de datos de máquina virtual para redes VDC privadas de organización que se puedan enrutar a una red externa.

La figura Figura 6-4. Redes de módulo de nube se centra en los módulos de nube. Muestra cuatro redes físicas; sin embargo, la red de almacenamiento es específica para las tecnologías de hardware y de almacenamiento que haya elegido en particular. Si los grupos de recursos no incluyen los clústeres, es posible que no tenga que proporcionar una red de datos física de máquina virtual. De lo contrario (en caso de que los grupos de recursos sí abarquen los clústeres), este documento recomienda una red física independiente para el tráfico de vMotion.

Figura 6-4. Redes de módulo de nube

Seguridad de vCloud Director

VMware, Inc. 38

También se supone que las tecnologías de seguridad de centro de datos más habituales, como IDS/IPS, SIEM, la administración de configuraciones, la administración de revisiones, la administración de vulnerabilidades, el antivirus y los sistemas de administración de GRC, se aplicarán a vCloud Director, a sus sistemas asociados, a vSphere y a sus sistemas asociados, y a las redes e infraestructuras de almacenamiento que sean compatibles. Los detalles sobre estos sistemas tampoco se incluyen en este documento.

Recomendaciones sobre aislamiento y uso compartido de recursosEn condiciones normales, un proveedor de servicios puede compartir recursos informáticos, de almacenamiento y de red entre varias organizaciones de tenants. El sistema aplica el aislamiento mediante prácticas de ingeniería segura y abstracción en el hipervisor y la pila de software de vCloud Director.

Las organizaciones de tenants comparten los grupos de recursos subyacentes, los almacenes de datos y las redes externas expuestas a través de un solo VDC de proveedor, sin que ello afecte a los recursos que no poseen (o incluso desconozcan que existen dichos recursos). Mediante la correcta administración del almacenamiento de vApp y las concesiones de tiempo de ejecución, las cuotas de vApp, los límites en las operaciones de uso intensivo de recursos y los modelos de asignación de VDC de la organización, es posible garantizar que un tenant no denegará el servicio a otro de forma intencionada o accidental. Por ejemplo, en una configuración muy conservadora, todos los VDC de organización se configurarían bajo el modelo de asignación de grupo de reserva y nunca se sobreasignarían recursos. En este documento no se explicarán todas las opciones posibles, pero se destacarán algunos puntos en las siguientes subsecciones.

Dominios de seguridad y VDC de proveedorAunque las organizaciones de tenants cuenten con un aislamiento adecuado del software y una configuración adecuada de la organización, a veces es posible que no quieran que se ejecuten cargas de trabajo diferentes o que estas se almacenen en un determinado recurso informático, de red o de almacenamiento. Esto no eleva el sistema general a un entorno de “alta seguridad” (cuya discusión queda fuera del alcance de este documento), pero plantea la necesidad de segmentar la nube en varios dominios de seguridad. Estos son algunos ejemplos de cargas de trabajo que requieren dicho tratamiento:

n Datos sujetos a leyes de privacidad que requieren que se almacenen y procesen dentro de regiones preestablecidas.

n Datos y recursos que son propiedad de países u organizaciones que, a pesar de confiar en el aislamiento de la nube, exigen que sus VDC no puedan compartir recursos con determinados tenants (como una empresa de la competencia) por cuestiones de prudencia y máxima protección.

En estos y otros casos, los grupos de recursos, las redes y los almacenes de datos deben segmentarse en diferentes “dominios de seguridad” a través de distintos VDC de proveedor, mediante los cuales se puedan agrupar (o aislar) las vApp con problemas similares. Por ejemplo, se pueden identificar con claridad algunos VDC de proveedor como almacenamiento y procesamiento de datos en ciertos países.

Seguridad de vCloud Director

VMware, Inc. 39

Grupos de recursosDentro de un solo VDC de proveedor, puede haber varios grupos de recursos que agreguen recursos de CPU y memoria proporcionados por la infraestructura de vSphere subyacente. Desde una perspectiva de integridad y confidencialidad, no es necesario segmentar diferentes organizaciones entre diferentes grupos de recursos. Pero desde una perspectiva de disponibilidad, es posible que haya motivos para hacerlo. Este problema de administración de recursos depende de los modelos de asignación de VDC de organización, de las cargas de trabajo esperadas, de las cuotas y los límites que se aplican a estas organizaciones y de la velocidad con la que el proveedor pueda poner en línea otros recursos informáticos. En esta guía no se definen los distintos modelos de asignación de recursos y cómo afectan al uso de un grupo de recursos por parte de la organización. Tan solo se explica que, cuando se permite la sobreasignación de recursos de un grupo usado por más de una organización, se corre el riesgo de degradar la calidad del servicio para una o varias organizaciones. La supervisión adecuada de los niveles de servicio es fundamental para evitar la denegación de servicio que provoca una organización, pero la seguridad no dicta una separación específica de las organizaciones para que alcancen este objetivo.

Limitar el consumo compartido de recursos compartidosEn la configuración predeterminada, todos los tenants pueden consumir muchos recursos informáticos y de almacenamiento de vCloud Director en cantidades ilimitadas. El sistema ofrece varias maneras para que un administrador del sistema administre y supervise el consumo de estos recursos. El análisis detenido de las siguientes áreas es una parte importante para limitar la oportunidad de que un “vecino ruidoso” afecte al nivel de servicio proporcionado por vCloud Director.

Limitar las operaciones de uso intensivo de recursos

Consulte Configurar los límites del sistema en la Guía del administrador de vCloud Director.

Imponer cuotas razonables

Consulte Configurar concesión, cuotas y límites de organización y Configurar los límites del sistema (para limitar el número de VDC que puede crear un tenant y limitar el número de conexiones simultáneas por máquina virtual) en la Guía del administrador de vCloud Director.

Administrar concesiones de tiempo de ejecución y almacenamiento

Las concesiones proporcionan un grado de control sobre el consumo de almacenamiento y los recursos informáticos de los tenants. Un paso fundamental para administrar recursos compartidos consiste en limitar la duración de tiempo que una vApp puede permanecer encendida o que una vApp apagada puede consumir almacenamiento. Consulte Entender las concesiones en la Guía del administrador de vCloud Director.

Seguridad de vCloud Director

VMware, Inc. 40

Redes externasUn proveedor de servicios crea redes externas y las pone a disposición de los tenants para que puedan acceder a ellas. Una red externa puede compartirse de manera segura entre varias redes públicas ya que, por definición, esas redes son públicas. Será necesario recordar a los tenants que el tráfico en las redes externas corre el peligro de ser interceptado y, por lo tanto, deben tomar medidas de seguridad en el nivel de aplicación o de transporte en dichas redes por motivos de confidencialidad e integridad cuando sea oportuno.

Las redes enrutadas privadas pueden compartir estas redes externas en las mismas circunstancias: cuando se usan para conectarse a una red pública. En ocasiones, una red externa puede utilizarse en una red de VDC de organización para conectar dos vApp distintas y sus redes, o para conectar una red de vApp con el centro de datos empresariales. En estos casos, la red externa no se debe compartir entre varias organizaciones.

Desde luego, no es habitual que cada organización tenga una red física independiente, sino que es preferible que una red física compartida esté conectada a una sola red externa que esté identificada claramente como una red de DMZ. De este modo, las organizaciones sabrán que no ofrece protección de confidencialidad. Para aquellas comunicaciones que atraviesan una red externa pero que requieren protección de confidencialidad, como por ejemplo, una conexión de centro de datos de vApp a empresa o un puente de vApp a vApp a través de una red pública, se puede implementar una VPN. El motivo es que, para poder acceder a una vApp en una red enrutada, es necesario aprovechar el reenvío de direcciones IP mediante una dirección IP enrutable en esa red externa. Cualquier otra vApp que se conecta a esa red física puede enviar paquetes a esa vApp, aunque se trate de otra organización conectada a otra red externa. Para evitar esto, un proveedor de servicios puede utilizar el firewall distribuido de NSX y el enrutamiento lógico distribuido para forzar la separación del tráfico procedente de varios tenants en una misma red externa. Consulte Firewall distribuido de NSX y enrutamiento lógico en VMware vCloud® Architecture Toolkit™ for Service Providers (vCAT-SP).

Las redes de VDC de una organización que pertenecen a distintos tenants pueden compartir la misma red externa (como un vínculo superior de una puerta de enlace Edge), siempre que no permitan el acceso al interior con NAT y enmascaramiento de IP.

Importante Las redes avanzadas de vCloud Director permiten a los tenants y los proveedores de servicios emplear protocolos de enrutamiento dinámico como OSPF. El mecanismo de detección automática de OSPF, cuando se utiliza sin autenticación, podría establecer relaciones de emparejamiento entre puertas de enlace Edge que pertenezcan a diferentes tenants y empezar a intercambiar rutas. Para evitar esto, no habilite OSPF en interfaces compartidas públicas, a menos que habilite también la autenticación de OSPF para evitar el emparejamiento con puertas de enlace Edge sin autenticar.

Seguridad de vCloud Director

VMware, Inc. 41

Grupos de redesVarios tenants pueden usar un solo grupo de redes con la condición de que todas las redes del grupo estén debidamente aisladas. Los grupos de redes respaldados mediante VXLAN (predeterminados) dependen de que los switches físicos y virtuales se configuren para permitir la conectividad dentro de una VXLAN y el aislamiento entre las distintas VXLAN. Los grupos de redes respaldados mediante un grupo de puertos deben configurarse con grupos de puertos que estén aislados entre sí. Estos grupos de puertos podrían estar aislados físicamente, a través de las VXLAN.

De los tres tipos de grupos de redes (grupo de puertos, VLAN y VXLAN), resulta más fácil compartir un grupo de redes VXLAN de vCloud Director. Los grupos de VXLAN admiten muchas más redes que los grupos de redes respaldados mediante VLAN o un grupo de puertos, y el aislamiento se aplica en el nivel de kernel de vSphere. Aunque los switches físicos no aíslan el tráfico sin utilizar la VXLAN, VXLAN tampoco es susceptible de configurarse erróneamente en el nivel de hardware. Como ya se comentó antes, ninguna de las redes de un grupo de redes proporciona protección de confidencialidad para paquetes interceptados (por ejemplo, en la capa física).

Perfiles de almacenamientoLos perfiles de almacenamiento de vCloud Director agregan almacenes de datos de modo que permite al proveedor de servicios ofrecer capacidades de almacenamiento en niveles según la capacidad, el rendimiento y otros atributos. Las organizaciones de tenants no pueden acceder a almacenes de datos individuales. En su lugar, un tenant puede elegir a partir de un conjunto de perfiles de almacenamiento ofrecidos por el proveedor de servicios. Si los almacenes de datos subyacentes están configurados para poder acceder a ellos solamente desde la red de administración de vSphere, el riesgo de compartir almacenes de datos está limitado según la disponibilidad, como ocurre con los recursos informáticos. Una organización puede terminar usando más almacenamiento del esperado, limitando así la cantidad de almacenamiento disponible para otras organizaciones. Esto es especialmente útil con organizaciones que utilizan el modelo de asignación de pago por uso y la configuración predeterminada de “almacenamiento ilimitado”. Por este motivo, si comparte almacenes de datos, debe establecer un límite de almacenamiento, habilitar el aprovisionamiento ligero (si es posible) y supervisar que el almacenamiento se utilice con cuidado. También debe administrar cuidadosamente las concesiones de almacenamiento, como se explica en Limitar el consumo compartido de recursos compartidos. Otra posibilidad es que, si no comparte almacenes de datos, dedique adecuadamente el almacenamiento a los perfiles de almacenamiento que ponga a disposición de cada organización, con el posible riesgo de desperdiciar almacenamiento asignándolo a organizaciones que no lo necesitan.

Los objetos del almacén de datos de vSphere son los volúmenes lógicos donde se almacenan los VMDK. Aunque los administradores de vSphere pueden ver los sistemas de almacenamiento físico desde donde se crean estos almacenes de datos, para esto se necesitan derechos que no están disponibles para el administrador o el tenant de vCloud Director. Los usuarios del tenant que crean y cargan varias vApp simplemente almacenan los VMDK de las vApp en uno de los perfiles de almacenamiento que hay disponibles en el VDC de organización que están utilizando.

Seguridad de vCloud Director

VMware, Inc. 42

Por este motivo, las máquinas virtuales nunca ven ningún almacenamiento aparte del consumido por sus VMDK a menos que tengan conectividad de red con esos sistemas de almacenamiento. En esta guía se recomienda que no la tengan: un proveedor podría proporcionar acceso al almacenamiento externo para vApp como un servicio de red, pero debe estar separado de los LUN que se asignan a los hosts de vSphere que respaldan la nube.

De forma similar, las organizaciones de tenants solo ven los perfiles de almacenamiento que hay disponibles en los VDC de organización, e incluso esa vista está limitada a la abstracción de vCloud Director. No pueden examinar los almacenes de datos del sistema. Solo ven lo que se ha publicado en catálogos o lo que han utilizado las vApp que administran. Si los perfiles de almacenamiento de VDC de la organización no comparten los almacenes de datos, las organizaciones no pueden influir negativamente en el almacenamiento de las demás (excepto, tal vez, si usan demasiado ancho de banda para la E/S de almacenamiento). Aunque lo hicieran, las anteriores restricciones y abstracciones garantizan el aislamiento adecuado entre las organizaciones. Los administradores de vCloud Director pueden habilitar Storage I/O Control de vSphere en determinados almacenes de datos para restringir la capacidad de un tenant de consumir una cantidad excesiva de ancho de banda de E/S de almacenamiento. Consulte Configurar el soporte de Storage I/O Control en un VDC de proveedor en la Guía del administrador de vCloud Director.

Administración de cuentas de usuarioLa administración de los usuarios y sus credenciales es importante para la seguridad de cualquier sistema. Debido a que todas las autenticaciones hacia el sistema de vCloud Director y dentro de él se realizan mediante nombre de usuario y contraseña, es fundamental seguir las prácticas recomendadas para administrar usuarios y sus contraseñas.

El objetivo de este tema es definir las capacidades y las limitaciones de la administración de usuarios y contraseñas en vCloud Director, y ofrecer recomendaciones para administrarlas y utilizarlas de forma segura dadas estas limitaciones.

Limitaciones de las cuentas de usuario localesvCloud Director proporciona un proveedor de identidades autocontenidas para las cuentas de usuario, que se crean y mantienen en la base de datos de vCloud Director. Aunque estas cuentas no suelen ser vulnerables en un sistema configurado con acceso de red limitado a la base de datos (consulte Configuración de la red de administración), estas cuentas no proporcionan los tipos de funciones de administración de contraseñas solicitados por determinados sectores, como por ejemplo, el estándar de seguridad de datos PCI. Para impedir ataques por fuerza bruta, las cuentas locales deben someterse a límites de reintentos y reglas de bloqueo de cuenta.

Los proveedores de servicios deben sopesar detenidamente las ventajas y los riesgos de seguir usando cuentas locales para los administradores del sistema, y deben controlar de cerca qué direcciones IP de origen pueden autenticarse en la URL de nube de una organización si hay configuradas cuentas locales de administrador del sistema. Se recomienda eliminar, o al menos limitar, el uso de este proveedor de identidad de las cuentas de administrador del sistema.

Seguridad de vCloud Director

VMware, Inc. 43

Una nueva instalación de vCloud Director crea una cuenta de administrador del sistema local. En la configuración predeterminada, vCloud Director requiere que al menos una cuenta de administrador del sistema siga siendo local. Un proveedor de servicios que ha permitido a la organización del sistema que utilice el servicio SSO de vSphere (un IDP de SAML) o LDAP, puede configurar vCloud Director para que no funcione con ninguna cuenta de administrador del sistema local siguiendo estos pasos:

1 Cree una o varias cuentas para los administradores del sistema en el servicio SSO de vSphere (un IDP de SAML) o LDAP.

2 Importe estas cuentas en la organización del sistema.

3 Ejecute el comando manage-config de la herramienta de administración de celdas para volver a configurar el sistema de modo que no se requiera ninguna cuenta local de administrador del sistema y ningún administrador del sistema pueda autenticarse en el sistema.

./cell-management-tool manage-config -n local.sysadmin.disabled -v true

Tenga en cuenta que esto no deshabilita las cuentas locales para otras organizaciones.

Nota En un sistema que no tiene cuentas locales de administrador del sistema, los comandos de la herramienta de administración de celdas que le piden que especifique las credenciales de administrador del sistema deben usar la opción -i --pid en su lugar, proporcionando los ID de proceso de la celda en pid. Consulte la Referencia de la herramienta de administración de celdas en Guía del administrador de vCloud Director.

4 Puede deshacer este cambio con una línea de comandos similar de la herramienta de administración de celdas, que rehabilita el acceso a los administradores de sistema que tienen cuentas locales.

./cell-management-tool manage-config -n local.sysadmin.disabled -v false

Administración de contraseñasLa mayoría de los proveedores de identidades (IDP) de LDAP, OAUTH y SAML proporcionan capacidades o se integran con sistemas para controlar aquellas situaciones en las que los usuarios han olvidado su contraseña. Estos IDP no se incluirán en el ámbito de este documento. La herramienta de administración de celdas de vCloud Director incluye un comando recover-password que sirve para recuperar una contraseña perdida del administrador del sistema. En vCloud Director no hay ninguna capacidad nativa para controlar esta situación para otros usuarios locales. Se recomienda que todas las contraseñas de cuentas locales se guarden de manera segura y conforme a lo establecido por el departamento de seguridad de TI. Algunas organizaciones bloquean las contraseñas en un depósito. Otras utilizan programas de almacenamiento de contraseñas de pago o gratuitos. En este documento no se recomienda ningún método en particular.

Seguridad de vCloud Director

VMware, Inc. 44

Seguridad de contraseñasLa seguridad de las contraseñas de los usuarios de los IDP depende de los controles proporcionados por ese IDP o de las herramientas utilizadas para administrar usuarios dentro del directorio. Por ejemplo, si vCloud Director se conecta a Active Directory, este aplica los controles típicos de longitud, complejidad e historial de la contraseña de Active Directory asociados a Microsoft Active Directory. Otros IDP tienden a admitir capacidades similares. Los detalles de los controles de seguridad de las contraseñas son específicos del directorio y no se tratan en detalle en este documento.

vCloud Director requiere que los usuarios locales tengan contraseñas con una longitud mínima de seis caracteres. Este requisito no se puede configurar y no hay disponibles otros controles de historial o complejidad de contraseña. Se recomienda que los usuarios, especialmente los administradores del sistema y de la organización, tengan especial cuidado al elegir sus contraseñas para protegerse frente a ataques por fuerza bruta (consulte el apartado de problemas de bloqueo de cuentas más adelante).

Protección de contraseñas de usuariosLas credenciales de usuarios administradas por un IDP nunca se almacenan en la base de datos de vCloud Director, sino que se transmiten mediante el método elegido por el IDP. Consulte Configurar proveedores de identidad para obtener más información sobre cómo proteger este canal de información.

Para las contraseñas de los usuarios locales se usa sal y hash antes de almacenarlas en la base de datos de vCloud Director. Una contraseña con texto sin formato no se puede recuperar de la base de datos. Los usuarios locales se autentican aplicando hash a la contraseña presentada y comparándola con el contenido de su campo de contraseña en la base de datos.

Otras contraseñasAdemás de las credenciales para los usuarios locales, la base de datos de vCloud Director almacena contraseñas para los servidores de vCenter y los administradores de NSX conectados. Los cambios realizados en estas contraseñas no se actualizan automáticamente en el sistema. Deberá cambiarlas manualmente mediante el script de configuración de vCloud Director (para la contraseña de base de datos de vCloud Director) o la interfaz de usuario web para vCenter y NSX.

vCloud Director también mantiene contraseñas para acceder a las claves privadas asociadas con sus certificados TLS/SSL, así como las contraseñas para base de datos de vCloud Director, los servidores de vCenter y los servidores de administrador de NSX, como se mencionó anteriormente. Estas contraseñas se cifran mediante una clave única por instalación de vCloud Director y se almacenan en el archivo $VCLOUD_HOME/etc/global.properties. Como se mencionó en Protección de los archivos confidenciales tras la instalación, proteja adecuadamente cualquier copia de seguridad que contenga ese archivo.

Control de acceso basado en funcionesvCloud Director implementa un modelo de autorización basado en funciones. En esta sección se analizan los diferentes orígenes de identidad, los tipos de usuario, los controles de autenticación, las funciones y los derechos que se encuentran en vCloud Director. Es necesario comprender toda esta

Seguridad de vCloud Director

VMware, Inc. 45

información para poder proteger correctamente el sistema y proporcionar el acceso correcto a las personas adecuadas.

Una organización de tenants de vCloud Director puede contener un número arbitrario de usuarios y grupos. El administrador de la organización puede crear los usuarios localmente o bien se pueden importar desde un servicio de directorio externo (LDAP) o un proveedor de identidades (OAUTH, SAML). Los usuarios importados pueden ser miembros de uno o varios grupos. A un usuario que forma parte de varios grupos se le asignan todas las funciones que se asignan a esos grupos. Cada organización se crea con un conjunto predeterminado de derechos y un conjunto de funciones predefinidas que incluyen combinaciones de esos derechos. Un administrador del sistema puede conceder otros derechos a una organización, y los administradores de la organización pueden utilizar esos derechos para crear funciones personalizadas que tengan un carácter local dentro de la organización. Los permisos dentro de una organización se controlan mediante la asignación de derechos y funciones a usuarios y grupos.

No se permite que usuarios sin autenticar accedan a cualquier funcionalidad de vCloud Director a través de la consola web, la API de vCloud, el portal para tenants ni la API de vCloud. Cada usuario se autentica con un nombre de usuario y una contraseña. Es posible configurar políticas de reintentos y bloqueo de cuentas a nivel global o de organización.

Las funciones son agrupaciones de derechos que proporcionan funcionalidades al usuario que esté asignado a esa función. Entre las funciones predefinidas se incluyen:

n Administrador del sistema

n Administrador de organización

n Autor de catálogo

n Autor de vApp

n Usuario de vApp

n Solo acceso a la consola

En la Guía del administrador de vCloud Director también se identifican qué derechos se asignan a cada una de estas funciones. El propósito de esa sección es ayudarle a elegir la función adecuada para cada tipo de usuario. Por ejemplo, la función del usuario de vApp puede ser apropiada para un administrador que necesite encender y apagar las máquinas virtuales, pero si también necesita modificar la cantidad de memoria asignada a una máquina virtual, la función Autor de vApp sería más adecuada. Es posible que estas funciones no tengan los conjuntos exactos de derechos relevantes para sus organizaciones de tenants, por lo que los administradores de cada organización pueden crear funciones personalizadas. En este documento no se incluye la descripción de qué derechos específicos se pueden combinar para crear una función personalizada que resulte útil.

Configurar proveedores de identidadUna organización de tenant de vCloud Director puede definir un proveedor de identidad que se comparte con otras aplicaciones o empresas. Los usuarios se autentican en el proveedor de identidad para obtener un token que se puede utilizar para iniciar sesión en la organización. Esta estrategia permite que las empresas proporcionen acceso a varios servicios no relacionados, incluido vCloud Director, con un solo conjunto de credenciales, lo que se conoce como inicio de sesión único.

Seguridad de vCloud Director

VMware, Inc. 46

Acerca de los proveedores de identidadvCloud Director admite los siguientes tipos de proveedores de identidad:

OAuth Una organización puede definir un proveedor de identidad externo que admita la autenticación de OAuth, según se define en RFC 6749 (http://tools.ietf.org/html/rfc6749).

SAML Una organización puede definir un proveedor de identidad externo que admita el lenguaje de marcado de aserción de seguridad (SAML) 2.0 estándar.

Integrado El proveedor de identidad integrado es un servicio de vCloud Director que autentica a los usuarios que se crearon de forma local o se importaron desde LDAP.

OAuthEn cualquier implementación de OAuth, la mayoría de las decisiones de seguridad se producen en la capa del servidor de autorización de OAuth. vCloud Director se encuentra en la función de un servidor de recursos, que es un consumidor del token y solamente es responsable de comprobar la integridad del token.

Para proteger las sesiones de vCloud Director y los activos confidenciales subyacentes, el servidor de autorización de OAuth debe estar configurado de manera segura y tener instaladas las revisiones de seguridad más recientes.

Si el servidor de autorización de OAuth puede establecerse para redirigir a los usuarios a una dirección URL arbitraria especificada por un parámetro de consulta, el servidor de autorización de OAuth debe configurarse para validar las direcciones URL con el fin de evitar que un atacante controle las redirecciones a aplicaciones de terceros. Debe utilizarse una lista blanca de aplicaciones legítimas para la validación cuando esté disponible.

LDAPEl proveedor de identidades integrado de vCloud Director es compatible con varios servicios LDAP conocidos.

Consulte las Notas de la versión de vCloud Director para obtener una lista de los servicios LDAP compatibles.

vCloud Director permite que el administrador del sistema pueda definir un servicio LDAP de todo el sistema que puedan utilizar todos los tenants. Las cuentas de usuario de tenants se importan en la base de datos de vCloud Director, donde se les asignan funciones de vCloud Director. Las contraseñas de los usuarios LDAP se administran y se mantienen en el directorio LDAP, y la autenticación se lleva a cabo en ese directorio con la configuración que se especifica en la pantalla de configuración de LDAP. Se mantienen todos los controles del directorio LDAP que guardan alguna relación con la autenticación y las

Seguridad de vCloud Director

VMware, Inc. 47

contraseñas, incluidos los bloqueos por errores de autenticación, la caducidad de contraseñas, el historial, la complejidad, etc., y que son específicos del servicio LDAP elegido. Si una organización se configura para que utilice el LDAP del sistema, sus usuarios provendrán de la OU que se especifique en la configuración del servicio LDAP del sistema de vCloud Director de esa organización.

Los proveedores de nube pueden elegir entre permitir que organizaciones de tenants utilicen una OU dentro del LDAP del sistema o que hospeden su propio servicio de directorios LDAP. En cualquier caso, se debe proporcionar el acceso de administración adecuado a ese directorio para que el administrador de la organización pueda administrar los usuarios. La falta de ese control podría suponer una carga adicional al administrador del sistema y podría impedir que la organización controlara de forma fácil y adecuada el acceso a sus VDC. Ante la ausencia de tales controles de administración, una organización solo debe utilizar un directorio LDAP privado que la misma organización pueda hospedar y administrar.

La conectividad de las celdas de vCloud Director con el servidor LDAP del sistema y los servidores LDAP de cualquier organización debe estar habilitada para que el software pueda autenticar correctamente a los usuarios. Tal y como se recomienda en este documento, el servidor LDAP del sistema debe estar situado en la red de administración privada, separado de la DMZ mediante un firewall. Algunos proveedores de nube y la mayoría de las organizaciones de TI ejecutarán los servidores LDAP de las organizaciones que sean necesarios, los cuales estarían también en una red privada, no en la DMZ. Otra opción para un servidor LDAP de la organización consiste en hospedarlo y administrarlo fuera del entorno del proveedor de nube y que el control lo tenga la organización. En ese caso, debe estar expuesto a las celdas de vCloud Director, posiblemente a través de la propia DMZ del centro de datos de la empresa.

En todas estas circunstancias, es necesario abrir los puertos adecuados a través de los diversos firewalls de la ruta de acceso entre las celdas y el servidor LDAP, como se describe en LDAP a través de TLS/SSL. Además, una de las preocupaciones que surgen cuando la organización hospeda su propio servidor LDAP es la cuestión de tener que dejarlo expuesto a través de su DMZ. No se trata de un servicio al que puede acceder el público general, por lo que hay que realizar ciertos pasos para limitar el acceso solo a las celdas de vCloud Director. Un método sencillo de hacerlo es configurar el servidor LDAP o el firewall externo para permitir únicamente el acceso de las direcciones IP que pertenecen a las celdas de vCloud Director que notifique el proveedor de nube. Entre otras opciones se incluyen sistemas como las VPN de sitio a sitio por organización que conectan esos dos conjuntos de sistemas, directorios virtuales o servidores proxy LDAP fortalecidos. Ninguna de estas opciones se discuten en este documento puesto que no pertenecen a este ámbito.

Por el contrario, los proveedores de nube deben tener en cuenta que se podrían usar servidores LDAP hospedados por organizaciones que administren clientes sin escrúpulos y que formen parte de un ataque a otras organizaciones. Por ejemplo, alguien podría inventar una organización que solicite un nombre de organización muy similar al nombre de otra organización (excepto por una incorrección ortográfica común) y que use una dirección URL de acceso muy parecida en un ataque de phishing. El proveedor puede tomar medidas para protegerse frente a este ataque y a otros similares. Para ello puede limitar las direcciones IP de origen de las solicitudes cuando sea posible para evitar los intentos de inicio de sesión entre organizaciones, así como garantizar que los nombres de organización que asigne nunca serán muy parecidos al nombre de otra.

Seguridad de vCloud Director

VMware, Inc. 48

LDAP a través de TLS/SSL

Se recomienda que configure un directorio LDAPv3 para la autenticación de usuarios. vCloud Director se debe configurar para conectarse a los servidores LDAP a través de SSL con el fin de proteger adecuadamente las contraseñas que se comprueban en dichos servidores. Consulte "Configuración de una conexión LDAP" en la Guía del administrador de vCloud Director para obtener más información. La configuración de LDAP más segura especifica Utilizar SSL y requiere un certificado SSL que proporcione el servicio LDAP.

Si el certificado firmado del servidor LDAP no está disponible, el certificado de la entidad de certificación que firma el certificado del servidor LDAP se debe importar en el almacén de claves JCE (JCEKS) del sistema o la organización. Las configuraciones de LDAP que especifican un almacén de claves JCEKS son también seguras, pero se pueden generar errores de configuración cuando se confía en muchos de los certificados de CA (o incluso muchos de los certificados específicos del servidor). Además, es preferible elegir un proveedor LDAP que admita la autenticación de Kerberos.

Se debe poder conectar con el servidor LDAP. Mientras que el LDAP sin formato (sin SSL) se ejecuta a través del puerto 389/TCP, los servidores que admiten LDAP a través de SSL usan el puerto 636/TCP de forma predeterminada. Este puerto también se puede configurar, sin embargo. Tenga en cuenta que vCloud Director es compatible con el LDAP heredado a través de SSL (LDAPS) y no es compatible con la negociación de TLS dentro de una conexión LDAP que utiliza el comando StartTLS.

Por último, el servidor de directorio habilitado con LDAP debe estar correctamente configurado con un certificado SSL. El método que hay que seguir para lograrlo no se incluye en este documento.

Importación de grupos

La finalidad de importar los grupos en vCloud Director es evitar tener que importar manualmente uno a uno los usuarios que tengan la misma función. Cuando los usuarios LDAP inician sesión, en esa sesión se asignan las funciones que están asignadas a los grupos a los que pertenecen. Como las pertenencias a los grupos de los usuarios cambian en función de los controles que se producen en sus organizaciones, las funciones que se asignan a esos usuarios también cambian automáticamente para adecuarse a la asignación de funciones para el grupo. De este modo, las organizaciones pueden integrar fácilmente las funciones de nube con las funciones o los grupos internos de la organización y los sistemas que aprovisionan y administran a estas organizaciones.

Por ejemplo, una organización puede decidir conceder inicialmente la función de "Solo acceso a la consola" a los usuarios LDAP para limitar los derechos de los usuarios. Para ello, todos los usuarios que necesitan esta función básica se agregan a un único grupo LDAP y, cuando ese grupo se importa, el administrador de la organización le asigna la función de Solo acceso a la consola. A continuación, esos usuarios con otros controles de trabajo se podrían agregar a otros grupos LDAP, también importados a vCloud Director y se les podría asignar estas funciones con más privilegios. Por ejemplo, los usuarios que necesitan crear catálogos se podrían agregar al grupo "Autor de catálogo de la organización A" en el servidor LDAP de la organización. Después, el administrador de la organización A importaría el grupo "Autor de catálogo de la organización A" y le asignaría la función de Autor de catálogo predefinida en vCloud Director. Todo esto se consigue siguiendo las instrucciones relacionadas con la importación de un grupo en la Guía del usuario de vCloud Director.

Seguridad de vCloud Director

VMware, Inc. 49

Lista de comprobación 7Esta lista de comprobación resume las tareas de configuración de seguridad de claves que se describen en este documento.

n Además de las instrucciones de este documento, debería supervisar los avisos de seguridad de http://www.vmware.com/security/advisories/ y suscribirse a las alertas de correo electrónico utilizando el formulario de esa página. Los avisos de última hora y las instrucciones adicionales de seguridad relacionadas con vCloud Director se publicarán en ese mismo sitio.

n Los administradores deben aplicar los pasos recomendados en Seguridad de vSphere (https://docs.vmware.com/es/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-52188148-C579-4F6A-8335-CFBCE0DD2167.html), Protección de VMware NSX para vSphere (https://communities.vmware.com/docs/DOC-27674) y la Guía de configuración de seguridad para NSX-v 6.3.x (https://communities.vmware.com/docs/DOC-28142) para asegurarse de que disponen de instalaciones seguras de dichos productos.

n Aplique las revisiones de seguridad actualizadas a la plataforma Linux de las celdas, la base de datos de vCloud Director y la infraestructura virtual antes de la instalación; también es crucial supervisar constantemente que el nivel de revisión de los componentes esté actualizado.

n Los procedimientos estándar de refuerzo de la seguridad deben aplicarse a la plataforma Linux de las celdas, incluidas la desactivación de los servicios de red innecesarios, la eliminación de los paquetes innecesarios, la restricción del acceso raíz remoto y la aplicación de directivas de contraseña segura. Si es posible, utilice un servicio de autenticación centralizado como Kerberos. Considere la instalación de herramientas de supervisión y detección de intrusiones.

n Es posible instalar aplicaciones adicionales y aprovisionar más usuarios en la plataforma de Linux de las celdas, pero no se recomienda hacerlo. La ampliación del acceso al sistema operativo de las celdas podría significar una reducción de la seguridad.

n Asegúrese que el archivo responses.properties solo esté disponible para aquellos usuarios que lo necesiten. Cuando se esté usando (al agregar celdas a un grupo de servidores), configure controles de acceso adecuados en una ubicación accesible para todos los hosts de destino. Las copias de seguridad que se creen se deberán controlar cuidadosamente, y se deberán cifrar si el software de copia de seguridad lo admite. Una vez que el software esté instalado en los hosts del servidor, se deberán eliminar las copias del archivo responses.properties en estas ubicaciones.

VMware, Inc. 50

n Los archivos responses.properties y global.properties están protegidos mediante los controles de acceso de la carpeta $VCLOUD_HOME/etc y de los propios archivos. No cambie los permisos de los archivos ni la carpeta.

n El acceso físico y lógico a los servidores de vCloud Director debe limitarse exclusivamente a aquellos que necesiten iniciar sesión, y solo con los niveles mínimos de acceso necesarios. Esto implica limitar el uso de la cuenta raíz mediante sudo y otras prácticas recomendadas. Las copias de seguridad de los servidores se deben proteger y cifrar de forma estricta con claves administradas de manera independiente de las propias copias de seguridad.

n Para consultar los requisitos de seguridad de la base de datos, consulte las guías de seguridad del software de base de datos de vCloud Director que haya elegido.

n El usuario de la base de datos de vCloud Director no debe tener privilegios en otras bases de datos de ese servidor, así como tampoco debe tener privilegios de administración del sistema.

n Asegúrese de que las credenciales utilizadas para el acceso administrativo a las celdas, las instancias de vCenter Server conectadas, la base de datos de vCloud Director, los firewalls y otros dispositivos sigan los criterios estándar de complejidad de contraseña.

n Desde la perspectiva de defensa en profundidad, es importante modificar las contraseñas administrativas de los distintos servidores del entorno de vCloud Director, incluidas las celdas, la base de datos de vCloud Director, las instancias de vCenter Server y NSX.

n Consulte https://docs.vmware.com/es/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-779A011D-B2DD-49BE-B0B9-6D73ECF99864.html para obtener más información sobre la creación y la sustitución de los certificados utilizados por vCenter y ESXi. Esto se recomienda encarecidamente.

n Los certificados de vCenter deben tener un campo de nombre común (CN) que coincida con el nombre de dominio completo (FQDN) del servidor en el que esté instalado vCenter.

n Configure vCloud Director para comprobar los certificados de vCenter.

n Los certificados de vCenter deben estar firmados por una CA y tener un CN que coincida con el FQDN del host donde esté instalada la celda.

n El enfoque recomendado para que los servicios de vCloud Director estén disponibles en el exterior consiste en colocar las celdas en una DMZ con un firewall de red que separe Internet de las celdas de vCloud Director de la DMZ. El único puerto que se debe permitir a través del firewall orientado a Internet es 443/TCP.

n Debido a que las celdas de vCloud Director están en la DMZ, el acceso a los servicios que necesitan debería realizarse mediante un firewall de red. En concreto, se recomienda que el acceso a la base de datos de vCloud Director, vCenter Server, los hosts vSphere, los IDP (como LDAP) y los servicios de copia de seguridad o similares estén en el lado contrario del firewall que separa la DMZ de la red interna.

Seguridad de vCloud Director

VMware, Inc. 51

n Las máquinas virtuales que requieren acceso desde fuera de la nube (por ejemplo, desde Internet) deberán conectarse a una red pública o una red privada con enrutamiento NAT y enrutamiento de puerto configurado para los servicios expuestos. La red externa a la que se conectan estas redes VDC de la organización requeriría un firewall que la protegiera y que permitiera la entrada del tráfico acordado a esta red de la DMZ.

n Por lo general, se recomienda colocar las vApps que necesiten accesibilidad desde Internet en una red privada y enrutada. Esto proporciona control de tenant sobre las reglas de firewall y enrutamiento de puerto proporcionadas por NSX. Es posible que el firewall de red elegido para la implementación aplique estas y otras reglas de forma predeterminada. Consulte la documentación del firewall para obtener instrucciones de configuración específicas y saber cuáles son las capacidades predeterminadas.

n Una doctrina de defensa en profundidad requiere que se bloqueen JMX (puerto 8999/TCP) y JMS (puertos 61611/TCP y 61616/TCP) en el firewall de red que protege la DMZ a la que se conectan las celdas.

n Para establecer la URL web pública, la dirección del proxy de la consola pública y la URL base de la API de REST pública para una nube de varias celdas que se encuentra detrás de un WAF o un equilibrador de carga.

n Debe implementarse un firewall de aplicación web (WAF) frente a las celdas de vCloud Director.

n En este tipo de implementaciones, se recomienda que el WAF esté configurado de modo que permita la inspección y el bloqueo del tráfico malintencionado. Esto se suele hacer con la terminación de TLS o SSL.

n Al configurar la terminación de TLS o SSL, además de instalar un certificado firmado por la CA en el firewall de aplicación web (WAF) para que las aplicaciones cliente de vCloud API y la consola web puedan estar seguras de la identidad del servidor, también es importante utilizar un certificado firmado por la CA en las celdas aunque solo las tenga en cuenta el WAF.

n Por último, si el equilibrador de carga es independiente del WAF, también se debe utilizar un certificado firmado por la CA.

n Se recomienda habilitar la generación del encabezado X-Forwarded-For en el firewall si es posible.

n Si el servidor de vCloud Director tiene asignada una tercera IP de forma exclusiva para la administración, vincule JMX directamente a esta dirección IP. De forma predeterminada, el conector JMX de vCloud Director se vincula a las direcciones IP principales especificadas durante la configuración. Este comportamiento predeterminado se puede anular insertando la siguiente propiedad en /opt/vmware/vcloud-service-director/etc/global.properties: vcloud.cell.ip.management=IP o nombre de host de la red de administración a la que se debe

vincular el conector JMX.

n La configuración recomendada y más segura consiste en vincular el conector JMX a la dirección de host local: vcloud.cell.ip.management=127.0.0.1. Si JMX solo está expuesto al host local, se

Seguridad de vCloud Director

VMware, Inc. 52

deberá usar SSH como mecanismo de túnel para el acceso a JMX con el fin de proteger las comunicaciones con este. Si los requisitos de administración no admiten este tipo de configuración del host local, y JMX debe estar expuesto fuera del servidor de vCloud Director, use TLS o SSL para protegerlo.

n Detrás de las celdas se encuentran los elementos de administración privada necesarios para vCloud Director: su base de datos, NSX, vCenter Server, el servidor LDAP del sistema (si existe), el servidor de Active Directory usado por vCenter y las interfaces de administración de los hosts de vSphere. A sus conexiones las controlan exclusivamente los firewalls, ya que a esos servicios no se puede acceder desde otras máquinas que estén en la DMZ ni directamente desde Internet.

n También se presupone que las tecnologías de seguridad de centro de datos habituales, como IDS/IPS, SIEM, administración de configuración, administración de revisiones, administración de vulnerabilidades, antivirus y sistemas de administración de GRC, se aplicarán a vCloud Director y sus sistemas asociados, vSphere y sus sistemas asociados y a las redes y la infraestructura de almacenamiento que les dan soporte.

n La administración adecuada de las concesiones, las cuotas, los límites y los modelos de asignación garantiza que una organización de tenants no pueda denegar el servicio a otra por accidente o de forma intencionada.

n En este y otros escenarios, los grupos de recursos, las redes y los almacenes de datos deben separarse en distintos dominios de seguridad mediante el uso de VDC de proveedor diferentes en los que se puedan agrupar (o aislar) las vApp con problemas similares.

n Cada vez que se permite la sobreasignación de recursos en un grupo utilizado por más de una organización de tenants, se corre el riesgo de empeorar la calidad del servicio para otros tenants. La correcta supervisión de los niveles de servicio es fundamental para evitar denegaciones de servicio causadas por un tenant "ocupado", pero la seguridad no requiere que se separen los tenants en grupos de recursos individuales para alcanzar este objetivo.

n En ocasiones, una red externa puede utilizarse en una red de VDC de organización para conectar dos vApp distintas y sus redes, o para conectar una red de vApp con el centro de datos empresariales. En estos casos, la red externa no se debe compartir entre las organizaciones de tenants.

n Para las comunicaciones que pasan por una red externa y que requieren protección de confidencialidad (por ejemplo, una conexión de centro de datos de vApp a la empresa o un puente de vApp a vApp), se recomienda implementar una instancia de NSX Edge u otro dispositivo virtual de VPN en la red de VDC de organización.

n Si los grupos de redes se deben compartir entre los tenants, lo más seguro es compartir un grupo respaldado por VXLAN, que admite muchas más redes que un grupo respaldado por VLAN y aplica el aislamiento a nivel de kernel de ESXi.

n Si se comparten almacenes de datos entre los perfiles de almacenamiento, se debe establecer un límite de almacenamiento, habilitar el aprovisionamiento ligero si es posible y supervisar el uso del almacenamiento con cuidado. También se deben administrar cuidadosamente las concesiones de almacenamiento de vApp.

Seguridad de vCloud Director

VMware, Inc. 53

n Las máquinas virtuales nunca tienen acceso al almacenamiento fuera de sus VMDK, a menos que tengan conectividad de red con dichos sistemas de almacenamiento. En esta guía se recomienda que no lo tengan; un proveedor puede proporcionar acceso al almacenamiento externo a las vApp como un servicio de red, pero este debe ser independiente de los LUN asignados a los hosts de vSphere que respaldan la nube.

n Según se define en Seguridad de vSphere (https://docs.vmware.com/es/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-52188148-C579-4F6A-8335-CFBCE0DD2167.html), es importante que la red de administración sea independiente de las redes de datos de las máquinas virtuales.

n Del mismo modo, la red de administración debe ser independiente de la DMZ que proporciona acceso a los administradores de la organización.

n Las redes de almacenamiento también deben estar separadas físicamente. Estas son las prácticas recomendadas de vSphere que protegen el almacenamiento de los tenants de la organización y del proveedor frente a máquinas virtuales malintencionadas.

n vMotion no siempre se coloca en una red independiente de la red de administración; sin embargo, en la nube, es importante desde una perspectiva de separación de tareas. Los procesos de vMotion se suelen realizar sin cifrado, y si se coloca en la red de administración, permitirá que un administrador de proveedores u otro usuario con acceso a dicha red pueda "fisgonear" el tráfico de vMotion, lo que infringiría la privacidad del tenant. Por esta razón, se debe crear una red física independiente para vMotion en las cargas de trabajo de nube.

n Otra práctica recomendada consiste en examinar periódicamente los registros en busca de actividades sospechosas, inusuales o no autorizadas. El análisis rutinario de los registros también permite identificar errores y fallos de configuración del sistema y ayuda a garantizar el cumplimiento de los SLA.

n Se puede configurar un servidor syslog durante la instalación. Se recomienda utilizar una infraestructura de syslog que admita TLS. Se recomienda exportar los registros a un servidor syslog por varias razones. Se recomienda que el servidor syslog se configure con redundancia, para asegurar que los eventos esenciales se registren siempre. Las organizaciones de operaciones de seguridad y operaciones de TI también pueden beneficiarse de la agregación y la administración centralizadas de los registros de diagnóstico. Le recomendamos que utilice logrotate u otros métodos similares para controlar el tamaño de los registros y el número de archivos de registro antiguos que se conservan.

n Asegúrese de que haya suficiente espacio en disco para dar cabida a los registros de diagnóstico y los registros de las solicitudes Jetty. El registro centralizado garantiza que no se pierda información de diagnóstico valiosa al llegar al total de 400 MB del archivo de registro, además los archivos se alternan o se eliminan.

n Otros sistemas conectados a vCloud Director y que este utiliza crean registros de auditoría que deben consolidarse en los procesos de auditoría. Estos incluyen registros de NSX, la base de datos de vCloud Director, vCenter Server y los hosts de vSphere.

Seguridad de vCloud Director

VMware, Inc. 54

n Después de crear la cuenta de administrador del sistema local inicial, se recomienda enfáticamente que todas las cuentas de administrador del sistema se administren mediante un proveedor de identidad, como LDAP o el servicio SSO de vSphere.

n Algunos proveedores de nube pueden optar por permitir que las organizaciones utilicen una OU del sistema LDAP o que hospeden el directorio LDAP de la organización. En cualquier caso, se debe proporcionar el acceso de administración adecuado a ese directorio para que el administrador de la organización pueda administrar los usuarios. En ausencia de tales controles de administración, la organización de tenants solo debería usar un directorio LDAP privado alojado y administrado por ella misma.

n Otra preocupación que surge cuando la organización aloja su propio servidor LDAP es la exposición fuera de la DMZ. No se trata de un servicio al que puede acceder el público general, por lo que hay que realizar ciertos pasos para limitar el acceso solo a las celdas de vCloud Director. La forma más sencilla de hacerlo es configurar el servidor LDAP o el firewall externo para permitir el acceso solo desde las direcciones IP que pertenezcan a las celdas de vCloud Director.

n El proveedor puede tomar medidas para proteger frente a este ataque entre tenants y otros similares. Para ello puede limitar las direcciones IP de origen de las solicitudes cuando sea posible así como garantizar que los nombres de organización que asigne a los tenants nunca serán muy parecidos al nombre de otra.

n vCloud Director se debe configurar para conectarse a los servidores LDAP a través de SSL con el fin de proteger adecuadamente las contraseñas que se comprueban en dichos servidores. Al configurar LDAP a través de SSL, no acepte todos los certificados.

n Es importante comprender y aplicar las prácticas recomendadas para administrar los usuarios y sus contraseñas.

n Se deben utilizar la administración de registros, la administración de información y eventos de seguridad (SIEM) u otros sistemas de supervisión para inspeccionar los intentos de descifrado de contraseñas mediante ataques de fuerza bruta.

n Se recomienda almacenar de forma segura las contraseñas de los administradores del sistema y la organización según las directivas aprobadas por su departamento de seguridad de TI.

Seguridad de vCloud Director

VMware, Inc. 55