신뢰할 수 있는 Egress IP를 사용한 LLM 액세스 보호

대부분의 호스팅된 LLM 엔드포인트에 대한 액세스는 클라이언트 구성에 코딩된 공유 API 키로 보호됩니다. API 키는 배포하기가 간단하지만 공유, 누출 또는 유출하기가 쉽습니다. LLM 추론 컴퓨팅이 비싸기 때문에 권한이 없는 사용으로 인해 상당하고 예상치 못한 비용이 발생할 수 있습니다.

이는 보안 문제이자 비용 거버넌스 문제입니다.

Jamf의 Network Relay 및 신뢰할 수 있는 egress IP 제한을 결합하면 제로 터치 접근 방식으로 이 격차를 해결합니다.

문제: API 키 단독으로는 충분하지 않습니다.

일반적인 호스팅된 LLM 배포 예제:

조직은 내부 인프라 또는 클라우드 VPC (AWS, Azure, GCP) 내에 모델 (예: Llama 3, Mistral 또는 미세 조정된 변형)을 배포합니다.
API 엔드포인트는 공유 API 키로 인증된 요청을 수락하는 (OpenAI 호환) 노출됩니다.
API 키는 구성 프로필, MDM, 환경 변수 또는 개발자 설명서를 통해 클라이언트에 배포됩니다.

문제는 API 키가 정적이고 수명이 긴 비밀이라는 것입니다. 유출하기 쉽습니다:

개발자가 개인 프로젝트 또는 노트북에 키를 복사합니다.
키가 Git 저장소 (프라이빗이더라도)에 커밋됩니다.
직원이 권한이 없는 동료 또는 계약자와 키를 공유합니다.
키가 구성된 기기가 손실되거나 손상됩니다.

키가 유출되면 해당 키가 있는 모든 사용자는 모든 기기, 모든 네트워크, 어디서나에서 LLM 리소스를 사용할 수 있습니다. LLM 추론은 모델 및 프롬프트 길이에 따라 요청당 몇 센트에서 여러 달러까지의 비용이 들 수 있으므로 권한이 없는 사용으로 인해 상당한 청구서가 생성될 수 있습니다. 또는 더 나쁜 경우 모델이 소유 정보에서 미세 조정되었다면 민감한 내부 데이터를 노출할 수 있습니다.

키 회전과 같은 기존 완화는 운영 복잡성을 제입니다. 그러나 근본적인 문제를 해결하지는 못합니다:

키 단독으로는 요청이 신뢰할 수 있는 관리 기기에서 발생하는지 확인할 수 없습니다.

솔루션: Network Relay + 신뢰할 수 있는 Egress IP 잠금

Jamf의 Network Relay는 Apple의 기본 MASQUE 프로토콜 및 Managed Device Attestation (MDA)에 기반하여 조직이 사용자 상호 작용 없이 검증되고 관리되는 Apple 기기로만 LLM 엔드포인트 액세스를 제한할 수 있게 합니다.

아키텍처:

1. 관리 기기의 트래픽이 Jamf Security Cloud를 통해 라우팅됩니다.

Network Relay가 MDM을 통해 배포되면 LLM 엔드포인트의 도메인을 대상으로 하는 모든 트래픽은 자동으로 암호화된 MASQUE/HTTP3 터널을 사용하여 Jamf의 Security Cloud를 통해 터널됩니다. 기기의 신원은 Managed Device Attestation을 통해 Apple Secure Enclave의 하드웨어 바운드 키를 사용하여 암호로 검증되므로 진정한 회사 관리 기기만 이러한 터널을 설정할 수 있습니다.

2. 트래픽은 알려진 Jamf IP 주소를 통해 Egresses입니다.

트래픽이 Jamf Security Cloud를 통과하고 정책 평가를 통과한 후 인터넷으로 (그리고 따라서 LLM 엔드포인트로) egress되며, 다음 중 하나인 알려진 결정성 Jamf IP 주소 세트에서:

Jamf의 글로벌 데이터 센터 영역 중 하나의 공유 egress IP.
Dedicated egress IP, 조직에 고유하게 할당되고 높은 가용성을 위해 지역당 2개의 공개 IP 제공. 다른 Jamf 고객은 사용하지 않습니다.

