← Справочные архитектуры / reference-architecture / design-guides

Внедрение архитектуры Zero Trust в вашем стартапе

Большая часть документации Cloudflare (как и документации большинства других поставщиков в этой сфере) написана исходя из предположения, что переход на продукты Zero Trust потребует отказа от чего-то уже существующего. Если у вас пока ничего не построено или нет инструмента, решающего задачи вашей команды, такой подход может сбивать с толку и вызывать отчуждение. Особенно уязвимы новые стартапы: сосредоточив все силы на запуске бизнеса, сложно и долго разбираться в документации, ориентированной на предприятия, проходящие трансформацию сети.

В этом руководстве объясняется, как с помощью Cloudflare заложить основу архитектуры Zero Trust на раннем этапе формирования практик безопасности, работы с сетью и DevOps, чтобы построить устойчивый и масштабируемый бизнес на принципах безопасности Zero Trust.

Общие принципы построения «бизнеса» кардинально изменились. Двадцать лет назад это могло выглядеть как аренда офиса (или гаража), закупка аппаратной инфраструктуры, серверов и пользовательских машин, с которых начиналась разработка. По мере роста компании добавлялись аппаратные межсетевые экраны и защитные устройства, чтобы создать корпоративный периметр и защитить то, что в основном существовало в одном месте. О развитии сетевых и защитных практик написано уже немало, поэтому подробно останавливаться на этом мы не будем: важно понимать, почему «новая» модель имеет значение для вашего стартапа по мере его роста.

Скорее всего, сегодня большая часть вашей инфраструктуры размещена у публичного облачного провайдера. Большая часть кода отправляется и проверяется с помощью распространённых инструментов управления репозиториями, большинство ваших разработчиков пишут код на машинах с MacOS или Linux и, вероятно, активно полагаются на ту или иную форму контейнеризации для локальной разработки. В рамках такой модели принципы безопасности Zero Trust остаются столь же актуальными, хотя и гораздо более достижимыми, по мере того как ваш бизнес расширяется, охватывая новые сложные функции, подразделения и растущий набор активов и данных.

Cloudflare Zero Trust дает стартапам простой, а иногда и бесплатный, способ выстроить комплексную стратегию Zero Trust, которая будет органично расти вместе с бизнесом.

У Cloudflare уже есть немало материалов о миграции и внедрении продуктов линейки Zero Trust. Этот документ адресован непосредственно техническим основателям и первым инженерам молодых стартапов, которые хотят выстроить основу современной корпоративной сети с современными средствами защиты, начиная с первой строчки кода.

В этом документе рассматриваются:

• Начало работы с практическими возможностями удаленного доступа Zero Trust (ZTNA)
• Определение источников достоверных данных для идентификации и состояния устройств и изучение способов их использования
• Построение сети: традиционное и mesh
• Встраивание Zero Trust во внутренние инструменты
• Анализ угроз в интернете
• Расшифровка TLS и ее значение для ваших целей
• Изучение Zero Trust для ваших SaaS-инструментов
• Управление доступом подрядчиков и клиентов
• Работа с Infrastructure as Code

Некоторые темы, которые прямо не рассматриваются в этом документе:

• Введение в базовую терминологию и концепции Zero Trust
• Рекомендации за или против использования конкретных сторонних поставщиков (хотя в этом документе упоминаются другие поставщики, это сделано исключительно для иллюстрации и не должно восприниматься как официальная рекомендация Cloudflare)
• Подробности о том, почему стоит рассмотреть переход на методологию безопасности Zero Trust (по ссылкам ниже вы найдёте много полезных материалов на эту тему)
• Микросегментация и автономные концепции Zero Trust (могут быть рассмотрены в будущих обновлениях)
• Аутентификация без пароля (это перспективное и активно развивающееся направление, рекомендации по которому мы приведём здесь позже)

Чтобы лучше разобраться в Cloudflare, рекомендуем следующие материалы:

• Что такое Cloudflare? | Сайт ↗ (пять минут на чтение) или видео ↗ (две минуты)
• Блог: Zero Trust, SASE и SSE: базовые концепции для сети нового поколения ↗ (14 минут на чтение)
• Эталонная архитектура: Переход к архитектуре SASE с Cloudflare (три часа на чтение)

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

• Что уже существует и нуждается в устойчивой модели безопасности?
• Если вы уже начали строить инфраструктуру у публичного облачного провайдера, сколько отдельных виртуальных частных облаков (VPC) вы уже создали и как они взаимодействуют между собой? Ещё важнее: как и зачем ваши пользователи обращаются к этим средам?
• Всё ли управление осуществляется через консоль и браузер, или используются инструменты командной строки?
• Настроен ли у вас публичный доступ по IP к некоторым сервисам через HTTPS или SSH?
• Есть ли ресурсы, которые допускают доступ из интернета, хотя должны быть полностью приватными?
• Настроен ли у вас традиционный VPN для удаленного доступа к среде и как он контролируется?

Далее постройте карту своей физической и виртуальной частной инфраструктуры (по сути, всего, что содержит данные компании). Для многих стартапов это может быть просто единственный облачный провайдер. Отметьте все ресурсы в этой среде, к которым обращаются пользователи, другая инфраструктура или публичные и частные API, и опишите назначение каждого сервиса, который регулярно получает трафик. При этом попробуйте ответить на следующие вопросы:

• Это внутренний веб-инструмент, созданный для мониторинга вашего конвейера сборки?
• Это самостоятельно размещённый инструмент аналитики, например Grafana, или вспомогательный сервер метрик, например Prometheus?
• Как пользователи получают доступ к этой службе: через публичный IP-адрес, приватный IP-адрес или локальный путь?
• Могут ли пользователи обращаться к сервису из других облачных сред или VPC? Если да, каким образом установлено соединение?

Когда вы составите полный список существующих ресурсов, он станет инвентаризацией активов для разработки архитектуры Zero Trust. Если вы не знаете, что нужно защищать, защитить это будет сложно, сколько бы средств безопасности у вас ни было.

