К основному содержимому

Cloudflare Access: защита админки по модели Zero Trust

Cloudflare · 29.09.2026 · 4 мин чтения
Иллюстрация к статье «Cloudflare Access: защита админки по модели Zero Trust»

Что такое 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 скриптам деплоя вместо общего пароля

Частые вопросы

Что увидит посетитель, если случайно попадёт на поддомен админки без доступа в 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 имеет смысл, когда нужна групповая политика или единый вход сразу в несколько защищённых приложений.

Статья помогла?
← Назад в базу знаний Задать вопрос поддержке