Seguridad de vCloudDirectorvCloud Director 9.5vCloud Director 9.1

Seguridad de vCloud Director

VMware, Inc. 2

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

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

El sitio web de VMware también ofrece las actualizaciones de producto más recientes.

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

docfeedback@vmware.com

Copyright © 2010–2018 VMware, Inc. Todos los derechos reservados. Información sobre el copyright y marcacomercial.

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

Contenido

1 Introducción 4

2 Amenazas 6

3 Arquitectura y funciones de seguridad de vCloud Director 8

Aislamiento y seguridad de máquinas virtuales 9

Seguridad y abstracción de vCloud Director 9

Seguridad y la capa de redes virtuales 11

4 Seguridad de la infraestructura 14

Seguridad de la base de datos 16

5 Seguridad del sistema 17

Requisitos de seguridad de red 17

Certificados 19

Firewalls 22

Equilibradores de carga y terminación SSL 23

Protección de AMQP (RabbitMQ) 24

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

Proteger el acceso a JMX 25

Configuración de la red de administración 27

Auditoría y registro 28

6 Seguridad de tenants 32

Seguridad de la red en organizaciones de tenants 32

Aislamiento y asignación de recursos 34

Administración de cuentas de usuario 42

7 Lista de comprobación 49

VMware, Inc. 3

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

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

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

En general, las amenazas a vCloud Director se dividen en dos grupos independientes: amenazasinternas y amenazas externas. En las amenazas internas están involucrados generalmente problemas devarios tenants, y las amenazas externas tienen como objetivo la seguridad del entorno de nubehospedado, pero el límite entre unas y otras no es estricto y puede variar. Puede haber amenazasinternas 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 seindican en http://www.vmware.com/security/advisories.html y suscribirse a las alertas de correoelectrónico mediante el formulario que aparece en esa página. Los avisos de última hora y lasinstrucciones adicionales de seguridad relacionadas con vCloud Director se publicarán en ese mismositio.

VMware, Inc. 4

Ámbito de recomendacionesLas recomendaciones que se proporcionan en esta guía se limitan a la administración de problemas deseguridad específicos de vCloud Director. Al igual que una aplicación web que se hospeda en unaplataforma Linux, vCloud Director está sujeto a las vulnerabilidades de seguridad que se presentan enesas 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 procesode 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 otrosmuchos 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 amenazasinternas que se originan dentro del sistema y sus tenants, o amenazas externas que se originan fuera delsistema. Esta última categoría incluye las amenazas a la infraestructura creada para alojar un grupo deservidores 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 recursosinformáticos, de red y de almacenamiento de VMware vSphere ® . Los usuarios de los tenants puedeniniciar sesión en vCloud Director y, por lo general, se les otorgan derechos para implementar y usar lasmáquinas virtuales, el almacenamiento, ejecutar aplicaciones y (hasta cierto límite) compartir recursoscon otros usuarios.

Una de las principales funciones de vCloud Director es que los usuarios no administrativos no tienenvisibilidad o acceso directo a la mayoría de los recursos de nivel de sistema, incluida la información delhost físico, como las direcciones IP, las direcciones MAC, el tipo de CPU, el acceso de ESXi, lasubicaciones de almacenamiento físico, etc. Sin embargo, los usuarios sí que pueden intentar acceder ainformació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ítimopara acceder sin autorización a partes del sistema para las que no tienen derecho, como los recursosque pertenecen a otra organización. Concretamente, podrían intentar una escalación de privilegios paraacceder a acciones reservadas a administradores. Es posible que los usuarios también intenten realizaracciones que, de forma intencionada o no, interrumpan la disponibilidad general y el rendimiento delsistema 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 eladministrador del sistema de un sitio de vCloud Director, los administradores de la organización detenants, 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 usuariostienen mayores privilegios que los usuarios normales y, por lo general, disponen de inicio de sesióndirecto en los sistemas internos. No obstante, sus privilegios no son ilimitados. Existe una posibleamenaza de que también intenten realizar una escalación de privilegios o realizar accionesmalintencionadas.

VMware, Inc. 6

Como veremos, la seguridad de vCloud Director frente a estas amenazas se logra mediante laarquitectura, el diseño y la implementación de vCloud Director, vSphere y VMware NSX®, junto con otrossistemas de seguridad, y la infraestructura en la que se implementan estos sistemas. Debido a laflexibilidad y la naturaleza dinámica de estos sistemas, es fundamental seguir las instrucciones deconfiguració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, incluidoInternet, los ataques a vCloud Director a través de sus API e interfaces web (la consola web devCloud Director y el portal para tenants de vCloud Director), así como el servicio de transferencia devApp y la consola remota de máquina virtual. Un usuario remoto que no tenga derechos de acceso alsistema puede intentar acceder como un usuario autorizado. Los usuarios autenticados de estasinterfaces también pueden considerarse como los orígenes de las amenazas externas, ya que puedenintentar aprovechar las vulnerabilidades del sistema que no están disponibles para los usuarios noautenticados.

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

Seguridad de vCloud Director

VMware, Inc. 7

Arquitectura y funciones deseguridad 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 servidordel grupo ejecuta una colección de servicios denominada celda de vCloud Director. Todas las celdascomparten una sola base de datos de vCloud Director, y se conectan a varios sistemas devCenter Server, a los hosts ESXi que administran y a las instancias de NSX Manager que proporcionanservicios 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 se muestra un solo grupo de servidores de vCloud Director (instalación). Esposible que en dicho grupo de servidores haya varios hosts del servidor de vCloud Director, cada unocon una sola celda en ejecución. El grupo de servidores comparte la base de datos de vCloud Director yun recurso compartido de archivo NFS (no se muestra). La abstracción de nube se ha diseñado con elsoftware vCloud Director y aprovechando las capacidades de vCenter y NSX; en el diagrama se muestracomo la conexión con el grupo de servidores. Las organizaciones de vCloud Director y sus usuarios no

VMware, Inc. 8

interactúan directamente con vCenter ni NSX para crear y administrar sus cargas de trabajo. Paracualquier usuario que no sea administrador del sistema, las interacciones con vCenter y NSX sepresentan como operaciones de vCloud Director en objetos de vCloud Director. El permiso para accedera los objetos de vCloud Director y utilizarlos está basado en funciones. Las funciones predefinidasproporcionan acceso de valor de referencia a las tareas comunes. Los administradores de organizacióntambién pueden crear funciones personalizadas para sacar el máximo partido a una matriz de derechosdetallados.

Las siguientes subsecciones describen la seguridad en la capa de computación virtual, la abstracción denube 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 elriesgo de que los controles de aislamiento de tráfico y segregación de red sean insuficientes y elegir lasacciones correctivas recomendadas.

Al observar la segmentación de redes, tenemos la noción de una zona de confianza. Las zonas deconfianza son un control de seguridad proactivo que permiten controlar el acceso al tráfico de red. Enlíneas generales, una zona de confianza se define como un segmento de red dentro del cual los datosfluyen 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 lanube de amenazas internas, proviene del diseño de seguridad y la configuración específica de la capa devirtualización subyacente. Esto incluye el diseño y la configuración de vSphere, la seguridad adicional deredes definidas por software de vCloud Director, el aprovechamiento de la tecnología de NSX y laseguridad de los propios hosts de ESXi.

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

Seguridad de vCloud Director

VMware, Inc. 9

La abstracción de vCloud Director permite que un proveedor de servicios delegue la creación, laadministración y el uso de una vApp a las organizaciones de tenants (o que un departamento de TIdelegue estas capacidades a los equipos de la línea de negocio). Los usuarios y los administradores dela organización de tenants no utilizan ni administran funciones de vCenter, como vMotion, vSAN, etc. Lostenants solo tratan con la implementación de sus cargas de trabajo (vApp) para grupos de recursos yperfiles de almacenamiento, y su conexión a redes de VDC de la organización que son propiedad de laorganización. Debido a que los usuarios y los administradores de la organización nunca inician sesión envCenter, no existe el peligro de haber configurado mal un permiso de vCenter que conceda demasiadosderechos al usuario. Además, el proveedor puede cambiar cuando quiera la composición de los gruposde 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é elcaso de que se le asignen redes, almacenes de datos o grupos de recursos comunes, no podránmodificar ni siquiera ver las vApp de las demás organizaciones (a excepción de las vApp conectadas a lamisma red externa, ya que comparten el mismo vSwitch). Si a cada organización de tenants se leproporcionan sus propios almacenes de datos, redes y grupos de recursos exclusivos (aunque no sea unrequisito del sistema), permitirá al proveedor de servicios forzar una separación aún mayor entre lasorganizaciones.

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 delsistema, algunas funciones del sistema pueden estar configuradas para proporcionar información quepodría ser aprovechada por un tenant malintencionado.

