Documento técnico: Mejores prácticas de seguridad para Citrix Virtual Apps and Desktops

Descargo de responsabilidad: Esta información se proporciona “TAL CUAL” sin garantía de ningún tipo. Es solo con fines informativos y está sujeto a cambios en cualquier momento a criterio exclusivo de Citrix.

Introducción

Las organizaciones globales, incluidos los servicios de salud, gubernamentales y financieros, confían en Citrix Virtual Apps and Desktops (CVAD) para proporcionar acceso remoto seguro a entornos y aplicaciones. Cuando se configura correctamente, CVAD puede proporcionar medidas de seguridad que van mucho más allá de lo que está disponible de forma nativa en los sistemas operativos empresariales. Citrix proporciona controles adicionales que se habilitan mediante la virtualización.

Este documento técnico comparte recomendaciones y recursos para ayudarlo a establecer una base de seguridad para su entorno virtualizado. Destacamos algunas de las mejoras de seguridad más importantes que puede realizar. Pruebe siempre cambios como estos en un entorno de prueba o desarrollo antes de modificar el entorno de producción. Las pruebas pueden ayudarle a evitar problemas o resultados inesperados.

Este documento técnico utiliza la metodología tradicional en capas desarrollada por los servicios profesionales de Citrix:

Enfoque por

En el modelo por capas de Citrix, la seguridad no tiene su propia capa. Cualquier proceso de seguridad o funcionalidad de seguridad está entrelazado entre las capas. Es fundamental que la seguridad esté cubierta en toda la infraestructura, incluidos los procesos que la rodean.

¿Es necesario que una organización cumpla con estándares de seguridad específicos para cumplir con los requisitos reglamentarios? Este documento no cubre ese tema, porque dichos estándares de seguridad cambian con el tiempo. Para obtener información actualizada sobre los estándares de seguridad y los productos Citrix, visite Security and Compliance Information y Citrix Trust Center.

Capa de usuarios y dispositivos

¿Cómo permite una empresa que sus usuarios finales se conecten a equipos de escritorio virtuales? Hay disponibles opciones como Bring Your Own Device (BYOD) o dispositivos emitidos por la empresa. Ambos vienen con sus propios gastos operativos. El modelo de entrega de puntos finales puede tener muchas implicaciones de diseño, incluidas decisiones sobre qué funciones se pueden descargar al dispositivo de punto final. Es posible que un usuario que se conecte desde un dispositivo BYOD no tenga acceso al portapapeles, la asignación de unidades del cliente (CDM) o la impresión. Un usuario que se conecte desde un dispositivo corporativo “de confianza” puede tener acceso al portapapeles y a las unidades locales. No existe una “talla única” para los dispositivos de punto final. Los clientes de terminales deben seleccionarse en función del caso de uso, la movilidad, el rendimiento, el coste y los requisitos de seguridad

Bloqueo de dispositivos

El dispositivo de punto final tiene el potencial de usarse como vector de ataque, incluidos ataques como registradores de pulsaciones o puntos de entrada a la red. La ventaja de usar Citrix es la reducción de los puntos de entrada al actualizar el ratón, el teclado y la pantalla. Los usuarios pueden necesitar más funciones, como acceder a las unidades de cliente locales, las instalaciones de impresión y la funcionalidad del portapapeles. Esa funcionalidad se puede configurar mediante directivas de Citrix. Citrix tiene los controles para reducir el riesgo de vectores de ataque, como la protección contra el registro de tecleo y la desactivación de cualquier punto de entrada y salida.

Todas estas preguntas deben tener en cuenta los equipos de soporte de TI al implementar dispositivos para los usuarios finales.

  • ¿Los usuarios requieren permisos administrativos locales en el dispositivo?
  • ¿Qué otro software se ejecuta en el punto final? ¿Se puede instalar otro software?
  • ¿El usuario tiene capacidad de VPN?
  • ¿Quién actualiza el dispositivo en términos de parches del sistema operativo y de las aplicaciones?
  • ¿A qué recursos puede acceder el punto final?
  • ¿Quién tiene acceso al punto final en sí?

Registro de endpoints

Incluso si un usuario no puede instalar software en el punto final, asegúrese de que los registros estén habilitados y capturados de forma centralizada. Los registros pueden ayudarle a entender qué ocurrió en una infracción. También se pueden entregar a analistas forenses para que los revisen más a fondo. El registro es un elemento crucial para cualquier entorno y sus procesos de supervisión de seguridad. También es una buena práctica reenviar todos los registros a un sistema de administración de eventos e información de seguridad (SIEM). Este detalle le permite establecer alertas para métodos de ataque conocidos u otros eventos clave.

Al igual que con cualquier tipo de recopilación de datos, es importante no solo recopilar datos, sino también poder analizarlos. Es fácil sentirse abrumado por la cantidad de datos informados. Asegúrese de que puede detectar y responder a una posible alerta.

terminales Thin Client

En muchos casos, los dispositivos de cliente ligero son perfectos para entornos de alto riesgo. Los clientes ligeros ejecutan una versión especializada de un sistema operativo y solo tienen un sistema operativo y una aplicación suficientes para conectarse a una sesión de Citrix. En este caso, existen ventajas en torno a la aplicación de parches. Con los clientes ligeros, hay aplicaciones limitadas que se deben aplicar parches y mantener. Por lo general, los sistemas operativos ocupan poco espacio. Debido a que los dispositivos tienen un sistema operativo simplificado y especialmente diseñado, hay datos limitados en reposo en el punto final.

Para los terminales de cliente ligero que ejecutan un sistema operativo completo, resulta útil el uso de filtros de escritura para detener la persistencia de los datos. El restablecimiento de los terminales cuando se produce un reinicio reduce la posibilidad de que un atacante conserve datos en el punto final que se pueden utilizar para formular un ataque. Asegúrese de no destruir registros y otros datos críticos, ya que son necesarios para un análisis forense posterior. Los terminales Thin Client tienen la ventaja adicional de ser, por lo general, más baratos de comprar y mantener que los equipos de escritorio o portátiles tradicionales

Aplicación de parches

La administración de parches debe ser una de las principales consideraciones a tener en cuenta a la hora de elegir un punto final. ¿Cómo aplica la empresa las correcciones de seguridad a los puntos finales? En la mayoría de los entornos Windows tradicionales, las máquinas reciben parches mediante Windows Services Update Service (WSUS), System Center Configuration Manager (SCCM) u otros servicios automatizados. Estos servicios son excelentes si la TI corporativa administra el punto final.

¿Qué pasa con BYOD? ¿Quién repara esos dispositivos para asegurarse de que estén actualizados? Con el rápido crecimiento del trabajo desde casa, la aplicación de parches para endpoints se vuelve más complicada. Las directivas deben definirse con responsabilidades claras para el usuario. La directiva es necesaria para garantizar que los usuarios sepan cómo aplicar parches y actualizar sus dispositivos. Un método consiste en notificaciones simples en la página de inicio de sesión que sugieren que se ha lanzado una nueva actualización y que se deben aplicar parches lo antes posible. También puede usar Endpoint Analysis Scans (EPA) en el punto final para denegar el acceso a la infraestructura, a menos que estén ejecutando software actualizado.

También es importante asegurarse de que la aplicación Citrix Workspace esté parcheada y actualizada en el dispositivo de punto final. Citrix no solo ofrece mejoras de funciones, sino también correcciones de seguridad en las nuevas versiones.

Directivas de protección de aplicaciones

El usuario final es ampliamente considerado la pieza más débil en la superficie de ataque de una organización. Se ha convertido en una práctica común para los atacantes utilizar métodos sofisticados para engañar a los usuarios para que instalen malware en sus dispositivos de punto final. Una vez instalado, el malware puede recopilar y filtrar datos confidenciales de forma silenciosa.
Se seleccionan las credenciales del usuario, la información confidencial, la propiedad intelectual de la empresa o los datos confidenciales. Los puntos finales se convierten en una superficie de amenaza aún más expuesta con el aumento de los dispositivos BYO. Y al acceder a los recursos corporativos desde puntos finales no gestionados. Con muchos usuarios trabajando desde casa, el riesgo para las organizaciones aumenta debido a la falta de fiabilidad del dispositivo de punto final.

Con el uso de aplicaciones y escritorios virtuales, se ha reducido considerablemente la superficie de ataque de los puntos finales. Los datos se almacenan de forma centralizada en un centro de datos y es mucho más difícil para el atacante robarlos. La sesión virtual no se está ejecutando en el dispositivo de punto final y los usuarios generalmente no tienen permiso para instalar aplicaciones dentro de la sesión virtual. Los datos de la sesión son seguros en el centro de datos o en la ubicación de recursos en la nube. Sin embargo, un extremo comprometido puede capturar pulsaciones de teclas de sesión e información mostrada en el dispositivo de punto final. Citrix ofrece a los administradores la capacidad de prevenir estos vectores de ataque mediante una función complementaria denominada Protección de aplicaciones. La función permite a los administradores de CVAD aplicar directivas específicamente en uno o más grupos de entrega. Cuando los usuarios se conectan a sesiones desde estos grupos de entrega, el dispositivo de punto final del usuario tiene una captura anti pantalla o anti-registro de teclas, o ambos se aplican en los dispositivos de punto final.

