Recomendaciones para crear una estrategia de segmentación

Se aplica a la recomendación de lista de comprobación de seguridad del marco de trabajo bien diseñado:

Un segmento es una sección lógica de la solución que debe protegerse como una unidad. Una estrategia de segmentación define cómo se debe separar una unidad de otras unidades con su propio conjunto de requisitos y medidas de seguridad.

En esta guía se describen las recomendaciones para crear una estrategia de segmentación unificada. Mediante el uso de perímetros y límites de aislamiento en cargas de trabajo, puede diseñar un enfoque de seguridad que le convenga.

Definiciones 

Estrategias de diseño principales

El concepto de segmentación se usa normalmente para las redes. Sin embargo, se puede usar el mismo principio subyacente en toda una solución, incluida la segmentación de recursos con fines de administración y control de acceso.

La segmentación le ayuda a diseñar un enfoque de seguridad que aplica defensa en profundidad en función de los principios del modelo de Confianza cero. Asegúrese de que un atacante que infringe un segmento de red no puede obtener acceso a otro mediante la segmentación de cargas de trabajo con controles de identidad diferentes. En un sistema seguro, los atributos de identidad y red bloquean el acceso no autorizado y ocultan los recursos que se exponen. Estos son algunos ejemplos de segmentos:

• Suscripciones que aíslan las cargas de trabajo de una organización
• Grupos de recursos que aíslan los recursos de carga de trabajo
• Entornos de implementación que aíslan la implementación por fases
• Teams y roles que aíslan las funciones de trabajo relacionadas con el desarrollo y la administración de cargas de trabajo
• Niveles de aplicación que aíslan la utilidad de carga de trabajo
• Microservicios que aíslan un servicio de otro

Tenga en cuenta estos elementos clave de segmentación para asegurarse de que está creando una estrategia completa de defensa en profundidad:

• El límite o perímetro es el borde de entrada de un segmento donde se aplican controles de seguridad. Los controles perimetrales deben bloquear el acceso al segmento a menos que se permita explícitamente. El objetivo es evitar que un atacante se interrumpa a través del perímetro y obtenga el control del sistema. Por ejemplo, un nivel de aplicación podría aceptar el token de acceso de un usuario final cuando procesa una solicitud. Pero el nivel de datos puede requerir un token de acceso diferente que tenga un permiso específico, que solo puede solicitar el nivel de aplicación.

• La contención es el borde de salida de un segmento que impide el movimiento lateral en el sistema. El objetivo de la contención es minimizar el efecto de una infracción. Por ejemplo, una red virtual de Azure podría usarse para configurar grupos de seguridad de red y enrutamiento para permitir solo los patrones de tráfico que espera, evitando el tráfico a segmentos de red arbitrarios.

• El aislamiento es la práctica de agrupar entidades con garantías similares para protegerlos con un límite. El objetivo es facilitar la administración y la contención de un ataque dentro de un entorno. Por ejemplo, puede agrupar los recursos relacionados con una carga de trabajo específica en una suscripción de Azure y, a continuación, aplicar el control de acceso para que solo los equipos de carga de trabajo específicos puedan acceder a la suscripción.

Es importante tener en cuenta la distinción entre perímetros y aislamiento. Perimeter hace referencia a los puntos de ubicación que se deben comprobar. El aislamiento consiste en agrupar. Contienen activamente un ataque mediante el uso de estos conceptos juntos.

El aislamiento no significa crear silos en la organización. Una estrategia de segmentación unificada proporciona alineación entre los equipos técnicos y establece líneas claras de responsabilidad. La claridad reduce el riesgo de errores humanos y de automatización que pueden provocar vulnerabilidades de seguridad, tiempo de inactividad operativo o ambos. Supongamos que se detecta una infracción de seguridad en un componente de un sistema empresarial complejo. Es importante que todos comprendan quién es responsable de ese recurso para que la persona adecuada se incluya en el equipo de evaluación de prioridades. La organización y las partes interesadas pueden identificar rápidamente cómo responder a diferentes tipos de incidentes mediante la creación y documentación de una buena estrategia de segmentación.

Compensación: la segmentación introduce complejidad porque hay sobrecarga en la administración. También hay un equilibrio en el costo. Por ejemplo, se aprovisionan más recursos cuando se segmentan los entornos de implementación que se ejecutan en paralelo.

