Administración de acceso de un clúster de línea de base de AKS para PCI-DSS 3.2.1 (parte 6 de 9)

En este artículo se describen las consideraciones para un clúster de Azure Kubernetes Service (AKS) configurado de acuerdo con el estándar de seguridad de datos del sector de tarjetas de pago (PCI-DSS 3.2.1).

Este artículo forma parte de una serie. Lea la introducción.

Kubernetes tiene un control de acceso basado en rol (RBAC) que administra los permisos para la API de Kubernetes. Hay varios roles integrados con permisos o acciones específicos en los recursos de Kubernetes. Azure Kubernetes Service (AKS) admite esos roles integrados y roles personalizados para un control pormenorizado. Estas acciones se pueden autorizar (o denegar) a un usuario mediante RBAC de Kubernetes.

Esta arquitectura y la implementación no están diseñadas para proporcionar controles sobre el acceso físico a los recursos o centros de datos locales. Una ventaja de hospedar el CDE en Azure, en lugar de en la plataforma perimetral o en el centro de datos, es que la restricción del acceso físico ya se controla principalmente a través de la seguridad del centro de datos de Azure. No hay ninguna responsabilidad para la organización en la administración del hardware físico.

Implementación de medidas de control de acceso sólidas

Requisito 7: Restricción del acceso a los datos de los titulares de las tarjetas según la información que necesiten las empresas

Compatibilidad con características de AKS

AKS está totalmente integrado con Microsoft Entra ID como proveedor de identidades.

No tiene que administrar identidades de usuario y credenciales independientes para Kubernetes. Puede agregar usuarios de Microsoft Entra para RBAC de Kubernetes. Esta integración permite asignar roles a usuarios de Microsoft Entra. Mediante el uso de identidades de Microsoft Entra, puede usar una variedad de roles integrados, como visor, escritor, administrador de servicios y administrador de clústeres. También puede crear roles personalizados para un control más pormenorizado.

De forma predeterminada, Azure RBAC está establecido para denegar cualquier acceso, por lo que no se puede acceder a un recurso sin permisos concedidos. AKS limita el acceso SSH a los nodos de trabajo de AKS y usa la directiva de red de AKS para controlar el acceso a las cargas de trabajo en los pods.

Para más información, consulte Uso de Azure RBAC para la autorización de Kubernetes y Protección del clúster con Azure Policy.

Sus responsabilidades

Requisito	Responsabilidad
Requisito 7.1	Limite el acceso a los componentes del sistema y los datos de los titulares de las tarjetas solo a aquellas personas cuyo trabajo exige ese acceso.
Requisito 7.2	Establezca un sistema de control de acceso para los componentes del sistema que restrinja el acceso en función de la información que necesiten los usuarios y que esté configurado en "denegar todo", salvo que se permita de manera específica.
Requisito 7.3	Asegúrese de que las directivas de seguridad y los procedimientos operativos para restringir el acceso físico a los datos de los titulares de las tarjetas estén documentados, en uso, y que los conocen todas las partes afectadas.

Requisito 7.1

Limite el acceso a los componentes del sistema y los datos de los titulares de las tarjetas solo a aquellas personas cuyo trabajo exige ese acceso.

Sus responsabilidades

A continuación, se indican algunas consideraciones:

• Asegúrese de que la implementación está alineada con los requisitos de la organización y con los requisitos de cumplimiento sobre la administración de identidades.
• Minimice los permisos permanentes especialmente para las cuentas de impacto crítico.
• Siga el principio de acceso con privilegios mínimos. Proporcione tan solo el acceso suficiente para completar la tarea.

Requisito 7.1.1

Defina las necesidades de acceso para cada rol, entre las que se incluyen:

• Componentes del sistema y recursos de datos a los que necesita acceder cada rol para realizar su trabajo
• Nivel de privilegio necesario (por ejemplo, usuario, administrador, etc.) para acceder a los recursos.

Sus responsabilidades

Defina roles basados en las tareas y las responsabilidades necesarias para los componentes del ámbito y su interacción con los recursos de Azure. Puede empezar con categorías amplias, como:

• Ámbito por grupos de administración, suscripciones o grupos de recursos de Azure
• Azure Policy para la carga de trabajo o la suscripción
• Operaciones de contenedor
• Administración de secretos
• Canalizaciones de compilación e implementación

Aunque la definición de roles y responsabilidades en torno a esas áreas puede estar asociada a la estructura del equipo, céntrese en el requisito de la carga de trabajo. Por ejemplo, determine quién es responsable de mantener la seguridad, el aislamiento, la implementación y la observabilidad. Estos son algunos ejemplos:

