Класифікація даних на основі контенту – це відкрите завдання. Традиційні системи запобігання втраті даних (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 ми можемо передавати необроблені зразки рядків, які витягнуті безпосередньо з кожного ресурсу даних. Крім того, моделі машинного навчання можуть навчатися безпосередньо на кожній вибірці, а не на сотнях розрахунків ознак, які лише намагаються наблизити вибірку. Тому є кілька причин:
- Конфіденційність насамперед: найголовніше, поняття ознак дозволяє нам зберігати у пам'яті лише ті зразки, які ми отримуємо. Це гарантує, що ми зберігаємо зразки для єдиної мети та ніколи не логуємо їх нашими власними зусиллями. Це особливо важливо для нестійких даних, оскільки сервіс повинен підтримувати певний стан класифікації, перш ніж прогнозувати.
- Пам'ять: деякі семпли можуть мати довжину тисячі символів. Зберігання таких даних та передача їх частинам системи без потреб споживає багато додаткових байтів. Два чинники можуть об'єднатися з часом, враховуючи, що є багато ресурсів даних із тисячами стовпців.
- Агрегування ознак: за допомогою ознак через їх набір чітко надаються результати кожного сканування, що дозволяє системі об'єднувати результати попередніх сканувань одного і того ж ресурсу даних зручним способом. Це може бути корисним для агрегування результатів сканування одного ресурсу даних у декількох запусках.
Потім ознаки відправляються до сервісу прогнозування, де ми використовуємо класифікацію на основі правил і машинне навчання для прогнозування міток даних кожного стовпця. Сервіс спирається як на класифікатори правил, так і на машинне навчання та вибирає найкращий прогноз, даний із кожного об'єкта прогнозування.
Класифікатори правил - це ручна евристика, вона використовує розрахунки та коефіцієнти для нормалізації об'єкта в діапазоні від 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 для моделі дозволило нам рухатися швидше, давши можливість розробникам поза командою швидко вносити та тестувати зміни.
При проектуванні архітектури було важливо моделювати розріджені (наприклад, текстові) та щільні (наприклад, числові) об'єкти окремо через їх внутрішні відмінності. Для остаточної архітектури також було важливо розгорнути параметри, щоб знайти оптимальне значення швидкості навчання, розміру пакета та інших гіперпараметрів. Вибір оптимізатора також був важливим гіперпараметром. Ми виявили, що популярний оптимізатор Адамчасто призводить до перенавчання, тоді як модель з SGD стабільніше. Були додаткові нюанси, які ми мали включити безпосередньо до моделі. Наприклад, статичні правила, які гарантували, що модель робить детермінований прогноз, коли ознака має певне значення. Ці статичні правила визначено нашими клієнтами. Ми виявили, що включення їх безпосередньо до моделі призвело до створення більш самодостатньої та надійної архітектури, на відміну від реалізації етапу постобробки для обробки цих спеціальних граничних випадків. Також зверніть увагу, що під час тренування ці правила відключені, щоб не заважати тренувальному процесу градієнтного спуску.
Проблеми
Однією з проблем було збирання високоякісних достовірних даних. Модель потребує достовірності для кожного класу, щоб вона могла вивчати асоціації між об'єктами та мітками. У попередньому розділі ми обговорювали методи збору даних, як для вимірювання системи, так і для навчання моделей. Аналіз показав, що такі класи даних, як номери кредитних карток та банківських рахунків не дуже поширені у нашому сховищі. Це ускладнює збирання великих обсягів достовірних даних для навчання моделей. Для вирішення цієї проблеми ми розробили процеси отримання синтетичних достовірних даних для цих класів. Ми генеруємо такі дані для чутливих типів, включаючи SSN, номери кредитних карток и IBAN-Номери, для яких модель не могла прогнозувати раніше. Цей підхід дозволяє обробляти конфіденційні типи даних без ризику конфіденційності, пов'язаного з приховуванням реальних конфіденційних даних.
Крім проблем достовірних даних є відкриті архітектурні проблеми, над якими ми працюємо, такі як ізоляція змін и рання зупинка. Ізоляція змін важлива для того, щоб при внесенні різних змін до різних частин мережі вплив був ізольований від конкретних класів і не надавав широкого впливу на загальну продуктивність прогнозування. Покращення критеріїв ранньої зупинки також має вирішальне значення для того, щоб ми могли зупинити тренувальний процес у стабільній точці для всіх класів, а не в тій точці, де деякі класи перенавчаються, а інші ні.
Важливість ознаки
Коли модель вводиться новий ознака, хочемо знати його загальний впливом геть модель. Ми також хочемо переконатися, що прогнози інтерпретовані людиною, щоб можна було точно зрозуміти які ознаки використовуються для кожного типу даних. Для цього ми розробили та ввели покласову важливість ознак моделі PyTorch. Зверніть увагу, що це відрізняється від загальної важливості ознаки, яка зазвичай підтримується, тому що вона не говорить нам, які ознаки важливі для певного класу. Ми вимірюємо важливість об'єкта, обчислюючи збільшення помилки прогнозу після перестановки об'єкта. Ознака є «важливою», коли перестановка значень збільшує помилку моделі, оскільки в цьому випадку модель покладалася на ознаку прогнозування. Ознака "неважливий", коли перетасовування його значень залишає помилку моделі незмінною, оскільки в цьому випадку модель ігнорувала його [5].
Важливість ознаки для кожного класу дозволяє зробити модель, що інтерпретується, щоб ми могли бачити, на що модель звертає увагу при прогнозуванні мітки. Наприклад, коли ми аналізуємо АДР, то гарантуємо, що пов'язана з адресою ознака, така як AddressLinesCount, Займає високе місце в таблиці важливості ознак для кожного класу, щоб наша людська інтуїція добре узгоджувалась з тим, що вивчила модель.
Оцінка
Важливо визначити єдину метрику успіху. Ми вибрали F2 — баланс між відкликанням та точністю (зміщення відкликання трохи більше). Відкликання важливіше для використання конфіденційності, ніж точність, тому що для команди вкрай важливо не пропустити жодних конфіденційних даних (забезпечуючи при цьому розумну точність). Фактичні дані оцінки продуктивності F2 нашої моделі виходять за межі цієї статті. Тим не менш, при ретельному налаштуванні ми можемо досягти високого (0,9+) бала F2 для найважливіших чутливих класів.
Пов'язана робота
Існує безліч алгоритмів автоматичної класифікації неструктурованих документів з використанням різних методів, таких як зіставлення шаблонів, пошук подібності документів та різні методи машинного навчання (байєсовські, дерева рішень, k-найближчих сусідів та багато інших) [6]. Будь-який з них можна використовувати як частину класифікації. Проте проблема масштабованості. Підхід до класифікації у цій статті зміщений у бік гнучкості та продуктивності. Це дозволяє нам підтримувати нові класи у майбутньому та підтримувати низьку затримку.
Існує також маса робіт зі зняття відбитків із даних. Наприклад, автори [7] описали рішення, яке фокусується на проблемі уловлювання витоків конфіденційних даних. Основне припущення полягає у можливості відбитка даних, щоб зіставити його з набором відомих конфіденційних даних. Автори [8] описують аналогічну проблему витоку конфіденційності, але їх рішення засноване на конкретній архітектурі Android і класифікується тільки в тому випадку, коли дії користувача призвели до відправки особистої інформації або якщо в базовому додатку витік даних користувача. Ситуація тут дещо відрізняється, оскільки дані користувача також можуть бути сильно неструктурованими. Тому нам потрібна складніша техніка, ніж зняття відбитків.
Нарешті, щоб впоратися з нестачею даних деяких типів конфіденційних даних, ми ввели синтетичні дані. Існує великий обсяг літератури з аугментації даних, наприклад, автори [9] досліджували роль ін'єкції шуму під час навчання і спостерігали позитивні результати в контрольованому навчанні. Наш підхід до конфіденційності відрізняється, тому що введення зашумлених даних може бути контрпродуктивним, і натомість ми фокусуємося на високоякісних синтетичних даних.
Висновок
У цій статті ми надали систему, яка може класифікувати фрагмент даних. Це дозволяє нам створювати системи забезпечення дотримання політик конфіденційності та безпеки. Ми показали, що масштабована інфраструктура, безперервна інтеграція, машинне навчання та високоякісні дані про достовірність даних відіграють ключову роль в успіху багатьох наших ініціатив у сфері конфіденційності.
Є багато напрямків майбутньої роботи. Вона може включати забезпечення підтримки несхематизованих даних (файлів), класифікацію як типу даних, а й рівня чутливості, і навіть використання самоконтрольованого навчання безпосередньо під час навчання шляхом генерації точних синтетичних прикладів. Які, у свою чергу, допоможуть моделі зменшити втрати на найбільшу величину. Майбутня робота може також зосередитися на робочому процесі розслідування, де ми виходимо за рамки виявлення та надаємо аналіз причин різних порушень конфіденційності. Це допоможе в таких випадках, як аналіз чутливості (тобто чи чутливість конфіденційності типу даних високої (наприклад, IP користувача) або низької (наприклад, внутрішній IP Facebook)).
Бібліографія
- David Ben-David, Tamar Domany, і Abigail Tarem. Enterprise data clasification using semantic web technologies. У Петра Ф.І Патель-Шнейдера, Юї Пана, Паскаля Хітлера, Петра Міка, Леї Жанг, Джефа З. Пан, Іан Хорокс, і Бірте Глім, editors, The Semantic Web – ISWC 2010, 66–81, Berlin, Heidelberg, 2010. Springer Berlin Heidelberg.
- Subramanian Muralidhar, Wyatt Lloyd, Sabyasachi Roy, Cory Hill, Ernest Lin, Weiwen Liu, Satadru Pan, Shiva Shankar, Viswanath Sivakumar, Linpeng Tang, і Sanjeev Kumar. f4: Facebook's warm BLOB storage system. In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14), pages 383–398, Broomfield, CO, October 2014. USENIX Association.
- Tomas Mikolov, Ilya Sutskever, Kai Chen, Greg S Corrado, і Jeff Dean. Розповсюджені тлумачення слів і фраз і їх композиційність. В CJC Burges, L. Bottou, M. Welling, Z. Ghahramani, і KQ Weinberger, editors, Досягнення в нейронних системах обробки інформації 26, pages 3111–3119. Curran Associates, Inc., 2013.
- Sergey Ioffe та Christian Szegedy. Batch normalization: Accelerating deep network training by reduction internal covariate shift. In Francis Bach і David Blei, editors, Процедури 32-ї міжнародної конференції на Machine Learning, том 37 р Proceedings of Machine Learning Research, pages 448–456, Lille, France, 07–09 Jul 2015. PMLR.
- Leo Breiman. Random forests. мах. вчитися.45(1):5–32, October 2001.
- Thair Nu Phyu. Survey of classification techniques в data mining.
- X. Shu, D. Yao, та E. Bertino. Privacy-preserving detection of sensitive data exposure. IEEE Transactions on Information Forensics and Security, 10(5):1092–1103, 2015.
- Zhemin Yang, Min Yang, Yuan Zhang, Guofei Gu, Peng Ning, і Xiaoyang Wang. Appintent: Analyzing sensitive data transmission в android для privacy leakage detection. pages 1043-1054, 11 2013.
- Qizhe Xie, Zihang Dai, Eduard H. Hovy, Minh-Thang Luong, і Quoc V. Le. Unsupervised data augmentation.
Дізнайтеся подробиці, як отримати затребувану професію з нуля або Level Up за навичками та зарплатою, пройшовши онлайн-курси SkillFactory:
- (12 місяців)
- (12 тижнів)
- (20 тижнів)
- (20 тижнів)
Ще курси
- (9 місяців)
- (8 місяців)
- (9 місяців)
- (12 місяців)
- (18 місяців)
- (12 місяців)
- (9 місяців)
- (7 місяців)
Джерело: habr.com