До основного вмісту

Cloudflare Access: захист адмінки за моделлю Zero Trust

Cloudflare · 29.09.2026

Що таке Cloudflare Access і навіщо він адмінці

Cloudflare Access ставить перевірку особи перед origin-сервером: користувач відкриває адресу панелі, бачить форму входу Cloudflare і отримує доступ лише після підтвердження через пошту, Google-акаунт або корпоративний SSO. До origin запит доходить вже з готовим рішенням "пускати чи ні".

Для адмін-панелей на VDS це закриває типову діру: phpMyAdmin, панель керування або Git-хук висять на публічному порту, і їх знаходять сканери за першу добу. Access прибирає панель з публічної зони, залишаючи перевірку особи перед Cloudflare, а не на самому сервері.

Чим Access відрізняється від VPN і звичайного firewall

Різниця в тому, де саме відбувається перевірка і що видно ззовні до моменту входу.

КритерійVPNCloudflare Access
Що видно ззовніВідкритий VPN-порт на серверіЗвичайний HTTPS-домен без зайвих портів
КлієнтОкремий застосунок і профільБраузер, без встановлення клієнта
Гранулярність правилДоступ до всієї підмережі одразуОкрема політика на кожен застосунок

Як підключити застосунок у панелі Zero Trust

Застосунок створюється в Zero Trust Dashboard у розділі Access → Applications. Там вказується піддомен адмінки, наприклад admin.example.com, і шлях до origin-сервера.

cloudflared tunnel login
cloudflared tunnel create admin-panel
cloudflared tunnel route dns admin-panel admin.example.com

Коли сервер не має публічної IP-адреси, застосунок варто завести через Cloudflare Tunnel — тоді порт адмінки взагалі не відкривається назовні.

Політики доступу: кому і за яких умов

Політика Access — це набір умов, які перевіряються перед видачею сесії. Умови можна комбінувати в одному правилі:

  • email або домен пошти — доступ лише співробітникам компанії
  • належність до групи identity-провайдера
  • країна запиту за даними Cloudflare
  • перевірка пристрою через WARP-клієнт та його конфігурацію
  • обмеження за часом дії сесії, від години до тижня

Налаштування входу через identity-провайдера

Access підтримує вхід через Google Workspace, GitHub, Azure AD і одноразовий PIN-код на пошту без зовнішнього провайдера. Для невеликої команди достатньо One-time PIN: лист із кодом приходить на вказану адресу при кожній спробі входу.

Для команди зі спільним Google-акаунтом варто підключити Google як identity-провайдера в розділі Settings → Authentication і вказати перелік дозволених доменів пошти.

Service Tokens для API і CI/CD

Коли до захищеної адреси звертається не людина, а скрипт деплою чи моніторинг, вхід через форму не підходить. Для цього в Access є Service Tokens — пара Client ID і Client Secret, яка передається заголовками запиту.

curl -H "CF-Access-Client-Id: <client_id>" \
     -H "CF-Access-Client-Secret: <client_secret>" \
     https://admin.example.com/deploy-hook

Токен прив'язується до окремої політики, і його легко відкликати, не чіпаючи правила для решти користувачів.

Підсумок: перелік дій перед увімкненням Access

Access закриває вхід у панель перевіркою особи перед origin, без потреби у VPN-клієнті та окремому порту на сервері.

  1. винести адмінку на окремий піддомен і завести застосунок в Access
  2. сховати origin через Cloudflare Tunnel, коли публічна IP-адреса не потрібна
  3. налаштувати identity-провайдера або One-time PIN для входу
  4. описати політику за email, групою і країною запиту
  5. видати Service Token скриптам деплою замість спільного пароля
← Назад до бази знань Поставити питання підтримці