• Decida las configuraciones sobre la seguridad de las aplicaciones, RBAC de Kubernetes, directivas de red, directivas de Azure y comunicación con otros servicios.
• Configure y mantenga Azure Firewall, firewall de aplicaciones web (WAF), grupos de seguridad de red (NSG) y DNS.
• Supervisión y corrección de la seguridad del servidor, aplicación de revisiones, configuración y seguridad de los puntos de conexión.
• Establezca la dirección de uso de RBAC, Microsoft Defender for Cloud, la estrategia de protección del administrador y Azure Policy para controlar los recursos de Azure.
• Identifique el equipo de supervisión de incidentes y respuesta. Investigue y corrija los incidentes de seguridad mediante un sistema de administración de eventos e información de seguridad (SIEM) como Microsoft Sentinel o Microsoft Defender for Cloud.

A continuación, formalice la definición mediante la determinación de qué nivel de acceso es necesario para el rol con respecto a la carga de trabajo y la infraestructura. Esta es una definición sencilla con fines ilustrativos.

Role	Responsabilidades	Niveles de acceso
Propietarios de la aplicación	Definir y priorizar características que se alinean con los resultados empresariales. Entienden cómo afectan las características al ámbito de cumplimiento de la carga de trabajo y equilibran la propiedad y la protección de los datos de los clientes con los objetivos empresariales.	Acceso de lectura a los registros y métricas emitidos por la aplicación. No necesitan permisos para acceder a la carga de trabajo o al clúster.
Desarrolladores de aplicaciones	Desarrollar la aplicación. Todo el código de la aplicación está sujeto a entrenamiento y puertas de calidad que respetan los procesos de cumplimiento, atestación y administración de versiones. Pueden administrar las canalizaciones de compilación, pero normalmente no las canalizaciones de implementación.	Acceso de lectura a los espacios de nombres de Kubernetes y a los recursos de Azure que están en el ámbito de la carga de trabajo. No hay acceso de escritura para implementar o modificar algún estado del sistema.
Operadores de aplicación (o SRE)	Tener un conocimiento profundo de la base de código, la observabilidad y las operaciones. Realizar la evaluación de prioridades en el sitio activo y la solución de problemas. Junto con los desarrolladores de aplicaciones, mejorar la disponibilidad, la escalabilidad y el rendimiento de la aplicación. Administrar la canalización de implementación de la "recta final" y ayudar a administrar las canalizaciones de compilación.	Privilegios elevados dentro del ámbito de la aplicación que incluye espacios de nombres de Kubernetes y recursos de Azure relacionados. Es probable que tengan acceso permanente a partes del clúster de Kubernetes.
Propietarios de infraestructura	Diseñar una arquitectura rentable, incluida su conectividad y la funcionalidad de los componentes. El ámbito puede incluir servicios en la nube y locales. Decidir la retención de datos de funcionalidades, características de continuidad empresarial y otras.	Acceso a los registros de la plataforma y a los datos del centro de coste. No se requiere acceso en el clúster.
Operadores de infraestructura (o SRE)	Operaciones relacionadas con el clúster y los servicios dependientes. Compilar, implementar y arrancar la canalización para el clúster en el que se implementa la carga de trabajo. Establezca los grupos de nodos de destino y los requisitos de tamaño y escala previstos. Supervisar el estado de la infraestructura de hospedaje del contenedor y los servicios dependientes.	Acceso de lectura a los espacios de nombres de carga de trabajo. Acceso con privilegios elevados para el clúster.
Propietarios de directivas, seguridad	Tener experiencia en el cumplimiento normativo o de seguridad. Definir directivas que protejan la seguridad y el cumplimiento normativo de los empleados de la empresa, sus recursos y los de los clientes de la empresa. Funciona con todos los demás roles para garantizar de que la directiva se aplica y se puede auditar en todas las fases.	Acceso de lectura a la carga de trabajo y al clúster. Acceso también a los datos de registro y auditoría.
Operadores de red	Asignación de red virtual y subredes en toda la empresa. Configuración y mantenimiento de Azure Firewall, WAF, NSG y configuración DNS.	Privilegios elevados en la capa de red. Sin permiso de escritura en el clúster.

Requisito 7.1.2

Restrinja el acceso a los id. de usuario con privilegios a los privilegios mínimos para realizar su trabajo.

Sus responsabilidades

En función de las funciones del trabajo, esfuércese por minimizar el acceso sin causar interrupciones. Estos son algunos procedimientos recomendados:

• Reduzca el acceso que requiere cada identidad. Una identidad debe tener suficiente acceso para completar su tarea.
• Minimice los permisos permanentes, especialmente en las identidades de impacto crítico que tienen acceso a los componentes dentro del ámbito.
• Agregue restricciones adicionales siempre que sea posible. Una manera es proporcionar acceso condicional en función de los criterios de acceso.
• Realice una revisión y auditoría periódicas de los usuarios y grupos que tienen acceso en las suscripciones, incluso para el acceso de lectura. Evite invitar a identidades externas.

