https://habr.com/ru/company/skillfactory/blog/520376/

• Блог компании SkillFactory
• Информационная безопасность
• Python
• Big Data
• Data Engineering

Классификация данных на основе контента — это открытая задача. Традиционные системы предотвращения потери данных (DLP) решают эту проблему путем снятия отпечатков с соответствующих данных и мониторинга конечных точек для снятия отпечатков. Учитывая большое количество постоянно меняющихся ресурсов данных в Facebook, этот подход не только не масштабируется, но и неэффективен для определения того, где находятся данные. Эта статья посвящена сквозной системе, построенной для обнаружения чувствительных семантических типов в Facebook в масштабе и автоматического обеспечения хранения данных и контроля доступа.

Описанный здесь подход — это наша первая сквозная система конфиденциальности, которая пытается решить эту проблему путем включения сигналов данных, машинного обучения и традиционных методов снятия отпечатков для отображения и классификации всех данных в Facebook. Описанная система эксплуатируется в производственной среде, достигая среднего балла F2 0,9+ по различным классам конфиденциальности при обработке большого количества ресурсов данных в десятках хранилищ. Представляем перевод публикации Facebook на ArXiv о масштабируемой классификации данных для обеспечения безопасности и конфиденциальности на основе машинного обучения.

Введение

Сегодня организации собирают и хранят большие объемы данных в различных форматах и местах [1], затем данные потребляются во многих местах, иногда копируются или кэшируются несколько раз, в результате чего ценная и конфиденциальная деловая информация рассеивается по многим корпоративным хранилищам данных. Когда от организации требуется выполнить определенные правовые или нормативные требования, например, соблюдать нормативные акты в ходе гражданского судопроизводства, возникает необходимость сбора данных о местоположении нужных данных. Когда в постановлении о конфиденциальности говорится, что организация должна маскировать все номера социального страхования (SSN) при передаче личной информации неавторизованным субъектам, естественным первым шагом является поиск всех SSN в хранилищах данных всей организации. При таких обстоятельствах классификации данных приобретает решающее значение [1]. Система классификации позволит организациям автоматически обеспечить соблюдение конфиденциальности и политики безопасности, такие как включение политики управления доступом, сохранение данных. Facebook представляет систему, построенную нами в Facebook, которая использует множество сигналов данных, масштабируемую системную архитектуру и машинное обучение для обнаружения чувствительных семантических типов данных.

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

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


Рисунок 1. Потоки онлайн и офлайн-прогнозирования

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

В этой статье описывается, как мы справлялись с проблемами выше, и представляется быстрая и масштабируемая система классификации, которая классифицирует элементы данных всех типов, форматов и источников на основе общего набора признаков. Мы расширили системную архитектуру и создали специальную модель машинного обучения для быстрой классификации офлайн и онлайн-данных. Эта статья организована следующим образом: в разделе 2 представляется общий дизайн системы. В разделе 3 обсуждаются части системы машинного обучения. В разделах 4 и 5 рассказывается о связанной работе, намечается будущее направление работы.

Архитектура

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

Устойчивые данные

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

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

Каждое задание — это скомпилированный двоичный файл, который выполняет выборку Бернулли по последним данным, доступным для каждого актива. Актив разбивается на отдельные столбцы, где результат классификации каждого столбца обрабатывается независимо. Кроме того, система сканирует любые насыщенные данные внутри столбцов. JSON, массивы, кодированные структуры, URL-адреса, сериализованные данные base 64 и многое другое — всё это сканируется. Это может значительно увеличить время выполнения сканирования, так как одна таблица может содержать тысячи вложенных столбцов в большом двоичном объекте json.

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

Для чего нужны признаки?

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

