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

Элизабет Наммур, Пиняо Го, Венди Джин

Вступление

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

  1. Данные постоянно развиваются. Из-за этого инженерам сложно иметь глобальное представление о данных и о том, как данные проходят через инфраструктуру компании. Данные можно реплицировать и распространять в разные хранилища данных. Кроме того, можно собирать новые типы данных по мере появления или изменения продуктов.
  2. Ручная классификация более подвержена ошибкам. Инженеры могут забыть, содержит ли актив данных личные данные, или, возможно, как в случае с произвольными записями пользователей, могут не знать, что содержит актив.
  3. Элементы безопасности и конфиденциальности личных данных постоянно расширяются. Инженеры должны снова выполнить ручную классификацию данных для любых новых элементов данных, требуемых новыми правилами конфиденциальности и соблюдением требований безопасности, что влечет за собой высокие затраты и низкую эффективность труда для компаний.
  4. Секреты могут просочиться в нашу кодовую базу и различные хранилища данных. Секреты, такие как рабочие ключи API, секреты поставщиков и учетные данные базы данных, обычно используются инженерами. Утечка секрета в базе кода - известная проблема в технической индустрии, обычно из-за случайного или непреднамеренного кода, совершенного инженерами, и они не всегда обнаруживаются рецензентами. После регистрации секреты превращаются в иголки в стоге сена, и их нелегко обнаружить.

Чтобы решить эти проблемы, мы создали инструменты классификации данных для обнаружения личных и конфиденциальных данных в наших хранилищах данных, журналах и исходном коде. Продолжайте читать, пока мы рассмотрим архитектуру наших инструментов классификации данных. В частности, мы подробно рассмотрим технические компоненты Inspekt, нашей системы классификации данных для наших хранилищ данных и журналов, и Angmar, нашей системы обнаружения и предотвращения секретов для нашей кодовой базы на Github Enterprise.

Inspekt: ​​служба классификации данных

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

Создатель задач

Система создания задач отвечает за определение того, что сканировать, и разделение этого на задачи, которые система сканирования должна принять.

Создатель задач Inspekt периодически вызывает Madoka, нашу службу метаданных, описанную в нашем предыдущем сообщении в блоге, чтобы получить список активов данных, существующих на Airbnb. Из хранилищ данных MySQL и Hive сервис извлекает список всех таблиц. Для AWS S3 сервис извлекает список сегментов для каждой учетной записи AWS и соответствующий им список объектных ключей. Из-за огромного объема данных создатель задач случайным образом выбирает небольшой процент ключей объектов из каждой корзины. Для журналов приложений служба извлекает список всех служб в Airbnb и их соответствующих кластеров Elasticsearch, в которых хранятся журналы. Затем создатель задачи создает сообщение SQS для каждой таблицы / объекта / приложения, которое называется задачей, и добавляет его в очередь сканирования SQS, которая будет использоваться сканером на более позднем этапе.

Сканер

Система сканирования отвечает за выборку и сканирование данных для обнаружения личной информации. Inspekt предоставляет интерфейс для определения методов сканирования, алгоритмов сканирования выборочных данных. Для каждого элемента данных мы определяем «верификатор» как комбинацию одного или нескольких методов сканирования.

