Compartir a través de

Microsoft Entra ID y requisito 8 de PCI-DSS

  • Artículo

Requisito 8: identificar usuarios y autenticar el acceso a los componentes del sistema
Requisitos de enfoque definidos

8.1 Se definen y entienden los procesos y mecanismos para identificar a los usuarios y autenticar el acceso a los componentes del sistema.

Requisitos de enfoque definidos por PCI-DSS Instrucciones y recomendaciones de Microsoft Entra
8.1.1 Todas las directivas de seguridad y procedimientos operativos identificados en el requisito 8 son:
documentados
se mantienen actualizados
en uso
Conocidos por todas las partes afectadas		 Use la orientación y los enlaces que se indican a continuación para elaborar la documentación que cumpla los requisitos en función de la configuración de su entorno.
8.1.2 Las funciones y responsabilidades para llevar a cabo las actividades del Requisito 8 están documentadas, asignadas y comprendidas. Use la orientación y los enlaces que se indican a continuación para elaborar la documentación que cumpla los requisitos en función de la configuración de su entorno.
Requisitos de enfoque definidos por PCI-DSS Instrucciones y recomendaciones de Microsoft Entra
8.2.1 Todos los usuarios tienen asignado un identificador único antes de permitir el acceso a los componentes del sistema o a los datos de titulares de tarjetas. Para las aplicaciones CDE que se basan en Microsoft Entra ID, el ID de usuario único es el atributo de nombre principal de usuario (UPN). Rellenado de UserPrincipalName en Microsoft Entra
8.2.2 Las cuentas de grupo, compartidas o genéricas u otras credenciales de autenticación compartidas solo se usan cuando es necesario en función de una excepción y se administran de la siguiente manera:
Se impide el uso de la cuenta a menos que sea necesario para una circunstancia excepcional.
El uso se limita al tiempo necesario para la circunstancia excepcional.
Se documenta la justificación comercial para su uso.
El uso se aprueba explícitamente mediante la administración
La identidad de usuario individual se confirma antes de que se conceda acceso a una cuenta.
Cada acción realizada es imputable a un usuario individual.		 Asegúrate de que los CDE que usan Microsoft Entra ID para el acceso a la aplicación tengan procesos para evitar cuentas compartidas. Créalos como una excepción que requiere aprobación.
Para los recursos de CDE implementados en Azure, use identidades administradas para recursos de Azure para representar la identidad de carga de trabajo, en lugar de crear una cuenta de servicio compartido. ¿Qué son las identidades administradas de recursos de Azure?
Si no puedes usar identidades administradas y los recursos a los que se tiene acceso usan el protocolo OAuth, usa entidades de servicio para representar identidades de carga de trabajo. Concede acceso con privilegios mínimos a las identidades a través de ámbitos de OAuth. Los administradores pueden restringir el acceso y definir flujos de trabajo de aprobación para crearlos. ¿Qué son las identidades de carga de trabajo?
8.2.3 Requisito adicional solo para los proveedores de servicios: los proveedores de servicios con acceso remoto a las instalaciones del cliente usan factores de autenticación únicos para cada entorno local del cliente. Microsoft Entra ID tiene conectores locales para habilitar funcionalidades híbridas. Los conectores son identificables y usan credenciales generadas de forma única. Sincronización de Microsoft Entra Connect: comprensión y personalización de la sincronización
Análisis detallado de la sincronización en la nube
Arquitectura de aprovisionamiento de aplicaciones locales de Microsoft Entra
Planifica la aplicación de recursos humanos en la nube para el aprovisionamiento de usuarios de Microsoft Entra
Instalar los agentes de Microsoft Entra Connect Health
8.2.4 La adición, eliminación y modificación de identificadores de usuario, factores de autenticación y otros objetos de identificador se administran de la siguiente manera:
Autorizado con la aprobación adecuada.
Implementado solo con los privilegios especificados en la aprobación documentada.		 Microsoft Entra ID ha automatizado el aprovisionamiento de cuentas de usuario desde sistemas de RR. HH. Usa esta característica para crear un ciclo de vida. ¿Qué es el aprovisionamiento controlado por RR. HH.?
Microsoft Entra ID tiene flujos de trabajo de ciclo de vida para habilitar la lógica personalizada para los procesos de incorporación, transferencia y abandono. ¿Qué son los flujos de trabajo de ciclo de vida?
Microsoft Entra ID tiene una interfaz de programación para administrar los métodos de autenticación con Microsoft Graph. Algunos métodos de autenticación, como Windows Hello for Business y las claves FIDO2, requieren la intervención del usuario para registrarse. Comenzar con los métodos de autenticación de Graph
Los administradores de API y/o la automatización generan la credencial de Pase de acceso temporal mediante Graph API. Usa esta credencial para la incorporación sin contraseña. Configuración de un pase de acceso temporal en Microsoft Entra ID para registrar métodos de autenticación sin contraseña
8.2.5 El acceso de los usuarios cancelados se revoca inmediatamente. Para revocar el acceso a una cuenta, deshabilita las cuentas locales para las cuentas híbridas sincronizadas desde Microsoft Entra ID, deshabilita las cuentas en Microsoft Entra ID y revoca los tokens. Revocar el acceso de los usuarios en Microsoft Entra ID
Use la Evaluación continua de acceso (CAE) para aplicaciones compatibles para tener una conversación bidireccional con Microsoft Entra ID. Las aplicaciones pueden recibir notificaciones de eventos, como la terminación de la cuenta y rechazar tokens. Evaluación continua de acceso
8.2.6 Las cuentas de usuario inactivas se quitan o deshabilitan en un plazo de 90 días de inactividad. En el caso de las cuentas híbridas, los administradores comprueban la actividad en Active Directory y Microsoft Entra cada 90 días. Para Microsoft Entra ID, usa Microsoft Graph para buscar la última fecha de inicio de sesión. Cómo: Administración de cuentas de usuario inactivas en Microsoft Entra ID
8.2.7 Las cuentas utilizadas por terceros para acceder, respaldar o mantener los componentes del sistema a través del acceso remoto se administran de la siguiente manera:
habilitadas solo durante el período de tiempo necesario y deshabilitadas cuando no están en uso.
El uso se supervisa en busca de actividad inesperada.		 Microsoft Entra ID tiene capacidades de administración de identidades externas.
Utiliza el ciclo de vida de los huéspedes controlados con la administración de derechos. Los usuarios externos se incorporan en el contexto de aplicaciones, recursos y paquetes de acceso, que puede otorgar por un período limitado y requieren revisiones de acceso periódicas. Las revisiones pueden resultar en la eliminación o desactivación de la cuenta. Controlar el acceso para usuarios externos en la administración de derechos
Microsoft Entra ID genera eventos de riesgo en el nivel de usuario y sesión. Aprenda a proteger, detectar y responder a actividades inesperadas. ¿Qué es el riesgo?
8.2.8 Si la sesión de un usuario ha estado inactiva durante más de 15 minutos, el usuario debe volver a autenticarse para reactivar el terminal o la sesión. Usa directivas de administración de puntos de conexión con Intune y Microsoft Endpoint Manager. A continuación, usa el acceso condicional para permitir el acceso desde dispositivos compatibles. Use directivas de cumplimiento para establecer reglas para los dispositivos que administra con Intune
Si su entorno de CDE se basa en objetos de política de grupo (GPO), configure GPO para establecer un tiempo de espera inactivo. Configure Microsoft Entra ID para permitir el acceso desde Microsoft Entra dispositivos unidos híbridos. Dispositivos híbridos unidos a Microsoft Entra