1. Конфиденциальность прежде всего: самое главное, понятие признаков позволяет нам хранить в памяти только те образцы, которые мы извлекаем. Это гарантирует, что мы храним образцы для единственной цели и никогда не логируем их нашими собственными усилиями. Это особенно важно для неустойчивых данных, поскольку сервис должен поддерживать некоторое состояние классификации, прежде чем предоставлять прогноз.
2. Память: некоторые сэмплы могут иметь длину в тысячи символов. Хранение таких данных и передача их частям системы без необходимости потребляет много дополнительных байтов. Два фактора могут объединиться с течением времени, учитывая, что существует много ресурсов данных с тысячами столбцов.
3. Агрегирование признаков: с помощью признаков через их набор четко представляются результаты каждого сканирования, что позволяет системе объединять результаты предыдущих сканирований одного и того же ресурса данных удобным способом. Это может быть полезно для агрегирования результатов сканирования одного ресурса данных в нескольких запусках.
   

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

Классификаторы правил — это ручная эвристика, она использует расчёты и коэффициенты для нормализации объекта в диапазоне от 0 до 100. Как только такой начальный балл генерируется для каждого типа данных и имени столбца, связанного с этими данными, не попадает ни в какие «запрещающие списки», классификатор правил выбирает самый высокий нормализованный балл среди всех типов данных.

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

Служба прогнозирования хранит результаты для каждого столбца вместе с метаданными, касающимися времени и состояния сканирования. Любые потребители и нижестоящие процессы, зависящие от этих данных, могут считывать их из ежедневно публикуемого набора данных. Этот набор агрегирует результаты всех этих заданий сканирования, или API реального времени каталога данных. Опубликованные прогнозы — фундамент автоматического применения политики конфиденциальности и безопасности.

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

Неустойчивые данные

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

Здесь API принимает два основных аргумента: ключ группировки и необработанные данные, которые должны быть спрогнозированы. Сервис выполняет то же извлечение объектов, что описано выше, и группирует объекты вместе для одного и того же ключа. Эти признаки также поддерживаются в сохраняемом кэше для восстановления после отказа. Каждому ключу группировки служба гарантирует, что перед вызовом сервиса прогнозирования она видела достаточно выборок в соответствии с процессом, описанным выше.

Оптимизация

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

Для чрезвычайно больших таблиц (50 + петабайт), несмотря на все оптимизации и эффективность памяти, система работает над сканированием и вычислением всего, прежде чем закончится память. В конце концов, сканирование полностью вычисляется в памяти и не сохраняется в течение сканирования. Если большие таблицы содержат тысячи столбцов с неструктурированными сгустками данных, задание может завершиться неудачей из-за нехватки ресурсов памяти при выполнении прогнозов для всей таблицы. Это приведет к уменьшению покрытия. Чтобы бороться с этим, мы оптимизировали систему, чтобы использовать скорость сканирования в качестве посредника в том, насколько хорошо система справляется с текущей нагрузкой. Мы используем скорость как прогностический механизм, тчобы видеть проблемы с памятью и при упреждающем расчете карты объектов. При этом мы используем меньше данных, чем обычно.

Сигналы данных

Система классификации хороша настолько, насколько хороши сигналы от данных. Здесь мы рассмотрим все сигналы, используемые системой классификации.

• На основе содержимого: конечно, первый и важнейший сигнал — это содержимое. Выполняется выборка Бернулли по каждому активу данных, который мы сканируем и извлекаем признаки по содержанию данных. Многие признаки происходят из содержимого. Возможно любое количество плавающих объектов, которые представляют рассчеты того, сколько раз был замечен определенный тип образца. Например, у нас могут быть ротзнаки количества электронных писем, увиденных в выборке, или признаки того, сколько смайликов замечено в выборке. Эти расчеты признаков можно нормализовать и агрегировать по различным сканированиям.
• Происхождения данных: важный сигнал, который может помочь, когда содержимое изменилось из родительской таблицы. Распространенный пример — хэшированные данные. Когда данные в дочерней таблице хэшируются, они часто поступают из родительской таблицы, где остаются в открытом виде. Данные о происхождении помогают классифицировать определенные типы данных, когда они не читаются четко или преобразованы из таблицы вверх по потоку.
• Аннотации: еще один высококачественный сигнал, помогающий в идентификации неструктурированных данных. Фактически аннотации и данные происхождения могут работать вместе для распространения атрибутов между различными активами данных. Аннотации помогают идентифицировать источник неструктурированных данных, в то время как данные о происхождении могут помочь отслеживать поток этих данных по всему хранилищу.
• Инъекция данных — это метод, когда намеренно вводятся специальные, нечитаемые символы в известные источники с известными типами данных. Затем, всякий раз, когда мы сканируем содержимое с одной и той же нечитаемой последовательностью символов, можно сделать вывод, что содержимое исходит из этого известного типа данных. Это еще один качественный сигнал данных, подобный аннотациям. За исключением того, что обнаружение на основе контента помогает обнаружить введенные данные.