Deshabilite el envío dedatos de rendimientodel host a los sistemasoperativos invitados.

vSphere incluye contadores de rendimiento de las máquinas virtuales ensistemas operativos Windows con VMware Tools instalado. De formapredeterminada, vSphere no expone la información del host a la máquinavirtual invitada. Debido a que la información sobre el host físico podría seraprovechada por un tenant malintencionado, debe comprobar que estecomportamiento predeterminado se encuentra en su lugar. Para másdetalles, consulte Comprobar que está deshabilitado el envío de datos derendimiento del host a los invitados en Seguridad de vSphere.

Limitar la recopilaciónde métricas de máquinavirtual

vCloud Director puede recopilar métricas que ofrecen información actual ehistórica sobre el rendimiento y consumo de recursos de las máquinasvirtuales. Debido a que algunas de estas métricas incluyen informaciónsobre el host físico, la cual podría ser aprovechada por un tenantmalintencionado, considere la posibilidad de configurar el subsistema derecopilación de métricas para recopilar solo las métricas que no seansusceptibles de ser utilizadas malintencionadamente. Consulte Configurarrecopilación de métricas en Guía del administrador de vCloud Director paraobtener más información.

Seguridad de vCloud Director

VMware, Inc. 10

Precaución con las extensionesvCloud Director admite un número de métodos de extensibilidad. Aunque estos métodos estándiseñados para evitar que cualquier extensión adquiera derechos que no se han otorgado a usuarios deltenant o aumente los privilegios que se le asignó durante la instalación, una extensión puedeproporcionar, ya sea de manera intencionada o no, superficies de ataque adicionales que podrían seraprovechadas por alguien que tenga conocimiento de la extensión. Los proveedores de servicios y losadministradores 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 complementoscarguen contenido malintencionado.

Seguridad y la capa de redes virtualesLas redes de vCloud Director aprovechan las capacidades de redes definidas por software de vSphere yNSX para proporcionar a los tenants un acceso seguro a los recursos compartidos de red. Lasresponsabilidades del proveedor de servicios se limitan a proporcionar las conexiones externas y lainfraestructura de red necesarias para lograr que los tenants puedan usar esas conexiones, y asignarrecursos 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 losrequisitos de red de nivel de tenant y de nivel de proveedor desde un punto de vista de configuración deseguridad. 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 entrevCloud 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 seintercepten los paquetes que la atraviesan en el nivel físico y no proporcionan ninguna función deaislamiento 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 variosgrupos de redes que agreguen recursos de DVswitches y grupos de puertos de ESXi de manera quepuedan ponerse a disposición de las organizaciones de tenants. (Una red externa no consume recursosde un grupo de redes). Un grupo de redes respaldado mediante VLAN o VXLAN proporciona aislamientoal utilizar VLAN a través de un switch distribuido de vNetwork. Una red VXLAN de vCloud Directortambién puede proporcionar aislamiento mediante el encapsulamiento de paquetes de capa 2 en otrospaquetes de capa 2 (MAC en MAC) en el kernel de ESXi, lo que permite al kernel, cuando se anula elencapsulamiento de paquetes, enviarlos a las máquinas virtuales invitadas correctas que estánconectadas a redes creadas a partir de este tipo de grupo.

Seguridad de vCloud Director

VMware, Inc. 11

El proveedor de servicios se encarga también de crear y administrar la infraestructura de NSX que seencuentra 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, lasorganizaciones 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 secomuniquen entre sí y accedan a otras redes, incluidas las redes de VDC de organización y las redesexternas, ya sea directamente o a través de una puerta de enlace Edge que pueda proporcionarservicios NAT y firewall.

n Una red de VDC de organización directa se conecta directamente a una red externa. Solamente losadministradores 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 deenlace Edge. Una red de VDC de organización enrutada también requiere que el VDC contenedorincluya un grupo de redes. Una vez que el administrador del sistema aprovisiona un VDC deorganización con una puerta de enlace Edge y lo asocia con un grupo de redes, los administradoresde la organización o del sistema pueden crear redes de VDC de organización enrutadas en eseVDC.

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 eladministrador del sistema crea un VDC de organización con un grupo de redes, los administradoresde la organización o del sistema pueden crear redes de VDC de organización aisladas en ese VDC.

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

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

Conexión directa a una redexterna.

Proporciona conectividad de capa 2 directa a las máquinasy las redes fuera del VDC de organización. Las máquinasfuera de este VDC de organización pueden conectarsedirectamente a las máquinas del VDC de organización.

La nube debe contener una redexterna.

Conexión enrutada a unared externa.

Proporciona un acceso controlado a máquinas y redesfuera del VDC de organización a través de una puerta deenlace Edge. Los administradores del sistema y losadministradores de la organización pueden configurar latraducción de direcciones de red (NAT) y la configuraciónde firewall en la puerta de enlace para poder acceder adeterminadas máquinas virtuales del VDC desde una redexterna.

El VDC debe contener una puertade enlace Edge y un grupo deredes.

Sin conexión a una redexterna.

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

El VDC debe contener un grupode redes.

Seguridad de vCloud Director

VMware, Inc. 12

De forma predeterminada, solo pueden utilizarlas las máquinas virtuales del VDC de organización quecontiene 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 laorganización.

Redes de vAppCada vApp contiene una red de vApp. Una red de vApp es una red lógica que controla el modo en quelas máquinas virtuales de una vApp se conectan entre sí y a las redes de VDC de organización. Losusuarios pueden crear y actualizar redes de vApp y conectarlas a redes de VDC de organización, ya seadirectamente 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 delsistema también requiere que se proteja la infraestructura de la que depende vCloud Director, incluidosvSphere, 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 deinfraestructura antes de la instalación es un paso clave, así como resulta crucial supervisar estoscomponentes 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 seguridadde 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 seguridadmá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 sinprivilegios (vcloud.vcloud) que se crea durante la instalación. En las Notas de la versión devCloud 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 devCloud 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 decontraseña segura. Pruebe con un servicio centralizado de autenticación como Kerberos y considere laposibilidad 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 sistemaoperativo de las celdas, pero se recomienda evitarlo siempre que sea posible. La ampliación del accesoal sistema operativo de las celdas podría significar una reducción de la seguridad.

Protección de los archivos confidenciales tras lainstalaciónDurante la instalación, vCloud Director escribe los datos de instalación, incluidas las contraseñas, en losarchivos del sistema de archivos local del host Linux de celdas. Estos archivos, global.properties yresponses.properties (ambos se encuentran en $VCLOUD_HOME/etc), contienen informaciónconfidencial que se volverá a utilizar cuando se agreguen más servidores a un grupo de servidores. Elarchivo responses.properties contiene las respuestas que proporciona el administrador cuando seejecuta el script de configuración. Ese archivo contiene una versión cifrada de la contraseña de la basede datos de vCloud Director y las contraseñas del almacén de claves del sistema. El acceso noautorizado a ese archivo podría dar acceso a un atacante a la base de datos de vCloud Director con losmismos permisos que el usuario de la base de datos especificó en el script de configuración. El archivoglobal.properties también contiene las credenciales cifradas. Estas credenciales no se debenconceder 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ánprotegidos mediante controles de acceso sobre la carpeta $VCLOUD_HOME/etc y los archivos mismos. Nocambie los permisos de los archivos ni de la carpeta, ya que se podría ampliar demasiado el acceso y sepodría provocar una reducción de la seguridad, o se podría restringir demasiado el acceso, lo queprovoca que el software de vCloud Director deje de funcionar. Para que los controles de accesofuncionen correctamente, el acceso físico y lógico a los servidores de vCloud Director se debe limitarexclusivamente a aquellos que necesiten iniciar sesión y se producirá únicamente con los nivelesmínimos de acceso necesarios. Esto implica que se limite el uso de la cuenta raíz a través de sudo yotras prácticas recomendadas que no se tratan en este documento. Además, las copias de seguridad delos servidores se deben proteger y cifrar de forma estricta, y las claves se deben administrar porseparado 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 deinstalación y actualización de vCloud Director.