8.3 Se establece y gestiona una autenticación sólida para usuarios y administradores.

Para obtener más información sobre los métodos de autenticación de Microsoft Entra que cumplen con los requisitos de PCI, consulta el Suplemento de información: autenticación de varios factores.

Requisitos del enfoque definido por PCI-DSS Instrucciones y recomendaciones de Microsoft Entra
8.3.1 Todo el acceso de los usuarios a los componentes del sistema para usuarios y administradores se autentica mediante al menos uno de los siguientes factores de autenticación:
Algo que sabes, como una contraseña o frase de contraseña.
Algo que tengas, como un dispositivo token o una tarjeta inteligente.
Algo que te represente, como un dispositivo biométrico.		 Microsoft Entra ID requiere métodos sin contraseña para cumplir con los requisitos de PCI
Consulte la implementación holística sin contraseña. Planeamiento de una implementación de autenticación sin contraseña en Id. de Microsoft Entra
8.3.2 Se utiliza la criptografía sólida para hacer que todos los factores de autenticación sean ilegibles durante la transmisión y el almacenamiento en todos los componentes del sistema. La criptografía utilizada por Microsoft Entra ID cumple con la definición PCI de criptografía fuerte. Consideraciones de protección de datos de Microsoft Entra
8.3.3 La identidad del usuario se comprueba antes de modificar cualquier factor de autenticación. Microsoft Entra ID requiere que los usuarios se autentiquen para actualizar sus métodos de autenticación mediante el autoservicio, como el portal mysecurityinfo y el portal de autoservicio de restablecimiento de contraseña (SSPR). Configurar la información de seguridad desde una página de inicio de sesión
Directiva de acceso condicional común: protección del registro de información de seguridad
Autoservicio de restablecimiento de contraseña de Microsoft Entra
Los administradores con roles privilegiados pueden modificar los factores de autenticación: Global, Contraseña, Usuario, Autenticación y Autenticación con privilegios. Roles con privilegios mínimos por tarea en Microsoft Entra ID. Microsoft recomienda habilitar el acceso y la gobernanza JIT para el acceso privilegiado mediante Microsoft Entra Privileged Identity Management
8.3.4 Los intentos de autenticación no válidos están limitados por:
Bloquear la ID de usuario después de no más de 10 intentos.
Establecer la duración del bloqueo en un mínimo de 30 minutos o hasta que se confirme la identidad del usuario.		 Implementa Windows Hello para empresas para dispositivos Windows que admitan hardware Trusted Platform Modules (TPM) 2.0 o superior.
Para Windows Hello para empresas, el bloqueo se relaciona con el dispositivo. El gesto, el PIN o la biometría desbloquea el acceso al TPM local. Los administradores configuran el comportamiento de bloqueo con directivas de GPO o Intune. Configuración de la directiva de grupo de TPM
Administrar Windows Hello para empresas en dispositivos en el momento en que los dispositivos se inscriban en Intune
Aspectos básicos de TPM
Windows Hello para empresas funciona para la autenticación local en Active Directory y recursos en la nube en Microsoft Entra ID.
Para las claves de seguridad FIDO2, la protección de fuerza bruta está relacionada con la clave. El gesto, el PIN o la biometría desbloquea el acceso al almacenamiento de claves local. Los administradores configuran Microsoft Entra ID para permitir el registro de claves de seguridad FIDO2 de fabricantes que cumplen con los requisitos de PCI. Habilitar el inicio de sesión con clave de seguridad sin contraseña

