Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
DevSecOps, también denominado Secure DevOps, se basa en la práctica de DevOps mediante la incorporación de seguridad en diferentes fases de un ciclo de vida tradicional de DevOps. Cree la seguridad en los procedimientos de DevOps para:
Hacer que las aplicaciones y los sistemas sean más seguros, proporcione visibilidad de las amenazas de seguridad y evite que las vulnerabilidades lleguen a entornos implementados.
Aumente el conocimiento de la seguridad entre los equipos de desarrollo y operaciones.
Incorpore procesos de seguridad automatizados en el ciclo de vida de desarrollo de software (SDLC).
Reduzca los costos de corrección mediante la búsqueda de problemas de seguridad al principio de las fases de desarrollo y diseño.
Al aplicar DevSecOps a Azure Kubernetes Service (AKS), cada rol de organización tiene consideraciones de seguridad específicas:
Los desarrolladores crean aplicaciones seguras que se ejecutan en AKS.
Los ingenieros en la nube crean una infraestructura de AKS segura.
Los equipos de operaciones pueden controlar clústeres o supervisar problemas de seguridad.
En este artículo se organizan las instrucciones de la fase del ciclo de vida de DevOps y se proporcionan recomendaciones para los controles de seguridad y los procedimientos recomendados. Trata los procesos y herramientas comunes para las canalizaciones de integración continua y entrega continua (CI/CD), con un enfoque en las herramientas integradas.
Flujo del proceso
Descargue un archivo de Visio de esta arquitectura.
Note
En este artículo se hace referencia a AKS y GitHub, pero puede aplicar estas recomendaciones a cualquier plataforma de CI/CD o orquestación de contenedores. Los detalles de implementación pueden variar, pero la mayoría de los conceptos y procedimientos de cada fase siguen aplicándose.
Microsoft Entra ID se configura como proveedor de identidades para GitHub. Configure la autenticación multifactor (MFA) para ayudar a proporcionar seguridad de autenticación adicional.
Los desarrolladores usan Visual Studio Code o Visual Studio con extensiones de seguridad habilitadas para analizar de forma proactiva su código para detectar vulnerabilidades de seguridad.
Los desarrolladores realizan un commit del código de la aplicación en un repositorio de GitHub Enterprise, propiedad y regulado por la corporación.
GitHub Enterprise integra el examen automático de seguridad y dependencias a través de GitHub Advanced Security.
Las solicitudes de incorporación de cambios desencadenan compilaciones de integración continua (CI) y pruebas automatizadas a través de GitHub Actions.
El flujo de trabajo de compilación de CI a través de Acciones de GitHub genera una imagen de contenedor de Docker y la almacena en Azure Container Registry.
Puede agregar aprobaciones manuales para implementaciones a entornos específicos, como producción, como parte del flujo de trabajo de entrega continua (CD) en Acciones de GitHub.
GitHub Actions habilitan CD para AKS. Use GitHub Advanced Security para detectar secretos, credenciales y otra información confidencial en los archivos de origen y configuración de la aplicación.
Microsoft Defender examina Container Registry, el clúster de AKS y Azure Key Vault para detectar vulnerabilidades de seguridad.
Microsoft Defender for Containers examina la imagen de contenedor para detectar vulnerabilidades de seguridad conocidas cuando Acciones de GitHub la carga en Container Registry.
Defender para contenedores también puede examinar el entorno de AKS y proporcionar protección contra amenazas en tiempo de ejecución para los clústeres de AKS.
Microsoft Defender para Key Vault detecta intentos inusuales y sospechosos de acceder a las cuentas del almacén de claves.
Puede aplicar Azure Policy a Container Registry y AKS para aplicar el cumplimiento de directivas. Azure Policy incluye directivas de seguridad integradas para Container Registry y AKS.
Key Vault inserta de forma segura secretos y credenciales en una aplicación en tiempo de ejecución sin exponerlos a los desarrolladores.
El motor de directivas de red de AKS está configurado para ayudar a proteger el tráfico entre pods de aplicación mediante directivas de red de Kubernetes. Se recomienda Azure CNI Powered by Cilium como motor de directivas de red. Proporciona la implementación basada en el filtro de paquetes de Berkeley extendido (eBPF), la política de capa 7 y el filtrado de nombres de dominio totalmente cualificados (FQDN).
Puede configurar la supervisión continua del clúster de AKS mediante Azure Monitor para recopilar métricas de Prometheus, registros de contenedor y eventos de Kubernetes. Utilice los paneles de Azure Managed Grafana para la visualización y Log Analytics para las alertas basadas en consultas.
Azure Monitor recopila métricas de rendimiento mediante Prometheus administrado y registros de aplicaciones y clústeres a través de la recolección de registros de contenedores.
Un área de trabajo de Log Analytics almacena los registros de diagnóstico y aplicación para ejecutar consultas de registro.
Use Microsoft Sentinel como información de seguridad centralizada y administración de eventos (SIEM) para correlacionar la telemetría de AKS con señales de Microsoft Defender for Cloud, Microsoft Entra ID y recursos de red. Microsoft Sentinel proporciona detección, investigación y respuesta automatizada a incidentes de seguridad en todo el entorno de AKS.
Las herramientas de código abierto como el proxy de ataque Zed (ZAP) pueden realizar pruebas de penetración para aplicaciones y servicios web.
Defender para DevOps, un servicio disponible en Defender for Cloud, permite a los equipos de seguridad administrar la seguridad de DevOps en entornos multipipeline, incluidos GitHub y Azure DevOps.
Información general y responsabilidades de los miembros del equipo
Considere la posibilidad de administrar la complejidad de DevSecOps en las implementaciones de soluciones basadas en Kubernetes dividiendo las responsabilidades entre los equipos. En esta sección se describen los roles y responsabilidades de los desarrolladores, operadores de aplicaciones, como ingenieros de confiabilidad de sitios, operadores de clúster y equipos de seguridad.
Developers
Los desarrolladores escriben el código de la aplicación y lo confirman en el repositorio designado. Crean y ejecutan scripts para pruebas automatizadas para asegurarse de que su código funciona según lo previsto e se integra con el resto de la aplicación. Los desarrolladores también definen y programan la construcción de imágenes de contenedor como parte del proceso automatizado.
Operadores de aplicaciones (ingenieros de confiabilidad de sitios)
La creación de aplicaciones mediante contenedores y Kubernetes puede simplificar el desarrollo, la implementación y la escalabilidad de aplicaciones. Pero estos enfoques de desarrollo también crean entornos cada vez más distribuidos que complican la administración.
Los ingenieros de confiabilidad de sitios crean soluciones que automatizan la forma en que los equipos supervisan los sistemas de software de gran tamaño. Sirven como puente entre los equipos de operadores de desarrollo y clúster. Ayudan a establecer y supervisar los objetivos de nivel de servicio (SLO) y los presupuestos de errores. Los ingenieros de confiabilidad de sitios también ayudan a administrar implementaciones de aplicaciones y escribir archivos de manifiesto de Kubernetes (YAML).
Operadores de clúster
Los operadores de clúster configuran y administran la infraestructura del clúster. A menudo usan procedimientos recomendados y marcos de trabajo de infraestructura como código (IaC), como GitOps , para aprovisionar y mantener sus clústeres. Usan herramientas de supervisión como el servicio administrado de Azure Monitor para Prometheus y Azure Managed Grafana para supervisar el estado general del clúster. Son responsables de aplicar parches, actualizaciones de clúster, permisos y control de acceso basado en roles (RBAC) en el clúster. En los equipos de DevSecOps, los operadores de clúster colaboran con los equipos de seguridad para establecer estándares de seguridad y garantizar que los clústeres cumplan esos requisitos.
Equipo de seguridad
El equipo de seguridad desarrolla y aplica estándares de seguridad. Algunos equipos pueden crear y seleccionar definiciones de Azure Policy que aplique en las suscripciones y los grupos de recursos que contienen los clústeres. Los equipos de seguridad supervisan los problemas de seguridad y trabajan con otros equipos para priorizar la seguridad en todo el proceso de DevSecOps.
Fases del ciclo de vida de DevSecOps
Cada fase del SDLC implementa controles de seguridad. Estos controles de seguridad son fundamentales para DevSecOps y las prácticas de desplazamiento hacia la izquierda.
Descargue un archivo de Visio de esta arquitectura.
Fase de planeamiento
La fase del plan suele tener la menor cantidad de automatización, pero tiene implicaciones de seguridad importantes que afectan a las fases posteriores del ciclo de vida de DevOps. Esta fase implica la colaboración entre los equipos de seguridad, desarrollo y operaciones. Para asegurarse de tener en cuenta o mitigar los requisitos de seguridad y los problemas de seguridad, incluya las partes interesadas de seguridad en esta fase.
Procedimiento recomendado: Diseño de una plataforma de aplicación segura
Para crear una carga de trabajo segura hospedada en AKS, debe incorporar la seguridad en el sistema en cada capa, empezando por la propia plataforma. La plataforma puede incluir componentes internos del clúster, como agentes de directivas y seguridad en tiempo de ejecución, y componentes externos a AKS, como firewalls de red y registros de contenedor.
Procedimiento recomendado: Integrar el modelado de amenazas en tu proceso
El modelado de amenazas suele ser una actividad manual que implica equipos de seguridad y desarrollo. Puede modelar y buscar amenazas en un sistema para abordar vulnerabilidades antes de desarrollar código o realizar cambios. Los equipos llevan a cabo el modelado de amenazas en respuesta a cambios de software significativos, cambios de arquitectura de soluciones o incidentes de seguridad.
Se recomienda el modelo de amenazas STRIDE. Esta metodología comienza con un diagrama de flujo de datos y clasifica las amenazas mediante el mnemónico STRIDE: suplantación de identidad, manipulación, rechazo, divulgación de información, denegación de servicio y elevación de privilegios. Los equipos usan estas categorías para identificar, mitigar y validar los riesgos. Una herramienta de modelado ayuda a notar y visualizar componentes del sistema, flujos de datos y límites de seguridad.
La creación de modelos de amenazas en el SDLC agrega sobrecarga de proceso y requiere que mantenga los modelos de amenazas actualizados. Sin embargo, aborda la seguridad al principio del desarrollo, lo que reduce el costo de corregir problemas detectados más adelante.
Procedimiento recomendado: Aplicación de Azure Well-Architected Framework
Aplique los procedimientos recomendados de seguridad que proporcionan instrucciones para la administración de identidades, la seguridad de aplicaciones, la protección de la infraestructura, la seguridad de datos y DevOps, ya que se aplica a entornos nativos de la nube.
Aplique los procedimientos recomendados de excelencia operativa , ya que se aplica a DevSecOps y a la supervisión de los entornos de producción.
Fase de desarrollo
El desplazamiento a la izquierda es una tenet clave de la mentalidad de DevSecOps. Este proceso comienza antes de confirmar el código en un repositorio e implementarlo a través de una canalización. Para solucionar problemas de seguridad anteriores en el ciclo de vida de desarrollo, adopte procedimientos recomendados de codificación seguros y use herramientas y complementos del entorno de desarrollo integrado (IDE) para el análisis de código durante la fase de desarrollo.
Procedimiento recomendado: Aplicar estándares de codificación seguros
Use los procedimientos recomendados de codificación segura establecidos y las listas de comprobación para ayudar a proteger el código frente a vulnerabilidades comunes, como la inyección y el diseño no seguro. La fundación Open Worldwide Application Security Project (OWASP) publica recomendaciones estándar del sector para la codificación segura que usted debería adoptar al escribir código. Estas directrices son especialmente importantes cuando se desarrollan aplicaciones o servicios web orientados al público.
Revise los procedimientos de codificación seguros para los entornos de ejecución de lenguaje de programación específicos, como Java y .NET.
Implemente los estándares de registros para proteger la información confidencial de las fugas en los logs de la aplicación. Los marcos de registro más populares, como Apache Log4j y Apache log4net, proporcionan filtros y complementos para enmascarar información confidencial, como números de cuenta o datos personales.
Procedimiento recomendado: Uso de herramientas y complementos del IDE para automatizar las comprobaciones de seguridad
Los IDE más populares, como Visual Studio, VS Code, IntelliJ IDEA y Eclipse, admiten extensiones que puede usar para obtener comentarios inmediatos y recomendaciones para posibles problemas de seguridad que se presentan al escribir código de aplicación.
SonarQube para IDE es un complemento IDE para los lenguajes y entornos de desarrollo más populares. SonarQube para IDE proporciona comentarios y examina automáticamente el código para detectar errores de programación comunes y posibles problemas de seguridad.
Otros complementos gratuitos y comerciales se centran en elementos específicos de la seguridad, como las 10 vulnerabilidades más comunes de OWASP. El complemento Snyk también examina el origen de la aplicación y las dependencias externas y le avisa si encuentra vulnerabilidades.
El complemento Formato de intercambio de resultados de análisis estáticos (SARIF) para Visual Studio y VS Code le permite ver fácilmente las vulnerabilidades de las herramientas conocidas de pruebas de seguridad de aplicaciones estáticas (SAST) frente a interpretar los resultados de los archivos de salida JSON sin procesar.
Procedimiento recomendado: Establecimiento de controles en los repositorios de código fuente
Establezca una metodología de bifurcación para la coherencia en toda la empresa. Las metodologías como flujo de liberación y el flujo de GitHub tienen directrices estructuradas sobre cómo usar ramas para admitir el desarrollo en equipo y en paralelo. Estas metodologías pueden ayudar a los equipos a establecer estándares y controles para las confirmaciones de código y las combinaciones en el flujo de trabajo de CI/CD.
Algunas ramas, como main, son ramas de larga duración que conservan la integridad del código fuente de la aplicación. Establezca políticas de combinación para estas ramas antes de confirmar o fusionar cambios. Por ejemplo, puede hacer lo siguiente:
Impedir que otros desarrolladores realicen commits de código directamente en la rama principal.
Establezca un proceso de revisión del mismo nivel y requiera un número mínimo de aprobaciones antes de combinar los cambios en una rama principal. Configure y aplique estos controles mediante GitHub. Use GitHub para designar grupos de aprobadores autorizados si es necesario para entornos cerrados.
Use enlaces de confirmación previa para comprobar si hay información confidencial en el código fuente de la aplicación y bloquear las confirmaciones cuando detectan problemas de seguridad.
- Usar los ganchos precommit integrados proporcionados por GitHub. Configúrelos fácilmente para proyectos específicos. Por ejemplo, algunos enlaces creados previamente buscan secretos, claves privadas y credenciales y bloquean una confirmación si encuentran estos problemas.
Establezca RBAC en el sistema de control de versiones.
Cree roles bien definidos mediante el principio de privilegios mínimos. Una canalización de CI/CD funciona como la cadena de suministro para las implementaciones de producción.
Aplique roles de usuario o grupo establecidos dentro de su organización. Para agrupar usuarios en función de su rol y función específicos en los flujos de trabajo de CI/CD, cree roles como Administrador, Desarrollador, Administrador de seguridad y Operador.
Habilite la auditoría de los flujos de trabajo para agregar transparencia y rastreabilidad para la configuración y otros cambios en las canalizaciones de CI/CD.
Procedimiento recomendado: Asegura tus imágenes de contenedor
Utiliza imágenes ligeras que tengan un impacto mínimo en el sistema operativo para reducir la superficie total de ataque. Considere la posibilidad de crear imágenes mínimas como Alpine o imágenes sin distribución que contengan solo la aplicación y su entorno de ejecución asociado.
Use solo imágenes base confiables al construir tus contenedores. Recupere estas imágenes base de un registro privado que escanea frecuentemente en busca de sus vulnerabilidades.
Use herramientas de desarrollo para evaluar las vulnerabilidades de imagen localmente. Trivy es una herramienta de código abierto que analiza las vulnerabilidades de seguridad dentro de las imágenes de contenedor.
Impedir el acceso o el contexto del usuario raíz para una imagen. De forma predeterminada, los contenedores se ejecutan como raíz.
En el caso de los contenedores que necesitan una seguridad mejorada, considere la posibilidad de usar un perfil de AppArmor o seccomp en el clúster de Kubernetes para ayudar a aplicar aún más la seguridad de los contenedores en ejecución.
Fase de construcción
Durante la fase de compilación, los desarrolladores trabajan con ingenieros de confiabilidad de sitios y equipos de seguridad para integrar exámenes automatizados de su origen de aplicación dentro de sus canalizaciones de compilación de CI. Los equipos configuran las canalizaciones para habilitar las prácticas de seguridad mediante las extensiones y las herramientas de seguridad de la plataforma de CI/CD. Estos procedimientos incluyen SAST, análisis de composición de software (SCA) y escaneo de secretos.
Procedimiento recomendado: Realizar SAST para encontrar posibles vulnerabilidades en el código fuente de la aplicación
Utilice las funcionalidades de escaneo de seguridad avanzada de GitHub para el escaneo de código y CodeQL.
El examen de código es una característica que analiza el código en un repositorio de GitHub para buscar vulnerabilidades de seguridad y errores de codificación. Muestra los problemas en GitHub Enterprise Cloud.
Si el examen de código encuentra una posible vulnerabilidad o error en el código, GitHub muestra una alerta en el repositorio.
Puede configurar reglas de rama para las comprobaciones de estado necesarias. Por ejemplo, puede requerir que las ramas de características estén actualizadas con la rama base antes de combinar código nuevo. Este requisito garantiza que usted pruebe su rama con el código más reciente.
Habilite Copilot Autofix para recibir sugerencias automáticas de corrección para alertas del análisis de código. Copilot Autofix propone la corrección directamente en los pull requests, lo que ayuda a los desarrolladores a resolver rápidamente las vulnerabilidades de seguridad.
Use herramientas como kube-score para analizar los objetos de implementación de Kubernetes. Esta herramienta realiza análisis de código estático de las definiciones de objetos de Kubernetes. Genera una lista de recomendaciones para que la aplicación sea más segura y resistente.
Mejores prácticas: Usa el escaneo de secretos para detectar secretos registrados accidentalmente
Al habilitar el examen de secretos para un repositorio, GitHub examina el código de los patrones que coinciden con los secretos que usan muchos proveedores de servicios.
GitHub ejecuta periódicamente un examen completo del historial de Git de contenido existente en repositorios y envía notificaciones de alerta.
Para Azure DevOps, Defender for Cloud usa el análisis de secretos para detectar credenciales, secretos, certificados y otro contenido confidencial en el código fuente y la salida de compilación.
Puede realizar el escaneo de secretos dentro de la extensión Microsoft Security DevOps para Azure DevOps.
Procedimiento recomendado: Uso de herramientas de SCA para realizar un seguimiento de los componentes de código abierto en el código base y detectar vulnerabilidades en dependencias
La revisión de dependencias le permite detectar dependencias no seguras antes de introducirlas en el entorno. También proporciona información sobre la licencia, los dependientes y la edad de las dependencias. Muestra los cambios de dependencia a través de un diferencial enriquecido en la pestaña Archivos cambiados de una solicitud de incorporación de cambios.
Dependabot realiza un examen para detectar dependencias no seguras y envía alertas de Dependabot cuando se agrega un nuevo aviso a la base de datos de asesoramiento de GitHub o cuando cambia el gráfico de dependencias de un repositorio.
Procedimiento recomendado: Generación de un SBOM para las imágenes de contenedor
Una lista de materiales de software (SBOM) proporciona un inventario completo de los componentes, bibliotecas y dependencias que componen las imágenes de contenedor. Utiliza herramientas de generación SBOM como Microsoft sbom-tool o Syft durante la construcción de CI para generar un manifiesto SPDX o CycloneDX.
Adjunte un SBOM a las imágenes de contenedor almacenadas en Container Registry para habilitar el análisis de vulnerabilidades de bajada y el seguimiento del cumplimiento de licencias en toda la cadena de suministro.
Procedimiento recomendado: Examen de plantillas de IaC para detectar configuraciones incorrectas antes de la implementación
Supervise proactivamente las configuraciones de recursos en la nube durante todo el ciclo de vida de desarrollo.
Microsoft Defender para DevOps admite repositorios de GitHub y Azure DevOps y puede examinar plantillas de IaC para identificar vulnerabilidades de IaC.
Procedimiento recomendado: Examen de las imágenes de carga de trabajo en registros de contenedor para identificar vulnerabilidades conocidas
Defender for Containers examina los contenedores en Container Registry y Amazon Elastic Container Registry (ECR) para notificarle las vulnerabilidades conocidas en las imágenes.
Puede habilitar Azure Policy para realizar una evaluación de vulnerabilidades en las imágenes almacenadas en Container Registry y proporcionar información detallada sobre cada búsqueda.
Procedimiento recomendado: Crear nuevas imágenes en actualizaciones de imágenes base automáticamente
- Container Registry Tasks detecta dinámicamente las dependencias de la imagen base cuando crea una imagen de contenedor. Cuando detecta una actualización de la imagen base de una imagen de aplicación, puede configurar una tarea de compilación para recompilar automáticamente las imágenes de aplicación que hacen referencia a esa imagen base.
Procedimiento recomendado: Uso de Container Registry, Key Vault y notación para firmar digitalmente las imágenes de contenedor y configurar el clúster de AKS para permitir solo imágenes validadas
Key Vault almacena las claves de firma que usa la herramienta de notación . El complemento de notación Key Vault (azure-kv) accede a estas claves para firmar y verificar imágenes de contenedor y otros artefactos. Puede adjuntar estas firmas a imágenes de Container Registry mediante los comandos de la CLI de Azure.
Los contenedores firmados garantizan que las implementaciones proceden de un origen de confianza y que los artefactos no se manipulan después de la creación. El artefacto firmado garantiza la integridad y la autenticidad antes de que el usuario extraiga un artefacto en cualquier entorno, lo que ayuda a evitar ataques.
- Ratifica los metadatos de seguridad de artefactos y aplica directivas de admisión antes de la implementación en clústeres de Kubernetes. La integridad de la imagen de AKS usa Ratify como verificador integrado para validar las firmas de imagen y las atestaciones SBOM antes de admitir los pods en el clúster.
Fase de implementación
Durante la fase de implementación, los desarrolladores, los operadores de aplicaciones y los equipos de operadores de clúster trabajan juntos para establecer los controles de seguridad adecuados para las canalizaciones de CD. Estos controles ayudan a implementar código en un entorno de producción de forma segura y automatizada.
Procedimiento recomendado: Gestionar el acceso y el flujo de trabajo del pipeline de implementación
Puede proteger las ramas importantes estableciendo reglas de protección para las ramas. Estas reglas definen si los colaboradores pueden eliminar o forzar la inserción en la rama. También establecen requisitos para los envíos a la rama, como pasar comprobaciones de estado o mantener un historial de confirmaciones lineal.
Use entornos para la implementación y configurar reglas de protección y secretos.
Usa la característica de aprobaciones y de puertas para controlar el flujo de trabajo del pipeline de implementación. Por ejemplo, puede requerir aprobaciones manuales de un equipo de seguridad o operaciones antes de realizar la implementación en un entorno de producción.
Procedimiento recomendado: Protección de las credenciales de implementación
OpenID Connect (OIDC) permite que los flujos de trabajo de GitHub Action accedan a los recursos de Azure sin necesidad de almacenar las credenciales de Azure como secretos de GitHub de larga duración.
Utilice un enfoque de extracción para CI/CD con GitOps para trasladar las credenciales de seguridad al clúster de Kubernetes. Este enfoque reduce la seguridad y la superficie de riesgo mediante la eliminación de credenciales de las herramientas de CI externas. También puede reducir las conexiones entrantes permitidas y limitar el acceso de nivel de administrador a los clústeres de Kubernetes.
Procedimiento recomendado: Ejecutar DAST para encontrar vulnerabilidades en la aplicación en ejecución
Use Acciones de GitHub en los flujos de trabajo de implementación para ejecutar pruebas de seguridad dinámica de aplicaciones.
Use herramientas de código abierto como ZAP para realizar pruebas de penetración para detectar vulnerabilidades comunes de aplicaciones web.
Mejor práctica: Despliegue de imágenes de contenedor solo desde registros de confianza
Utilice Defender para contenedores para habilitar el complemento de Azure Policy para Kubernetes.
Configure Azure Policy para Kubernetes con el fin de restringir las implementaciones de imágenes de contenedor a registros de confianza.
Fase de funcionamiento
Durante esta fase, realice tareas de supervisión de operaciones y supervisión de seguridad para supervisar, analizar y alertar proactivamente sobre posibles incidentes de seguridad. Use herramientas de observabilidad de producción como Azure Monitor y Microsoft Sentinel para supervisar y garantizar el cumplimiento de los estándares de seguridad empresariales.
Procedimiento recomendado: Uso de Defender for Cloud para examinar y supervisar automáticamente las configuraciones de producción
Ejecute un examen continuo para detectar el desfase en el estado de vulnerabilidad de la aplicación e implementar un proceso para aplicar revisiones y reemplazar las imágenes vulnerables.
Implemente la supervisión automatizada de la configuración para sistemas operativos.
Use las recomendaciones de contenedor en Defender for Cloud (en Proceso y aplicaciones) para realizar exámenes de línea base de los clústeres de AKS. Defender for Cloud muestra cualquier problema de configuración o vulnerabilidades en su panel.
Use Defender for Cloud y siga sus recomendaciones de protección de red para ayudar a proteger los recursos de red del clúster de AKS.
Realice una evaluación de vulnerabilidades para las imágenes almacenadas en Container Registry.
- Implemente exámenes continuos para ejecutar imágenes en Container Registry habilitando Defender for Containers.
Procedimiento recomendado: Mantener actualizados los clústeres de Kubernetes
Kubernetes publica nuevas versiones con frecuencia. Mantenga una estrategia de gestión del ciclo de vida para mantener los clústeres compatibles y actualizados. AKS proporciona herramientas para administrar las actualizaciones del clúster. Use las características de mantenimiento planeado de AKS para controlar cuándo se producen las ventanas de mantenimiento y las actualizaciones.
Actualizar Nodos de trabajo de AKS con frecuencia. Azure publica actualizaciones semanales del sistema operativo y del entorno de ejecución. Aplique estas actualizaciones automáticamente a través del modo desatendido o manualmente a través de la CLI de Azure para obtener más control.
Procedimiento recomendado: Uso de Azure Policy para proteger y controlar los clústeres de AKS
Después de instalar el complemento de Azure Policy para AKS, puede aplicar definiciones de directivas individuales o grupos de definiciones de directiva, denominadas iniciativas o conjuntos de directivas, al clúster.
Use directivas integradas de Azure para escenarios comunes, como impedir que los contenedores con privilegios se ejecuten o restrinjan las direcciones IP externas a una lista de permitidos. También puede crear directivas personalizadas para casos de uso específicos.
Aplique definiciones de directiva al clúster y compruebe que Azure Policy aplica esas asignaciones.
Use Gatekeeper para configurar un controlador de admisión que permita o deniega las implementaciones en función de las reglas especificadas. Azure Policy amplía Gatekeeper.
Proteja el tráfico entre pods de carga de trabajo mediante directivas de red en AKS.
- Use Azure CNI Powered by Cilium como motor de directivas de red. Cilium usa un plano de datos basado en eBPF y admite directivas nativas de Kubernetes, directiva de nivel 7 y filtrado de FQDN.
Procedimiento recomendado: Uso de Azure Monitor para la supervisión continua y las alertas
Use Azure Monitor para recopilar registros y métricas de AKS. Recopile métricas de Prometheus a través del servicio administrado de Azure Monitor para Prometheus, consulte los registros de contenedor y plataforma en Log Analytics y visualice el estado del clúster a través de paneles de Grafana administrados de Azure .
Azure Monitor amplía la supervisión continua a los pipelines de lanzamiento. Utilice los datos de monitoreo para aprobar o deshacer versiones. Azure Monitor también ingiere registros de seguridad y alertas sobre la actividad sospechosa.
Incorpore las instancias de AKS a Azure Monitor y configure las opciones de diagnóstico del clúster.
Para más información, consulte Línea de base de seguridad de Azure para AKS.
Procedimiento recomendado: Uso de Defender for Cloud para la supervisión de amenazas activa
Defender for Cloud proporciona supervisión de amenazas activa para AKS en el nivel de nodo (amenazas de máquina virtual) y cargas de trabajo de clúster.
Use Defender para DevOps para obtener una visibilidad completa de todas las canalizaciones de CI/CD. Proporciona equipos de seguridad y operadores con un panel centralizado. Se beneficia especialmente de esta visibilidad centralizada cuando se usan varias plataformas de canalización, como Azure DevOps y GitHub o se ejecutan canalizaciones en nubes públicas.
Defender para Key Vault detecta intentos inusuales y sospechosos de acceder a las cuentas del almacén de claves y puede enviar alertas a los administradores en función de la configuración.
Defender for Containers puede alertar sobre las vulnerabilidades que se encuentran en las imágenes de contenedor almacenadas en Container Registry.
Procedimiento recomendado: Habilitación de la supervisión centralizada de registros y uso de productos SIEM para supervisar amenazas de seguridad en tiempo real
- Conecte los registros de diagnóstico de AKS a Microsoft Sentinel para la supervisión de seguridad centralizada basada en patrones y reglas. Microsoft Sentinel habilita este acceso a través de conectores de datos.
Procedimiento recomendado: Habilitar el registro de auditoría para supervisar la actividad en los clústeres de producción
Use registros de actividad para supervisar acciones en recursos de AKS para ver toda la actividad y su estado. Determine quién realizó qué operaciones en los recursos.
Habilite el registro de consultas del sistema de nombres de dominio (DNS) aplicando la configuración documentada en el configMap personalizado de CoreDNS.
Supervise los intentos de acceder a las credenciales desactivadas.
Integre la autenticación de usuario para AKS con Microsoft Entra ID. Cree la configuración de diagnóstico para el identificador de Microsoft Entra y envíe los registros de auditoría e inicio de sesión a un área de trabajo de Log Analytics. En el área de trabajo de Log Analytics, configure alertas para eventos de seguridad, como los intentos de inicio de sesión de cuentas desactivadas.
Procedimiento recomendado: Habilitación de diagnósticos en los recursos de Azure
- Habilite diagnósticos de Azure en todos los recursos de la carga de trabajo para acceder a los registros de plataforma que proporcionan información detallada de diagnóstico y auditoría. Puede ingerir estos registros en Log Analytics o en una solución SIEM como Microsoft Sentinel para la supervisión y las alertas de seguridad.
Colaboradores
Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.
Autor principal:
- Adnan Khan | Sr. Arquitecto de soluciones en la nube
Otros colaboradores:
- Ayobami Ayodeji | Administrador de programas 2
- Ahmed Bham | Sr. Arquitecto de soluciones en la nube
- Chad Kittel | Ingeniero principal de software - Azure: patrones y prácticas.
- John Poole | Sr. Arquitecto de soluciones en la nube
- Bahram Rushenas | Arquitecto de soluciones sr.
- Abed Sau | Sr. Arquitecto de soluciones en la nube
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Defensor para Contenedores
- Protección de DevOps
- Seguridad en DevOps (DevSecOps)
- Seguridad avanzada de GitHub