Aplicaciones y servicios

Las aplicaciones y los datos asociados a ellas actúan en última instancia como almacén principal del valor empresarial en una plataforma en la nube. Aunque los componentes de la plataforma, como la identidad y el almacenamiento, sean elementos esenciales del entorno de seguridad, las aplicaciones desempeñan un papel enorme en los riesgos para la empresa porque:

  • Los procesos empresariales, encapsulados y ejecutados por las aplicaciones y los servicios, deben estar disponibles y proporcionarse con una alta integridad.

  • Las cargas de trabajo de la aplicación almacenan y procesan los datos empresariales que requieren un alto grado de seguridad en confidencialidad, integridad y disponibilidad.

Esta sección se centra en las aplicaciones escritas por la organización o por otros usuarios en nombre de la organización frente a las aplicaciones SaaS o comercializadas que se instalan en máquinas virtuales IaaS.

Diagram of Application Models

Las plataformas en la nube modernas, como Azure, pueden hospedar generaciones de aplicaciones tanto heredadas como modernas

  • Las aplicaciones heredadas se hospedan en máquinas virtuales de infraestructura como servicio (IaaS) que normalmente incluyen todas las dependencias, como el sistema operativo, el middleware y otros componentes.

  • Las aplicaciones modernas de plataforma como servicio (PaaS) no requieren que el propietario de la aplicación administre y proteja los sistemas operativos de servidor subyacentes; a veces, son totalmente "sin servidor" y se crean principalmente con funciones como servicio.

    Notas: Las formas populares de las aplicaciones modernas son código de aplicación hospedado en Azure App Services y aplicaciones contenedorizadas (aunque los contenedores también se pueden hospedar en máquinas virtuales de IaaS o también en el entorno local).

  • Híbrido: aunque las aplicaciones híbridas pueden adoptar muchas formas, la más común es un estado "IaaS Plus" en el que las aplicaciones heredadas se encuentran en una etapa de transición a una arquitectura moderna con servicios modernos que reemplazan a los componentes heredados o agregan una aplicación heredada.

La protección de una aplicación requiere garantías de seguridad para tres tipos de componentes diferentes:

  • Código de aplicación: es la lógica que define la aplicación personalizada que escribe. La seguridad de este código es responsabilidad del propietario de la aplicación en todas las generaciones de la arquitectura de la aplicación, incluidos los componentes o fragmentos de código abierto del código. La protección del código requiere la identificación y la mitigación de riesgos del diseño y la implementación de la aplicación, así como la evaluación del riesgo de la cadena de suministro de los componentes incluidos. Tenga en cuenta que, en la evolución de las aplicaciones hacia arquitecturas de microservicios, se dividirán los distintos aspectos del código de aplicación en servicios más pequeños y no habrá un solo código base monolítico.

  • Servicios de aplicación: son los distintos componentes normalizados que usa la aplicación, como bases de datos, proveedores de identidades, centros de eventos, administración de dispositivos de IoT, etc. Para los servicios en la nube, se trata de una responsabilidad compartida:

    • Proveedor de nube: la seguridad del servicio subyacente es responsabilidad del proveedor de la nube.

    • Propietario de la aplicación: el propietario de la aplicación es responsable de las implicaciones de seguridad de la configuración y el funcionamiento de las instancias de servicio usadas por la aplicación, incluidos los datos almacenados y procesados en el servicio.

  • Plataforma de hospedaje de aplicaciones: es el entorno informático en el que la aplicación se ejecuta realmente. En una empresa con aplicaciones hospedadas en el entorno local, en Azure y en nubes de terceros como, Amazon Web Services (AWS), podría adoptar muchas formas con variaciones significativas sobre quién es responsable de la seguridad:

    • Las aplicaciones heredadas normalmente requieren un sistema operativo completo (y cualquier middleware) hospedado en hardware físico o virtualizado. El hardware virtual se puede hospedar de forma local o en máquinas virtuales de infraestructura como servicio (IaaS). El propietario de la aplicación o sus equipos de infraestructura operan y protegen este sistema operativo, así como el middleware y otros componentes instalados.
      La responsabilidad de los componentes de virtualización del hardware físico y del sistema operativo (hosts de virtualización, sistemas operativos y servicios de administración) varía:

      • Local: el propietario de la aplicación o su organización es responsable del mantenimiento y la seguridad.

      • IaaS: el proveedor de la nube es responsable del mantenimiento y la seguridad de la infraestructura subyacente y la organización del propietario de la aplicación es responsable de la configuración de la máquina virtual, el sistema operativo y los componentes instalados en él.

    • Las aplicaciones modernas se hospedan en entornos de plataforma como servicio (PaaS), como un servicio de aplicaciones de Azure. En la mayoría de los tipos de servicio de aplicación, el sistema operativo subyacente se abstrae del propietario de la aplicación y está protegido por el proveedor de la nube. Los propietarios de la aplicación son responsables de la seguridad de las configuraciones del servicio de aplicación que se les proporcionan.

    • Los contenedores son un mecanismo de empaquetado de aplicaciones en el que las aplicaciones se abstraen del entorno en el que se ejecutan. Estas aplicaciones contenedorizadas se ajustan a los modelos modernos o heredados, en función de si se ejecutan en un servicio de contenedor por el proveedor de nube (aplicaciones modernas) o de un servidor administrado por la organización (local o en IaaS). Para más información, consulte la sección sobre la seguridad del contenedor más abajo.