Riesgo: la microsegmentación más allá de un límite razonable pierde el beneficio del aislamiento. Al crear demasiados segmentos, resulta difícil identificar puntos de comunicación o permitir rutas de comunicación válidas dentro del segmento.

Establecimiento de la identidad como perímetro de seguridad principal

Varias identidades, como personas, componentes de software o dispositivos, acceden a segmentos de carga de trabajo. La identidad es un perímetro que debe ser la línea principal de defensa para autenticar y autorizar el acceso a través de los límites de aislamiento, independientemente de dónde se origine la solicitud de acceso. Use la identidad como perímetro para:

• Asigne acceso por rol. Las identidades solo necesitan acceso a los segmentos necesarios para realizar su trabajo. Minimice el acceso anónimo mediante la comprensión de los roles y responsabilidades de la identidad solicitante para que sepa la entidad que solicita acceso a un segmento y para qué propósito.

  Una identidad puede tener distintos ámbitos de acceso en distintos segmentos. Considere la posibilidad de configurar un entorno típico, con segmentos independientes para cada fase. Las identidades asociadas al rol de desarrollador tienen acceso de lectura y escritura al entorno de desarrollo. A medida que la implementación se mueve al almacenamiento provisional, esos permisos se reducen. En el momento en que la carga de trabajo se promueve a producción, el ámbito de los desarrolladores se reduce al acceso de solo lectura.

• Considere la posibilidad de usar las identidades de aplicación y administración por separado. En la mayoría de las soluciones, los usuarios tienen un nivel de acceso diferente al de los desarrolladores o operadores. En algunas aplicaciones, puede usar diferentes sistemas de identidades o directorios para cada tipo de identidad. Considere la posibilidad de usar ámbitos de acceso y crear roles independientes para cada identidad.

• Asigne acceso con privilegios mínimos. Si se permite el acceso a la identidad, determine el nivel de acceso. Comience con el privilegio mínimo para cada segmento y amplíe ese ámbito solo cuando sea necesario.

  Al aplicar el privilegio mínimo, se limitan los efectos negativos si la identidad se ve comprometida. Si el acceso está limitado por tiempo, la superficie expuesta a ataques se reduce aún más. El acceso limitado por tiempo es especialmente aplicable a cuentas críticas, como administradores o componentes de software que tienen una identidad en peligro.

Compensación: el rendimiento de la carga de trabajo puede verse afectado por los perímetros de identidad. La comprobación de cada solicitud requiere explícitamente ciclos de proceso adicionales y E/S de red adicionales.

El control de acceso basado en rol (RBAC) también da lugar a una sobrecarga de administración. Realizar un seguimiento de las identidades y sus ámbitos de acceso pueden ser complejos en las asignaciones de roles. La solución consiste en asignar roles a grupos de seguridad en lugar de identidades individuales.

Riesgo: la configuración de identidad puede ser compleja. Las configuraciones incorrectas pueden afectar a la confiabilidad de la carga de trabajo. Por ejemplo, supongamos que hay una asignación de roles mal configurada que se deniega el acceso a una base de datos. Las solicitudes comienzan a producir errores, lo que finalmente provoca problemas de confiabilidad que no se pueden detectar hasta el tiempo de ejecución.

Para obtener información sobre los controles de identidad, consulte Administración de identidades y acceso.

A diferencia de los controles de acceso a la red, la identidad valida el control de acceso en el momento del acceso. Se recomienda realizar una revisión de acceso normal y requerir un flujo de trabajo de aprobación para obtener privilegios para las cuentas de impacto crítico. Por ejemplo, consulte Patrones de segmentación de identidades.

Mejora con las redes como perímetro

Los perímetros de identidad son independientes de la red, mientras que los perímetros de red aumentan la identidad, pero nunca lo reemplazan. Los perímetros de red se establecen para controlar el radio de explosión, bloquear el acceso inesperado, prohibido y no seguro, y ofuscar los recursos de carga de trabajo.

Aunque el enfoque principal del perímetro de identidad es el privilegio mínimo, debe suponer que habrá una infracción al diseñar el perímetro de red.

Cree perímetros definidos por software en la superficie de red mediante servicios y características de Azure. Cuando una carga de trabajo (o partes de una carga de trabajo determinada) se coloca en segmentos independientes, se controla el tráfico de o a esos segmentos para proteger las rutas de comunicación. Si un segmento está en peligro, se incluye y se evita que se propague lateralmente a través del resto de la red.

