Cloudflare Accessで認証を追加する

《 Cloudflare完全ガイド 目次へ 》

前のページで、NASをポート開放なしでインターネットに公開しました。ただし最後に書いたとおり、いまの状態はURLを知っている人なら誰でもDSMのログイン画面まで到達できます。ポート開放をやめたのに、ログイン画面が世界に晒されているのでは、守りとしては中途半端です。

このページでは、その手前にCloudflare Accessを置きます。設定が終わると、認証を通らない人にはDSMのログイン画面すら表示されません。攻撃者から見れば、そのURLの向こうに何があるのかすら分からない状態になります。

概念は第3章のCloudflare Accessで説明しました。ここでは実際に設定します。所要時間は10分ほどです。

このページで分かること

  • Accessでアプリケーションを登録する手順
  • ポリシーの組み方（誰を通し、誰を止めるか）
  • IdPを用意しなくても使えるOne-time PINでの認証
  • 認証したのに「ログイン画面が二重に出る」ときの考え方
  • スマホアプリやAPIが繋がらなくなったときの対処

Accessを置くと何が変わるか

まず、設定前と設定後の違いを整理します。

Accessを置く前と置いたあと
図1：Accessを置く前と置いたあと

設定前：誰でもDSMのログイン画面に到達できる。攻撃者はそこにIDとパスワードを何度でも投げ込める。DSMに脆弱性が見つかれば、その瞬間から危険にさらされる。

設定後：認証を通っていない人には、Cloudflareのログイン画面しか見えない。NASのソフトウェアにはリクエストが1つも届きません。DSMに脆弱性が見つかっても、そもそも攻撃者はそこに到達できません。

この「アプリケーションに届く前に止める」という点が、Accessの本質的な価値です。

手順1：アプリケーションを登録する

Cloudflareのダッシュボードで Zero Trust（Cloudflare One）→ Access controls → Applications を開き、Create new application を選びます。

種類を聞かれたら Self-hosted and private（自分で運用しているアプリ）を選び、Add public hostname に進みます。

主な設定項目は次のとおりです。

項目 入力例 説明
Application name NAS 管理画面 管理用の名前。何でも構いません
Session Duration 24 hours 一度認証したら何時間有効にするか
Public hostname nas + example.com 前のページで公開したホスト名
Identity providers One-time PIN など 使わせたい認証方法

Session Duration は、使い勝手と安全性の綱引きです。短くすると頻繁に認証を求められ、長くすると端末を盗まれたときのリスクが伸びます。自宅NASなら24時間〜1週間、業務システムなら数時間〜1日が目安です。

ホスト名はワイルドカードも使えます。*.example.com と指定すれば、そのドメインのサブドメイン全体をまとめて守れます。

手順2：ポリシーを作る

登録しただけでは、まだ誰も通れません。Accessは既定ですべて拒否だからです。公式ドキュメントにも「すべてのAccessアプリケーションは既定で拒否であり、利用者はAllowポリシーに一致して初めて許可される」と明記されています。

そこで、通す条件を書きます。最小の構成は次のとおりです。

  • Action（アクション）：Allow
  • Rule type：Include
  • Selector：Emails
  • Value：自分のメールアドレス

これで「このメールアドレスの持ち主だけ通す」という意味になります。

家族やチームで使うなら、次のような書き方が便利です。

やりたいこと Selector 値の例
特定の数人だけ通す Emails [email protected], [email protected]
会社のドメイン全体を通す Emails ending in @example.co.jp
特定の国からだけ通す Country 日本
グループで管理する Access groups 事前に作ったグループ

条件の組み合わせ方

ルールの種類は3つあり、この違いが最初は分かりにくいところです。

  • Include（含む）：どれか1つに当てはまれば通る（OR）
  • Require（必須）：すべて満たさないと通らない（AND）
  • Exclude（除外）：当てはまったら通さない

たとえば「会社のドメインのメールアドレスで、かつ日本からのアクセス」なら、Include に Emails ending in @example.co.jp、Require に Country 日本 と書きます。

手順3：認証方法を決める

「認証する」といっても、Cloudflareがパスワードを持つわけではありません。Accessは身元の確認を外部に委ねます。委ねる先がIdP（アイデンティティプロバイダー）です。

One-time PIN：何も用意しなくていい方法

まず試すなら One-time PIN が最も手軽です。IdPの設定が一切要りません。

  1. 利用者がURLを開くと、メールアドレスの入力欄が出る
  2. 入力すると、そのアドレス宛にワンタイムのコードが届く
  3. コードを入力すると通過できる

ポリシーに書いたメールアドレス以外を入力しても、コードは意味を持ちません。手軽さのわりに、しっかり防御になります。

GoogleやGitHubアカウントを使う

普段使っているアカウントで認証させたい場合は、IdPを追加します。Settings → Authentication から設定でき、Google・Microsoft Entra ID・GitHub・Okta・OneLoginなど主要なサービスに対応しています。

Googleアカウントを使う設定にすると、利用者は「Googleでログイン」を押すだけで通過できます。すでにブラウザでGoogleにログインしていれば、クリック1回で終わります。

認証が二重になることについて

設定が終わると、nas.example.com を開いたときの流れはこうなります。

  1. Cloudflareの認証画面が出る → 通過する
  2. DSMのログイン画面が出る → NASのIDとパスワードでログインする

「二重で面倒だ」と感じるかもしれませんが、これは正しい状態です。Accessが守っているのは「そこに到達できるか」であって、NAS自体のログインを肩代わりするものではありません。多層防御として、両方あるほうが安全です。