Puede encontrar más información en el resumen técnico de las directivas de protección de aplicaciones.

Gestión de cuentas

A través de la capa de usuarios y dispositivos, se ha centrado principalmente en la seguridad de los dispositivos. Cosas como los procesos de creación de cuentas de usuario y autorización de asignación de recursos deben estar centralizados y gestionados de manera eficiente. Muchas veces, las cuentas simplemente se “copian” de usuarios con roles similares. Puede acelerar la incorporación, pero crea problemas en términos de permisos y membresías de grupos no autorizadas dentro del directorio central. Copiar los permisos de un usuario de una cuenta anterior también puede dar lugar a un acceso no autorizado a los datos. Idealmente, el propietario de los datos debe autorizar cualquier solicitud de grupo antes de permitir el acceso.

El desmantelamiento de cuentas puede ser sencillo si se integra correctamente con los sistemas de recursos humanos. A veces, las empresas necesitan incorporar y retirar recursos de terceros. Cuentas de proveedores y soporte adicional para los períodos de mayor actividad y cuando se subcontratan negocios. ¿Cómo se retiran esas cuentas y, en última instancia, se eliminan? En el mejor de los casos, la empresa tiene procedimientos claramente definidos tanto para la incorporación como para la baja de cualquier recurso de contratación. Completar la baja antes de las fechas de finalización establecidas en un mínimo, inhabilitar la cuenta y pasar a una “UO de retención” dentro de Active Directory. Luego, debe eliminarse cuando se confirme que el recurso ya no es necesario. En última instancia, no queremos que los contratistas inicien sesión meses después de haber dejado el negocio.

Capa de acceso

Dentro del proceso de diseño de Citrix, la capa de acceso es donde los usuarios se autentican. Aquí se aplican las directivas necesarias y se evalúa el acceso dinámico basado en el contexto. El nivel de acceso está diseñado teniendo en cuenta un alto nivel de seguridad y es fundamental.

En la siguiente sección, nuestro objetivo es cubrir las tareas principales para ayudar a proteger mejor la implementación de Citrix ADC. Hay dos tipos de implementación comunes para los ADC de Citrix. Una forma es usar el ADC como proxy para las implementaciones de CVAD. La otra forma es que las aplicaciones de balanceo de carga estén más disponibles y sean más seguras. Seguir los detalles incluidos en este documento ayuda a reducir el riesgo y la exposición a los elementos con los que interactúa Citrix ADC.

Autentificación sólida

Se recomienda una autenticación sólida para todas las conexiones externas a cualquier sistema interno. Desafortunadamente, hay una gran cantidad de nombres de usuario y contraseñas que los atacantes pueden buscar. Son de filtraciones y filtraciones pasadas, con más de 12 300 millones de registros. Este número aumenta los riesgos de una brecha en su empresa, a medida que haya más disponibles. La reutilización de una contraseña es común en casi todo el mundo, y su empresa puede estar en riesgo debido a los malos hábitos de contraseña de sus usuarios. Un nombre de usuario y una contraseña no deben ser la única defensa para sus aplicaciones. No debe confiar intrínsecamente en las personas con solo dos datos que pueden ser robados fácilmente. Agregar la autenticación multifactor a todas las aplicaciones no siempre es posible con el flujo de trabajo del usuario, pero recomendamos implementarla siempre que sea posible, especialmente para el acceso externo.

Puede encontrar más información en la documentación del producto.

Cifrado HDX

Ha sido un estándar desde hace mucho tiempo para habilitar RC5: 128 bits como cifrado de seguridad para la transmisión HDX/ICA. Proporciona un nivel de seguridad en la transmisión ICA. Se recomienda habilitar SSL de VDA en la transmisión ICA entre el dispositivo de punto final y el VDA. Habilite SSL entre el ADC y el VDA un nivel adicional de cifrado. La configuración vincula un certificado al servicio Desktop. Cifra el flujo ICA según el estándar dado del certificado enlazado. Para obtener más información sobre cómo llevar a cabo este proceso, lea CTX220062.

Cifrados SSL/TLS

Validar los cifrados de seguridad de la capa de transporte (TLS) y la puntuación SSL para todos los VIP externos (Citrix Gateway). Ha habido muchas vulnerabilidades en los protocolos SSL y TLS en los últimos años. Asegúrese de utilizar todas las prácticas recomendadas de TLS, ya que cambian constantemente. Asegúrese de que los protocolos más antiguos, como SSLv3, TLS 1.0 y TLS 1.1, estén inhabilitados.

La elección entre un certificado Wildcard o SAN es otro aspecto de este proceso. Los comodines pueden ser rentables, pero también pueden ser más complicados. La caducidad de los certificados tiene un gran impacto en las implementaciones con una gran cantidad de hosts. Sin embargo, un certificado SAN puede ser efectivamente un comodín restringido para solo 2 a 5 sitios. Todo ello con la capacidad de usar más de un TLD en el mismo certificado.

Lea las prácticas recomendadas de SSL/TLS para redes de Citrix para obtener las recomendaciones más recientes.

Cifrado de XML

Asegúrese de que el tráfico XML del Delivery Controller o Cloud Connector a los servidores StoreFront esté siempre cifrado. El propósito es evitar que alguien con acceso simple a la red vea lo que solicitan los usuarios. Se requieren certificados para cada servidor, además de cambiar la configuración de cada servidor para usar el nuevo puerto cifrado (por defecto, el puerto 443). Puede encontrar más información en la documentación del producto.

Recomendación de alta seguridad: Para una implementación de alta seguridad, se recomienda usar puertos no estándar para la ofuscación. Asegúrese también de que haya firewalls configurados entre las funciones del servidor para que el tráfico XML controle el tráfico bidireccionalmente.

SSL de StoreFront

Recomendamos encarecidamente usar una URL base cifrada para cualquier implementación de StoreFront. El cifrado garantiza que ni las credenciales ni los datos de inicio de sesión atraviesen una red sin protección de transporte. En la mayoría de las implementaciones, el certificado se puede emitir desde una entidad emisora de certificados interna. Estos servidores están detrás de una implementación de Citrix ADC como parte de la configuración del perfil ICA para un dispositivo Citrix Gateway para dispositivos externos. O están detrás de una VIP de Citrix ADC a la que normalmente solo se accede desde dispositivos internos. Garantice el uso de cifrados seguros y TLS 1.1 o 1.2 para la comunicación con el servidor. Los detalles de este proceso se describen en la documentación de Microsoft.

Recomendación de alta seguridad: En implementaciones de alta seguridad, recomendamos habilitar la firma de archivos ICA para garantizar que los archivos recibidos por la aplicación Citrix Workspace sean de confianza. Este proceso se describe en la documentación del producto StoreFront.

Cifrado de VDA

El cifrado de VDA suele ser uno de los últimos elementos configurados para aumentar la seguridad del transporte de sesiones. La configuración se completa en el VDA y en los objetos del grupo de entrega.

Recomendación de alta seguridad: En implementaciones de alta seguridad, recomendamos habilitar el cifrado de VDA para proteger aún más el transporte de la información de la sesión de Citrix. El uso de un script de PowerShell es el método más simple y el proceso se describe en la documentación del producto.

Controlar el acceso físico

Los dispositivos Citrix ADC deben implementarse en una ubicación segura con suficiente control de acceso físico para protegerlos del acceso no autorizado. Este requisito se aplica a los modelos físicos y sus puertos COM. También se aplica a los modelos virtuales en hosts de virtualización y sus conexiones ILO/DRAC asociadas. Encuentre más información en la documentación del producto Citrix ADC: prácticas recomendadas de seguridad física.

Cambiar contraseñas predeterminadas

