Control de seguridad v3: Administración de identidades

Identity Management trata los controles para establecer una identidad segura y controles de acceso mediante Azure Active Directory, incluido el uso de inicio de sesión único, autenticaciones seguras, identidades administradas (y entidades de servicio) para aplicaciones, acceso condicional y supervisión de anomalías de cuentas.

IM-1: Uso de una identidad centralizada y un sistema de autenticación

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Principio de seguridad: use un sistema centralizado de identidad y autenticación para regular las identidades y autenticaciones de la organización para los recursos dentro y fuera de la nube.

Guía de Azure: Azure Active Directory (Azure AD) es el servicio de administración de identidades y autenticación de Azure. Debe normalizar el uso de Azure AD para controlar las identidades y autenticación de la organización en:

  • Los recursos en la nube de Microsoft, como Azure Storage, Azure Virtual Machines (Linux y Windows), Azure Key Vault, PaaS y aplicaciones SaaS.
  • Los recursos de la organización, como aplicaciones en Azure, aplicaciones de terceros que se ejecutan en los recursos de la red corporativa y aplicaciones SaaS de terceros.
  • Las identidades empresariales de Active Directory mediante sincronización con Azure AD para garantizar una estrategia de identidad coherente y administrada de forma centralizada.

Nota: Tan pronto como sea técnicamente posible, debe migrar las aplicaciones basadas en Active Directory local a Azure AD. Podría ser un directorio de empresa de Azure AD, una configuración de negocio a negocio, o una configuración de negocio a consumidor.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (más información):

IM-2: Protección del sistema de identidad y autenticación

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Principio de seguridad: proteja su sistema de identidades y autenticación con una prioridad alta en la práctica de seguridad en la nube de su organización. Controles de seguridad comunes incluyen:

  • Restricción de roles y cuentas con privilegios
  • Exigencia de autenticación sólida para todo el acceso con privilegios
  • Supervisión y auditoría de actividades de alto riesgo

Guía de Azure: use la base de referencia de seguridad de Azure AD y la puntuación de seguridad de la identidad de Azure AD para evaluar la posición de seguridad de la identidad de Azure AD y corregir las brechas de seguridad y configuración. La puntuación de seguridad de la identidad de Azure AD evalúa las siguientes configuraciones de Azure AD: Usar roles administrativos limitados

  • Activar la directiva de riesgo de usuario
  • Designar más de un administrador global
  • Habilitar la directiva para bloquear la autenticación heredada
  • Garantizar que todos los usuarios pueden completar la autenticación multifactor para el acceso seguro
  • Requerir MFA para roles administrativos
  • Habilitar el autoservicio de restablecimiento de contraseña
  • No expirar las contraseñas
  • Activar la directiva de riesgo de inicio de sesión
  • No permitir que los usuarios concedan acceso a aplicaciones no administradas

Nota: Siga los procedimientos recomendados publicados para todos los demás componentes de identidad, incluidas las funcionalidades de Active Directory local y de terceros, y las infraestructuras (como sistemas operativos, redes y bases de datos) que los hospedan.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (más información):

IM-3: Administración de identidades de aplicaciones de forma segura y automática

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
N/D AC-2, AC-3, IA-4, IA-5, IA-9 N/D

Principio de seguridad: use identidades de aplicación administradas en lugar de crear cuentas humanas para que las aplicaciones accedan a los recursos y ejecuten código. Las identidades de aplicación administradas proporcionan ventajas, como la reducción de la exposición de las credenciales. Automatice la rotación de credenciales para garantizar la seguridad de las identidades.

Guía de Azure: Use identidades administradas de Azure, que le permiten autenticarse en los servicios y recursos de Azure que admiten la autenticación de Azure AD. La plataforma administra totalmente, rota y protege las credenciales de identidad administrada, lo que evita las credenciales codificadas de forma rígida en el código fuente o en los archivos de configuración.

En el caso de los servicios que no admiten identidades administradas, use Azure AD para crear entidades de servicio con permisos restringidos a nivel de recurso. Se recomienda configurar entidades de servicio con credenciales de certificado y revertir a secretos de cliente para la autenticación.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (más información):

IM-4: Autenticación de servidores y servicios

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
N/A IA-9 N/D

