Zabezpieczanie dostępu LLM za pomocą zaufanych adresów IP wyjściowych

Dostęp do większości hostowanych punktów końcowych LLM jest chroniony przez wspólny klucz API kodowany w konfiguracjach klienta. Klucze API są proste do wdrażania, ale łatwe do udostępniania, wyciekania lub eksfiltowania --- a biorąc pod uwagę, że obliczenia wnioskowania LLM są kosztowne, nieautoryzowane użycie może generować znaczące i nieoczekiwane koszty.

To jest zarówno problem bezpieczeństwa, jak i problem zarządzania kosztami.

Network Relay Jamf połączony z ograniczeniami zaufanych adresów IP wyjściowych rozwiązuje tę lukę za pomocą podejścia bez dotyku.

Problem: Tylko klucze API nie są wystarczające

Typowy przykład wdrożenia hostowanego LLM:

Organizacja wdraża model (np. Llama 3, Mistral lub wariant dostrojony) w infrastrukturze wewnętrznej lub w VPC w chmurze (AWS, Azure, GCP).
Punkt końcowy API jest ujawniany --- często kompatybilny z OpenAI --- który akceptuje żądania uwierzytelnione za pomocą wspólnego klucza API.
Klucz API jest dystrybuowany do klientów za pośrednictwem profilów konfiguracji, MDM, zmiennych środowiskowych lub dokumentacji dla deweloperów.

Problem polega na tym, że klucze API to statyczne, długoterminowe sekrety, które są łatwe do wycieku:

Deweloper kopiuje klucz do osobistego projektu lub notatnika.
Klucz jest zatwierdzony do repozytorium Git (nawet prywatnego).
Pracownik udostępnia klucz nieautoryzowanemu kolegze lub wykonawcy.
Urządzenie z skonfigurowanym kluczem zostaje zgubione lub skompromitowane.

Po udostępnieniu klucza, każdy, kto go ma, może zużywać zasoby LLM z dowolnego urządzenia, dowolnej sieci, gdziekolwiek. Biorąc pod uwagę, że wnioskowanie LLM może kosztować od ułamków centa do kilku dolarów za żądanie w zależności od modelu i długości wiersza, nieautoryzowane użycie może generować znaczne rachunki --- lub, co gorsza, ujawnić wrażliwe wewnętrzne dane, jeśli model został dostrojony na informacje zastrzeżone.

Tradycyjne środki zaradcze, takie jak rotacja kluczy, pomagają, ale wprowadzają złożoność operacyjną i nie rozwiązują fundamentalnego problemu:

Sam klucz nie może potwierdzić, że żądanie pochodzi z zaufanego, zarządzanego urządzenia.

Rozwiązanie: Network Relay + zabezpieczenie adresu IP wyjściowego zaufanego

Network Relay Jamf, zbudowany na natywnym MASQUE protocol Apple i Managed Device Attestation (MDA), umożliwia organizacjom ograniczenie dostępu do punktów końcowych LLM do zweryfikowanych, zarządzanych urządzeń Apple --- z zerową wymaganą interakcją użytkownika końcowego.

Architektura:

1. Ruch z zarządzanych urządzeń przechodzi przez chmurę bezpieczeństwa Jamf

Gdy Network Relay jest wdrażany za pośrednictwem MDM, cały ruch przeznaczony dla domeny punktu końcowego LLM jest automatycznie tunelowany przez chmurę bezpieczeństwa Jamf przy użyciu zaszyfrowanych tuneli MASQUE/HTTP3. Tożsamość urządzenia jest kryptograficznie weryfikowana za pomocą kluczy związanych ze sprzętem z Apple Secure Enclave za pośrednictwem Managed Device Attestation, dzięki czemu tylko autentyczne, zarządzane przez firmę urządzenia mogą nawiązywać te tunele.

2. Ruch wychodzi przez znane adresy IP Jamf

Po przeprowadzeniu ruchu przez chmurę bezpieczeństwa Jamf i ocenę polityki wychodzi (wychodzenie) do Internetu --- a zatem do punktu końcowego LLM --- z znanego, deterministycznego zestawu adresów IP Jamf. Mogą to być:

Wspólne adresy IP wyjściowe z jednego z globalnych regionów centrum danych Jamf.
Dedykowane adresy IP wyjściowe, które są wyjątkowo przydzielone Twojej organizacji --- zapewniając dwa wysoko dostępne publiczne adresy IP na region, które nie są używane przez żadnych innych klientów Jamf.

3. Punkt końcowy LLM ogranicza dostęp tylko do zaufanych adresów IP