3. LLM 엔드포인트는 신뢰할 수 있는 IP만 제한합니다.

이제 트래픽이 알려진 신뢰할 수 있는 IP 주소 세트에서 도착하고 있으므로 해당 Jamf egress IP에서만 연결을 허용하도록 LLM 인프라를 구성합니다. 이는 네트워크 계층에 적용된 표준 IP 허용 목록입니다:

클라우드 호스팅 LLM (AWS/Azure/GCP): 보안 그룹, 네트워크 보안 그룹 또는 방화벽 규칙을 구성하여 Jamf egress IP의 인바운드 HTTPS (TCP/443)만 허용합니다. AWS Bedrock의 예는 아래를 참조하세요 내 제목으로 이동
온프레미스 LLM: Jamf egress IP 범위에서만 연결을 허용하도록 에지 방화벽 또는 리버스 프록시 (예: nginx, HAProxy, Caddy)를 구성합니다.
API Gateway / LLM Proxy (예: LiteLLM, OpenWebUI): 많은 LLM 게이트웨이 솔루션은 심층 방어의 추가 계층으로 애플리케이션 계층에서 IP 허용 목록을 지원합니다.

결과: API 키가 누출되더라도 요청이 Jamf Security Cloud를 통해 라우팅되는 관리 기기에서 발생하지 않는 한 쓸모가 없습니다.

Network Relay를 사용하는 이유

기존 VPN 기반 IP 잠금과의 핵심 차이점은 zero-touch, zero-agent 배포 모델입니다:

앱 설치 필요 없음. Network Relay는 Jamf Pro에서 배포되는 MDM 구성 프로필을 통해 완전히 구성됩니다. 설치할 VPN 클라이언트가 없으며, 기본 릴레이 기능에 Jamf Trust 앱이 필요하지 않으며, 사용자 로그인 또는 활성화 단계가 없습니다.
사용자 상호 작용 없음. 릴레이 프로필이 관리 기기에 설치되면 자동으로 활성화됩니다. 사용자에게 VPN 토글이 보이지 않으며, 네트워크 액세스에 대한 자격증명을 입력하거나 중단될 수 없습니다. 정의된 LLM 도메인으로의 트래픽은 투명하게 터널됩니다.
하드웨어 루트 기기 신뢰. Managed Device Attestation은 Apple Secure Enclave를 사용하여 기기가 진정한 Apple 하드웨어, 조직의 MDM에서 관리하며 변조되지 않았음을 암호로 증명합니다. 이는 소프트웨어 전용 에이전트보다 강력한 신원 신호를 제공합니다.
도메인별 정밀성. 모든 트래픽을 라우팅하는 전체 터널 VPN과 달리 Network Relay는 도메인 기반으로 작동합니다. 정확히 어떤 도메인 (예: llm.internal.yourcompany.com)을 Jamf를 통해 터널링해야 하는지 정의합니다. 다른 모든 트래픽은 영향을 받지 않습니다. 이는 성능 영향을 최소화하고 기존 VPN 아키텍처의 "all or nothing" 트레이드오프를 방지합니다.
Apple 플랫폼에서 작동합니다. Network Relay는 macOS, iOS, iPadOS 및 visionOS에서 지원되며 단일 구성에서 관리할 수 있습니다.

*참고: 비 Apple 플랫폼에서 Jamf의 ZTNA 솔루션으로 IP 잠금을 사용하는 것도 가능합니다.

배포 개요

다음 단계는 엔드-투-엔드 구성을 간략히 설명합니다:

단계 1: Jamf Security Cloud에서 Egress 구성

Jamf Security Cloud (RADAR) 콘솔에서 Integrations > Access Gateways로 이동하여 기본 지역의 공유 egress IP를 기록하거나 Dedicated Internet Gateway를 생성하여 조직에만 할당된 두 개의 고유 공개 IP를 수신합니다.

dedicated 게이트웨이의 경우 여러 지역 게이트웨이를 생성하고 기기가 Jamf Security Cloud로의 연결을 기반으로 가장 가까운 egress 지점을 자동으로 사용하도록 그룹화할 수 있습니다.

단계 2: LLM 엔드포인트에 대한 액세스 정책 생성