Requisito 7.1.3

Asigne el acceso según la clasificación del trabajo y la función de cada persona.

Sus responsabilidades

Determine los permisos en función de las obligaciones de trabajo asignadas claramente a la persona. Evite parámetros como el sistema o la permanencia del empleado. Conceda derechos de acceso a un solo usuario o a un grupo.

A continuación se muestran algunos ejemplos.

Clasificación del trabajo	Role
El propietario de un producto define el ámbito de la carga de trabajo y da prioridad a las características. Equilibra la protección y la propiedad de los datos de los clientes con los objetivos empresariales. Necesita acceso a los informes, centro de coste o paneles de Azure. No se necesita acceso para los permisos en clúster o de nivel de clúster.	Propietarios de la aplicación
Un ingeniero de software diseña, desarrolla e incluye en contenedores el código de la aplicación. Un grupo con permisos de lectura permanentes dentro de ámbitos definidos en Azure (como Application Insights) y los espacios de nombres de carga de trabajo. Estos ámbitos y permisos pueden ser diferentes entre los entornos de preproducción y producción.	Desarrollador de aplicaciones
Un ingeniero de confiabilidad de sitios realiza la evaluación de prioridades del sitio activo, administra las canalizaciones y configura la infraestructura de la aplicación. Grupo A con control total dentro de sus espacios de nombres asignados. No se necesitan permisos permanentes. Grupo B para las operaciones diarias de la carga de trabajo. Puede tener permisos permanentes dentro de sus espacios de nombres asignados, pero no tienen privilegios elevados.	Operadores de aplicación
Un operador de clúster diseña e implementa un clúster de AKS confiable y seguro en la plataforma. Responsable de mantener el tiempo de actividad del clúster. Grupo A con control total dentro de sus espacios de nombres asignados. No se necesitan permisos permanentes. Grupo B para las operaciones diarias de la carga de trabajo. Puede tener permisos permanentes dentro de sus espacios de nombres asignados, pero no tienen privilegios elevados.	Operadores de infraestructura
Un ingeniero de red asigna la red virtual y las subredes de toda la empresa, la conectividad local a la nube y la seguridad de red.	Operadores de infraestructura

Requisito 7.1.4

Requiera la aprobación documentada de las partes autorizadas que especifique los privilegios necesarios.

Sus responsabilidades

Disponga de un proceso con puertas para aprobar los cambios en roles y permisos, incluida la asignación inicial de privilegios. Asegúrese de que esas aprobaciones están documentadas y disponibles para la inspección.

Requisito 7.2

Establezca un sistema de control de acceso para los componentes del sistema que restrinja el acceso en función de la información que necesiten los usuarios y que esté configurado en "denegar todo", salvo que se permita de manera específica.

Sus responsabilidades

Después de seguir el requisito 7.1, debe haber evaluado los roles y las responsabilidades aplicables a la organización y a la carga de trabajo. Todos los componentes de la arquitectura que están dentro del ámbito deben tener acceso restringido. Esto incluye los nodos de AKS que ejecutan la carga de trabajo, el almacenamiento de datos, el acceso a la red y todos los demás servicios que participan en el procesamiento de los datos de los titulares de las tarjetas (CHD).

En función de los roles y las responsabilidades, asigne roles al control de acceso basado en rol (RBAC) de la infraestructura. Este mecanismo puede ser:

• RBAC de Kubernetes es un modelo de autorización nativo de Kubernetes que controla el acceso al plano de control de Kubernetes, expuesto a través del servidor de API de Kubernetes. Este conjunto de permisos define lo que puede hacer con el servidor de API. Por ejemplo, puede denegar a un usuario los permisos para crear o incluso enumerar pods.
• Azure RBAC es un modelo de autorización basado en Microsoft Entra ID que controla el acceso al plano de control de Azure. Se trata de una asociación del inquilino de Microsoft Entra con su suscripción de Azure. Con Azure RBAC puede conceder permisos para crear recursos de Azure, como redes, un clúster de AKS e identidades administradas.

Suponga que necesita conceder permisos a los operadores del clúster (asignados al rol de operador de infraestructura). Todas las personas a las que se asignan las responsabilidades de operador de infraestructura pertenecen a un grupo de Microsoft Entra. Como se estableció en el requisito 7.1.1, este rol requiere el privilegio más alto en el clúster. Kubernetes tiene roles RBAC integrados, como cluster-admin, que cumplen esos requisitos. Deberá enlazar el grupo de Microsoft Entra para el operador de infraestructura a cluster-admin mediante la creación de enlaces de rol. Existen dos enfoques. Puede elegir los roles integrados. O bien, si los roles integrados no cumplen sus requisitos (por ejemplo, pueden ser muy permisivos), puede crear roles personalizados para los enlaces.

