Todos sabemos que la asignación de políticas de Azure es una de las mejores formas de tener un gobierno en la nube y muchas organizaciones utilizan las iniciativas integradas del centro de seguridad de Azure o las políticas creadas a medida para proteger su infraestructura/cargas de trabajo.
El siguiente artículo es para
arrojar algo de luz sobre cómo usar las políticas de Azure y las capacidades de
monitoreo del centro de seguridad de Azure juntas para crear barandillas de
seguridad en torno a la seguridad de la red y cómo el equipo de seguridad
cibernética/equipo de operaciones puede tener un solo panel para monitorear las
derivas.
Antes de
sumergirnos, veamos rápidamente qué ofrece el centro de seguridad de Azure:
Las características de Azure
Security Center cubren
los dos grandes pilares de la seguridad en la nube:
Gestión de postura de
seguridad en la nube (CSPM) : Security Center está disponible de forma
gratuita para todos los usuarios de Azure. La experiencia gratuita incluye
características de CSPM como puntaje seguro, detección de configuraciones
incorrectas de seguridad en sus máquinas de Azure, inventario de activos y
más. Utilice estas funciones de CSPM para fortalecer su postura de nube
híbrida y realizar un seguimiento del cumplimiento de las políticas integradas.
Protección de cargas de
trabajo en la nube (CWP) : la plataforma integrada de protección de
cargas de trabajo en la nube (CWPP) de Security Center , Azure Defender,
brinda protección avanzada e inteligente de sus cargas de trabajo y recursos
híbridos y de Azure. Habilitar Azure Defender trae una variedad de
características de seguridad adicionales.
Azure Defender es un producto de CWP
con capacidades de detección de amenazas impulsadas por ML e IA que no solo
incluye máquinas virtuales, sino también otros servicios de Azure como el
servicio de aplicaciones, el almacenamiento, los servidores SQL, Keyvault, etc.
Se puede acceder a Dashboard for AzD desde ( https://portal
.azure.com > Centro de seguridad > Azure defender )
. Esto viene con un costo adicional y los clientes pueden elegir optar por
el servicio seleccionando el plan AzD y habilitando los servicios requeridos.
Crédito: seminarios web de
Microsoft
Aquí vamos a usar la
capacidad CSPM del centro de seguridad de Azure para nuestro caso de uso, que
viene sin costo junto con la suscripción de Azure.
Las políticas de seguridad
habilitadas en Azure Security Center impulsan las recomendaciones y el
monitoreo de seguridad.
Una política de seguridad
define el conjunto de controles que se recomiendan para los recursos dentro de
la suscripción especificada. En Azure Security Center , define
políticas para sus suscripciones de Azure según los requisitos de seguridad de
su empresa y el tipo de aplicaciones o la confidencialidad de los datos en cada
suscripción.
Podemos escribir
declaraciones muy simples en JSON usando el editor de políticas de Azure para
crear estas plantillas y publicarlas como políticas de "ámbito" para
un grupo de administración, una suscripción o incluso un grupo de recursos
según el requisito. Podríamos agrupar múltiples políticas en una iniciativa
que sirve a un objetivo común (como una iniciativa para políticas relacionadas
con NIST, otra para estándares relacionados con CIS)
Antes de pasar
directamente a las políticas, analicemos algunos de los conceptos básicos sobre
la configuración de la red virtual de Azure y la conectividad de Internet
saliente para Azure, porque las políticas que intentamos crear abordarán casos
de uso de seguridad de red muy específicos.
En general, primero
configuramos una red virtual y luego
creamos una subred para implementar máquinas virtuales u otros recursos en el
entorno de Azure. De forma predeterminada, todas las subredes están
conectadas directamente y pueden comunicarse entre sí, dentro de la misma VNET.
Para una subred determinada,
se reservarán 5 IP para los requisitos internos de Azure. Todas las
VNET en segundo plano tienen una IP pública única asignada, lo que permite que
las cargas de trabajo se comuniquen con Internet, sin tener asignada ninguna
dirección IP pública o puerta de enlace NAT .
Tenemos muchas formas de
controlar o modificar este comportamiento predeterminado del tráfico saliente
de Azure a Internet: mediante la creación de una puerta de enlace NAT, la
asignación de una IP pública a una máquina virtual, la asociación de la VM con
un equilibrador de carga estándar o, finalmente, el uso de un NVA (dispositivo
virtual de red). o Firewall como servicio nativo de Azure.
Para la mayoría de las
organizaciones, un enfoque común será utilizar un NVA (dispositivo virtual de
red) o un firewall de Azure (firewall en la nube de Microsoft) y
crear una UDR (ruta definida por
el usuario) para forzar el tráfico por túnel, ya que esto nos permite enrutar
el tráfico saliente. a un cortafuegos local o a un cortafuegos en la nube para
filtrar/inspeccionar el tráfico por motivos de seguridad. Hay muchos
proveedores de cortafuegos conocidos que ofrecen NVA a través del mercado, como
Barracuda, Checkpoint, Palo Alto, etc.
También es una práctica común
que las organizaciones empleen políticas para garantizar que las ILPIP (IP
públicas de nivel de instancia) no estén asociadas directamente a la máquina
virtual y que estén en el firewall o en el equilibrador de carga externo, por
lo que es más escalable y fácil de usar. solucionar problemas. También
podemos asignar grupos de seguridad de red (NSG)
a una NIC oa un nivel de subred. Estos NSG se pueden usar para definir
reglas de cinco tuplas que se pueden aplicar para el flujo de tráfico saliente
o entrante.
La siguiente imagen muestra
un modelo muy común para la conectividad de Internet saliente para las cargas
de trabajo de Azure, donde los firewalls se implementan en una subred NVA, los
servidores web en otra subred dentro de la red virtual, con NSG de nivel de
subred para controlar el tráfico este-oeste. Esto también podría
extenderse fácilmente a un modelo HUB y SPOKE donde
el NVA se encuentra en una red virtual HUB y los servidores web se implementan
en una red virtual SPOKE, emparejados para permitir la comunicación entre ambas
redes virtuales.
Para simplificar, el
escenario anterior se representa a continuación. Observe la UDR en la
subred del servidor web para enrutar todo el tráfico saliente de Internet al LB
frontend de NVA para su inspección/cortafuegos y otra UDR en la subred de NVA para
enrutar directamente el tráfico a Internet.
Creación de rutas definidas por
el usuario para subredes para acceso saliente
Vamos a discutir sobre cuatro
políticas de seguridad diferentes que ayudarán a las organizaciones a
auditar/prevenir (según el "efecto" que elija en la política) eludir
diferentes controles de seguridad en torno a la asignación de UDR, el
siguiente salto utilizado y el uso de Internet como tipo de siguiente salto en
la UDR y, finalmente, NSG aplicado en la subred, etc.
A continuación se muestra la
lista de barandillas de seguridad que vamos a discutir aquí (se pueden usar
tanto como preventivas como de detección, según las políticas de la empresa). Aquí
estoy mostrando una mezcla de ambos.
1. Auditar UDR en subredes
2. Aplicar la dirección IP de NVA como 'NextHop
IP' en la UDR.
3. Forzar el tipo de salto siguiente no está
configurado en "Internet" para las subredes creadas en SPOKE Vnets.
4. Auditar NSG X en subredes
Ahora veamos estas políticas en detalle y lo que nos ayudan a lograr.
1. Auditar UDR en subredes
Esta política audita si una
tabla de rutas ( UDR ) está adjunta a la subred. Esto ayudará a
identificar cualquier configuración incorrecta (podría ser accidental o alguien
con intenciones maliciosas tratando de eludir los controles de seguridad) en
UDR mientras se crean subredes que a veces serán difíciles de identificar, ya
que las cargas de trabajo tomarán la ruta predeterminada y se conectarán a
Internet. Con esta política activada, podemos realizar una auditoría e
informar el cumplimiento o agregar un efecto para denegar la creación de
subredes sin tener adjunta la UDR específica. Poner la política y la
auditoría al principio y luego moverla para negar el efecto es la práctica
ideal para evaluar el riesgo y asegurarse de no romper nada. Además, de
forma predeterminada, esta política no tiene ningún efecto sobre los recursos
ya existentes, incluso con el efecto de denegación. (La aplicación de la
política solo se realizará para recursos futuros)
2. Hacer cumplir la dirección
IP de NVA como IP de NextHop
Esto es para hacer cumplir
las IP del próximo salto (IP NVA) en una regla UDR. Esta política evitará
que se pierdan configuraciones y permitirá a los administradores usar solo las
direcciones IP especificadas en la política de NextHop. Azure acepta
cualquier dirección IP de dispositivo que tenga el reenvío de puertos
habilitado en el campo NextHop, por lo que tener esta política garantiza que
nadie pueda configurar la regla incorrectamente de forma accidental o
malintencionada, lo que puede conducir a la filtración de datos o al incumplimiento
de los dispositivos perimetrales de la organización.
También puede modificar esta
política para usar los efectos 'Auditoría' o 'denegar' según el requisito
3. Exigir que el tipo de
salto siguiente no esté configurado en 'Internet' para las subredes creadas en
SPOKE Vnets.
Es igualmente importante no
permitir el tipo NextHop como 'Internet' para las VNET de Spoke, ya que esto
permitirá que las cargas de trabajo implementadas en una subred vayan
directamente a Internet, sin pasar por la NVA.
Esto aborda un riesgo
ligeramente diferente, pero en un nivel de configuración diferente, como puede
imaginar.
4. Auditar NSG X en subredes
Esta asignación de política
audita si una subred determinada tiene un NSG específico adjunto. Si su
organización tiene políticas para garantizar que todas las subredes deben tener
un NSG aplicado, para controlar el tráfico de este a oeste o de norte a sur,
para lograr la segmentación, esta política nos ayudará a verificar el
cumplimiento de su entorno. Puede especificar el ID del NSG o modificar la
política para informar si falta el NSG en la subred y proyectarlo por
incumplimiento.
Una vez aplicada, la política
nos proporcionará la vista de cumplimiento desde la hoja Política >
cumplimiento como se muestra a continuación.
Nota: puede agrupar todas
estas políticas en una iniciativa para que pueda adjuntarse fácilmente al
inicio personalizado del centro de seguridad más adelante.
Panel de cumplimiento de
políticas de Azure
Nota: Si nota que el estado
de cumplimiento es No iniciado, significa que la política se asignó, pero aún
debe ser evaluada por la política de Azure con respecto a los
recursos. Tendrá que esperar para obtener los informes de estado de
cumplimiento.
Ahora viene el caso de uso
real del centro de seguridad de Azure para monitorearlos y mostrar los recursos
"no saludables" en las recomendaciones. Esto ayudará al equipo
de seguridad o al equipo de infraestructura a monitorear la deriva, clasificar
o informar el cumplimiento de manera periódica.
Todo lo que tenemos que hacer
es crear una iniciativa de política (puede llamarla política de cumplimiento de
seguridad de red, por ejemplo) como se mencionó anteriormente en estas
políticas y luego agregarla como una iniciativa personalizada en el centro de
seguridad de Azure.
Vaya a Centro de seguridad
> Política de seguridad > Sus iniciativas personalizadas > Agregar una
iniciativa personalizada y seleccione la iniciativa de política que creó
Nota: Esto no requiere ninguna licencia,
disponible como parte de la oferta gratuita de ASC.
Una vez hecho esto, los verá
en la pestaña de recomendaciones como se muestra a continuación.
Ventana de recomendaciones del
centro de seguridad de Azure
Estas recomendaciones tendrán
una marca 'Personalizada' para que puedan distinguirse de otras
recomendaciones.
También es importante tener en cuenta que
ninguno de estos generará ningún costo en su factura de Azure (es decir, crear
políticas de Azure + monitoreo ASC). Si tuviera que enviar estos datos a
un SIEM de terceros para monitorear o almacenar las recomendaciones en el área
de trabajo de análisis de registros, eso generará algún costo en función del
volumen de alertas. )
¡Podemos definir muchas
políticas similares para abordar las configuraciones incorrectas generales que
actuarán como barreras para la aplicación de la seguridad y mejorarán el CSPM
(Gestión de posturas de seguridad en la nube) para las organizaciones y
utilizarán el poder de las políticas del centro de seguridad de Azure para
informar y monitorear el cumplimiento!
No hay comentarios.:
Publicar un comentario