Що таке 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 скриптам деплою замість спільного пароля