La implementación de referencia muestra el ejemplo anterior mediante el uso de RBAC nativo de Kubernetes. Se puede lograr la misma asociación con Azure RBAC. Para más información, vea Administración del acceso a recursos de clúster mediante el control de acceso basado en roles de Kubernetes y las identidades de Microsoft Entra en Azure Kubernetes Service.

Puede elegir el ámbito de permiso en el nivel de clúster o en el nivel de espacio de nombres. Para los roles que tienen responsabilidades con ámbito, como los operadores de aplicación, los permisos se asignan en el nivel de espacio de nombres para la carga de trabajo.

Además, los roles también necesitan permisos de Azure RBAC para que puedan realizar sus tareas. Por ejemplo, el operador de clúster debe acceder a Azure Monitor a través del portal. Por lo tanto, el rol de operador de infraestructura debe tener la asignación adecuada de RBAC.

Además de las personas y sus roles, los recursos de Azure e incluso los pods del clúster tienen identidades administradas. Esas identidades necesitan un conjunto de permisos a través de Azure RBAC y deben tener un ámbito estricto en función de las tareas esperadas. Por ejemplo, Azure Application Gateway debe tener permisos para obtener secretos (certificados TLS) de Azure Key Vault. No debe tener permisos para modificar los secretos.

Estos son algunos procedimientos recomendados:

• Mantenga una documentación meticulosa sobre cada rol y los permisos asignados, así como las justificaciones. Mantenga una distinción clara sobre qué permisos son JIT y cuáles son permanentes.

• Supervise los roles en busca de cambios, como los cambios de asignación o definiciones de roles. Cree alertas sobre los cambios incluso si se espera que obtengan visibilidad sobre las intenciones de los cambios.

Requisito 7.2.1

Cobertura de todos los componentes del sistema

Sus responsabilidades

Estos son algunos procedimientos recomendados para mantener las medidas de control de acceso:

• No tenga acceso permanente. Considere la posibilidad de usar la pertenencia a grupos de AD Just-In-Time. Esta característica requiere Microsoft Entra Privileged Identity Management.

• Configure las directivas de acceso condicional en Microsoft Entra ID para el clúster. Esto impone más restricciones en el acceso al plano de control de Kubernetes. Con las directivas de acceso condicional, puede requerir la autenticación multifactor, restringir la autenticación a los dispositivos administrados por el inquilino de Microsoft Entra o bloquear intentos de inicio de sesión que no son típicos. Aplique estas directivas a los grupos de Microsoft Entra asignados a roles de Kubernetes con privilegios elevados.

  Nota:

  Las opciones de tecnología de acceso condicional y JIT requieren licencias de Microsoft Entra ID P1 o P2.

• Lo ideal es deshabilitar el acceso SSH a los nodos del clúster. Esta implementación de referencia no genera detalles de conexión SSH para ese propósito.

• Los usuarios autorizados deben acceder a cualquier proceso adicional, como jumpboxes. No cree inicios de sesión genéricos disponibles para todo el equipo.

Requisito 7.2.2

Asignación de privilegios a personas según la clasificación del trabajo y función.

Sus responsabilidades

Según la versión 7.1.3, habrá muchos roles implicados en las operaciones de clúster. Además de los roles de recursos estándar de Azure, deberá definir la extensión y el proceso de acceso.

Por ejemplo, considere el rol de operador de clúster. Debe tener un cuaderno de estrategias claramente definido para las actividades de evaluación de prioridades del clúster. ¿En qué se diferencia ese acceso del equipo de cargas de trabajo? En función de su organización, puede que sean iguales. Estos son algunos puntos que se deben tener en cuenta:

• ¿Cómo deben acceder al clúster?
• ¿Qué orígenes se permiten para el acceso?
• ¿Qué permisos deben tener en el clúster?
• ¿Cuándo se asignan esos permisos?

Asegúrese de que las definiciones se documentan en la documentación de gobernanza, directivas y materiales de entrenamiento del operador de carga de trabajo y del operador del clúster.

Requisito 7.2.3

Configuración "denegar todo" predeterminada.

Sus responsabilidades

Al iniciar la configuración, comience con directivas de confianza cero. Establezca excepciones según sea necesario y documéntelas con detalle.

• RBAC de Kubernetes implementa denegar todo de forma predeterminada. No lo reemplace agregando enlaces de rol de clúster altamente permisivos que inviertan la configuración de denegar todo.

• Azure RBAC también implementa denegar todo de forma predeterminada. No lo reemplace agregando asignaciones de RBAC que inviertan la configuración de denegar todo.

• Todos los servicios de Azure, incluidos Azure Key Vault y Azure Container Registry, deniegan todos los permisos de manera predeterminada.

• Cualquier punto de acceso administrativo, como un jumpbox, debe denegar todo el acceso en la configuración inicial. Todos los permisos elevados deben definirse explícitamente para invalidar la regla de denegar todo.

