使用受信任的出口 IP 保護 LLM 存取

大多數託管 LLM 端點的存取都受到編碼在用戶端配置中的共享 API 金鑰保護。API 金鑰易於部署但容易共享、洩露或外洩 — 由於 LLM 推理計算成本高昂，未經授權的使用可能產生重大且意外的成本。

這既是安全問題，也是成本治理問題。

Jamf 的 Network Relay 結合受信任的出口 IP 限制以零接觸方法解決此問題。

問題：API 金鑰單獨不夠安全

典型的託管 LLM 部署示例：

組織在內部基礎設施或雲 VPC（AWS、Azure、GCP）內部署模型（例如 Llama 3、Mistral 或微調變體）。
公開 API 端點 — 通常兼容 OpenAI — 接受使用共享 API 金鑰進行身份驗證的請求。
API 金鑰透過配置描述檔、MDM、環境變數或開發人員文檔分發給用戶端。

問題是 API 金鑰是靜態、長期有效的秘密，容易洩露：

開發人員將金鑰複製到個人專案或筆記本。
金鑰被提交到 Git 儲存庫（即使是私人儲存庫）。
員工與未授權的同事或承包商共享金鑰。
配置了金鑰的裝置遺失或遭到破壞。

一旦金鑰被洩露，任何擁有它的人都可以從任何裝置、任何網路、任何地方消耗您的 LLM 資源。考慮到 LLM 推理每個請求的成本從不到一分錢到幾美元不等（取決於模型和提示長度），未經授權的使用可能產生可觀的帳單 — 或更糟的是，如果模型已在專有資訊上進行微調，可能洩露敏感的內部資料。

傳統的緩解措施（如金鑰輪換）有所幫助，但引入了操作複雜性且無法解決根本問題：

金鑰單獨無法驗證請求是否來自受信任、受管理的裝置。

解決方案：Network Relay + 受信任的出口 IP 鎖定

Jamf 的 Network Relay 以 Apple 原生 MASQUE 協議和受管理裝置證明 (MDA) 為基礎，使組織能夠限制 LLM 端點存取至已驗證、受管理的 Apple 裝置 — 無需任何終端使用者互動。

架構：

1. 來自受管理裝置的流量透過 Jamf Security Cloud 路由

部署 Network Relay via MDM 時，所有發往您 LLM 端點網域的流量會自動透過使用加密 MASQUE/HTTP3 隧道的 Jamf Security Cloud 進行隧道化。裝置的身份透過受管理裝置證明使用來自 Apple Secure Enclave 的硬體綁定金鑰進行密碼學驗證，因此只有真正的公司管理裝置才能建立這些隧道。

2. 流量透過已知的 Jamf IP 位址出站

流量通過 Jamf Security Cloud 和政策評估後，會出站（出口）到網際網路 — 因此出站到您的 LLM 端點 — 來自已知、確定性的 Jamf IP 位址集合。這些可以是：

共享出口 IP 來自 Jamf 的全球資料中心區域之一。
專用出口 IP 唯一分配給您的組織 — 每個區域提供兩個高可用公用 IP，沒有其他 Jamf 客戶使用。

3. 您的 LLM 端點限制存取至受信任 IP 只

既然您的流量現在來自已知且受信任的 IP 位址集合，您可以配置您的 LLM 基礎設施來僅接受來自那些 Jamf 出口 IP 的連線 — 拒絕所有其他。這是在網路層應用的標準 IP 白名單：

雲託管 LLM（AWS/Azure/GCP）： 配置安全群組、網路安全群組或防火牆規則以僅允許來自 Jamf 出口 IP 的入站 HTTPS（TCP/443）。請參閱下方 AWS Bedrock 的示例連結至我的標題
內部部署 LLM： 配置您的邊界防火牆或反向代理（例如 nginx、HAProxy、Caddy）以僅接受來自 Jamf 出口 IP 範圍的連線。
API Gateway / LLM Proxy（例如 LiteLLM、OpenWebUI）： 許多 LLM 閘道解決方案支援在應用層的 IP 白名單作為額外的深度防禦措施。

結果是：即使 API 金鑰被洩露，除非請求來自透過您的 Jamf Security Cloud 租戶路由的受管理裝置，否則它也是無用的。

為何使用 Network Relay

與傳統 VPN 型 IP 鎖定的主要差異是零接觸、零代理部署模型：