Полезным третьим шагом может стать ранжирование этих служб по уровню риска на случай взлома, чтобы затем определить детализацию политики безопасности. Например, внутренний инструмент оповещения о статусе сборки может относиться к уровню 3, а рабочая база данных с информацией о клиентах будет уровнем 1. К приложению уровня 3 пользователь может получать доступ со своего личного устройства при условии соблюдения требований контроля идентификации, тогда как приложение уровня 1 может требовать доступа только с корпоративного устройства и использования определённого вида многофакторной аутентификации (MFA).

Многие стартапы, использующие Cloudflare, приходят к модели безопасности Zero Trust под влиянием внешних сторон: инвесторов, партнёров, поставщиков, риск-аналитиков или специалистов по комплаенсу. Даже если проект или оценка инициированы извне, вы всё равно можете сформулировать общие цели, чтобы обеспечить измеримый и желаемый эффект.

Вот какие цели чаще всего называют наши клиенты:

• Обеспечить нашим пользователям простой и безопасный доступ к внутренним инструментам
• Встраивайте безопасность в конвейер разработки
• Повышайте уровень безопасности, не жертвуя удобством работы пользователей
• Разработка и реализация стратегии использования личных устройств (BYOD)
• Упростите управление сетями и доступом к приложениям
• Защита данных в SaaS-приложениях и в корпоративной сети
• Обеспечение аудируемости («возможность быстро увидеть, что происходит, кто это делает и допустимо ли это»)
• Демонстрация лучших практик безопасности нашим клиентам и конечным пользователям

Также возможно, что ваши цели проще или более тактические, например: внедрить современный инструмент удалённого доступа, безопасно соединить внутренние сети или разрешить подключение к вашему тенанту Gitlab Enterprise только корпоративным устройствам. Какой бы ни была ваша цель, при постановке целей важнее всего определить, что нужно вам сейчас, и соотнести это с тем, что может понадобиться в ближайшей или среднесрочной перспективе. Это особенно важно, если вы планируете значительный рост, ожидаете клиентов со строгими требованиями к проверке безопасности или готовитесь получить новый сертификат соответствия, такой как SOC II или PCI. Чтобы этого добиться, важно с самого начала выбрать поставщика решений Zero Trust, который поможет наращивать дополнительные инструменты и возможности безопасности без экспоненциального роста сложности или затрат.

Постановка целей также важна для расстановки приоритетов. Если вы знаете, что ваша основная цель заключается в том, чтобы выявлять пользователей и защищать все внутренние сервисы решениями безопасности, учитывающими идентификацию, но в течение следующих шести месяцев планируете ограничить использование устройств BYOD приложениями уровня 3, ваша первая цель должна стратегически поддерживать достижение второй. Понимание приоритетов на ближайшие несколько месяцев (с учетом того, что в стартапе все быстро меняется) избавит вас от долгих споров о пересмотре архитектуры и от необходимости пересматривать технические или коммерческие решения с поставщиками, которые подходят на короткий срок, но не на среднесрочную перспективу.

Идентификация лежит в основе любой стратегии Zero Trust. В конечном счете большинство клиентов стремятся использовать единый источник идентификации для аутентификации, проверки и журналирования всех действий пользователя как в «собственных» (размещенных в приватной сети) приложениях, так и в SaaS приложениях. Идентификация (например, через поставщика SSO) затем позволяет добавить дополнительные меры защиты, такие как многофакторная аутентификация или аутентификация, устойчивая к фишингу.

Один из важнейших шагов, которые стоит предпринять на раннем этапе, заключается в том, чтобы приучить пользователей к многофакторной аутентификации. Устойчивые к фишингу варианты MFA, такие как физические ключи, локальные аутентификаторы и биометрическая аутентификация, Cloudflare называет одним из главных факторов в остановка попытки взлома ↗ которая затронула Twilio и другие SaaS-компании в 2022 году.

Когда вы только начинаете работу с Zero Trust, выбор провайдера идентификации (чаще всего это Google Workspace или Microsoft Entra Identity) имеет меньшее значение, чем сама стратегия внедрения. Если у вас есть защищённый каталог, который поддерживает устойчивые к фишингу методы аутентификации и назначен единым источником достоверных данных, у вас уже есть всё необходимое для интеграции с поставщиком Zero Trust, таким как Cloudflare, и для постоянной проверки идентификации как элемента защищённости всех корпоративных инструментов.

Многие каталоги также предлагают решения единого входа (SSO) для прямой интеграции с SaaS-приложениями. Хотя это простой и логичный выбор, во многих корпоративных приложениях интеграция SSO вызывает сложности, а подключение критической массы SaaS-приложений к одному каталогу может привести к зависимости от единственного поставщика. По мере роста организации ваша стратегия управления идентификацией неизбежно будет меняться и развиваться, поэтому важно сохранять гибкость для реагирования на непредвиденные проблемы, например на утечки у поставщиков, подобные тем, что произошли в 2023 году.

Помимо сложностей, связанных с гибкостью, многие поставщики SSO ещё не полностью интегрировали концепции состояния устройства в свою модель «источника достоверных данных». Некоторые поставщики, например Okta, предлагают сертификацию устройства как часть события аутентификации, однако это ограничено продуктом Okta FastPass и не учитывает сигналы от других источников или поставщиков, которые помогли бы точнее определить, что считать корпоративным устройством.

И наконец, не все учётные записи, используемые для доступа к вашим системам, будут принадлежать вам. Вам может понадобиться нанять внешних аудиторов, которым для аутентификации нужны собственные корпоративные учётные записи. Вы можете разрешить подрядчикам использовать существующие учётные записи GitHub для доступа к приватным репозиториям GitHub. Иногда достаточно просто предоставить доступ к ресурсу с низким уровнем риска, например к предварительной версии интерфейса нового продукта, человеку, у которого есть только адрес электронной почты. Поэтому ваше решение Zero Trust должно поддерживать учётные записи за пределами центрального каталога.

Далее в этом документе мы расскажем, как использовать Cloudflare Zero Trust для защиты внутренних приложений, а также как использовать Cloudflare в качестве SSO перед вашими SaaS-приложениями, чтобы обеспечить простую единую защиту везде.