Credenciales administrativasCompruebe que las credenciales que se utilizan para el acceso administrativo a la celda, vSphere, labase de datos de vCloud Director, los firewalls externos y otros dispositivos siguen los criterios decomplejidad de contraseñas adecuados. Siempre que sea posible, sopese implantar una directiva decaducidad y rotación para las contraseñas. Tenga en cuenta, sin embargo, que, cuando la contraseña deuna base de datos, vSphere o NSX cambia o caduca, parte o toda la infraestructura de nube deja defuncionar 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 diversascontraseñas administrativas para los distintos servidores del entorno de vCloud Director, incluidos lasceldas de vCloud Director, la base de datos de vCloud Director, los servidores de vSphere y NSXManager. De este modo, en caso de que peligrara la seguridad de un conjunto de credenciales (porejemplo, por un empleado descontento que deja la organización), la seguridad de los otros sistemas dela infraestructura no se vería comprometida.

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

Seguridad de la base de datosEn general, la seguridad de la base de datos está fuera del alcance de este documento. Al igual queocurre con los demás sistemas utilizados en la implementación de nube, se espera que la base de datosde 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 sistemaque aparecen en la guía de configuración de la base de datos correspondiente en la Guía de instalacióny actualización de vCloud Director. El usuario de la base de datos de vCloud Director no debe tenerprivilegios en otras bases de datos de ese servidor, así como tampoco debe tener privilegios deadministración del sistema. Esto infringiría el principio de mínimo privilegio en el servidor de la base dedatos y otorgaría al usuario más derechos de lo necesario.

Se recomienda consultar los siguientes documentos para obtener información sobre la seguridad de labase 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 deMicrosoft 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 admiteconexiones HTTPS y SSL a una base de datos de Oracle.

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

Seguridad de vCloud Director

VMware, Inc. 16

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

Para proteger un grupo de servidores de vCloud Director frente a atacantes externos, es necesario tomarmedidas defensivas comunes a todos los servicios web, como por ejemplo, proteger los extremosHTTPS 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 brokerAMQP RabbitMQ y una base de datos de Apache Cassandra opcional. De este modo, se reducirán almí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 pruebedicho entorno de red antes de empezar a instalar vCloud Director

VMware, Inc. 17

Conecte todos los vCloud Director Servers a una red que esté protegida y que se esté supervisando. Lasconexiones 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 conexionesde red de vCloud Director con un firewall. Solamente el puerto 443 (HTTPS) debe estar abierto paralas conexiones entrantes. Los puertos 22 (SSH) y 80 (HTTP) también se pueden abrir para lasconexiones entrantes, de ser necesario. Además, cell-management-tool requiere acceso a ladirección del bucle invertido de la celda. El firewall debe rechazar el resto del tráfico entranteprocedente de redes públicas, incluidas las solicitudes realizadas a JMX (puerto 8999).

Tabla 5‑1. Puertos que deben permitir paquetes entrantes provenientes de hosts devCloud Director

Puerto Protocolo Comentarios

111 TCP, UDP Asignador de puertos NFS utilizado por elservicio de transferencia

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

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 devCloud Director

Puerto Protocolo Comentarios

25 TCP, UDP SMTP

53 TCP, UDP DNS

111 TCP, UDP Asignador de puertos NFS utilizado por elservicio de transferencia

123 TCP, UDP NTP

389 TCP, UDP LDAP

443 TCP Las conexiones de vCenter, NSX Manager yESXi usan el puerto estándar. Si ha elegidootro puerto para estos servicios, deshabilite laconexión al puerto 443 y habilítelos en elpuerto 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 detransferencia.

1433 TCP Puerto de base de datos de Microsoft SQLServer predeterminado.

Seguridad de vCloud Director

VMware, Inc. 18

Tabla 5‑2. Puertos que deben permitir paquetes salientes provenientes de hosts devCloud Director (Continuación)

Puerto Protocolo Comentarios

5672 TCP, UDP Opcional. Mensajes de AMQP para lasextensiones 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 unared 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 deuna red privada dedicada.

n Los switches virtuales y los switches virtuales distribuidos que admitan redes de proveedor debenestar 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 enejecución o la manipulación de los datos transferidos. Las amenazas inherentes a NFSv3 sedescriben en el documento técnico acerca de la seguridad de NFS en entornos de confianza y queno son de confianza de SANS. Encontrará información adicional acerca de la configuración y laprotecció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 endpointsexternos. HTTPS también es compatible con varios endpoints internos, incluidos AMQP y LDAP. Esespecialmente 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 loscasos se pueden proteger adecuadamente con los certificados de la empresa o incluso con certificadosautofirmados.

Todos los certificados deben tener un campo de nombre común (CN) que coincida con el nombre dedominio completo (FQDN) del servidor en el que están instalados. Por lo general, esto implica que elservidor 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 planeaconectarse mediante la dirección IP, el certificado debe incluir el campo subjectAltName que coincidecon la dirección IP del host.

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

Seguridad de vCloud Director

VMware, Inc. 19

Certificados de endpoints públicosLos endpoints expuestos a una red empresarial u otra red pública como Internet deben protegersemediante 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 ambasdirecciones y proporcionar los detalles de su certificado y su almacén de claves durante lainstalació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 puedeverificar la cadena de confianza hasta la raíz. Los certificados de menor nivel (de entidad de certificaciónempresarial o autofirmados) no se pueden comprobar de esta manera; como a estos los ha creado elequipo 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 yque, por lo general, se han creado para su uso específico con componentes de vCloud Director, como labase de datos y AMQP, pueden usar certificados firmados por una CA empresarial, o incluso emplearcertificados 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 auna 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 formapredeterminada, ya que tiene vulnerabilidades conocidas. Tras la instalación, puede usar la herramientade administración de celdas para configurar el conjunto de protocolos y cifrado que admite el sistemapara 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 hostESXi 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 aVMCA en una entidad de certificación subordinada, o bien, reemplazar todos los certificados porcertificados personalizados. Consulte Certificados de seguridad de vSphere en la guía Seguridad devSphere para obtener más información sobre la creación y la sustitución de los certificados utilizados porvCenter y ESXi.

Seguridad de vCloud Director

VMware, Inc. 20

Configurar vCloud Director para comprobar los certificados devCenterSi desea configurar vCloud Director para comprobar los certificados de vCenter, cree un almacén declaves de Java en formato JCEKS que contenga los certificados de confianza utilizados para firmar loscertificados de vCenter. (Los certificados de los servidores individuales de vCenter no se encuentran eneste 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 unalmacé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énde 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 delsistema. En la sección Configuración del sistema de la pestaña Administración, haga clic en Generaly desplácese hasta la parte inferior de la página.

Seleccione los certificados Comprobar vCenter y SSO de vSphere y Comprobar certificados de NSXManager. 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 dedatos 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 certificadoscorrecta y un certificado que coincida con su FQDN. Si no es así, se producirá un error en las conexionescon vCenter y NSX.

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

Actualizar los certificados y las claves de las celdas devCloud DirectorCada servidor vCloud Director requiere dos certificados SSL, uno para el servicio HTTP y otro para elservicio 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 ofrecenel nivel más alto de confianza.

Seguridad de vCloud Director

VMware, Inc. 21

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

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

cell-management-tool certificates options

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

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

Los firewalls de red segmentan las redes físicas o virtuales de modo que solo pueda pasar entre ellos untráfico limitado y bien definido en puertos y protocolos concretos. Este documento no define la lógica deimplementación de firewall en general ni explica los detalles de configuración de firewall. Estos temas nose tratan en esta guía. Por el contrario, esta guía identifica las ubicaciones donde se recomienda colocarlos 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 enla 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 necesitandebería realizarse mediante un firewall de red. En concreto, se recomienda restringir el acceso a la basede datos de vCloud Director, vCenter Server, los hosts ESXi, AMQP y los servicios de copia de seguridado 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 dedirecciones IP)

n Descartar los paquetes TCP con un formato incorrecto

