Що таке Cloudflare Access і навіщо він адмінці
Cloudflare Access ставить перевірку особи перед origin-сервером: користувач відкриває адресу панелі, бачить форму входу Cloudflare і отримує доступ лише після підтвердження через пошту, Google-акаунт або корпоративний SSO. До origin запит доходить вже з готовим рішенням "пускати чи ні".
Для адмін-панелей на VDS це закриває типову діру: phpMyAdmin, панель керування або Git-хук висять на публічному порту, і їх знаходять сканери за першу добу. Access прибирає панель з публічної зони, залишаючи перевірку особи перед Cloudflare, а не на самому сервері.
Чим Access відрізняється від VPN і звичайного firewall
Різниця в тому, де саме відбувається перевірка і що видно ззовні до моменту входу.
| Критерій | VPN | Cloudflare 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-клієнті та окремому порту на сервері.
- винести адмінку на окремий піддомен і завести застосунок в Access
- сховати origin через Cloudflare Tunnel, коли публічна IP-адреса не потрібна
- налаштувати identity-провайдера або One-time PIN для входу
- описати політику за email, групою і країною запиту
- видати Service Token скриптам деплою замість спільного пароля
Часті питання
Що побачить відвідувач, якщо випадково потрапить на піддомен адмінки без доступу в Access?
Замість панелі керування чи форми входу застосунку він побачить сторінку авторизації Cloudflare із запитом email або вибором identity-провайдера. Сам origin-сервер запит навіть не отримає, поки перевірку особи не пройдено, тож вміст адмінки та сам факт її існування лишаються прихованими від стороннього спостерігача.
Що станеться, якщо забули видати Service Token скрипту деплою після увімкнення Access на домені?
Запит скрипта дійде до форми входу Cloudflare так само, як від звичайного браузера, і отримає редирект замість очікуваної відповіді API — деплой чи хук обірветься з помилкою авторизації. Рішення просте: випустити окремий Service Token саме для цього скрипта і прописати його заголовки в запиті.
Чи захищає Cloudflare Access від атак на сам застосунок, а не лише від стороннього входу?
Ні, Access перевіряє особу перед видачею доступу до адреси, але не аналізує вміст запитів після входу і не замінює захист застосунку від вразливостей на кшталт SQL-ін'єкції. Це бар'єр входу, а не WAF: вразливість усередині самої адмінки лишається доступною будь-кому, хто пройшов перевірку особи законно.
Як бути, якщо команда не користується Google Workspace чи іншим корпоративним identity-провайдером?
Підійде One-time PIN без зовнішнього провайдера: Cloudflare надсилає одноразовий код на вказаний email при кожній спробі входу, і цього достатньо для невеликої команди. Підключати Google, GitHub чи Azure AD має сенс, коли потрібна групова політика або єдиний вхід одразу в кілька захищених застосунків.