はじめに
「社外から社内システムに入る手段がVPNしかない」「VPN装置の脆弱性対応に追われている」——中小規模の情シスでよくある悩みです。
本記事では、Cloudflare Zero Trust を使って、VPNを使わずに社外から社内リソース（社内Web・RDPなど）へ安全にアクセスする ZTNA（Zero Trust Network Access） を構築する手順をまとめます。実際に自社導入し、社外からのRDP接続まで動作確認した内容をベースにしています。
ポイントは次の3つです。
- 50ユーザーまで無料（Freeプラン）で始められる
- 社内側のポート開放が不要（cloudflaredトンネルがアウトバウンドで張る）
- 考え方は「既定は全拒否、許可だけを足す」。アプリ単位で「誰が・どんな条件で」を定義する
前提
- Cloudflareアカウント（one.dash.cloudflare.com でZero Trustを有効化）
- IdP：Microsoft Entra ID（他のIdPでも可。本記事はEntra ID前提）
- 公開したい社内リソース（社内WebアプリやRDP対象のPCなど）
- 社内にcloudflaredを常駐させられるマシン1台（Linuxサーバ推奨。Windowsでも可）
全体像
[社外端末] --WARP--> [Cloudflareエッジ] <--Tunnel(アウトバウンド)-- [社内 cloudflared]
| |
Access(Entra ID + MFA で認可) 社内Web / RDP / ファイルサーバ
利用者はWARPクライアントで接続し、Entra ID＋MFAで認証。Accessポリシーで許可されたアプリ・IP帯だけに到達できます。
Step 1. Zero Trust を初期化する
- one.dash.cloudflare.com を開き、チーム名（team name） を決めます
- プランは Free（50ユーザーまで）を選択
チーム名は https://<チーム名>.cloudflareaccess.com として利用者のログイン先URLになり、後述のEntra ID連携のリダイレクトURIにも使います。後から変えにくいので組織名ベースで慎重に決めるのがおすすめです。
確認： Zero Trustダッシュボードが開き、左メニューに Settings / Access / Networks 等が表示される。
Step 2. IdP（Entra ID）を連携する
Entra側：アプリ登録
- Entra管理センター → アプリの登録 → 新規登録
- リダイレクトURIに以下を設定（Web）
https://<チーム名>.cloudflareaccess.com/cdn-cgi/access/callback
- クライアントシークレットを発行（有効期限をカレンダーに控えておく）
- APIのアクセス許可に
openid/profile/emailを付与。Entraのグループをポリシー条件に使いたい場合はGroupMember.Read.All（管理者の同意が必要）も追加
Cloudflare側
- Zero Trust → Settings → Authentication → Login methods → Add new → Azure AD（Microsoft Entra ID）
- アプリケーション（クライアント）ID／クライアントシークレット／ディレクトリ（テナント）ID の3点を入力
- グループ条件を使う場合は「Support Groups」を有効化
- Test ボタンで疎通確認
確認： Login methodsにEntra IDが表示され、TestでEntraのサインイン→成功画面まで通る。
Step 3. デバイス（WARP）を登録する
- Settings → WARP Client のデバイス登録ポリシー（Device enrollment permissions）で、登録を許可する条件を設定（例：自社メールドメイン）
- 利用者端末に WARPクライアント をインストールし、設定画面から Zero Trustにログイン（Step 1のチーム名を入力 → Entra ID＋MFAで認証）
確認： WARPが「接続済み」になり、ダッシュボードの My Team → Devices に端末が出てくる。
Step 4. 社内リソースへの経路（トンネル）を用意する
社内側にcloudflaredトンネルを立てます。ダッシュボード管理型（リモート管理）が運用しやすいのでこちらを使います。
- Networks → Tunnels → Create a tunnel → Cloudflared でトンネルを作成
- 画面に表示されるコネクタのインストールコマンドを社内マシンで実行（例：Ubuntu）
# ダッシュボードに表示されるトークン付きコマンドをそのまま実行
sudo cloudflared service install <トンネルトークン>
# 稼働確認
systemctl status cloudflared
- RDPやファイルサーバなどIPで届かせたいものは、トンネル設定の Private Network タブで社内IP帯（例：
192.168.10.0/24）を登録
確認： Tunnelsの一覧でステータスが HEALTHY、Private Networkに社内IP帯が表示される。
アウトバウンド443で張るため、社内FWのポート開放やNAT設定は不要です。
Step 5. アクセスポリシーを作成する
Access → Applications → Add an application から登録します。
- 社内Webアプリ → Self-hosted（公開ホスト名を割り当て）
- RDP・SMBなどIP直アクセス → Private Network（対象IP/CIDRを指定）
ポリシー（Allow）の条件例：
- 対象：自社メールドメイン or Entraの特定グループ
- Require：MFA必須（Authentication Method）、デバイス登録済み（WARP enrolled）
「既定は全拒否、許可だけを足す」が原則です。最初に「どのアプリに・誰が・どんな条件で」を一覧化してから設定すると迷いません。全社一括の広い許可を作るより、アプリ単位で最小限に絞るのがZTNAの肝です。
Step 6. 動作確認（社外から）
社外ネットワーク（テザリング等）の端末で確認します。
- WARP接続 → ブラウザでEntra＋MFAログイン
- 許可したアプリに到達できること、許可していないユーザー・アプリはブロックされることの両方を確認
RDPの例（VPNなしで社外→社内PC）：
rem WARP接続後、社内PCのプライベートIPへそのままRDP
mstsc /v:192.168.10.21
ログイン時のユーザー名は、ドメイン未参加のPCでは次の形式で入力します。
コンピュータ名\ユーザー名
つまずきポイントと対処
1. 社内IPにそもそも到達しない（Split Tunnels）
WARPは既定でRFC1918のプライベートIP帯を**除外（Exclude）**しています。Settings → WARP Client → Device settings profile → Split Tunnels で、対象の社内IP帯（例：192.168.10.0/24）を除外リストから外す（または除外範囲を狭める）必要があります。ここが一番ハマりやすいポイントです。
2. RDPで認証に失敗する
ドメイン未参加PCは コンピュータ名\ユーザー名 形式で入力します。対象PC側でRDPが有効になっているかも確認してください。
3. ログインできない／端末が登録できない
Step 2のIdP連携Testが成功しているか、Step 3のデバイス登録ポリシー（許可メールドメイン等）に該当しているかを確認します。クライアントシークレットの有効期限切れも定番の原因です。
4. 社内にいるのにWARPが切れる・誤検知する
マネージドネットワーク（社内Wi-Fi検出で自動オフにする設定）を入れている場合は、検出条件（TLS証明書のフィンガープリント等）を見直します。
完了チェックリスト
- Zero Trustを初期化し、チーム名を決めた（Free 50席）
- Entra IDをIdP連携し、Testが成功した
- WARPで端末を登録した（Devicesに表示）
- cloudflaredトンネルがHEALTHY＋プライベートネットワーク登録済み
- アプリ単位のアクセスポリシー（MFA必須等）を設定した
- 社外から許可アプリに到達でき、未許可がブロックされることを確認した
まとめ
VPN装置の運用・脆弱性対応から解放されつつ、「全社に広く開ける」のではなく「アプリ単位で最小限を許可する」構成が、無料枠の範囲で実現できます。まずは1アプリ（社内Web1つ、またはRDP対象PC1台）から小さく始めて、動作確認のうえ横展開するのがおすすめです。
株式会社ブレインディレクションは、ITソリューション・生成AI活用・クラウド/セキュリティ支援を行う大阪のIT企業です（ISMS取得済）。 https://www.brain-d.jp