Identificación y clasificación de aplicaciones críticas para la empresa

Asegúrese de que ha identificado y clasificado las aplicaciones de su cartera que son críticas para las funciones empresariales.

Normalmente, las organizaciones empresariales tienen una cartera de aplicaciones de gran tamaño, por lo que priorizar dónde se debe invertir tiempo y esfuerzo en tareas manuales y con un uso intensivo de recursos, como el modelado de amenazas, puede aumentar la eficacia del programa de seguridad.

Identifique las aplicaciones que tienen un alto impacto potencial o una alta exposición potencial al riesgo.

  • Alto impacto potencial: identifique la aplicación que podría afectar de manera significativa a la empresa si se viera comprometida. Puede adoptar una o varias de las formas siguientes:

    • Datos críticos para la empresa: aplicaciones que procesan o almacenan información, ya que provocaría un importante impacto en la empresa u objetivo si se pierde la confidencialidad, la integridad o la disponibilidad.

    • Datos regulados: aplicaciones que controlan instrumentos monetarios e información personal confidencial regulada por normas. Por ejemplo, el sector de tarjetas de pago (PCI) y la Ley sobre la transferibilidad y responsabilidad de los seguros médicos (HIPAA).

    • Disponibilidad crítica para la empresa: aplicaciones cuya funcionalidad es fundamental para las organizaciones, como las líneas de producción que generan ingresos, los dispositivos o los servicios críticos para la vida y la seguridad, así como otras funciones críticas.

    • Acceso significativo: aplicaciones que tienen acceso a los sistemas con un gran impacto potencial a través de medios técnicos, como

      • Credenciales almacenadas o claves/certificados que conceden acceso a los datos o al servicio

      • Permisos concedidos a través de listas de control de acceso u otros medios

  • Alta exposición a ataques: aplicaciones a las que atacantes pueden acceder fácilmente, como aplicaciones web en Internet. Las aplicaciones heredadas también pueden tener una mayor exposición, ya que los atacantes y los evaluadores de penetración suelen apuntar a ellas porque saben que suelen tener vulnerabilidades que son difíciles de corregir.

Adopción del enfoque de DevOps

Las organizaciones deben cambiar de un ciclo de desarrollo en "cascada" al ciclo de vida de DevOps de integración continua, entrega continua (CI/CD) para aplicaciones, tan rápido como práctico. DevOps es la unión de personas, procesos y herramientas para hacer posible la entrega continua de valor a los usuarios finales. La contracción Dev y Ops hace referencia a la combinación de las disciplinas de desarrollo y operaciones en equipos multidisciplinarios que trabajan con herramientas y prácticas compartidas y eficientes.

El modelo DevOps aumenta la capacidad de la organización de abordar rápidamente los problemas de seguridad sin tener que esperar a un ciclo de planeación y pruebas más largo de un modelo en cascada.

Aplicación de la guía de seguridad de DevOps

Las organizaciones deben utilizar la guía y la automatización para proteger las aplicaciones en la nube, en lugar de comenzar desde cero.

El uso de los recursos y las lecciones aprendidas por organizaciones externas pioneras en estos modelos puede acelerar la mejora de la postura de seguridad de una organización con menos gastos en esfuerzo y recursos.

Uso de servicios en la nube en lugar de implementaciones personalizadas

