使用受信任的出口 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 协议和 Managed Device Attestation (MDA)，使组织能够将 LLM 端点的访问限制为经过验证的托管 Apple 设备 — 无需任何最终用户交互。

架构如下：

1. 来自托管设备的流量通过 Jamf Security Cloud 路由

部署 Network Relay 后，通过 MDM 将所有目的地为您的 LLM 端点域的流量自动通过使用加密 MASQUE/HTTP3 隧道的 Jamf Security Cloud 进行隧道传输。使用来自 Apple Secure Enclave 的硬件绑定密钥通过 Managed Device Attestation 对设备身份进行加密验证，因此只有真正的公司托管设备才能建立这些隧道。

2. 流量通过已知的 Jamf IP 地址出口

一旦流量通过 Jamf Security Cloud 和策略评估，它就会出口（出站）到互联网 — 因此也出口到您的 LLM 端点 — 来自已知、确定性的 Jamf IP 地址集合。这些可以是：

来自 Jamf 的全球数据中心区域之一的共享出口 IP。
专属出口 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 网关 / LLM 代理（例如 LiteLLM、OpenWebUI）： 许多 LLM 网关解决方案支持在应用层进行 IP 允许列表，作为额外的纵深防御措施。

结果：即使 API 密钥泄露，除非请求来自通过您的 Jamf Security Cloud 租户的托管设备，否则它也是无用的。

为什么选择 Network Relay

与传统的基于 VPN 的 IP 锁定的关键区别是零接触、零代理的部署模型：

无需安装应用。 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 架构的"全有或全无"权衡。
跨 Apple 平台运作。 Network Relay 在 macOS、iOS、iPadOS 和 visionOS 上受支持，可从单一配置进行管理。

*注：也可以在非 Apple 平台上使用 Jamf 的 ZTNA 解决方案进行 IP 锁定。

部署概述

以下步骤概述了端到端配置：

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

在 Jamf Security Cloud (RADAR) 控制台中，导航到集成 > 访问网关，并记下您的首选区域的共享出口 IP，或创建专属互联网网关以获得两个唯一的公共 IP，这些 IP 专门分配给您的组织。

对于专属网关，您可以创建多个区域网关并将其分组，以便设备根据其与 Jamf Security Cloud 的连接自动使用最近的出口点。

第 2 步：为您的 LLM 端点创建访问策略

导航到策略 > 访问策略并创建新策略：

定义您的 LLM 端点的域（例如 llm.yourcompany.com、api.ai.internal.yourcompany.com）。
将路由设置为使用您选择的出口网关（共享或专属）。
配置策略以应用于适当的设备组。

第 3 步：部署 Network Relay 配置文件

导航到设备 > 激活配置文件并创建或更新您的 Network Relay 激活配置文件：

在服务功能下，确保选中零信任网络访问。
在身份验证下，为零接触、无密码激活选择 Managed Device Attestation。
通过 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：

```json
{
    "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：

```json
{
    "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` 条件是为了使拒绝不会无意中阻止代表您的 Bedrock 调用（例如，您 VPC 内的 Lambda 函数调用 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 策略模拟器或从托管设备（应成功）和未托管设备（应收到 `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 基础设施，而无需对最终用户工作流进行任何更改。

---

## 相关资源

- [Jamf Connect ZTNA 快速入门指南](https://trusted.jamf.com/docs/private-access-quick-start)
- [共享互联网网关 IP 地址](https://docs.jamf.com/jamf-security/radar/documentation/Private_Access_Cloud_Internet_Gateways.html)
- [创建专属互联网网关](https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Creating_a_Dedicated_Internet_Gateway.html)
- [Jamf Connect ZTNA 网络工程师指南](https://trusted.jamf.com/docs/network-engineers-guide-to-private-access)
- [访问控制策略](https://trusted.jamf.com/v1/docs/access-restriction-strategies)
- [为网络访问强制实施合规基线](https://trusted.jamf.com/docs/enforcing-compliance-baselines-for-network-access)
- [Apple：Managed Device Attestation](https://support.apple.com/guide/deployment/managed-device-attestation-dep28afbde6a/web)
- [Apple：Network Relay (RelayManaged)](https://developer.apple.com/documentation/devicemanagement/relay)