Compartir vía

Directrices generales e información de seguridad de la empresa en Azure HDInsight

  • Artículo

Al implementar un clúster de HDInsight seguro, hay algunos procedimientos recomendados que facilitan la implementación y administración de clústeres. A continuación, se tratan algunas directrices e información generales.

Uso de un clúster seguro

  • Varios usuarios usarán el clúster al mismo tiempo.
  • Los usuarios tienen distintos niveles de acceso a los mismos datos.

No es necesario

  • Si va a ejecutar solo trabajos automatizados (como una cuenta de usuario único), un clúster estándar es suficiente.
  • Puede realizar la importación de datos mediante un clúster estándar y usar la misma cuenta de almacenamiento en otro clúster seguro en el que los usuarios puedan ejecutar trabajos de análisis.

Uso de una cuenta local

  • Si utiliza una cuenta de usuario compartida o una cuenta local, será difícil identificar quién usó la cuenta para cambiar la configuración o el servicio.
  • El uso de cuentas locales es problemático cuando los usuarios ya no forman parte de la organización.

Ranger

Directivas

  • De manera predeterminada, Ranger usa Denegar como directiva.

  • Cuando el acceso a los datos se realiza a través de un servicio en el que se ha habilitado la autorización:

    • Se invoca un complemento de autorización de Ranger y se le aplica el contexto de la solicitud.
    • Ranger aplica las directivas configuradas para el servicio. Si las directivas de Ranger fallan, la comprobación de acceso se aplaza en el sistema de archivos. Algunos servicios, como MapReduce, solo comprueban si el archivo o la carpeta son propiedad del mismo usuario que envía la solicitud. Servicios como Hive comprueban si la propiedad coincide o se adecúa a los permisos del sistema de archivos (rwx).

  • En el caso de Hive, además de tener los permisos para crear, actualizar o eliminar permisos, el usuario debe tener permisos rwx en el directorio del almacenamiento y en todos los subdirectorios.

  • Las directivas se pueden aplicar a grupos (preferiblemente) en lugar de individuos.

  • El autorizador de Ranger evaluará todas las directivas de Ranger de dicho servicio para cada solicitud. Esta evaluación podría afectar al tiempo que se tarda en aceptar el trabajo o la consulta.

Acceso al almacenamiento

  • Si el tipo de almacenamiento es WASB, no implica ningún token de OAuth.
  • Si Ranger ha llevado a cabo la autorización, el acceso al almacenamiento se produce mediante la identidad administrada.
  • Si Ranger no ha llevado a cabo ninguna autorización, el acceso al almacenamiento se produce mediante el token de OAuth del usuario.

Espacio de nombres jerárquico

Cuando el espacio de nombres jerárquico no se ha habilitado:

  • No hay permisos heredados.
  • El único permiso del sistema de archivos que funciona es el rol de Azure Storage Data XXXX, que se va a asignar al usuario directamente en Azure Portal.

Permisos de HDFS predeterminados

  • De manera predeterminada, los usuarios no tienen acceso a la carpeta / en HDFS (deben estar en el rol de propietario de blob de almacenamiento para poder obtener acceso).
  • En el caso del directorio de almacenamiento provisional para MapReduce y otros, se crea un directorio específico del usuario y se proporcionan permisos sticky _wx. Los usuarios pueden crear archivos y carpetas debajo, pero no pueden ver otros elementos.

Autenticación de URL