Seguridad de vCloud Director

VMware, Inc. 22

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 deuna solicitud entrante

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

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 elbloqueo del tráfico malintencionado mediante la finalización de la conexión HTTPS en el WAF. De estemodo se permite que el WAF complete el protocolo de enlace utilizando su propio certificado y reenvíesolicitudes 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 unaconexión HTTP con la celda, pero no es segura). Incluso cuando las comunicaciones entre el clienteremoto y el WAF están protegidas por HTTPS, es necesario que también se pueda realizar lacomunicació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 dosconexiones TLS o SSL que existen cuando se utiliza la terminación TLS o SSL: una entre el equipo delusuario 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 laentidad de certificación en el WAF para que las aplicaciones de ese cliente, como la API de vCloud y laconsola web, puedan comprobar la identidad del servidor, sino también usar un certificado firmado por laentidad de certificación en las celdas, incluso cuando solo las vaya a ver el WAF. Aunque el WAF aceptalos certificados autofirmados, solo se recomienda usarlos cuando cada certificado se aceptamanualmente durante la instalación; sin embargo, esto limita la flexibilidad del grupo del servidor devCloud Director, ya que cada celda se debe configurar de forma manual (y se tiene que volver aconfigurar cuando se renueven los certificados).

Seguridad de vCloud Director

VMware, Inc. 23

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

Encabezado X-Forwarded-ForX-Forwarded-For es un encabezado muy utilizado que admiten muchos servidores proxy y firewalls. Serecomienda 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 poderiniciar 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óncomo la dirección del cliente y registrará la dirección del firewall como un campo de proxyAddressindependiente 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 mensajesque admite mensajería flexible para sistemas corporativos. vCloud Director utiliza el agente AMQP deRabbitMQ para proporcionar el bus de mensajería que utilizan los servicios de extensión, las extensionesde objeto y las notificaciones de tareas de bloqueo.

Los mensajes que se publican en RabbitMQ incluyen información confidencial. La exposición del tráficode AMQP entre celdas de vCloud Director puede suponer una amenaza de seguridad para el sistema ysus tenants. Los endpoints AMQP se deben configurar para que usen SSL. Los puertos AMQP se debenbloquear en el firewall del sistema. Se debe permitir a los clientes de terceros que consumen mensajesAMQP operar en la DMZ. Cualquier código que consuma mensajes de vCloud Director debe someterse auna 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 laentrada 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ónConfiguración de broker AMQP de la página Extensibilidad de la consola web de vCloud Director yproporcione:

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. 24

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

Importante Aunque hay disponible una opción Aceptar todos los certificados, no se recomiendaseleccionarla cuando la seguridad sea un asunto prioritario. Al aceptar todos los certificados sincomprobarlos, 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 lared de administración. No se debe poder acceder, sin embargo, a ningún endpoint AMQP desde lasredes públicas o de empresa.

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

Además de colocarla en una red de administración dedicada, la infraestructura de Cassandra debeprotegerse 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ómoinstalar 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 certificadosautofirmados, 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 certificadosSSL 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 exponevarios MBeans a través de JMX para permitir la administración de las operaciones del servidor yproporcionar acceso a estadísticas internas. Debido a que esta interfaz puede exponer informaciónconfidencial sobre el sistema que se está ejecutando y afectar su funcionamiento, es fundamental que elacceso a JMX esté estrictamente controlado.

Seguridad de vCloud Director

VMware, Inc. 25

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

Limitar conexiones a JMXDado que JMX es una interfaz de administración destinada solo a administradores del sistema, no hayninguna razón por la que se deba exponer fuera de la red de administración de vCloud Director. Si elsistema tiene asignada una tercera dirección IP exclusivamente para administración, enlace JMXdirectamente a esta dirección IP. De forma predeterminada, el conector JMX de vCloud Director seenlaza a la dirección IP principal que especificó durante la configuración del sistema. Puede invalidareste 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 IPasignadas a esta red de administración y el puerto JMX (el predeterminado es 8999) no deberían permitirque 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 sistemade 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 deJMX 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 exponersefuera 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. 26

Los clientes de JMX ahora deberán conectarse con HTTPS, pero deben tener acceso al certificado deCA. Por ejemplo, para jconsole debe importar el certificado de CA en un almacén de claves en lamáquina que ejecutará jconsole. A continuación, inicie jconsole con los siguientes argumentos de lalí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íaneste proceso en algo difícil de manejar, ya que se necesitaría cada certificado autofirmado en unalmacén de claves en la máquina que ejecuta el cliente de JMX. Es más fácil que los certificadosfirmados por una entidad de certificación sean compatibles aquí porque solo se necesita el certificado dela 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 denube y proporciona acceso a los sistemas de cliente que se utilizan para realizar funcionesadministrativas en vCloud Director.

Los sistemas que se conectan a la red de administración incluyen el servidor de base de datos devCloud 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 directoriosLDAPv3 que mantiene el proveedor para autenticar a los usuarios de la organización y losadministradores de NSX. Los servidores de vCenter de esta red también tienen que acceder a suspropios servidores de Active Directory.

Requisitos de configuración de la red de administración de lainfraestructura virtualPara la red de administración es muy importante ser independiente de las redes de datos de la máquinavirtual. Más aún en un entorno de nube donde el proveedor y los tenants pertenezcan a distintasorganizaciones. Seguro que no desea exponer la red de administración del proveedor a posibles ataquesde vApps de la organización. Del mismo modo, la red de administración debe ser independiente de laDMZ que proporciona acceso a los administradores de la organización. A pesar de que pueden estaraccediendo a las mismas interfaces como administradores del sistema del proveedor, el concepto deDMZ es importante a la hora de segmentar el tráfico público del privado y de proporcionar una estrategiade defensa exhaustiva.

Seguridad de vCloud Director

VMware, Inc. 27

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

Desde una perspectiva de arquitectura de red, se requiere el firewall interno que intercede ante lasconexiones de vCenter y vCloud Director con vSphere (y otras redes). No se trata de si distintasmáquinas virtuales en un solo host se pueden conectar con una zona DMZ y una red privada a la vez. Ensu lugar, hay máquinas virtuales en ese módulo de administración, las celdas de nube, que se conectanellas mismas con ambas redes. Si bien el software de vCloud Director se diseñó y se implementó segúnla política de seguridad de productos de VMware y se cumplieron los requisitos de seguridad, no se tratade un firewall propiamente dicho y, por lo tanto, no debería mediar tráfico por sí mismo entre la DMZ y lasredes 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 almacenamientotambién son físicamente independientes. Esto sigue las prácticas recomendadas de vSphere y protege altenant y al proveedor de almacenamiento ante máquinas virtuales malintencionadas. Lo mismo sucedecon la red de copia de seguridad. Técnicamente se trata de una rama de la red de administración. Susrequisitos específicos y su configuración dependen del software de copia de seguridad y la configuraciónque se esté usando.

vMotion no siempre se coloca en una red independiente de la red de administración; sin embargo, en lanube, es importante desde una perspectiva de separación de tareas. Por lo general, vMotion tiene lugaren una zona segura y, si se coloca en la red de administración, permite que un administrador deproveedores u otro usuario con acceso a esa red "examine" el tráfico de vMotion, infringiendo laprivacidad de las organizaciones. Por esta razón, se debe crear una red física independiente paravMotion 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 seguridadgeneral del sistema. La mayoría de organizaciones tiene normas que rigen quién tiene permiso paraacceder al software y los recursos relacionados con el hardware, así como para realizar cambios enellos. Mantener un registro de auditoría de las actividades importantes permite que la organizacióncompruebe el cumplimiento de las reglas, detecte las infracciones e inicie actividades de corrección. Enalgunas empresas, se aplican leyes y normativas externas que exigen supervisión continua ycomprobació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, paraobtener acceso no autorizado al sistema, sondear su información o interrumpir su funcionamiento. Si sesabe que se intentó perpetrar un ataque, y se conocen los detalles de dicho ataque, se pueden mitigarlos daños y prevenir ataques futuros.

Seguridad de vCloud Director

VMware, Inc. 28

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

vCloud Director incluye dos tipos de registro:

Registros dediagnóstico

