← Cloudflare One / cloudflare-one / access-controls / applications

Выберите тип приложения

Cloudflare Access находится перед вашими приложениями и проверяет каждый запрос по вашим политикам Access, прежде чем пропустить пользователя. Он поддерживает несколько типов приложений, каждый из которых рассчитан на свой сценарий использования. Выбор зависит от того, где размещено ваше приложение, как к нему подключаются пользователи и какой уровень контроля над сессиями и авторизацией вам нужен.

Большинство команд начинают с self-hosted приложений, а затем со временем расширяются до SaaS-приложений, инфраструктурных целей или их сочетания.

В следующей таблице перечислены основные различия между типами приложений. Подробные инструкции по настройке приведены в разделе для каждого типа.

Локально размещённые приложения являются самым универсальным типом приложений и составляют большинство развёртываний Access. Под локально размещённым приложением понимается любой ресурс, трафик которого вы сами направляете, например: общедоступный веб-сайт в DNS Cloudflare, не веб-служба в вашей приватной сети, подключённая через Cloudflare Tunnel, или Worker, запущенный в Cloudflare.

Локально размещённые приложения используют полный набор возможностей движка политик Access, включая управление сессиями, токены приложений, принудительную повторную аутентификацию, проверки состояния устройства и группы поставщика идентификации.

Если ваше приложение уже доступно из интернета, а его DNS управляется через Cloudflare (или используется частичная настройка CNAME, при которой DNS размещен в другом месте, но трафик проксируется через Cloudflare), можно разместить Access перед ним, сопоставив имя хоста приложения. Cloudflare проксирует запрос, показывает страницу входа и передает трафик на ваш источник только после того, как пользователь пройдет проверку политиками Access.

Это самый распространённый вариант начала работы. Вам не нужно ничего устанавливать на устройстве пользователя: аутентификация полностью происходит в браузере.

Инструкции по настройке см. в Добавьте публичное локально размещённое приложение.

Вы также можете использовать локально размещённые приложения для защиты ресурсов в вашей частной сети, указывая конкретные частные IP-адреса, имена хостов или диапазоны CIDR (блоки IP-адресов, например 10.0.0.0/8) с присоединённым портом или диапазоном портов. Это основной способ построения сетевого доступа Zero Trust в Cloudflare.

Приложения приватной сети требуют, чтобы пользователи направляли трафик через Cloudflare, как правило запустив Cloudflare One Client на своём устройстве. Вам также потребуется подключить свою частную сеть к Cloudflare с помощью Cloudflare Tunnel или Cloudflare Mesh.

С приложениями приватной сети вы задаёте те же типы политик Access, что и для публичных приложений, но применяете их к приватным адресатам. Это даёт вам детализированный, учитывающий идентичность контроль над тем, кто и к чему может обращаться в вашей сети: такой подход заменяет широкий доступ на уровне VPN политиками для отдельных приложений или сервисов. Политики Access можно использовать повторно, поэтому одну и ту же политику можно применять к нескольким приложениям.

Инструкции по настройке см. в Добавьте частное локально размещённое приложение.

Локально размещённые приложения также могут защищать Cloudflare Worker напрямую по имени, а не по имени хоста или IP-адресу. Если в качестве назначения выбран Worker, можно защитить его вместе со всеми предварительными развёртываниями либо только предварительные развёртывания.

Это самый безопасный и простой способ разместить аутентификацию перед Worker. Вместо того чтобы настраивать отдельные маршруты для Worker и управлять аутентификацией на уровне маршрута, вы привязываете весь Worker (и, при необходимости, его preview-развёртывания) к приложению Access. Любой запрос к Worker по любому маршруту сначала проходит через Access.

Инструкции по настройке специально для Workers см. в Cloudflare Access for Workers.

Локально размещённые приложения поддерживают клиентский cloudflared аутентификацию. Пользователи могут установить cloudflared на своём устройстве и выполнить cloudflared access login <hostname> из командной строки для аутентификации через ваши политики Access без установленного Cloudflare One Client. Это удобно для SSH-сессий, вызовов API и других сценариев работы из командной строки, где вход через браузер неудобен.

Подробнее см. в аутентификация cloudflared.

Приложения SaaS предназначены для сторонних инструментов, которые использует ваша организация, но не размещает их у себя, например Salesforce, Atlassian, Slack или Workday. Для приложения SaaS вы настраиваете Cloudflare Access в качестве провайдера единого входа (SSO) для стороннего сервиса по протоколу SAML или OIDC, двум наиболее распространённым протоколам федерации идентификации.