Tener cualquier contraseña predeterminada conocida por la comunidad de TI es un riesgo enorme. Hay escáneres de red que pueden buscar las credenciales predeterminadas que se utilizan en una red determinada. La eficacia de estos escáneres se puede mitigar o incluso eliminar fácilmente con solo cambiar la contraseña predeterminada. Todas las contraseñas de las cuentas de servicio deben almacenarse en una ubicación segura, como un administrador de contraseñas. El almacenamiento seguro de todas las contraseñas de cuentas de servicio es un estándar fundamental de seguridad de la información. La contraseña de cada rol e implementación (par HA) debe ser única y las credenciales no deben volver a utilizarse nunca. Para obtener más información, consulte la documentación del producto Citrix ADC: Cambiar las contraseñas predeterminadas.

  • nsroot: Cambia el valor predeterminado al iniciar la configuración inicial del dispositivo. Esta cuenta permite el acceso administrativo total y la protección de esta contraseña debe ser la prioridad número uno al implementar este sistema. Si va a implementar un nuevo sistema Citrix ADC en 2020, tendrá el número de serie del dispositivo como contraseña predeterminada.
    • Cree un segundo superusuario que pueda usarse en situaciones de emergencia cuando la autenticación externa no esté activa. Usa esta cuenta en lugar de usar la cuenta nsroot predeterminada. Obtenga más información en la documentación del producto Citrix ADC: Crear una cuenta de superusuario alternativa
    • Los usuarios de SDX también deben crear un perfil administrativo para configurar la contraseña de administrador predeterminada para cada instancia VPX aprovisionada. Recomendamos crear un perfil de administrador diferente para cada instancia. Cada par de HA tiene la misma contraseña, pero es exclusiva de las demás instancias. Encuentre más información en el artículo CTX215678 de la base de conocimientos
  • Lights on Management (LOM): Esta cuenta es común en muchas plataformas físicas de Citrix ADC. Permite el acceso a la línea de comandos y la administración de energía del dispositivo. También tiene contraseñas predeterminadas que se deben cambiar en la configuración inicial para evitar el acceso remoto no autorizado.
  • Contraseña de clave de cifrado de clave (KEK): Esta configuración cifra las áreas de contraseñas confidenciales de forma local en cada dispositivo. Encontrará más información en el capítulo KEK.
  • Cuenta de administrador de SVM: Este cambio de cuenta y contraseña solo se aplica a las plataformas Citrix ADC SDX. Tiene la contraseña nsroot predeterminada y no utiliza el número de serie como los dispositivos físicos. La contraseña debe cambiarse en su configuración inicial para evitar el acceso remoto no autorizado.

Proteja el tráfico NSIP desde todos los accesos a

Se debe denegar a todos los dispositivos de la red la capacidad de administrar sus dispositivos Citrix ADC. Las direcciones IP de administración deben estar en una VLAN donde usted controle el tráfico de entrada y salida. Esta configuración garantiza que solo las estaciones de trabajo con privilegios autorizados u otras redes autorizadas puedan acceder a ellas para su administración. Muchas de las vulnerabilidades que se han encontrado en los últimos 10 años se han relacionado con el acceso a los NSIP. Al asegurar estas IP de manera controlada, puede reducir drásticamente este vector de ataque o eliminarlo por completo. Siempre que limite el acceso a la administración de cualquier sistema de TI, debe documentarlo minuciosamente.
Es mejor contar con planes de continuidad del negocio para que entiendas claramente el impacto.

  • Asegúrese de que las IP de subred (SNIP) y las IP asignadas (MIP) no tengan habilitada la administración. Si se habilita la administración, su red DMZ tendrá acceso a la consola de administración a través del SNIP o MIP.
  • Para comprobarlo, vaya a su SNIP o MIP a través de HTTP y HTTPS. En la consola, vaya a Sistema — Red — IP, seleccione la IP y verá si la casilla de administración está seleccionada.
  • También puede usar las listas de control de acceso para limitar el acceso a la administración del dispositivo ADC. La limitación a hosts o subredes específicos se puede hacer sin que la interfaz de administración se coloque detrás de un firewall. Puede encontrar más información en CTX228148 - Cómo bloquear interfaces de administración de Citrix ADC con ACL y documentación del producto Citrix ADC - Seguridad de red.
  • Si coloca sus ADC de Citrix detrás de un cortafuegos, debe planificar de acuerdo con los servicios que proporciona el dispositivo. Planifique también el acceso a la interfaz de administración de cada dispositivo. También planifique cualquier dispositivo de mantenimiento o seguridad de apoyo, como NetScaler Application Delivery Management (ADM) y Citrix Analytics. Puede encontrar más información en Communication Ports Used by Citrix Technologies) y CTX113250: Sample DMZ Configuration.
  • En implementaciones de mayor seguridad, también puede cambiar los puertos de administración de HTTP (TCP 80) y HTTPS (TCP 443) predeterminados. Cámbielos a un puerto personalizado para crear ofuscación y ayudar a evitar la identificación en exploraciones típicas. Cada dispositivo debe cambiarse de forma individual. Puede encontrar más información en la documentación del producto Citrix ADC.
  • Limite todo el tráfico Egress (saliente) e Ingress (entrante) de las redes de administración en las que se implementa Citrix ADC. No tener restricciones junto con la supervisión de estas redes de administración aumenta el riesgo para ese dispositivo. Con dispositivos críticos como un Citrix ADC, la administración debe restringirse a estaciones de trabajo con privilegios específicos para reducir el riesgo de posibles ataques. Controle el acceso externo para detener o retrasar el acceso de cualquier atacante a otros dispositivos. Impida que los atacantes accedan al software de comando y control alojado fuera de su red.
  • Mantenga todos los NISIP, LOM y SVM e IP de administración de Citrix ADC separados de otros equipos de red. Según los estándares de su directiva, coloque las LOM en redes de administración físicas y fuera de banda con otros sistemas similares. Coloque los NSIP y las SVM en otra red independiente. El uso de una VLAN solo para las IP de administración de Citrix ADC puede simplificar las reglas de firewall y ACL. Limite el acceso interno a una estación de trabajo privilegiada y restrinja el acceso externo.

Enlazar Citrix ADC a LDAPS

No recomendamos usar cuentas de inicio de sesión genéricas para la administración diaria. Cuando en un equipo de TI nsroot realiza todos los cambios de configuración, no podrá realizar un seguimiento de quién inició sesión y realizó un cambio en particular. Una vez que se haya cambiado la contraseña de la cuenta nsroot, el sistema debe vincularse inmediatamente a LDAPS para realizar un seguimiento del uso de una cuenta de usuario específica. Este paso proporciona control delegado para que pueda crear grupos de solo visualización para los equipos de auditoría y aplicación. A continuación, puede conceder derechos de administrador completos a grupos de AD específicos. No recomendamos la vinculación mediante LDAP sin cifrar, ya que las credenciales se pueden recopilar con capturas de paquetes. Puede encontrar más información en CTX212422

Si está enlazando con Microsoft Active Directory, asegúrese de que solo utiliza LDAPS como protocolo. Además, asegúrese de que NTLMv2 sea el único método de hash para las credenciales y las sesiones de red. Este paso es una práctica recomendada de seguridad de AD. Garantiza que las credenciales estén lo más protegidas posible durante el tránsito para las solicitudes de autenticación y las sesiones de red. Pruebe correctamente esta configuración y realice la validación con clientes de Windows anteriores para identificar problemas de compatibilidad con versiones anteriores de Windows.

Al vincular a cualquier fuente de autenticación externa, debe inhabilitar la autenticación local para cuentas como nsroot. De manera opcional, solo habilite cuentas locales específicas para usar la autenticación local. Dependiendo de sus requisitos de implementación, puede requerir una ruta u otra. La mayoría de las implementaciones no requieren cuentas locales. Si se necesita una cuenta de servicio, puede crear y delegar un usuario de LDAP. Esta guía cubre la configuración de ambos métodos, se debe implementar un método.

Registro y alertas

La práctica de reenvío de Syslog es fundamental para proporcionar respuesta a incidentes junto con una solución de problemas más avanzada. Estos registros le permiten ver los intentos de inicio de sesión en el ADC. Citrix Gateway puede realizar acciones que se basan en directivas de operaciones de paquetes y sistemas, tales como:

  • Bloqueo de GeoIP y BAdIP
  • Protección AppQoE
  • Acciones de directivas de respuesta

Esta información puede ser muy valiosa para solucionar problemas. Este detalle le ayuda a comprender una posible situación de ataque actual. Ayuda a determinar la mejor manera de reaccionar en función de datos procesables para resolver problemas, detener o mitigar un ataque. Sin un destino de Syslog configurado en su Citrix ADC, se eliminan los registros necesarios para ahorrar espacio y que el sistema siga funcionando. Puede encontrar más información en la documentación del producto Citrix ADC: Registro y supervisión.

Hay muchos servidores y recopiladores de Syslog gratuitos y de pago disponibles. Algunos tienen un precio según la cantidad de mensajes por día, el espacio de almacenamiento de los mensajes o simplemente son una suscripción continua. Estas soluciones deben planificarse, ya que requieren que se asigne una cantidad considerable de espacio de almacenamiento. El tamaño del servidor o recopilador de Syslog debe basarse en la cantidad de eventos de otros servicios críticos. Estos servicios incluyen Active Directory, bases de datos y servidores de archivos, VDA y otros servidores de aplicaciones.