Измерение метрик

Важный компонент — строгая методологии измерения метрик. Основными метриками итерации улучшения классификации — точность и отзыв каждой метки, причем оценка F2 — важнейшая.

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

Сбор достоверных данных

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

• Конфигурации платформы логирования: определенные поля в таблицах улья заполняются данными, которые относятся к определенному типу. Использование и распространение этих данных служит надежным источником достоверных данных.
• Ручная маркировка: разработчики, поддерживающие систему, а также внешние маркировщики обучены маркировать столбцы. Это обычно хорошо работает для всех типов данных в хранилище, и может быть основным источником достоверности для некоторых неструктурированных данных, таких как данные сообщений или пользовательский контент.
• Столбцы из родительских таблиц могут помечаться или аннотироваться как содержащие определенные данные, и мы можем отслеживать эти данные в нижестоящих таблицах.
• Выборка потоков выполнения: потоки выполнения в Facebook несут данные определенного типа. Используя наш сканер в качестве сервисной архитектуры, мы можем делать выборку потоков, имеющих известные типы данных, и отправлять их через систему. Система обещает не хранить эти данные.
• Таблицы выборки: большие таблицы улья, которые, как известно, содержат весь корпус данных, также могут использоваться в качестве обучающих данных и передаваться через сканер как сервис. Это отлично подходит для таблиц с полным диапазоном типов данных, так что выборка столбца случайным образом эквивалентна выборке всего множества этого типа данных.
• Синтетические данные: мы можем даже использовать библиотеки, которые генерируют данные на лету. Это хорошо работает для простых, общедоступных типов данных, таких как адрес или GPS.
• Стюарды данных: программы конфиденциальности, как правило, используют стюардов данных для ручного закрепления политик за частями данных. Это служит высокоточным источником достоверности.

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

Непрерывная интеграция

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

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

Так мы сравниваем результаты классификации релиз-кандидата и производственной модели в режиме реального времени.

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

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

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

Некоторые результаты

Маркируется более 100 различных типов данных с высокой точностью. Хорошо структурированные типы, такие как электронные письма и телефонные номера, классифицируются с оценкой f2 более 0,95. Свободные типы данных, такие как пользовательский контент и имя, также работают очень хорошо, с F2-баллами более 0,85.

Ежедневно классифицируется большое количество отдельных столбцов устойчивых и неустойчивых данных во всех хранилищах. Более 500 терабайт сканируются ежедневно в более чем 10 хранилищах данных. Охват большинства из этих хранилищ составляет более 98%.

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


Рис. 2. Диаграмма, описывающая непрерывный поток интеграции, чтобы понимать, как RC-объекты генерируются и отправляются в модель.


Рисунок 3. Высокоуровневая диаграмма компонента машинного обучения.

Компонент системы машинного обучения

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

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

Реализованная модель изучает векторные представления [3] над плотными и разреженными объектами отдельно. Затем они объединяются, чтобы сформировать вектор, который проходит через серию этапов пакетной нормализации [4] и нелинейности для получения конечного результата. Конечный результат — число с плавающей точкой между [0-1] для каждой метки, указывающий вероятность того, что пример принадлежит данному типу чувствительности. Использование PyTorch для модели позволило нам двигаться быстрее, дав возможность разработчикам вне команды быстро вносить и тестировать изменения.