Z ruchem dochodów teraz z znanego i zaufanego zestawu adresów IP, konfigurujesz infrastrukturę LLM, aby akceptować połączenia tylko z adresów IP wyjściowych Jamf --- odrzucając wszystkie inne. To jest standardowe IP allowlisting zastosowane na warstwie sieciowej:

Hostowane LLM w chmurze (AWS/Azure/GCP): Skonfiguruj grupy bezpieczeństwa, sieciowe grupy bezpieczeństwa lub reguły zapory, aby zezwolić tylko na przychodzące HTTPS (TCP/443) z Twoich adresów IP wyjściowych Jamf. Poniżej znajduje się przykład na AWS Bedrock Link to My Heading
LLM lokalnie: Skonfiguruj zaporę sieciową krawędzi lub odwrotny serwer proxy (np. nginx, HAProxy, Caddy), aby akceptować połączenia tylko z zakresów adresów IP wyjściowych Jamf.
Brama API / Serwer proxy LLM (np. LiteLLM, OpenWebUI): Wiele rozwiązań bramy LLM obsługuje IP allowlisting na warstwie aplikacji jako dodatkową miarę obrony wgłąb.

Rezultat: nawet jeśli klucz API jest wyciekł, jest bezużyteczny, chyba że żądanie pochodzi z zarządzanego urządzenia routingu przez dzierżawę chmury bezpieczeństwa Jamf.

Dlaczego Network Relay

Kluczową różnicą od tradycyjnego VPN-based IP lockdown jest model wdrażania bez dotyku, bez agenta:

Nie ma potrzeby instalacji aplikacji. Network Relay jest konfigurowany całkowicie za pośrednictwem profilów konfiguracji MDM wdrażanych z Jamf Pro. Nie ma klienta VPN do zainstalowania, nie jest wymagana aplikacja Jamf Trust dla funkcjonalności relay podstawowej i nie ma kroku logowania lub aktywacji użytkownika.
Brak interakcji użytkownika. Po zainstalowaniu profilu relay na zarządzanym urządzeniu, aktywuje się automatycznie. Użytkownik nie widzi przełącznika VPN, nie wprowadza poświadczeń do dostępu do sieci ani nie zostaje przerwany. Ruch do zdefiniowanych domen LLM jest tunelowany przezroczysty.
Zaufanie do urządzenia zakotwiczone w sprzęcie. Managed Device Attestation korzysta z Apple Secure Enclave do kryptograficznie udowodnienia, że urządzenie jest autentycznym sprzętem Apple, zarządzanym przez MDM Twojej organizacji i nie zostało manipulowane. Zapewnia to silniejszy sygnał tożsamości niż agenci tylko oprogramowania.
Precyzja dla domeny. W przeciwieństwie do pełnego tunelu VPN, który kieruje cały ruch, Network Relay działa na podstawie domeny. Definiujesz dokładnie, które domeny (np. llm.internal.yourcompany.com) powinny być tunelowane przez Jamf --- pozostawiając cały inny ruch niezmieniony. To minimalizuje wpływ na wydajność i unika kompromisu "wszystko lub nic" starszych architektur VPN.
Działa na platformach Apple. Network Relay jest obsługiwany na macOS, iOS, iPadOS i visionOS i może być zarządzany z jednej konfiguracji.

*N.b. Jest również możliwe użycie blokady IP z rozwiązaniem ZTNA Jamf na platformach innych niż Apple.

Przegląd wdrażania

Poniższe kroki opisują konfigurację end-to-end:

Krok 1: Skonfiguruj ruch wyjściowy w chmurze bezpieczeństwa Jamf

W konsoli chmury bezpieczeństwa Jamf (RADAR) przejdź do Integrations > Access Gateways i albo zanotuj Shared egress IPs dla preferowanego regionu, albo utwórz Dedicated Internet Gateway aby otrzymać dwa unikalne publiczne adresy IP przydzielone wyłącznie Twojej organizacji.

W przypadku dedykowanych bram możesz tworzyć wiele regionalnych bram i grupować je, dzięki czemu urządzenia automatycznie korzystają z najbliższego punktu wyjściowego na podstawie ich połączenia z chmurą bezpieczeństwa Jamf.

Krok 2: Utwórz politykę dostępu dla punktu końcowego LLM

Przejdź do Policies > Access Policies i utwórz nową politykę:

Zdefiniuj domeny punktu końcowego LLM (np. llm.yourcompany.com, api.ai.internal.yourcompany.com).
Ustaw routing, aby korzystać z wybranej bramy wyjściowej (udostępnionej lub dedykowanej).
Skonfiguruj politykę, aby zastosować ją do odpowiednich grup urządzeń.