Policies > Access Policies로 이동하여 새 정책을 생성합니다:

LLM 엔드포인트의 도메인을 정의합니다 (예: llm.yourcompany.com, api.ai.internal.yourcompany.com).
라우팅을 선택한 egress 게이트웨이 (공유 또는 dedicated)를 사용하도록 설정합니다.
정책이 적절한 기기 그룹에 적용되도록 구성합니다.

단계 3: Network Relay 프로필 배포

Devices > Activation Profiles로 이동하여 Network Relay 활성화 프로필을 생성하거나 업데이트합니다:

Service Capabilities에서 Zero Trust Network Access가 선택되어 있는지 확인합니다.
Authentication에서 Managed Device Attestation을 선택하여 zero-touch, 암호 없는 활성화를 수행합니다.
Jamf Pro를 통해 결과 구성 프로필을 관리 기기에 배포합니다.

배포되면 기기는 자동으로 Jamf Security Cloud를 통해 LLM 도메인으로의 트래픽 라우팅을 시작합니다.

단계 4: LLM 엔드포인트를 Jamf Egress IP로 잠금

LLM 인프라 측에서 Jamf egress IP 주소로만 인바운드 액세스를 제한합니다. 예제:

AWS Security Group:

Inbound Rule:
  Type: HTTPS (TCP 443)
  Source: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  Description: Jamf Trusted Devices Only

nginx reverse proxy:

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

    # Only allow Jamf egress IPs
    allow <Jamf Egress IP 1>;
    allow <Jamf Egress IP 2>;
    deny all;

    location / {
        proxy_pass http://localhost:8080;  # Your LLM inference server
    }
}

Azure Network Security Group:

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

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

단계 5: 검증 및 모니터링

릴레이 프로필이 배포된 관리 기기에서 LLM 엔드포인트에 대한 요청이 성공하는지 확인합니다.
관리 기기에서 (또는 릴레이 프로필을 제거하여) 요청이 차단되는지 확인합니다.
LLM 인프라의 액세스 로그를 모니터링하여 모든 인바운드 연결이 예상된 Jamf egress IP에서 발생하는지 확인합니다.
Jamf Security Cloud Reports > Access 섹션의 연결 로그를 검토하여 어떤 사용자와 기기가 LLM 엔드포인트에 액세스하는지 파악합니다.

Managed LLM Services로 확장: AWS Bedrock

동일한 신뢰할 수 있는 egress IP 접근 방식은 자체 호스팅되는 모델을 넘어 적용됩니다. 조직이 관리되는 LLM 추론을 위해 Amazon Bedrock을 사용하는 경우 aws:SourceIp 조건이 있는 AWS IAM 정책을 사용하여 IP 기반 제한을 시행할 수 있습니다. Jamf egress IP에서만 발생하는 요청이 Bedrock 모델을 호출할 수 있도록 합니다.

자체 호스팅 배포와 달리 네트워크 계층 (보안 그룹, 방화벽)을 제어합니다. Bedrock은 완전 관리 AWS 서비스입니다. Bedrock 자체에서 인바운드 방화벽 규칙을 구성하지 않습니다. 대신 신뢰할 수 있는 IP에서 요청이 오지 않는 한 모델 호출을 거부하는 IAM 정책을 연결합니다.

IAM Deny Policy: 소스 IP에 의한 Bedrock Invocation 제한

Bedrock 액세스 권한이 있는 IAM 사용자, 역할 또는 그룹에 다음 정책을 연결합니다. 명시적 거부는 모든 허용 명령문을 재정의하여 Bedrock 호출이 신뢰할 수 있는 IP에서 발생하지 않는 한 차단되는지 확인합니다:

{
    "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"
                    ]
                }
            }
        }
    ]
}

이 정책은 다른 모든 Bedrock 권한 (예: 모델 나열, 프로비저닝된 처리량 관리)이 정상적으로 작동하도록 허용합니다. 추론 호출 작업만 신뢰할 수 있는 IP로 제한합니다. 기존 IAM 정책에 명시적 DENY 규칙이 이미 포함된 경우 암시적 허용에 의존하는 대신 신뢰할 수 있는 IP에 대한 명시적 ALLOW 명령문을 추가해야 할 수 있습니다.