Citrix ofrece el servicio Citrix ADM como recopilador de Syslog. Citrix ADM puede permitirle tener cierta retención fuera del dispositivo. Citrix ADM también es una excelente herramienta para poder buscar y ver estos registros y usar sus paneles de eventos. Hay muchas vistas predeterminadas excelentes de los datos de registro para ayudarlo a solucionar problemas, ver el hardware, los problemas de autenticación, los cambios de configuración y mucho más. Puede encontrar más información en la documentación del producto Citrix ADM: Configuración de syslog en instancias y Ver y exportar mensajes de syslog.

Recomendamos encarecidamente utilizar esta lista de mensajes para crear sus alertas en función de las funciones de Citrix ADC que esté utilizando. El solo hecho de que los registros se conserven y se puedan buscar es valioso para solucionar problemas y auditar los eventos de seguridad. Es importante asegurarse de que envía alertas en función del umbral de inicios de sesión incorrectos junto con cualquier inicio de sesión con nsroot las cuentas predeterminadas. Puede encontrar más información en Developer Docs - Syslog Message Reference.

Configure SNMP en su solución de supervisión para asegurarse de que tiene habilitada la supervisión a nivel físico y de servicio. Esta configuración garantiza el servicio y el funcionamiento del aparato. La configuración del correo electrónico permite que las notificaciones del sistema se envíen al buzón correspondiente. Este paso también le permite recibir notificaciones de certificados que vencen y otras notificaciones.

Planificar servicios para supervisar y proteger

Tomarse el tiempo para planificar qué servicios usar en su Citrix ADC le ayuda a comprender qué funciones se pueden aplicar a esas direcciones IP. Es una gran oportunidad para validar si tiene IP asignadas para realizar pruebas. Valide siempre todos los ajustes de seguridad de un VIP de prueba antes de aplicar el respondedor y otras directivas a su VIP de producción. Este paso puede requerir más registros DNS, certificados SSL, direcciones IP y otras configuraciones para que funcione.

Los tres casos de uso más comunes de Citrix ADC son el equilibrio de carga, el equilibrio de carga de servidor global y Citrix Gateway.

Recomendamos organizar todos los VIP planificados por Internos o Externos. Es posible que los VIP internos no requieran todas las funciones de seguridad necesarias para los VIP externos. Evaluar qué países necesitan acceder a recursos externos es un buen paso de planificación si planea utilizar las funciones de GeoIP. Reúnase con el liderazgo empresarial y los propietarios de aplicaciones para saber si necesita restringir ciertos países.

Si es posible, implemente Citrix ADM antes de empezar a hacer cambios en la configuración. Citrix ADM puede realizar fácilmente copias de seguridad de los dispositivos con regularidad y proporcionar una mejor visibilidad de los registros junto con las métricas. Se pueden agregar otras funciones más avanzadas a una implementación de Citrix ADC para proporcionar aún más visibilidad y seguridad. Citrix ADM tiene ediciones de pago junto con Citrix Analytics que pueden ir más allá de una simple solución de supervisión. Podemos convertirnos en un sistema de respuesta de seguridad automático.

Reemplazar los certificados SSL predeterminados

Los navegadores modernos le advierten que un certificado no es válido y supondrá un riesgo para la seguridad si es el certificado predeterminado. Si reconoce este error todos los días, es susceptible a un verdadero ataque de intermediario. Alguien puede leer lo que escribes a medida que escribes porque puede entrar en la transmisión TLS. Reemplazar el certificado puede ser fácil en función de si aloja su propia entidad de certificación interna, utiliza un servicio de terceros (posible coste asociado) o certificados autofirmados. Una vez que haya actualizado los certificados, su explorador debe confiar en el nuevo certificado y no debe generar errores al acceder al dispositivo. Si vuelve a aparecer un error de certificado, debe comprobar la fecha de caducidad. Es posible que lo hayan reemplazado sin su conocimiento.

  • NSIP: Primero se debe cambiar este certificado, ya que es donde se lleva a cabo toda la administración del dispositivo. Este proceso debe completarse en cada dispositivo. Puede encontrar más información en CTX122521.
  • LOM: Cambiar estos certificados debe ser el siguiente objetivo una vez que los certificados de administración de NSIP hayan cambiado de los predeterminados. Este proceso debe completarse en cada dispositivo. Puede encontrar más información en la documentación del producto.
  • SDX SVM: Si es cliente de SDX, asegúrese de que se haya reemplazado el certificado predeterminado. El SDX SVM se convierte en el método principal de administración de dispositivos, junto con la administración de las propias instancias. Este proceso también debe completarse en cada aparato. Puede encontrar más información en CTX200284.

Actualización de firmware

  1. Implementación inicial: Utilice la última versión de firmware disponible para cada plataforma Citrix ADC. Asegúrese de revisar las notas de la versión para ver si hay algún “problema conocido” que pueda afectarle. La metodología N-1 se usa a menudo para mantenerse una versión por detrás de la última versión. Las actualizaciones de firmware se realizan en cada instancia independientemente de la plataforma que utilice, ya sea CPX, MPX, SDX o VPX.
  2. Actualizaciones de firmware LOM\IPMI: Recomendamos que el firmware se actualice en el momento de la implementación. Las actualizaciones garantizan que disponga de las últimas funciones y correcciones. Puede encontrar más detalles aquí en la documentación del producto.
  3. Actualizaciones continuas: Regístrese para recibir alertas de los boletines de seguridad de Citrix y notificaciones de actualizaciones para Citrix ADC, Citrix ADM y Citrix Web Application Firewall.

Planifique la frecuencia con la que decide actualizar los ADC de Citrix cada año. Las funciones implementadas y las directivas de la organización de TI deben determinar cómo se programan estas actualizaciones. Por lo general, vemos actualizaciones que se publican de 2 a 4 veces al año. También incluye dos actualizaciones de funciones y dos actualizaciones que abordan problemas conocidos y correcciones de seguridad. Hay guías disponibles para ayudarlo a planificar y programar estas actualizaciones sin interrupción del servicio. También se puede aplicar a otros sistemas de soporte como Citrix ADM, ya que siempre se recomienda la paridad de versiones. Más información sobre cómo actualizar un par de alta disponibilidad.

Protección de datos con KEK

Al crear un par de claves KEK, puede obtener una mayor protección de datos. Recomendamos encarecidamente realizar este paso en cada dispositivo. El par de claves cifra la configuración en las áreas clave relacionadas con las contraseñas. Si alguien obtiene acceso a su archivo ns.conf, no podrá obtener ninguna credencial o contraseña del mismo como resultado. Los dos archivos clave que se encuentran en la raíz de la \flash\nsconfig\ carpeta deben considerarse altamente confidenciales y deben protegerse en consecuencia con copias de seguridad con la seguridad adecuada.

Esta advertencia significa que las migraciones de un dispositivo a otro requieren más pasos. La clave KEK debe agregarse a la nueva implementación antes de poder descifrar la configuración. Obtenga más información sobre cómo crear una clave maestra para la protección de datos (busque una cadena KEK).

Descartar paquetes no válidos

Todos los días se envían muchos paquetes no válidos a su dispositivo Citrix ADC. Algunos son benignos, pero la mayoría se utilizan con fines de toma de huellas digitales junto con ataques basados en protocolos. Al habilitar esta función, se ahorran recursos de CPU y memoria en el dispositivo. Prevenga la mayoría de los ataques de protocolo conocidos al no enviar un paquete parcial o defectuoso a la aplicación de back-end a la que se dirige el ADC. Este paso puede incluso bloquear posibles ataques futuros que dependan de la manipulación de paquetes.

Puede encontrar más información en la documentación del productoCTX227979 y CTX121149.

Seguridad de transporte estricta de HTTP

Asegúrese de que el HSTS esté configurado en todos los VIP de SSL. El objetivo principal de HTTP Strict Transport Security es proteger las aplicaciones de varios métodos de ataque, como los ataques de degradación, el secuestro de cookies y la eliminación de SSL. Es similar a Descartar paquetes no válidos, pero se basa tanto en HTTP como en HTTPS. Esto se basa en los estándares que se encuentran en RFC 6797 mediante el uso de una entrada en el encabezado HTTP. Esto agrega otra capa de defensa a cualquier aplicación detrás de Citrix ADC.

Capa de recursos

Los recursos que alojan la sesión de usuario pueden presentar un mayor nivel de riesgo de riesgo. Un usuario que ejecuta una sesión de VDI es similar a un equipo que está conectado a la red corporativa. El uso de capas de acceso y control bien diseñadas permite a la empresa avanzar hacia modelos de confianza cero. Con la confianza cero, el acceso se ajusta dinámicamente a los recursos presentados al usuario final en función de un conjunto determinado de variables. La siguiente guía proporciona niveles más altos de control para proteger los activos corporativos de los usuarios.

Construir endurecimiento