При проектировании архитектуры было важно моделировать разреженные (например, текстовые) и плотные (например, числовые) объекты отдельно из-за их внутреннего различия. Для окончательной архитектуры также было важно выполнить развертку параметров, чтобы найти оптимальное значение скорости обучения, размера пакета и других гиперпараметров. Выбор оптимизатора также был важным гиперпараметром. Мы обнаружили, что популярный оптимизатор Adamчасто приводит к переобучению, тогда как модель с SGD стабильнее. Были дополнительные нюансы, которые мы должны были включить непосредственно в модель. Например, статические правила, которые гарантировали, что модель делает детерминированный прогноз, когда признак имеет определенное значение. Эти статические правила определены нашими клиентами. Мы обнаружили, что включение их непосредственно в модель привело к созданию более самодостаточной и надежной архитектуры, в отличие от реализации этапа постобработки для обработки этих специальных граничных случаев. Также обратите внимание, что во время тренировки эти правила отключены, чтобы не мешать тренировочному процессу градиентного спуска.

Проблемы

Одной из проблем был сбор высококачественных достоверных данных. Модель нуждается в достоверности для каждого класса, чтобы она могла изучать ассоциации между объектами и метками. В предыдущем разделе мы обсуждали методы сбора данных как для измерения системы, так и для обучения моделей. Анализ показал, что такие классы данных, как номера кредитных карт и банковских счетов не очень распространены в нашем хранилище. Это затрудняет сбор больших объемов достоверных данных для обучения моделей. Чтобы решить эту проблему, мы разработали процессы получения синтетических достоверных данных для этих классов. Мы генерируем такие данные для чувствительных типов, включая SSN, номера кредитных карт и IBAN-номера, для которых модель не могла прогнозировать ранее. Этот подход позволяет обрабатывать конфиденциальные типы данных без риска конфиденциальности, связанного с укрывательством реальных конфиденциальных данных.

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

Важность признака

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

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

Оценка

Важно определить единую метрику успеха. Мы выбрали F2 — баланс между отзывом и точностью (смещение отзыва немного больше). Отзыв важнее для случая использования конфиденциальности, чем точность, потому что для команды крайне важно не пропустить никаких конфиденциальных данных (обеспечивая при этом разумную точность). Фактические данные оценки производительности F2 нашей модели выходят за рамки данной статьи. Тем не менее, при тщательной настройке мы можем достичь высокого (0,9+) балла F2 для наиболее важных чувствительных классов.

Связанная работа

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

Существует также масса работ по снятию отпечатков с данных. Например, авторы в [7] описали решение, которое фокусируется на проблеме улавливания утечек конфиденциальных данных. Основное предположение заключается в возможности отпечатка с данных, чтобы сопоставить его с набором известных конфиденциальных данных. Авторы в [8] описывают аналогичную проблему утечки конфиденциальности, но их решение основано на конкретной архитектуре Android и классифицируется только в том случае, когда действия пользователя привели к отправке личной информации или если в базовом приложении утечка пользовательских данных. Ситуация здесь несколько отличается, поскольку пользовательские данные также могут быть сильно неструктурированными. Поэтому нам нужна более сложная техника, чем снятие отпечатков.

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

Заключение

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

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

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:

• Обучение профессии Data Science с нуля (12 месяцев)
• Курс по Machine Learning (12 недель)
• Продвинутый курс «Machine Learning Pro + Deep Learning» (20 недель)
• Курс «Математика и Machine Learning для Data Science» (20 недель)

Eще курсы

• Курс «Python для веб-разработки» (9 месяцев)
• Профессия Веб-разработчик (8 месяцев)
• Профессия аналитика с любым стартовым уровнем (9 месяцев)
• Курс по DevOps (12 месяцев)
• Профессия Java-разработчик с нуля (18 месяцев)
• Курс по JavaScript (12 месяцев)
• Профессия UX-дизайнер с нуля (9 месяцев)
• Профессия Web-дизайнер (7 месяцев)