Principio de seguridad: autentique los servidores y servicios remotos desde el lado cliente para asegurarse de conectarse a servicios y servidores de confianza. El protocolo de autenticación de servidores más común es Seguridad de la capa de transporte (TLS), donde el lado cliente (a menudo un explorador o dispositivo cliente) comprueba el servidor mediante la verificación de que el certificado del servidor ha sido emitido por una entidad de certificación de confianza.

Nota: La autenticación mutua se puede usar cuando tanto el servidor como el cliente se autentican entre sí.

Guía de Azure: muchos servicios de Azure admiten la autenticación TLS de manera predeterminada. En el caso de los servicios que admiten el modificador para habilitar o deshabilitar TLS por parte del usuario, asegúrese de que siempre esté habilitado para admitir la autenticación de servidores o servicios. Además, la aplicación cliente debe diseñarse para comprobar la identidad del servidor o servicio (mediante la verificación del certificado del servidor emitido por una entidad de certificación de confianza) en la fase de protocolo de enlace.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (más información):

IM-5: Uso del inicio de sesión único (SSO) para acceder a las aplicaciones

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
12.5 IA-4, IA-2, IA-8 N/D

Principio de seguridad: use el inicio de sesión único (SSO) para simplificar la experiencia del usuario para autenticarse en recursos, incluidas aplicaciones y datos en servicios en la nube y entornos locales.

Guía de Azure: use Azure AD para el acceso de las aplicaciones de carga de trabajo a través del inicio de sesión único (SSO) de Azure AD, lo que evita la necesidad de varias cuentas. Azure AD ofrece administración de identidades y acceso a recursos de Azure (plano de administración, incluida la CLI, PowerShell, el portal), aplicaciones en la nube y aplicaciones locales.

Azure AD admite el SSO para identidades empresariales, como identidades de usuario corporativo, así como identidades de usuario externo provenientes de usuarios públicos y de terceros de confianza.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (más información):

IM-6: Uso de controles de autenticación sólida

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

Principio de seguridad: aplique controles de autenticación sólida (autenticación sólida sin contraseña o autenticación multifactor) con el sistema centralizado de administración de identidades y autenticación para todo el acceso a los recursos. La autenticación basada solo en credenciales con contraseña se considera heredada, ya que no es segura y no soporta métodos de ataque populares.

Al implementar la autenticación sólida, configure primero los administradores y usuarios con privilegios para garantizar el mayor nivel del método de autenticación sólida, seguido rápidamente de la implementación de la directiva de autenticación sólida adecuada para todos los usuarios.

Nota: Si se requiere la autenticación heredada basada en contraseñas para aplicaciones y escenarios heredados, asegúrese de que se sigan los procedimientos recomendados de seguridad con contraseña, como los requisitos de complejidad.

Guía de Azure: Azure AD admite controles de autenticación sólida a través de métodos sin contraseña y autenticación multifactor (MFA).

  • Autenticación sin contraseña: Use la autenticación sin contraseña como método de autenticación predeterminado. Hay tres opciones disponibles en la autenticación sin contraseña: Windows Hello para empresas, inicio de sesión con la aplicación telefónica Microsoft Authenticator y FIDO 2Keys. Además, los clientes pueden usar métodos de autenticación locales, como tarjetas inteligentes.
  • Autenticación multifactor: Azure MFA se puede exigir a todos los usuarios, a usuarios concretos o por usuario en función de los factores de riesgo y las condiciones de inicio de sesión. Habilite Azure MFA y siga las recomendaciones de administración de identidades y acceso de Azure Defender for Cloud para la configuración de MFA.

Si la autenticación heredada basada en contraseña todavía se usa para la autenticación de Azure AD, recuerde que las cuentas solo en la nube (cuentas de usuario creadas directamente en Azure) tienen una directiva de contraseñas de base de referencia predeterminada. Además, las cuentas híbridas (cuentas de usuario que proceden de Active Directory local) siguen las directivas de contraseñas locales.

En el caso de las aplicaciones y servicios de terceros que pueden tener identificadores y contraseñas predeterminados, debe deshabilitarlos o cambiarlos durante la configuración inicial del servicio.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (más información):

IM-7: Restricción del acceso a los recursos en función de las condiciones

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Principio de seguridad: valide explícitamente las señales de confianza para permitir o denegar el acceso de los usuarios a los recursos, como parte de un modelo de acceso de confianza cero. Las señales que se van a validar deben incluir la autenticación sólida de la cuenta de usuario, el análisis del comportamiento de la cuenta de usuario, la confiabilidad del dispositivo, la pertenencia a grupos o usuarios, las ubicaciones, etc.