El fortalecimiento de las compilaciones del sistema operativo puede ser complejo y difícil de lograr. Viene con las compensaciones entre la experiencia del usuario, la usabilidad y la seguridad, todo un buen equilibrio. Muchos clientes optan por seguir las líneas base del Centro para la Seguridad de Internet (CIS) para reforzar las máquinas virtuales en diferentes roles. Microsoft también proporciona guías de refuerzo para cargas de trabajo similares. Incluso hay archivos ADMX para implementar directamente en la directiva de grupo. Si elige esta ruta, proceda con precaución. Asegúrese de realizar primero pruebas exhaustivas si las directivas iniciales son demasiado restrictivas. Estas líneas de base son un excelente punto de partida para el endurecimiento. Sin embargo, no pretenden ser exhaustivos para todos los casos. La clave para el bloqueo es realizar pruebas exhaustivas y fomentar la participación de terceros en las pruebas de penetración. Las pruebas validan sus controles de seguridad y su eficacia frente a los métodos de ataque más recientes.

Como parte del fortalecimiento del sistema, recomendamos que los administradores dediquen algún tiempo a optimizar los sistemas operativos, los servicios y las tareas programadas subyacentes. Este paso elimina cualquier proceso innecesario de los sistemas subyacentes. También mejora la capacidad de respuesta del host de la sesión y proporciona una experiencia de usuario mejorada al usuario final. Citrix proporciona la herramienta optimizadora Citrix Optimizer que optimiza muchos elementos del sistema operativo automáticamente para los administradores. Los resultados de Citrix Optimizer se ajustan para garantizar que no haya un impacto negativo en su entorno.

Tareas programadas

En algunos casos, necesitamos utilizar tareas programadas para realizar un mantenimiento de rutina o para resolver un problema continuo en el entorno. Si en el caso de que necesitemos utilizar tareas programadas, hay algunas recomendaciones que deben tenerse en cuenta de antemano.

Cuentas con privilegios: Siempre que sea posible, asegúrese de que las tareas programadas estén configuradas con cuentas que tengan los permisos correctos para lo que deben hacer. La ejecución de tareas programadas con credenciales de administrador de dominio, por ejemplo, no es una práctica recomendada.

Alternativas: Puede ser que una tarea programada se esté utilizando como “un parche temporal” sobre un tema más amplio. ¿Hay alguna forma mejor que usar una tarea programada para solucionar el problema? Es posible que resuelva un problema temporal, pero corrija la causa de la ruta en lugar de dejar en ejecución una tarea programada. Esto es especialmente cierto con las actualizaciones de imágenes, ya que existe la posibilidad de que no se haya documentado o incorporado en los procedimientos de compilación. Se perderá en futuras actualizaciones y podría causar más problemas.

Aplicación de parches y actualizaciones

Garantizar que los sistemas de TI cuenten con parches y estén actualizados es una práctica estándar para todo el software, los sistemas operativos y los hipervisores. Los proveedores tienen la obligación de garantizar que su software esté parcheado y no permiten ninguna vulnerabilidad de seguridad. Algunos proporcionan más estabilidad y mejoras en las funciones. Casi todos los proveedores tienen un calendario o ciclo de lanzamiento para aplicar parches y actualizaciones a su software. Se recomienda que los clientes lean y comprendan lo que se está parcheando o las nuevas funciones que se están introduciendo. Estas actualizaciones a menudo se procesan a través de soluciones route-to-live. Las pruebas adecuadas pueden ayudar a evitar interrupciones causadas por cambios en el entorno de producción.

Antimalware

Siempre se recomienda implementar antimalware o antivirus en todos los servidores de la infraestructura. El antivirus proporciona una buena primera línea de defensa contra el malware conocido y muchos otros tipos de virus. Uno de los aspectos más complejos del antivirus es garantizar que las definiciones de virus se actualicen con regularidad. Se necesita una atención especial dentro de la VDI no persistente o las cargas de trabajo compartidas alojadas. Hay muchos artículos que detallan formas de redirigir las definiciones de antivirus a las unidades persistentes. El objetivo es garantizar que las máquinas se identifiquen como objetos individuales en el conjunto de gestión antivirus. Siga estas pautas para asegurarse de que una solución antivirus se implemente e instale correctamente. Los proveedores de antivirus tienen sus propias prácticas recomendadas para implementar su software antimalware. Recomendamos seguir sus pautas para una integración correcta. Puede obtener más información en Prácticas recomendadas de seguridad y antivirus para endpoints.

Control de aplicaciones

Las tecnologías como AppLocker pueden ser difíciles de implementar, pero son herramientas poderosas. Especialmente en términos de protección de servidores con aplicaciones publicadas con patrones de uso predecibles. Poder bloquear el entorno de forma granular al nivel ejecutable. Definir claramente qué puede o no puede funcionar y quién lo hace es altamente beneficioso. Sin mencionar las capacidades de registro durante el lanzamiento de las aplicaciones. En un entorno empresarial grande con más de 500 aplicaciones, todos estos aspectos deben considerarse cuidadosamente.

Directivas de Windows

Al aplicar directivas de Windows a un host de sesión, ya sea una carga de trabajo basada en VDI o basada en servidor, puede desempeñar dos funciones principales:

  • Fortalecimiento del sistema operativo
  • Optimización de la experiencia del usuario

Para simplificar la administración de los sistemas operativos, estas políticas se deben aplicar a través de las políticas de grupo de Microsoft. Esto facilita el proceso de creación de imágenes. Si no se utiliza la directiva de grupo, se debe encontrar un método alternativo para entregar los bloqueos. El fortalecimiento y las optimizaciones que no se pueden ofrecer a través de directivas deben automatizarse como parte del proceso de creación de la imagen.

Asegúrese siempre de que el sistema operativo esté reforzado antes de que los usuarios puedan acceder a él. Los usuarios solo deben poder llevar a cabo el número mínimo de tareas necesarias para desempeñar su función. Todas las aplicaciones administrativas deben estar protegidas y el acceso debe estar deshabilitado para los usuarios generales. Este paso reduce el riesgo de que un usuario pueda “interrumpir” su sesión. Evitar que los usuarios obtengan acceso a datos no autorizados o realicen actos malintencionados dentro del sistema operativo.

Directivas de Citrix

Las directivas se pueden aplicar según el caso de acceso de los usuarios. Algunos ejemplos de evaluaciones de sesiones de Citrix incluyen desactivar el acceso al portapapeles o la asignación de unidades del cliente si se considera necesario. Incluso habilita el portapapeles unidireccional para permitir que los datos se copien en una sesión, pero no fuera de una sesión. Varias directivas pueden ayudar a controlar la salida no autorizada de datos de la sesión del sistema. Cada directiva debe planificarse y entenderse cuidadosamente.

Muchas de las configuraciones de endurecimiento que se discutieron en la sección Fortalecimiento del sistema de este artículo se pueden aplicar en forma de directivas grupales. Permite una aplicación uniforme en todos los servidores que se aplica en el arranque antes de que el usuario inicie sesión. Este paso permite una experiencia de usuario coherente en toda la infraestructura. Lo que significa menos solución de problemas, además de garantizar que los controles de seguridad sean consistentes en todos los activos y usuarios.

Configure los grupos de entrega para permitir que el VDA se establezca antes de permitir que los usuarios inicien sesión. Este paso proporciona tiempo suficiente para que las directivas y los bloqueos se apliquen a la sesión. Garantiza que todas las políticas se hayan aplicado al servidor antes de que el usuario inicie sesión. Más información sobre SettlementPeriodBeforeUse en Developers Docs.

Administración de imágenes

La implementación adecuada de un sistema de administración de imágenes ha demostrado ahorrar mucho tiempo a los clientes. Admitimos tanto Machine Creation Services (MCS) como Provisioning Services (PVS). La administración de imágenes proporciona enormes beneficios a la funcionalidad operativa y de seguridad.

En primer lugar, se aplica un bloqueo o control en una compilación de manera uniforme en todas las máquinas desde las que los usuarios acceden a sus recursos. La construcción manual de máquinas individuales no solo lleva mucho tiempo, sino que también garantiza que se omita alguna configuración o configuración o que sea inconsistente. Establecer la configuración una vez e implementarla en todas las máquinas proporciona la tranquilidad de que la implementación de seguridad es uniforme en todas las máquinas.

En segundo lugar, durante una sesión de usuario en un VDA, el usuario abre otras aplicaciones y documentos y accede a datos confidenciales. En última instancia, los datos se almacenan en caché en el escritorio virtual o dentro de la aplicación. Una vez que el usuario cierra la sesión, los restos de datos se quedan sin duda atrás. Reiniciar la máquina y volver a la imagen maestra dorada original proporciona un nivel de seguridad de que se borrarán todos los datos confidenciales. Todo está listo para que el siguiente usuario inicie sesión y comience a trabajar sin el riesgo de acceder a los datos del usuario anterior. Puede encontrar más información aquí Arquitectura de referencia de gestión de imágenes.

