Jamf Concepts
ガイド

ガイド

信頼されたエグレス IP による LLM アクセスのセキュリティ保護

~5 min read

信頼されたエグレス 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 を経由して自動的にトンネリングされます。デバイス ID は、Managed Device Attestation 経由で Apple Secure Enclave のハードウェアバウンドキーを使用して暗号的に検証されるため、本物の企業管理デバイスのみがこれらのトンネルを確立できます。

2. トラフィックが既知の Jamf IP アドレス経由でエグレス

トラフィックが Jamf Security Cloud を通過してポリシー評価を受けた後、インターネット — したがって LLM エンドポイント — に（エグレス）します — 既知の確定的な Jamf IP アドレスのセットから。これは以下のいずれかです:

  • Jamf の グローバルデータセンターリージョンからの共有エグレス IP。
  • 組織に一意に割り当てられた専用エグレス IP — 他の Jamf 顧客が使用しないリージョンごとに 2 つの高可用性パブリック IP を提供します。

3. LLM エンドポイントは信頼された IP からのアクセスのみを制限

トラフィックが既知で信頼されたセットの IP アドレスから到着するようになったため、LLM インフラストラクチャを構成して、これらの Jamf エグレス IP からの接続のみを受け入れ — 他のすべてを拒否します。これはネットワークレイヤーで適用される標準的な IP ホワイトリストです:

  • クラウドホストされた LLM（AWS/Azure/GCP）: Security Groups、Network Security Groups、またはファイアウォールルールを構成して、Jamf エグレス IP からのインバウンド HTTPS（TCP/443）のみを許可します。AWS Bedrock の例については以下を参照してください マイ見出しへのリンク
  • オンプレミス LLM: エッジファイアウォールまたはリバースプロキシ（例：nginx、HAProxy、Caddy）を構成して、Jamf エグレス IP 範囲からの接続のみを受け入れるようにします。
  • API Gateway / 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 によって管理されており、改ざんされていないことを暗号的に証明します。これはソフトウェアのみのエージェントよりも強力な ID シグナルを提供します。
  • ドメイン単位の精度。 すべてのトラフィックをルーティングする完全トンネル VPN とは異なり、Network Relay はドメイン単位で動作します。Jamf 経由でトンネリングする必要があるドメイン（例：llm.internal.yourcompany.com）を正確に定義します — 他のすべてのトラフィックに影響を与えません。これにより、パフォーマンスへの影響を最小化し、レガシー VPN アーキテクチャの「すべてかなし」のトレードオフを回避できます。
  • Apple プラットフォーム全体で動作します。 Network Relay は macOS、iOS、iPadOS、visionOS でサポートされており、単一の構成から管理できます。

*注: IP ロックダウンを Jamf の ZTNA ソリューションと共に非 Apple プラットフォームで使用することも可能です。

デプロイメント概要

以下のステップは、エンドツーエンド構成の概要を示しています:

ステップ 1: Jamf Security Cloud でエグレスを構成

Jamf Security Cloud（RADAR）コンソールで、Integrations > Access Gateways に移動し、優先リージョンの共有エグレス IP を確認するか、組織に一意に割り当てられた 2 つのパブリック IP を受け取るために専用インターネット ゲートウェイを作成します。

専用ゲートウェイの場合、複数の地域ゲートウェイを作成してグループ化できるため、デバイスは Jamf Security Cloud への接続に基づいて自動的に最も近いエグレスポイントを使用します。

ステップ 2: LLM エンドポイント用のアクセスポリシーを作成

Policies > Access Policies に移動し、新しいポリシーを作成します:

  • LLM エンドポイントのドメイン（例：llm.yourcompany.com、api.ai.internal.yourcompany.com）を定義します。
  • ルーティングを選択したエグレスゲートウェイ（共有または専用）を使用するように設定します。
  • ポリシーを適切なデバイスグループに適用するように構成します。

ステップ 3: Network Relay プロファイルをデプロイ

