По мере того как растет потребность в управлении конфиденциальностью, суверенитетом, размещением и стоимостью данных, будет появляться все больше корпоративных сценариев использования модели «своего облака» (Bring Your Own Cloud, BYOC), пишет на портале Network Computing Чад Тиндел, технический директор и вице-президент по архитектуре решений компании ngrok.

Чтобы быть успешными, многим SaaS-решениям требуется доступ к данным своих клиентов. Например, Databricks, услугами которой пользуется более половины компаний из списка Fortune 500 для обработки, анализа и монетизации массивов данных, нужно подключаться к облачным аккаунтам своих клиентов, чтобы обрабатывать и хранить данные, обеспечивая безопасность и масштабирование.

Однако отправка данных поставщикам для обработки сопряжена с различными трудностями. Резкий рост объема и сложности данных делает такой подход непрактичным, зачастую требуя значительных затрат на обработку и передачу при выводе данных из облака клиента и/или их вводе в облако поставщика. И, пожалуй, самое главное — передача контроля вызывает опасения по поводу конфиденциальности, суверенитета и безопасности данных.

Встречайте BYOC

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

Проблемы, связанные с получением доступа к BYOC в сети заказчика

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

Кроме того, идея предоставления доступа облачным провайдерам может заставить некоторые предприятия задуматься. Согласно CrowdStrike Intelligence «2023 Global Threat Report», в 2022 г. число облачных инцидентов безопасности выросло на 95%, что, по мнению исследователей, объясняется тем, что субъекты угроз для получения первоначального доступа используют действительные облачные учетные записи и общедоступные приложения. Чтобы обеспечить безопасность сети и быстрое время получения ценности, компании должны внедрить лучшие практики для решения этих проблем.

Лучшие практики для доступа к сетям клиентов с помощью BYOC

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

Хотя и поставщики, и заказчики обязаны обеспечивать безопасность своих сетей, доступ к целям BYOC должен быть четко определен с помощью политик аутентификации. Заказчики должны убедиться, что любой поставщик, использующий BYOC, поддерживает политики Mutual TLS (mTLS), IP-ограничения, аутентификацию OAuth, SAML, Open ID Connect (OIDC) и JWT. Для поставщиков важно, чтобы в их сеть из сред клиентов попадал только авторизованный трафик.

Будущее BYOC

По мере роста объема данных растет и потребность в безопасном и экономически эффективном доступе к ним, их обработке и хранении. Несмотря на то что десятки сценариев использования требуют от поставщиков безопасного доступа к данным клиентов, вот три основных, в которых BYOC будет использоваться в первую очередь:

  • Основанные на данных инсайты и аналитика. Такие компании, как Databricks, используют BYOC для обработки, анализа и монетизации массивов данных в облаках клиентов. Чтобы избежать расходов на передачу данных и сохранить контроль над ними в целях соблюдения нормативных требований, все больше клиентов будут требовать от компаний, занимающихся анализом данных, предоставления BYOC.
  • Обучение больших языковых моделей и искусственный интеллект. Новое поколение ИИ-компаний обучают свои модели на наборах данных, хранящихся у заказчика. Передача обучающих данных из сетей клиентов нежелательна, так как она ставит под угрозу безопасность и суверенитет данных, является дорогостоящей и медленной. BYOC позволяет компаниям запускать программное обеспечение ИИ в сетях клиентов, где хранятся данные, чтобы обучать модели на информации, являющейся собственностью компании и не покидающей своего облака.
  • Управление уязвимостями на базе SaaS. Чтобы обеспечить управление уязвимостями в режиме реального времени, поставщики SaaS должны подключаться к сетям клиентов для сканирования, обнаружения и постоянного мониторинга активов. Они также должны применять надежные меры безопасности для защиты конфиденциальной информации и соблюдения организационных политик и норм, как это предусмотрено в BYOC.

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