Asegurando el Acceso a LLM con IPs de Egreso de Confianza

El acceso a la mayoría de los endpoints de LLM alojados está protegido por una clave API compartida codificada en las configuraciones del cliente. Las claves API son fáciles de implementar pero fáciles de compartir, filtrar o exfiltrar — y dado que la inferencia de LLM tiene un costo computacional elevado, el uso no autorizado puede generar costos significativos e inesperados.

Esto es tanto un problema de seguridad como un problema de gobierno de costos.

Network Relay de Jamf combinado con restricciones de IPs de egreso de confianza aborda esta brecha con un enfoque sin intervención del usuario.

El Problema: Las Claves API por Sí Solas No Son Suficientes

Un ejemplo típico de implementación de LLM alojado:

La organización implementa un modelo (p. ej., Llama 3, Mistral o una variante ajustada) en infraestructura interna o dentro de un VPC en la nube (AWS, Azure, GCP).
Se expone un endpoint de API — a menudo compatible con OpenAI — que acepta solicitudes autenticadas con una clave API compartida.
La clave API se distribuye a los clientes a través de perfiles de configuración, MDM, variables de entorno o documentación para desarrolladores.

El problema es que las claves API son secretos estáticos y de larga duración que son fáciles de filtrar:

Un desarrollador copia la clave en un proyecto personal o cuaderno.
La clave se confirma en un repositorio de Git (incluso uno privado).
Un empleado comparte la clave con un colega o contratista no autorizado.
Un dispositivo con la clave configurada se pierde o se ve comprometido.

Una vez que una clave está en la red, cualquiera que la tenga puede consumir sus recursos de LLM desde cualquier dispositivo, cualquier red, en cualquier lugar. Dado que la inferencia de LLM puede costar desde fracciones de centavo hasta varios dólares por solicitud según el modelo y la longitud del prompt, el uso no autorizado puede generar facturas sustanciales — o peor, exponer datos internos sensibles si el modelo ha sido ajustado con información patentada.

Las mitigaciones tradicionales como la rotación de claves ayudan, pero introducen complejidad operativa y no resuelven el problema fundamental:

La clave por sí sola no puede verificar que la solicitud se origina desde un dispositivo de confianza y gestionado.

La Solución: Network Relay + Bloqueo de IP de Egreso de Confianza

Network Relay de Jamf, construido sobre el protocolo MASQUE nativo de Apple y Managed Device Attestation (MDA), permite a las organizaciones restringir el acceso a endpoints de LLM a dispositivos Apple verificados y gestionados — sin requerir interacción del usuario final.

La arquitectura:

1. El Tráfico de Dispositivos Gestionados se Enruta a Través de la Nube de Seguridad de Jamf

Cuando Network Relay se implementa a través de MDM, todo el tráfico destinado al dominio de su endpoint de LLM se tuneliza automáticamente a través de la Nube de Seguridad de Jamf usando túneles MASQUE/HTTP3 cifrados. La identidad del dispositivo se verifica criptográficamente usando claves vinculadas al hardware desde Apple Secure Enclave a través de Managed Device Attestation, por lo que solo dispositivos genuinos gestionados por la empresa pueden establecer estos túneles.

2. El Tráfico Egresa a través de Direcciones IP Conocidas de Jamf

Una vez que el tráfico pasa a través de la Nube de Seguridad de Jamf y la evaluación de políticas, sale (egresa) hacia Internet — y por lo tanto hacia su endpoint de LLM — desde un conjunto conocido y determinístico de direcciones IP de Jamf. Estas pueden ser:

IPs de egreso compartidas de una de las regiones del centro de datos global de Jamf.
IPs de egreso dedicadas que se asignan de forma única a su organización — proporcionando dos IPs públicas de alta disponibilidad por región que ningún otro cliente de Jamf utiliza.

3. Su Endpoint de LLM Restringe el Acceso Solo a IPs de Confianza

Con su tráfico llegando ahora desde un conjunto conocido y confiable de direcciones IP, configura su infraestructura de LLM para aceptar solo conexiones de esas IPs de egreso de Jamf — rechazando todas las demás. Esta es la lista blanca de IP estándar aplicada en la capa de red:

LLMs alojados en la nube (AWS/Azure/GCP): Configure Security Groups, Network Security Groups o reglas de firewall para permitir solo HTTPS entrante (TCP/443) desde sus IPs de egreso de Jamf. Vea abajo para un ejemplo en AWS Bedrock Enlace a Mi Encabezado
LLMs en las instalaciones: Configure su firewall perimetral o proxy inverso (p. ej., nginx, HAProxy, Caddy) para aceptar solo conexiones desde los rangos de IP de egreso de Jamf.
API Gateway / Proxy de LLM (p. ej., LiteLLM, OpenWebUI): Muchas soluciones de gateway de LLM soportan lista blanca de IP en la capa de aplicación como una medida adicional de defensa en profundidad.

El resultado: incluso si una clave API se filtra, es inútil a menos que la solicitud se origina desde un dispositivo gestionado enrutado a través de su inquilino de la Nube de Seguridad de Jamf.

Por Qué Network Relay

La diferencia clave con respecto al bloqueo de IP tradicional basado en VPN es el modelo de implementación sin intervención del usuario y sin agente:

No se requiere instalación de aplicaciones. Network Relay se configura completamente a través de perfiles de configuración de MDM implementados desde Jamf Pro. No hay cliente VPN que instalar, no se requiere la aplicación Jamf Trust para la funcionalidad de relay básica, y no hay paso de inicio de sesión o activación del usuario.
Sin interacción del usuario. Una vez que el perfil de relay se instala en un dispositivo gestionado, se activa automáticamente. El usuario no ve un botón de alternancia de VPN, ingresa credenciales para acceso de red ni se ve interrumpido. El tráfico a los dominios de LLM definidos se tuneliza transparentemente.
Confianza de dispositivo enraizada en hardware. Managed Device Attestation utiliza Apple Secure Enclave para probar criptográficamente que un dispositivo es hardware genuino de Apple, gestionado por el MDM de su organización y no ha sido alterado. Esto proporciona una señal de identidad más fuerte que los agentes solo de software.
Precisión por dominio. A diferencia de un VPN de túnel completo que enruta todo el tráfico, Network Relay opera por dominio. Usted define exactamente qué dominios (p. ej., llm.internal.suempresa.com) deben ser enrutados a través de Jamf — dejando todo otro tráfico sin afectación. Esto minimiza el impacto en el rendimiento y evita el compromiso "todo o nada" de las arquitecturas VPN heredadas.
Funciona en todas las plataformas de Apple. Network Relay es soportado en macOS, iOS, iPadOS y visionOS, y puede ser gestionado desde una única configuración.

*N.b. También es posible usar bloqueo de IP con la solución ZTNA de Jamf en plataformas que no son de Apple.

Descripción General de Implementación

Los siguientes pasos describen la configuración de extremo a extremo:

Paso 1: Configurar Egreso en la Nube de Seguridad de Jamf

En la Nube de Seguridad de Jamf (consola RADAR), navegue a Integrations > Access Gateways y anote sus IPs de egreso compartidas para su región preferida, o cree un Dedicated Internet Gateway para recibir dos IPs públicas únicas asignadas exclusivamente a su organización.

Para gateways dedicados, puede crear múltiples gateways regionales y agruparlos para que los dispositivos utilicen automáticamente el punto de egreso más cercano según su conexión a la Nube de Seguridad de Jamf.

Paso 2: Crear una Política de Acceso para su Endpoint de LLM

Navegue a Policies > Access Policies y cree una nueva política:

Defina los dominio(s) del endpoint de LLM (p. ej., llm.suempresa.com, api.ai.internal.suempresa.com).
Establezca el enrutamiento para usar su gateway de egreso elegido (compartido o dedicado).
Configure la política para aplicarse a los grupos de dispositivos apropiados.

Paso 3: Implementar el Perfil de Network Relay

Navegue a Devices > Activation Profiles y cree o actualice su perfil de activación de Network Relay:

En Service Capabilities, asegúrese de que Zero Trust Network Access esté seleccionado.
En Authentication, seleccione Managed Device Attestation para activación sin contraseña y sin intervención del usuario.
Implemente los perfiles de configuración resultantes en sus dispositivos gestionados a través de Jamf Pro.

Una vez implementado, los dispositivos comenzarán automáticamente a enrutar el tráfico a sus dominios de LLM a través de la Nube de Seguridad de Jamf.

Paso 4: Bloquear su Endpoint de LLM a IPs de Egreso de Jamf

En el lado de la infraestructura de LLM, restrinja el acceso entrante solo a sus direcciones IP de egreso de Jamf. Ejemplos:

AWS Security Group:

Inbound Rule:
  Type: HTTPS (TCP 443)
  Source: <IP de Egreso de Jamf 1>/32, <IP de Egreso de Jamf 2>/32
  Description: Solo Dispositivos de Confianza de Jamf

nginx reverse proxy:

server {
    listen 443 ssl;
    server_name llm.suempresa.com;

    # Solo permitir IPs de egreso de Jamf
    allow <IP de Egreso de Jamf 1>;
    allow <IP de Egreso de Jamf 2>;
    deny all;

    location / {
        proxy_pass http://localhost:8080;  # Su servidor de inferencia de LLM
    }
}

Azure Network Security Group:

Inbound security rule:
  Priority: 100
  Source: <IP de Egreso de Jamf 1>/32, <IP de Egreso de Jamf 2>/32
  Destination port: 443
  Protocol: TCP
  Action: Allow

Inbound security rule:
  Priority: 200
  Source: Any
  Destination port: 443
  Protocol: TCP
  Action: Deny

Paso 5: Validar y Monitorear

Desde un dispositivo gestionado con el perfil de relay implementado, confirme que las solicitudes a su endpoint de LLM tienen éxito.
Desde un dispositivo no gestionado (o con el perfil de relay eliminado), confirme que las solicitudes se bloquean.
Monitoree los registros de acceso en su infraestructura de LLM para verificar que todas las conexiones entrantes se originan desde sus IPs de egreso de Jamf esperadas.
Revise los registros de conexión en la sección Reports > Access de la Nube de Seguridad de Jamf para visibilidad sobre qué usuarios y dispositivos están accediendo al endpoint de LLM.

Extendiendo a Servicios LLM Gestionados: AWS Bedrock

El mismo enfoque de IP de egreso confiable se aplica más allá de los modelos auto-hospedados. Si su organización utiliza Amazon Bedrock para inferencia de LLM gestionada, puede aplicar restricciones basadas en IP usando políticas de AWS IAM con condiciones aws:SourceIp — asegurando que solo las solicitudes originadas desde sus IPs de egreso de Jamf puedan invocar modelos de Bedrock.

A diferencia de las implementaciones auto-hospedadas donde controla la capa de red (Security Groups, firewalls), Bedrock es un servicio AWS completamente gestionado. No configura reglas de firewall entrantes en Bedrock en sí. En su lugar, adjunta políticas de IAM que niegan la invocación del modelo a menos que la solicitud provenga de una IP de confianza.

Política de Negación de IAM: Restringir la Invocación de Bedrock por IP de Origen

Adjunte la siguiente política a los usuarios, roles o grupos de IAM que tienen acceso a Bedrock. La negación explícita anula cualquier declaración de permiso, asegurando que las llamadas de Bedrock se bloqueen a menos que se originen desde sus IPs de egreso de Jamf:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyBedrockUnlessTrustedIP",
            "Effect": "Deny",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "arn:aws:bedrock:*:*:model/*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "<IP de Egreso de Jamf 1>/32",
                        "<IP de Egreso de Jamf 2>/32"
                    ]
                }
            }
        }
    ]
}

Esta política permite que todos los demás permisos de Bedrock (p. ej., listar modelos, gestionar rendimiento provisionado) funcionen normalmente — solo restringe las acciones de invocación de inferencia a IPs de confianza. Si sus políticas de IAM existentes ya contienen reglas DENY explícitas, puede que necesite agregar una declaración ALLOW explícita para IPs de confianza en su lugar de confiar en el permiso implícito.