Los registros de diagnóstico que se almacenan en el directorio de registrosde 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 lasinteracciones importantes del sistema. Cada celda de vCloud Director creavarios archivos de registro de diagnóstico de los que se describen en Verlos registros de vCloud Director en la Guía del administrador devCloud Director.

Registros de auditoría Los registros de auditoría registran las acciones significativas, incluidos elinicio y el cierre de la sesión. El registro de auditoría del sistema sealmacena en la base de datos de vCloud Director y se puede supervisar enla interfaz de usuario web. Cada administrador de organización y eladministrador 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 otrosregistros, 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 unservidor de syslog durante la instalación. Se recomienda exportar los registros a un servidor syslog porvarias razones:

n Los registros de la base de datos no se conservan después de 90 días, mientras que los registrosque 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 almismo tiempo.

n Protege los registros de auditoría frente a pérdidas en el sistema local debido a errores, falta deespacio 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 deinformació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 dehardware físico de la pila.

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

Seguridad de vCloud Director

VMware, Inc. 29

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

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

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

La explicación anterior solo abarca el envío del registro de auditoría a un servidor syslog. Lasorganizaciones de operaciones de seguridad y operaciones de TI también pueden beneficiarse de laagregació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ódicapara copiarlos en una ubicación centralizada, la configuración de un registrador adicional en el archivolog4j.properties ($VCLOUD_HOME/etc/log4j.properties) en un servidor syslog central o el uso deuna utilidad de recopilación de registros como vRealize Log Insight para supervisar y copiar los archivosde registro en una ubicación centralizada. La configuración de estas opciones depende del sistema queprefiera 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 faltade cifrado expone los datos de registro al rastreo (la información presente en los registros podríautilizarse para iniciar ataques posteriores), y la falta de control de la transmisión podría permitir que unatacante alterase los datos de registro. Para obtener más información, consulte la sección 4 de RFC5426.

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ñomáximo. Por este motivo, existe un riesgo de crecimiento del archivo de registro descontrolado. Por cadasolicitud 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 losregistros 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 tenersuficiente espacio en disco para almacenar esos archivos, más el tamaño que permita que consuman losregistros de solicitudes Jetty. Tal como se menciona anteriormente, el registro centralizado garantiza queno 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. 30

NTP y registrosLa Guía de instalación y actualización de vCloud Director identifica NTP como un requisito para todas lasceldas de vCloud Director. Un beneficio adicional del uso de NTP es que los mensajes de registro de lasceldas tienen marcas de tiempo sincronizadas. De hecho, las herramientas de administración de registroy los sistemas SIEM incorporan sus propias marcas de tiempo para permitir la coordinación de losregistros de varios orígenes, pero estas marcas de tiempo son la hora indicada por esos sistemas, no lahora 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 debenconsolidarse en los procesos de auditoría. Estos incluyen los registros de NSX Manager, la base dedatos de vCloud Director, vCenter Server y los hosts de vSphere. Los detalles de los archivos de registrode cada sistema y su finalidad están fuera del alcance de este documento y se pueden encontrar en ladocumentación relacionada con esos productos.

Seguridad de vCloud Director

VMware, Inc. 31

Seguridad de tenants 6El proveedor de servicios, los administradores del sistema y los administradores de la organización sonlos 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 consisteprincipalmente en proporcionar una buena seguridad de nivel del sistema para que los atacantesexternos no puedan acceder a los recursos de los tenants. El proveedor de servicios también debe serconsciente de la posibilidad de que sea un tenant el que realice el ataque o simplemente interfiera conotro tenant. Algunos de los posibles ataques entre tenants incluyen fisgonear detalles a nivel de sistemade los recursos informáticos, de almacenamiento y de red. Las interferencias, ya sean intencionadas ono, surgen cuando los recursos del sistema se comparten entre varios tenants (que pueden sospecharsemutuamente) y un tenant consigue consumir una cantidad suficiente de esos recursos para denegar a losdemás tenants el nivel de servicio que esperan recibir. Esta situación a menudo se conoce como elproblema del “vecino ruidoso”.

Como se describe en Capítulo 3Arquitectura y funciones de seguridad de vCloud Director,vCloud Director está diseñado para permitir un uso compartido de recursos del sistema transparenteentre un gran número de tenants. En general, un proveedor de servicios tiene libertad para implementarlos recursos del sistema de forma que potencie al máximo la eficiencia del sistema a la vez que minimizalos posibles problemas de tiempo de inactividad. Cada vez que se comparten recursos entreorganizaciones de tenants, el proveedor de servicios debe plantearse cómo puede afectar este usocompartido 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.

Dentro del sistema de vCloud Director, las redes VXLAN y VLAN exigen que se separe el tráfico depaquetes que equivale a lo que se puede conseguir con redes físicas independientes. También ofrecenuna gama de opciones de enrutamiento y de protección con firewall que concede a las organizacionestener un control detallado sobre el acceso a sus cargas de trabajo desde sistemas externos y los de

VMware, Inc. 32

dentro de la organización. Estas funciones se describen en detalle en la documentación devCloud Director en http://docs.vmware.com. En su mayor parte, un proveedor de servicios que hayadiseñ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 tomarparte 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 redempresarial, el proveedor de servicios no debe nunca pasar por alto los requisitos de firewall de lainfraestructura de vSphere que ha implementado y usado vCloud Director. Lo más probable es quealgunas vApps necesiten acceso a Internet o que haya que acceder a ellas de forma remota, ya sea através de RDP, SSH, etc., para la administración, o a través de HTTP u otros protocolos por parte de losusuarios finales de dichos servicios. Por ese motivo, se recomienda utilizar dos redes de datos demáquina virtual distintas (como se muestra en los diagramas de arquitectura en Aislamiento y asignaciónde 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 depuertos configurado para los servicios expuestos. La red externa a la que se conectan estas redes VDCde la organización requeriría un firewall que la protegiera y que permitiera la entrada del tráfico acordadoa esta red de la DMZ. Es decir, el proveedor de servicios tiene que asegurarse de que no todos lospuertos y protocolos puedan iniciar una conexión con la red externa de la DMZ. Al mismo tiempo, debeconfirmar que se permite suficiente tráfico para que las vApps de esa organización puedan proporcionarlos servicios para los que se han creado. Por lo general, esto incluye los puertos 80/TCP y 443/TCP, perose podrían incluir otros protocolos y puertos. El proveedor de servicios debe determinar cuál es la mejormanera de mantener este equilibrio y debe saber que, desde una perspectiva de seguridad, se debenbloquear los protocolos y puertos innecesarios.

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

Del mismo modo, se utiliza una red VDC privada de organización con enrutamiento NAT en una red dedatos 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 redde datos interna para máquinas virtuales. De nuevo, la parte de la red externa de esta red conenrutamiento debe estar en la zona DMZ para que un firewall de red independiente separe la DMZ de laconexión a Internet.

Seguridad de vCloud Director

VMware, Inc. 33

Aislamiento y asignación de recursosLa implementación de un proveedor de servicios estándar de vCloud Director visualiza el uso compartidode recursos de vSphere entre varias organizaciones de tenants. De este modo se proporciona a lasorganizaciones la máxima flexibilidad y al proveedor, el máximo aprovechamiento de los recursosinformáticos, de red y de almacenamiento aprovisionados. A continuación se muestran diagramas deejemplos 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 lassubsecciones posteriores se describen las recomendaciones específicas en torno a los grupos derecursos, los almacenes de datos, la configuración de redes y la de otros componentes.

Implementación de recursos compartidosFigura 6‑1 y Figura 6‑2 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 sededica a la administración del sistema ("módulo de administración") o de las cargas de trabajo de lostenants ("módulo de nube").

Seguridad de vCloud Director

VMware, Inc. 34

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

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

Seguridad de vCloud Director

VMware, Inc. 35

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; entreellos, vCenter, NSX, la base de datos de vCloud Director, etc. A sus conexiones las controlanexclusivamente los firewalls del diagrama, ya que a esos servicios no se puede acceder desde otrasmáquinas que estén en la DMZ ni directamente desde Internet.

Seguridad de vCloud Director

VMware, Inc. 36