Piense como un atacante para lograr un punto de conexión dentro de la carga de trabajo y establecer controles para minimizar la expansión. Los controles deben detectar, contener y impedir que los atacantes obtengan acceso a toda la carga de trabajo. Estos son algunos ejemplos de controles de red como perímetro:

• Defina el perímetro perimetral entre las redes públicas y la red donde se coloca la carga de trabajo. Restrinja la línea de visión de las redes públicas a la red tanto como sea posible.
• Implemente zonas desmilitarizadas (DMZ) delante de la aplicación con controles adecuados a través de firewalls.
• Cree microsegmentación dentro de la red privada mediante la agrupación de partes de la carga de trabajo en segmentos independientes. Establecer rutas de comunicación seguras entre ellas.
• Cree límites basados en la intención. Por ejemplo, segmente redes funcionales de cargas de trabajo de redes operativas.

Para conocer patrones comunes relacionados con la segmentación de redes, consulte Patrones de segmentación de redes.

Compensación: los controles de seguridad de red suelen ser costosos porque se incluyen con las SKU premium. La configuración de reglas en firewalls suele dar lugar a una complejidad abrumadora que requiere excepciones amplias.

La conectividad privada cambia el diseño de la arquitectura, a menudo agregando más componentes, como jump boxes para el acceso privado a los nodos de proceso.

Dado que los perímetros de red se basan en puntos de control o saltos, en la red, cada salto puede ser un posible punto de error. Estos puntos pueden tener un efecto en la confiabilidad del sistema.

Riesgo: los controles de red se basan en reglas y hay una posibilidad significativa de una configuración incorrecta, que es un problema de confiabilidad.

Para obtener información sobre los controles de red, consulte Redes y conectividad.

Definición de roles y líneas claras de responsabilidad

La segmentación que evita la confusión y los riesgos de seguridad se logra definiendo claramente las líneas de responsabilidad dentro de un equipo de carga de trabajo.

Documente y comparta roles y funciones para crear coherencia y facilitar la comunicación. Designe grupos o roles individuales responsables de las funciones clave. Tenga en cuenta los roles integrados en Azure antes de crear roles personalizados para objetos.

Considere la coherencia al adaptar varios modelos organizativos al asignar permisos para un segmento. Estos modelos pueden ir desde un único grupo de TI centralizado hasta equipos de TI y DevOps bastante independientes.

Riesgo: la pertenencia a grupos puede cambiar con el tiempo a medida que los empleados se unen o dejan equipos o cambian roles. La administración de roles entre segmentos puede dar lugar a una sobrecarga de administración.

Organización de recursos para promover la segmentación

La segmentación permite aislar los recursos de carga de trabajo de otras partes de la organización o incluso dentro del equipo. Las construcciones de Azure, como los grupos de administración, las suscripciones, los entornos y los grupos de recursos, son formas de organizar los recursos que promueven la segmentación. Estos son algunos ejemplos de aislamiento de nivel de recurso:

• La persistencia poliglot implica una combinación de tecnologías de almacenamiento de datos en lugar de un único sistema de base de datos para admitir la segmentación. Use la persistencia políglota para la separación entre varios modelos de datos, la separación de funcionalidades como el almacenamiento de datos y el análisis, o para separarlos mediante patrones de acceso.
• Asigne un servicio para cada servidor al organizar el proceso. Este nivel de aislamiento minimiza la complejidad y puede ayudar a contener un ataque.
• Azure proporciona aislamiento integrado para algunos servicios, por ejemplo, la separación del proceso del almacenamiento. Para ver otros ejemplos, consulte Aislamiento en la nube pública de Azure.

Compensación: el aislamiento de recursos puede dar lugar a un aumento del costo total de propiedad (TCO). En el caso de los almacenes de datos, puede haber complejidad y coordinación adicionales durante la recuperación ante desastres.

Facilitación de Azure

Algunos servicios de Azure están disponibles para su uso en la implementación de una estrategia de segmentación, como se describe en las secciones siguientes.

Identidad

RBAC de Azure admite la segmentación al aislar el acceso por función de trabajo. Solo se permiten determinadas acciones para determinados roles y ámbitos. Por ejemplo, las funciones de trabajo que solo necesitan observar el sistema se pueden asignar permisos de lector frente a permisos de colaborador que permiten a la identidad administrar recursos.

Para obtener más información, consulte Procedimientos recomendados para RBAC.

Redes