Política de Control de Servicio (SCP) para Aplicación en Toda la Organización

Si desea aplicar la restricción de IP en todas las cuentas de AWS en su organización — no solo en principios de IAM individuales — aplíquela como una SCP en AWS Organizations:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceBedrockIPRestriction",
            "Effect": "Deny",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "<IP de Egreso de Jamf 1>/32",
                        "<IP de Egreso de Jamf 2>/32"
                    ]
                },
                "BoolIfExists": {
                    "aws:ViaAWSService": "false"
                }
            }
        }
    ]
}

La condición aws:ViaAWSService se incluye para que la negación no bloquee inadvertidamente llamadas de Bedrock realizadas por otros servicios de AWS en su nombre (p. ej., una función Lambda invocando Bedrock dentro de su VPC, flujos de Step Functions llamando a Bedrock o cuadernos de SageMaker usando Bedrock para inferencia). Asegura que la restricción de IP solo se aplique a llamadas de API directas — que es exactamente la ruta que toman los dispositivos de usuario final a través del relay de Jamf.

Consideraciones Clave para Bedrock

aws:SourceIp se aplica a llamadas de API directas sobre Internet pública. Esta es la ruta esperada cuando el tráfico fluye desde un dispositivo gestionado → Nube de Seguridad de Jamf → IP de egreso de Jamf → endpoint de API de AWS Bedrock.
Acceso a través de VPC Endpoint: Si también accede a Bedrock a través de un VPC endpoint, aws:SourceIp no se evalúa. Use aws:VpcSourceIp o políticas de VPC endpoint para controlar el acceso en esa ruta por separado.
Inferencia entre regiones de Bedrock: Si utiliza perfiles de inferencia entre regiones, asegúrese de que su Resource de política cubra las regiones relevantes o use un comodín como se muestra arriba.
Pruebas: Utilice el Simulador de Política de IAM o haga llamadas de prueba InvokeModel tanto desde un dispositivo gestionado (debería tener éxito) como desde un dispositivo no gestionado (debería recibir AccessDenied) para validar la política antes de su implementación amplia.

Defensa en Profundidad: Combinación de Bloqueo de IP con Claves API

Es importante notar que la restricción de acceso basada en IP complementa la autenticación de clave API — no la reemplaza. La postura recomendada es combinar ambos controles:

Capa	Control	Lo Que Prueba
Red	Lista blanca de IP de egreso de Jamf	La solicitud se origina desde un dispositivo atestiguado y gestionado
Aplicación	Clave API / token	La solicitud está autorizada para el servicio de LLM específico
(Opcional) Identidad	Integración de IdP / OAuth	La solicitud está vinculada a un usuario específico autenticado

Con este enfoque en capas, un atacante necesitaría simultáneamente poseer una clave API válida y estar operando desde un dispositivo gestionado por Jamf con atestación de hardware — una barra significativamente más alta que cualquiera de los controles por sí solo.

Resumen

Los LLMs auto-hospedados representan un compromiso significativo de infraestructura para organizaciones que necesitan controlar sus datos, costos y cadena de suministro de IA. Ese compromiso se ve socavado si el acceso se basa únicamente en claves API compartidas que pueden filtrarse y usarse desde cualquier dispositivo en Internet.

La implementación de Network Relay con restricciones de IP de egreso de confianza proporciona:

Confianza de dispositivo criptográfica enraizada en la atestación de hardware de Apple, no un token de software o secreto compartido.
Implementación sin intervención del usuario y sin agente sin clientes VPN, sin interacción del usuario y sin pasos de activación.
Direcciones IP de origen determinísticas que permiten lista blanca de IP sencilla en cualquier infraestructura de LLM.
Precisión de enrutamiento por dominio que evita los compromisos de rendimiento y privacidad de los VPNs de túnel completo.
Seguridad en capas que combina confianza de dispositivo a nivel de red con autenticación de API a nivel de aplicación.

El efecto neto es que solo dispositivos gestionados y de confianza pueden acceder a la infraestructura de LLM, sin requerir ningún cambio en los flujos de trabajo del usuario final.

Guías