Devices > Activation Profiles に移動し、Network Relay 有効化プロファイルを作成または更新します:

  • Service Capabilities で、Zero Trust Network Access が選択されていることを確認します。
  • Authentication で、ゼロタッチ、パスワードレス有効化について Managed Device Attestation を選択します。
  • 結果の構成プロファイルを Jamf Pro 経由で管理対象デバイスにデプロイします。

デプロイされると、デバイスは Jamf Security Cloud 経由で LLM ドメインへのトラフィックのルーティングを自動的に開始します。

ステップ 4: LLM エンドポイントを Jamf エグレス IP にロックダウン

LLM インフラストラクチャ側では、インバウンドアクセスを Jamf エグレス IP アドレスのみに制限します。例:

AWS セキュリティグループ:

インバウンドルール: タイプ: HTTPS（TCP 443） ソース: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32 説明: Jamf 信頼されたデバイスのみ

nginx リバースプロキシ:

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

    # Jamf エグレス IP のみを許可
    allow <Jamf Egress IP 1>;
    allow <Jamf Egress IP 2>;
    deny all;

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

**Azure ネットワークセキュリティグループ:**

インバウンドセキュリティルール:
  優先度: 100
  ソース: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  宛先ポート: 443
  プロトコル: TCP
  アクション: 許可

インバウンドセキュリティルール:
  優先度: 200
  ソース: Any
  宛先ポート: 443
  プロトコル: TCP
  アクション: 拒否

### ステップ 5: 検証と監視

- リレープロファイルがデプロイされた管理対象デバイスから、LLM エンドポイントへのリクエストが成功することを確認します。
- 管理対象外のデバイス（またはリレープロファイルが削除されている）から、リクエストがブロックされることを確認します。
- LLM インフラストラクチャのアクセスログを監視して、すべてのインバウンド接続が期待される Jamf エグレス IP から発信されていることを確認します。
- Jamf Security Cloud の **Reports > Access** セクションで接続ログを確認して、LLM エンドポイントにアクセスしているユーザーとデバイスを可視化します。

## 管理 LLM サービスへの拡張: AWS Bedrock

同じ信頼されたエグレス IP アプローチは、自己ホストされたモデルを超えて適用されます。組織が管理 LLM 推論に **Amazon Bedrock** を使用する場合、**AWS IAM ポリシー**で `aws:SourceIp` 条件を使用して IP ベースの制限を実施でき、Jamf エグレス IP から発信されたリクエストのみが Bedrock モデルを呼び出せることを確保します。

セキュリティグループ、ファイアウォールなどのネットワークレイヤーを制御する自己ホストデプロイとは異なり、Bedrock は完全に管理された AWS サービスです。Bedrock 自体のインバウンドファイアウォールルールは構成しません。代わりに、**リクエストが信頼できる IP から発信されない限り、モデル呼び出しを拒否する** IAM ポリシーをアタッチします。

### 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 Egress IP 1>/32",
                        "<Jamf Egress IP 2>/32"
                    ]
                }
            }
        }
    ]
}

このポリシーは他のすべての Bedrock 権限（例：モデルのリスト、プロビジョニングされたスループットの管理）が正常に機能することを許可します — 推論呼び出しアクションのみを信頼できる IP に制限します。既存の IAM ポリシーに既に明示的な DENY ルールが含まれている場合、暗黙的な許可に依存する代わりに、信頼できる IP に対する明示的な ALLOW ステートメントを追加する必要があります。

### サービスコントロールポリシー（SCP）組織全体の実施のため

個々の IAM プリンシパルではなく、組織内の**すべての AWS アカウント**全体で IP 制限を実施する場合、AWS Organizations で SCP として適用します:

```json
{
    "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 内から Bedrock を呼び出す Lambda 関数、Bedrock を呼び出す Step Functions ワークフロー、Bedrock を使用する SageMaker ノートブック）推論）。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` を受け取る必要があります）の両方から test `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)