Supervisión de operaciones de un clúster de línea de base de AKS para PCI-DSS 3.2.1 (parte 7 de 9)

En este artículo, se describen las consideraciones para un clúster de Azure Kubernetes Service (AKS) que ejecuta una carga de trabajo que cumple 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. Consulte la introducción.

Supervisión y pruebas de las redes con frecuencia

Requisito 10: Seguimiento y supervisión de todos los accesos a recursos de red y datos de los titulares de tarjetas

Compatibilidad de características de AKS

Azure proporciona la característica Container Insights que supervisa los contenedores, incluidos los clústeres de AKS. Para más información, consulte Introducción a Container Insights.

AKS proporciona registros de auditoría en varios niveles que pueden ser útiles para proteger el sistema y los datos de forma proactiva. Los registros de actividad proporcionan información sobre las operaciones relacionadas con la administración de cuentas y secretos, la administración de la configuración de diagnóstico, la administración del servidor y otras operaciones de acceso a recursos. Todos los registros se registran con la fecha, la hora, la identidad y otra información detallada. También puede acceder a todos los registros cronológicos de todas las llamadas API realizadas en el clúster de AKS. Los registros incluyen información sobre el llamador, la hora en la que se realizó la llamada y el origen donde se inició la llamada. Para obtener más información, consulte Registros de recursos o planos de control de AKS.

Se puede utilizar RBAC (control de acceso basado en rol) para administrar la directiva de acceso de recursos como procedimiento estándar en Azure.

Todos los registros se deben almacenar en una cuenta de almacenamiento propiedad del cliente o en los registros de Azure Monitor. De este modo, puede generar rápidamente información detallada a partir de un gran volumen de datos. Todos los registros se mantienen con al menos tres copias en una región. Para tener más copias, habilite la copia de seguridad o la replicación entre regiones. Todas las entradas de registro solo están disponibles mediante canales HTTP protegidos.

La plataforma de alertas de Azure permite configurar alertas para detectar accesos sospechosos. Puede establecer las alertas que deben desencadenarse y los eventos. Los usuarios también pueden comprobar manualmente el registro completo mediante Log Analytics con la funcionalidad de filtrado en función del tipo de actividad, el contenido de la actividad o el autor de la llamada de la actividad.

Sus responsabilidades

Requisito 11: Probar con regularidad los sistemas y procesos de seguridad

Compatibilidad de características de AKS

AKS se integra en los servicios de supervisión de Azure:

• Microsoft Defender para contenedores proporciona muchas características de análisis de seguridad. Por ejemplo, Defender para contenedores examina las imágenes extraídas, insertadas e importadas en los registros de contenedor y proporciona recomendaciones. Para obtener más información, consulte Evaluación de vulnerabilidades.

• Azure Monitor se puede utilizar para establecer alertas basadas en el tipo de evento a fin de proteger la integridad y la seguridad del sistema. Cuando hay errores del sistema esperados en los nodos de AKS, AKS repara automáticamente el recurso de forma oportuna sin interrupciones en el procesamiento del sistema.

Los clústeres de AKS están protegidos por Azure Application Gateway con Web Application Firewall (WAF) y se pueden configurar en modo de detección para registrar alertas y amenazas. Es mejor usar el modo de prevención , que bloquea activamente las intrusiones y los ataques detectados. Para más información, consulte Procedimientos recomendados con la conectividad de red y la seguridad en Azure Kubernetes Service (AKS).

Sus responsabilidades

Requisito 10.1

Implementar pistas de auditoría para vincular todo el acceso a componentes del sistema a cada usuario individual.

Sus responsabilidades

Se recomienda usar las operaciones de auditoría realizadas en cada componente mediante los métodos siguientes:

• Registro de actividad de Azure Monitor. El registro de actividad proporciona información sobre el tipo y la hora de las operaciones de los recursos de Azure. También registra la identidad que inició la operación. Está habilitado de forma predeterminada, y la información se recopila en cuanto se realiza la operación del recurso. La pista de auditoría es inmutable y no se puede eliminar.

  Los datos se conservan durante 90 días. Para opciones de retención más largas, considere la posibilidad de enviar las entradas del registro de actividad a los registros de Azure Monitor y configurar una directiva de retención y archivo.

  