Cloudflare имеет значение в данном случае, поскольку после того как вы определили источник достоверных данных для своего провайдера идентификации, вам понадобятся инструменты для непрерывной аутентификации всех пользователей. Создать и поддерживать такие инструменты сложно, о чем свидетельствует опыт ряда известных технологических компаний, которые в 2023 году отказались от собственных прокси Zero Trust и перешли на Cloudflare, сославшись на сложность управления и невозможность добавления новых функций безопасности.

Cloudflare способен упростить вашу архитектуру, став единой точкой проверки прав доступа для частных приложений, сетей, сервисов разработки и SaaS-приложений. Cloudflare является одним из немногих поставщиков, которые реализуют концепции аутентификации Zero Trust сразу тремя способами: как веб-прокси (сервисы уровня 7), как замену VPN (сервисы уровня 3/4) и как безопасный веб-шлюз.

По мере роста бизнеса и перехода к практическому распределению конечных устройств среди пользователей состояние устройства становится ключевым элементом надёжной стратегии Zero Trust. После проверки состояния идентификации пользователей можно предпринять и другие меры для дальнейшего снижения риска утечки данных. Учтите: даже если пользователь легитимен и у него активен сеанс идентификации, его устройство теоретически может быть заражено, и злоумышленники могут воспользоваться этим (или перехват) их действительную сессию идентификации.

Компании используют device posture, чтобы подтвердить, что соединение исходит от доверенного устройства. Рассмотрим теорию, лежащую в основе device posture, прежде чем перейти к типичным стратегиям и подходам к внедрению. Предположим, у вас есть конфиденциальные данные, размещенные где-то в AWS. Эти данные критически важны для работы бизнеса. Они (справедливо) защищены аутентификацией с учетом идентификации, поэтому вы уверены, что доступ к ним получат только пользователи с корректным identity posture. Все ваши пользователи работают удаленно и подключаются к AWS с Macbook, заранее настроенных с выбранным вами ПО для обнаружения угроз на конечных точках и реагирования на них (EDR). У пользователей, работающих на Macbook с корпоративным EDR-ПО, риск потенциальных взломов ниже, чем при использовании личных ноутбуков для доступа к данным компании. Но как доказать, что ваши пользователи с корректным identity posture только обращаться к вашим критически важным данным с устройств с более низким риском компрометации?

По мере роста вашей службы безопасности и внедрения стратегий и инструментов предотвращения потери данных (DLP) это становится вдвойне важным. Если пользователи теоретически могут получить доступ к конфиденциальным данным без подтверждения надёжности используемого устройства, они могут (намеренно или случайно) обойти ваши инструменты безопасности, что создаёт риск утечки данных или как минимум слепые зоны в видимости и возможности аудита.

Типичные стратегии device posture обычно опираются на сочетание инструмента управления конечными устройствами (например, JAMF, Intune и подобных), корпоративного сертификата и средств защиты, таких как EDR-ПО, установленное на устройстве. Часть такого инструментария может составлять «отпечаток» устройства способом, который при поддержке можно проверить извне. Для реализации контроля доступа Zero Trust с проверкой device posture на устройствах обычно нужно развернуть endpoint-агент от поставщика решения Zero Trust. Затем этот агент «независимо» проверяет утверждение стороннего поставщика, прежде чем применить это состояние устройства в политике. При выборе поставщика важно оценить, насколько часто он способен опрашивать состояние устройства, чтобы соответствовать философии Zero Trust о «непрерывной оценке» состояния.

Когда вы начинаете применять решения сторонних поставщиков для реализации целей Zero Trust, этим поставщикам нужны первичные данные от вас (first-party signals), чтобы помочь принимать оптимальные решения по безопасности. В этом случае Cloudflare становится точкой применения политик не только для идентификации, но и для состояния устройства. Агент Cloudflare на устройстве оценивает владельца устройства и показатели его состояния и использует их вместе с политиками идентификации пользователя, чтобы доступ к конфиденциальным ресурсам предоставлялся только при надлежащей проверке личности и только с соответствующего устройства с приемлемым уровнем защиты.

В модели «старого мира» (её также называют архитектурой безопасности по принципу замка и рва) инфраструктура обычно однородна и защищена межсетевым экраном. Чтобы получить доступ к сетевым ресурсам, пользователи вне офиса (как и другие сторонние лица, поставщики и так далее) должны были подключаться к сети через VPN и межсетевой экран либо использовать другой доступный сетевой маршрут через публичный IP адрес. Сегодня большая часть инфраструктуры находится в облаке, а большинство стартапов изначально строятся как remote-first, поэтому почти ни одна из традиционных сетевых концепций напрямую не пригодится вам при проектировании первых этапов «корпоративной сети».

В этой более традиционной сетевой модели ваша инфраструктура, скорее всего, будет построена по одному или нескольким из следующих принципов:

• Он будет находиться в одном или нескольких VPC (которые могут быть или не быть соединены транзитными шлюзами облачного провайдера)
• Адресацией ваших сервисов, скорее всего, занимается ваш облачный провайдер
• Вы используете внутренний DNS от облачного провайдера, например AWS Route53 DNS (в той или иной степени на внутренний DNS полагается большинство компаний, даже самых cloud-native)
• Всегда может существовать причина сохранять концепцию частного сетевого пространства, пока вы поддерживаете собственную инфраструктуру
• Возможно, что не всем пользователям нужно будет разбираться во внутренней DNS-инфраструктуре или ориентироваться в ней (хотя техническим пользователям и сервисам это, скорее всего, понадобится)

По мере того как в создаваемой вами инфраструктуре начнут складываться устойчивые шаблоны, вы, скорее всего, сосредоточитесь вокруг одного основного облачного провайдера. Основные понятия, рассматриваемые в этом документе, касаются того, как пользователи подключаются к вашей сети для доступа к внутренним ресурсам и сервисам, а также того, как ваши внутренние сервисы взаимодействуют с интернетом в целом. Управление правами доступа и политиками облачной инфраструктуры, а также понимание того, как ваши внутренние сервисы могут взаимодействовать друг с другом, не менее важны для комплексной стратегии Zero Trust, но будут подробно рассмотрены в будущих обновлениях этого документа.

