Мащабируема класификация на данните за сигурност и поверителност

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

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

въведение

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

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

Нашата цел е да изградим система за класифициране на данни, която се мащабира както към стабилни, така и към преходни потребителски данни, без никакви допълнителни ограничения за типа или формата на данните. Това е дръзка цел и естествено идва с предизвикателства. Даден запис на данни може да бъде дълъг хиляди символи.

Фигура 1. Потоци на онлайн и офлайн прогнозиране

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

Този документ описва как се справихме с предизвикателствата по-горе и представя бърза и мащабируема система за класификация, която класифицира елементи от данни от всички видове, формати и източници въз основа на общ набор от функции. Разширихме системната архитектура и създадохме персонализиран модел за машинно обучение за бързо класифициране на офлайн и онлайн данни. Този документ е организиран по следния начин: Раздел 2 представя цялостния дизайн на системата. Раздел 3 обсъжда частите на система за машинно обучение. Раздели 4 и 5 подчертават свързаната работа и очертават бъдещите насоки на работа.

архитектура

За да се справи с предизвикателствата на постоянните онлайн данни от мащаба на Facebook, системата за класификация има два отделни потока, които ще обсъдим подробно.

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

Първоначално системата трябва да научи за множеството информационни активи на Facebook. За всяко хранилище се събира основна информация, като например центърът за данни, съдържащ тези данни, системата, съдържаща тези данни, и активите, разположени в конкретното хранилище на данни. Това създава каталог с метаданни, който позволява на системата ефективно да извлича данни, без да претоварва клиенти и ресурси, използвани от други инженери.

Този каталог с метаданни предоставя достоверен източник за всички сканирани активи и ви позволява да проследявате състоянието на различни активи. Използвайки тази информация, приоритетът на планирането се установява въз основа на събраните данни и вътрешна информация от системата, като например времето, когато активът е последно успешно сканиран и времето, когато е създаден, както и предишните изисквания за памет и процесор за този актив, ако сканирано е преди това. След това за всеки ресурс от данни (когато ресурсите станат достъпни) се извиква задание за действително сканиране на ресурса.

Всяко задание е компилиран двоичен файл, който извършва вземане на проби от Бернули върху най-новите налични данни за всеки актив. Активът е разделен на отделни колони, където резултатът от класификацията на всяка колона се обработва независимо. Освен това системата сканира за наситени данни в колоните. Сканират се JSON, масиви, кодирани структури, URL адреси, базови 64 сериализирани данни и други. Това може значително да увеличи времето за изпълнение на сканирането, тъй като една таблица може да съдържа хиляди вложени колони в петно json.

За всеки ред, който е избран в актива с данни, системата за класификация извлича плаващите и текстовите обекти от съдържанието и асоциира всеки обект обратно към колоната, от която е взет. Резултатът от стъпката за извличане на функции е карта на всички функции за всяка колона, открита в актива с данни.

За какво са знаците?

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

1. Поверителността на първо място: Най-важното е, че концепцията за функциите ни позволява да съхраняваме в паметта само тези модели, които извличаме. Това гарантира, че съхраняваме проби с една единствена цел и никога не ги регистрираме чрез собствени усилия. Това е особено важно за непостоянни данни, тъй като услугата трябва да поддържа някакво състояние на класификация, преди да предостави прогноза.
2. Памет: Някои примери могат да бъдат дълги хиляди знака. Съхраняването на такива данни и предаването им към части от системата ненужно изразходва много допълнителни байтове. Двата фактора могат да се комбинират с течение на времето, като се има предвид, че има много ресурси с данни с хиляди колони.
3. Агрегиране на функции: Характеристиките ясно представят резултатите от всяко сканиране чрез набор от функции, което позволява на системата да комбинира резултатите от предишни сканирания на същия ресурс от данни по удобен начин. Това може да бъде полезно за обобщаване на резултати от сканиране от един ресурс от данни в множество изпълнения.

След това функциите се изпращат до услуга за прогнозиране, където използваме базирана на правила класификация и машинно обучение, за да прогнозираме етикетите с данни на всяка колона. Услугата разчита както на класификатори на правила, така и на машинно обучение и избира най-добрата прогноза, дадена от всеки обект на прогноза.

Класификаторите на правилата са ръчни евристики, те използват изчисления и коефициенти за нормализиране на обект в диапазон от 0 до 100. След като такъв първоначален резултат бъде генериран за всеки тип данни и име на колона, свързани с тези данни, той не се включва в никаква "забрана списъци", Класификаторът на правилата избира най-високия нормализиран резултат сред всички типове данни.

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

Услугата за прогнозиране съхранява резултатите за всяка колона заедно с метаданни относно времето и състоянието на сканирането. Всички потребители и процеси надолу по веригата, които зависят от тези данни, могат да ги четат от ежедневно публикувания набор от данни. Този набор агрегира резултатите от всички тези задания за сканиране или API на каталог с данни в реално време. Публикуваните прогнози са основата за автоматично прилагане на политиките за поверителност и сигурност.