Estas son algunas consideraciones para la administración de una sola imagen:

  • Tenga en cuenta las configuraciones de antivirus.
  • No cree cuentas en una plantilla o imagen antes de que Machine Creation Services o Provisioning Services tengan la oportunidad de copiar la imagen completa.
  • No programe tareas mediante cuentas de dominio almacenadas con privilegios.
  • Las cuentas de servicio deben tener una cuenta dedicada con los permisos correspondientes aplicados.
  • Asegúrese de eliminar todos los archivos de registro, archivos de configuración y otras fuentes de información que un atacante pueda usar para obtener información sobre su entorno.

El mantenimiento de estas prácticas de seguridad ayuda a evitar que un ataque de máquina obtenga contraseñas de cuentas locales persistentes. Estas contraseñas se utilizan luego para iniciar sesión en imágenes compartidas de MCS/PVS que pertenecen a otras personas.

Separación de cargas

Colocar los recursos en silos separados ha sido durante mucho tiempo una práctica recomendada. No solo en la capa de recursos, sino también en las capas de hardware y redes, que trataremos más adelante en este artículo. Separar las cargas de trabajo en varios grupos de entrega o catálogos de máquinas no ayudará a ajustar las directivas de seguridad para un conjunto de máquinas. También reducirá el impacto de una violación de seguridad. Si tiene un conjunto de usuarios de alto riesgo que acceden a datos de alto impacto, deben separarse en un entorno segregado debidamente configurado. El entorno debe tener directivas y registros mucho más estrictos aplicados. Las capacidades como la grabación de sesiones proporcionan una capa adicional de protección cuando se está accediendo a estos datos.

Las cargas de trabajo se pueden separar en diferentes niveles: separación de hardware (hosts dedicados), separación de máquinas virtuales o incluso dentro de la separación del SO (por ejemplo, enmascaramiento de aplicaciones o reglas NTFS estrictas). Como parte de la separación de los usuarios en varios niveles de perfiles de riesgo, los datos a los que acceden también deben tratarse de manera similar. Este paso implica aplicar los permisos de archivos y las reglas de acceso correctos a los datos.

Micro segmentación

Un concepto que ahora se ha hecho más prominente a medida que se implementa la migración a la infraestructura alojada en la nube y a las arquitecturas de confianza cero. Si un atacante logró acceder a los recursos, queremos limitar el daño que podría causar. Ya sea que se trate de daños malintencionados o de una fuga de datos.

Por lo tanto, la separación de la carga de trabajo y los datos es una buena práctica a seguir. Este paso implica algunos aportes de Business Analysts (BA) para ayudar a destacar los activos y datos clave en toda la red. Entonces, lo ideal sería que cada parte de los datos pudiera clasificarse como de alto, medio o bajo impacto para la empresa en caso de que se pudiera acceder a los datos.

Según el impacto en la empresa, cada segmento de datos puede tratarse de manera diferente y separarse unos de otros. Por ejemplo, un usuario que navega por Internet puede ser de alto riesgo. Esto es especialmente cierto si tienen la capacidad de descargar software o documentos y guardarlos en su sesión. Por lo tanto, nos gustaría considerar la posibilidad de aislar los recursos más críticos de las actividades de los usuarios de mayor riesgo. La navegación web y el acceso al correo electrónico están separados de datos como la información de identificación personal (PII) o incluso la información de salud personal (PHI).

Separe las cargas de trabajo entre firewalls y controle qué aplicaciones y protocolos pueden atravesar esos segmentos de red. Las cargas de trabajo en áreas de “alto riesgo” pueden estar bloqueadas mucho más que las máquinas de acceso de usuario “estándar”. La clave aquí es implementar los controles de seguridad necesarios basados en la segmentación de usuarios y datos.

Grabación de sesiones

La grabación de sesiones proporciona a los equipos de TI la capacidad de grabar y reproducir vídeo de lo que ocurrió durante una sesión de usuario determinada. El vídeo se utiliza en el caso de que un usuario esté llevando a cabo algo malicioso dentro del entorno. Es posible que esta capacidad no sea necesaria para todos los usuarios. Se puede habilitar para personas clave, grupos de usuarios o al acceder a aplicaciones, escritorios o recursos confidenciales. Se pueden extraer muchas conclusiones de estas grabaciones que podrían no ser posibles solo con los registros de eventos y aplicaciones de Windows. Los vídeos pueden ser útiles en un caso de respuesta a incidentes o en el análisis de la causa raíz. Esta función es potente y debe considerarse cuidadosamente en función de sus directivas de usuario y acuerdos con la aprobación de su equipo legal y de TI.

Marca de agua

Para las sesiones en las que un usuario accede a datos confidenciales, un gran elemento disuasorio para que los datos sean robados es una marca de agua. Especialmente si la marca de agua puede identificar de forma única al usuario. Citrix permite a los administradores configurar qué mostrar. Puede mostrar:

  • Nombre de inicio de sesión del usuario
  • Dirección IP del cliente
  • Dirección IP del VDA
  • Nombre de host del VDA
  • Marca de tiempo de inicio de sesión
  • Texto personalizado.

Al ser una función del lado del servidor, es aplicable a todas las sesiones (no solo en puntos finales específicos). Es inmune a la terminación del proceso en el punto final por parte del usuario como solución alternativa.

Más información sobre la marca de agua de sesión en la documentación del producto.

Uso concurrente

Un tema más polémico ha sido el uso de hosts multisesión frente a sesiones de VDI de un solo usuario. El hecho de que varios usuarios inicien sesión en un solo servidor puede causar problemas. Esto es especialmente cierto si un usuario descontento puede ejecutar software o código para recopilar otras credenciales o acceder a otros datos de usuario. La ejecución de una infraestructura sólida de equipos de escritorio virtuales conlleva un coste adicional y se deben considerar estas compensaciones. Amenaza a los usuarios del modelo y selecciona el mecanismo de entrega más eficiente. Decida si un host de sesión multiusuario o un host de sesión de un solo usuario es la ruta ideal. La talla única no se ajusta a todos los usuarios. Realice perfiles de usuario para comprender sus requisitos y, a continuación, seleccione el mejor método de entrega de cargas de trabajo para los grupos de usuarios.

Seguridad basada en la virtualización

La seguridad basada en la virtualización (VBS) utiliza una parte segura de la memoria para almacenar activos seguros de la sesión. Esta función requiere que se ejecute un módulo de plataforma segura (TPM) o un módulo de plataforma segura virtual (vTPM) en una plataforma compatible para ofrecer una integración segura. Esto significa que incluso si de alguna manera el malware se implementa correctamente en el núcleo, los datos secretos almacenados por el usuario permanecen protegidos. Cualquier código que se pueda ejecutar en el entorno seguro debe estar firmado por Microsoft, lo que proporciona una capa de control adicional. Microsoft VBS se puede habilitar en los sistemas operativos Windows Desktop y Server. Microsoft VBS se basa en un conjunto de tecnologías que incluyen protección de credenciales y protección de aplicaciones. Puede encontrar más información sobre la seguridad basada en la virtualización aquí.

Capa de control

El nivel de control es el nivel de la solución que permite a los administradores administrar el entorno de Citrix, además de permitir el acceso de los usuarios a los recursos. En esta sección se pueden encontrar detalles sobre cómo permitir que los recursos se comuniquen entre sí. Debido a la integración de esta capa, es fundamental garantizar que los componentes puedan integrarse y comunicarse de forma segura. Lo siguiente reduce la postura de seguridad de los componentes.

Garantizar la disponibilidad

Al implementar cualquier solución, los componentes deben implementarse de manera altamente disponible. Tener servicios que sufren interrupciones constantes debido a puntos únicos de falla es una mala práctica. Por lo tanto, el uso del enfoque N+1 en cuanto a la capacidad garantiza que haya suficientes recursos disponibles durante las tormentas de inicio y cierre de sesión. Pero hay un nivel aceptable de pérdida de componentes para mantener la “buena” experiencia de usuario. Ahora, la mayoría de los clientes siguen N+1 en términos de planificación de la cantidad de recursos que deben estar disponibles. Sin embargo, dependiendo del nivel de riesgo tolerable, puede ser N+2.

Además, para garantizar que haya suficientes recursos disponibles para gestionar la carga de los usuarios, los componentes deben separarse en máquinas virtuales dedicadas. Es una mala práctica ejecutar componentes compartidos en máquinas virtuales, no solo desde el punto de vista del rendimiento, sino también de la seguridad. Los componentes clave desde la perspectiva de Citrix son los siguientes, pero no se limitan a:

  • StoreFront
  • Delivery Controllers
  • Servidor SQL
  • Servicio de autenticación federada
  • Director
  • Servidor de licencias
  • Cloud Connectors

Cifrar flujos de datos