Это, вероятно, один из самых распространённых сценариев Zero Trust для большинства стартапов. Возможно, вы задаётесь вопросом: как предоставить пользователям доступ к внутренней сети или приложению без управления VPN-оборудованием и без риска для бизнеса? При выборе оптимального способа подключения пользователей к частным сетям и службам с соблюдением принципов Zero Trust стоит учитывать два важных момента:

1. Сокращение поверхности атаки: философия Zero Trust побуждает организации ограничивать число способов доступа к сетям и сервисам. Наличие публичных IP-адресов или путей входа в сеть создает лишний риск. Обычно этого достигают с помощью исходящих прокси, которые подключаются к поставщикам Zero Trust и пропускают в сеть только аутентифицированный трафик, не требуя никакого публичного IP-доступа.
2. Ограничение горизонтального перемещения: один из лучших способов уменьшить радиус потенциальной утечки данных заключается в применении принципа минимальных привилегий ко всем ресурсам. Доступ с минимальными привилегиями является ключевым принципом архитектуры Zero Trust, при котором пользователи получают только тот уровень доступа, который необходим для выполнения их роли, а не неограниченный доступ ко всей корпоративной сети. Ближайшим аналогом этого понятия в концепциях Zero Trust можно считать «микротуннели»: рекомендуемый подход, при котором каждое приложение или сервис, к которому нужен доступ, получает собственный отдельный «маршрут». Подобно микротуннелям, доступ с минимальными привилегиями позволяет выстроить практику, при которой доступ к конкретным ресурсам имеют только явно указанные сервисы и пользователи, что выгодно скажется на организации систем безопасности в будущем.

Чёткая стратегия создания и управления инфраструктурой, включая предсказуемую структуру внутренних IP-адресов и DNS-записей, окажется незаменимой для доступа к вашим ресурсам и их защиты по мере роста организации. Далее в документе мы подробнее расскажем, как с помощью автоматизированных процессов создавать инфраструктуру, которая мгновенно интегрируется с выбранным вами поставщиком решений Zero Trust. Если вы постоянно и ясно понимаете, какая инфраструктура существует и как она адресуется в данный момент, накладывать политики безопасности на модели контроля доступа будет значительно проще.

Cloudflare Zero Trust позволяет распространить концепции частной сети на конечных пользователей с помощью сочетания программного обеспечения для конечных точек и облачных сетевых коннекторов. В этом случае Cloudflare можно использовать как «оверлейную» сеть для расширения защищённого доступа к внутренней сети для конечных пользователей без раскрытия публичных IP-адресов, без разрешения входящих подключений из ваших облачных сред и без дополнительных рисков, обычно сопутствующих удалённому доступу.

В такой 'оверлейной' сети небольшой программный компонент размещается в вашей сети и предоставляет как 'сетевые' туннели (дающие пользователям административный доступ к сервисам внутренней сети и заменяющие классическую концепцию exposed-bastion), так и 'прикладные' туннели (micro-туннели, которые позволяют аутентифицированному пользователю обращаться исключительно к единственному сервису, заданному в туннеле).

Благодаря этому значительно упрощается управление доступом пользователей к нескольким разным частным сетевым средам: не нужно менять профиль, переключать настройки или постоянно отключаться и переподключаться в одном или нескольких клиентах. Это также позволяет легко открывать доступ к отдельному частному приложению или службе для конкретной аудитории, соблюдая принципы Zero Trust.

Для большинства стартапов сеть не входит в число приоритетов для изменений. Обычно компании идут по пути наименьшего сопротивления: управляют подключёнными VPC в AWS или GCP и, возможно, настраивают несколько внешних подключений к физическим офисам. Однако у большинства компаний рост быстро приводит к всё более сложной топологии сети, и происходит это, как правило, очень быстро.

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

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

Традиционные методы сетевого подключения по-прежнему имеют большое значение как в физических, так и в облачных средах, но эффективное их использование при сохранении надёжного периметра безопасности может быть непростой задачей. Когда у компаний были только требования к физическому подключению, например филиалы или дополнительные центры обработки данных, схема была намного проще. Вы использовали либо граничные устройства, такие как маршрутизаторы или межсетевые экраны, для терминирования физического подключения, либо выделенное головное устройство для построения VPN («виртуального») сетевого подключения между площадками. По сути, вы соединяли две «сети», предоставляя новый маршрут к новой сети или подсети для всех машин на исходной площадке.

Помимо создания связности WAN, конечная цель объединения нескольких площадок, простота управления. Единая сеть облегчает поддержку таких сетевых функций, как edge-маршрутизация, шлюзы и адресация через DHCP. Однако это может привести к чрезмерно широким политикам, и по мере роста сети становится сложнее управлять последствиями для безопасности во всё более сложных граничных случаях и нетипичных сценариях.

У современных стартапов проблемы могут отличаться от описанных выше, но им, скорее всего, всё равно придётся решать задачу растущей сложности сети. Лучший способ справиться с этим эффективно планировать. Если с самого начала строить корпоративную сеть с учетом безопасности и масштабируемости, будет гораздо проще справляться с растущей сложностью по мере развития служб безопасности и ИТ.

Если традиционные сетевые концепции в первую очередь сосредоточены на соединении сетей друг с другом, то ячеистые (mesh) или одноранговые (peer-to-peer) сетевые концепции соединяют сети с активами или независимыми конечными точками (например, пользовательскими устройствами, такими как ноутбуки и мобильные телефоны, или устройствами IoT, такими как умные лампы и камеры видеонаблюдения).

В традиционной сети у вас может быть VPN-туннель, создающий соединение site-to-site между адресными пространствами 10.0.0.0/8 и 192.168.0.0/24, предоставляя всем устройствам в обеих сетях шлюз для локального взаимодействия друг с другом. В mesh-модели сети, напротив, вы можете разрешить обмен данными только между определёнными адресными пространствами, например позволить 10.2.3.4 взаимодействовать только с устройством по адресу 192.168.0.50.