Aplicación Microsoft Authenticator
Para mitigar los ataques de fuerza bruta mediante el inicio de sesión sin contraseña de la aplicación Microsoft Authenticator, habilite la coincidencia de números y más contexto.
Microsoft Entra ID genera un número aleatorio en el flujo de autenticación. El usuario lo escribe en la aplicación autenticadora. El símbolo del sistema de autenticación de la aplicación móvil muestra la ubicación, la dirección IP de la solicitud y la aplicación de solicitud. Cómo utilizar la coincidencia de números en las notificaciones de MFA
Cómo usar contexto adicional en las notificaciones de Microsoft Authenticator
8.3.5 Si se utilizan contraseñas/frases de contraseña como factores de autenticación para cumplir con el Requisito 8.3.1, se configuran y restablecen para cada usuario de la siguiente manera:
Se configuran en un valor único para el primer uso y al restablecerse.
Obligado a ser cambiado inmediatamente después del primer uso.		 No es aplicable a Microsoft Entra ID.
8.3.6 Si se utilizan contraseñas/frases de contraseña como factores de autenticación para cumplir con el Requisito 8.3.1, cumplen con el siguiente nivel mínimo de complejidad:
Una longitud mínima de 12 caracteres (o SI el sistema no admite 12 caracteres, una longitud mínima de ocho caracteres).
Contener caracteres numéricos y alfabéticos.		 No es aplicable a Microsoft Entra ID.
8.3.7 Las personas no pueden enviar una nueva contraseña/frase de acceso que sea igual a cualquiera de las últimas cuatro contraseñas/frases de acceso utilizadas. No es aplicable a Microsoft Entra ID.
8.3.8 Las políticas y los procedimientos de autenticación se documentan y comunican a todos los usuarios, lo que incluye:
Guía sobre la selección de factores de autenticación sólidos.
Guía sobre cómo los usuarios deben proteger sus factores de autenticación.
Instrucciones para no reutilizar contraseñas/frases de acceso utilizadas anteriormente.
Instrucciones para cambiar contraseñas/frases de acceso si existe alguna sospecha o conocimiento de que las contraseñas/frases de acceso han sido comprometidas y cómo informar el incidente.		 Documenta las políticas y los procedimientos, luego comunícalo a los usuarios según este requisito. Microsoft proporciona plantillas personalizables en el Centro de descargas.
8.3.9 Si las contraseñas/frases de contraseña se utilizan como el único factor de autenticación para el acceso del usuario (es decir, en cualquier implementación de autenticación de un solo factor), entonces: Las contraseñas/frases de acceso se cambian al menos una vez cada 90 días,
O
La postura de seguridad de las cuentas se analiza dinámicamente y el acceso en tiempo real a los recursos se determina automáticamente en consecuencia.		 No es aplicable a Microsoft Entra ID.
8.3.10 Requisito adicional solo para proveedores de servicios: si se utilizan contraseñas/frases de contraseña como el único factor de autenticación para el acceso del usuario del cliente a los datos del titular de la tarjeta (es decir, en cualquier implementación de autenticación de un solo factor), se brinda orientación a los usuarios del cliente, que incluye:
Guía para que los clientes cambien sus contraseñas/frases de usuario periódicamente.
Guía sobre cuándo y bajo qué circunstancias se deben cambiar las contraseñas/frases de contraseña.		 No es aplicable a Microsoft Entra ID.
8.3.10.1 Requisito adicional solo para proveedores de servicios: si las contraseñas/frases de acceso se utilizan como el único factor de autenticación para el acceso del usuario del cliente (es decir, en cualquier implementación de autenticación de un solo factor), entonces:
Las contraseñas/frases de acceso se cambian al menos una vez cada 90 días,
O
La postura de seguridad de las cuentas se analiza dinámicamente y el acceso en tiempo real a los recursos se determina automáticamente en consecuencia.		 No es aplicable a Microsoft Entra ID.
8.3.11 Cuando se usan factores de autenticación como tokens de seguridad físicos o lógicos, tarjetas inteligentes o certificados:
Los factores se asignan a un usuario individual y no se comparten entre varios usuarios.
Los controles físicos y/o lógicos aseguran que solo el usuario previsto pueda usar ese factor para obtener acceso.		 Usa métodos de autenticación sin contraseña, como Windows Hello para empresas, claves de seguridad FIDO2 y la aplicación Microsoft Authenticator para iniciar sesión en el teléfono. Usa tarjetas inteligentes basadas en pares de claves públicas o privadas asociadas con los usuarios para evitar su reutilización.