La figura Figura 6‑3 solo se centra en el módulo de administración. Muestra que se necesitan al menosdos, si no tres, redes físicas independientes conectadas a ese módulo. Aquí se incluye la red de DMZcon equilibrio de carga, la red de administración privada y una red opcional de almacenamientodedicado, 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 ellostiene redes externas que se muestran como una red de datos de DMZ de máquina virtual para que seusen como redes VDC públicas de organización, así como redes de datos de máquina virtual para redesVDC privadas de organización que se puedan enrutar a una red externa.

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

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

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 devulnerabilidades, el antivirus y los sistemas de administración de GRC, se aplicarán a vCloud Director, asus sistemas asociados, a vSphere y a sus sistemas asociados, y a las redes e infraestructuras dealmacenamiento que sean compatibles. Los detalles sobre estos sistemas tampoco se incluyen en estedocumento.

Seguridad de vCloud Director

VMware, Inc. 37

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

Las organizaciones de tenants comparten los grupos de recursos subyacentes, los almacenes de datos ylas redes externas expuestas a través de un solo VDC de proveedor, sin que ello afecte a los recursosque no poseen (o incluso desconozcan que existen dichos recursos). Mediante la correcta administracióndel almacenamiento de vApp y las concesiones de tiempo de ejecución, las cuotas de vApp, los límitesen 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íanbajo el modelo de asignación de grupo de reserva y nunca se sobreasignarían recursos. En estedocumento no se explicarán todas las opciones posibles, pero se destacarán algunos puntos en lassiguientes subsecciones.

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

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

n Datos y recursos que son propiedad de países u organizaciones que, a pesar de confiar en elaislamiento de la nube, exigen que sus VDC no puedan compartir recursos con determinadostenants (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 segmentarseen diferentes “dominios de seguridad” a través de distintos VDC de proveedor, mediante los cuales sepuedan agrupar (o aislar) las vApp con problemas similares. Por ejemplo, se pueden identificar conclaridad algunos VDC de proveedor como almacenamiento y procesamiento de datos en ciertos países.

Grupos de recursosDentro de un solo VDC de proveedor, puede haber varios grupos de recursos que agreguen recursos deCPU y memoria proporcionados por la infraestructura de vSphere subyacente. Desde una perspectiva deintegridad y confidencialidad, no es necesario segmentar diferentes organizaciones entre diferentesgrupos de recursos. Pero desde una perspectiva de disponibilidad, es posible que haya motivos para

Seguridad de vCloud Director

VMware, Inc. 38

hacerlo. Este problema de administración de recursos depende de los modelos de asignación de VDC deorganización, de las cargas de trabajo esperadas, de las cuotas y los límites que se aplican a estasorganizaciones y de la velocidad con la que el proveedor pueda poner en línea otros recursosinformáticos. En esta guía no se definen los distintos modelos de asignación de recursos y cómo afectanal uso de un grupo de recursos por parte de la organización. Tan solo se explica que, cuando se permitela sobreasignación de recursos de un grupo usado por más de una organización, se corre el riesgo dedegradar la calidad del servicio para una o varias organizaciones. La supervisión adecuada de losniveles 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 esteobjetivo.

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

Limitar las operacionesde uso intensivo derecursos

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

Imponer cuotasrazonables

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 quepuede crear un tenant y limitar el número de conexiones simultáneas pormáquina virtual) en la Guía del administrador de vCloud Director.

Administrarconcesiones de tiempode ejecución yalmacenamiento

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

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

Seguridad de vCloud Director

VMware, Inc. 39

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 enuna red de VDC de organización para conectar dos vApp distintas y sus redes, o para conectar una redde vApp con el centro de datos empresariales. En estos casos, la red externa no se debe compartir entrevarias organizaciones.

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

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

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

Grupos de redesVarios tenants pueden usar un solo grupo de redes con la condición de que todas las redes del grupoesté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 deuna VXLAN y el aislamiento entre las distintas VXLAN. Los grupos de redes respaldados mediante ungrupo de puertos deben configurarse con grupos de puertos que estén aislados entre sí. Estos grupos depuertos podrían estar aislados físicamente, a través de las VXLAN.

Seguridad de vCloud Director

VMware, Inc. 40

De los tres tipos de grupos de redes (grupo de puertos, VLAN y VXLAN), resulta más fácil compartir ungrupo de redes VXLAN de vCloud Director. Los grupos de VXLAN admiten muchas más redes que losgrupos de redes respaldados mediante VLAN o un grupo de puertos, y el aislamiento se aplica en el nivelde kernel de vSphere. Aunque los switches físicos no aíslan el tráfico sin utilizar la VXLAN, VXLANtampoco 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 parapaquetes 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 alproveedor de servicios ofrecer capacidades de almacenamiento en niveles según la capacidad, elrendimiento y otros atributos. Las organizaciones de tenants no pueden acceder a almacenes de datosindividuales. En su lugar, un tenant puede elegir a partir de un conjunto de perfiles de almacenamientoofrecidos por el proveedor de servicios. Si los almacenes de datos subyacentes están configurados parapoder acceder a ellos solamente desde la red de administración de vSphere, el riesgo de compartiralmacenes 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 cantidadde almacenamiento disponible para otras organizaciones. Esto es especialmente útil con organizacionesque 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ímitede almacenamiento, habilitar el aprovisionamiento ligero (si es posible) y supervisar que elalmacenamiento se utilice con cuidado. También debe administrar cuidadosamente las concesiones dealmacenamiento, como se explica en Limitar el consumo compartido de recursos compartidos. Otraposibilidad es que, si no comparte almacenes de datos, dedique adecuadamente el almacenamiento alos perfiles de almacenamiento que ponga a disposición de cada organización, con el posible riesgo dedesperdiciar 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 losVMDK. Aunque los administradores de vSphere pueden ver los sistemas de almacenamiento físicodesde donde se crean estos almacenes de datos, para esto se necesitan derechos que no estándisponibles para el administrador o el tenant de vCloud Director. Los usuarios del tenant que crean ycargan varias vApp simplemente almacenan los VMDK de las vApp en uno de los perfiles dealmacenamiento que hay disponibles en el VDC de organización que están utilizando.

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

De forma similar, las organizaciones de tenants solo ven los perfiles de almacenamiento que haydisponibles en los VDC de organización, e incluso esa vista está limitada a la abstracción devCloud Director. No pueden examinar los almacenes de datos del sistema. Solo ven lo que se hapublicado en catálogos o lo que han utilizado las vApp que administran. Si los perfiles dealmacenamiento de VDC de la organización no comparten los almacenes de datos, las organizaciones

Seguridad de vCloud Director

VMware, Inc. 41

no pueden influir negativamente en el almacenamiento de las demás (excepto, tal vez, si usandemasiado ancho de banda para la E/S de almacenamiento). Aunque lo hicieran, las anterioresrestricciones y abstracciones garantizan el aislamiento adecuado entre las organizaciones. Losadministradores de vCloud Director pueden habilitar Storage I/O Control de vSphere en determinadosalmacenes de datos para restringir la capacidad de un tenant de consumir una cantidad excesiva deancho de banda de E/S de almacenamiento. Consulte Configurar el soporte de Storage I/O Control en unVDC 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 cualquiersistema. Debido a que todas las autenticaciones hacia el sistema de vCloud Director y dentro de él serealizan mediante nombre de usuario y contraseña, es fundamental seguir las prácticas recomendadaspara administrar usuarios y sus contraseñas.

El objetivo de este tema es definir las capacidades y las limitaciones de la administración de usuarios ycontraseñas en vCloud Director, y ofrecer recomendaciones para administrarlas y utilizarlas de formasegura 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 servulnerables 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 deadministración de contraseñas solicitados por determinados sectores, como por ejemplo, el estándar deseguridad de datos PCI. Para impedir ataques por fuerza bruta, las cuentas locales deben someterse alímites de reintentos y reglas de bloqueo de cuenta.

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

Una nueva instalación de vCloud Director crea una cuenta de administrador del sistema local. En laconfiguración predeterminada, vCloud Director requiere que al menos una cuenta de administrador delsistema siga siendo local. Un proveedor de servicios que ha permitido a la organización del sistema queutilice el servicio SSO de vSphere (un IDP de SAML) o LDAP, puede configurar vCloud Director para queno 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 (unIDP de SAML) o LDAP.

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

Seguridad de vCloud Director

VMware, Inc. 42