Если вы работаете только с «микротуннелями» (например, конкретный узел X может обращаться только к конкретному узлу Y), вы значительно сокращаете возможности для горизонтального перемещения злоумышленника. Например, при mesh-модели сети IP-адрес 10.2.3.4 не сможет получить доступ к конфиденциальным данным по другому адресу подсети 192.168.0.0/24 (хотя в традиционной сетевой модели это могло бы быть возможно). Однако такое повышение уровня безопасности увеличивает и сложность. Вам не только придётся (как правило) управлять агентами на каждой конечной точке mesh-сети, но и заранее готовить и поддерживать отдельные политики для каждого ресурса и каждого пути подключения.

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

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

Продукты Cloudflare, которые обычно наиболее актуальны для стартапов, это Cloudflare One Client на устройствах пользователей, Cloudflare Tunnel (cloudflared) для публикации частных сервисов и Cloudflare Mesh для двунаправленного соединения и связи между площадками (site-to-site). Это позволяет управлять удалённым доступом, mesh-соединениями и традиционной сетевой связностью из единой панели управления. На более детальном уровне это означает, что вы можете настраивать данные о состоянии устройства, данные идентификации, клиентские сертификаты и типовые параметры L4 (такие как порт, IP-адрес и протоколы источника и назначения) из единой точки применения политик, что позволяет выстраивать надёжные политики безопасности как для людей, так и для автономного сетевого взаимодействия.

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

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

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

Однако одна из главных трудностей, с которой сталкивается бизнес при переходе на модель Zero Trust, связана не с аутентификацией, а с авторизацией. Довести пользователя до входа в приложение в рамках модели Zero Trust относительно несложно, но управлять его учетными данными для аутентификации и авторизации, следить за их соответствием друг другу и при этом сохранять удобный, ненавязчивый пользовательский опыт может быть очень непросто.

В идеальном мире аутентификация и авторизация должны выполняться одним и тем же сервисом. Это означает, что, решая, как защитить внутренние приложения, встраивать ли в них поддержку OAUTH напрямую или интегрироваться с основным SSO, который вы используете для SaaS-приложений, вам также стоит подумать, не будут ли методы аутентификации конфликтовать или дублироваться с методами проверки идентификации. Есть два основных способа использовать эти подходы, чтобы выстроить масштабируемую систему аутентификации и авторизации.

Понятие «токены поставщика» есть не у каждого поставщика Zero Trust или SSE. Это связано с достаточно уникальным подходом Cloudflare: поскольку мы крупнейший в мире поставщик авторитативного DNS, мы предоставляем DNS для «внешнего» пути к вашим внутренним приложениям, а затем создаем токены для доступа пользователей.

Эти токены основаны на информации, которую Cloudflare получает от вашего поставщика удостоверений после успешной аутентификации и сверяет с пользовательскими политиками для данного приложения. Каждый токен содержит все данные, которые подписываются при аутентификации пользователя через IdP: имя, имя пользователя, адрес электронной почты, членство в группах и другие имеющиеся значения. Кроме того, ему присваивается уникальная метка, указывающая на его принадлежность к конкретному приложению.

После того как Cloudflare токен создан, он передается вашим внутренним приложениям для проверки их запросов и авторизации доступа к вашим внутренним инструментам. Это требует минимальных дополнительных усилий для каждого приложения и может быть встроено в процесс создания приложений там, где иначе потребовалась бы полноценная интеграция OAUTH или SSO.

Благодаря токенам Cloudflare ваши пользователи получат слаженную работу как аутентификация через уже настроенный прокси Zero Trust и получая авторизованный прямо в ваше приложение с той же информацией.

Некоторые поставщики решений Zero Trust могут выступать в роли провайдера SSO, напрямую интегрируясь с вашими приложениями (например, open source или self-hosted решениями), которые поставляются с готовым коннектором SSO. В этом сценарии ваш SSO контролирует авторизацию доступа к приложению, а поставщик Zero Trust обращается к вашему поставщику удостоверений для принятия решений об аутентификации, избавляя вас от необходимости управлять несколькими основными каталогами.

Для пользователей Cloudflare это даёт ряд преимуществ: упрощает аутентификацию (AuthN) и авторизацию (AuthZ), снижает зависимость от конкретного поставщика SSO и позволяет использовать несколько провайдеров аутентификации одновременно. Но главное, это позволяет легко перейти на нового поставщика удостоверений или начать его использовать.Компании с 25-50 пользователями нередко используют не того же поставщика удостоверений, что и компании с 300-500+ пользователями, и переход от одной интеграции SSO к другой почти всегда сопровождается значительными сложностями. Такой переход может быть особенно трудным с учётом того, сколько времени и разочарований связано с интеграцией SSO некоторых приложений. Использование Cloudflare в качестве поставщика SSO помогает снизить эти сложности за счёт объединения всех интеграций, связанных с удостоверениями, состоянием устройств и рисками, в единой точке применения политик: это упрощает AuthZ/AuthN и добавляет дополнительные меры защиты перед самостоятельно размещёнными приложениями.

Мы рекомендуем использовать продукт Cloudflare Access для удаленного доступа к внутренним сервисам (через программное обеспечение Cloudflare Tunnel в вашей сети). С Cloudflare Access вы можете обрабатывать JWT созданный Cloudflare Access, либо использовать Access for SaaS в качестве прокси SAML или OAUTH для ваших частных, самостоятельно размещённых приложений (в которые уже встроены интеграции SSO).

Во многих случаях для доступа к приложениям можно использовать оба продукта одновременно. Например, если вы самостоятельно размещаете Sentry ↗ (в настоящее время недоступного в публичном интернете), выполните следующие действия:

1. Настройте в Cloudflare Access публичное имя хоста, на которое ваши пользователи будут переходить для доступа к Sentry.
2. Установите Cloudflare Tunnel с соответствующим Опубликованное приложение чтобы указывать на ваш локальный сервис Sentry.
3. Интегрируйте Sentry с Access for SaaS в качестве поставщика SSO.

Теперь пользователи, обращающиеся к приложению за пределами вашей сети, уже будут иметь Cloudflare JWT и автоматически проходить аутентификацию в приложении.

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

