> 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/self-hosted/inference-server/configuration/security.md).

# self-hosted サーバーのセキュリティ保護

self-hosted Inference を既定でローカルに保ち、Workflows を実行できるユーザーを選択し、モデル、メディア、トランスポートの制御を構成します。

Self-hosted Inference ではローカル開発の自由度を保ちます。カスタム Python は既定でローカル実行され、認証を設定しない限りサーバーに API キーは不要です。CLI はサーバーを次のアドレスで公開します `127.0.0.1` 既定では、以下の例外を除き、他のマシンはその公開ポートに到達できません。

アップグレード時の動作とバージョンスコープについては、次を参照してください [セキュリティ設定の移行](/deployment/ja/self-hosted/inference-server/configuration/security-migration.md).

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

Workflow のどの機能を使用できるかを変更する前に、クライアントがサーバーにどう到達するかを選択してください。

<table data-search="false"><thead><tr><th>起動方法</th><th>既定のネットワークアクセス</th><th>設定</th></tr></thead><tbody><tr><td>CPU または GPU ホスト上の Inference CLI</td><td>ホストのループバック、127.0.0.1:9001</td><td>--bind-address または -b を使って別のホストアドレスを選択します。</td></tr><tr><td>Jetson イメージを使う Inference CLI</td><td>すべてのホストインターフェース、0.0.0.0:9001</td><td>ローカル専用アクセスにするには --bind-address 127.0.0.1 を使用します。</td></tr><tr><td>macOS および Windows のデスクトップバンドル</td><td>127.0.0.1</td><td>別のインターフェースを選ぶには HOST を明示的に設定します。</td></tr><tr><td>手動の Docker または Compose</td><td>ポートマッピングによって決定される</td><td>ローカル専用アクセスには 127.0.0.1:9001:9001 を使用します。</td></tr><tr><td>--tunnel を使う Inference CLI</td><td>CLI はトンネルが接続できるように 0.0.0.0 で公開します。</td><td>LAN アクセスとトンネルアクセスの両方を確認してください。</td></tr></tbody></table>

### CLI でサーバーを起動する

`inference server start` ポート 9001 を次で公開します `127.0.0.1`。そのため、この方法で起動したサーバーは、それを起動したマシン上のプロセスにのみ応答します。これはローカル開発に適した既定値であり、このページの許容的な既定値が安全なのはこの構成だけです。非ループバックアドレスで公開すると、CLI は警告します。

```bash
# 既定: このマシンからのみ到達可能
inference server start

# 意図的な LAN アクセス: このホストへ経路を持つすべてのマシンから到達可能 - まず保護する
inference server start --bind-address 0.0.0.0 --env-file inference.env
```

{% hint style="warning" %}
**NVIDIA Jetson は例外です。** Jetson イメージはヘッドレスなエッジデバイスで、ほとんど常に別のマシンから操作されるため、 `inference server start` 次の場所で公開します `0.0.0.0` - それが接続されている Wi‑Fi ネットワークの残り部分を含め、デバイスへ経路を持つあらゆるものから到達可能です。以下の制御を適用するか、次で固定してください `inference server start --bind-address 127.0.0.1`.
{% endhint %}

### 次でサーバーを起動する `docker run`

イメージ側ではこの選択はできないため、 **コマンドラインで指定する必要があります**. `HOST` インターフェースを選択します *内側の* コンテナ内で、コンテナは独自のネットワーク名前空間を持ちます。つまり、イメージが `HOST=127.0.0.1` を出荷している場合は、コンテナ自身のループバックにバインドされ、公開ポートからは到達できません。そのため、サーバーはホスト側からも到達不能になります。これが、すべてのイメージが `HOST=0.0.0.0`で出荷される理由です。ブリッジネットワークのコンテナ内ではそのままにして、代わりにポートマッピングのホスト側で制限してください:

```bash
# このマシンからのみ到達可能
docker run --rm -p 127.0.0.1:9001:9001 roboflow/roboflow-inference-server-cpu:latest

# このホストへ経路を持つすべてのマシンから到達可能 - まず保護する
docker run --rm -p 9001:9001 roboflow/roboflow-inference-server-cpu:latest
```

動作が異なるケースが 2 つあります:

* **`--network host`** （Linux）ではポートマッピングが完全になくなり、コンテナはホストのインターフェースに直接バインドします。その場合、 `-e HOST=127.0.0.1` *が* サーバーをローカルのままに保つ方法です。
* **Kubernetes** では各 Pod に独自のネットワーク名前空間が与えられるため、 `HOST=0.0.0.0` はそのままにして、バインドアドレスではなく Service の種類と NetworkPolicy で露出を制御してください。

{% hint style="warning" %}
**`-p 9001:9001` はすべてのインターフェースを意味します。** 明示的なアドレスを指定しない場合、Docker は次で公開します `0.0.0.0`。ホストが持つ任意のパブリック IP も含まれます。Linux では、Docker 独自のフォワーディングルールが `ufw`/`firewalld` のルールより先にほとんどの既定構成で評価されるため、別途設定したホストファイアウォールではブロックできない場合があります。実際に何が待ち受けているかは次で確認してください `docker port <container>` または `ss -tlnp | grep 9001`.
{% endhint %}

{% hint style="info" %}
Python サーバーの直接起動、ホストネットワーキング、手動の Docker 公開はそれぞれ独自のネットワーク設定が必要であり、CLI の既定値はそれらの経路を制限しません。
{% endhint %}

ループバック以外にバインドすると、信頼されていないクライアントがサーバーに到達できる可能性があり、このページで説明している既定値はそれを想定していません。ポートを公開する前に、少なくとも次を実施してください: [リモートクライアントを許可する前に](#before-allowing-remote-clients) まず。

## 認証を強制する

設定 `WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT` を許可する Workspace のスラッグに設定して、Inference、Workflow、および統合された `/inference_pipelines/*` へのリクエストに API キーを要求します。クライアントはキーを `Authorization: Bearer YOUR_API_KEY`、 `api_key` クエリパラメータ、または対応する JSON リクエストボディで送信できます。サーバーは Roboflow API を通じて Workspace 所属を検証します。

たとえば、これを `inference.env` ファイルに入れて CLI に渡します:

```dotenv
WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT=your-workspace-url-slug
```

別の ID システムを使っている場合や、Roboflow API への接続なしで認証が必要な場合は、サーバーの前段に認証済みプロキシを置き、クライアントがそれをバイパスできないようにしてください。

### ヘルスと可観測性

Workspace のチェックは `/`, `/docs`, `/redoc`, `/info`, `/healthz`, `/readiness`, `/metrics`, `/openapi.json`、静的アセット、および任意の `/secure-gateway/health` エンドポイントを API キーなしで利用可能にしたままにします。これによりヘルスチェックと [テレメトリ](/deployment/ja/self-hosted/inference-server/configuration/telemetry.md)が維持されます。出力が機密情報の場合はネットワークアクセスを制限してください。有効な場合、TLS クライアント証明書の要件はこれらのエンドポイントにも適用されます。

## 信頼できる呼び出し元に対して Custom Python を利用可能に保つ

`ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=True` と `WORKFLOWS_CUSTOM_PYTHON_EXECUTION_MODE=local` は既定のままであるため、ローカルユーザーはオプトインしなくても Custom Python を実行できます。そのコードはサーバープロセス内で、その権限で実行されます。認証は送信できる相手を制御しますが、認証済みの呼び出し元をサンドボックス化しません。Workspace 認証なしでローカル Custom Python が有効な場合、サーバーはセキュリティ通知をログに出します。

### 不要な場合はローカル実行を無効にする

設定 `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=False` にすると、ローカル Custom Python の実行を拒否します。Modal 実行は別モードであり、このフラグでは無効になりません。次を参照してください [Custom Blocks](https://docs.roboflow.com/workflows/blocks/custom-blocks) および [オフライン移行ガイダンス](/deployment/ja/self-hosted/inference-server/configuration/security-migration.md#offline-custom-python).

## モデルアクセスを保護する

[モデルパッケージのセキュリティ](/deployment/ja/self-hosted/inference-server/configuration/model-security.md) は、Workspace 認証、モデルごとの認可、実行可能パッケージを読み込む権限を区別します。特に、オンラインのモデルごとの認可は、ファイルシステムのパスには認可すべき Roboflow モデル ID がないため、直接のローカルパッケージ読み込みと組み合わせることはできません。

## ビデオワークロードを設定する

[ビデオ設定](/deployment/ja/self-hosted/inference-server/configuration/video-configuration.md) は、管理されたパイプラインのプロセス上限、ウォームワーカー、サーバー側のメディア参照を対象とします。プロセス上限はリソース使用量を制限しますが、呼び出し元の認証やコードの分離は行いません。

## ネットワーク転送を保護する

を使用してください [HTTPS](/deployment/ja/self-hosted/inference-server/configuration/https.md) を、ホストを超える通信にはサーバー側または認証済み TLS プロキシで利用します。送信側の [Secure Gateway](/deployment/ja/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers) 接続には独自の TLS 設定があり、サーバーのリッスンアドレスとは別です。

## 画像の取得を制限する

呼び出し元が指定した画像 URL により、サーバーが内部サービスやメタデータエンドポイントへ接続してしまう可能性があります。 [受け入れ可能な入力形式](/deployment/ja/self-hosted/inference-server/configuration/input-formats.md#sending-urls-to-inference-images) は、アプリケーションに必要な形式を維持しながら、URL 入力の無効化、送信先の制限、リダイレクトの検証方法を説明します。これらの画像取得制御は、他の Workflow 統合やビデオ転送のネットワーク制限の代わりにはなりません。

## Webhook Sink の送信先を制限する

Webhook Sink は、Workflow データをプライベートネットワーク上のサービスへ送信できます。Self-hosted Inference では、既存の工場内および LAN の webhook が引き続き機能するよう、これらの送信先を既定で許可しています。

設定 `ALLOW_WEBHOOK_WORKFLOWS_SINK_TO_NON_GLOBAL_ADDRESSES=False` は、呼び出し元が送信先を選べない場合に使用します。これはループバック、プライベート、リンクローカル（クラウドメタデータを含む）、CGNAT、予約済み、マルチキャストの各アドレスを拒否します。Webhook リクエストはホスト名を 1 回解決し、検証済みのアドレスへ接続します。どちらの設定でもリダイレクトと HTTP(S) プロキシは拒否されます。

## リモートクライアントを許可する前に

ループバック以外にバインドすると、信頼されていないクライアントがサーバーに到達できる可能性があり、このページの許容的な既定値はそれを想定していません。ポートを公開する前に、少なくとも次を実施してください:

* バインドアドレスを意図的に選ぶ: `inference server start` なしで `--bind-address`、または `-p 127.0.0.1:9001:9001` を使う `docker run`、リモートクライアントが必要な場合を除いて。
* アクセスは既知のクライアントに限定してください。プライベートネットワークまたは VPC に留まり、公開 IP ではなく VPN、SSH トンネル、またはサービスメッシュ経由でサーバーに到達し、ホストおよびクラウドのファイアウォールやセキュリティグループでポート `9001` を必要な特定のクライアントからのみ許可します。
* Workspace 認証またはプロキシでの独自認証を有効にしてください。それがないと、ポート `9001` に到達できる誰でも、あなたのハードウェア上で、あなたの Roboflow アカウントのクォータを使ってモデルや Workflows を実行できます。
* 信頼されていないネットワークを越える通信には TLS を設定してください。
* Custom Python と実行可能なモデルパッケージは、サーバーの権限で信頼できる呼び出し元だけが使えるようにしてください。到達可能なサーバーで有効のままだと、ローカル Custom Python は Workflow を送信できる誰にとってもリモートコード実行になります。
* URL からの画像入力を無効にするか、あるいは、に記載のとおり、送信先許可リストとリダイレクト検証で強化してください [受け入れ可能な入力形式](/deployment/ja/self-hosted/inference-server/configuration/input-formats.md#sending-urls-to-inference-images).
* 設定 `ALLOW_WEBHOOK_WORKFLOWS_SINK_TO_NON_GLOBAL_ADDRESSES=False` 信頼できるプライベートサービスまたはローカルサービスへ webhook を送る必要がある場合を除いて。
* より広く公開する必要がある場合は、サーバーの前段にリバースプロキシ（nginx、Traefik、Caddy、またはクラウドロードバランサー）を置いてください。そうすれば、TLS、レート制限、アクセスログを追加する単一の場所を確保できます。
* ヘルスチェックとメトリクスコレクターが引き続き接続できることを確認してください。

認証と TLS がないまま inference ポートを直接パブリックインターネットに公開しないでください。

次を使用してください [本番稼働準備チェックリスト](/deployment/ja/production-checklist.md) を、再試行、容量、監視について確認してください。