Inspekt в настоящее время поддерживает четыре типа методов сканирования:

  • Регулярные выражения (Regexes). Регулярные выражения полезны для элементов данных, которые следуют фиксированному формату, например, координаты долготы и широты, даты рождения, адреса электронной почты и т. д. Inspekt позволяет нам определять регулярные выражения для соответствия метаданные (например, имя столбца, имя ключа объекта) актива данных или с содержанием актива. Inspekt позволяет нам определять регулярные выражения как списки разрешений, так и списки денилистов. Например, мы можем определить регулярное выражение для обнаружения ресурсов данных, в которых имя столбца содержит «дату рождения», или где содержимое содержит слово «дата рождения», или где содержимое не содержит слова «дата рождения».
  • Попытки. Некоторые элементы данных, которые мы собираем, не соответствуют фиксированному шаблону, например имя и фамилия, и не могут быть обнаружены с помощью регулярных выражений. Когда элемент данных хранится в хранилище данных известного источника, мы можем использовать алгоритм Aho-corasick, который использует попытки обнаружения совпадений подстрок конечной выборки этих данных.
  • Модели машинного обучения (ML). Ряд элементов данных невозможно точно или эффективно обнаружить с помощью сканирования на основе регулярных выражений по нескольким причинам. Во-первых, некоторые элементы данных, такие как физические адреса, имеют разные форматы или неисчерпывающий объем содержимого. Во-вторых, как глобальная компания, работающая в более чем 200 странах, Airbnb размещает данные на разных языках. В-третьих, некоторые данные, например изображения, не являются текстовыми и поэтому не могут быть распознаны с помощью обычных методов сканирования. Алгоритмы, основанные на машинном обучении, естественным образом подходят для решения этих задач. Мы разработали различные модели машинного / глубокого обучения, такие как многозадачная CNN, Bert-NER и модель классификации WiDeText, для обнаружения нескольких сложных элементов данных. Модели обучаются либо с использованием образцов данных из нашей производственной базы данных, таких как адреса пользователей из таблиц объявлений Airbnb, либо с использованием общедоступных наборов данных или моделей, предварительно обученных на большом текстовом корпусе. Мы размещаем эти модели на платформе машинного обучения Airbnb под названием Bighead, которая обслуживает конечные точки API для Inspekt, чтобы обнаруживать каждый элемент данных с помощью методов сканирования машинного обучения.
  • Жестко запрограммированные методы. Некоторые элементы данных, которые мы собираем, следуют фиксированному шаблону, но либо слишком сложны для описания в регулярном выражении, либо уже существует решение с открытым исходным кодом, которое обнаруживает элементы данных с высоким качеством. Inspekt позволяет нам определять блок кода для обнаружения элемента данных. Например, мы создали верификатор элемента данных международного номера банковского счета (IBAN), используя валидатор из библиотеки с открытым исходным кодом.

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

Вот пример конфигурации верификатора, которая направлена ​​на обнаружение любого имени столбца, содержащего слово «дата рождения» или содержимого, содержащего слово «дата рождения»:

Inspekt Scanner - это распределенная система, использующая Kubernetes. В зависимости от рабочей нагрузки (т. Е. Задач в очереди) он может масштабироваться по горизонтали по мере необходимости. Каждый узел сканера принимает сообщения о задачах из очереди задач SQS. Для обеспечения надежности сканирования каждое сообщение снова появляется в очереди N раз, пока узел сканирования не удалит его. Схема архитектуры сканера показана ниже.

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

  1. Сканер Inspekt подключается к хранилищу данных, указанному в задаче, и производит выборку данных из хранилища данных. Для MySQL узел сканера подключается к базе данных MySQL и отбирает подмножество строк для каждой таблицы. Чтобы каждый раз сканировать другой набор строк, не вызывая полного сканирования таблицы, мы случайным образом генерируем значение X, меньшее максимального значения первичного ключа, и выбираем подмножество строк, где первичный ключ ›= X. Для Hive мы выбираем выборку подмножество строк для каждой таблицы из последней секции. Для журналов обслуживания мы отбираем подмножество журналов для каждой службы в день. Чтобы лучше охватить различные журналы, мы делаем запросы к нашим кластерам журналов Elasticsearch, чтобы выбрать журналы из разных точек ведения журнала. Для S3 мы генерируем случайное смещение, меньшее размера объекта, и выбираем настраиваемый набор байтов, начиная с этого смещения. Мы также поддерживаем сканирование учетных записей AWS. Если объект находится в другой учетной записи AWS, чем та, в которой запущен сканер, Inspekt автоматически использует соответствующие разрешения Assume Role IAM для доступа и чтения объектов из внешней учетной записи.
  2. Для каждой части выборки данных из хранилищ данных Inspekt Scanner сравнивает каждую верификатор с датумом, чтобы определить, было ли найдено какое-либо совпадение.
  3. Inspekt Scanner сохраняет результаты сопоставления в базе данных. Для каждого совпадения мы будем хранить метаданные ресурса данных, в котором было найдено совпадение, совпадающий контент и верификатор, с которым он был сопоставлен. Мы также храним подмножество этой информации, содержащее только актив данных и найденный элемент данных, в отдельной таблице. Мы периодически удаляем записи из таблицы результатов сопоставления, чтобы обеспечить безопасность и конфиденциальность наших данных.
  4. Inspekt Scanner удаляет сообщение SQS

Служба измерения качества Inspekt

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

Стратегия измерения качества

