Намаляване на неяснотата във вашите роли и правила за сигурност на данните

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

Добре... може би малко драматично, но инженерите по данни често се чувстват като второстепенна задача, наложена им, което се отразява негативно на способността им да вършат работата си. Вярвам, че можем да освободим Лари законно.

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

Екипите по сигурността трябва да приличат повече на съдия във футболен мач. Те помагат на протичането на играта, но в никакъв случай не са основното събитие. Тълпите дойдоха да видят отборите.

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

След като дъвчех това до края на сесията, стотинката падна.

Правилата често са двусмислени или в най-добрия случай подлежат на тълкуване.

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

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

Ето няколко примера за сиви зони:

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

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

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

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

Както неяснотата, така и неотложността на сигурността изискват часове и часове дискусии и преработки, без да се докаже много.

Трябва да намалим двусмислието и бързо да включим промяната, ако възникне необходимост.

Екипите, които наблюдавах, които са по-малко засегнати от този проблем, не са непременно тези, които спазват стриктно правилата, а по-скоро тези компании, където правилата са по-ясни и по-обективно дефинирани. Това води до по-малко разногласия и по-малко затруднения.

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

И така, как да премахнем неяснотата? Или, казано по-информационно, как да сме сигурни, че имаме правилните изисквания?

Е, ние го правим с други събирания на изисквания от... завинаги. Крайните потребители рядко могат да опишат своите изисквания в детайли, но със сигурност могат да ви кажат какво не искат, след като го видят. Това важи и за сигурността и поверителността на данните.

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

Опитвам се да обясня защо в тази диаграма.

Базирането на правила и роли върху повтарящи се модели отприщва ефект на доминото, което води до по-бърз резултат, по-високо доверие и ангажирани заинтересовани страни.

Ето някои практически стъпки за използване на автоматизацията в сигурността на данните.

Дефинирайте правила на бизнес и нетехническо ниво

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

Изградете шаблони, които приемат политиката за „многословие“ и я изпълняват на вашата целева платформа

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

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

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

Платформа: Снежинка

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

Използване на автоматизация: PII данните се маркират от собствениците на изходни данни в каталог с данни или инструмент за моделиране на данни. Инструментът за автоматизация/домашно изградената машина за шаблони използва тези метаданни, за да генерира хранилище с необработени данни, като всички PII данни се съхраняват в отделни сателити. Ако PII данните са бизнес ключ, тогава тези бизнес ключове трябва да бъдат изключени от всякакви артефакти на презентационния слой. Трябва да има ясно, логично разделение между презентационните слоеве и другите. Автоматизирани тестове за проверка дали в метаданните на презентационния слой не са включени PII данни. Шаблони за генериране на политика за маскиране на Snowflake и присвояване на политика и обекти на потребителски роли.

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

Прототипирайте и бързо попаднете в ръцете на точните хора

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

Създайте автоматизирани тестове

Изградете автоматизирани тестове, така че крайните потребители да трябва да направят някои съществени тестове само веднъж. След това само за големи промени в политиката или извънредни аномалии.

Автоматизираните тестове в моя пример са (но не само) следните:

  • Проверка дали PII данните винаги са присвоени на политика за маскиране
  • Обектите на непрезентационния слой са разделени в роли от обектите на презентационния слой

Обратната връзка от потребителите трябва да накара или промяна на правилата, или промяна в правилата за автоматизация (шаблони). Независимо от резултата, изпълнението трябва да бъде бързо. Портите за подписване за сигурност са необходими само когато се изисква промяна в шаблона.

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

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