Los desarrolladores deben usar los servicios disponibles en el proveedor de nube para las funciones bien establecidas, como las bases de datos, el cifrado, el directorio de identidades y la autenticación, en lugar de escribir versiones personalizadas de ellas.

Estos servicios proporcionan una mayor seguridad, confiabilidad y eficacia, ya que los proveedores de nube los operan y protegen mediante equipos dedicados con una experiencia profunda en esas áreas. El uso de estos servicios también libera a los recursos de desarrollador de la proverbial reinvención de la rueda, por lo que pueden enfocar el tiempo de desarrollo en los requisitos únicos para la empresa. Esta práctica debe seguirse para evitar riesgos durante el desarrollo de nuevas aplicaciones, así como para reducir el riesgo de las aplicaciones existentes durante el ciclo de actualización planeado o con una actualización de la aplicación centrada en la seguridad.

Hay varias funciones que se deben priorizar en primer lugar debido a un posible impacto en la seguridad:

  • Identidad: los directorios de usuario y otras funciones de autenticación son complejos de desarrollar y muy importantes para las garantías de seguridad. Evite el uso de soluciones de autenticación internas y favorezca las funcionalidades consolidadas como Azure Active Directory (Azure AD), Azure AD B2B, Azure AD B2C o soluciones de terceros para autenticar y conceder permisos a usuarios, partners, clientes, aplicaciones, servicios y otras entidades.

  • Protección de datos: los desarrolladores deben usar funcionalidades establecidas de proveedores en la nube, como el cifrado nativo en servicios en la nube, para cifrar y proteger los datos. El mundo de la seguridad está plagado de ejemplos de intentos fallidos de proteger los datos o las contraseñas que no soportaron ataques reales. Si se requiere el uso directo de la criptografía, los desarrolladores deben llamar a algoritmos criptográficos bien establecidos y no intentar inventar los suyos propios.

  • Administración de claves: idealmente, use la identidad para la autenticación en lugar de controlar las claves directamente (vea Preferencia de autenticación de identidad sobre claves). En situaciones en las que el acceso a los servicios requieran acceso a claves, aproveche un servicio de administración de claves como Azure Key Vault o el Servicio de administración de claves de AWS para administrar y proteger estas claves, en lugar de intentar controlar las claves de forma segura en el código de la aplicación. Puede usar CredScan para detectar claves potencialmente expuestas en el código de la aplicación.

  • Configuraciones de aplicación: las configuraciones incoherentes de las aplicaciones pueden crear riesgos para la seguridad. Azure App Configuration proporciona un servicio para administrar la configuración de la aplicación y las marcas de características de forma centralizada, lo que ayuda a mitigar el riesgo.

Uso de capacidades de seguridad nativas en servicios de aplicaciones

Use las capacidades de seguridad nativas integradas en los servicios en la nube en lugar de agregar componentes de seguridad externos (para el cifrado de datos, el filtrado de tráfico de red, la detección de amenazas y otras funciones).

El proveedor de servicios mantiene y admite los controles de seguridad nativos, lo que elimina o reduce el esfuerzo necesario para integrar herramientas de seguridad externas y actualizar esas integraciones a lo largo del tiempo. Los servicios en la nube evolucionan rápidamente, lo que aumenta en gran medida la carga de mantener una herramienta externa y también el riesgo de perder la visibilidad y las protecciones de seguridad de estas herramientas si no se mantienen al día con el servicio en la nube.

Preferencia de la autenticación de identidad sobre las claves

Autentique siempre con servicios de identidad en lugar de claves criptográficas, cuando estén disponibles.

La administración de claves de forma segura con el código de aplicación es difícil y periódicamente provoca errores, como la publicación accidental de claves de acceso confidenciales en repositorios de código como GitHub. Los sistemas de identidad ofrecen una experiencia segura y que se puede usar para el control de acceso, con mecanismos sofisticados integrados para la rotación de claves, la supervisión de anomalías y mucho más. La mayoría de las organizaciones también tienen equipos experimentados dedicados a la administración de sistemas de identidad y pocas personas (si las hay) que administran activamente los sistemas de seguridad de claves.

En el caso de los servicios que ofrecen la autenticación de Azure AD como Azure Storage, Azure App Service, Azure Backup, úsela para la autenticación y la autorización. Para simplificar aún más el uso de identidades para desarrolladores, también puede aprovechar las identidades administradas para asignar identidades a recursos, como máquinas virtuales y App Services, de modo que los desarrolladores no tengan que administrar identidades dentro de la aplicación.