Redes virtuales: las redes virtuales proporcionan contención de nivel de red de recursos sin agregar tráfico entre dos redes virtuales. Las redes virtuales se crean en espacios de direcciones privadas dentro de una suscripción

Grupos de seguridad de red (NSG): un mecanismo de control de acceso para controlar el tráfico entre recursos en redes virtuales y redes externas, como Internet. Implemente rutas definidas por el usuario (UDR) para controlar el próximo salto para el tráfico. Los grupos de seguridad de red pueden llevar la estrategia de segmentación a un nivel granular mediante la creación de perímetros para una subred, una máquina virtual (VM) o un grupo de máquinas virtuales. Para obtener información sobre las posibles operaciones con subredes en Azure, consulte Subredes.

Grupos de seguridad de aplicaciones (ASG): los GRUPOS de seguridad de aplicaciones permiten agrupar un conjunto de máquinas virtuales en una etiqueta de aplicación y definir reglas de tráfico que se aplican a cada una de las máquinas virtuales subyacentes.

Azure Firewall: un servicio nativo en la nube, que se puede implementar en la red virtual o en las implementaciones del centro de Azure Virtual WAN . Use Azure Firewall para filtrar el tráfico que fluye entre los recursos en la nube, Internet y los recursos locales. Use Azure Firewall o Azure Firewall Manager para crear reglas o directivas que permitan o denieguen el tráfico mediante controles de nivel 3 a nivel 7. Filtre el tráfico de Internet mediante Azure Firewall y terceros mediante la dirección del tráfico a través de proveedores de seguridad de terceros para el filtrado avanzado y la protección del usuario. Soporte técnico de Azure implementación de aplicaciones virtuales de red, lo que ayuda a segmentar desde firewalls de terceros.

Ejemplo

Estos son algunos patrones comunes para segmentar una carga de trabajo en Azure. Elija un patrón en función de sus necesidades.

Este ejemplo se basa en el entorno de tecnología de la información (TI) establecido en la línea base de seguridad (SE:01). En el diagrama siguiente se muestra la segmentación en el nivel de grupo de administración realizado por una organización.

Patrones de segmentación de identidad

Patrón 1: Agrupación basada en títulos de trabajo

Una manera de organizar los grupos de seguridad es por título de trabajo, como ingeniero de software, administrador de bases de datos, ingeniero de confiabilidad de sitios, ingeniero de control de calidad o analista de seguridad. Este enfoque implica la creación de grupos de seguridad para el equipo de cargas de trabajo en función de sus roles, sin tener en cuenta el trabajo que debe realizarse. Conceda permisos de RBAC de grupos de seguridad, de pie o just-in-time (JIT), según sus responsabilidades en la carga de trabajo. Asigne principios humanos y de servicio a los grupos de seguridad en función de su acceso según sea necesario.

La pertenencia es muy visible en el nivel de asignación de roles, lo que facilita ver a qué tiene acceso un rol . Cada persona suele ser miembro de un solo grupo de seguridad, lo que facilita la incorporación y retirada. Sin embargo, a menos que los títulos de trabajo se superpongan perfectamente con responsabilidades, la agrupación basada en títulos no es ideal para la implementación con privilegios mínimos. Es posible que termine combinando la implementación con la agrupación basada en funciones.

Patrón 2: agrupación basada en funciones

La agrupación basada en funciones es un método de organización de grupo de seguridad que refleja el trabajo discreto que debe realizarse, no teniendo en cuenta la estructura del equipo. Con este patrón, se conceden permisos de RBAC de grupos de seguridad, permanentes o JIT según sea necesario, según su función necesaria en la carga de trabajo.

Asigne principios humanos y de servicio a los grupos de seguridad en función de su acceso según sea necesario. Siempre que sea posible, use grupos homogéneos existentes como miembros de los grupos basados en funciones, como esos grupos del patrón 1. Entre los ejemplos de grupos basados en funciones se incluyen:

• Operadores de base de datos de producción
• Operadores de base de datos de preproducción
• Operadores de rotación de certificados de producción
• Operadores de rotación de certificados de preproducción
• Producción de sitios en directo/evaluación de prioridades
• Preproducción de todo el acceso

Este enfoque mantiene el acceso con privilegios mínimos más estricto y proporciona grupos de seguridad en los que el ámbito es evidente, lo que facilita la auditoría de las pertenencias en relación con las tareas de trabajo realizadas. A menudo existe un rol integrado de Azure para que coincida con esta función de trabajo.

