¿Qué es Private Link?

Private Link permite acceder de forma privada a un servicio compatible, utilizando conectividad que permanece dentro de la infraestructura de Azure. En lugar de consumirlo necesariamente por su punto de entrada público, una aplicación puede llegar a él mediante una dirección privada de su red virtual. La utilidad práctica es acercar un servicio gestionado al diseño de red de la organización sin desplegar ese servicio dentro de sus propias máquinas.

Aquí hablamos de Azure Private Link, porque los nombres y las capacidades cambian entre proveedores. La idea aparece en otras nubes, pero no conviene trasladar sus configuraciones como si fueran intercambiables. Incluso dentro de Azure, cada servicio admite recursos, subrecursos y condiciones que hay que comprobar antes de diseñar el acceso.

Private Link y Private Endpoint cumplen papeles distintos

Private Link es la tecnología y Private Endpoint es el punto de conexión que la aplicación utiliza en su red virtual. Ese endpoint dispone de una interfaz de red con dirección privada y se vincula con el recurso que se quiere consumir. No es una copia del servicio ni una máquina que el equipo de sistemas deba mantener.

Una base de datos gestionada sirve como ejemplo. La aplicación sigue utilizando el nombre del servicio, pero la resolución de nombres debe llevarla al endpoint privado adecuado. El recorrido de red cambia sin convertir la base de datos en una instalación local. Sus permisos, configuración y responsabilidades de administración continúan existiendo.

La conexión también puede necesitar aprobación por parte del propietario del recurso. Tener una dirección privada disponible no otorga por sí mismo acceso a los datos. La autorización de red y la autenticación de la aplicación resuelven preguntas diferentes, y ambas deben funcionar para que una consulta termine correctamente.

-InfraCrew dice: Una entrada privada sigue necesitando llave. El cartel de «solo personal» nunca ha autenticado a nadie.-

El DNS forma parte del camino

Uno de los componentes más importantes es DNS, el sistema que traduce nombres a direcciones. Si una aplicación resuelve el nombre hacia la dirección pública, puede intentar un recorrido distinto del previsto. Crear el endpoint y dar por terminada la instalación deja precisamente esta parte sin demostrar.

Azure documenta zonas DNS privadas y configuraciones específicas para los servicios compatibles. La zona debe ser visible desde las redes que realmente consumen el servicio. Cuando intervienen otras redes virtuales o equipos locales, hay que revisar enlaces, resolutores y reenvío de consultas, en lugar de asumir que todos reciben la misma respuesta.

Una prueba útil parte del equipo que ejecuta la aplicación: resolver el nombre, comprobar la dirección obtenida y probar la conexión con las credenciales habituales. Un resultado correcto desde el portátil del administrador no acredita el comportamiento del servidor de producción. Sus rutas, DNS y reglas de salida pueden ser distintos.

Conectividad privada no significa configuración completa

Private Link tampoco sustituye a una VPN o a ExpressRoute para conectar una sede con Azure. La sede necesita una ruta hasta la red donde está el endpoint, además de resolver correctamente su nombre. El enlace privado al servicio y el acceso de la sede a esa red son piezas que deben encajar.

Otra comprobación importante es el acceso público del recurso. Crear un endpoint privado no implica desactivar automáticamente todas las entradas públicas del servicio. Si el objetivo exige cerrar esa exposición, debe hacerse con las opciones del recurso correspondiente y después comprobar qué clientes siguen necesitando acceder.

Conviene mantener también el cifrado de la conexión y los permisos de mínimo privilegio. La dirección privada cambia la exposición de red, no convierte cualquier solicitud en confiable. Un equipo comprometido dentro de la red puede seguir realizando peticiones; la aplicación y el servicio necesitan reconocer qué operaciones están autorizadas.

-InfraCrew dice: «Está dentro» describe una ubicación. Como política de seguridad, se queda bastante corto.-

Cómo llevarlo a producción sin perder el servicio de vista

Antes de implantarlo, identifica el recurso exacto, los consumidores y los nombres que utilizan. Una dependencia olvidada puede quedarse fuera aunque la aplicación principal funcione. Incluye herramientas de administración, procesos de integración y tareas de mantenimiento que también consulten el servicio, siempre según las capacidades documentadas de ese producto.

Planifica después la transición: qué se prueba antes de cerrar el acceso público, quién valida cada consumidor y cómo se revierte un cambio de DNS incorrecto. La secuencia importa tanto como el estado final. Cortar primero y descubrir después los clientes pendientes transforma una mejora de arquitectura en una incidencia evitable.

La disponibilidad merece una revisión propia. Tener un camino privado no garantiza que la aplicación soporte una caída regional o una dependencia mal distribuida. El diseño de recuperación debe incluir endpoints, nombres y rutas, junto con el servicio y sus datos; también conviene revisar límites y costes aplicables al consumo previsto.

Deja por último una comprobación repetible desde los consumidores reales. Resolver, conectar y completar una operación autorizada son tres evidencias distintas. Guardarlas permite reconocer si un fallo posterior pertenece a nombres, conectividad o permisos, sin empezar cada diagnóstico cambiando reglas a ciegas.

-InfraCrew dice: El DNS suele ser inocente hasta que alguien enseña la dirección a la que está resolviendo.-

Diccionario de la Crew

Private Endpoint — Interfaz con dirección privada que conecta una red virtual con un recurso compatible mediante Private Link.

DNS — Sistema que resuelve nombres de servicios y equipos a las direcciones necesarias para localizarlos.