Предприятия переносят рабочую нагрузку AI / ML в облако, но сталкиваются с серьезными проблемами безопасности. Вот проблемы и способы их решения.

Началась миграция AI / ML в облако

Сегодня потребность AI / ML в передовых вычислениях и хранении данных побуждает предприятия переносить рабочие нагрузки AI / ML из удобных границ своих центров обработки данных в облако. Но недавние заголовки о громких утечках данных показали, что существуют действительные, реальные и серьезные проблемы кибербезопасности, которые необходимо решать.

Это особенно острая проблема для AI / ML. В конце концов, практикующие AI / ML полагаются на огромные объемы данных, многие из которых являются конфиденциальными и / или конфиденциальными, для обучения своих моделей. Что еще более усложняет ситуацию, данные, используемые специалистами по обработке данных, должны в основном оставаться незамутненными (или «открытым текстом»), что может увеличить как возможность утечки данных, так и, возможно, также ее влияние.

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

Сегодня кажется, что решение проблем кибербезопасности могло стать предпосылкой для переноса рабочей нагрузки AI / ML в облако для многих предприятий.

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

Миграция в облако AI / ML вызвала серьезные проблемы с безопасностью

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

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

Но сам характер использования облака для обработки рабочих нагрузок AI / ML вызывает и усугубляет проблемы кибербезопасности. Следует выделить две уникальные характеристики: (a) AI / ML требует доступа к огромным объемам конфиденциальных данных, и (b) AI / ML требует, чтобы эти данные были немаскированы (в открытом виде), чтобы облегчить исследования, обучение и верификация моделей специалистов по данным.

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

К сожалению, не всегда очевидно, что прежние методы корпоративной безопасности эволюционировали, чтобы идти в ногу со временем. По крайней мере, недавние заголовки об утечке данных Capital One предполагают, что это так.

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

Во-вторых, современные враги умнее и приобретают лучшие инструменты, в результате чего периметры сети, казалось бы, становятся более проницаемыми. Недавняя утечка данных Uber в облаке, безусловно, продемонстрировала, что это так.

В-третьих, при наличии огромного количества конфиденциальных данных, необходимых для ИИ / машинного обучения, доступным для сотрудников, предприятиям необходимо ввести средства контроля, чтобы избежать преднамеренных утечек. Globe and Mail сообщил, что утечка данных в Desjardins Group затронула 2,9 миллиона клиентов, была вызвана ошибочным сотрудником, который якобы украл и раскрыл конфиденциальные данные, включая личную информацию, такую ​​как имена, даты рождения, номера социального страхования (аналогично US Social Номер безопасности), а также адрес электронной почты, телефона и домашнего адреса.

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

Решение проблем кибербезопасности, связанных с AI / ML

Существует несколько современных методов (см. Рисунок 1), которые устраняют вышеупомянутые угрозы безопасности и являются основой для безопасной аренды корпоративного облака.

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

Подход к безопасности на основе идентификации («1» на рисунке 1) гарантирует, что конфиденциальные данные будут доступны только специалистам по данным, которые проверили учетные данные. И как следствие: злонамеренные или неавторизованные агенты не будут иметь необходимых учетных данных, необходимых для доступа к конфиденциальным данным.

При реализации подхода к безопасности на основе идентичности необходимо как минимум учитывать следующее:

  • Локальные и облачные каталоги (например, Microsoft Active Directory или LDAP) должны быть синхронизированы («2» на рисунке 1). Это позволяет согласованно управлять удостоверениями и связанными с ними учетными данными независимо от того, где они созданы или используются.
  • Локальный экземпляр - это мастер, предлагающий единый авторитетный источник идентификаторов, который должен снизить риски безопасности из-за человеческих ошибок и сложности конфигурации. С точки зрения конечного пользователя это обеспечивает возможность единого входа (SSO) для доступа как к облачным, так и к локальным ресурсам, что устраняет общие проблемы, связанные с управлением несколькими идентификаторами и паролями.
  • Механизм управления доступом на основе ролей (RBAC) (3 на рисунке 1), поддерживаемый в корпоративной системе управления идентификацией, представляет собой систему авторизации, которая ограничивает доступ к ресурсам для авторизованных пользователей. Это работает следующим образом (хотя это упрощение): роли обычно создаются для представления должностных функций; Разрешения назначаются ролям для выполнения различных операций; Затем пользователи / сотрудники обычно распределяются по группам, которые затем, в свою очередь, назначаются ролям. Это создает полезный уровень косвенности: пользователям не назначаются разрешения, а они получают разрешения только будучи членом роли. Теперь управление правами пользователей упрощено, поскольку для этого требуется только назначить соответствующие роли учетной записи пользователя / сотрудника.

Во-вторых, подход безопасности с нулевым доверием (4 на рис. 1) диктует, что ресурсы создаются без прав доступа - ничто не доступно в облачной среде предприятия, если не предусмотрены явная аутентификация и авторизация. предоставлена. Архитектура Zero Trust использует идентификационные данные и утверждения / информацию об устройствах (например, IP-адрес) для аутентификации пользователей и проверки авторизации, необходимой для получения доступа к данным и приложениям в облачной среде предприятия. Таким образом, безопасность на основе идентификационных данных обеспечивает базовые возможности, необходимые для реализации политики нулевого доверия.

В-третьих, политика нулевой утечки гласит, что данные нельзя передавать каким-либо образом за пределы облачной аренды предприятия. Эта политика не позволит как сотрудникам, имеющим доступ к конфиденциальным данным, так и злонамеренным агентам, которые получают доступ к конфиденциальным данным, позволить данным покинуть или утекать из арендуемого корпоративного облака. По моему опыту, Zero Leakage можно реализовать с помощью безопасного портала (5 на рисунке 1), который действует как окно просмотра, используемое специалистами по обработке данных для доступа к облачной среде. Портал обеспечивает относительно полнофункциональный доступ к облаку, но у него отключены определенные возможности (обычно возможность вырезать, вставить и загрузить), которые позволяют перемещать данные. У Citrix есть ряд продуктов, которые это поддерживают, как и у Microsoft (удаленный рабочий стол) и VMWare (Horizon View).

Наконец, очень важно установить политику для непрерывного мониторинга дрейфа конфигурации (цифра 6 на Рисунке 1). Управление многочисленными облачными компонентами сложно - еще сложнее управлять их безопасностью. И, как бы то ни было, энтропия в конечном итоге заставит вашу облачную конфигурацию измениться - или дрейфовать - неожиданным образом. Мониторинг использования облака на предприятии и отметка любых неожиданных изменений конфигурации, внесенных вашей командой или внесенных поставщиком облачных услуг, гарантирует, что любые уязвимости кибербезопасности будут обнаружены и устранены до того, как они нанесут значительный ущерб.

На пути к безопасному искусственному интеллекту / машинному обучению

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

Но предприятия не стоят на месте. Они отвечают:

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

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

Примечание от редакторов Data Science. Хотя мы разрешаем независимым авторам публиковать статьи в соответствии с нашими правилами и рекомендациями, мы не поддерживаем вклад каждого автора. Не стоит полагаться на работы автора без консультации с профессионалами. См. Подробности в наших Условиях для читателей.