И накрая, след като услугата за прогнозиране запише всички данни и всички прогнози бъдат съхранени, нашият API за каталог на данни може да върне всички прогнози за типа данни за ресурса в реално време. Всеки ден системата публикува набор от данни, съдържащ всички най-нови прогнози за всеки актив.

Променливи данни

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

Тук API приема два основни аргумента: групиращия ключ и необработените данни, които трябва да бъдат предвидени. Услугата извършва същото извличане на обекти, както е описано по-горе, и групира обектите заедно за един и същи ключ. Тези функции се поддържат и в кеша за постоянство за възстановяване при повреда. За всеки ключ за групиране услугата гарантира, че е видяла достатъчно проби, преди да извика услугата за прогнозиране, следвайки процеса, описан по-горе.

Оптимизация

За да сканираме някои хранилища, ние използваме библиотеки и техники за оптимизиране на четенето от горещо хранилище [2] и гарантираме, че няма смущения от други потребители, които имат достъп до същото хранилище.

За изключително големи таблици (50+ петабайта), въпреки всички оптимизации и ефективност на паметта, системата работи, за да сканира и изчисли всичко, преди да изчерпи паметта. В крайна сметка сканирането се изчислява изцяло в паметта и не се съхранява по време на сканирането. Ако големите таблици съдържат хиляди колони с неструктурирани групи от данни, заданието може да се провали поради недостатъчни ресурси на паметта при извършване на прогнози върху цялата таблица. Това ще доведе до намалено покритие. За да се борим с това, ние оптимизирахме системата да използва скоростта на сканиране като прокси за това колко добре системата се справя с текущото натоварване. Използваме скоростта като предсказващ механизъм, за да видим проблеми с паметта и да изчислим предсказуемо картата на характеристиките. В същото време използваме по-малко данни от обикновено.

Сигнали за данни

Системата за класифициране е толкова добра, колкото и сигналите от данните. Тук ще разгледаме всички сигнали, използвани от класификационната система.

• Базирано на съдържание: Разбира се, първият и най-важен сигнал е съдържанието. Извадката на Bernoulli се извършва върху всеки актив от данни, който сканираме и извличаме функции въз основа на съдържанието на данните. Много знаци идват от съдържанието. Възможни са всякакъв брой плаващи обекти, които представляват изчисления за това колко пъти е видян определен тип проба. Например, може да имаме признаци за броя на имейлите, видяни в извадка, или признаци за това колко емотикони се виждат в извадка. Тези изчисления на характеристиките могат да бъдат нормализирани и обобщени при различни сканирания.
• Произход на данни: Важен сигнал, който може да помогне, когато съдържанието се е променило от родителската таблица. Често срещан пример са хеширани данни. Когато данните в дъщерна таблица се хешират, те често идват от родителската таблица, където остават чисти. Данните за родословието помагат за класифицирането на определени типове данни, когато не се четат ясно или са преобразувани от таблица нагоре по веригата.
• Анотации: Друг висококачествен сигнал, който помага при идентифицирането на неструктурирани данни. Всъщност анотациите и данните за произхода могат да работят заедно, за да разпространяват атрибути в различни активи с данни. Анотациите помагат да се идентифицира източникът на неструктурирани данни, докато данните за родословието могат да помогнат за проследяване на потока от тези данни в цялото хранилище.
• Инжектирането на данни е техника, при която специални, нечетливи знаци се въвеждат умишлено в известни източници на известни типове данни. След това, когато сканираме съдържание със същата нечетима последователност от знаци, можем да заключим, че съдържанието идва от този известен тип данни. Това е друг сигнал за качествени данни, подобен на анотациите. С изключение на това, че откриването на базата на съдържание помага за откриването на въведените данни.

Измерване на показатели

Важен компонент е строга методология за измерване на показатели. Основните показатели за итерацията за подобряване на класификацията са прецизност и запомняне на всеки етикет, като резултатът F2 е най-важен.

За изчисляване на тези показатели е необходима независима методология за етикетиране на активи от данни, която е независима от самата система, но може да се използва за директно сравнение с нея. По-долу описваме как събираме основната истина от Facebook и я използваме, за да обучим нашата система за класификация.

Събиране на надеждни данни

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

• Конфигурации на платформа за регистриране: определени полета в таблиците на кошерите се попълват с данни от определен тип. Използването и разпространението на тези данни служи като надежден източник на истина.
• Ръчно етикетиране: Разработчиците, поддържащи системата, както и външните етикети са обучени да етикетират колони. Това обикновено работи добре за всички типове данни в склада и може да бъде основният източник на истина за някои неструктурирани данни, като данни за съобщения или потребителско съдържание.
• Колоните от родителските таблици могат да бъдат маркирани или анотирани като съдържащи определени данни и ние можем да проследим тези данни в детските таблици.
• Извличане на нишки за изпълнение: нишките за изпълнение във Facebook носят специфични типове данни. Използвайки нашия скенер като сервизна архитектура, можем да вземаме проби от потоци, които имат известни типове данни, и да ги изпращаме през системата. Системата обещава да не съхранява тези данни.
• Примерни таблици: Големи кошерни таблици, за които е известно, че съдържат целия корпус от данни, могат също да се използват като данни за обучение и да се прехвърлят през скенера като услуга. Това е чудесно за таблици с пълен набор от типове данни, така че произволното вземане на проби от колона е еквивалентно на вземане на проби от целия набор от този тип данни.
• Синтетични данни: Можем дори да използваме библиотеки, които генерират данни в движение. Това работи добре за прости, публични типове данни като адрес или GPS.
• Data Stewards: Програмите за поверителност обикновено използват data stewards за ръчно присвояване на политики на части от данни. Това служи като много точен източник на истина.

