> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/ja/serufuhosuto/inference-server/configuration/security.md).

# セルフホストサーバーの保護

自分のハードウェアで Inference を実行する場合、 **そのセキュリティ態勢はあなたが管理します**。ローカルにデプロイされたサーバーは、デフォルトでは認証、暗号化、ネットワーク制限を強制しません。安全に公開するためではなく、簡単に起動できるように作られています。初期状態では、モデルの実行や Workflow の実行要求を含め、到達するあらゆるリクエストに応答します。

このページでは、ローカル開発トラフィック以外を処理する前に、すべてのセルフホスト型デプロイメントで確認すべき 5 つのコントロールについて説明します。これらは相互補完的であるため、環境で許される限り多く適用してください。

{% hint style="warning" %}
**これはあなたの責任です。** Roboflow は、マネージドの [Serverless Hosted API](/deployment/ja/roboflow-cloud/serverless-api.md) および [Dedicated Deployment](/deployment/ja/roboflow-cloud/dedicated-deployments.md) のサービスを保護します。自分で実行するサーバーについては、ホスト、その周辺のネットワーク、および受け入れる認証情報の保護はあなたの責任です。以下のコントロールなしに信頼できないネットワークからサーバーへ到達できる場合は、世界中に公開されているものとして扱ってください。
{% endhint %}

## 1. ネットワークアクセスを制限する

最も効果的な単一のコントロールは、そもそもサーバーを公開しないことです。Inference はデフォルトでポート `9001` をリッスンし、「信頼できる」ネットワークという概念を持ちません。このポートに到達できるものは何でも使用できます。

* **localhost にバインドする** 同じホスト上のプロセスだけが必要とする場合は、たとえばコンテナポートを次のように公開します `127.0.0.1:9001:9001` ではなく `9001:9001`.
* **プライベートネットワークまたは VPC 上に保持する** 。パブリック IP ではなく、VPN、SSH トンネル、またはサービスメッシュ経由でアクセスします。
* **ホストおよびクラウドのファイアウォールまたはセキュリティグループを使用する** ポート `9001` へのアクセスを、それを必要とする特定のクライアントだけに許可するためです。
* **その前段にリバースプロキシを配置する** （nginx、Traefik、Caddy、またはクラウドロードバランサー）。より広く公開する必要がある場合に使用します。これにより、TLS、レート制限、アクセスログを追加する場所を一元化できます。

認証と TLS を導入せずに、推論ポートをパブリックインターネットへ直接公開しないでください。

## 2. 認証を強制する

デフォルトでは、セルフホスト型サーバーは **ありません** リクエストに API キーを必要としません。プラットフォームからデータを取得する際に Roboflow API レベルで行われる認証以外に、サーバー自体には追加のセキュリティはありません。認証を有効にするには、 `WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT` を、サーバーの使用を許可する Roboflow ワークスペーススラッグのカンマ区切りリストに設定します。

```bash
docker run --rm -p 9001:9001 \
  -e WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT=your-workspace-url-slug,another-workspace-url-slug \
  roboflow/roboflow-inference-server-cpu:latest
```

これを設定すると、サーバーは認可ミドルウェアをインストールします。すべての推論および Workflow リクエストには、 `api_key` （クエリパラメーターまたは JSON 本文内）が必要です。このキーは Roboflow を通じてホワイトリスト登録済みワークスペースのいずれかに解決されます。キーがない、無効である、またはホワイトリストにないリクエストは、次のエラーで拒否されます。 `401 Unauthorized`.

{% hint style="info" %}
**API キーチェックの対象外となるもの。** サーバーの使用可能性と可観測性を維持するため、少数の未認証エンドポイントは公開されたままです。 `/`, `/docs`, `/redoc`, `/info`, `/healthz`, `/readiness`, `/metrics`, `/openapi.json`、および静的アセット（`/static/...`, `/_next/...`）。次を扱ってください `/info` および `/metrics` を、サーバーに到達できる誰もが読み取れる情報として扱い、それが誰であるかを制限するためにネットワーク制限（コントロール 1）に依存してください。
{% endhint %}

**独自の認証を導入する。** 組み込みチェックは認可を Roboflow ワークスペースに結び付けます。独自のアイデンティティモデルがある場合は、サーバーの前段にリバースプロキシまたは認証ミドルウェアを配置し、OAuth/OIDC、mTLS、署名付きヘッダー、API ゲートウェイ、または組織ですでに使用している方法を強制して、認証済みトラフィックのみをポート `9001`へ通過させてください。2 つのアプローチは組み合わせることができます。

## 3. ネットワークで必要な場合は TLS を有効にする

組み込みの API キーチェックは、リクエスト内で認証情報を送信します。これらのリクエストが完全に管理下にないネットワークを通過する場合、接続は暗号化されなければなりません。そうでない場合、キーとペイロードは平文で公開されます。

選択肢は 2 つあります。

