Как стать автором
Обновить

Игры для самых больших: песочница данных и её безопасность

Время на прочтение8 мин
Количество просмотров2K

Говорят, что большие данные — новая нефть. В этом есть глубокая аналогия: каждый день большим данным находят всё новые и новые применения. Но есть и отличие: из двух бочек нефти можно сделать то же, что и из одной, только в два раза больше. А вот объединив два датасета, порой можно обнаружить удивительные вещи, не содержавшиеся ни в одном из них отдельно.

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

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

Вопрос доверия

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

Технически есть куча способов добиться такой безопасности. Один из них, о котором читатель, вероятно, наслышан — гомоморфное шифрование. Можно сделать так, что система будет производить вычисления, сама не зная, что именно вычисляет. Плюс этого подхода — криптографические гарантии. Не нужно верить поставщику услуги, достаточно верить в математику. Однако есть и очевидный минус. А именно — оверхед. Гомоморфное шифрование в принципе не отличается производительностью, а в случае биг даты можно упереться в какие-то вообще трансвычислительные задачи.

АБД решила пойти другим путём. Если доверие нельзя обеспечить математически — это можно сделать организационно-технически. Выступить в качестве доверенного третьего лица, гарантирующего сохранность данных. С одной стороны, АБД существует при поддержке всех крупных игроков на рынке, с другой стороны — не подчиняется ни одному из них. Таким образом, она обладает ресурсами крупной IT-компании, но в то же время лишена корыстной выгоды. Идеально для гаранта безопасности.

1 + 1 = много

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

Конкретные эксперименты, проходившие в песочнице, защищены NDA, поэтому разберём синтетический пример. Допустим, есть две крупные компании. Одна продаёт одежду, другая — фастфуд. И у каждой — здоровенная бочка данных.

Можно предположить, что то, как человек одевается, коррелирует с тем, что этот человек ест. Ну, например, такая гипотеза: любитель футболок более склонен есть бургеры, чем любитель рубашек с длинным рукавом. Бургер, особенно «многоэтажный», трудно есть аккуратно — высокий риск заляпать рукав.

Если гипотеза верна, это можно использовать в таргетированной рекламе или совместных акциях. Тому, кто съел бургер — показать рекламу футболки. Тому, кто купил футболку — дать скидку на бургер. Но верна ли она? Не всё, что звучит правдоподобно, является правдой.

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

Или вот ещё интересный случай: у вас нет ни одной бочки данных, зато уйма идей по поводу того, что бы с ними сделать. Иначе говоря, вы — стартап в области Data Science. Пока у вас нет хотя бы MVP, маловероятно, что большая компания поделится своими данными. Пока нет данных — не из чего собрать MVP. Порочный круг.

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

А внутри у ней неонка

Как же всё-таки устроена песочница данных? Принципиальная схема выглядит так:

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

Есть хранилище данных — то место, где они непосредственно лежат. В качестве такого хранилища используется S3 Object Storage, любезно предоставленное Яндексом в качестве PaaS.

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

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

Если говорить о векторах атаки, то имеет смысл начинать не с вопроса «как», а с вопроса «кто». Кто может украсть данные? Составим список подозреваемых:

  1. Случайный хакер.

  2. Поставщик инфраструктуры (то есть на текущий момент — Яндекс).

  3. Поставщик данных.

  4. Исследователь данных.

  5. Администратор песочницы.

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

Разделяй и властвуй

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

Хранилище S3 разделено на каталоги, каталоги — на бакеты (отдельные логические подхранилища). Каждый поставщик данных имеет доступ только к собственному каталогу, к чужим — ни-ни. Воровать собственные данные — не слишком выгодное занятие.

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

Там царь Кащей над златом чахнет

Следующий подозреваемый — поставщик инфраструктуры. Почему бы ему не украсть данные? Ну и сразу поднимем вопрос: почему бы хакеру не украсть данные через него?