Sin embargo, la pertenencia se abstrae al menos en una capa, lo que le obliga a ir al proveedor de identidades para comprender quién está en el grupo al mirar desde la perspectiva del recurso. Además, una persona debe tener varias pertenencias mantenidas para una cobertura completa. La matriz de grupos de seguridad superpuestos puede ser compleja.

Se recomienda el patrón 2 para que los patrones de acceso sean el enfoque, no el organigrama. Los organigramas y los roles de miembro a veces cambian. La captura de la administración de identidades y acceso de la carga de trabajo desde una perspectiva funcional le permite abstraer la organización del equipo de la administración segura de la carga de trabajo.

Patrones de segmentación de redes

Patrón 1: Segmentación dentro de una carga de trabajo (límites suaves)

En este patrón, la carga de trabajo se coloca en una sola red virtual mediante subredes para marcar los límites. La segmentación se logra mediante dos subredes, una para la base de datos y otra para cargas de trabajo web. Debe configurar grupos de seguridad de red que permitan que la subred 1 solo se comunique con la subred 2 y la subred 2 para que solo se comuniquen con Internet. Este patrón proporciona control de nivel 3.

Patrón 2: Segmentación dentro de una carga de trabajo

Este patrón es un ejemplo de segmentación de nivel de plataforma. Las cargas de trabajo components se distribuyen entre varias redes sin emparejamiento entre ellas. Toda la comunicación se enruta a través de un intermediario que actúa como punto de acceso público. El equipo de carga de trabajo posee todas las redes.

El patrón 2 proporciona contención, pero tiene la complejidad adicional de la administración y el ajuste de tamaño de las redes virtuales. La comunicación entre las dos redes tiene lugar a través de la red pública de Internet, lo que puede ser un riesgo. También hay latencia con conexiones públicas. Sin embargo, las dos redes se pueden emparejar y dividir la segmentación mediante la conexión para crear un segmento mayor. El emparejamiento debe realizarse cuando no se necesitan otros puntos de conexión públicos.

Organización de recursos

Organización de recursos de Azure en función de la responsabilidad de propiedad

Considere un patrimonio de Azure que contiene varias cargas de trabajo y componentes de servicio compartidos, como redes virtuales de concentrador, firewalls, servicios de identidad y servicios de seguridad como Microsoft Sentinel. Los componentes de todo el patrimonio deben agruparse en función de sus áreas funcionales, cargas de trabajo y propiedad. Por ejemplo, los recursos de red compartidos deben agruparse en una sola suscripción y administrarlos un equipo de red. Los componentes dedicados a cargas de trabajo individuales deben estar en su propio segmento y pueden dividirse aún más en función de los niveles de aplicación u otros principios de la organización.

Conceda acceso para administrar recursos dentro de segmentos individuales mediante la creación de asignaciones de roles de RBAC. Por ejemplo, el equipo de red en la nube podría concederse acceso administrativo a la suscripción que contiene sus recursos, pero no a suscripciones de cargas de trabajo individuales.

Una buena estrategia de segmentación permite identificar fácilmente a los propietarios de cada segmento. Considere la posibilidad de usar etiquetas de recursos de Azure para anotar grupos de recursos o suscripciones con el equipo propietario.

Configuración y revisión del control de acceso

Conceda el acceso adecuado en función de la necesidad mediante la definición clara de segmentos para los recursos.

Tenga en cuenta el principio de privilegios mínimos al definir directivas de control de acceso. Es importante distinguir entre las operaciones del plano de control (administración del propio recurso) y las operaciones del plano de datos (acceso a los datos almacenados por el recurso). Por ejemplo, supongamos que tiene una carga de trabajo que contiene una base de datos con información confidencial sobre los empleados. Puede conceder acceso de administración a algunos usuarios que necesitan configurar opciones como copias de seguridad de base de datos o usuarios que supervisan el rendimiento del servidor de bases de datos. Sin embargo, estos usuarios no deben poder consultar los datos confidenciales almacenados en la base de datos. Seleccione los permisos que conceden el ámbito mínimo necesario para que los usuarios realicen sus tareas. Revise periódicamente las asignaciones de roles de cada segmento y quite el acceso que ya no es necesario.

Vínculos relacionados

• Aislamiento en la nube pública de Azure
• Recomendaciones para RBAC
• Introducción a las redes virtuales
• ASG
• Azure Firewall
• Introducción a Firewall Manager

Lista de comprobación de seguridad

Consulte el conjunto completo de recomendaciones.