조직 전체 시행을 위한 서비스 제어 정책 (SCP)

개별 IAM 주체뿐 아니라 조직의 모든 AWS 계정에 걸쳐 IP 제한을 시행하려면 AWS Organizations에서 SCP로 적용합니다:

{
    "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"
                }
            }
        }
    ]
}

aws:ViaAWSService 조건은 거부가 자신의 대신 다른 AWS 서비스에서 발생한 Bedrock 호출을 실수로 차단하지 않도록 포함됩니다 (예: VPC 내 Lambda 함수가 Bedrock을 호출하거나 Step Functions 워크플로우가 Bedrock을 호출하거나 SageMaker 노트북이 추론을 위해 Bedrock을 사용). 직접 API 호출에만 IP 제한을 적용합니다. 이는 정확히 최종 사용자 기기가 Jamf 릴레이를 통해 취하는 경로입니다.

Bedrock에 대한 주요 고려사항

aws:SourceIp은 공개 인터넷을 통한 직접 API 호출에 적용됩니다. 이는 관리 기기 → Jamf Security Cloud → Jamf egress IP → AWS Bedrock API 엔드포인트에서 트래픽이 흐를 때 예상되는 경로입니다.
VPC 엔드포인트 액세스: Bedrock을 VPC 엔드포인트를 통해서도 액세스하는 경우 aws:SourceIp은 평가되지 않습니다. 해당 경로에서 액세스를 제어하려면 aws:VpcSourceIp 또는 VPC 엔드포인트 정책을 사용합니다.
Bedrock 교차 지역 추론: 교차 지역 추론 프로필을 사용하는 경우 정책 Resource가 관련 지역을 포함하거나 위에 표시된 대로 와일드카드를 사용하는지 확인합니다.
테스트: IAM Policy Simulator를 사용하거나 관리 기기 (성공해야 함)와 관리 기기 (AccessDenied를 받아야 함)에서 테스트 InvokeModel 호출을 수행하여 광범위하게 배포하기 전에 정책을 확인합니다.

심층 방어: IP 잠금을 API 키로 계층화

IP 기반 액세스 제한이 API 키 인증을 보완한다는 점에 유의하는 것이 중요합니다. 이를 대체하지는 않습니다. 권장되는 태세는 두 제어를 계층화하는 것입니다:

계층	제어	증명하는 것
네트워크	Jamf egress IP 허용 목록	요청은 관리되고 증명된 기기에서 발생합니다.
애플리케이션	API 키 / 토큰	요청은 특정 LLM 서비스에 대해 권한이 있습니다.
(선택 사항) 신원	IdP 통합 / OAuth	요청은 특정 인증된 사용자에 연결됩니다.

이 계층화된 접근 방식을 통해 공격자는 동시에 유효한 API 키 및 Jamf 관리되는 하드웨어 증명 기기에서 작동해야 합니다. 이는 어느 제어보다 훨씬 높은 막대입니다.

요약

자체 호스팅 LLM은 조직이 데이터, 비용 및 AI 공급 체인을 제어해야 하는 경우 상당한 인프라 약속을 나타냅니다. 공유 API 키에만 의존하고 인터넷의 모든 기기에서 사용할 수 있다면 해당 약속이 훼손됩니다.

신뢰할 수 있는 egress IP 제한과 함께 Network Relay를 배포하면 다음을 제공합니다:

암호 기반 기기 신뢰, 소프트웨어 토큰 또는 공유 비밀이 아닌 Apple 하드웨어 증명에 루트.
Zero-touch, zero-agent 배포, VPN 클라이언트, 사용자 상호 작용 또는 활성화 단계 없음.
결정성 소스 IP 주소, 모든 LLM 인프라에서 직선적인 IP 허용 목록을 활성화합니다.
도메인별 라우팅 정밀성, 전체 터널 VPN의 성능 및 개인정보 보호 트레이드오프를 회피합니다.
계층화된 보안, 네트워크 수준의 기기 신뢰를 애플리케이션 수준의 API 인증과 결합.

순효과는 신뢰할 수 있는 관리 기기만 최종 사용자 워크플로우에 대한 변경 없이 LLM 인프라에 도달할 수 있다는 것입니다.

Guides