Когда пользователи входят в SaaS-приложение, они перенаправляются на Cloudflare. Cloudflare перенаправляет их к настроенному поставщику идентификации для аутентификации, а затем проверяет аутентифицированного пользователя на соответствие политикам Access. Если пользователь проходит обе проверки, Cloudflare выдает SaaS-приложению подписанные учетные данные (утверждение SAML или токен OIDC), подтверждающие личность пользователя.

Используйте приложение SaaS, если вы хотите:

• Обеспечивайте единообразные политики Access для сторонних инструментов. Применяйте те же требования к идентификации, состоянию устройства и местоположению, которые используются для внутренних приложений, и к внешним инструментам SaaS.
• Агрегация нескольких поставщиков идентификации. Cloudflare умеет федерировать аутентификацию между несколькими поставщиками идентификации (IdP), поэтому вы можете заменять или добавлять поставщиков идентификации, не перенастраивая каждое приложение SaaS по отдельности. При прямой интеграции SSO это, как правило, невозможно.
• Примените элементы управления, специфичные для Cloudflare. Задавайте требования, которые ваш SaaS-провайдер не может проверить самостоятельно, например требование использовать клиент Cloudflare One или пройти проверку состояния устройства перед предоставлением доступа к SaaS-инструменту.

Для приложений SaaS сторонний инструмент должен поддерживать федерацию SAML или OIDC. Не все инструменты SaaS предлагают такую поддержку, а некоторые ограничивают количество интеграций SSO или набор функций, доступных через федеративную аутентификацию. Информацию о совместимости с SSO уточняйте в документации поставщика SaaS.

Инструкции по настройке см. в Приложения SaaS.

Приложения Infrastructure обеспечивают контроль доступа с учётом протокола для серверов и инфраструктурных целевых объектов, доступных как через публичное имя хоста, так и через частную сеть. В отличие от локально размещённых приложений, которые оценивают, может ли пользователь достичь пункта назначения, приложения Infrastructure также контролируют, что пользователь может делать после подключения: под какими именами пользователей он может пройти аутентификацию, к каким портам может получить доступ и какие команды может выполнять.

Для приложений Infrastructure требуется Cloudflare One Client. Для целевых объектов в вашей частной сети также необходимо подключить сеть к Cloudflare через Cloudflare Tunnel или Cloudflare Mesh.

Используйте инфраструктурное приложение, если вам нужно:

• Авторизация на уровне протокола. Определяйте политики, которые предоставляют определённым пользователям доступ к конкретным портам и именам пользователей на целевом сервере.
• Логирование команд. Все SSH-сессии и команды регистрируются для целей соответствия требованиям и аудита. Вы можете экспортировать журналы в сервис хранения данных или SIEM-систему с помощью Logpush.
• Краткосрочные сертификаты. Исключите долгоживущие SSH-ключи, аутентифицируя пользователей с помощью сертификатов с коротким сроком действия. Это устраняет риск того, что украденный или забытый ключ предоставит постоянный доступ к вашим серверам.

Приложения Infrastructure поддерживают SSH. Вы всё равно можете использовать локально размещённые приложения для защиты доступа к серверам по другим протоколам (включая SSH), но инфраструктурные приложения являются единственным способом дополнительно контролировать авторизацию пользователей.

Инструкции по настройке см. в Добавьте инфраструктурное приложение.

Объекты Bookmark не защищены Access. Bookmark представляет собой ссылку на любой URL, который вы хотите отобразить в App Launcher наряду с другими вашими приложениями. Вы можете назначать политики Access закладкам, но эти политики лишь определяют, отображается ли плитка закладки в App Launcher, они не защищают саму целевую ссылку.

Используйте объекты Bookmark, чтобы предоставить пользователям единый портал, где они смогут найти все нужные инструменты, включая внешние приложения, не интегрированные с Cloudflare.

Инструкции по настройке см. в Добавление закладок.

Устаревший тип приложения для частной сети создаёт политики Gateway Network для управления доступом к частному IP-адресу. При добавлении устаревшего приложения для частной сети Cloudflare создаёт два правила Gateway: одно правило Allow и одно правило Block. Это связано с тем, что политики Gateway Network не запрещают трафик по умолчанию (в отличие от политик Access, которые требуют явного правила Allow, прежде чем пользователь сможет получить доступ к защищённому приложению).

Устаревшие приложения для частных сетей не поддерживают управление на уровне сессии, токены приложений и полный набор функций, доступных в политиках Access. Этот тип приложения признан устаревшим для новых клиентов и остаётся доступным для уже существующих клиентов.

Если вы сейчас используете устаревшие приложения для частной сети, настоятельно рекомендуем перейти на локально размещённые приложения частной сети для более полного контроля политик и управления сеансами.

Подробнее см. в Приложения приватной сети (устаревшие).