• Configuración de diagnóstico de Azure. La configuración de diagnóstico proporciona información de diagnóstico y auditoría de los recursos de Azure y la plataforma a la que se aplica la configuración. Se recomienda habilitar la configuración de diagnóstico para AKS y otros componentes del sistema, como Azure Blob Storage y Key Vault. En función del tipo de recurso, puede elegir el tipo de registros y datos de métricas para enviarlos a un destino. El destino del diagnóstico debe cumplir los períodos de retención necesarios.

  • En las categorías de AKS proporcionadas, habilite los registros de auditoría de Kubernetes. La configuración de diagnóstico incluye kube-audit o kube-audit-admin y guard.

    Habilite kube-audit-admin para ver las llamadas del servidor de API basadas en el registro que podrían modificar el estado del clúster. Si necesita una pista de auditoría de todas las interacciones del servidor de API (incluidos los eventos que no modifican, como las solicitudes de lectura), habilite kube-audit en su lugar. Esos eventos pueden ser prolíficos, crear ruido y aumentar el costo de consumo. Estos registros tienen información sobre el acceso y el nombre de identidad que se utiliza para realizar la solicitud.

    Habilite los registros de guard para realizar un seguimiento de las auditorías de control de acceso basado en rol (RBAC) de Azure y Microsoft Entra ID administrado.

  • Además de los registros basados en el usuario, tenga en cuenta los registros del plano de control de Kubernetes, incluidos kube-apiserver y kube-controller-manager. Normalmente, estos registros no están asociados al usuario, pero pueden ayudar a correlacionar los cambios del sistema que los usuarios han realizado.

    Para más información, consulte Visualización de los registros de componentes del plano de control.

  Esta implementación de referencia habilita los registros cluster-autoscaler, kube-controller-manager, kube-audit-admin y guard, y los reenvía a un área de trabajo de Log Analytics. El período de retención del área de trabajo se establece en 90 días.

  

• Los diagnósticos de Azure Kubernetes Service (AKS) ayudan a detectar y solucionar problemas con el clúster, como los errores de nodo. También incluye datos de diagnóstico específicos de redes que no incurren en cargos adicionales. Estos datos no suelen estar asociados con la actividad del usuario, pero pueden ayudar si necesita comprender los efectos de los cambios del sistema que han realizado los usuarios. Para más información, consulte Introducción a los diagnósticos de Azure Kubernetes Service (versión preliminar).

Los mecanismos de seguimiento de auditoría anteriores se deben implementar en el momento de la implementación de los recursos. Azure Policy debe estar activo para asegurarse de que estas configuraciones no se deshabilitan de forma involuntaria o malintencionada en el CDE.

Requisito 10.2

Implementar registros de auditoría automatizados de todos los componentes del sistema para reconstruir los siguientes eventos:

• 10.2.1 Todos los accesos de usuarios individuales a los datos de titulares de tarjetas
• 10.2.2 Todas las acciones realizadas por individuos con privilegios administrativos o de raíz
• 10.2.3 Acceso a todos los registros de auditoría
• 10.2.4 Intentos de acceso lógico no válidos
• 10.2.5 Cambios y uso de los mecanismos de identificación y autenticación, incluidas, entre otras acciones, la creación de cuentas nuevas y la elevación de privilegios, así como todos los cambios, adiciones o eliminaciones de cuentas con privilegios administrativos o de raíz
• 10.2.6 Inicialización, detenimiento o pausa de los registros de auditoría
• 10.2.7 Creación y eliminación de objetos del sistema

Sus responsabilidades

AKS proporciona registros de auditoría en varios niveles, tal como se describe en el Requisito 10.1. A continuación se muestran algunos puntos clave:

• De forma predeterminada, los registros de actividad proporcionan información sobre las operaciones críticas de recursos de Azure. Todos los registros incluyen el estado, la hora y la identidad de quién inició la operación.
• Habilite la configuración de diagnóstico para acceder a todos los registros de todas las llamadas API realizadas en el clúster de AKS. Los registros proporcionan detalles sobre el solicitante, la marca de tiempo, el origen de la solicitud y el contenido de esta. Almacene los registros en un área de trabajo de Log Analytics con un período de retención adecuado. Habilite el registro del área de trabajo de Log Analytics para asegurarse de que se registra incluso el acceso al registro de auditoría.
• Habilita la recopilación de syslog con Container Insights para capturar los registros de eventos de estado y seguridad del sistema operativo de nivel de nodo de AKS en el área de trabajo de Log Analytics. Estos registros también deben ingerirse en su SIEM.
• Incluya el registro de auditoría de uso y del sistema operativo para otros recursos informáticos, como agentes de compilación y cuadros de salto. Deshabilite el acceso a los sistemas directamente como raíz. Compruebe que todas las acciones se realicen bajo una identidad específica.
• Registre los intentos de acceso incorrectos. Esto incluye solicitudes de acceso a componentes como Azure Storage, Azure Key Vault, el servidor de API de AKS y cualquier acceso RDP/SSH en otros sistemas.
• Aproveche las ventajas de las características que ofrecen los agentes de seguridad de terceros para ayudar a analizar los patrones de usuario dentro del clúster de AKS. Estas características pueden ser útiles para los datos de auditoría de acceso de usuario.

Requisito 10.3

Registrar, como mínimo, las siguientes entradas de registro de auditoría de todos los componentes del sistema para cada evento:

• 10.3.1 Identificación del usuario
• 10.3.2 Tipo de evento
• 10.3.3 Fecha y hora
• 10.3.4 Indicación de una operación correcta o errónea
• 10.3.5 Origen del evento
• 10.3.6 Identidad o nombre de los datos, del componente del sistema o del recurso que están afectados.

Sus responsabilidades

Tal como se describe en el Requisito 10.2, puede obtener registros de auditoría del clúster habilitando la configuración de diagnóstico para AKS. Los registros contienen información detallada sobre los eventos get, list, create, update, delete, patch y post. Los registros contienen la información especificada en el requisito. Almacene los registros en una cuenta de almacenamiento para que pueda consultar la información.

Por ejemplo, quiere ver el conjunto de información anterior para los eventos kube-audit-admin mediante la ejecución de esta consulta:

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

El conjunto de resultados muestra la información como parte del campo log_s.

Para obtener información sobre los registros del plano de control, consulte Registros de recursos o plano de control de AKS.

Requisito 10.4

Use la tecnología de sincronización de hora para sincronizar todos los relojes y las horas del sistema críticas y compruebe que se haya implementado lo siguiente para adquirir, distribuir y almacenar la hora.

• 10.4.1 Los sistemas críticos tienen la hora correcta y coherente.
• 10.4.2 Los datos de hora están protegidos.
• 10.4.3 La configuración de hora se recibe desde orígenes de hora aceptados por el sector.

Nota: Un ejemplo de tecnología de sincronización de hora es el protocolo de tiempo de redes (NTP).

Sus responsabilidades

AKS usa NTP desde los hosts de Azure subyacentes y no requiere ninguna concesión de tráfico de red de salida para admitir NTP. Otras máquinas virtuales que agregue al CDE podrían usar servidores NTP externos, como ntp.ubuntu.org (y su grupo) como su origen de sincronización de hora. Cualquier proceso adicional que lleve al CDE debe usar explícitamente el origen NTP de su elección y se debe documentar.

Requisito 10.5

Limitar la visualización de las pistas de auditoría a solo aquellas personas que tengan una necesidad relacionada con el trabajo.

• 10.5.1 Limitar la visualización de las pistas de auditoría a aquellas personas que tengan una necesidad relacionada con el trabajo.
• 10.5.2 Proteger los archivos de registro de auditoría de modificaciones no autorizadas.
• 10.5.3 Realizar una copia de seguridad de forma puntual de los archivos de registro de auditoría en un soporte físico o en un servidor de registros centralizado que sea difícil de modificar.
• 10.5.4 Escribir los registros para las tecnologías de uso externo en un dispositivo multimedia o servidor de registros interno, centralizado y seguro.
• 10.5.5 Usar software de detección de cambios o supervisión de integridad de los archivos de registros para asegurarse de que no se pueden cambiar los datos de registro existentes sin generar alertas (aunque los datos nuevos que se agreguen no deberían causar ninguna alerta).