* **リバースプロキシまたはロードバランサーで TLS を終端する** 。すでにそれらを運用している場合、これは通常の選択です。
* **サーバーから直接 HTTPS を提供する** 。証明書とキーをマウントし、次を設定します。 `ENABLE_HTTPS=true`。「 [HTTPS 経由で Inference を提供する](/deployment/ja/serufuhosuto/inference-server/configuration/https.md) 」を参照してください。ここには、次を使用する相互 TLS（クライアント証明書）を含む完全なガイドがあります。 `SSL_CA_CERTS`.

純粋にローカルで、ループバックのみに限定されたトラフィック（コントロール 1、次にバインドされている場合： `127.0.0.1`）では、TLS は任意です。信頼できないネットワークを介してリクエストがホストを離れる場合は常に、TLS が必要です。

## 4. Workflow でのカスタム Python 実行を無効にする

Workflow には、 **カスタム Python ブロック**を含めることができます。これはサーバープロセス内で実行される任意の Python コードです。これは強力な機能ですが、サーバーに Workflow を送信できる人は誰でも、ホスト上で任意のコードを実行できることを意味します。信頼できないクライアントが到達できるサーバーでは、これはリモートコード実行です。

これは次の変数で制御されます。 `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS`.

| 設定                | 効果                                                    |
| ----------------- | ----------------------------------------------------- |
| `True` （現在のデフォルト） | Workflow でカスタム Python ブロックを定義および実行できます。               |
| `False`           | カスタム Python ブロックは拒否されます。他のすべての Workflow 機能は引き続き動作します。 |

Workflow がカスタム Python に依存していない場合は、これを次の値に設定してください。 `False`:

```bash
docker run --rm -p 9001:9001 \
  -e ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=false \
  roboflow/roboflow-inference-server-cpu:latest
```

{% hint style="warning" %}
**デフォルトは 2026-06-19 に変更されます。** 現在、このフラグのデフォルトは `True` で、後方互換性のためです。2026-06-19 に、デフォルトは次の値に変わります。 `False`。Workflow がカスタム Python ブロックに依存している場合は、 `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=true` を明示的に設定して、その日以降も動作し続けるようにしてください。それ以外の場合は無効のままにし、上記のネットワークおよび認証コントロールがすでに導入されているデプロイメントでのみ、有効化することを推奨します。
{% endhint %}

## 5. URL からの画像取得を制限する（SSRF）

Inference は、リクエストで指定された URL から直接画像を読み込むことができます（`{"image": {"type": "url", "value": "https://..."}}`）。サーバーが呼び出し元によって制御される URL を取得する場合、呼び出し元はサーバーに代わりにリクエストを実行させようとすることができます。これは、次のように呼ばれる攻撃の一種です。 **サーバーサイドリクエストフォージェリ（SSRF）**。内部ネットワークに直接到達できない人でも、サーバーにたとえば以下を取得するよう要求できます。

* `http://169.254.169.254/latest/meta-data/`。これはクラウドメタデータサービス（AWS、GCP、Azure）であり、インスタンス認証情報を返す可能性があります。
* `http://127.0.0.1:9001/...` およびその他の localhost サービス、すなわち管理パネル、データベース、または Inference サーバー自身の未認証エンドポイント。
* `http://10.0.0.5/`, `http://192.168.1.1/`、および境界の内側にあるその他のプライベート（RFC1918）、リンクローカル、CGNAT、または IPv6 ULA ホスト。

公開されているように見えるホスト名は、公開ターゲットである証拠ではありません。プライベート IP に解決される、プライベート IP にリダイレクトされる、または **DNS リバインディング** を使用する可能性があります（検証チェックではパブリック IP に解決し、実際の接続ではプライベート IP に解決する）。Inference には、これらすべてに対応するコントロールが備わっています。

### 必要ない場合は URL 入力を無効にする

最も強力なコントロールは、URL 画像をまったく受け入れないことです。クライアントが常に base64 またはファイルアップロードとして画像を送信する場合は、URL 取得を完全に無効にしてください。

```bash
docker run --rm -p 9001:9001 \
  -e ALLOW_URL_INPUT=false \
  roboflow/roboflow-inference-server-cpu:latest
```

### 必要な場合は URL 入力を強化する

URL 画像が必要な場合、これらのフラグはサーバーが取得を許可される対象を絞り込みます。これらを組み合わせることで、内部ターゲットを拒否し、 **検証済み IP に接続を固定し** （DNS リバインディングを防止）、すべてのリダイレクトホップを再検証します。

