Съответствие в сигурността на данните: защитете целия жизнен цикъл на информацията

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

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

Разграничете изискванията за сигурност от по-широките задължения относно данните

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

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

Поддържайте отделно три източника на изисквания:

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

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

Установете приложимостта, преди да изберете контроли

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

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

Член 32 от ОРЗД изисква сигурност, съответстваща на риска, като се вземат предвид фактори, включително естеството на обработването, разходите за прилагане и достиженията на техническия прогрес. Той посочва мерки като криптиране, устойчивост, възстановяване и редовна оценка; той не налага универсално общо задължение за криптиране.

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

SOC 2 е атестационен доклад, а не сертифициране. Критериите му се отнасят до сигурността и, когато са включени в обхвата, до наличността, целостта на обработката, поверителността и защитата на личните данни. Нито докладът по SOC 2, нито сертификатът по ISO установяват съответствие с ОРЗД.

Секторните задължения се нуждаят от собствена оценка. SOX се отнася до финансовото отчитане и свързаните с него вътрешни контроли за съответните компании; CMMC се отнася до определени изисквания по договори в областта на отбраната и до информационни среди. В Европа NIS2 изисква анализ на сектора, размера, услугата и правилата за включване съгласно националното транспониране. DORA обхваща предимно определени финансови субекти, с договорни задължения за доставчиците на ИКТ услуги и режим на надзор за определените критични доставчици. Не приемайте, че всяка финтех компания или технологичен доставчик има едни и същи преки задължения.

Изградете карта на жизнения цикъл, която включва вторичните копия

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

За всеки набор от данни запишете:

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

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

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

Внедрете защитни мерки на всеки етап от жизнения цикъл

Събиране: свеждайте данните до минимум и ограничавайте приемането им

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

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

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

Използване и достъп: прилагайте оторизацията близо до данните

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

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

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

Производствените данни не бива да се превръщат в тестови данни по подразбиране. Предпочитайте синтетични данни. Ако изключение с реални данни е оправдано, одобрете неговия обхват, ограничете достъпа и определете срок на валидност. Псевдонимизацията може да намали експозицията, но псевдонимизираните лични данни остават в обхвата на ОРЗД, когато физическите лица могат да бъдат идентифицирани повторно чрез допълнителна информация.

Съхранение и пренос: защитавайте данните и техните ключове

Разграничавайте криптирането в покой от криптирането при пренос. Криптирането на хранилищата защитава при определени сценарии на загуба или достъп; криптирането при пренос защитава комуникационните канали. Нито едното не пречи на оторизирано приложение да върне записи на грешния потребител.

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

Управлението на ключовете е част от контрола, а не бележка под линия към внедряването. Документирайте кой може да използва, администрира, ротира, отнема и възстановява ключове. KMS поддържа управлявани операции с ключове; HSM може да осигури хардуерно подкрепена защита на криптографския материал. Изберете подход според модела на заплахите и оперативните изисквания.

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

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

Цялост и наличност: тествайте оперативните твърдения

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

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

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

Съхранение и унищожаване: направете изтриването изпълнимо

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

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

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

Третирайте увереността за облака като доказателство с определен обхват

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

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

Местоположението е друг въпрос с определен обхват. Картографирайте основното хранилище, репликите, аварийното възстановяване, достъпа за поддръжка, подизпълнителите и местата, където се изпраща телеметрията. Хостването в избран регион само по себе си не установява суверенитет на данните или съответствие с ОРЗД. Оценките на международните предавания са отделни от изискванията за договорите с обработващи лични данни по член 28 от ОРЗД.

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

Прилагайте контекста на HealthTech, без да сливате отделните задължения

HealthTech илюстрира защо контекстът на данните има значение. Здравните данни се третират като специална категория съгласно член 9 от ОРЗД, наред с необходимостта от правно основание по член 6. Документирайте съответното условие по член 9, вместо да приемате, че всяка операция със здравни данни може да разчита на една и съща обосновка.

Оценете дали обработването е вероятно да породи висок риск и следователно изисква оценка на въздействието върху защитата на данните съгласно член 35. Доказателствата за сигурност трябва да отразяват вероятната вреда: неверни записи, неуместен достъп на персонал, разкриване чрез известия и недостъпни услуги може да имат значение.

Задълженията, свързани с медицинските изделия, зависят от продукта и предназначението. Оценката по MDR или IVDR е отделна линия от поверителността и информационната сигурност. Продуктите за електронни здравни досиета и дейностите по вторично използване също налагат оценка спрямо приложимите разпоредби за Европейското пространство за здравни данни и поетапните изисквания. Националните правила в здравеопазването и за реимбурсиране може да добавят допълнителни ограничения.

Продажбата на болница не установява автоматично прекия статус по NIS2 на всеки доставчик. Документирайте правната приложимост отделно от договорните изисквания за сигурност на болницата. Исканията на клиенти за сертифициране по ISO, SOC 2 или друга увереност може да са важни от търговска гледна точка, без да са универсални законови изисквания.

Изградете доказателствата около твърденията и след това наблюдавайте отклоненията

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

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

Наблюдавайте промените, които могат да обезсилят модела: нови интеграции, промени в правата, изключено одитно регистриране, неуспешни резервни копия, грешки при изтриване и нови места за изпращане. Насочвайте сигналите към собственици с път за ескалация. Периодичните одити трябва да проверяват чрез извадка дали тези проверки са функционирали, а не просто дали съществува табло. Тестовете за проникване може да са уместни с оглед на риска или договорните изисквания, но не са универсален задължителен тест по ISO 27001 или SOC 2.

Включете реагирането при инциденти в плана за доказателства. Съгласно ОРЗД обработващите лични данни уведомяват администраторите без ненужно забавяне. Администраторите преценяват уведомяването на надзорния орган без ненужно забавяне и, когато това е осъществимо, не по-късно от 72 часа след узнаването, освен ако не съществува вероятност нарушението да породи риск за правата и свободите на физическите лица. Нарушенията с висок риск могат да изискват и съобщаване на засегнатите лица, при спазване на изключенията по член 34. Записвайте мотивите при неуведомяване и оценявайте отделно другите договорни или секторни задължения за докладване.

Практически пример: затваряне на пропуск при експорта от поддръжката

Да приемем, за илюстрация, че доставчик на HealthTech SaaS обработва записи за часове и симптоми за клиники. Основната му база данни е криптирана, достъпът до приложението е ограничен по клиенти, а резервни копия съществуват. Преглед на жизнения цикъл открива, че служителите по поддръжката експортират записи в електронни таблици и ги прикачват към заявки.

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

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

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

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

Направете първо един чувствителен поток подлежащ на преглед

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

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

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