8.4 Se implementa la autenticación multifactor (MFA) para asegurar el acceso al entorno de datos del titular de la tarjeta (CDE)

Requisitos de enfoque definidos por PCI-DSS Instrucciones y recomendaciones de Microsoft Entra
8.4.1 MFA se implementa para todos los accesos que no sean de consola al CDE para el personal con acceso administrativo. Usa el acceso condicional para requerir una autenticación sólida para acceder a los recursos del CDE. Defina directivas para tener como destino un rol administrativoo un grupo de seguridad que represente el acceso administrativo a una aplicación.
Para el acceso administrativo, usa Microsoft Entra Privileged Identity Management (PIM) para habilitar la activación justo a tiempo (JIT) de roles privilegiados. ¿Qué es el acceso condicional?
Plantillas de acceso condicional
Empezar a usar PIM
8.4.2 MFA se implementa para todo el acceso al CDE. Bloquea el acceso a protocolos heredados que no admitan autenticación sólida. Bloquear la autenticación heredada con el acceso condicional de Microsoft Entra ID
8.4.3MFA se implementa para todo acceso remoto a la red que se origine fuera de la red de la entidad que podría acceder o afectar el CDE de la siguiente manera:
Todo acceso remoto por parte de todo el personal, tanto usuarios como administradores, con origen fuera de la red de la entidad.
Todo el acceso remoto por parte de terceros y proveedores.		 Integra tecnologías de acceso como red privada virtual (VPN), escritorio remoto y puntos de acceso a la red con Microsoft Entra ID para autenticación y autorización. Usa el acceso condicional para requerir una autenticación sólida para acceder a las aplicaciones de acceso remoto. Plantillas de acceso condicional