3 Ejecute el comando manage-config de la herramienta de administración de celdas para volver aconfigurar el sistema de modo que no se requiera ninguna cuenta local de administrador del sistemay 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 laherramienta de administración de celdas que le piden que especifique las credenciales deadministrador del sistema deben usar la opción -i --pid en su lugar, proporcionando los ID deproceso de la celda en pid. Consulte la Referencia de la herramienta de administración de celdas enGuía del administrador de vCloud Director.

4 Puede deshacer este cambio con una línea de comandos similar de la herramienta de administraciónde 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 proporcionancapacidades o se integran con sistemas para controlar aquellas situaciones en las que los usuarios hanolvidado su contraseña. Estos IDP no se incluirán en el ámbito de este documento. La herramienta deadministración de celdas de vCloud Director incluye un comando recover-password que sirve pararecuperar una contraseña perdida del administrador del sistema. En vCloud Director no hay ningunacapacidad nativa para controlar esta situación para otros usuarios locales. Se recomienda que todas lascontraseñas de cuentas locales se guarden de manera segura y conforme a lo establecido por eldepartamento 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 nose recomienda ningún método en particular.

Seguridad de contraseñasLa seguridad de las contraseñas de los usuarios de los IDP depende de los controles proporcionados porese IDP o de las herramientas utilizadas para administrar usuarios dentro del directorio. Por ejemplo, sivCloud Director se conecta a Active Directory, este aplica los controles típicos de longitud, complejidad ehistorial de la contraseña de Active Directory asociados a Microsoft Active Directory. Otros IDP tienden aadmitir capacidades similares. Los detalles de los controles de seguridad de las contraseñas sonespecí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 seiscaracteres. Este requisito no se puede configurar y no hay disponibles otros controles de historial ocomplejidad de contraseña. Se recomienda que los usuarios, especialmente los administradores delsistema y de la organización, tengan especial cuidado al elegir sus contraseñas para protegerse frente aataques por fuerza bruta (consulte el apartado de problemas de bloqueo de cuentas más adelante).

Seguridad de vCloud Director

VMware, Inc. 43

