Todos hemos usado alguna vez los Private Endpoints de Azure para acceder a nuestros servicios a través de la red interna sin necesidad de exponerlos a Internet. Pero la pregunta es ¿los hemos definido correctamente a nivel de arquitectura?
Empecemos por el principio, un Private Endpoints no es más que un servicio de Azure que nos va a permitir acceder a determinados servicios PaaS (un Storage Account, un key Vault, una bbdd SQL…etc.) a través de una IP interna (dinámica o manual) de nuestra Virtual Network. Básicamente lo que hace es asociar una tarjeta de red a dicho servicio, asignándole una IP* dentro de nuestro rango de red (más exactamente dentro de una subnet) y permitiéndonos por lo tanto securizarlo, ya que al acceder a través de la red interna estamos reduciendo nuestro grado de exposición del servicio y por lo tanto podemos denegar todo el tráfico exterior (internet).
Al crear este Private Endpoint nos dará la opción de integrarlo con el servicio Private DNS Zone y crear un “registro” con sus datos (si no existe una Private DNS Zone previo para este tipo de servicio nos lo creará). Esta práctica es la más recomendada ya que posteriormente nos permitirá llamar a un servicio por su nombre y nos resolverá automáticamente por la IP de nuestra red que se le ha asignado.
El formato de los Private DNS Zone es el siguiente, en función del servicio:
privatelink.blob.core.windows.net
privatelink.azuredatabricks.net
privatelink.azurecr.io
beehaviour-db.private.postgres.database.azure.com
privatelink.database.windows.net
privatelink.datafactory.azure.net
privatelink.documents.azure.com
privatelink.servicebus.windows.net
privatelink.vaultcore.azure.net
En este Link podéis encontrar la lista de servicios que permiten los Private EndPoint.
Pues bien, hasta aquí ya todos tenemos claro que es un Private Endpoint y como funciona a grandes rasgos. Ahora vamos a hablar de los problemas que surgen por no tener un buen diseño a nivel de arquitectura.
Por un lado, lo haremos desde un punto de vista de seguridad (en aquellos diseños en donde el tráfico de red y la seguridad no están centralizadas, como pasa en un diseño Hub-Spoke) y por otro desde un punto de vista de redes/resolución DNS.
Al crear un Private EndPoint para acceder a un determinado servicio, este servicio ya es accesible a través de la IP asociada y aquí está el “problema”, es accesible por cualquiera que tenga acceso a esa red interna ya que por defecto al crear este punto privado poca gente le asocia un Network Security Group (en este punto debemos recordar que no podemos asociar un NSG a la NIC asociada al Private EndPoint, sino que debe de ser a nivel de subnet).
Debemos partir de la idea de que al crear cualquier servicio de Azure (aunque sea un servicio de acceso interno) debemos restringir el acceso al mismo exclusivamente a aquellos que realmente lo necesiten a través de <Origen – Destino – Puerto – Protocolo>
Con la regla anterior estamos permitiendo el acceso desde nuestro servidor al KeyVault a través del puerto 443. Sin embargo, esta regla debe de ir acompañada de otra regla que prohíba el acceso para el resto de la red, dado que los NSG se crean con una regla propia que no puede tocarse y que permite todo el tráfico dentro de una Virtual Network.
Esta regla, desde un punto de vista de “Prioridad”, debe de ir después de las diversas reglas que permitan el acceso al Private EndPoint.
Con estas reglas nuestro Private EndPoint estará completamente protegido garantizando que el KeyVault solo sea accesible desde donde sea necesario y por el puerto y protocolo adecuado.
Como hemos comentado anteriormente, al crear un Private EndPoint podemos asociarlo a un Private DNS Zone (y es lo más recomendable) para que nos resuelva internamente el FQDN del servicio. Para ello ese Private DNS Zone debe de estar asociado a la Virtual Network dentro de la cual debemos de resolver ese nombre, y es aquí en donde en ocasiones nos encontramos con el problema de que al intentar asociar un Private DNS Zone esto no es posible porque Azure ya nos indica que existe un “Namespace” con el mismo nombre.
Esto es debido a que ya existe una zona (ej: privatelink.vaultcore.azure.net) con el mismo nombre. En el siguiente pantallazo podemos ver que se han creado dos Private DNS Zone para el servicio de Key Vault cada uno en un Resource Group distinto (y se usan en distintas Virtual Networks).
Este diseño “puede funcionar” (y resalto que está entre comillas ) siempre y cuando desde ninguna de las dos Virtual Networks sea necesario resolver un Private EndPoint que esté registrado en otro Private DNS Zone distinto al que ya tenga asociado.
Por esto lo mejor es centralizar la asociación de los Private EndPoint dentro de una única Private DNS Zone (para cada uno de los tipos de servicios) para de esta manera poder asociarla a varias Virtual Networks que necesiten acceder a un mismo tipo de servicios por la red interna.
A la hora de usar un Private EndPoint debemos de tener claro que es muy importante restringir el acceso al mismo (desde un punto de vista de red) ya sea a través de un NSG o de un Firewall (como podría ser una arquitectura centralizada) de forma que solo se permita acceder al mismo desde aquellos orígenes imprescindibles para la correcta ejecución de nuestra aplicación.
Asimismo, centralizar la creación de registros DNS en una misma Private DNS Zone para cada uno de los servicios que lo necesiten nos permitirá poder vincular la zona a varias Virtual Networks para su resolución interna.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