無需應用程式安裝。 Network Relay 完全透過從 Jamf Pro 部署的 MDM 配置描述檔進行配置。無需安裝 VPN 用戶端、基本中繼功能不需要 Jamf Trust 應用程式，也沒有使用者登入或啟用步驟。
無使用者互動。 中繼描述檔安裝在受管理裝置上後，會自動啟用。使用者看不到 VPN 切換、輸入網路存取認證，或被中斷。發往定義 LLM 網域的流量會透明地隧道化。
硬體根深蒂固的裝置信任。 受管理裝置證明使用 Apple Secure Enclave 來密碼學證明裝置是真正的 Apple 硬體、由您的組織 MDM 管理，且未被篡改。這提供比僅軟體代理更強的身份信號。
每個網域的精密度。 與路由所有流量的完整隧道 VPN 不同，Network Relay 在每個網域的基礎上運作。您定義完全應該透過 Jamf 隧道化的網域（例如 llm.internal.yourcompany.com） — 所有其他流量保持不受影響。這最大限度地減少了性能影響並避免了傳統 VPN 架構的「全有或全無」折衷。
適用於所有 Apple 平台。 Network Relay 在 macOS、iOS、iPadOS 和 visionOS 上獲得支援，並可從單一配置進行管理。

*注。也可以在非 Apple 平台上將 IP 鎖定與 Jamf 的 ZTNA 解決方案搭配使用。

部署概述

以下步驟概述端對端配置：

步驟 1：在 Jamf Security Cloud 中配置出口

在 Jamf Security Cloud (RADAR) 控制台中，導覽至整合 > 存取閘道並記下您偏好區域的共享出口 IP，或建立專用網際網路閘道以接收唯一分配給您的組織的兩個公用 IP。

對於專用閘道，您可以建立多個區域閘道並將它們分組，以便裝置根據它們對 Jamf Security Cloud 的連線自動使用最近的出口點。

步驟 2：為您的 LLM 端點建立存取政策

導覽至政策 > 存取政策並建立新政策：

定義您的 LLM 端點的網域（例如 llm.yourcompany.com、api.ai.internal.yourcompany.com）。
設定路由以使用您選擇的出口閘道（共享或專用）。
配置政策以套用至適當的裝置群組。

步驟 3：部署 Network Relay 描述檔

導覽至裝置 > 啟用描述檔並建立或更新您的 Network Relay 啟用描述檔：

在服務功能下，確保選擇了零信任網路存取。
在身份驗證下，為零接觸、無密碼啟用選擇受管理裝置證明。
透過 Jamf Pro 將產生的配置描述檔部署至您的受管理裝置。

部署後，裝置將自動開始透過 Jamf Security Cloud 路由發往 LLM 網域的流量。

步驟 4：將 LLM 端點鎖定至 Jamf 出口 IP

在 LLM 基礎設施端，限制入站存取為僅您的 Jamf 出口 IP 位址。範例：

AWS 安全群組：

入站規則：
  類型：HTTPS (TCP 443)
  來源：<Jamf 出口 IP 1>/32、<Jamf 出口 IP 2>/32
  描述：僅限 Jamf 受信任裝置

nginx 反向代理：

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

    # 僅允許 Jamf 出口 IP
    allow <Jamf 出口 IP 1>;
    allow <Jamf 出口 IP 2>;
    deny all;

    location / {
        proxy_pass http://localhost:8080;  # 您的 LLM 推理伺服器
    }
}

Azure 網路安全群組：

入站安全規則：
  優先級：100
  來源：<Jamf 出口 IP 1>/32、<Jamf 出口 IP 2>/32
  目的地連接埠：443
  協議：TCP
  動作：允許

入站安全規則：
  優先級：200
  來源：任何
  目的地連接埠：443
  協議：TCP
  動作：拒絕

步驟 5：驗證和監控

從部署了中繼描述檔的受管理裝置，確認發往 LLM 端點的請求成功。
從未受管理的裝置（或移除中繼描述檔後），確認請求被封鎖。
監控 LLM 基礎設施上的存取日誌，以驗證所有入站連線都來自您預期的 Jamf 出口 IP。
在 Jamf Security Cloud 報告 > 存取部分檢閱連線日誌，以查看哪些使用者和裝置正在存取 LLM 端點。

擴展至受管理 LLM 服務：AWS Bedrock

相同的受信任出口 IP 方法適用於自託管模型之外。如果您的組織使用 Amazon Bedrock 進行受管理 LLM 推理，您可以使用帶有 aws:SourceIp 條件的 AWS IAM 政策來強制執行基於 IP 的限制 — 確保只有來自 Jamf 出口 IP 的請求才能調用 Bedrock 模型。