Enfoque ascendente para reducir el volumen y el impacto de los errores de seguridad

image showing bottom-up approach to reduce security bug volume and impact

Reduzca el número y la gravedad potencial de los errores de seguridad de la aplicación mediante la implementación de prácticas de seguridad y herramientas durante el ciclo de vida de desarrollo.

Los errores de seguridad pueden dar lugar a que se revelen datos confidenciales en una aplicación, se posibilite que los delincuentes modifiquen datos o registros, o que los datos o la aplicación no estén disponibles para su uso por parte de clientes y empleados. Las aplicaciones siempre tendrán algunos errores lógicos que pueden dar lugar a riesgos de seguridad, por lo que es importante detectarlos, evaluarlos y corregirlos para evitar daños en la reputación, los ingresos o los márgenes de la organización. Es más fácil y más barato resolverlos antes, en el ciclo de vida de desarrollo, que corregirlos una vez finalizada la prueba de la aplicación, que esté en uso en producción o que se haya infringido con frecuencia el principio denominado "desplazamiento a la izquierda" o "inserción a la izquierda".

La mitigación del riesgo de la aplicación se logra mediante la integración de prácticas y herramientas de seguridad en el ciclo de vida de desarrollo, a menudo denominado ciclo de vida de desarrollo seguro (SDL o SDLC). Microsoft ha publicado una serie de recomendaciones en una nota del producto titulada Desarrollo de aplicaciones seguras en Azure basada en el Ciclo de vida de desarrollo de seguridad de Microsoft para mitigar los riesgos comunes con la validación de la entrada y la salida, realizar pruebas aproximadas, revisiones de la superficie expuesta a ataques y mucho más.

Enfoque descendente a través del modelado de amenazas

image showing top-down approach through threat modeling

Realice el modelado de amenazas en las aplicaciones críticas para la empresa para detectar y mitigar los posibles riesgos para su organización.

El modelado de amenazas identifica los riesgos para la propia aplicación, así como los riesgos que la aplicación puede suponer para su empresa, en especial al evaluar aplicaciones individuales en un sistema mayor.

El modelado de amenazas puede usarse en cualquier fase de la aplicación, desarrollo o producción, pero es especialmente eficaz para las fases de diseño de nuevas funcionalidades, ya que todavía no existe ningún dato del mundo real para esa aplicación.

Dado que el modelado de amenazas es un ejercicio que requiere muchos conocimientos, se recomienda tomar medidas para reducir al mínimo la inversión en tiempo y maximizar el valor de seguridad:

  1. Priorizar por riesgo: aplique primero el modelado de amenazas a las aplicaciones críticas para la empresa que tendrían un impacto enorme en ella si se ven comprometidas.

  2. Limitar el ámbito: realice un modelado de amenazas en fases progresivas de detalle para identificar rápidamente las ganancias rápidas y mitigaciones accionables antes de dedicar una gran cantidad de esfuerzo manual:

    1. El método de inicio con preguntas simples (consulte Método de preguntas simples) que se documenta a continuación para obtener información sobre los riesgos y si se han implementado las protecciones básicas.

    2. Diseño de evaluación progresiva de la aplicación: como los recursos y los conocimientos están disponibles, pase a un análisis más avanzado con el método Técnicas avanzadas del modelado de amenazas de STRIDE u otro similar que el equipo ya use. Comience con el diseño de nivel de arquitectura y aumente progresivamente los detalles cuando el tiempo y los recursos lo permitan:

      1. Diseño de nivel de sistema: incluye aplicaciones y cómo interactúan entre sí.

      2. Nivel de aplicación: incluye los componentes de la aplicación y cómo interactúan entre sí.

      3. Nivel de componente: incluye cómo se compone el componente individual y cómo sus elementos interactúan entre sí.

  3. Alinear con el ciclo de vida de desarrollo: optimice los esfuerzos mediante la alineación de las actividades de modelado de amenazas con los ciclos de vida de desarrollo de aplicaciones.

    1. En cascada: asegúrese de que los proyectos principales deban incluir el modelado de amenazas durante el proceso de diseño y durante las actualizaciones significativas de la aplicación.

    2. DevOps: desencadene actividades de modelado de amenazas con una frecuencia que agregue valor de seguridad sin sobrecargar los equipos de desarrollo. Los puntos de integración válidos se dan durante la introducción de características o cambios importantes en la aplicación y una programación regular del calendario periódico, por ejemplo, cada trimestre para aplicaciones críticas para la empresa.

    3. Aplicaciones heredadas: estas aplicaciones normalmente carecen de soporte técnico, acceso al código fuente o conocimientos de la organización, por lo que debe realizar el modelado de amenazas de la mejor manera posible con el conocimiento o la experiencia de la aplicación que tiene disponible.