Sus responsabilidades

Tener varios receptores de registro agrega sobrecarga a la protección, revisión, examen y consulta de datos del registro de auditoría. Planee las topologías de pista de auditoría para lograr una solución intermedia entre el aislamiento completo de la pista de auditoría y los problemas de administración.

Cuando sea posible, integre registros. La ventaja es la capacidad de revisar, analizar y consultar datos de forma eficaz. Azure ofrece varias opciones de tecnología. Puede usar la información del contenedor de Azure Monitor para escribir registros en un área de trabajo de Log Analytics. Otra opción es integrar los datos en soluciones de administración de eventos e información de seguridad (SIEM), como Microsoft Sentinel. Otras opciones populares de terceros son Splunk, QRadar y ArcSight. Microsoft Defender for Cloud y Azure Monitor admiten todas esas soluciones. Estas soluciones son receptores de datos de solo anexión para asegurarse de que no se pueda modificar la pista.

Defender for Cloud puede exportar resultados a intervalos configurados. Para más información, consulte el artículo sobre exportación continua.

Todos los registros se mantienen con al menos tres copias en una región. Como estrategia de copia de seguridad, puede tener más copias habilitando la copia de seguridad o la replicación entre regiones. Todas las entradas de registro solo están disponibles mediante canales HTTP protegidos.

Log Analytics y Microsoft Sentinel admiten varios controles de acceso basados en roles para administrar el acceso al registro de auditoría. Asegúrese de que los roles estén asignados a los roles y las responsabilidades de la organización.

Asegúrese de que el área de trabajo de Log Analytics admita tanto las operaciones como las necesidades de cumplimiento. Considere la posibilidad de tener un área de trabajo dedicada para los clústeres en el ámbito, que se reenvíe a la solución SIEM.

La mayoría del registro en AKS procederá de stdout/stderr, y lo recopilará Azure Monitor Container Insights. Si tiene otros registros creados manualmente, considere la posibilidad de emitir datos de manera que se envíen a un flujo de reenvío de confianza y que no estén sujetos a manipulaciones.

Requisito 10.6

Revisar los registros y eventos de seguridad de todos los componentes del sistema para identificar anomalías o actividades sospechosas.

• 10.6.1 Revisar los siguientes aspectos a diario como mínimo:
  • Todos los eventos de seguridad
  • Registros de todos los componentes del sistema que almacenan, procesan o transmiten CHD o SAD
  • Registros de todos los componentes fundamentales del sistema
  • Registros de todos los servidores y componentes del sistema que realizan funciones de seguridad (por ejemplo, firewalls, sistemas de detección o prevención de intrusiones (id. o IP), servidores de autenticación, servidores de redireccionamiento de comercio electrónico, etc.).
• 10.6.2 Revisar los registros de los restantes componentes del sistema periódicamente de acuerdo con la estrategia de administración de riesgos y las directivas de la organización, según lo determina la evaluación de riesgos anual de la organización.
• 10.6.3 Realizar un seguimiento de las excepciones y anomalías identificadas durante el proceso de revisión.

Sus responsabilidades

Los servicios de supervisión de Azure, Azure Monitor y Microsoft Defender pueden generar notificaciones o alertas cuando detecten actividad anómala. Estas alertas incluyen información de contexto, como la gravedad, el estado y el tiempo de actividad.

A medida que se generan alertas, tenga una estrategia de corrección y revise el progreso. Una manera es realizar un seguimiento de la puntuación de seguridad en Microsoft Defender for Cloud y compararla con los resultados históricos.

Centralice los datos en una sola vista mediante soluciones SIEM, como Microsoft Sentinel. La integración de datos puede proporcionar un contexto de alerta enriquecido.