Requisito 7.3

Asegúrese de que las directivas de seguridad y los procedimientos operativos para restringir el acceso físico a los datos de los titulares de las tarjetas estén documentados, en uso, y que los conocen todas las partes afectadas.

Sus responsabilidades

Es fundamental mantener una documentación exhaustiva sobre los procesos y las directivas. Esto incluye las directivas de RBAC de Kubernetes y Azure, y las directivas de gobernanza de la organización. Las personas que operan en entornos regulados deben estar formadas e informadas y se les debe incentivar para respaldar las garantías de seguridad. Esto es especialmente importante para las personas que forman parte del proceso de aprobación desde una perspectiva de directiva.

Requisito 8: Identificación y autenticación del acceso a los componentes del sistema

Compatibilidad de características de AKS

Gracias a la integración de AKS y Microsoft Entra, puede aprovechar las capacidades de autorización y administración de identidades, incluida la administración de acceso, la administración de objetos de identificador, etc. Para más información, consulte Integración de Microsoft Entra administrado por AKS.

Sus responsabilidades

Requisito	Responsabilidad
Requisito 8.1	Defina e implemente directivas y procedimientos que garanticen que la administración de la identificación de usuarios administradores y no consumidores sea adecuada en todos los componentes del sistema, como se indica a continuación:
Requisito 8.2	Además de asignar un id. único, debe garantizarse una administración correcta de la autenticación de administradores y usuarios no consumidores en todos los componentes del sistema mediante el uso de al menos uno de los métodos siguientes para autenticar a todos los usuarios:
Requisito 8.3	Proteja mediante la autenticación multifactor todos los accesos individuales a CDE, tanto los administrativos que no se hagan a través de la consola como los realizados desde sistemas remotos.
Requisito 8.4	Documente las directivas y los procedimientos de autenticación y comuníquelos a todos los usuarios, incluido lo siguiente:
Requisito 8.5	No use identificadores, contraseñas u otros métodos de autenticación que sean grupales, compartidos o genéricos, de la manera siguiente:
Requisito 8.6	Cuando se usan otros mecanismos de autenticación (por ejemplo, tokens de seguridad físicos o lógicos, tarjetas inteligentes, certificados, etc.), el uso de estos mecanismos debe asignarse de la manera siguiente:
Requisito 8.7	Todo acceso a cualquier base de datos que contenga información de los titulares de las tarjetas (incluido el acceso por parte de aplicaciones, administradores y demás usuarios) se restringe de la manera siguiente:
Requisito 8.8	Asegúrese de que las directivas de seguridad y los procedimientos operativos para la identificación y autenticación estén documentados, en uso, y que todas las partes afectadas los conozcan.

Requisito 8.1

Defina e implemente directivas y procedimientos que garanticen que la administración de la identificación de usuarios administradores y no consumidores sea adecuada en todos los componentes del sistema, como se indica a continuación:

• 8.1.1 Asigne un identificador único a todos los usuarios antes de permitirles el acceso a componentes del sistema o a datos de los titulares de tarjetas.
• 8.1.2 Controle la adición, eliminación y modificación de identificadores de usuario, credenciales y otros objetos de identificación.
• 8.1.3 Revoque de inmediato el acceso a los usuarios finalizados.
• 8.1.4 Quite o deshabilite las cuentas de usuario inactivas en un plazo de 90 días.
• 8.1.5 Administre los identificadores usados por terceros para tener acceso a los componentes del sistema a través de acceso remoto, así como para ofrecer soporte técnico o realizar el mantenimiento pertinente, de la manera siguiente:
  • Solo se habilita durante el período de tiempo necesario y se deshabilita cuando no está en uso.
  • Se supervisa cuando está en uso.
• 8.1.6 Limite la repetición de intentos de acceso mediante el bloqueo del identificador de usuario tras seis intentos.
• 8.1.7 Establezca la duración del bloqueo en un mínimo de 30 minutos o hasta que un administrador habilite el identificador de usuario.
• 8.1.8 Si una sesión ha estado inactiva durante más de 15 minutos, requiera que el usuario vuelva a autenticarse para activar de nuevo el terminal o la sesión.

Sus responsabilidades

Estas son las consideraciones generales para este requisito:

SE APLICA A: 8.1.1, 8.1.2, 8.1.3

No comparta ni reutilice identidades para partes funcionalmente diferentes del CDE. Por ejemplo, no use una cuenta de equipo para acceder a los datos o a los recursos del clúster. Asegúrese de que la documentación de las identidades es clara sobre el uso de cuentas compartidas.