DSMのログインを省略したい場合、SAMLに対応したDSMのSSO設定と組み合わせる方法もありますが、最初は素直に二段階のままにしておくことをおすすめします。

手順4：動作を確認する

必ずプライベートウィンドウで確認してください。 普段使っているウィンドウでは、すでに認証済みのCookieが残っていて、正しく守られているか分かりません。

確認すべきことは2つです。

  1. プライベートウィンドウで https://nas.example.com を開くと、DSMではなくCloudflareの認証画面が出る
  2. ポリシーに書いていないメールアドレスでは通過できない

1つめが「DSMのログイン画面が出てしまう」場合、ホスト名の指定が違っているか、設定が反映されていません。数十秒待ってから、ホスト名の綴りを確認してください。

つまずきやすいところ

Accessのポリシー評価順とアクション
図2：Accessのポリシー評価順とアクション

スマホアプリやAPIが繋がらなくなる

最も多いトラブルがこれです。 Accessはブラウザでの認証を前提にしているため、ブラウザ以外からのアクセスは認証画面を表示できず、そのまま弾かれます。

  • Synology の DS file・DS photo などのモバイルアプリ
  • WebDAV接続
  • 外部サービスからのWebhook
  • 自作スクリプトからのAPI呼び出し

対処は3つあります。

  • サービストークンを使う：Cloudflareが発行するクライアントIDとシークレットを、リクエストのヘッダーに付けて送ります。ポリシーのアクションを Service Auth にして、そのトークンを許可します。スクリプトやサーバー間の連携に向いています
  • 特定のパスだけBypassする：Webhookの受け口など、公開せざるを得ない経路に限って、アクションを Bypass にしたポリシーを作ります。ただしその経路はまったく無防備になるので、範囲は最小限にしてください
  • アプリ用に別のホスト名を用意する：app-nas.example.com を作り、そちらにはAccessをかけず、代わりにWARP経由でのみ届くプライベートネットワーク構成にする方法もあります

ポリシーの評価順を理解する

複数のポリシーがあるとき、評価される順番が決まっています。

  1. Bypass と Service Auth が先に、上から順に評価される
  2. その後に Block と Allow が、上から順に評価される
  3. AllowかBlockに一致した時点で、評価は終わる

「Blockを書いたのに通ってしまう」場合、上に広いBypassがある可能性を疑ってください。

オリジンを直接叩かれる経路を塞ぐ

Accessは、Cloudflareを経由するアクセスを守ります。逆に言えば、Cloudflareを迂回してサーバーに直接届く経路が残っていれば、Accessは意味を失います。

前のページの構成なら、NASはTunnel経由でしか外に出ていないので、この心配はありません。TunnelとAccessの組み合わせが定番とされるのは、この点が構造的に解決されるからです。

一方、レンタルサーバーのようにIPアドレスが分かる場所で運用している場合は、サーバー側でCloudflare以外からのアクセスを拒否する設定（Authenticated Origin Pulls など）を併用する必要があります。

初心者が注意するポイント

  • 自分を締め出さないように：ポリシーのメールアドレスを打ち間違えると、自分も入れなくなります。Cloudflareのダッシュボード自体は別の認証なので復旧できますが、慌てないよう最初の確認はプライベートウィンドウで行ってください
  • 無料枠は50ユーザーまで：Cloudflare OneのFreeプランの範囲で、Accessの基本機能はひととおり使えます（2026年8月時点）。個人・家庭・小さなチームなら十分です
  • メールアドレスは「認証した人」を指す：ポリシーに書いたアドレスの持ち主が、そのメールを受け取れる状態であることが前提です。退職者のアドレスを消し忘れると、そのまま権限が残ります
  • Session Durationを長くしすぎない：便利ですが、端末の紛失時にそのまま生き続けます。業務利用なら1日以内を推奨します
  • ログを見る習慣を付ける：Access のログには、いつ誰が認証を試み、通ったか弾かれたかが残ります。不審なアクセスの兆候はここに出ます
  • アプリを追加するたびにポリシーを見直す：ワイルドカードで広く守っていると、あとから追加したサブドメインが意図せず含まれる（あるいは漏れる）ことがあります

関連サービス

まとめ

  • Accessを置くと、認証を通らない人にはアプリのログイン画面すら表示されない。攻撃はアプリに届く前に止まる
  • 設定は「アプリケーションを登録する → ポリシーを作る → 認証方法を決める」の3段階
  • Accessは既定ですべて拒否。Allowポリシーに一致した人だけが通る
  • One-time PINを使えば、IdPを用意しなくてもすぐ始められる
  • Cloudflareの認証とアプリ自身のログインが二重になるのは正しい状態。多層防御として意味がある
  • スマホアプリやAPIが繋がらなくなったら、サービストークン・限定的なBypass・別ホスト名のいずれかで対処する
  • ポリシーは Bypass と Service Auth が先に評価される。「Blockが効かない」ときはここを疑う
  • TunnelとAccessの組み合わせは、オリジンへの直接アクセス経路が構造的に存在しないため相性がよい

前のページと合わせて、ポート開放なしで公開し、認証を通った人だけが使える自宅サーバーが完成しました。これはCloudflareの機能を最も実感しやすい構成の1つです。

ここまでの3ページは、既存のものを守る話でした。次のページからは、Cloudflareの上で自分でものを作る話に移ります。まずはWorkersのHello Worldからです。

次に読む

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。

ホーム
Cloudflare完全ガイド
タイトルとURLをコピーしました