Como alternativa, compruebe manualmente el registro completo en el almacenamiento. Por ejemplo, en los registros de Azure Monitor, puede utilizar una funcionalidad de filtrado basada en el tipo de actividad, el contenido de la actividad o el autor de la llamada de la actividad.

Tenga directivas organizativas para revisar alertas y eventos a una cadencia regular y planear iniciativas con objetivos de mejora específicos. Utilice consultas guardadas personalizadas en Log Analytics para documentar las consultas de registro previstas y facilitarlas. Esto garantiza que el equipo sepa lo que es importante revisar en relación con el punto 10.6 y que todos los esfuerzos manuales implicados en este proceso sigan un flujo de trabajo coherente.

Requisito 10.7

Retener el historial de registros de auditoría durante al menos un año, y que durante un mínimo de tres meses ofrezca disponibilidad inmediata para el análisis (por ejemplo, en línea, archivado o que se pueda restaurar desde la copia de seguridad).

Sus responsabilidades

De forma predeterminada, los registros no se conservan indefinidamente. Asegúrese de configurar los registros de actividad de Azure y la configuración de diagnóstico para que se conserven de forma que se puedan consultar. Especifique un período de retención de tres meses al habilitar la configuración de diagnóstico para los recursos. Los registros de Azure Monitor admiten el archivado a largo plazo a fin de que se puedan usar para auditorías o análisis sin conexión. Implemente la solución de archivado a largo plazo para alinearse con el principio de una sola escritura/varias lecturas.

Requisito 10.8

10.8.1 Requisito adicional solo para proveedores de servicios: responder a los errores de los controles de seguridad críticos de manera oportuna. Los procesos para responder a los errores de los controles de seguridad deben incluir las siguientes acciones:

• Restauración de las funciones de seguridad
• Identificación y documentación de la duración (principio a fin de fecha y hora) del error de seguridad
• Identificación y documentación de las causas del error, incluida la causa principal, y documentación de la corrección necesaria para tratar la causa principal
• Identificación y direccionamiento de los problemas de seguridad que se produjeron durante el error
• Realización de una evaluación de riesgos para determinar si son necesarias más acciones como resultado del error de seguridad
• Implementación de controles para evitar que la causa del error se vuelva a producir
• Reanudación de la supervisión de los controles de seguridad

Sus responsabilidades

Cuando sea práctico, tenga alertas que indiquen la existencia de controles de seguridad críticos. De lo contrario, asegúrese de que el proceso de auditoría pueda detectar la falta de un control de seguridad esperado de forma oportuna. Considere la posibilidad de utilizar controles como agentes de seguridad que se ejecutan en el clúster de AKS y controles de acceso (IAM y red) en los recursos de Azure. Incluya opciones para comprobar si el clúster de AKS es un clúster privado, comprobar los puntos de exposición de red mediante reglas de grupo de seguridad de red (NSG) o comprobar si hay direcciones IP públicas inesperadas. Incluya también cambios inesperados en DNS, enrutamiento de red, firewall y Microsoft Entra ID.

Requisito 10.9

Asegurarse de que las directivas de seguridad y los procedimientos operativos para supervisar todos los accesos a los recursos de redes y a los datos de titulares de tarjetas 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 una documentación sobre las directivas aplicadas. Como parte de los esfuerzos de supervisión, las personas deben estar entrenadas para habilitar y ver los registros de auditoría, así como identificar y corregir los riesgos comunes. Es especialmente importante para las personas que forman parte del proceso de aprobación desde la perspectiva de las directivas.

Requisito 11.1

Implementar procesos para comprobar la presencia de puntos de acceso inalámbrico (802.11) y detectar e identificar todos los puntos de acceso inalámbrico autorizados y no autorizados de forma trimestral.

Las redes externas están fuera del ámbito de esta documentación y se deben evaluar por separado.

Sus responsabilidades

Esta arquitectura y su implementación no están diseñadas para admitir transacciones de la red local o corporativa a la nube mediante conexiones inalámbricas. Para conocer las consideraciones, consulte la guía del Estándar PCI-DSS 3.2.1 oficial.

Requisito 11.2

Ejecute exámenes de vulnerabilidades de red internos y externos al menos trimestralmente y después de cualquier cambio significativo en la red, como:

• Nuevas instalaciones de componentes del sistema
• Cambios en la topología de red
• Modificaciones de reglas de firewall
• Actualizaciones de productos

Para más información, consulte Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors (Proveedores de exámenes aprobados por el Estándar de seguridad de datos del sector de tarjetas de pago (PCI)).

Sus responsabilidades

Tenga un proceso que compruebe si hay cambios en el clúster de AKS, la configuración de red, los registros de contenedor y otros componentes de la arquitectura.

Si hay cambios en la red, el proceso debe evaluar si es necesario realizar un examen. Por ejemplo, ¿el clúster está ahora expuesto a la red pública de Internet? ¿Las nuevas reglas de firewall son demasiado permisivas? Dentro del clúster, ¿hay brechas de seguridad en el flujo entre los pods?

Tenga una definición clara y acordada sobre los cambios importantes con respecto a la infraestructura. Ejemplos:

• Configuración de reglas de NSG o Azure Firewall
• Emparejamientos de red virtual
• Configuración de DNS
• Configuraciones de Azure Private Link
• Otros componentes de red

SE APLICA A 11.2.1

El examen trimestral de puntos vulnerables lo debe ejecutar personal cualificado con un conocimiento profundo de los conceptos de redes de Azure y de Kubernetes. Asigne los resultados al Requisito 6.1 con niveles de gravedad y resuelva los elementos de prioridad alta. Si hay cambios importantes, ejecute los exámenes antes del examen trimestral programado. Esto ayuda a detectar nuevas vulnerabilidades para que pueda corregir los problemas de forma proactiva.

Este examen también debe incluir redes en clúster (de pod a pod).

SE APLICA A 11.2.2

Seleccione un proveedor de análisis aprobado (ASV) que tenga una amplia experiencia con las redes de Azure y de Kubernetes. Esto proporciona profundidad y especificidad en la corrección sugerida.

Requisito 11.3

Implementar una metodología para las pruebas de penetración que incluya lo siguiente:

• Debe estar basado en enfoques de pruebas de penetración aceptados por el sector (por ejemplo, NIST SP800-115).
• Debe incluir cobertura para todo el perímetro del CDE y los sistemas críticos.
• Debe incluir pruebas del interior y exterior de la red.
• Debe incluir pruebas para validar cualquier control de segmentación y reducción del ámbito.
• Debe definir pruebas de penetración de nivel de aplicación para incluir, como mínimo, las vulnerabilidades descritas en el Requisito 6.5.
• Debe definir pruebas de penetración de la capa de red para incluir los componentes que admiten las funciones de red y los sistemas operativos
• Debe incluir la revisión y consideración de las amenazas y vulnerabilidades que se han producido en los últimos 12 meses
• Debe especificar la retención de los resultados de las pruebas de penetración y las actividades de corrección.

Sus responsabilidades

Ejecute unas pruebas de penetración para encontrar brechas de seguridad mediante la recopilación de información, el examen de puntos vulnerables y la generación de informes. Se recomienda seguir las directrices del sector proporcionadas en Penetration Testing Execution Standard (PTES) (Estándar de ejecución de pruebas de penetración (PTES)) para abordar los escenarios comunes y las actividades necesarias para establecer una base de referencia.

El profesional de pruebas de penetración debe tener un conocimiento profundo de las redes locales y de Azure para asegurarse de que se traten ampliamente las pruebas de segmentación anuales. Amplíe la metodología de prueba a las redes en clúster. Esto requiere una sólida experiencia con los conceptos de redes de Kubernetes.

Las pruebas deben cubrir las capas de datos y de aplicación que se ejecutan en el CDE.

En un ejercicio de pruebas de penetración, los profesionales que las llevan a cabo pueden necesitar acceder a datos confidenciales para toda la organización. Siga las reglas de interacción para asegurarse de que el acceso y la intención no se usen de forma inadecuada. Para obtener instrucciones sobre cómo planear y ejecutar ataques simulados, consulte Reglas de interacción de las pruebas de penetración.

Requisito 11.4