Чтобы постоянно отслеживать и улучшать качество каждого верификатора элементов данных, мы создали сервис Inspekt Quality Measurement для измерения их точности, полноты и достоверности.

Для каждого элемента данных мы храним истинно положительные данные и истинно отрицательные данные как основную истину в нашей базе данных Inspekt Quality Measurement. Затем мы запускаем верификатор против набора данных наземной истины. Из истинно положительных данных мы выводим количество истинных положительных результатов (TP) и количество ложных отрицательных результатов (FN), сгенерированных верификатором. Из истинно отрицательных данных мы выводим количество ложных срабатываний (FP) и истинных отрицаний (TN), сгенерированных верификатором. Затем мы можем рассчитать точность, отзыв и точность по счетчикам TP, FN, FP, TN.

Выборка и заполнение тестовых данных

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

  • Известные наборы данных в производстве: известно, что некоторые столбцы в наших онлайн-базах данных или нашем хранилище данных содержат и представляют определенный элемент данных, например, столбец MySQL, который, как известно, хранит адреса электронной почты. Мы можем использовать эти столбцы как истинные положительные результаты.
  • Результаты Inspekt: ​​по мере того, как Inspekt запускает и генерирует результаты, результат может представлять либо истинно положительный, либо ложный положительный результат. Поэтому мы можем использовать эти данные для заполнения набора данных.
  • Известные произвольные / неструктурированные данные: некоторые столбцы в наших онлайн-базах данных или нашем хранилище данных представляют произвольные данные, введенные пользователем, или неструктурированные большие двоичные объекты, такие как сообщения, объекты JSON и т. Д. Эти столбцы могут содержать любые типы элементов данных и представлять хорошие тестовые данные. источник, чтобы гарантировать, что наша система обнаруживает элементы данных в неструктурированных форматах и ​​в различных крайних случаях.
  • Сгенерированные поддельные синтезированные данные. Некоторые элементы данных, такие как рост и вес пользователя, нечасто присутствуют в наших хранилищах данных, и нет известных исходных столбцов, в которых они хранятся. Чтобы иметь достаточно тестовых данных для этих элементов данных, мы генерируем поддельные данные в надлежащем формате и заполняем ими нашу тестовую базу данных.

Маркировка

После выборки данных нам необходимо убедиться, что каждый образец представляет истинно положительный или истинно отрицательный, прежде чем сохранять его в наших наборах тестовых данных. Для этого мы вручную маркируем выбранные данные с помощью AWS Ground Truth. Для каждого элемента данных мы разработали инструкции и обучили сотрудников Airbnb правильно маркировать каждый образец как истинный или ложный. Затем наша система загрузит необработанные данные, выбранные для каждого элемента данных, в AWS S3 и создаст задание маркировки с соответствующими инструкциями на Ground Truth. Как только сотрудники закончат маркировку данных, помеченный вывод будет сохранен в корзине S3 для нашей системы. Служба Inspekt Quality Measurement будет периодически проверять сегмент, чтобы определить, готовы ли помеченные данные. Если все будет готово, он получит и сохранит данные в наших наборах тестовых данных, а затем удалит необработанные и помеченные данные из S3.

Переобучение моделей машинного обучения

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

Ангмар: обнаружение и предотвращение секретов в коде

В предыдущих разделах мы описали, как Inspekt фокусируется на обнаружении личных и конфиденциальных данных в хранилищах данных. Однако некоторые конфиденциальные данные, такие как секреты бизнеса и инфраструктуры, также могут существовать в кодовой базе компании, что может привести к серьезным уязвимостям в случае утечки непреднамеренным сторонам. Мы расширили наши возможности до решения для обнаружения секретов под названием Angmar, которое использует подходы обнаружения и предотвращения для защиты секретных данных Airbnb в Github Enterprise (GHE).

Архитектура

Angmar состоит из двух частей: проверки CI, которая предназначена для обнаружения секретов, переданных в GHE, и ловушки предварительной фиксации Github, которая в первую очередь предназначена для предотвращения попадания секретов в GHE.