Amplíe esta entidad de seguridad de identidades a las asignaciones de identidades administradas en Azure. No comparta las identidades administradas por el usuario entre recursos de Azure. Asigne a cada recurso de Azure su propia identidad administrada. Del mismo modo, cuando use la identidad de carga de trabajo de Microsoft Entra en el clúster de AKS, asegúrese de que cada componente de la carga de trabajo recibe su propia identidad en lugar de usar una identidad de ámbito amplio. Nunca comparta la misma identidad administrada entre entornos de producción y no de producción.

Más información sobre Opciones de acceso e identidad en Azure Kubernetes Service (AKS).

SE APLICA A: 8.1.2, 8.1.3, 8.1.4

Use Microsoft Entra ID como almacén de identidades. Dado que el clúster y todos los recursos de Azure usan Microsoft Entra ID, deshabilitar o revocar el acceso de una entidad de servicio se aplica automáticamente a todos los recursos. Si hay algún componente que no tenga el respaldo directo de Microsoft Entra ID, asegúrese de que tiene un proceso para quitar el acceso. Por ejemplo, las credenciales SSH para acceder a un jumpbox pueden necesitar la eliminación explícita si el usuario ya no es válido.

SE APLICA A: 8.1.5

Aproveche Microsoft Entra ID diseñada para hospedar cuentas de terceros de negocio a negocio (B2B), como proveedores y asociados, como usuarios invitados. Conceda el nivel de acceso adecuado mediante directivas condicionales para proteger los datos corporativos. Estas cuentas deben tener permisos permanentes mínimos y fechas de expiración obligatorias. Para obtener más información, consulte Colaboración B2B con invitados externos para sus empleados.

La organización debe tener un patrón claro y documentado de acceso de proveedor y similar.

SE APLICA A: 8.1.6, 8.1.7, 8.1.8

Sus responsabilidades

Microsoft Entra ID proporciona una característica de bloqueo inteligente para bloquear a los usuarios después de los intentos de inicio de sesión con errores. La manera recomendada de implementar bloqueos es con las directivas de acceso condicional de Microsoft Entra.

Implemente el bloqueo para componentes que admitan características similares, pero que no tengan el respaldo de Microsoft Entra ID (por ejemplo, máquinas habilitadas para SSH, como un jumpbox). Esto garantiza que los bloqueos estén habilitados para evitar o ralentizar el abuso de intento de acceso.

Los nodos de AKS no están diseñados para tener acceso rutinario. Bloquee el acceso SSH directo o de Escritorio remoto para los nodos de clúster. El acceso SSH solo debe considerarse como parte de los esfuerzos de solución de problemas avanzados. El acceso debe supervisarse estrechamente y revertirse rápidamente después de la finalización del evento específico. Si hace esto, tenga en cuenta que cualquier cambio de nivel de nodo puede hacer que el clúster no sea compatible.

Requisito 8.2

Además de asignar un id. único, asegúrese de realizar una administración adecuada de la autenticación de usuario para los usuarios y administradores que no son consumidores en todos los componentes del sistema mediante el uso de al menos uno de los métodos siguientes para autenticar a todos los usuarios: algo que sepa, como una contraseña o frase de contraseña, algo que tenga, como un dispositivo de token o una tarjeta inteligente o algo que sea, como un elemento biométrico.

• 8.2.1 Use criptografía segura para que la representación de las credenciales de autenticación (como contraseñas o frases de contraseña) no se pueda leer durante la transmisión y el almacenamiento en todos los componentes del sistema.
• 8.2.2 Compruebe la identidad del usuario antes de modificar cualquier credencial de autenticación (por ejemplo, restablecer contraseñas, aprovisionar nuevos tokens o generar nuevas claves).
• 8.2.3 Las contraseñas o frases deben cumplir los siguientes requisitos:
  • Requerir una longitud mínima de siete caracteres.
  • Contener caracteres alfabéticos y numéricos.
• 8.2.4 Cambie las contraseñas o frases de contraseña del usuario al menos una vez cada 90 días.
• 8.2.5 No permita que un usuario individual envíe una nueva contraseña o frase que sea igual a una de las últimas cuatro contraseñas o frases que ha utilizado.
• 8.2.6 Establezca las contraseñas o frases para el primer uso y en el restablecimiento en un valor único para cada usuario, y cámbiela inmediatamente después del primer uso.

Sus responsabilidades

Configure las directivas de acceso condicional en Microsoft Entra ID para el clúster. Esto impone más restricciones en el acceso al plano de control de Kubernetes.

Microsoft Entra ID administra automáticamente varios de los conjuntos de requisitos anteriores. Estos son algunos ejemplos:

