GDPR, лични данни и syslog при използване на облачни услуги
Последните законодателни инициативи, касаещи кибер пространството налагат промени. За да бъдат анализирани тези промени е необходимо да се осветли дълбочината им. В следващите редове ще демонстрирам елементи от темата GDPR, лични данни и syslog.
Наблюдавам интересни тенценции в голяма част от компаниите, с които контактувам по отношение на GDPR. Обикновено в компаниите липсва експертиза за GDPR, лични данни и syslog. Озобщо се пропускат личните данни и връзката с облачните услуги.
Ясно се виждат две тенденции за съобразяване с GDPR:
- Едната тенденция буквално изключва техническите мерки и реорганизация на експлоатационната среда на ИКТ;
- а другата включва допълване на ИКТ с нови технически средства, за превенция на изтичането на данни например.
В следващите редове можете да прочетете анализ на част от възможностите, които предоставят syslog при въвеждането на съответствие с изискванията на GDPR.
Актуалното разширено определение за лични данни в GDPR изисква да се обръща специално внимание на данните от журналите (или дневника).
За пояснение: преводът на термини system logs според речниците с технически термини от английски език е системен журнал. Има достатъчно RFC по темата. Pа целите на настоящия текст само споменавам, че в българския превод на регламента и интерпретациите му се наблюдава явлението загубени в превода. Открих, че в някои компании този момент от спазването на закона, имам предвид GDPR, е сведен до записи в терминологията на организационните стандарти, които всъщност са незадължителни насоки…
Съдържание на системните журнали
Системните журнали съдържат записи наистина. Това са описания на технически събития, които се регистрират с цел последващо разследване и проследяване. Интензивността на създаването на тези записи често е изключително висока. В някои случаи се създават файлове с обем 500 и повече терабайта само за един ден. В директориите, в които стоят подобни файлове се извършват регистрации за:
- работата на операционната система;
- услугите (сървисите);
- драйверите;
- поведението на потребителите;
- поведението на приложенията (обработване на изключения);
- граничните състояния на хардуера (прегряване, добавяне на диск)
- опитите за нерегламентирани действия от страна на потребителите или приложенията…
Същите файлове, филтрирани в реално време дават възможности за откриване на софистични корелирани атаки от злонамерени актьори срещу платформите – сървъри, сайтове, облачни услуги, хипервайзори, машини за бази данни…
В специализираните професионални форуми за GDPR обсъждането на темата тече от преди четири години, още на етапа обсъждане на регламента.
[box] Content gGDPR, опазването на личните данни и syslog е тема, която е предмет на специалистите в областта на кибер сигурността.oes here[/box]
В случай, че IP адресите се корелират с други данни от тези журнали, или в тях се записват данни от „бисквитките“, се оказва че там се съдържат лични данни. Следователно тези данни трябва да се съхраняват само със съгласието на клиентите за ограничен период от време. Препоръчително е те да се анонимизират. В случай, че се предават на трета страна, за да бъде сведен до минимум риска. Добър пример е анонимизирането на IP адресите, преди да се появат в дашборда за анализи на големите търсещи машини.
Добрите практики, които ще запазят компаниите от проблеми с GDPR, лични данни и syslog
В журналите са записани действията на всички потребители и има доказателства за операциите над личните данни!
Вече се сещаме, че периодично логовете трябва да се изтриват, че централизираното събиране ще улесни обработването, но има и други изисквания, които са описани в съответните RFC.
Когато се използват облачни услуги за събиране и обработване на логове, доставчиците не могат да поемат пълната отговорност за данните, които им изпращате за съхранение или анализи. В света на GDPR, доставчикът на услуги често има две роли. Доставчикът обикновено действа като „Data controler“ за вашите лични данни (име, адрес, електронна поща, телефонен номер и т. н.). За вашето съдържание, както и логове, е приложима ролята „Data Processor“, в който случай сте „контролер на данни“ и вие сте отговорни за файловете с журнални записи, които изпращате до доставчика на облачни услуги.
За да бъдат полезни логовете от гледна точка на GDPR
е необходима екипна синергия на компетенции от двете проблемни области
функционалност и архитектура на подсистемата за журнализация (syslog);
и детайлно познаване на буквата на закона GDPR, лични данни и syslog.
От технологична гледна точка това означава реинженеринг на архитектурата на системата за събиране на логове в цялостната ИКТ инфраструктура на организацията.
Началото на този процес е одитът. Той трябва да даде яснота за обхвата на всички хардуерни и софтуерни компоненти на ИКТ на организацията, които са локализирани в отдалечени дейтацентрове, офиси, различни видове облачни услуги, системи за архивиране, за масово наблюдение, контрол на физическата сигурност и устройства номади (лаптопи, таблети, подвижни камери, мобилни телефони), всички облачни услуги, които се използват от номадите и целият набор от приложения, независимо с каква архитектура са конструирани и къде са разположени.
Картината се усложнява от политиките за достъп до логовете при обачните услуги, които се предоставят в режим конаематели
Целта на настоящият текст е да покаже дълбочината на мерките, които изисква връзката GDPR, лични данни и syslog, за да се постигнат:
- детайлен трекинг на действията на потребителите върху данните, които се намират във файлове, машини за бази данни и пръснати в различни сайтове в интернет;
- възможности за проследяване на действията на потребителите, които имат привилегировани права, обработващите лични данни и доказателства при претенции от стана на субектите на данни.
Какви са алтернативите на тези мерки? Как да се свържат изискванията на GDPR, лични данни и syslog. Най-често компаниите закупуват комплекс от продукти за сигурност с различни области на предназначение. Против изтичане на данни, защитни стени, за превенция от зловреден софтуер и други. Изниква въпросът за баланса между вградените в обкръжението (операционни системи, приложения, машини за бази данни, приложни сървъри и др.) възможности за защита и закупуването на допълнителни инструменти.
Оразмеряването на този баланс се налага поради следните причини:
- най-напред се нарушава принципа на Окам за неумножаване на същностите – нещо което може да се направи по лесен начин се прави по труден и сложен;
- добавянето на средства за защита увеличава повърхността за заплахи по естествен начин, тъй като защитните стени, антивирусните програми и останалите подобни също се нуждаят от ъпдейти по сигурността;
- изискванията към набора от екипни компетенции на екипите по управление на сигурността в ИКТ се увеличават;
- оскъпява се експлоатацията.
За да се постигнат тези цели е необходимо:
- да се преконфигурират всички подсистеми за syslog;
- да се организира криптиране на данните на изхода им;
- и съхраняването им в отдалечени хранилища.
Накрая остава трудната част – за да се извършат тези дейности е необходима предварителна подготовка.
На екипа на внедряване на изискванията на GDPR във взаимодействие с CERT. Последният е екипът за реагиране при компютърни инциденти. Тези екипи от своя страна могат да изпълнят изискванията на GDPR само след задълбочено обучение. То е предмет на допълнителни изследвания. За да се установят изискванията към компетентностния профил на отделните роли – DPO и останалите. Тези изисквания се оказват специфични за всяка отделна корпоративна среда от информационни технологии.
Поделянето на журнални записи между конаемателите и доставчиците на облачни услуги извиква потребност от анонимизиране и филтриране на данните.
Достачикът може да достави изглед на отделен потребител до записите от журналите на хипервайзора или на конзолата за управление на виртуалните машини, но там да се видят само данни, които касаят договорните отношения между двете страни. Например кои от служителите на доставчика са оперирали с дадена услуга SaaS и са виждали съдържанието на базата данни, но без да се вижда от кои IP адреси са се свързвали. Подобна е и ситуацията с другите два модела облачни услуги.
Литература:
The Syslog Protocol
Трансформация на SIEM при мигриране към облачни услуги
The BSD syslog Protocol
RFC 5426 (was draft-ietf-syslog-transport-udp) RFC 5425 (was draft-ietf-syslog-transport-tls)
Transport Layer Security (TLS) Transport Mapping for Syslog
Transmission of Syslog Messages over UDP
RFC 5427 (was draft-ietf-syslog-tc-mib)
Textual Conventions for Syslog Management
RFC 5848 (was draft-ietf-syslog-sign)
Signed Syslog Messages
RFC 6012 (was draft-ietf-syslog-dtls)
Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
draft-ietf-netmod-syslog-model-26
A YANG Data Model for Syslog Configuration