8.5 Los sistemas de autenticación multifactor (MFA) están configurados para evitar el uso incorrecto.

Requisitos de enfoque definidos por PCI-DSS Instrucciones y recomendaciones de Microsoft Entra
8.5.1 Los sistemas MFA se implementan de la siguiente manera:
El sistema MFA no es susceptible a ataques de repetición.
Los sistemas MFA no pueden ser eludidos por ningún usuario, incluidos los usuarios administrativos, a menos que estén específicamente documentados y autorizados por la administración de forma excepcional, durante un período de tiempo limitado.
Se utilizan al menos dos tipos diferentes de factores de autenticación.
Se requiere el éxito de todos los factores de autenticación antes de que se conceda el acceso.		 Los métodos de autenticación de Microsoft Entra recomendados usan nonce o desafíos. Estos métodos resisten los ataques de reproducción porque Microsoft Entra ID detecta las transacciones de autenticación reproducidas.
Windows Hello para empresas, FIDO2 y la aplicación Microsoft Authenticator para el inicio de sesión de teléfono sin contraseña usan un nonce para identificar la solicitud y detectar intentos de reproducción. Usa credenciales sin contraseña para los usuarios en el CDE.
La autenticación basada en certificados utiliza desafíos para detectar intentos de reproducción.
Nivel de garantía del autenticador de NIST 2 con Microsoft Entra ID
Garantía del autenticador NIST 3 mediante Microsoft Entra ID

8.6 El uso de las cuentas de aplicación y del sistema, y los factores de autenticación asociados se administran estrictamente.

