# 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/ru/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/ru/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/ru/kb/cloudflare-zero-trust-access/