• Seguridad de contraseñas

  Microsoft Entra ID proporciona características que aplican el uso de contraseñas seguras. Por ejemplo, se bloquean las contraseñas no seguras que pertenecen a la lista global de contraseñas prohibidas. Esto no es suficiente protección. Para crear una lista de prohibiciones específicas de la organización, considere la posibilidad de agregar la característica de protección de contraseñas de Microsoft Entra. Se aplica una directiva de contraseñas de forma predeterminada. Ciertas directivas no se pueden modificar y cubren algunos de los conjuntos de requisitos anteriores. Incluyen la expiración de la contraseña y los caracteres permitidos. Para obtener la lista completa, consulte Directivas de contraseñas de Microsoft Entra. Considere la aplicación avanzada con directivas de acceso condicional, como las basadas en el riesgo del usuario, que detectan pares de nombre de usuario y contraseña filtrados. Para más información, vea Acceso condicional: acceso condicional basado en el riesgo del usuario.

  Nota

  Se recomienda encarecidamente tener en cuenta las opciones sin contraseña. Para obtener más información, consultePlaneamiento de una implementación de autenticación sin contraseña en ID. de Microsoft Entra.

• Verificación de la identidad del usuario

  Puede aplicar la directiva de acceso condicional de riesgo de inicio de sesión para detectar si la identidad solicitante emitió la solicitud de autenticación. La solicitud se valida con los orígenes de inteligencia sobre amenazas. Entre ellas se incluyen las anomalías de la dirección IP y la difusión de contraseña. Para más información, vea Acceso condicional: acceso condicional basado en el riesgo del inicio de sesión.

Es posible que tenga componentes que no usen Microsoft Entra ID, como el acceso a jumpboxes con SSH. En tales casos, use el cifrado de clave pública con al menos el tamaño de clave RSA 2048. Especifique siempre una frase de contraseña. Tenga un proceso de validación que realice un seguimiento de las claves públicas aprobadas conocidas. Los sistemas que usan el acceso de clave pública no deben exponerse a Internet. En su lugar, se debe permitir todo el acceso SSH solo a través de un intermediario, como Azure Bastion, para reducir el impacto de una pérdida de clave privada. Deshabilite el acceso directo con contraseña y use una solución sin contraseña alternativa.

Requisito 8.3

Proteja mediante la autenticación multifactor todos los accesos individuales a CDE, tanto los administrativos que no se hagan a través de la consola como los realizados desde sistemas remotos. Nota: La autenticación multifactor requiere usar al menos dos de los tres métodos de autenticación (consulte el requisito 8.2 en el que se describen los métodos de autenticación). Usar dos veces uno de los factores (por ejemplo, utilizar dos contraseñas distintas) no se considera autenticación multifactor.

Sus responsabilidades

Use directivas de acceso condicional para aplicar la autenticación multifactor, específicamente en las cuentas administrativas. Estas directivas se recomiendan en varios roles integrados. Aplique estas directivas a los grupos de Microsoft Entra asignados a roles de Kubernetes con privilegios elevados.

Esta directiva se puede mejorar aún más con directivas adicionales. Estos son algunos ejemplos:

• Puede restringir la autenticación a los dispositivos administrados por el inquilino de Microsoft Entra.
• Si el acceso se origina en una red fuera de la red del clúster, puede aplicar la autenticación multifactor.

Para más información, consulte:

• Acceso condicional: Exigir autenticación multifactor para administradores
• Acceso condicional: Solicitud de dispositivos compatibles
• Acceso condicional: Autenticación multifactor basada en el riesgo de inicio de sesión

Requisito 8.4

Documente las directivas y los procedimientos de autenticación y comuníquelos a todos los usuarios, incluido lo siguiente:

• Instrucciones sobre cómo seleccionar credenciales de autenticación seguras
• Instrucciones sobre cómo proteger las credenciales de autenticación
• Instrucciones para no volver a usar contraseñas utilizadas previamente
• Instrucciones para cambiar las contraseñas si hay sospechas de que la seguridad de la contraseña está en riesgo.

Sus responsabilidades

Mantenga la documentación sobre las directivas aplicadas. Como parte del entrenamiento de incorporación de identidades, proporcione instrucciones para los procedimientos de restablecimiento de contraseñas y los procedimientos recomendados de la organización sobre la protección de recursos.

Requisito 8.5

No use identificadores, contraseñas u otros métodos de autenticación que sean grupales, compartidos o genéricos, de la manera siguiente:

• Los identificadores de usuario genéricos se deshabilitan o eliminan.
• Los identificadores de usuario compartidos no existen para la administración del sistema y otras funciones críticas.
• Los identificadores de usuario compartidos o genéricos no se usan para administrar ningún componente del sistema.

Sus responsabilidades

No comparta ni reutilice identidades para partes funcionalmente diferentes del clúster o pods. Por ejemplo, no use una cuenta de equipo para acceder a los datos o a los recursos del clúster. Asegúrese de que la documentación de las identidades es clara sobre el uso de cuentas compartidas.

Deshabilite los usuarios raíz en el CDE. Deshabilite el uso de cuentas locales de Kubernetes para que los usuarios no puedan usar el acceso integrado de --admin a los clústeres del CDE.