Krok 3: Wdróż profil Network Relay

Przejdź do Devices > Activation Profiles i utwórz lub zaktualizuj profil aktywacji Network Relay:

W Service Capabilities upewnij się, że wybrany jest Zero Trust Network Access.
W Authentication wybierz Managed Device Attestation dla aktywacji bez dotyku, bez hasła.
Wdróż otrzymane profile konfiguracji do zarządzanych urządzeń za pośrednictwem Jamf Pro.

Po wdrożeniu urządzenia automatycznie začną kierować ruch do domen LLM przez chmurę bezpieczeństwa Jamf.

Krok 4: Zablokuj punkt końcowy LLM do adresów IP wyjściowych Jamf

Po stronie infrastruktury LLM ograniczyć dostęp przychodzący tylko do adresów IP wyjściowych Jamf. Przykłady:

Grupa bezpieczeństwa AWS:

Reguła przychodzenia:
  Typ: HTTPS (TCP 443)
  Źródło: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  Opis: Tylko zaufane urządzenia Jamf

Reverse proxy nginx:

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

    # Zezwalaj tylko na adresy IP wyjściowe Jamf
    allow <Jamf Egress IP 1>;
    allow <Jamf Egress IP 2>;
    deny all;

    location / {
        proxy_pass http://localhost:8080;  # Twój serwer wnioskowania LLM
    }
}

Sieciowa grupa bezpieczeństwa Azure:

Reguła zabezpieczeń przychodzących:
  Priorytet: 100
  Źródło: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  Port docelowy: 443
  Protokół: TCP
  Działanie: Zezwalaj

Reguła zabezpieczeń przychodzących:
  Priorytet: 200
  Źródło: Każdy
  Port docelowy: 443
  Protokół: TCP
  Działanie: Odmów

Krok 5: Walidacja i monitorowanie

Z zarządzanego urządzenia z wdrożonym profilem relay potwierdź, że żądania do punktu końcowego LLM się powiodą.
Z niezarządzanego urządzenia (lub z usuniętym profilem relay) potwierdź, że żądania są blokowane.
Monitoruj dzienniki dostępu w infrastrukturze LLM, aby zweryfikować, że wszystkie połączenia przychodzące pochodzą z oczekiwanych adresów IP wyjściowych Jamf.
Przejrzyj dzienniki połączeń w sekcji Reports > Access chmury bezpieczeństwa Jamf, aby uzyskać wgląd w to, które użytkownicy i urządzenia uzyskują dostęp do punktu końcowego LLM.

Rozszerzenie na zarządzane usługi LLM: AWS Bedrock

Takie samo podejście zaufanego adresu IP wyjściowego ma zastosowanie poza wdrażaniem samodzielnie hostowanych modeli. Jeśli Twoja organizacja korzysta z Amazon Bedrock do zarządzanego wnioskowania LLM, możesz wymusić ograniczenia oparte na adresach IP przy użyciu polityk IAM AWS z warunkami aws:SourceIp --- zapewniając, że tylko żądania pochodzące z adresów IP wyjściowych Jamf mogą wywoływać modele Bedrock.

W przeciwieństwie do wdrażania samodzielnie hostowanych, gdzie kontrolujesz warstwę sieciową (grupy bezpieczeństwa, zapory), Bedrock jest w pełni zarządzaną usługą AWS. Nie konfigurujesz reguł zapory przychodzące w samym Bedrock. Zamiast tego dołączasz polityki IAM, które zamawiają wywoływanie modelu, chyba że żądanie pochodzi z zaufanego IP.

Polityka odmowy IAM: ograniczenie wzywanego Bedrock przez źródłowy IP

Dołącz następującą politykę do użytkowników IAM, ról lub grup, które mają dostęp Bedrock. Wyraźna odmowa zastępuje wszelkie instrukcje zezwalające, zapewniając, że wywołania Bedrock są blokowane, chyba że pochodzą z adresów IP wyjściowych Jamf:

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

Polityka ta pozwala na wszystkie inne uprawnienia Bedrock (np. wymień modele, zarządzaj aprowizacją przepustowości), aby działały normalnie --- ogranicza tylko akcje wywoływania wnioskowania do zaufanych adresów IP. Jeśli istniejące polityki IAM już zawierają jawne reguły DENY, może być konieczne dodanie jawnej instrukcji ALLOW dla zaufanych adresów IP zamiast polegania na niejawnym zezwoleniu.