Método de preguntas simples

Este sencillo método de preguntas está diseñado para que los profesionales de la seguridad y los desarrolladores empiecen a trabajar en el modelado de amenazas antes de pasar a un método más avanzado, como el método de STRIDE u OWASP (consulte Enfoque descendente a través del modelado de amenazas).

Formule y responda a estas preguntas para cada aplicación o componente

  • ¿Está autenticando conexiones mediante Azure AD, TLS (con autenticación mutua) u otro protocolo de seguridad moderno aprobado por el equipo de seguridad? Esto protege frente al acceso no autorizado a la aplicación y a los datos

    • Entre los usuarios y la aplicación (si procede)

    • Entre diferentes componentes de la aplicación y servicios (si procede)

  • ¿Limita las cuentas que tienen acceso para escribir o modificar datos en la aplicación a solo aquellas que requieren hacerlo? Esto reduce el riesgo de alteración o de alteración de datos no autorizadas.

  • ¿Se registra la actividad de la aplicación y se introduce en la Administración de eventos e información de seguridad (SIEM) a través de Azure Monitor o una solución similar? Esto ayuda al equipo de seguridad a detectar los ataques y a investigarlos rápidamente.

  • ¿Están protegidos los datos críticos para la empresa con cifrado aprobado por el equipo de seguridad? Esto ayuda a la protección contra la copia no autorizada de los datos mientras están en reposo.

  • ¿Se cifra el tráfico de red entrante y saliente mediante TLS? Esto ayuda a la protección contra la copia no autorizada de los datos mientras están en tránsito.

  • ¿Está protegida la aplicación frente a ataques por denegación de servicio distribuido (DDoS) mediante servicios como la protección contra DDoS de Azure, Akamai o similar? Esto protege contra los ataques diseñados para sobrecargar la aplicación a fin de que no se pueda usar.

  • ¿Almacena la aplicación las credenciales o claves de inicio de sesión para tener acceso a otras aplicaciones, bases de datos o servicios? Esto ayuda a identificar si un ataque puede usar la aplicación para atacar a otros sistemas.

  • ¿Permiten los controles de la aplicación cumplir los requisitos de seguridad y privacidad para las localidades en las que trabaja? (Esto ayuda a proteger los datos privados del usuario y a evitar las multas de cumplimiento).

Importante: La seguridad es un tema complejo y los posibles riesgos están limitados solo por la imaginación de los atacantes inteligentes y motivados. Estas preguntas están diseñadas para ayudar a identificar brechas fáciles de detectar que los atacantes pueden aprovechar fácilmente. A medida que desarrolla confort y competencias con este método, puede mirar de aumentar la capacidad del modelo de amenazas progresando hacia técnicas avanzadas de modelado de amenazas.

Técnicas avanzadas de modelado de amenazas

Un modelo de amenazas más completo puede identificar más riesgos potenciales. Dos técnicas populares son STRIDE y OWASP.

  • El Ciclo de vida de desarrollo de seguridad de Microsoft ha documentado un proceso de modelado de amenazas y ha lanzado una herramienta gratuita para ayudarle con este proceso.

    • Este método evalúa los componentes de la aplicación, así como las conexiones y las relaciones con los posibles riesgos y se asignan al mnemotécnico STRIDE:

      • Suplantación de identidad

      • Alteración

      • Rechazo

      • Divulgación de información

      • Denegación de servicio

      • Elevación de privilegios

    • Este método se puede aplicar a cualquier nivel de diseño de los componentes de la aplicación específicos de la arquitectura de alto nivel.

  • OWASP: el proyecto de la seguridad de aplicaciones web (OWASP) ha documentado un enfoque de modelado de amenazas para las aplicaciones, que hace referencia a STRIDE y otros métodos: https://www.owasp.org/index.php/Application_Threat_Modeling