Las empresas están adoptando un enfoque de “confianza cero” para los servicios en todos sus entornos. Ahora es más importante que nunca garantizar que todas las comunicaciones entre los componentes estén protegidas e incluso autenticadas cuando sea posible. Este paso reduce las posibilidades de que los atacantes puedan leer información confidencial mientras está en vuelo a través de la red. Desde la perspectiva de Citrix, este paso implica esencialmente vincular un certificado a los servicios relevantes desde una infraestructura de clave pública (PKI) privada o pública.

Recomendación de alta seguridad: En implementaciones de alta seguridad, los estándares establecidos sugieren que es posible que sea necesario cumplir con los Estándares Federales de Procesamiento de la Información (FIPS). Este requisito implica cambios en los componentes virtualizados y al considerar componentes como Citrix ADC. También requiere dispositivos de hardware acreditados. Centro de confianza de Citrix

Construir endurecimiento

Como se analizó en la sección Capa de recursos, se recomienda encarecidamente reforzar el sistema operativo y los servicios que se implementan. Este paso implica inhabilitar los servicios, las tareas programadas o las funciones no utilizadas. Asegúrese de no afectar a los elementos que se utilizan para reducir el servicio de ataque en la máquina. Existen líneas de base, como las líneas base de seguridad de CIS y Microsoft, que se pueden utilizar para bloquear las máquinas virtuales que se ejecutan en el entorno. Incluya tanto los servidores de sesión que alojan las sesiones de usuario como los servicios de control, como los conectores de nube y la infraestructura de soporte. Una máquina de infraestructura también debe tener inhabilitados los servicios, las funciones o las tareas programadas que no sean necesarios para que el servicio funcione.

Protección de cuentas de servicio

Algunos elementos de una solución Citrix requieren el uso de cuentas de servicio. Las cuentas de servicio permiten que las funciones automatizadas progresen con cierto nivel de autenticación y autorización. Una cuenta de servicio solo debe tener permiso para llevar a cabo la tarea requerida y no debe tener ningún acceso elevado en la red. Se deben crear cuentas de servicio para cada función automatizada. Este paso reduce intrínsecamente los elementos de autorización y garantiza que no se produzca ninguna pérdida de privilegios dentro del servicio. Recomendamos asegurarse de que las contraseñas de las cuentas de servicio se restablezcan al menos una vez al año o con mayor frecuencia según sus requisitos de cumplimiento Estas cuentas o grupos también deben estar en grupos de usuarios protegidos dentro de Active Directory para obtener protección y registro adicionales.

Para reforzar aún más las cuentas de servicio, también se recomienda denegar los derechos de inicio de sesión interactivo a dichas cuentas siempre que sea posible para garantizar que la cuenta no se pueda volver a utilizar para iniciar sesión en un dispositivo de red en caso de que la contraseña se vea comprometida.

Asegúrese de que la cuenta no pueda iniciar sesión de forma interactiva con ninguna cuenta de la red, ya sea una:

  • User account
  • Cuenta de administrador
  • Cuenta del servicio

Las cuentas deben auditarse periódicamente y sus permisos deben verificarse para garantizar que la cuenta siga siendo necesaria. Compruebe también que no haya habido ningún «aumento de privilegios» adicional en la red. El aumento de privilegios es cuando, con el tiempo, se pueden asignar permisos adicionales a las cuentas y nunca se retiran. Por ejemplo, se agregan permisos para solucionar un problema, pero nunca se revisan ni se eliminan. No se respeta el concepto de privilegio mínimo.

Privilegio mínimo

Este marco se aplica a cualquier cuenta de la red. Este paso garantiza que todas las cuentas creadas solo tengan los permisos necesarios para desempeñar la función. Cuando se requiere acceso administrativo, los usuarios deben tener cuentas separadas que se utilicen para realizar funciones administrativas. En un caso ideal, los permisos para las cuentas solo se deben conceder durante el tiempo que lleva realizar esa tarea. Una vez que se hayan completado las acciones administrativas, se deben eliminar los permisos que ya no sean necesarios.

Control de aplicaciones

Los controles de las aplicaciones se han cubierto en la capa de recursos. Sin embargo, se puede adoptar un enfoque similar para el nivel de control. Permitir los ejecutables específicos de una aplicación reduce aún más la superficie de ataque en las máquinas en ejecución. No se permitirá la ejecución de ningún ejecutable no autorizado. Esto viene con gastos administrativos, pero agrega una capa adicional de control. Este paso debe aplicarse a todas las aplicaciones implementadas. Una consideración de este enfoque es que las actualizaciones que cambian los archivos o ejecutables que se ejecutan en el sistema deben aprobarse previamente. Este paso permite que se ejecuten después de realizar una actualización.

Firewall basado en host

Lo más común y probablemente lo primero que los administradores inhabilitan es el firewall basado en host. Sin embargo, se puede habilitar para ciertos casos, como la solución de problemas. Dejar estos servicios inhabilitados permanentemente deja al entorno en un alto riesgo de seguridad. El cortafuegos está diseñado para evitar que los atacantes obtengan acceso al servidor a través de herramientas o aplicaciones desconocidas o falsas. Asegúrese de que el cortafuegos esté configurado para detener la ejecución de cualquier elemento no autorizado. Sin embargo, debe configurarse para permitir que las aplicaciones funcionen y se comuniquen entre sí. Al instalar el VDA de Citrix, este crea automáticamente las reglas de firewall necesarias para la comunicación básica del VDA. También puede agregar Asistencia remota de Windows y los puertos RealTime Audio necesarios. Los entornos de prueba son necesarios para permitir que los administradores comprendan claramente el funcionamiento de las aplicaciones. Este paso le permite configurar firewalls y servicios en el entorno de producción con confianza. Evite un impacto negativo en la aplicación o en la experiencia del usuario. Para conocer los puertos necesarios para permitir el funcionamiento de los entornos Citrix, consulte CTX101810.

Transport Layer Security

TLS cifra las comunicaciones entre dos o más componentes. La autenticación, la enumeración y el inicio de una sesión requieren la transferencia de información confidencial. Si estas comunicaciones no están cifradas, un atacante podría recuperar las credenciales de usuario u otros datos confidenciales. Al reforzar los entornos, habilitar TLS es una de las primeras cosas que se deben hacer. Al habilitar TLS, siga las prácticas recomendadas para la creación de las claves privadas. Existen muchos artículos sobre la administración de claves y la creación de prácticas recomendadas de certificados. Recomendamos habilitar TLS para las siguientes comunicaciones como mínimo:

  • Servicio STA
  • Intermediación XML
  • StoreFront (URL base)
  • Interfaz de administración de ADC
  • Gateway
  • Director si se ejecuta en las instalaciones

Capa de host

Cada entorno virtual compromete varios componentes, como el almacenamiento, la computación, el hipervisor y las redes. Diseñe e implemente siempre estos componentes con un enfoque de seguridad. Tiene un impacto significativo en la reducción continua de la superficie de ataque. Con los servicios en la nube, no todos son aplicables, pero la mayoría se aplican independientemente de dónde se encuentren los recursos.

Separación de hardware

En la era actual de la nube, el concepto de separación de hardware se ha convertido en una preocupación menor para los administradores. Además, cada vez más empresas buscan un mayor retorno de la inversión asegurándose de que todo el hardware se utilice por completo. Con algunos proveedores de servicios en la nube, esto es algo que ni siquiera es posible. Sin embargo, con las infraestructuras físicas locales, aún puede separar los recursos en entornos de alojamiento únicos. Estos ataques incluyen hyperjacking, en el que un atacante puede explorar en profundidad una VM a través de la pila de herramientas de VM. Luego, el atacante obtiene acceso al hipervisor.

Muchos de los ataques documentados son teóricos. Pero el hecho de que estén documentados públicamente sugiere que este tipo de ataque puede ser eficaz. Como se trata de una posibilidad real, se trata de proteger los datos. Separe las cargas de trabajo en clústeres únicos y asegúrese de que las cargas de trabajo que alojan la misma clasificación de datos se conserven dentro de Si un atacante irrumpió en la capa del hipervisor de alguna manera, las clasificaciones de datos más altas no se verán comprometidas.

Separación de redes

Dividir las cargas de trabajo en subredes individuales que estén separadas de forma lógica puede reducir drásticamente el impacto o la propagación de un ataque. Por lo general, estos diseños de subred son un lugar perfecto para empezar:

  • Componentes de acceso. Subred pequeña que compromete las direcciones IP de ADC y la puerta de enlace de devolución de llamada.
  • Infraestructura de Citrix. La subred de infraestructura de Citrix en función de la infraestructura que se implemente incluiría lo siguiente: StoreFront, Cloud Connectors/Controllers, Director servers, Citrix ADM.
  • Infraestructura de apoyo. Según los componentes de infraestructura que se requieran, estos servicios son ejemplos principales de separación: servidores SQL, servidores Jump y servidores de licencias. Esto depende de sus necesidades de cumplimiento.
  • Subredes de VDA. No hay una respuesta correcta o incorrecta al dimensionar las subredes del VDA. En el pasado, hemos utilizado datos históricos para guiarnos en torno al tamaño de las subredes de PVS. Con el tiempo, PVS recomendó que las prácticas evolucionaran. Lo principal a tener en cuenta es que el tamaño de la subred debe asignarse según la cantidad de usuarios y VDA y el contexto de seguridad al que acceden. Colocar a los usuarios con un perfil de riesgo similar en una sola subred también puede garantizar que cada una de estas subredes esté separada por un firewall.