Protección de contraseñas de usuariosLas credenciales de usuarios administradas por un IDP nunca se almacenan en la base de datos devCloud Director, sino que se transmiten mediante el método elegido por el IDP. Consulte Configurarproveedores 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 dedatos de vCloud Director. Una contraseña con texto sin formato no se puede recuperar de la base dedatos. Los usuarios locales se autentican aplicando hash a la contraseña presentada y comparándolacon 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 almacenacontraseñas para los servidores de vCenter y los administradores de NSX conectados. Los cambiosrealizados en estas contraseñas no se actualizan automáticamente en el sistema. Deberá cambiarlasmanualmente mediante el script de configuración de vCloud Director (para la contraseña de base dedatos 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 suscertificados TLS/SSL, así como las contraseñas para base de datos de vCloud Director, los servidores devCenter y los servidores de administrador de NSX, como se mencionó anteriormente. Estas contraseñasse 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 archivosconfidenciales tras la instalación, proteja adecuadamente cualquier copia de seguridad que contenga esearchivo.

Control de acceso basado en funcionesvCloud Director implementa un modelo de autorización basado en funciones. En esta sección seanalizan los diferentes orígenes de identidad, los tipos de usuario, los controles de autenticación, lasfunciones y los derechos que se encuentran en vCloud Director. Es necesario comprender toda estainformación para poder proteger correctamente el sistema y proporcionar el acceso correcto a laspersonas adecuadas.

Una organización de tenants de vCloud Director puede contener un número arbitrario de usuarios ygrupos. El administrador de la organización puede crear los usuarios localmente o bien se puedenimportar 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 devarios grupos se le asignan todas las funciones que se asignan a esos grupos. Cada organización secrea con un conjunto predeterminado de derechos y un conjunto de funciones predefinidas que incluyencombinaciones de esos derechos. Un administrador del sistema puede conceder otros derechos a unaorganización, y los administradores de la organización pueden utilizar esos derechos para crearfunciones personalizadas que tengan un carácter local dentro de la organización. Los permisos dentro deuna organización se controlan mediante la asignación de derechos y funciones a usuarios y grupos.

Seguridad de vCloud Director

VMware, Inc. 44

No se permite que usuarios sin autenticar accedan a cualquier funcionalidad de vCloud Director a travésde la consola web, la API de vCloud, el portal para tenants ni la API de vCloud. Cada usuario seautentica con un nombre de usuario y una contraseña. Es posible configurar políticas de reintentos ybloqueo 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 cadauna de estas funciones. El propósito de esa sección es ayudarle a elegir la función adecuada para cadatipo de usuario. Por ejemplo, la función del usuario de vApp puede ser apropiada para un administradorque necesite encender y apagar las máquinas virtuales, pero si también necesita modificar la cantidad dememoria asignada a una máquina virtual, la función Autor de vApp sería más adecuada. Es posible queestas funciones no tengan los conjuntos exactos de derechos relevantes para sus organizaciones detenants, por lo que los administradores de cada organización pueden crear funciones personalizadas. Eneste documento no se incluye la descripción de qué derechos específicos se pueden combinar paracrear 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 compartecon otras aplicaciones o empresas. Los usuarios se autentican en el proveedor de identidad para obtenerun token que se puede utilizar para iniciar sesión en la organización. Esta estrategia permite que lasempresas proporcionen acceso a varios servicios no relacionados, incluido vCloud Director, con un soloconjunto de credenciales, lo que se conoce como inicio de sesión único.

Seguridad de vCloud Director

VMware, Inc. 45

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 queadmita 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 queadmita el lenguaje de marcado de aserción de seguridad (SAML) 2.0estándar.

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

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

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

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

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

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

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

Seguridad de vCloud Director

VMware, Inc. 46

contraseñas, incluidos los bloqueos por errores de autenticación, la caducidad de contraseñas, elhistorial, la complejidad, etc., y que son específicos del servicio LDAP elegido. Si una organización seconfigura para que utilice el LDAP del sistema, sus usuarios provendrán de la OU que se especifique enla 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 OUdentro 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 administradorde la organización pueda administrar los usuarios. La falta de ese control podría suponer una cargaadicional al administrador del sistema y podría impedir que la organización controlara de forma fácil yadecuada el acceso a sus VDC. Ante la ausencia de tales controles de administración, una organizaciónsolo 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 LDAPde cualquier organización debe estar habilitada para que el software pueda autenticar correctamente alos usuarios. Tal y como se recomienda en este documento, el servidor LDAP del sistema debe estarsituado en la red de administración privada, separado de la DMZ mediante un firewall. Algunosproveedores de nube y la mayoría de las organizaciones de TI ejecutarán los servidores LDAP de lasorganizaciones que sean necesarios, los cuales estarían también en una red privada, no en la DMZ. Otraopción para un servidor LDAP de la organización consiste en hospedarlo y administrarlo fuera delentorno del proveedor de nube y que el control lo tenga la organización. En ese caso, debe estarexpuesto a las celdas de vCloud Director, posiblemente a través de la propia DMZ del centro de datos dela empresa.

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

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

Seguridad de vCloud Director

VMware, Inc. 47

LDAP a través de TLS/SSL

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

Si el certificado firmado del servidor LDAP no está disponible, el certificado de la entidad de certificaciónque firma el certificado del servidor LDAP se debe importar en el almacén de claves JCE (JCEKS) delsistema o la organización. Las configuraciones de LDAP que especifican un almacén de claves JCEKSson también seguras, pero se pueden generar errores de configuración cuando se confía en muchos delos certificados de CA (o incluso muchos de los certificados específicos del servidor). Además, espreferible 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 através del puerto 389/TCP, los servidores que admiten LDAP a través de SSL usan el puerto 636/TCP deforma predeterminada. Este puerto también se puede configurar, sin embargo. Tenga en cuenta quevCloud Director es compatible con el LDAP heredado a través de SSL (LDAPS) y no es compatible conla 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 uncertificado 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 auno los usuarios que tengan la misma función. Cuando los usuarios LDAP inician sesión, en esa sesiónse asignan las funciones que están asignadas a los grupos a los que pertenecen. Como las pertenenciasa los grupos de los usuarios cambian en función de los controles que se producen en susorganizaciones, las funciones que se asignan a esos usuarios también cambian automáticamente paraadecuarse a la asignación de funciones para el grupo. De este modo, las organizaciones pueden integrarfácilmente las funciones de nube con las funciones o los grupos internos de la organización y lossistemas que aprovisionan y administran a estas organizaciones.

Por ejemplo, una organización puede decidir conceder inicialmente la función de "Solo acceso a laconsola" a los usuarios LDAP para limitar los derechos de los usuarios. Para ello, todos los usuarios quenecesitan esta función básica se agregan a un único grupo LDAP y, cuando ese grupo se importa, eladministrador de la organización le asigna la función de Solo acceso a la consola. A continuación, esosusuarios con otros controles de trabajo se podrían agregar a otros grupos LDAP, también importados avCloud Director y se les podría asignar estas funciones con más privilegios. Por ejemplo, los usuariosque necesitan crear catálogos se podrían agregar al grupo "Autor de catálogo de la organización A" en elservidor 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 envCloud Director. Todo esto se consigue siguiendo las instrucciones relacionadas con la importación de ungrupo en la Guía del usuario de vCloud Director.

Seguridad de vCloud Director

VMware, Inc. 48

Lista de comprobación 7Esta lista de comprobación resume las tareas de configuración de seguridad de claves que se describenen 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 utilizandoel formulario de esa página. Los avisos de última hora y las instrucciones adicionales de seguridadrelacionadas 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 paraNSX-v 6.3.x (https://communities.vmware.com/docs/DOC-28142) para asegurarse de que disponende instalaciones seguras de dichos productos.

n Aplique las revisiones de seguridad actualizadas a la plataforma Linux de las celdas, la base dedatos de vCloud Director y la infraestructura virtual antes de la instalación; también es crucialsupervisar 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 delas celdas, incluidas la desactivación de los servicios de red innecesarios, la eliminación de lospaquetes innecesarios, la restricción del acceso raíz remoto y la aplicación de directivas decontraseñ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 delas celdas, pero no se recomienda hacerlo. La ampliación del acceso al sistema operativo de lasceldas podría significar una reducción de la seguridad.

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

VMware, Inc. 49

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

n El acceso físico y lógico a los servidores de vCloud Director debe limitarse exclusivamente a aquellosque necesiten iniciar sesión, y solo con los niveles mínimos de acceso necesarios. Esto implicalimitar el uso de la cuenta raíz mediante sudo y otras prácticas recomendadas. Las copias deseguridad de los servidores se deben proteger y cifrar de forma estricta con claves administradas demanera 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 delsoftware 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 datosde 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, lasinstancias de vCenter Server conectadas, la base de datos de vCloud Director, los firewalls y otrosdispositivos sigan los criterios estándar de complejidad de contraseña.

n Desde la perspectiva de defensa en profundidad, es importante modificar las contraseñasadministrativas de los distintos servidores del entorno de vCloud Director, incluidas las celdas, labase 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 loscertificados 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 elnombre 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 elFQDN del host donde esté instalada la celda.

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

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

Seguridad de vCloud Director

VMware, Inc. 50

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 depuerto configurado para los servicios expuestos. La red externa a la que se conectan estas redesVDC de la organización requeriría un firewall que la protegiera y que permitiera la entrada del tráficoacordado a esta red de la DMZ.

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

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 lasceldas.

n Para establecer la URL web pública, la dirección del proxy de la consola pública y la URL base de laAPI de REST pública para una nube de varias celdas que se encuentra detrás de un WAF o unequilibrador 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 permitala inspección y el bloqueo del tráfico malintencionado. Esto se suele hacer con la terminación de TLSo SSL.

n Al configurar la terminación de TLS o SSL, además de instalar un certificado firmado por la CA en elfirewall de aplicación web (WAF) para que las aplicaciones cliente de vCloud API y la consola webpuedan estar seguras de la identidad del servidor, también es importante utilizar un certificadofirmado 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 uncertificado 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 laadministración, vincule JMX directamente a esta dirección IP. De forma predeterminada, el conectorJMX de vCloud Director se vincula a las direcciones IP principales especificadas durante laconfiguración. Este comportamiento predeterminado se puede anular insertando la siguientepropiedad 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.

Seguridad de vCloud Director

VMware, Inc. 51

n La configuración recomendada y más segura consiste en vincular el conector JMX a la dirección dehost local: vcloud.cell.ip.management=127.0.0.1. Si JMX solo está expuesto al host local, sedeberá usar SSH como mecanismo de túnel para el acceso a JMX con el fin de proteger lascomunicaciones con este. Si los requisitos de administración no admiten este tipo de configuracióndel host local, y JMX debe estar expuesto fuera del servidor de vCloud Director, use TLS o SSL paraprotegerlo.

n Detrás de las celdas se encuentran los elementos de administración privada necesarios paravCloud Director: su base de datos, NSX, vCenter Server, el servidor LDAP del sistema (si existe), elservidor de Active Directory usado por vCenter y las interfaces de administración de los hosts devSphere. A sus conexiones las controlan exclusivamente los firewalls, ya que a esos servicios no sepuede 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, comoIDS/IPS, SIEM, administración de configuración, administración de revisiones, administración devulnerabilidades, antivirus y sistemas de administración de GRC, se aplicarán a vCloud Director ysus sistemas asociados, vSphere y sus sistemas asociados y a las redes y la infraestructura dealmacenamiento que les dan soporte.

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

n En este y otros escenarios, los grupos de recursos, las redes y los almacenes de datos debensepararse en distintos dominios de seguridad mediante el uso de VDC de proveedor diferentes enlos 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 unaorganización de tenants, se corre el riesgo de empeorar la calidad del servicio para otros tenants. Lacorrecta supervisión de los niveles de servicio es fundamental para evitar denegaciones de serviciocausadas por un tenant "ocupado", pero la seguridad no requiere que se separen los tenants engrupos de recursos individuales para alcanzar este objetivo.

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

n Para las comunicaciones que pasan por una red externa y que requieren protección deconfidencialidad (por ejemplo, una conexión de centro de datos de vApp a la empresa o un puentede vApp a vApp), se recomienda implementar una instancia de NSX Edge u otro dispositivo virtual deVPN 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 gruporespaldado por VXLAN, que admite muchas más redes que un grupo respaldado por VLAN y aplicael aislamiento a nivel de kernel de ESXi.

Seguridad de vCloud Director

VMware, Inc. 52

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

n Las máquinas virtuales nunca tienen acceso al almacenamiento fuera de sus VMDK, a menos quetengan conectividad de red con dichos sistemas de almacenamiento. En esta guía se recomiendaque no lo tengan; un proveedor puede proporcionar acceso al almacenamiento externo a las vAppcomo un servicio de red, pero este debe ser independiente de los LUN asignados a los hosts devSphere 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 redesde datos de las máquinas virtuales.

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

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

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

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

n Se puede configurar un servidor syslog durante la instalación. Se recomienda utilizar unainfraestructura de syslog que admita TLS. Se recomienda exportar los registros a un servidor syslogpor varias razones. Se recomienda que el servidor syslog se configure con redundancia, paraasegurar que los eventos esenciales se registren siempre. Las organizaciones de operaciones deseguridad y operaciones de TI también pueden beneficiarse de la agregación y la administracióncentralizadas de los registros de diagnóstico. Le recomendamos que utilice logrotate u otrosmétodos similares para controlar el tamaño de los registros y el número de archivos de registroantiguos que se conservan.

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

Seguridad de vCloud Director

VMware, Inc. 53

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

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

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

n Otra preocupación que surge cuando la organización aloja su propio servidor LDAP es la exposiciónfuera de la DMZ. No se trata de un servicio al que puede acceder el público general, por lo que hayque realizar ciertos pasos para limitar el acceso solo a las celdas de vCloud Director. La forma mássencilla de hacerlo es configurar el servidor LDAP o el firewall externo para permitir el acceso solodesde 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í comogarantizar que los nombres de organización que asigne a los tenants nunca serán muy parecidos alnombre de otra.

n vCloud Director se debe configurar para conectarse a los servidores LDAP a través de SSL con el finde proteger adecuadamente las contraseñas que se comprueban en dichos servidores. Al configurarLDAP 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 suscontraseñas.

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

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

Seguridad de vCloud Director

VMware, Inc. 54