Uso de firewalls de aplicaciones web

Los firewalls de aplicaciones web (WAF) mitigan el riesgo de que un atacante pueda aprovechar las vulnerabilidades de seguridad más conocidas de las aplicaciones. Aunque no son perfectos, los WAF proporcionan un nivel de seguridad mínimo básico para las aplicaciones web.

Los WAF son una mitigación importante cuando los atacantes se dirigen a aplicaciones web como punto de entrada a una organización similar a un punto de conexión de cliente. Los WAF son adecuados para los dos casos siguientes

  • Las organizaciones sin un programa de seguridad de aplicaciones potente, ya que es una medida de seguridad crítica (muy similar a un paracaídas en un avión). Tenga en cuenta que este no debe ser el único mecanismo de seguridad planeado para reducir el volumen y la gravedad de los errores de seguridad en las aplicaciones. Para ver los detalles, consulte Reducción del volumen y el impacto de los errores de seguridad.

  • Las organizaciones que han invertido en la seguridad de las aplicaciones como los WAF proporcionan una mitigación más profunda de defensa adicional. En este caso, los WAF actúan como mecanismo de seguridad final en caso de que los procedimientos de seguridad no hayan detectado un error de seguridad en el ciclo de vida de desarrollo.

Microsoft incluye funcionalidades de WAF en Azure Application Gateway y muchos proveedores ofrecen estas funcionalidades como dispositivos de seguridad independientes o como parte de los firewalls de próxima generación.

Aplicación de procedimientos recomendados para la seguridad de contenedores

Las aplicaciones hospedadas en contenedores deben seguir los procedimientos recomendados generales de la aplicación, así como algunas directrices específicas para administrar este nuevo tipo de arquitectura de aplicación.

Las aplicaciones contenedorizadas se enfrentan a los mismos riesgos que cualquier aplicación y, además, se agregan nuevos requisitos para hospedar y administrar de forma segura las aplicaciones contenedorizadas.

Las arquitecturas de contenedores de aplicaciones introdujeron un nuevo nivel de abstracción y herramientas de administración (normalmente Kubernetes) que han aumentado la productividad de los desarrolladores y la adopción de los principios de DevOps.

Aunque se trata de un espacio emergente que evoluciona rápidamente, varias lecciones clave y procedimientos recomendados han quedado claros:

  • Use un servicio administrado de Kubernetes en lugar de instalar y administrar Kubernetes
    Kubernetes es un sistema muy complejo y todavía tiene una serie de configuraciones predeterminadas que no son seguras y hay pocos expertos de seguridad de Kubernetes en el mercado. Aunque esto ha ido mejorando en los últimos años con cada versión, todavía hay muchos riesgos que se deben mitigar.

  • Valide el contenedor y la cadena de suministro del contenedor
    Del mismo modo que debe validar la seguridad de cualquier código abierto que agregue a las aplicaciones, también debe validar los contenedores que agregue a las aplicaciones.

    • Asegúrese de que las prácticas aplicadas a la creación del contenedor se validen con los estándares de seguridad, como la aplicación de las actualizaciones de seguridad, el examen de código no deseado, por ejemplo, puertas traseras y minerías de criptomoneda ilícitas, el examen de vulnerabilidades de seguridad y la aplicación de prácticas seguras de desarrollo.

    • Examine periódicamente los contenedores para detectar los riesgos conocidos en el registro de contenedores, antes de utilizarlos o durante su uso.

  • Configure el registro de contenedores válidos conocidos
    Esto permite a los desarrolladores de su organización usar contenedores validados por seguridad rápidamente con poca fricción. Además, cree un proceso para que el desarrollador solicite y obtenga rápidamente la validación de seguridad de nuevos contenedores para animar a los desarrolladores a usar este proceso frente a una solución temporal.

  • No ejecute contenedores como raíz o como administrador, a menos que se requiera explícitamente
    Las versiones tempranas de los contenedores requerían privilegios de raíz (lo que facilita los ataques), pero ya no es necesario con las versiones actuales.

  • Supervisión de contenedores
    Asegúrese de implementar herramientas de supervisión de seguridad que sean compatibles con los contenedores para supervisar el comportamiento anómalo y permitir la investigación de incidentes.

Pasos siguientes

Para obtener más directrices de seguridad de Microsoft, consulte la documentación de seguridad de Microsoft.