Polityka kontroli serwisu (SCP) do egzekwowania w skali całej organizacji

Jeśli chcesz wymusić ograniczenie IP na wszystkich kontach AWS w organizacji --- nie tylko poszczególnych podmiots IAM --- zastosuj go jako SCP w organizacjach AWS:

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

Warunek aws:ViaAWSService jest zawarty, dzięki czemu odmowa nie blokuje przypadkowo wywołań Bedrock dokonanych przez inne usługi AWS w Twoim imieniu (np. funkcja Lambda wywoływająca Bedrock w ramach VPC, przepływy pracy Step Functions wywoływające Bedrock lub noteboooki SageMaker korzystające z Bedrock do wnioskowania). Zapewnia, że ograniczenie IP dotyczy tylko bezpośrednich połączeń API --- które jest dokładnie ścieżką, którą urządzenia użytkowników końcowych przechodzą przez relay Jamf.

Kluczowe rozważania dla Bedrock

aws:SourceIp dotyczy bezpośrednich połączeń API przez publiczny Internet. To jest oczekiwana ścieżka, gdy ruch przepływa z zarządzanego urządzenia → chmury bezpieczeństwa Jamf → IP wyjściowy Jamf → punkt końcowy API AWS Bedrock.
Dostęp do punktu końcowego VPC: Jeśli masz również dostęp do Bedrock za pośrednictwem punktu końcowego VPC, aws:SourceIp nie jest oceniany. Użyj aws:VpcSourceIp lub polityk punktu końcowego VPC, aby oddzielnie kontrolować dostęp do tej ścieżki.
Bedrock wnioskowanie między regionami: Jeśli używasz profili wnioskowania między regionami, upewnij się, że Resource Twojej polityki obejmuje odpowiednie regiony lub użyj symbolu wieloznacznego, jak pokazano powyżej.
Testowanie: Użyj symulatora polityki IAM lub wykonaj test InvokeModel połączeń zarówno z zarządzanego urządzenia (powinno się powieść), jak i z niezarządzanego urządzenia (powinno otrzymać AccessDenied), aby zweryfikować politykę przed szerokim wdrożeniem.

Obrona wgłąb: warstw ograniczenia IP z klawiszami API

Ważne jest, aby pamiętać, że ograniczenie dostępu oparte na adresach IP uzupełnia uwierzytelnianie klucza API --- go nie zastępuje. Zalecana postawa jest warstwami obie kontrole:

Warstwa	Kontrola	Co to udowadnia
Sieć	Allowlist adresu IP wyjściowego Jamf	Żądanie pochodzi z zarządzanego, zatwierdzonego urządzenia
Aplikacja	Klucz API / token	Żądanie jest autoryzowane dla określonej usługi LLM
(Opcjonalnie) Tożsamość	Integracja IdP / OAuth	Żądanie jest powiązane z określonym uwierzytelnionym użytkownikiem

Z takim warstwowym podejściem atakujący musiałby jednocześnie posiadać ważny klucz API i operować z zarządzanego przez Jamf, urządzenia poświadczonego sprzętu --- znacznie wyższy bar niż sama każda kontrola.

Podsumowanie

Samodzielnie hostowane LLM reprezentują znaczące zaangażowanie infrastruktury dla organizacji, które muszą kontrolować swoje dane, koszty i łańcuch dostaw AI. To zaangażowanie jest podważane, jeśli dostęp polega wyłącznie na wspólnych kluczach API, które mogą być wyciekły i używane z dowolnego urządzenia w Internecie.

Wdrażanie Network Relay z ograniczeniami zaufanych adresów IP wyjściowych zapewnia:

Zaufanie do urządzenia kryptograficznego zakotwiczone w zaświadczeniu sprzętu Apple, a nie tokenie oprogramowania lub wspólnym tajemnicę.
Wdrażanie bez dotyku, bez agenta bez klientów VPN, bez interakcji użytkownika i bez kroków aktywacji.
Deterministic source IP addresses które umożliwiają proste IP allowlisting w dowolnej infrastrukturze LLM.
Per-domain routing precision które unika handlowania wydajnością i prywatnością pełnych tuneli VPN.
Warstwowe bezpieczeństwo, które łączy zaufanie do urządzenia na poziomie sieciowym z uwierzytelnianiem API na poziomie aplikacji.

Efektem netto jest to, że tylko zaufane, zarządzane urządzenia mogą osiągnąć infrastrukturę LLM, bez konieczności zmiany przepływów pracy użytkowników końcowych.

Guides