Requisito 8.6

Cuando se usan otros mecanismos de autenticación (por ejemplo, tokens de seguridad físicos o lógicos, tarjetas inteligentes, certificados, etc.), el uso de estos mecanismos debe asignarse de la manera siguiente:

• Los mecanismos de autenticación deben asignarse a una cuenta individual y no deben compartirse entre varias cuentas.
• Deben implementarse controles físicos o lógicos para asegurarse de que solo la cuenta correcta puede utilizar el mecanismo para obtener acceso.

Sus responsabilidades

Asegúrese de que todo el acceso al CDE se proporciona en identidades por usuario y esto se extiende a cualquier token físico o virtual. Esto incluye cualquier acceso de VPN a la red CDE, lo que garantiza que el acceso empresarial de punto a sitio (si lo hay) use certificados por usuario como parte de ese flujo de autenticación.

Requisito 8.7

Todo acceso a cualquier base de datos que contenga información de los titulares de las tarjetas (incluido el acceso por parte de aplicaciones, administradores y demás usuarios) se restringe de la manera siguiente:

• Todos los accesos, consultas y acciones de los usuarios en las bases de datos se realizan a través de métodos programáticos.
• Solo los administradores de base de datos tienen la capacidad de obtener acceso directo a las bases de datos o consultarlas.
• Los identificadores de las aplicaciones de base de datos únicamente pueden ser utilizados por las aplicaciones (y no por usuarios individuales ni por procesos que no sean de las aplicaciones).

Sus responsabilidades

Proporcione acceso basado en roles y responsabilidades. Las personas pueden usar su identidad, pero el acceso debe restringirse según la información que necesiten, con permisos permanentes mínimos. Las personas nunca deben usar identidades de aplicación y nunca se deben compartir las identidades de acceso a la base de datos.

Si es posible, acceda a las bases de datos desde las aplicaciones a través de la identidad administrada. De lo contrario, limite la exposición a las cadenas de conexión y las credenciales. Use secretos de Kubernetes para almacenar información confidencial en vez de mantenerla en lugares donde se detecta fácilmente, como la definición de pod. Otra manera es almacenar y cargar secretos en y desde un almacén administrado, diseñado para proteger los datos, como Azure Key Vault. Con las identidades administradas habilitadas en un clúster de AKS, tiene que autenticarse en Key Vault para obtener acceso.

Requisito 8.8

Asegúrese de que las directivas de seguridad y los procedimientos operativos para la identificación y autenticación estén documentados, en uso, y que todas las partes afectadas los conozcan.

Sus responsabilidades

Es fundamental mantener una documentación exhaustiva sobre los procesos y las directivas. Mantenga la documentación sobre las directivas aplicadas. Como parte del entrenamiento de incorporación de identidades, proporcione instrucciones para los procedimientos de restablecimiento de contraseñas y los procedimientos recomendados de la organización sobre la protección de recursos. Las personas que operan en entornos regulados deben estar formadas e informadas y se les debe incentivar para respaldar las garantías de seguridad. Esto es especialmente importante para las personas que forman parte del proceso de aprobación desde una perspectiva de directiva.

Requisito 9: Restricción del acceso físico a datos de los titulares de las tarjetas

Compatibilidad de características de AKS

No hay ninguna característica de AKS aplicable para este requisito.

Sus responsabilidades

Esta arquitectura y la implementación no están diseñadas para proporcionar controles sobre el acceso físico a los recursos o centros de datos locales. Para obtener consideraciones, consulte las instrucciones del estándar PCI-DSS 3.2.1 oficial.

Estas son algunas sugerencias para aplicar controles técnicos:

• Ajuste los tiempos de espera de sesión en cualquier acceso a la consola administrativa, como jumpboxes en el CDE, para minimizar el acceso.

• Ajuste las directivas de acceso condicional para minimizar el TTL en los tokens de acceso de Azure desde puntos de acceso, como Azure Portal. Para obtener más información, consulte estos artículos:

  • Configuración de directivas de duración de sesión adaptables
  • Vigencias configurables de tokens en la plataforma de identidad de Microsoft

• En el caso del CDE hospedado en la nube, no hay ninguna responsabilidad para administrar el acceso físico y el hardware. Confíe en los controles físicos y lógicos de la red corporativa.

• Minimice la exportación de copias de seguridad de CHD a destinos locales. Use soluciones hospedadas en Azure para limitar el acceso físico a las copias de seguridad.

• Minimice las copias de seguridad en el entorno local. Si es necesario, tenga en cuenta que el destino local estará en el ámbito de la auditoría.

Pasos siguientes

Seguimiento y supervisión de todos los accesos a recursos de red y datos de los titulares de tarjetas. Pruebas frecuentes de los procesos y sistemas de seguridad.