與您控制網路層（安全群組、防火牆）的自託管部署不同，Bedrock 是完全受管的 AWS 服務。您不會在 Bedrock 本身上配置入站防火牆規則。相反，您附加 IAM 政策來拒絕模型調用，除非請求來自受信任 IP。

IAM 拒絕政策：按來源 IP 限制 Bedrock 調用

將以下政策附加至具有 Bedrock 存取權限的 IAM 使用者、角色或群組。明確拒絕會覆蓋任何允許陳述，確保 Bedrock 呼叫被封鎖，除非它們來自 Jamf 出口 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 出口 IP 1>/32",
                        "<Jamf 出口 IP 2>/32"
                    ]
                }
            }
        }
    ]
}

此政策允許所有其他 Bedrock 權限（例如列出模型、管理已佈建輸送量）正常運作 — 它只限制推理調用動作至受信任 IP。如果您現有的 IAM 政策已包含明確 DENY 規則，您可能需要為受信任 IP 新增明確 ALLOW 陳述，而不是依賴隱含允許。

服務控制政策 (SCP) 用於整個組織強制執行

如果您想在所有 AWS 帳戶上強制執行 IP 限制（而不只是個別 IAM 主體），請在 AWS Organizations 中將其作為 SCP 應用：

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

包含 aws:ViaAWSService 條件是為了拒絕不會意外封鎖由您代表的其他 AWS 服務進行的 Bedrock 呼叫（例如，Lambda 函數在您的 VPC 內調用 Bedrock、Step Functions 工作流程呼叫 Bedrock 或 SageMaker 筆記本使用 Bedrock 進行推理）。它確保 IP 限制只適用於直接 API 呼叫 — 這正是終端使用者裝置透過 Jamf 中繼所採用的路徑。

Bedrock 的關鍵考慮事項

aws:SourceIp 適用於透過公開網際網路的直接 API 呼叫。 這是流量從受管理裝置 → Jamf Security Cloud → Jamf 出口 IP → AWS Bedrock API 端點時的預期路徑。
VPC 端點存取： 如果您也透過 VPC 端點存取 Bedrock，則不會評估 aws:SourceIp。使用 aws:VpcSourceIp 或 VPC 端點政策來分別控制該路徑的存取。
Bedrock 跨區域推理： 如果您使用跨區域推理設定檔，請確保您的政策 Resource 涵蓋相關區域或使用上面顯示的萬用字元。
測試： 使用 IAM Policy Simulator 或從受管理裝置（應該成功）和未受管理裝置（應該收到 AccessDenied）進行測試 InvokeModel 呼叫，以在廣泛部署前驗證政策。

深度防禦：將 IP 鎖定與 API 金鑰分層

重要的是要注意，基於 IP 的存取限制補充了 API 金鑰身份驗證 — 它不取代它。推薦的態勢是對兩個控制進行分層：

層級	控制	它證明了什麼
網路	Jamf 出口 IP 白名單	請求來自受管理、已驗證的裝置
應用程式	API 金鑰 / 權杖	請求被授權用於特定 LLM 服務
（可選）身份	IdP 整合 / OAuth	請求與特定認證使用者相關聯

使用此分層方法，攻擊者需要同時擁有有效的 API 金鑰和在 Jamf 管理、硬體驗證的裝置上運作 — 這是比任一控制單獨顯著更高的門檻。

摘要

自託管 LLM 代表需要控制其資料、成本和 AI 供應鏈的組織的重大基礎設施承諾。如果存取僅依賴可以洩露並從網際網路上的任何裝置使用的共享 API 金鑰，該承諾就會受損。

部署 Network Relay 與受信任出口 IP 限制提供：

密碼學裝置信任植根於 Apple 硬體證明，而不是軟體權杖或共享秘密。
零接觸、零代理部署，無 VPN 用戶端、無使用者互動且無啟用步驟。
確定性來源 IP 位址，使在任何 LLM 基礎設施上進行簡單的 IP 白名單成為可能。
每個網域的路由精密度，避免完整隧道 VPN 的性能和隱私折衷。
分層安全，結合網路級裝置信任和應用程式級 API 身份驗證。

淨效果是只有受信任、受管理的裝置可以到達 LLM 基礎設施，無需對終端使用者工作流程進行任何變更。

指南