Также возможно, что вы предоставляете клиентам размещённые или управляемые сервисы, которые они затем разворачивают в своих собственных сетях. В этом случае вам может понадобиться подключаться к этим сервисам для их надлежащего управления. Или же вы можете размещать частные ресурсы клиентов в своей собственной среде и предоставлять им безопасный доступ только к их собственному тенанту.

Когда вы определяете необходимость предоставить сторонним пользователям доступ к своей среде, сначала следует определить три параметра:

• К чему им нужен доступ
• Какой уровень аутентификации требуется для этого доступа
• Как долго этот доступ будет актуален

Определив область действия, необходимо выбрать модель доступа с наименьшими привилегиями, подходящую для данной группы пользователей. Это может означать интеграцию со вторичным провайдером идентификации (например, IdP заказчика или поставщика) для использования при аутентификации, либо применение временного метода аутентификации, такого как одноразовый PIN-код, только для подтверждения адреса электронной почты.

Некоторые компании также добавляют пользователей от поставщиков и подрядчиков в их провайдер идентификации, чтобы упростить аутентификацию и контролировать ее методы (например, использование MFA и других факторов аутентификации). Как минимум мы рекомендуем работать с провайдером безопасности Zero Trust, который поддерживает несколько одновременных методов аутентификации и может применять их через определенные политики или приложения.

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

Если такой доступ нельзя обеспечить через веб-браузер и требуется контроль на уровне сети, вашим внешним пользователям может понадобиться установить агент конечной точки, который используется в вашем развертывании Zero Trust. Например, у групп подрядчиков на одном пользовательском устройстве нередко установлено сразу несколько таких агентов, что может усложнить маршрутизацию сети или даже привести к конфликтам, если приватные сети разных компаний пересекаются.

Чтобы процесс предоставления доступа третьим сторонам оставался простым и управляемым, учтите следующее:

1. Поддерживает ли ваш поставщик решений Zero Trust несколько профилей для развёртывания агента на конечных устройствах? Учетные записи подрядчиков должны иметь строго ограниченные правила маршрутизации, чтобы обеспечить ограниченный доступ к вашей сети и снизить риск конфликтов с другими агентами на устройстве.
2. Существенно ли отличается доступ сторонних пользователей от доступа корпоративных пользователей? Если нет, вы можете упростить административное управление, создавая функциональные идентификации и интеграции для сторонних сервисов. Новые политики создавать не обязательно, если всё можно аудировать и разграничивать.

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

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

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

Cloudflare помогает предоставлять ограниченный защищённый доступ к веб- и сетевым ресурсам для сторонних пользователей в рамках модели Zero Trust.

• Cloudflare Access может интегрироваться и использовать несколько провайдеров идентификации одновременно. Это можно ограничить одним приложением и единой политикой, а также задать детализированные возможности, чтобы «принудительно» заставить часть пользователей проходить аутентификацию определённым способом. Существует также множество специфичных сторонних сценариев, например обоснование цели, который делает доступ простым для сторонних пользователей и одновременно документированным и управляемым для администраторов.
• Cloudflare Zero Trust можно развернуть с гибкими параметрами агента на конечных точках и логические группы для подрядчиков и сторонних пользователей. Если у вас есть внешние пользователи, которым нужен внутренний доступ, для них можно задать строго ограниченные права и снизить вероятность конфликтов с другими внешними системами.
• Cloudflare Tunnel может выступать в роли модели однонаправленного доступа, предоставляя корпоративным пользователям доступ к ограниченному набору ресурсов клиента. Это легковесное решение, простое в развертывании, которое можно даже встроить в ваши пакеты развертывания и разворачивать вместе со службами, которыми вы управляете в средах клиентов.
• Cloudflare Mesh (ранее WARP Connector) помогает создавать безопасные расширяемые сети, соответствующие каждому из применяемых у вас механизмов контроля на стороне клиента. Это особенно полезно, когда для взаимодействия с клиентами, их приложениями или для решения иных задач управления необходим двунаправленный трафик (сайт к сайту). Cloudflare Mesh обладает теми же встроенными средствами применения политик безопасности и аудита, что и остальная часть вашего развёртывания, поэтому вы можете поддерживать модель Zero Trust и одновременно обеспечивать связность с клиентами.

Традиционно понятие доступа Zero Trust целенаправленно относили только к доступу пользователей и устройств к внутренним или привилегированным ресурсам. На функциональном уровне это подразумевает отказ от расширения сети, снижение избыточных прав доступа и минимизацию горизонтального перемещения и векторов угроз, которые обычно возникают при удалённом доступе через VPN. Но для многих компаний VPN не просто проксировал трафик частной сети, он также управлял интернет-трафиком и позволял получать единую картину угроз, как правило, либо через модуль отправки DNS-запросов облачному провайдеру, либо путём перенаправления всего трафика пользователей в корпоративную сеть для прохождения через корпоративные межсетевые экраны.

Проблемы безопасности и сложности, возникающие из-за модели «замка и рва», вынудили многих вендоров пересмотреть две основные функции VPN. Сейчас secure web gateway (SWG) и Zero Trust access (ZTNA) нередко упоминаются вместе или входят в состав одного продукта.

Хотя этот сдвиг был инициирован поставщиками и аналитиками, а не исследователями в области безопасности, он, судя по всему, упростил управление безопасностью для заказчиков, а также упростил процесс покупки и развёртывания для стартапов. А именно, развёртывание единого агента для обработки как корпоративного, так и интернет-трафика представляет собой значительное улучшение по сравнению с использованием нескольких агентов устройства для разных видов инструментов безопасности.

В старом мире периметр определялся публичным исходящим IP адресом, а значит трафик проходил через ряд средств защиты, прежде чем попасть в интернет: это мог быть межсетевой экран, IPS, IDS или что-то ещё. Поэтому компании стали требовать конкретный исходный IP адрес трафика как условие «доверия»: это применялось к поставщикам, сторонним лицам и SaaS приложениям. Трафик из корпоративной сети (с корпоративных исходных IP адресов) был одним из главных признаков «доверия». Сегодня всё уже не так просто.

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