Usar técnicas de detección y prevención de intrusiones para detectar y evitar intrusiones en la red. Supervisar todo el tráfico en el perímetro del entorno de datos de los titulares de tarjetas y los puntos críticos del entorno de datos de los titulares de tarjetas. Alertar al personal sobre la sospecha de riesgos.

Sus responsabilidades

Proteger el clúster de AKS inspeccionando el tráfico entrante mediante un firewall de aplicaciones web (WAF). En esta arquitectura, Azure Application Gateway con WAF integrado evita las intrusiones. Utilice el modo de prevención para bloquear activamente las intrusiones y los ataques detectados. No use solo el modo de detección. Para más información, consulte Procedimientos recomendados con la conectividad de red y la seguridad en Azure Kubernetes Service (AKS).

Una opción alternativa es utilizar funcionalidades de detección de intrusiones o prevención de intrusiones en Azure Firewall Premium. Para más información, consulte IDPS.

Otra opción es habilitar Azure Monitor Network Insights, que proporciona acceso a funcionalidades de supervisión de red como Connection Monitor, el registro de flujo de los grupos de seguridad de red (NSG) y Análisis de tráfico.

Habilite planes de Microsoft Defender a medida que se apliquen a varios componentes del CDE. Por ejemplo, si se utiliza Azure SQL para almacenar CHD, Microsoft Defender para SQL se asegura de que se detecten las intrusiones en la capa de datos.

Además, detecte anomalías en los patrones de tráfico mediante la conexión de registros de flujo del grupo de seguridad de red a una solución SIEM centralizada, como Microsoft Sentinel. En esta implementación de referencia, los registros están en modo de solo anexión, lo que minimiza el seguimiento de los cambios en los registros de auditoría. Sin embargo, no se deben modificar todos los registros que se envían a receptores externos para un almacenamiento a largo plazo. Deben seguir el enfoque una sola escritura/varias lecturas. Asegúrese de que la solución de supervisión de la integridad de los archivos (FIM) cubra estas entidades externas para la detección de los cambios.

Requisito 11.5

Implementar una solución de seguimiento de cambios (por ejemplo, una solución de supervisión de la integridad de los archivos) para alertar al personal sobre la modificación no autorizada de archivos del sistema, archivos de configuración o archivos de contenido críticos. Configure el producto para realizar comparaciones de archivos críticos al menos semanalmente.

Sus responsabilidades

En el clúster, ejecute una solución de supervisión de la integridad de los archivos (FIM) junto con un agente de seguridad compatible con Kubernetes para detectar el acceso de nivel de sistema y de archivo que pudiera dar lugar a cambios en el nivel de nodo. Al elegir una solución FIM, tenga un conocimiento claro de sus características y de la profundidad de la detección. Tenga en cuenta el software desarrollado por proveedores de confianza.

Compruebe todas las configuraciones predeterminadas de la herramienta FIM para asegurarse de que los valores detecten los escenarios que desea cubrir y ajuste esas opciones adecuadamente.

Habilite la solución para enviar registros a la solución SIEM o de supervisión para que puedan generar alertas. Tenga en cuenta los cambios en el esquema de registro, o es posible que se pierdan las alertas críticas.

Cualquier otro recurso de proceso en el CDE debe tener habilitado el seguimiento de cambios.

Requisito 11.6

Asegurarse de que las directivas de seguridad y los procedimientos operativos para la supervisión y pruebas de seguridad estén documentados, en uso y sean conocidos por todas las partes afectadas.

Sus responsabilidades

Es fundamental mantener una documentación exhaustiva sobre los procesos y las directivas. Mantenga una documentación sobre las directivas aplicadas. Como parte de los esfuerzos de pruebas, incluya la cadencia de las revisiones y los criterios de revisión. Asegúrese de que el equipo entienda los aspectos de las pruebas de penetración. Tenga un plan de corrección documentado para mitigar los riesgos que surjan.

Es especialmente importante para las personas que forman parte del proceso de aprobación desde la perspectiva de las directivas.

Pasos siguientes

Mantenga una directiva que trate la seguridad de la información para todos los usuarios.