Requisitos de enfoque definidos por PCI-DSS Instrucciones y recomendaciones de Microsoft Entra
8.6.1 Si las cuentas utilizadas por los sistemas o las aplicaciones se pueden utilizar para el inicio de sesión interactivo, se administran de la siguiente manera:
Se impide el uso interactivo a menos que sea necesario para una circunstancia excepcional.
El uso interactivo se limita al tiempo necesario para la circunstancia excepcional.
Se documenta la justificación comercial para el uso interactivo.
El uso interactivo está explícitamente aprobado por la gerencia.
La identidad del usuario individual se confirma antes de que se conceda el acceso a la cuenta.
Cada acción realizada es imputable a un usuario individual.		 Para aplicaciones CDE con autenticación moderna y para recursos CDE implementados en Azure que usan autenticación moderna, Microsoft Entra ID tiene dos tipos de cuentas de servicio para aplicaciones: identidades administradas y entidades de servicio.
Obtener información sobre la gobernanza de cuentas de servicio de Microsoft Entra: planeación, aprovisionamiento, ciclo de vida, supervisión, revisiones de acceso, etc. Gobernanza de las cuentas de servicio de Microsoft Entra
Para proteger las cuentas de servicio de Microsoft Entra. Protección de identidades administradas en Microsoft Entra ID
Protección de entidades de servicio en Microsoft Entra ID
Para los CDE con recursos fuera de Azure que requieren acceso, configure federaciones de identidad de carga de trabajo sin administrar secretos ni iniciar sesión de forma interactiva. Federación de identidad de carga de trabajo
Para permitir que los procesos de aprobación y seguimiento cumplan con los requisitos, organice los flujos de trabajo mediante la Administración de servicios de TI (ITSM) y las bases de datos de administración de configuración (CMDB). Estas herramientas usan MS Graph API para interactuar con Microsoft Entra ID y administrar la cuenta de servicio.
Para los CDE que requieren cuentas de servicio compatibles con Active Directory local, usa cuentas de servicio administradas de grupo (GMSA) y cuentas de servicio administradas independientes (sMSA), cuentas de computadora o cuentas de usuario. Protección de cuentas de servicio locales
8.6.2 Las contraseñas/frases de acceso para cualquier aplicación y cuentas del sistema que se puedan usar para el inicio de sesión interactivo no están codificadas en scripts, archivos de configuración/propiedades o código fuente a medida y personalizado. Usa cuentas de servicio modernas como Azure Managed Identities y entidades de servicio que no requieran contraseñas.
Las credenciales de las identidades administradas de Microsoft Entra se aprovisionan y rotan en la nube, lo que evita el uso de secretos compartidos, como contraseñas y frases de contraseña. Cuando se usan identidades administradas asignadas por el sistema, el ciclo de vida está vinculado al ciclo de vida del recurso de Azure subyacente.
Usa entidades de servicio para usar certificados como credenciales, lo que evita el uso de secretos compartidos, como contraseñas y frases de contraseña. Si los certificados no son factibles, usa Azure Key Vault para almacenar los secretos de los clientes de la entidad de servicio. Procedimientos recomendados para usar Azure Key Vault
Para los CDE con recursos fuera de Azure que requieren acceso, configure las federaciones de identidades de carga de trabajo sin administrar secretos o inicio de sesión interactivo. Federación de identidades de carga de trabajo
Implemente el acceso condicional para identidades de carga de trabajo para controlar la autorización según la ubicación o el nivel de riesgo. Acceso condicional para identidades de carga de trabajo
Además de la guía anterior, use herramientas de análisis de código para detectar secretos codificados en archivos de configuración y código. Detectar secretos expuestos en el código
Reglas de seguridad
8.6.3 Las contraseñas/frases de acceso para cualquier aplicación y cuentas del sistema están protegidas contra el uso indebido de la siguiente manera:
Las contraseñas/frases de contraseña se cambian periódicamente (con la frecuencia definida en el análisis de riesgo específico de la entidad, que se realiza de acuerdo con todos los elementos especificados en el Requisito 12.3.1) y ante la sospecha o confirmación de compromiso.
Las contraseñas/frases de acceso se construyen con suficiente complejidad apropiada para la frecuencia con la que la entidad cambia las contraseñas/frases de acceso.		 Usa cuentas de servicio modernas como Azure Managed Identities y entidades de servicio que no requieran contraseñas.
Para las excepciones que requieren entidades de servicio con secretos, el ciclo de vida de secreto abstracto con flujos de trabajo y automatizaciones que establece contraseñas aleatorias para las entidades de servicio, las rota periódicamente y reacciona ante eventos de riesgo.
Los equipos de operaciones de seguridad pueden revisar y corregir los informes generados por Microsoft Entra, como las identidades de cargas de trabajo de riesgo. Protección de identidades de carga de trabajo con la versión preliminar de Identity Protection

Pasos siguientes

Los requisitos 3, 4, 9 y 12 de PCI-DSS no son aplicables a Microsoft Entra ID, por lo que no hay artículos correspondientes. Para ver todos los requisitos, visite pcisecuritystandards.org: Sitio oficial del Consejo sobre el Estándar de Seguridad de Datos para la PCI.

Para configurar Microsoft Entra ID de modo que cumpla con PCI-DSS, consulte los siguientes artículos.