В мире, где ваш провайдер Zero Trust и ваш SSO способны защитить большинство ваших частных приложений, сетей, сервисов и SaaS-приложений, пользователи должны получить больше свободы работать из любого места, чем когда-либо. Ваш асинхронный, высокоэффективный стиль работы не должен прерываться, если вы следуете лучшим практикам. Иными словами, то, что вы считаете «защищённой» конечной точкой, становится новым периметром вашей корпоративной сети.

Чётко определённая защищённая точка доступа с ясной измеримостью значительно лучше для безопасности, чем исходный IP-адрес, поскольку она максимально целевая и постоянно проверяется. В прежней модели это означало прохождение через межсетевой экран и применение мер безопасности при выходе из сети. В новой модели это обычно означает проверку шифрования, оценку состояния устройства (posture) и определение того, был ли трафик с этого устройства проверен защищённым веб-шлюзом. Исходный IP-адрес всё ещё может использоваться как один из методов проверки, но никогда как основной механизм контроля.

Продумывая, как управлять использованием BYOD (и как обеспечить безопасный доступ к корпоративным данным), нужно прежде всего определить, из чего состоит ваша стратегия защиты конечных точек. Затем стоит продумать, как проверять запросы к конфиденциальным ресурсам на соответствие этой стратегии. Например, подумайте, какие шаги должны пройти пользователи для доступа к Workday (или другой системе, интенсивно работающей с PII). Прежде чем предоставить доступ, может понадобиться направить их трафик через защищённый веб-шлюз и применить политики предотвращения потери данных. Теперь задайте себе вопрос: какие ещё шаги нужны для соблюдения этих требований?

В рамках этого раздела мы рассматриваем безопасность интернета (например, защищенные веб-шлюзы, DNS-фильтрацию, проксирование трафика и так далее) как набор продвинутых сигналов безопасности, на основе которых можно применять более точные и детализированные политики Zero Trust для защиты чувствительных ресурсов. Также стоит как можно раньше внедрить DNS-фильтрацию, поскольку по мере роста бизнеса и требований к безопасности развертывание ПО и проксирование трафика с ваших эндпоинтов будет только усложняться. Когда вы перейдете к рассмотрению других продвинутых средств защиты, таких как HTTP-фильтрация и предотвращение утечки данных, рекомендуем ознакомиться с Начало работы с расшифровкой TLS ↗ чтобы составить представление о решениях, которые нужно принять перед расшифровкой трафика.

Помимо возможностей безопасности Zero Trust для внутренних приложений, удалённого доступа к сети и SaaS-приложений, Cloudflare также предоставляет следующие функции:

• Фильтрация DNS
• Межсетевой экран уровня L4
• Защищённый веб-шлюз (SWG) с поддержкой распознавания приложений, расшифровкой TLS, предотвращением утечки данных, функциями CASB, изоляцией браузера и возможностью использовать выделенную структуру исходящих IP-адресов непосредственно из сети Cloudflare

Вся функциональность SWG управляется политиками, которые учитывают идентификацию пользователя, состояние устройства и уровень риска пользователя, и предоставляется через того же агента конечной точки, что и элементы управления Zero Trust: с использованием тех же движков политик и возможностей их применения.

Cloudflare позволяет фактически выстроить новый периметр за счёт выявления исходящего трафика на управляемых конечных устройствах, применения к нему политик и обеспечения его защиты. Это даёт такой же единый контроль безопасности, как и в старой модели периметра «замок и ров», но с независимой детализированной оценкой безопасности и без бэкхолинга пользовательского трафика. Затем эту оценку можно использовать для применения ещё более строгих мер контроля со стороны приложений, защищённых Zero Trust, что помогает различать пользователей с низким, средним и высоким уровнем риска, принимать решения об обработке трафика BYOD и многое другое.

Понятие безопасности SaaS каждый трактует по-своему. Поэтому это довольно спорная тема, особенно в контексте Zero Trust. Во время первой волны COVID число пользователей SaaS-сервисов резко выросло, во многом из-за перехода на удалённую работу. Почти в одночасье пользователям стало проще и удобнее подключаться к сервисам за пределами корпоративной инфраструктуры, чем к внутренним сервисам.

Некоторые утверждают, что SaaS-приложения либо 1) изначально безопасны, если у вас интегрирован SSO, либо 2) их защита является функциональной ответственностью поставщика SaaS. Эти аргументы касаются способа доступа к SaaS-решениям и их защиты, но не объясняют, зачем компании вообще используют SaaS: а используют они его в основном для хранения корпоративной информации. Растущее число мест, где может храниться ваша конфиденциальная информация, будет играть всё более важную роль при принятии решений о безопасности SaaS.

Все приведённые утверждения предполагают, что вы знаете, какими SaaS-инструментами пользуются ваши сотрудники, но часто это не так. Сначала мы рассмотрим «санкционированное» использование SaaS, а затем перейдём к понятиям, связанным с «несанкционированным» SaaS, также известным как Shadow IT.

Определение требуемого уровня защищённости является важным первым шагом для ваших конечных пользователей, прежде чем вы начнёте выстраивать политику безопасности. Поэтому если у вас есть приложения, содержащие значительный объём корпоративных данных или других данных, подпадающих под требования законов о соответствии или иные нормативные акты, может быть разумно ограничить доступ к ним только устройствами, которые соответствуют упомянутому выше «периметру».

Лучший способ добиться этого: найти агрегатор ваших сигналов (например, Cloudflare Access for SaaS), который обеспечит постоянное применение всех отдельных элементов политики безопасности при доступе пользователей. Можно ли добиться того же с помощью обычного поставщика SSO? Возможно. Okta FastPass, например, определяет идентичность устройства, проверяя сертификат, установленный на локальных устройствах, а затем определяет исходный IP-адрес запроса. Однако в большинстве случаев FastPass не может сообщить вам больше о событиях проверки безопасности в трафике этого пользователя или о состоянии устройства конечного пользователя. Стоит учитывать, что ваш поставщик SSO полезен ровно настолько, насколько много данных он способен получить для принятия решения о политике.

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