Мы создали CI-проверку для сканирования каждой фиксации, отправляемой на сервер Airbnb GHE. Когда фиксация отправляется в GHE, запускается задание CI, которое необходимо пройти до того, как слияние будет разрешено в основной ветке. Задание CI загружает последнюю настроенную библиотеку версий библиотеки с открытым исходным кодом Yelp / detect-secrets и запускает задание сканирования секретов для каждого измененного или добавленного файла в фиксации. После обнаружения секретов в задании CI он запускает платформу защиты данных для создания заявки JIRA и автоматически назначает заявку автору кода для разрешения. Подробности создания билетов будут обсуждаться в части 3 этой серии блогов. Мы требуем, чтобы все секреты производства были удалены, повернуты и снова зарегистрированы с помощью нашего инструмента управления секретами производства под названием Bagpiper в рамках SLA.

Тем не менее, поскольку проверка CI сопровождает каждое нажатие на кодовую базу, временное окно раскрытия секрета по-прежнему создает определенные риски безопасности для инфраструктуры компании. Кроме того, в некоторых случаях секретная ротация может быть очень дорогостоящей с точки зрения инженерных часов и затрат. Поэтому мы предлагаем упреждающий подход для предотвращения проникновения секретов в GHE, в первую очередь, для дальнейшего устранения раскрытия секретов и экономии усилий, связанных с сменой секретов. Мы создали инструмент предварительной фиксации Angmar, используя ту же настраиваемую библиотеку обнаружения для разработчиков, чтобы заблокировать фиксацию секретов в фиксации Git. Как только секреты будут обнаружены в фиксации, команда Git commit выдаст ошибку и заблокирует новую фиксацию.

Настройка

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

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

Будущая работа

Мы постоянно совершенствуем и расширяем Inspekt и Angmar, чтобы сканировать больше источников данных и выявлять больше конфиденциальных и конфиденциальных элементов данных. Несколько инициатив, которые мы в настоящее время изучаем или над которыми работаем, включают:

  1. Сканирование запросов и ответов API языка описания интерфейса Thrift для отслеживания передачи личных и конфиденциальных данных между службами.
  2. Сканирование наших сторонних приложений, таких как Google Drive, Box, чтобы понять происхождение данных о том, как данные поступают в сторонние приложения и как осуществляется доступ к данным как внутри, так и извне.
  3. Расширение наших возможностей сканирования до большего количества хранилищ данных, используемых в Airbnb, таких как DynamoDB, Redis и т. Д.

Альтернативы

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

  • Охват хранилищ данных: нам нужен был инструмент, который мог бы охватить большинство хранилищ данных, существующих в нашей экосистеме, поскольку создание настраиваемого инструмента для подмножества хранилищ данных потребовало бы очень тех же усилий, что и его создание для всех наших хранилищ данных. . Большинство поставщиков поддерживают только сканирование приложений SAAS и сегментов S3.
  • Индивидуальное сканирование: нам нужно было настроить алгоритмы сканирования. Это важно, поскольку мы хотим убедиться, что мы можем сканировать все элементы личных и конфиденциальных данных, а также обеспечить максимальную производительность (точность, отзывчивость, достоверность) для всех элементов данных. Многие поставщики поддерживают сканирование с использованием настраиваемого регулярного выражения, но ни один из них не поддерживает сканирование с использованием настраиваемой модели машинного обучения.
  • Экономическая эффективность: мы обнаружили, что для наших целей создание нашего решения было бы гораздо более рентабельным, чем использование коммерческого решения.

Заключение

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

Благодарности

Inspekt и Angmar стали возможными благодаря усилиям всех членов группы по обеспечению безопасности данных: Шэнпу Лю, Джейми Чонга, Зи Лю, Джесси Розенблума, Сергея Пичкурова, а также команды премьер-министра Джулии Клайн и Гурера Киратли. Благодарим Бо Цзэна из команды AI Labs за помощь в разработке моделей машинного обучения Inspekt. Спасибо нашему руководству, Марку Бланшу, Джой Чжан, Брендону Линчу, Полу Нихинсону и Виджая Каза за поддержку нашей работы. Поблагодарите Аарона Лу и Райана Флода из группы инженеров безопасности за их поддержку и советы. Спасибо членам группы управления данными за партнерство и поддержку нашей работы: Эндрю Луо, Шону Чену и Лиинь Тан. Спасибо Тине Нгуен и Кристи Шаан за то, что помогли водить машину и сделали эту запись в блоге возможной. Спасибо предыдущим членам команды, которые внесли большой вклад в работу: Лифенг Сангу, Бин Зенгу, Прасаду Кетане, Алексу Лейшману и Джули Триас.

Если вас интересует этот вид работы, см. Текущие вакансии на сайте https://careers.airbnb.com.

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