Сигурност на данните в облака: конкретизирайте споделената отговорност

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

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

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

Определете границата, преди да изберете контроли

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

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

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

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

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

Класифицирайте информацията там, където тя действително се намира

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

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

Картографирайте отговорността услуга по услуга

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

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

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

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

Оценявайте увереността, предоставяна от доставчика, без да я надценявате

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

Документите за увереност изискват преглед на обхвата. Докладът SOC 2 е доклад за атестация, а не сертификат. Сертифицирането по ISO 27001 се отнася до система за управление на информационната сигурност с определен обхват, а не е доказателство, че вашият наемател е конфигуриран сигурно. Проверете обхванатите услуги, отчетния период, изключенията и контролите на клиента, посочени в доклада.

Когато е относимо, каталогът C5 на BSI предоставя критерии за увереност в облака. Разграничавайте оценката от тип 1 за дизайна и внедряването към определен момент от тип 2, която обхваща функционирането за определен период. Нито една от тях не замества тестването на собствения ви достъп и потоци от данни.

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

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

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

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

Проверявайте ефективния достъп, а не само предвидените права

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

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

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

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

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

Проверявайте експозицията и поведението на приложенията заедно

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

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

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

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

Направете криптирането и достъпа до ключовете отделни контроли

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

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

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

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

Наблюдавайте активността по данните и запазете способността за реагиране

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

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

Дайте приоритет на сценарии за откриване като:

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

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

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

Използвайте инструментите за сигурност за определени въпроси

Инструментите за сигурност в облака са най-полезни, когато техният обхват и целта на решенията са ясни:

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

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

Доказвайте възстановяването независимо от статуса на архивирането

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

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

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

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

Практически пример: услуга за клиентски експорти

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

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

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

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

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

Запазвайте обхвата, изключенията и решенията от прегледите

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

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

Използвайте планирани прегледи наред със задействащи събития. Съществени промени във внедряването, нови региони, смяна на доставчици, инциденти, променена класификация на данните и нови пътища за споделяне трябва да водят до повторна оценка. NIST Cybersecurity Framework предоставя полезна организираща рамка чрез функциите Govern, Identify, Protect, Detect, Respond и Recover; тя е насока, а не доказателство, че дадено внедряване изпълнява задълженията си.

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

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