Ещё один способ управления разрешёнными SaaS-приложениями: интеграция с вашим поставщиком Zero Trust через API. Это позволяет сканировать приложения на предмет неверной настройки или наличия неожиданных конфиденциальных данных. Такой процесс не зависит от традиционных механизмов контроля доступа Zero Trust, но предлагается большинством поставщиков Zero Trust и позволяет в едином представлении отслеживать необходимые изменения конфигурации для всех ваших SaaS-инструментов.

Оценивая наличие конфиденциальных данных в управляемых вами SaaS-приложениях, вы можете начать формировать понимание приоритетности политик. Другими словами, это может изменить ваш подход к тому, что должно быть доступно через BYOD, а что должно требовать авторизованного доступа с управляемого устройства. Или, наоборот, как оценить риск доступа через BYOD, чтобы эффективно ограничить действия пользователей?

Модель безопасности существенно меняется при переходе от SaaS приложений, которые вы контролируете (то есть можете интегрировать с SSO и другими сторонними инструментами), к приложениям, которые вы не контролируете. SaaS приложения этой категории часто называют «несанкционированными»: иногда потому, что ими управляет сторонний вендор, не поддерживающий SSO, а иногда потому, что это сервисы, явно не одобренные вашей IT организацией для использования. Такие несанкционированные приложения называют shadow IT.

Почему такие приложения так быстро распространяются в вашей инфраструктуре? Логика здесь простая, особенно для стартапов. Пользователи хотят работать быстро и часто выбирают самый удобный способ довести дело до конца. Иногда это означает использование инструментов, которые не прошли проверку и не были одобрены для работы (в том числе для хранения конфиденциальных данных).

Проблему теневых ИТ обычно решают в рамках общей программы безопасности интернет-инфраструктуры, которая иногда рассматривается наряду с внедрением Zero Trust, а порой даже у тех же поставщиков. Снижение рисков, связанных с несанкционированными SaaS-приложениями, почти всегда строится на видимости. Если приложение не интегрировано с SSO или инструментом CASB, самое важное, что можно сделать, это оценить масштаб использования теневых ИТ.

Для документирования несанкционированных приложений обычно требуется прямой прокси-инструмент, например DNS-фильтр, защищённый веб-шлюз или специализированное решение для электронной почты. Такие инструменты показывают, какие пользователи работали с несанкционированными SaaS-приложениями, а иногда и как именно: загружали или скачивали файлы, сколько трафика передали и так далее.

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

Такой подход также помогает ИТ-подразделению определить, для каких инструментов стоит планировать закупочные циклы. Например, если критическая масса пользователей уже активно пользуется каким-то инструментом, иногда имеет смысл приобрести для него возможности уровня Enterprise: это снижает риск теневого ИТ и позволяет команде внедрить дополнительные функции безопасности, зачастую без существенного роста затрат.

Cloudflare помогает заложить основу для видимости и управления вашими теневой ИТ среда и последующие открытия. Трафик пользователей в интернет можно проверять и упорядочивать через Cloudflare One Client и наш Secure Web Gateway (SWG), и понимать, куда перемещаются ваши конфиденциальные данные за пределами SaaS-тенантов, одобренных корпоративной политикой.

Это можно использовать как возможность для дальнейшего расширения стратегии Zero Trust: явно заблокировать или разрешить вновь обнаруженные инструменты, задать для них конкретные средства контроля безопасности данных или интегрировать их с поставщиком Zero Trust (например, с помощью Access for SaaS для применения политик безопасности).

Многих стартапов, с которыми мы общаемся, в конечном счёте беспокоит количество людей и экспертизы, необходимых для управления инструментами безопасности, которые кажутся слишком сложными или избыточными для их задач. Значительную часть разработки они уже ведут через инструменты оркестрации, подход Infrastructure as Code и напрямую через API, при этом они часто стремятся к состоянию DevSecOps, при котором все проекты Zero Trust (и другие инструменты безопасности) можно создавать, поддерживать и обслуживать как код.

Хотя для традиционных инструментов безопасности это относительно новая концепция, её всё равно стоит учитывать при оценке потенциальных поставщиков. Помните, что, хотя такие концепции, как Terraform, поддерживаются рядом поставщиков Zero Trust, эти поставщики могут не поддерживать (или не публиковать) провайдеры или конечные точки API для каждой концепции продукта, что может приводить к дублированию или разделению усилий по управлению.

Если цель вашей организации состоит в том, чтобы управлять сетевой инфраструктурой и системой безопасности как кодом, важно заложить такой подход как можно раньше на пути к Zero Trust. Трудности здесь неизбежны, но ранний старт в развитии сети окупится, когда потребности бизнеса и безопасности неизбежно станут сложнее и труднее в управлении.

Продолжая оценивать поставщиков для инициатив Zero Trust или общей безопасности, рекомендуем убедиться, что у них есть полностью задокументированные конечные точки API для всей линейки продуктов и элементов управления, а также документация для инструментов оркестрации и Infrastructure as Code (например, Terraform).

Безопасность Zero Trust в контексте DevSecOps по-настоящему важна для Cloudflare. Принцип API-first лежит в основе разработки всех наших продуктов: мы открываем клиентам все нужные конечные точки API сразу в день выхода функции, а также предоставляем обширную документация ↗.

Кроме того, многие наши клиенты управляют развёртыванием Cloudflare Zero Trust, вообще не заходя в панель управления, и используют для всего управления Terraform или аналогичные инструменты. Если это ваш случай, у нас есть подробное и полное Провайдер Terraform ↗ чтобы вы могли реализовать концепцию Zero Trust as Code.

В итоге несколько осознанных решений, принятых сегодня в отношении базовых принципов безопасности и аутентификации, принесут пользу вашему стартапу на годы вперёд. Решения, которые вы принимаете сейчас, закладывают основу современной инфраструктуры безопасности, способной плавно масштабироваться вместе с ростом бизнеса. Каким бы ни был ваш дальнейший путь, несколько взвешенных шагов обеспечат, что стартап построен на устойчивых и масштабируемых принципах безопасности Zero Trust.

Если вы хотите подробнее обсудить свои требования к Zero Trust и связаться с одним из наших архитекторов, перейдите на https://www.cloudflare.com/cloudflare-one/ ↗ и запросить консультацию.