| 変数                                       | デフォルト   | 効果                                                                                                                                                     |
| ---------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ALLOW_URL_INPUT`                        | `True`  | URL 画像入力のマスタースイッチ。 `False` すべての URL 画像を拒否します。                                                                                                          |
| `ALLOW_URL_TO_NON_GLOBAL_ADDRESSES`      | `True`  | 次の場合、 `False`、ホストが非グローバルアドレス（ループバック、プライベート、リンクローカル/メタデータ、CGNAT、IPv6 ULA など）に解決される URL は拒否されます。また、2 回目の DNS 応答によってターゲットが切り替えられないように、接続は検証済み IP に固定されます。 |
| `VALIDATE_IMAGE_URL_REDIRECTS`           | `False` | 次の場合、 `True`の場合、リダイレクトは無条件に追跡されるのではなく、一度に 1 ホップずつ追跡され、各ホップの URL が再検証されます。                                                                              |
| `MAX_IMAGE_URL_REDIRECTS`                | `30`    | 上記フラグにかかわらず強制される、リダイレクトホップ数の厳格な上限。                                                                                                                     |
| `ALLOW_NON_HTTPS_URL_INPUT`              | `False` | 次の場合、 `False`の場合、 `https://` URL のみが受け入れられます。                                                                                                          |
| `ALLOW_URL_INPUT_WITHOUT_FQDN`           | `False` | 次の場合、 `False`の場合、ホストが裸の IP、またはパブリックサフィックスを持たない URL は拒否されるため、呼び出し元は実際のドメイン名を使用する必要があります。                                                                |
| `WHITELISTED_DESTINATIONS_FOR_URL_INPUT` | 未設定     | 送信先のカンマ区切り許可リスト（`subdomain.domain.suffix`）。設定すると、これらのみが許可されます。                                                                                         |
| `BLACKLISTED_DESTINATIONS_FOR_URL_INPUT` | 未設定     | 常に拒否される送信先のカンマ区切りブロックリスト。                                                                                                                              |

パブリック HTTPS 画像 URL を引き続き許可する強化設定：

```bash
docker run --rm -p 9001:9001 \
  -e ALLOW_URL_TO_NON_GLOBAL_ADDRESSES=false \
  -e VALIDATE_IMAGE_URL_REDIRECTS=true \
  roboflow/roboflow-inference-server-cpu:latest
```

最も厳格に制御するには、許可リストを追加し、サーバーが画像を提供する正確なホストにのみ到達できるようにします。

```bash
docker run --rm -p 9001:9001 \
  -e ALLOW_URL_TO_NON_GLOBAL_ADDRESSES=false \
  -e VALIDATE_IMAGE_URL_REDIRECTS=true \
  -e WHITELISTED_DESTINATIONS_FOR_URL_INPUT=images.example.com,cdn.example.com \
  roboflow/roboflow-inference-server-cpu:latest
```

{% hint style="warning" %}
**2 つのデフォルトは 2026 年第 4 四半期に変更されます。** `ALLOW_URL_TO_NON_GLOBAL_ADDRESSES` （次の値へ： `False`）および `VALIDATE_IMAGE_URL_REDIRECTS` （次の値へ： `True`）は現在、後方互換性のために従来の寛容な動作をデフォルトとしています。両方のデフォルトは 2026 年第 4 四半期に安全な値へ切り替わる予定です。早期に安全な値を使用するには今すぐ明示的に設定してください。あるいは、Workflow が実際に内部 URL の取得に依存している場合は従来の値に設定し、変更による予期しない影響を避けてください。
{% endhint %}

{% hint style="info" %}
**プロキシはこの保護を回避します。** サーバーに HTTP(S) プロキシが設定されている場合、送信先を解決するのは Inference ではなくプロキシです。そのため、非グローバルアドレスのブロックと接続固定を強制できません。サーバーはこれを検出すると警告を出します。これらのコントロールに依存する場合は、プロキシ自体が到達できる範囲を制限してください。
{% endhint %}

{% hint style="info" %}
**Python SDK にも同じコントロールがあります。** 次の `inference-sdk` クライアントは、URL から画像を読み込む際に同じ URL ポリシーおよび SSRF 保護を適用し、同じ環境変数を読み取ります。そのため、送信前に URL 画像を取得するクライアントも保護されます。
{% endhint %}

## 推奨ベースライン

次の範囲を超えて到達可能な、あらゆるセルフホスト型サーバーについて： `localhost`:

* ネットワークアクセスを既知のクライアントに制限する（ファイアウォール、プライベートネットワーク、またはプロキシ）。
* `WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT` を設定するか、前段に独自の認証を配置する。
* サーバーまたは上流プロキシで TLS を終端する。
* `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=false` が本当に必要な場合を除きます。
* URL 画像入力を無効にする（`ALLOW_URL_INPUT=false`）。または、次の設定で強化します： `ALLOW_URL_TO_NON_GLOBAL_ADDRESSES=false` および `VALIDATE_IMAGE_URL_REDIRECTS=true`。さらに可能な場合は許可リストを追加します。

こちらも参照 [受け入れられる入力形式](/deployment/ja/serufuhosuto/inference-server/configuration/input-formats.md) 。pickle 化された NumPy 入力のコントロールについては、また、 [本番運用準備チェックリスト](/deployment/ja/production-checklist.md) 。エラー処理とレート制限についてはこちらを参照してください。