Ние комбинираме всеки основен източник на истина в един корпус с всички тези данни. Най-голямото предизвикателство с валидността е да се уверите, че тя е представителна за хранилището на данни. В противен случай двигателите за класифициране могат да претренират. За да се бори с това, всички горепосочени източници се използват за осигуряване на баланс при обучение на модели или изчисляване на показатели. В допълнение, хората, етикетиращи, еднакво вземат проби от различни колони в хранилището и етикетират съответно данните, така че събирането на основната истина да остане безпристрастно.

Непрекъсната интеграция

За да се осигури бърза итерация и подобрение, е важно винаги да се измерва производителността на системата в реално време. Ние можем да измерим всяко подобрение на класификацията спрямо системата днес, така че да можем тактически да направляваме бъдещи подобрения въз основа на данни. Тук разглеждаме как системата завършва обратната връзка, която се предоставя от валидни данни.

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

По този начин сравняваме резултатите от класификацията на кандидата за освобождаване и производствения модел в реално време.

Докато наборите от данни сравняват характеристиките на 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)).

библиография

1. Дейвид Бен-Дейвид, Тамар Домани и Абигейл Тарем. Класификация на корпоративни данни с помощта на семантични уеб технологии. В Peter F.Ï Patel-Schneider, Yue Pan, Pascal Hitzler, Peter Mika, Lei Zhang, Jeff Z. Pan, Ian Horrocks и Birte Glimm, редактори, Семантичната мрежа – ISWC 2010, стр. 66–81, Берлин, Хайделберг, 2010 г. Springer Berlin Heidelberg.
2. Субраманиан Муралидхар, Уайът Лойд, Сабясачи Рой, Кори Хил, Ърнест Лин, Уейвен Лиу, Сатадру Пан, Шива Шанкар, Вишванат Сивакумар, Линпенг Танг и Санджив Кумар. f4: Топлата BLOB система за съхранение на Facebook. в 11-ти симпозиум на USENIX за проектиране и внедряване на операционни системи (OSDI 14), страници 383–398, Broomfield, CO, октомври 2014 г. Асоциация USENIX.
3. Томас Миколов, Иля Суцкевер, Кай Чен, Грег С Корадо и Джеф Дийн. Разпределени представяния на думи и фрази и тяхната композиция. В C. J. C. Burges, L. Bottou, M. Welling, Z. Ghahramani и K. Q. Weinberger, редактори, Напредък в системите за обработка на невронна информация 26, страници 3111–3119. Curran Associates, Inc., 2013 г.
4. Сергей Йофе и Кристиан Сегеди. Пакетно нормализиране: Ускоряване на задълбочено мрежово обучение чрез намаляване на вътрешното ковариатно изместване. Във Франсис Бах и Дейвид Блей, редактори, Доклади на 32-та международна конференция за машинно обучение, том 37 от Сборник на изследванията на машинното обучение, страници 448–456, Лил, Франция, 07–09 юли 2015 г. PMLR.
5. Лео Брейман. Случайни гори. Мах. Уча., 45(1):5–32, октомври 2001 г.
6. Thair Nu Phyu. Проучване на класификационни техники в извличането на данни.
7. X. Шу, Д. Яо и Е. Бертино. Запазващо поверителността откриване на излагане на чувствителни данни. Транзакции на IEEE за информационна криминалистика и сигурност, 10(5):1092–1103, 2015.
8. Zhemin Yang, Min Yang, Yuan Zhang, Guofei Gu, Peng Ning и Xiaoyang Wang. Appintent: Анализиране на предаването на чувствителни данни в android за откриване на изтичане на поверителност. стр. 1043–1054, 11 2013 г.
9. Qizhe Xie, Zihang Dai, Eduard H. Hovy, Minh-Thang Luong и Quoc V. Le. Неконтролирано увеличаване на данните.

Научете подробности за това как да получите търсена професия от нулата или ниво нагоре по отношение на умения и заплата, като вземете онлайн курсове SkillFactory:

• Преподаване на професията Data Science от нулата (12 месеца)
• Курс за машинно обучение (12 седмици)
• Курс за напреднали "Machine Learning Pro + Deep Learning" (20 седмици)
• Курс „Математика и машинно обучение за наука за данни“ (20 седмици)

Още курсове

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

Източник: www.habr.com