Cortafuegos

Los firewalls son uno de los elementos principales de la implementación de la seguridad en un entorno. La implementación de firewalls basados en host y en red generará una sobrecarga operativa significativa. La implementación de dos niveles de firewalls tanto a nivel de host como de red permitirá la separación de tareas. Este paso permite que una aplicación se comunique de un servidor a otro. Todas las reglas del cortafuegos deben estar bien documentadas y deben estar claramente marcadas en cuanto a qué roles o funciones se asignan. Esta información le ayuda a obtener la aprobación de las excepciones por parte de sus equipos de seguridad y red.

Fortalecimiento de hipervisores

Para que un hipervisor funcione correctamente, es necesario habilitar un cierto nivel de servicio y procesos. Al igual que en cualquier sistema operativo, muchos de los servicios a nivel de hipervisor se pueden inhabilitar para reducir la superficie de ataque en el nivel de hipervisor. Poner en peligro el hipervisor puede ser una declaración de un desbordamiento total por parte de un atacante. El atacante tiene acceso a la memoria de lectura, las instrucciones de la CPU y las máquinas de control. Si un atacante entra en esta capa, sería un asunto serio.

Capa de operaciones

Los procedimientos operativos para ejecutar un entorno seguro son tan críticos como la propia configuración técnica. Los siguientes elementos proporcionan un excelente punto de partida para construir una base sólida de excelencia en seguridad operativa.

Formación de usuarios

Proporcionar suficiente formación a los usuarios y a la administración. Promueve buenas prácticas de seguridad y la concienciación es una de las bases más fáciles de cubrir. Un ejemplo es asegurarse de que los usuarios conozcan el comportamiento normal esperado de una página de inicio de sesión. Comprenda qué detalles necesita el personal de soporte. Capacite al personal sobre cómo manejar las ventanas emergentes y esos temidos intentos de phishing por correo electrónico. Los usuarios deben saber cómo responder y comprender dónde y cómo informar los problemas relacionados con la seguridad a los centros operativos de seguridad.

Monitorización de usuarios

Permitir una supervisión mejorada de los usuarios, como la grabación de sesiones de los usuarios, a veces puede resultar Notificar a los usuarios dentro de su contrato de trabajo, por ejemplo, que sus acciones en los sistemas de TI pueden registrarse con fines de auditoría. Puede proporcionar un nivel de cobertura adecuado para cualquier implicación legal de Recursos Humanos. Lo que es más controvertido, es posible habilitar el registro de teclas. Este tipo de herramientas deben abordarse con cierto nivel de precaución, ya que existe la posibilidad de que surjan problemas. Depende de a qué acceda el usuario mientras está en sus máquinas corporativas. Los administradores pueden recopilar nombres de usuario o contraseñas de correos electrónicos personales o incluso cuentas bancarias, sin que el usuario lo sepa. Esto debe abordarse con cautela y, una vez más, los usuarios notifican que se están llevando a cabo tales acciones.

Registro y auditoría

Garantice el registro de todas las acciones de los administradores de TI y los usuarios. Registro habilitado en todo el entorno. Incluye todas las capas descritas en este artículo. Recopile y almacene estos registros con fines de auditoría. Conserve los registros, solo en caso de que sean necesarios para su revisión, en caso de incumplimiento. Este paso requiere que administre y actúe de forma continua en función de los registros que se generan. Algunas aplicaciones proporcionan cierto nivel de automatización que puede permitir que los registros y las alertas se procesen para la acción.

Citrix ofrece una solución basada en la nube como parte del servicio de análisis. Este servicio permite la puntuación de los riesgos de seguridad de un usuario. En función de la puntuación de riesgo, puede aumentar su postura de seguridad, desconectar o incluso bloquear la cuenta automáticamente. Estos eventos pueden habilitar funciones como Grabación de sesiones automáticamente, como se discutió anteriormente en este artículo. Podemos inhabilitar las funciones de Citrix y desconectar la sesión, hasta que un administrador pueda revisar las acciones de ese usuario. Security Analytics puede correlacionar el análisis del comportamiento de los usuarios y los controles de seguridad aplicados de forma automatizada. Puede encontrar más información en el resumen técnico de Citrix Analytics.

Separación de funciones

Asegúrese de que se implementen buenos mecanismos de control de acceso basados en roles. Sin embargo, también es un excelente enfoque para garantizar que ningún administrador pueda actuar solo para activar una función o un punto de salida. Lo ideal es implementar la separación de tareas para obligar a varios administradores a actuar de forma independiente para habilitar una función. Un buen ejemplo es habilitar la asignación de unidades de cliente en una sesión de Citrix. Esto se puede controlar mediante una directiva administrativa de Citrix habilitada en Citrix ADC dentro de una directiva SmartControl. Requiere dos cambios distintos para habilitar la función CDM.

Es importante tener dos administradores para habilitar una función. Los administradores también deben tener cuentas separadas de su cuenta de usuario normal. Las cuentas de administrador son solo para realizar tareas administrativas. Este paso reduce el vector de ataque de los ataques de phishing. Si un administrador tiene sus credenciales de usuario normales en colmenas y estas credenciales tienen permisos de administrador de dominio, se producirá un impacto significativo en el entorno. Por lo tanto, la cuenta de usuario normal del administrador no puede llevar a cabo tareas administrativas. Los usuarios no deben tener derechos de administrador globales en una red o dominio. Lo ideal es que el uso de grupos de controles de acceso basados en roles (RBAC) se utilice para dar permiso a las funciones administrativas a un nivel más detallado.

Gestión de cambios

Una de las cosas comunes que algunos clientes rara vez consideran es la importancia de tener entornos de prueba y desarrollo separados. Estos entornos son elementos cruciales para probar exhaustivamente las actualizaciones y los cambios para comprender cómo afectan al entorno del usuario. Las infraestructuras deben estar estrechamente relacionadas con los procesos de control de cambios para obligar a los administradores a realizar cambios en el entorno de pruebas y desarrollo antes de pasar a la producción. Como parte de las pruebas para los cambios de instalación o actualización en los entornos de desarrollo, es igualmente importante probar exhaustivamente la reversión de los cambios. De esta manera, los administradores están más familiarizados con el proceso, si alguna vez necesitan invocar un proceso de reversión dentro de la producción. Las pruebas exhaustivas y los planes de implementación sólidos protegen el entorno de producción de cortes innecesarios. Idealmente, un esquema aproximado para pasar a “Live” debe comprender las siguientes fases:

  • Prueba. Un entorno poco controlado y un área más sandbox para que los administradores se familiaricen con el software actualizado y las nuevas funciones.
  • Preproducción. La preproducción debe tratarse de manera similar a la producción, protegerse estrechamente mediante el control de cambios y mantenerse en sintonía con la producción. Esto proporciona una firme garantía de que los comportamientos de las actualizaciones en la preproducción están en sintonía con los de la producción, solo que en una escala más pequeña.
  • Producción. La producción no hace falta decir, su producción. No se deben permitir cambios no autorizados sin Control de cambios.

Hashes de software

Es una buena práctica al descargar software de los sitios web de los proveedores para validar el hash proporcionado en la página de descargas. Esto verificaría que el archivo descargado no haya sido manipulado por un adversario.

Auditorías de seguridad

Las operaciones de seguridad son un tema muy amplio e incluyen muchos elementos de documentación de usuario, documentación legal y cualquier entorno. Tanto como los aspectos técnicos de cualquier infraestructura son críticos. Es importante tener en cuenta que la documentación de apoyo, la legalidad y las comprobaciones de estado de TI que conducen, en última instancia, a la “aprobación” del uso o la retención de datos como la información de identificación personal (PII) o la industria de tarjetas de pago (PCI) son cruciales. Se recomienda encarecidamente asegurarse de realizar auditorías de seguridad y pruebas de penetración periódicas para validar sus operaciones y controles de seguridad.

Resumen

Muchos controles de seguridad se integran en un entorno en las primeras fases de un proyecto. Sin embargo, los riesgos de seguridad evolucionan constantemente y revisar los controles y procedimientos establecidos es un proceso continuo. Debe revisarse con frecuencia. Todos los esfuerzos deben reforzarse y validarse mediante pruebas de penetración en el entorno virtualizado en general. Este enfoque proporciona el mayor nivel de resiliencia contra un ataque del mundo real.

Documento técnico: Mejores prácticas de seguridad para Citrix Virtual Apps and Desktops

En este artículo