Microsoft Entra ID y requisito 6 de PCI-DSS
Requisito 6: Desarrollar y mantener sistemas y software seguros
Requisitos del enfoque definido
6.1 Los procesos y mecanismos para desarrollar y mantener sistemas y software seguros se definen y se entienden.
Requisitos del enfoque definido por PCI-DSS | Instrucciones y recomendaciones de Microsoft Entra |
---|---|
6.1.1 Todas las directivas de seguridad y procedimientos operativos identificados en el Requisito 6 están: Documentados Actualizados a la fecha En uso Son conocidos por todas las partes afectadas |
Use la guía 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. |
6.1.2 Las funciones y responsabilidades para llevar a cabo las actividades del Requisito 6 están documentadas, asignadas y se entienden. | Use la guía 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. |
6.2 El software personalizado y hecho a la medida se desarrolla de forma segura.
Requisitos del enfoque definido por PCI-DSS | Instrucciones y recomendaciones de Microsoft Entra |
---|---|
6.2.1 El software personalizado y hecho a la medida se desarrolla de forma segura como se indica a continuación: Se basa en los estándares del sector y/o en procedimientos recomendados para el desarrollo seguro. Concuerda con PCI-DSS (por ejemplo, registro y autenticación seguros). Incorpora las consideraciones sobre problemas de seguridad de la información durante cada fase del ciclo de vida de desarrollo del software. |
Adquiere y desarrolla aplicaciones que usan protocolos de autenticación modernos, como OAuth2 y OpenID Connect (OIDC), que se integran con Microsoft Entra ID. Compila el software mediante la Plataforma de identidad de Microsoft. Procedimientos recomendados y recomendaciones de la plataforma de identidad de Microsoft |
6.2.2 El personal de desarrollo de software que trabaja en software personalizado y hecho a la medida se entrena al menos una vez cada 12 meses de la siguiente manera: En la seguridad del software relevante para su función de trabajo y lenguajes de desarrollo. Incluye técnicas de diseño de software seguro y codificación segura. Incluye, si usa herramientas de pruebas de seguridad, cómo usar dichas herramientas para detectar vulnerabilidades en el software. |
Use el siguiente examen para proporcionar una prueba de competencia en la Plataforma de identidad de Microsoft: Examen MS-600: Compilar aplicaciones y soluciones con Microsoft 365 Core Services Use el siguiente entrenamiento para prepararse para el examen: MS-600: Implementación de la identidad de Microsoft |
6.2.3 El software personalizado y hecho a la medida se revisa antes de su lanzamiento para producción o para los clientes, de forma de identificar y corregir posibles vulnerabilidades en la codificación, como se indica a continuación: Las revisiones de código garantizan que el código se desarrolle según las directrices de codificación seguras. Las revisiones de código buscan vulnerabilidades de software existentes y emergentes. Se implementan las correcciones correspondientes antes del lanzamiento. |
No es aplicable a Microsoft Entra ID. |
6.2.3.1 Si las revisiones de código manual se realizan para el software personalizado y hecho a la medida antes de su lanzamiento para producción, los cambios de código son: Revisados por personas que no sean el autor del código de origen y que conocen las técnicas de revisión de código y las prácticas de codificación seguras. Revisados y aprobados por la gerencia antes del lanzamiento. |
No es aplicable a Microsoft Entra ID. |
6.2.4 Las técnicas de ingeniería de software u otros métodos se definen y usan por el personal de desarrollo de software para evitar o mitigar ataques de software comunes y vulnerabilidades relacionadas en el software personalizado y hecho a la medida, incluidos, entre otros: Ataques por inyección, incluidos los ataques SQL, LDAP, XPath u otros errores de comando, parámetro, objetos o de tipo de inyección. Ataques en los datos y las estructuras de datos, incluidos los intentos de manipular búferes, punteros, datos de entrada o datos compartidos. Ataques al uso de criptografía, incluidos los intentos de vulnerar la seguridad de implementaciones criptográficas, algoritmos, conjuntos de cifrado o modos de funcionamiento débiles, poco seguros o inapropiados. Ataques en la lógica de negocios, incluidos los intentos de abuso u omisión de características y funcionalidades de la aplicación a través de la manipulación de las API, los protocolos de comunicación y los canales, la funcionalidad del lado cliente u otras funciones y recursos del sistema o la aplicación. Esto incluye scripting entre sitios (XSS) y falsificación de solicitudes entre sitios (CSRF). Ataques a los mecanismos de control de acceso, incluidos intentos de omisión o abuso de la identificación, mecanismos de autenticación o autorización, o intentos de vulnerar la seguridad a través de puntos débiles en la implementación de dichos mecanismos. Ataques a través de las vulnerabilidades de "alto riesgo" identificadas en el proceso de identificación de vulnerabilidades, tal como se define en el Requisito 6.3.1. |
No es aplicable a Microsoft Entra ID. |
6.3 Las vulnerabilidades de seguridad se identifican y se abordan.
Requisitos del enfoque definido por PCI-DSS | Instrucciones y recomendaciones de Microsoft Entra |
---|---|
6.3.1 Las vulnerabilidades de seguridad se identifican y administran de la siguiente manera: Las nuevas vulnerabilidades de seguridad se identifican mediante orígenes reconocidos por el sector para obtener información sobre las vulnerabilidades de seguridad, incluidas las alertas de los equipos de respuesta de emergencia informática (CERT) internacionales y nacionales o regionales. A las vulnerabilidades se les asigna una clasificación de riesgos basada en los procedimientos recomendados del sector y en la consideración del posible impacto. Las clasificaciones de riesgo deben, como mínimo, identificar todas las vulnerabilidades que se consideren de alto riesgo o críticas para el entorno. Se tratan las vulnerabilidades del software personalizado y hecho a la medida (por ejemplo, sistemas operativos y bases de datos). |
Aprenda sobre las vulnerabilidades. MSRC | Guía de actualización de seguridad, actualizaciones de seguridad |
6.3.2 Se mantiene un inventario del software personalizado y hecho a la medida y de los componentes del software de terceros incorporados en el software personalizado y hecho a la medida para facilitar la gestión de vulnerabilidades y las revisiones. | Genere informes para las aplicaciones que usen Microsoft Entra ID para la autenticación para el inventario. Tipo de recurso applicationSignInDetailedSummary Aplicaciones enumeradas en aplicaciones empresariales |
6.3.3 Todos los componentes del sistema están protegidos frente a vulnerabilidades conocidas mediante la instalación de actualizaciones o revisiones de seguridad aplicables de la siguiente manera: Las revisiones o actualizaciones críticas o de alta seguridad (identificadas según el proceso de clasificación de riesgos en el Requisito 6.3.1) se instalan dentro del mes posterior al lanzamiento. Todas las demás revisiones o actualizaciones de seguridad aplicables se instalan dentro de un plazo de tiempo adecuado que determine la entidad (por ejemplo, en un plazo de tres meses después del lanzamiento). |
No es aplicable a Microsoft Entra ID. |
6.4 Las aplicaciones web de acceso público están protegidas contra ataques.
Requisitos del enfoque definido por PCI-DSS | Instrucciones y recomendaciones de Microsoft Entra |
---|---|
6.4.1 En el caso de las aplicaciones web orientadas al público, las nuevas amenazas y vulnerabilidades se abordan de forma continua y estas aplicaciones están protegidas contra ataques conocidos de la siguiente manera: Revisión de las aplicaciones web orientadas al público a través de herramientas o métodos de evaluación de vulnerabilidades de seguridad de las aplicaciones manuales o automatizadas de la siguiente manera: : Al menos una vez cada 12 meses y después de cambios significativos. : Por una entidad especializada en la seguridad de aplicaciones. : Incluye, como mínimo, todos los ataques de software comunes descritos en el Requisito 6.2.4. : Todas las vulnerabilidades se clasifican de acuerdo con el Requisito 6.3.1. : Se corrigen todas las vulnerabilidades. : La aplicación se vuelve a evaluar después de las correcciones O Se instala una solución técnica automatizada que detecte y evite continuamente ataques basados en la web de la siguiente manera: : Se instala delante de las aplicaciones web orientadas al público para detectar y evitar ataques basados en la web. : Se ejecuta y actualiza activamente, según corresponda. : Genera registros de auditoría. : Está configurada para bloquear ataques basados en la web o generar una alerta que se investiga inmediatamente. |
No es aplicable a Microsoft Entra ID. |
6.4.2 En el caso de las aplicaciones web orientadas al público, se implementa una solución técnica automatizada que detecta y evita continuamente ataques basados en la web, con al menos lo siguiente: Se instala delante de las aplicaciones web orientadas al público y está configurada para detectar y evitar ataques basados en la web. Se ejecuta y actualiza activamente, según corresponda. Genera registros de auditoría. Está configurada para bloquear ataques basados en la web o generar una alerta que se investiga inmediatamente. |
No es aplicable a Microsoft Entra ID. |
6.4.3 Todos los scripts de la página de pago que se cargan y ejecutan en el explorador del consumidor se administran de la siguiente manera: Se implementa un método para confirmar que cada script esté autorizado. Se implementa un método para garantizar la integridad de cada script. Se mantiene un inventario de todos los scripts con una justificación escrita de por qué cada uno es necesario. |
No es aplicable a Microsoft Entra ID. |
6.5 Los cambios en todos los componentes del sistema se administran de forma segura.
Requisitos del enfoque definido por PCI-DSS | Instrucciones y recomendaciones de Microsoft Entra |
---|---|
6.5.1 Los cambios realizados en todos los componentes del sistema en el entorno de producción se realizan de acuerdo con los procedimientos establecidos que incluyen: El motivo y la descripción del cambio. La documentación del impacto en la seguridad. La aprobación del cambio documentado generada por las partes autorizadas. Una prueba para comprobar que el cambio no afecte negativamente a la seguridad del sistema. Para los cambios de software personalizados y hechos a la medida, todas las actualizaciones se prueban para cumplir con el Requisito 6.2.4 antes de implementarse en producción. Procedimientos para solucionar errores y volver a un estado seguro. |
Se incluyen los cambios en la configuración de Microsoft Entra en el proceso de control de cambios. |
6.5.2 Tras la finalización de un cambio importante, se deben implementar todos los requisitos pertinentes de PCI-DSS en todas las redes y sistemas nuevos o modificados, así como en la documentación actualizada según corresponda. | No es aplicable a Microsoft Entra ID. |
6.5.3 Los entornos de preproducción están separados de los entornos de producción y la separación se aplica con controles de acceso. | Los enfoques para separar los entornos de preproducción y producción se hacen en función de los requisitos de la organización. Aislamiento de recursos en un solo inquilino Aislamiento de recursos con varios inquilinos |
6.5.4 Los roles y las funciones se separan entre los entornos de producción y preproducción para generar responsabilidad, de modo que solo se implementen los cambios revisados y aprobados. | Aprenda sobre los roles con privilegios y los inquilinos de preproducción dedicados. Procedimientos recomendados para los roles de Microsoft Entra |
6.5.5 Las PAN en directo no se usan en entornos de preproducción, excepto cuando esos entornos se incluyen en el CDE y están protegidos de acuerdo con todos los requisitos de PCI-DSS aplicables. | No es aplicable a Microsoft Entra ID. |
6.5.6 Los datos de prueba y las cuentas de prueba se quitan de los componentes del sistema antes de que el sistema entre en producción. | No es aplicable a Microsoft Entra ID. |
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.
- Guía de Microsoft Entra PCI-DSS
- Requisito 1: instalar y mantener controles de seguridad de red
- Requisito 2: aplicar configuraciones seguras a todos los componentes del sistema
- Requisito 5: Proteger todos los sistemas y redes contra el software malintencionado
- Requisito 6: Desarrollar y mantener sistemas y software seguros (Usted está aquí)
- Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de los titulares de tarjetas por necesidad empresarial
- Requisito 8: identificar a los usuarios y autenticar el acceso a los componentes del sistema
- Requisito 10: Registrar y supervisar todo el acceso a componentes del sistema y datos de titulares de tarjetas
- Requisito 11: Probar periódicamente la seguridad de sistemas y redes
- Guía de autenticación multifactor de PCI-DSS de Microsoft Entra