Conclusiones sobre Azure Private Link

Sitio dedicado a Microsoft Azure y otras tecnologías Cloud

Diagrama de Private Link. Conexión privada entre una LAN op premise y servicios Cloud en Azure.

La compañía de seguros «Lo siento mucho» quiere publicar una herramienta web en Azure con datos sensibles que no deben estar accesibles desde internet.

Es decir, la aplicación de Intranet y la base de datos, sobre un servicio Azure SQL en formato PaaS, deben evitar cualquier superficie de ataque público y limitar de manera efectiva el acceso a este Sitio exclusivamente desde la red local.

El ocaso de los Services Endpoints.

Hasta la llegada de Private Links, la única forma de cumplir estos requisitos era por medio de los Services Endpoints que, realmente, no deshabilitan del todo el acceso desde internet, si no que lo bloquean.

Digamos que en vez de deshabilitar la conexión física del servicio con el endpoint público, lo que se pone es una regla de enrutado que limita las comunicaciones con una red virtual, ip privada o ip publica específicas, mediante listas blancas o políticas de restricción de acceso.

Además, se aplican sobre todos los servicios del tipo escogido, por ejemplo WebApps. De forma que si tengo una Web interna y una externa, las dos se verían afectadas de la misma forma por la configuración del Service Endpoint.

Y no tengo la seguridad completa de evitar una exfiltración desde mi servicio, al seguir habilitados los canales de comunicaciones públicas.

Private Link al rescate

Infraestructura que une un red privada local con tres redes virtuales pareadas en Azure con Servicios Cloud de forma interna sin ninguna conexión pública a Internet.

Según la documentación que ofrece el propio Azure, las ventajas claves de este nuevo servicio son:

  • Acceso privado a servicios en la plataforma Azure: puedo conectarme una red virtual a los servicios de Azure sin utilizar una dirección IP pública en el origen o en el destino. La plataforma Private Link administra la conectividad entre el consumidor y los servicios a través de la red troncal de Azure.
  • Redes locales y emparejadas: puedo acceder a los servicios que se ejecutan en Azure desde mi red local a través de ExpressRoute, mis VPN P2S o S2S y las redes virtuales emparejadas por peering. 
  • Protección contra la pérdida de datos: un punto de conexión privado se asigna a una instancia de un recurso de PaaS en lugar de al servicio entero. Los consumidores solo pueden conectarse al recurso específico. Se bloquea el acceso a cualquier otro recurso del servicio. Este es el mecanismo que proporciona protección contra los riesgos de pérdida de datos.
  • Alcance global: puedo conectarme de forma privada a los servicios que se ejecutan en otras regiones. La red virtual del consumidor podría estar en la región A y puede conectarse a los servicios que hay detrás de Private Link en la región B. Conectando diferentes grupos de recursos, suscripciones y tier de Directorio activo de Azure.

Creación de un ejémplo

La letra pequeña de los servicios en Azure

Enlace interno entre VM en una Virtual Network de Azure y un grupo de Azure SQL en PaaS por medio de Private Link.

Como he mostrado en el vídeo, solo vale ahora mismo desde dos regiones Estus y Westus 2, pero además se puede crear desde la propia WebApp, en su configuración de la red, creando un nuevo Private Endpoint.

Pero así no funciona.

Lo primero es que no me crea una zona DNS en dónde los servicios pueden encontrar un registro del tipo A, para recuperar la IP interna. Lo segundo es que solo funciona desde dentro del mismo grupo de recursos.

Osea que toca hacerlo desde «Añadir nuevo recurso» y el panel de alta de un Private Link. Vamos, como si fuera una SQL pero escogiendo Web.

Por otro lado hay un problema de comportamiento que le va a poner los pelos de punta a la gente de seguridad. Si entro en el grupo de recursos dónde tengo el Private Endpoint y lo borro, inmediatamente se me activa la IP pública y la DNS pública de mi sitio!!

MAL!!

Debería quedarse sin conexión, no que se desplegará una superficie de ataque que no está siendo controlada por nada. Así que lo único que se me ocurre es meter la WebApp en una Virtual Network, ponerle un NSG para bloquear todo lo que no entré por la red (lo cual no vale porque sigue abierto el puerto público) y ponerle una restricción de acceso a la IP pública (que tampoco porque con un cambio de SKU nos puede cambiar dicha IP Pública y volverá a responder desde Internet).

Osea, cuidadito con los permisos!!

Logotipo de Private Endpoint

Un próximo post/video/twitch estudiaré las posibilidades de este servicio pero para servicios IaaS: Private Link Service.

Espero que sea de ayuda

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.