На последний вопрос ответ простой и скучный — сертификация. Облачные сервисы Яндекса соответствуют ISO 27001, 27017 и 27018 (это помимо российских стандартов безопасности, соответствовать которым необходимо по закону). Перечисленные стандарты ISO покрывают огромное множество кейсов, когда что-то может пойти не так. Начиная от физических вещей: видеонаблюдения, контроля доступа персонала и тому подобного. И заканчивая более айтишными: всё зашифровано, сервисы шифрования и хранения пространственно разнесены и так далее.

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

Но что всё-таки мешает самому провайдеру инфраструктуры присвоить данные? Ну, во-первых, песочница поверх его безопасности навешивает ещё дополнительный уровень собственной. А во-вторых, что более важно, но опять же скучно — договор. Юридические обязательства поставщика перед песочницей таковы, что лучше бы их не нарушать. Маркс писал, что нет такого преступления, на которое не пойдёт капиталист ради выгоды в 300%. Однако при угрозе штрафа в, грубо говоря, 1000%, все виды преступлений становятся для капиталиста крайне непривлекательными. Тем более что хорошая репутация для компаний гораздо выгоднее и стоит куда дороже, чем штрафы.

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

Видит око, да зуб неймёт

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

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

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

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

Следующий шаг — подключение к S3 и работа с данными… Мог бы быть, если бы мы меньше заботились о безопасности данных. На самом деле дата-сайентист подключается к прокси-серверу. Прокси “прозрачный”, он перенаправляет запросы на S3, а ответы — обратно. Но при этом — логирует их. Таким образом, всегда можно отследить, с какими данными дата-сайентист работал. Более того, это не только можно — это в самом деле регулярно смотрят специально обученные люди. Если дата-сайентист интересуется чем-то не тем или не так — к нему возникнут вопросы.

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

Ещё один уровень защиты вытекает из самоограничения. Теоретически у дата-сайентиста есть буфер, копирование в который нельзя запретить — собственная память. И, например, исследуя данные агрегатора такси, он мог бы подсмотреть, куда прошлым вечером ездила его девушка. Однако песочница не работает с персональными данными. Юридически — имеет право, необходимые разрешения есть. Но по собственному решению (в том числе — чтобы избежать ситуаций вроде описанных выше) она принимает только деперсонализированные данные. Которые представляют ценность именно как биг дата — а биг дату наизусть не выучишь.

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

Quis custodiet ipsos custodes?

Остаётся самый логичный вопрос: как обеспечить безопасность данных в песочнице от владельцев песочницы. Точнее — от того, кто с их стороны непосредственно имеет доступ. От администратора системы.

На самом деле, строго говоря, гарантий нет. Администратор имеет техническую возможность скопировать данные. Он может забрать их, затем быстро покинуть страну, сменить имя, залечь на дно… Зачем все эти шпионские игры? Ну потому что спокойно жить ему после этого не дадут. Все действия администратора также журналируются. Причём журнал ведётся на отдельном сервере, к которому сам администратор не имеет доступа. И особый сотрудник эти действия очень внимательно анализирует. Согласно договору песочницы с клиентами, он обязан делать это ежедневно. Стало быть, у администратора-злоумышленника есть максимум сутки, чтобы скрыться.

Есть, конечно, ещё фантастические сценарии. Например, сговор администратора со своим контролёром. Или что из дата-центра Яндекса увезут грузовик жёстких дисков, а администратор поможет их расшифровать. В конце концов, не бывает стопроцентных гарантий, бывает грамотный риск-менеджмент.

Кем вы видите себя через 5 лет?

Как следует из предыдущих разделов, песочница данных — уже довольно безопасное место. Однако нет предела совершенству. Есть много особо чувствительных видов данных, с которыми хотелось бы уметь работать. Медицинская тайна, банковская тайна, тайна связи. Исследуя эти нефтяные месторождения, можно получить ещё больше интересных результатов. Однако нужно иметь право работать с такими данными. Юридическое, а главное — моральное. Быть доверенной стороной — огромная ответственность, заставляющая действовать очень осмотрительно.

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

Теги:
Хабы:
+6
Комментарии0

Публикации

Информация

Сайт
rubda.ru
Дата регистрации
Дата основания
Численность
Неизвестно
Местоположение
Россия

Истории