こんにちは！セキュリティチームのHitomiです。
会社のBox テナントは全社で 1 つですが、そこにアクセスする環境は 2 種類あります。片方ではファイルリクエストを使わせたい、もう片方では使わせたくない・・・制御はどうしたらいい？というのを今回ブログでご紹介します。
本記事では次のように呼びます。
- 環境 A：ファイルリクエストを使わせたい環境。普段の業務 PC で、取引先から書類を集めるのに日常的に使っている
- 環境 B：ファイルリクエストを使わせたくない環境。複数人で使う共有の VM で、扱うデータの性質上、外部へファイルを持ち出せる経路はできるだけ減らしたい
イメージが湧きやすいように図にしました。
「環境 B だけファイルリクエストを止めればいいよね」
・・・と軽く考えて設定を探し始めたのですが、ちょっと混乱しました。
Box のテナント設定でも、Netskopeで一般的に使うアクティビティ制御やインスタンス識別でも、この「同じテナント内で環境ごとに分ける」をきれいに実現できません。
最終的にたどり着いたのは、Box が生成する通常のファイルリクエスト共有 URL が /f/ パスで始まるという仕様を利用する方法でした。
3行まとめ
- Box のファイルリクエストは、リンクさえあれば Box アカウントなしで相手のフォルダにファイルをアップロードできる機能。テナント設定で絞れるのは発行側（作成・編集できるユーザー）だけで、リンクを開いてアップロードする側は環境ごとに分けられない
- 筆者環境での検証では、Netskope の Upload アクティビティ制御上、ファイルリクエスト経由のアップロードも正規の業務アップロードも同じ「Upload」として扱われ、まとめてしか止められなかった。インスタンス識別では自社テナント宛のファイルリクエストを通常の自社 Box 利用から分けられず、今回の要件には適合しない
- Box が生成する通常のファイルリクエスト共有 URL が
/f/で始まる仕様を利用し、Box ドメイン +/f/の Destination Profile を Real-time Protection ポリシーに直接紐付け、対象環境だけにスコープしてブロックする
想定読者
- Netskope で Box への操作を、自社テナントを識別したインスタンス制御で運用していて、ファイルリクエスト経由の持ち出しが気になっている方
- 共有 VM・貸出端末など、特定の環境だけ SaaS の機能を絞りたい方
本記事の内容は、2026 年 9月時点の Box / Netskope 公式ドキュメントと、筆者環境での検証結果に基づきます。UI 名称・メニュー配置はリリースにより変更される可能性があります。
前提と要件
読み進める前に、本記事が扱う構成と要件を先に整理しておきます。
- Box テナントは全社で 1 つ。環境 A・環境 B は同じテナントにアクセスする
- 要件 1：環境 B では、宛先が自社テナントか他社テナントかを問わず、ファイルリクエスト経由のアップロードをすべて止めたい
- 要件 2：環境 A のファイルリクエスト利用と、環境 B での正規の Box 業務には影響を与えない
- 前提 1：環境 B の端末は Netskope でステアリングされており、Box 宛通信は SSL 復号の対象である
- 前提 2：Box のカスタムドメイン構成（Box Verified Enterprise 等）の有無は問わない（手順内で補足します）
そもそもファイルリクエストとは？なぜ持ち出し経路になるのか
ファイルリクエストは、自分の Box フォルダへのアップロード用フォームを生成して、そのリンクを配る機能です。リンクの受信者はファイルをドラッグアンドドロップするだけでよく、Box にログインする必要も、Box アカウントを所有している必要もありません（出典：Box 公式サポート「ファイルリクエストの概要」）。
取引先から書類を集めるにはとても便利です。ただ、視点を裏返すとどうでしょうか。誰かが自分のテナントで発行したリンクを環境 B で開けば、認証なしで、環境 B の中のファイルを外のフォルダに送り込めるということでもあります。
受け口の URL は、Box Platform API リファレンスの FileRequest.url フィールドで /f/19e57f40ace247278a8e3d336678c64a という形式と定義されています（出典：Box Developer「ファイルリクエストをコピー」）。
つまり、Box が生成する通常の共有リンクは、どのテナント宛でも次の形です。
https://app.box.com/f/{ID}この「通常の共有リンクでは、テナントを問わず /f/ で始まる」という点がポイントです。カスタムドメイン構成ではホスト名が 企業名.ent.box.com などに変わりますが、パスが /f/ で始まる点は変わりません。なお、ここで扱うのは Box が生成する通常の共有リンクです。埋め込みウィジェットなど別経路については、後述のとおり実環境での確認が必要です。
Box 側のテナント設定で対応できるか
まずは Box のテナント設定から確認しました。
ファイルリクエストの利用可否は、管理コンソールの Enterprise設定 > コンテンツと共有 で設定できます。すべての管理対象ユーザーに許可する／一部のユーザー・グループにのみ許可する／機能を全面的に無効にする、の 3 択です（出典：Box 公式サポート「ファイルリクエストの管理」）。
ユーザーやグループ単位で絞れるなら、環境別に分けられそうに見えます。
ただ、これは「人」の単位であって「環境」の単位ではありません。環境 A と環境 B を行き来するユーザーがいる場合、その人から権限を外せば環境 A での業務も止まります。
もちろん、環境 B 専用のアカウントを分けて運用すれば、この「人単位」の設定を実質環境単位に寄せることはできなくはありません。
ただ、そのためには環境 B 専用アカウントの発行・割り当て・ライフサイクル管理を含むアカウント設計の見直しが必要で、今回の要件に対しては変更範囲が大きくなります。
またこの設定で制御できるのはファイルリクエストを作成・編集できるユーザー、つまり発行側だけです。環境 B のユーザーが誰かの発行したリンクを開いてアップロードする経路には、この設定は最初から届きません。他社テナント発行のリンクはなおさら制御の外です。
おまけに、機能を無効にしても、無効化前に発行済みのリンクは個別に無効化・削除しない限り引き続き利用できます。
そこで発想を変えます。環境 B は Netskope を通っているので、ネットワーク経路上で受け口そのものを塞げれば、Box 側のアカウント設計に手を入れず、ブロックポリシーを 1 本入れるだけで済みそうです。ならば Netskope で、となるのですが、ここでもう一段つまずきました。
Netskope のいつもの制御が、この形には効かない
以下は、2026 年 9 月時点の筆者環境で確認した結果です。
| 対策案 | 期待したこと | 実際 |
|---|---|---|
| ① 環境 B 向けに Box への Upload アクティビティを Block | ファイルリクエストリンクを使った、テナント識別をしない（できない）アップロードだけ止まる | ファイルリクエストも止まるが、環境 B での正規の自社 Box 利用のアップロードまでブロックされる |
| ② インスタンス識別で自社インスタンスのみ Upload 許可 | 自社利用は通り、外部は止まる | 通常のアップロード制御には有効。しかし要件 1 のとおり、止めたいファイルリクエストの宛先には自社テナントも含まれるため、テナントの区別は今回の軸にならない |
②を補足します。インスタンス識別はテナントを見分ける仕組みです。「自社テナントのファイルリクエストも環境 B では禁止したい」という今回の要件の前では、そもそも切り口が合いません。
自社宛のファイルリクエストは、インスタンスから見ればどこまでも「自社」だからです。
加えて、ファイルリクエストのアップロードは既定では Box の認証を伴わずに行え、URL も通常の Box 操作と同じ Box ドメイン配下です（既定では app.box.com、Box Verified Enterprise などのカスタムドメイン構成では 企業名.ent.box.com 等になります）。
アクティビティでは粗すぎる。インスタンスでは軸が合わない。残っているのは、機能そのものを識別できる URL です。
突破口：通常のファイルリクエスト共有 URL は「/f/」で始まる
冒頭で確認したとおり、Box Platform API の FileRequest.url フィールドでは、Box が生成する通常のファイルリクエスト共有 URL が /f/ で始まる形式として示されています。これは宛先テナントが自社か他社かを問わず共通で、通常の Box 操作（/folder/、/file/ など）とはパスが重なりません。
ならば、Box 関連ドメインの /f/ 配下だけを URL でブロックし、そのポリシーを環境 B にだけ適用すれば、要件がそのまま満たせるはず。
受け皿は Destination Profile を使います。FQDN・URL・IP などの宛先をまとめてポリシーから参照するためのプロファイルで、すべての宛先タイプでポート・パス・クエリの指定に対応しており、*.example.com 形式のワイルドカードはサブドメインとトップドメインの両方にマッチします。
スキーム（http:// 等）は記述できず、必要ならポートで表現します（出典：Netskope 公式ドキュメント「Migrating URL Lists to Destination Profiles」の仕様記述）。
手順1：Destination Profile を作成する
Policies > Destination から New Destination Profile を作成し、Box の主要ドメインに /f/ を付けたものを宛先として登録します。
*.box.com/f/実際にユーザーが踏むのは、既定では app.box.com/f/、カスタムドメイン構成では 企業名.ent.box.com/f/ や 企業名.app.box.com/f/ です。*.box.com のワイルドカードはサブドメインとトップドメインの両方にマッチするため、これらはいずれも *.box.com/f/ の 1 行でカバーできます。Destination Profile のパスマッチは /f/ 配下に限定されるため、通常の Box 利用への影響を抑えられます。ただし、意図しない影響がないことは、後述の動作確認で確認してください。
なお、ここでの制御対象は通常の共有 URL です。埋め込みウィジェットなど別経路も対象になるかは、別途検証が必要です。
手順2：環境 B にスコープした Real-time Protection ポリシーを作る
Real-time Protection ポリシーを新規作成し、Destination Profile に手順 1 の Destination Profile、Action に Block を設定します。
ポリシーの適用範囲を環境 B だけに絞ります。環境 B の利用者が固定ならユーザーグループ / OU の指定で十分ですが、同一ユーザーが環境 A と環境 B を行き来する場合は、On-Premise Detection・ソース IP・デバイス分類など、「人」ではなく「環境」を識別できる条件でスコープしてください。
既存の Box 関連ポリシーとの評価順序を確認し、先に許可ポリシーへ一致する場合は、このブロックポリシーを上位に配置してください。環境 A のユーザーはこのポリシーの適用対象外なので、ファイルリクエストは従来どおり使えます。
💡 ブロック通知テンプレートに「この環境ではファイルリクエストの利用を制限しています」と理由をひとこと書いておくと、ヘルプデスクへの問い合わせが減ります。
通知テンプレートの作り込みについては「英語のデフォルト通知のまま展開しない。NetskopeのUser Alert通知を『チューニングの入力チャネル』にする」で詳しく書いています。
動作確認
デプロイ後に確認すべきは、「塞がったこと」と「巻き込んでいないこと」の両方です。
- 環境 B の端末からファイルリクエスト URL にアクセスし、ブロックページが表示されることを確認する（自社テナント発行・他社テナント発行の両方で。カスタムドメイン構成の場合は、そのドメインの URL でも確認する）
- 環境 B から自社 Box への通常のアップロード（
/folder/配下での操作）が従来どおり成功することを確認する - 環境 A の端末からは、ファイルリクエストの発行・アップロードとも従来どおり動くことを確認する
2 と 3 は省きたくなるのですが、この施策の価値は「環境 B を塞いだこと」ではなく「環境 A と B の通常業務に影響がなく塞げること」にあります。必ずセットで確認してくださいね。
運用上の注意点
- 環境 B の識別精度が、そのまま制御の精度になります。
ユーザーグループで絞る場合、環境 A と環境 B を行き来するユーザーがいると、環境 A 利用時までブロックされます。その場合は On-Premise Detection・ソース IP・デバイス分類など、ユーザー以外の属性で絞る設計に寄せてください。
- Netskope を経由しない経路には効きません。
環境 B の VM が確実にステアリングされていること、ステアリング例外に Box ドメインが入っていないことが前提です。
- HTTPS のパスを見る制御なので、Box 宛通信が SSL 復号の対象であることが前提です。
Do Not Decrypt 例外に Box ドメインが入っていると、パスマッチが機能しません。
- URL 構造は Box の仕様に依存します。
現行の公式リファレンスでは
/f/ですが、将来の UI 刷新でパスが変わる可能性はゼロではありません。リリースノートの監視対象に入れておくことをおすすめします。 - 埋め込みウィジェット経路は別途検証が必要です。
Box にはファイルリクエストを iframe でイントラネットや外部サイトに埋め込む「アップロード埋め込みウィジェット」の使い方もあります（出典：Box 公式サポート「ファイルリクエストの管理」）。ウィジェットの読み込み URL が
/f/を通るかは公式ドキュメントに明記がないため、埋め込みページ経由のアップロードもブロックされるかは実環境での検証をおすすめします。
まとめ
「環境 B だけファイルリクエストを止めればいいよね」から始まった今回の設定探し、蓋を開けてみれば、Box のテナント設定（発行側しか制御できず、環境単位に寄せるには大がかり）も、Upload アクティビティ制御（粗すぎる）も、Instance Awareness（同一テナント内の機能は見分けられない）も、今回の要件にはまっすぐ合いませんでした。
- Box が生成する通常のファイルリクエスト共有 URL は、テナントを問わず
/f/で始まる（埋め込みウィジェットなど別経路は要検証） - Box ドメイン +
/f/の Destination Profile を Real-time Protection ポリシーに直接紐付ける - ポリシーのスコープで環境を切れば、環境 A と通常の Box 利用には指一本触れずに、環境 B だけ塞げる
テナント設定は「誰が発行できるか」、インスタンス制御は「テナントの区別」、そして URL × ポリシースコープは「機能 × 環境の区別」。どのレイヤーが要件の軸に合っているかを先に見極めると、遠回りせずに済みます。
ファイルリクエストに限らず、SaaS 側に匿名の受け口を作れる機能（フォーム系・リクエスト系の機能全般）は同じ発想で環境別制御が組めるはずなので、統制対象アプリの棚卸しのついでに、ぜひ探してみてください。
参考文献
本記事の技術的内容は、2026 年 9 月時点の Box 公式サポート / Box Developer ドキュメントおよび Netskope 公式ドキュメント（Netskope Knowledge Portal）に基づいています。UI 名称・メニュー配置はリリースにより変更される可能性があります。
