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

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

## Що таке 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](https://www.zevshost.net/uk/kb/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](https://www.zevshost.net/uk/kb/cloudflare-tunnel/), коли публічна IP-адреса не потрібна
3. налаштувати identity-провайдера або One-time PIN для входу
4. описати політику за email, групою і країною запиту
5. видати 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 має сенс, коли потрібна групова політика або єдиний вхід одразу в кілька захищених застосунків.

---

Джерело: https://www.zevshost.net/uk/kb/cloudflare-zero-trust-access/