Si la autenticación de URL está habilitada:

  • La configuración incluirá los prefijos que se cubren en la autenticación de URL (como adl://).
  • Si el acceso es para este URL, Ranger comprobará si el usuario está en la lista de permitidos.
  • Ranger no comprobará ninguna de las directivas detalladas.

Administrar registros de auditoría de Ranger

Para evitar que los registros de auditoría de Ranger consuman demasiado espacio en disco en el nodo principal hn0, puede cambiar el número de días para conservar los registros.

  1. Inicie sesión en la interfaz de usuario de Ambari.
  2. Vaya a Servicios>Ranger>Configuración>Avanzado>ranger-solr-configuration.
  3. Cambie "Máximo de días de retención" a 7 días o menos.
  4. Seleccione Guardar y reinicie los componentes afectados para que el cambio surta efecto.

Usar una base de datos de Ranger personalizada

Se recomienda implementar una base de datos de Ranger externa para usarla con el clúster ESP para lograr una alta disponibilidad de los metadatos de Ranger, lo que garantiza que las directivas estén disponibles incluso si el clúster no está disponible. Dado que una base de datos externa está administrada por el cliente, también tendrá la capacidad de ajustar el tamaño de la base de datos y compartir la base de datos en varios clústeres ESP. Puede especificar la base de datos de Ranger externa durante el proceso de creación del clúster de ESP mediante Azure Portal, Azure Resource Manager, la CLI de Azure, etc.

Establecer la sincronización de usuarios de Ranger para que se ejecute diariamente

Los clústeres de ESP de HDInsight están configurados para que Ranger sincronice los usuarios de AD automáticamente cada hora. La sincronización de Ranger es una sincronización de usuario y puede provocar una carga adicional en la instancia de AD. Por este motivo, se recomienda cambiar el intervalo de sincronización del usuario de Ranger a 24 horas.

  1. Inicie sesión en la interfaz de usuario de Ambari.
  2. Vaya a Servicios>Ranger>Configuraciones>Avanzado>ranger-ugsync-site
  3. Establezca la propiedad ranger.usersync.sleeptimeinmillisbetweensynccycle en 864000000 (24 horas en milisegundos).
  4. Seleccione Guardar y reinicie los componentes afectados para que el cambio surta efecto.

Grupos de recursos

Use un nuevo grupo de recursos para cada clúster para poder distinguir entre los recursos de clúster.

NSG, firewalls y puerta de enlace interna

  • Use grupos de seguridad de red (NSG) para bloquear redes virtuales.
  • Use firewall para controlar las directivas de acceso de salida.
  • Use la puerta de enlace interna que no esté abierta para Internet pública.

Microsoft Entra ID

Microsoft Entra ID (Microsoft Entra ID) es el servicio de administración de identidades y accesos basado en la nube de Microsoft.

Directivas

  • Deshabilite la directiva de acceso condicional mediante la directiva basada en direcciones IP. Esto requiere la habilitación de puntos de conexión de servicio en las redes virtuales en las que se implementan los clústeres. Si usa un servicio externo para MFA (algo que no sea Microsoft Entra ID), la directiva basada en la dirección IP no funcionará

  • Se requiere la directiva AllowCloudPasswordValidation para los usuarios federados. Dado que HDInsight usa el nombre de usuario / contraseña directamente para obtener tokens de Microsoft Entra ID, esta directiva tiene que estar habilitada para todos los usuarios federados.

  • Habilite los puntos de conexión de servicio si se requiere la omisión del acceso condicional mediante direcciones IP de confianza.

Grupos

  • Implemente siempre los clústeres con un grupo.
  • Use Microsoft Entra ID para administrar las membresías de grupo (más fácil que tratar de administrar los servicios individuales en el clúster).

Cuentas de usuario

  • Use una cuenta de usuario única para cada escenario. Por ejemplo, use una cuenta para importar, otra para realizar consultas u otra para procesar trabajos.
  • Use directivas de Ranger basadas en grupos en lugar de directivas individuales.
  • Disponga de un plan sobre cómo administrar los usuarios que ya no deben tener acceso a los clústeres.

Servicios de dominio de Microsoft Entra

Microsoft Entra Domain Services proporciona servicios de dominio administrados, como unión a dominios, directiva de grupo, protocolo ligero de acceso a directorios (LDAP) y autenticación Kerberos / NTLM que es totalmente compatible con Windows Server Active Directory.

Microsoft Entra Domain Services es necesario para que los clústeres seguros se unan a un dominio. HDInsight no puede depender de controladores de dominio locales ni personalizados, ya que presenta demasiados puntos de error, uso compartido de credenciales, permisos de DNS, etc. Para obtener más información, consulte preguntas más frecuentes sobre Microsoft Entra Domain Services.

Elija el SKU correcto de Microsoft Entra Domain Services

Al crear el dominio administrado, puede elegir entre diferentes SKU que ofrecen distintos niveles de rendimiento y características. El número de clústeres de ESP y otras aplicaciones que usarán la instancia de Microsoft Entra Domain Services para las solicitudes de autenticación determina qué SKU es adecuada para su organización. Si observa un uso elevado de la CPU en el dominio administrado o en los requisitos empresariales, puede actualizar la SKU.

Instancia de Microsoft Entra Domain Services

  • Cree la instancia con .onmicrosoft.com domain. De esta forma, no habrá varios servidores DNS sirviendo al dominio.
  • Cree un certificado autofirmado para LDAPS y cárguelo en Microsoft Entra Domain Services.
  • Use una red virtual emparejada para implementar clústeres (será útil cuando tenga una gran cantidad de equipos implementando clústeres de HDInsight ESP). Así se garantiza que no sea necesario abrir puertos (NSG) en la red virtual con el controlador de dominio.
  • Configure correctamente el DNS para la red virtual (el nombre de dominio de Microsoft Entra Domain Services debe resolverse sin ninguna entrada en el archivo de hosts).
  • Si va a restringir el tráfico saliente, asegúrese de que ha leído la información del soporte técnico para firewall en HDInsight.

Tenga en cuenta los conjuntos de réplica de Microsoft Entra Domain Services

Al crear un dominio administrado de Microsoft Entra Domain Services, se define un espacio de nombres único y se implementan dos controladores de dominio (DC) en la región de Azure seleccionada. Esta implementación de controladores de dominio se conoce como "conjunto de réplicas". La adición de conjuntos de réplicas adicionales proporcionará resistencia y garantizará la disponibilidad de los servicios de autenticación, que es fundamental para los clústeres de Azure HDInsight.

Configurar la sincronización de usuarios o grupos con ámbito

Al habilitar Microsoft Entra Domain Services para el clúster de ESP, puede elegir sincronizar todos los usuarios y grupos de Microsoft Entra ID o grupos con ámbito y sus miembros. Se recomienda elegir la sincronización "con ámbito" para obtener el mejor rendimiento.

La sincronización con ámbito se puede modificar con diferentes selecciones de grupo o convertirse en "Todos" los usuarios y grupos si es necesario. No se puede cambiar el tipo de sincronización de "All" a "Scoped" a menos que se elimine y vuelva a crear la instancia de Microsoft Entra Domain Services.

Propiedades sincronizadas desde Microsoft Entra ID a Microsoft Entra Domain Services

  • Microsoft Entra Connect sincroniza desde los locales a Microsoft Entra ID.
  • Microsoft Entra Domain Services se sincroniza desde Microsoft Entra ID.

Microsoft Entra Domain Services sincroniza los objetos de Microsoft Entra ID periódicamente. La hoja Microsoft Entra Domain Services de Azure Portal muestra el estado de sincronización. Durante cada fase de la sincronización, es posible que algunas propiedades únicas entren en conflicto y cambien de nombre. Preste atención a la asignación de propiedades de Microsoft Entra ID a Microsoft Entra Domain Services.

Para obtener más información, vea Rellenado de UserPrincipalName de Microsoft Entra y Funcionamiento de la sincronización de Microsoft Entra Domain Services.

Sincronización de hash de contraseñas

  • Las contraseñas se sincronizan de forma diferente desde otros tipos de objetos. Solo los hash de contraseña no reversibles se sincronizan en Microsoft Entra ID y Microsoft Entra Domain Services
  • En los locales a Microsoft Entra ID tiene que ser habilitado a través de AD Connect
  • La sincronización de Microsoft Entra ID con Microsoft Entra Domain Services es automática (las latencias son inferiores a 20 minutos).
  • Los valores hash de contraseña solo se sincronizan cuando se cambia una contraseña. Al habilitar la sincronización de hash de contraseña, las contraseñas existentes no se sincronizan, ya que se almacenan de forma irreversible. Al cambiar la contraseña, se sincronizan los valores hash de contraseña.

Establecer la sincronización LDAP de Ambari para que se ejecute diariamente

El proceso de sincronización de nuevos usuarios LDAP con Ambari se configura automáticamente para que se ejecute cada hora. La ejecución de esto cada hora puede provocar una carga excesiva en los nodos principales del clúster y en la instancia de AD. Para mejorar el rendimiento, se recomienda cambiar el script /opt/startup_scripts/start_ambari_ldap_sync.py que ejecuta la sincronización LDAP de Ambari para que se ejecute una vez al día. Este script se ejecuta a través de un trabajo crontab y se almacena en el directorio "/etc/cron.hourly/" en los nodos principales del clúster.

Para que se ejecute una vez al día, realice los pasos siguientes:

  1. Cambio de ssh a hn0
  2. Mueva el script a la carpeta diaria cron: sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync
  3. Aplique el cambio en el trabajo crontab: sudo service cron reload
  4. ssh a hn1 y repita los pasos 1 a 3

Si es necesario, puede usar la API de REST de Ambari para sincronizar manualmente nuevos usuarios y grupos inmediatamente.

Ubicación de los objetos de equipo

Cada clúster virtual está asociado a una única unidad organizativa. Un usuario interno se aprovisiona en la unidad organizativa. Todos los nodos están unidos a un dominio en la misma unidad organizativa.

Herramientas administrativas de Azure Active Directory

Para más información, consulte Instalación de herramientas de administración.

Solución de problemas

La creación del clúster falla repetidamente

Motivos más comunes:

  • La configuración de DNS no es correcta y se produce un error en la unión a un dominio de nodos de clúster.
  • Los NSG son demasiado restrictivos, lo cual evita la unión a un dominio.
  • La identidad administrada no tiene permisos suficientes.
  • El nombre del clúster no es único en los seis primeros caracteres (debido a un clúster activo o uno eliminado).

Instalación y configuración de la autenticación

Nombre principal de usuario (UPN)

  • Use minúsculas en todos los servicios: los UPN no distinguen mayúsculas de minúsculas en los clústeres ESP.
  • El prefijo UPN debe coincidir tanto con SAMAccountName en Microsoft Entra Domain Services. No es necesario buscar coincidencias con el campo de correo.

Propiedades de LDAP en la configuración de Ambari

Para obtener una lista completa de las propiedades de Ambari que afectan a la configuración del clúster de HDInsight, consulte Configuración de la autenticación LDAP de Ambari.

Generar keytab(s) de usuario de dominio

Todas las keytabs de servicio se generan automáticamente durante el proceso de creación del clúster de ESP. Para habilitar la comunicación segura entre el clúster y otros servicios o trabajos que requieren autenticación, puede generar un keytab para el nombre de usuario del dominio.

Use ktutil en una de las máquinas virtuales del clúster para crear una keytab de Kerberos:


ktutil
ktutil: addent -password -p <username>@<DOMAIN.COM> -k 1 -e aes256-cts-hmac-sha1-96
Password for <username>@<DOMAIN.COM>: <password>
ktutil: wkt <username>.keytab
ktutil: q

Si su TenantName y DomainName es diferente, deberá agregar un valor SALT usando la opción -s. Consulte la página de preguntas más frecuentes de HDInsight para determinar el valor SALT adecuado al crear un keytab de Kerberos.

Renovación de certificado LDAP

HDInsight renovará automáticamente los certificados de las identidades administradas que use para los clústeres con Enterprise Security Package (ESP). Sin embargo, existe una limitación cuando se utilizan diferentes identidades administradas para Microsoft Entra Domain Services y ADLS Gen2 que podría causar que el proceso de renovación falle. Siga las 2 recomendaciones siguientes para asegurarnos de que podemos renovar los certificados correctamente:

  • Si usa identidades administradas diferentes para clústeres de ADLS Gen2 y Microsoft Entra Domain Services, ambos deben tener asignados los roles de Propietario de datos de blobs de Storage y Colaborador de HDInsight Domain Services.
  • Los clústeres de HDInsight requieren direcciones IP públicas para las actualizaciones de certificados y otro mantenimiento, por lo que se deben quitar las directivas que denieguen la dirección IP pública del clúster.

Pasos siguientes