Guía de Azure: use el acceso condicional de Azure AD para controles de acceso más granulares basados en condiciones definidas por el usuario, como requerir inicios de sesión de usuario desde determinados intervalos IP (o dispositivos) para usar MFA. El acceso condicional de Azure AD permite exigir controles de acceso en las aplicaciones de la organización, en función de ciertas condiciones.

Defina las condiciones y los criterios aplicables para el acceso condicional de Azure AD en la carga de trabajo. Considere los siguientes casos de uso comunes:

  • Requerir la autenticación multifactor a los usuarios con roles administrativos
  • Requerir la autenticación multifactor para las tareas de administración de Azure
  • Bloquear los inicios de sesión a los usuarios que intenten usar protocolos de autenticación heredados
  • Requerir ubicaciones de confianza para el registro de Azure AD Multi-Factor Authentication
  • Bloquear o conceder el acceso desde ubicaciones concretas
  • Bloquear de comportamientos de inicio de sesión peligrosos
  • Requerir dispositivos administrados por la organización para aplicaciones concretas

Nota: También se puede usar una administración pormenorizada de las sesiones con autenticación a través de una directiva de acceso condicional de Azure AD para controles como la frecuencia de inicio de sesión y la sesión del explorador persistente.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (más información):

IM-8: Restricción de la exposición de credenciales y secretos

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Principio de seguridad: asegúrese de que los desarrolladores de aplicaciones controlen de forma segura las credenciales y los secretos:

  • Evite insertar las credenciales y secretos en los archivos de código y configuración.
  • Use un almacén de claves o un servicio seguro de almacén de claves para almacenar las credenciales y secretos.
  • Busque credenciales en el código fuente.

Nota: Esto se suele regir y aplicar a través de un ciclo de vida de desarrollo de software seguro (SDLC) y un proceso de seguridad de DevOps.

Guía de Azure: asegúrese de que los secretos y credenciales se almacenen en ubicaciones seguras, como Azure Key Vault, en lugar de insertarlos en los archivos de código y configuración.

  • Implemente Azure DevOps Credential Scanner para identificar las credenciales en el código.
  • En GitHub, use la característica nativa de análisis de secretos para identificar credenciales u otro tipo de secretos en el código.

Los clientes, como los servicios Azure Functions, Azure Apps y las VM, pueden usar identidades administradas para acceder a Azure Key Vault de manera segura. Consulte los controles de protección de datos relacionados con el uso de Azure Key Vault para la administración de secretos.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (Obtenga más información):

IM-9: Protección del acceso de los usuarios a aplicaciones existentes

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 N/D

Principio de seguridad: en un entorno híbrido, donde tiene aplicaciones locales o aplicaciones en la nube no nativas que usan la autenticación heredada, considere soluciones como el agente de seguridad de acceso a la nube (CASB), proxy de aplicación, inicio de sesión único (SSO) para regular el acceso a estas aplicaciones para obtener las siguientes ventajas:

  • Aplicación de una autenticación sólida centralizada
  • Supervisión y control de las actividades de usuarios finales de riesgo
  • Supervisión y corrección de actividades de aplicaciones heredadas de riesgo
  • Detección y prevención de la transmisión de datos confidenciales

Guía de Azure: para proteger las aplicaciones locales y en la nube no nativas que usan la autenticación heredada, conéctelas a:

  • Azure AD Application Proxy, junto con la autenticación basada en encabezados para publicar aplicaciones locales heredadas en usuarios remotos con el inicio de sesión único (SSO), a la vez que se valida explícitamente la confiabilidad de los usuarios y dispositivos remotos con el acceso condicional de Azure AD. Si es necesario, use una solución de perímetro definido por software (SDP) de terceros que pueda ofrecer una funcionalidad similar.
  • Las redes y controladores de entrega de aplicaciones existentes de terceros.
  • Microsoft Defender for Cloud Apps, usándolo como un servicio de agente de seguridad de acceso a la nube (CASB) para proporcionar controles para supervisar las sesiones de aplicación de un usuario y las acciones de bloqueo (para aplicaciones locales heredadas y aplicaciones de software como servicio (SaaS) heredadas).

Nota: Las VPN suelen usarse para acceder a las aplicaciones heredadas; a menudo tienen un control de acceso básico y una supervisión de sesión limitada.

Implementación y contexto adicional:

Partes interesadas de seguridad del cliente (más información):