Recomendaciones para crear una estrategia de segmentación
Se aplica a la recomendación de lista de comprobación de seguridad de Well-Architected Framework:
| SE:04 | Cree la segmentación intencionada y los perímetros en el diseño de la arquitectura y la superficie de la carga de trabajo en la plataforma. La estrategia de segmentación debe incluir redes, roles y responsabilidades, identidades de carga de trabajo y organización de recursos. |
|---|
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 funcione para usted.
Definiciones
| Término | Definición |
|---|---|
| Containment | Técnica para contener el radio de explosión si un atacante obtiene acceso a un segmento. |
| Acceso con privilegios mínimos | Principio de Confianza cero que pretende minimizar un conjunto de permisos para completar una función de trabajo. |
| Perímetro | Límite de confianza alrededor de un segmento. |
| Organización de recursos | Una estrategia para agrupar los recursos relacionados por flujos dentro de un segmento. |
| Rol | Conjunto de permisos necesarios para completar una función de trabajo. |
| Segment | Unidad lógica aislada de otras entidades y protegida por un conjunto de medidas de seguridad. |
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 para 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 distintos controles de identidad. 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
- Equipos 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 la 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 en el que 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 interrumpa el 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. Sin embargo, 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 el enrutamiento y los grupos de seguridad de red 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 los perímetros y el aislamiento. Perimeter hace referencia a los puntos de ubicación que se deben comprobar. El aislamiento consiste en agrupar. Contenga 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. Clarity reduce el riesgo de errores humanos y errores 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.
Equilibrio: la segmentación presenta 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 la ventaja 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.
Identidad como perímetro
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 el 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 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 identidad 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 está en peligro. Si el acceso está limitado por el tiempo, la superficie expuesta a ataques se reduce aún más. El acceso limitado por el tiempo es especialmente aplicable a cuentas críticas, como administradores o componentes de software que tienen una identidad en peligro.
El control de acceso basado en rol (RBAC) también da como resultado 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.
Para obtener información sobre los controles de identidad, consulte Administración de identidades y acceso.
A diferencia de los controles de acceso de 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.
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, está contenido e impedido de propagarse lateralmente a través del resto de la red.
Piense como un atacante para lograr un punto de apoyo 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 las redes funcionales de la carga de trabajo de las redes operativas.
Para conocer patrones comunes relacionados con la segmentación de redes, consulte Patrones de segmentación de redes.
El diseño arquitectónico de cambios de conectividad privada suele agregar 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.
Para obtener información sobre los controles de red, consulte Redes y conectividad.
Roles y responsabilidades
La segmentación que impide la confusión y los riesgos de seguridad se logra mediante la definición clara de 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.
Organización de recursos
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 poliglot para la separación por varios modelos de datos, la separación de funcionalidades como el almacenamiento de datos y el análisis, o para separarlos por 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.
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 mediante el aislamiento del 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 de 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 de Azure Virtual WAN Hub. 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. Azure admite la 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 de 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 identidades
Patrón 1: Agrupación basada en títulos de trabajo
Una manera de organizar los grupos de seguridad es por puesto 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 carga de trabajo en función de sus roles, sin tener en cuenta el trabajo que debe realizarse. Conceda permisos 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 un trabajo discreto que debe realizarse, no teniendo en cuenta la estructura del equipo. Con este patrón, se conceden permisos 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 los grupos del patrón 1. Algunos ejemplos de grupos basados en funciones son:
- 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
- Sitio activo o evaluación de prioridades de producción
- 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 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 foco, no el organigrama. Los organigramas y los roles de miembro a veces cambian. Capturar 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 flexibles)
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 las 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 tamaño de la red virtual. 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 su conexión para crear un segmento mayor. El emparejamiento debe realizarse cuando no se necesitan otros puntos de conexión públicos.
| Consideraciones | Patrón 1 | Patrón 2 |
|---|---|---|
| Conectividad y enrutamiento: cómo se comunica cada segmento | El enrutamiento del sistema proporciona conectividad predeterminada a los componentes de carga de trabajo. Ningún componente externo puede comunicarse con la carga de trabajo. | Dentro de la red virtual, igual que el patrón 1. Entre redes, el tráfico pasa a través de la red pública de Internet. No hay conectividad directa entre las redes. |
| Filtrado de tráfico de nivel de red | El tráfico entre los segmentos se permite de forma predeterminada. Use grupos de seguridad de red o ASG para filtrar el tráfico. | Dentro de la red virtual, igual que el patrón 1. Entre las redes, puede filtrar el tráfico de entrada y salida a través de un firewall. |
| Puntos de conexión públicos abiertos involuntarios | Las tarjetas de interfaz de red (NIC) no obtienen direcciones IP públicas. Las redes virtuales no se exponen a Internet API Management. | Igual que el patrón 1. Punto de conexión público abierto previsto en una red virtual, que puede estar mal configurado para aceptar más tráfico. |
Organización de recursos
Organización de los 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 compartido, 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 administrarse por un equipo de red. Los componentes dedicados a cargas de trabajo individuales deben estar en su propio segmento y se pueden dividir 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, al equipo de redes en la nube se le podría conceder 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 definiendo claramente los segmentos de 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. Es posible que conceda acceso de administración a algunos usuarios que necesiten configurar opciones como copias de seguridad de base de datos o usuarios que supervisen 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 para cada segmento y quite el acceso que ya no es necesario.
Nota
Algunos roles con privilegios elevados, como el rol de propietario en RBAC, proporcionan a los usuarios la capacidad de conceder a otros usuarios acceso a un recurso. Limite cuántos usuarios o grupos tienen asignado el rol de propietario y revise periódicamente los registros de auditoría para asegurarse de que solo realizan operaciones válidas.
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.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de