🥇Мониторинг на сигурността на облаците

Прехвърлянето на данни и приложения в облака представлява ново предизвикателство за корпоративните SOC, които не винаги са готови да наблюдават чужда инфраструктура. Според данни на Netoskope средното предприятие (очевидно все пак в САЩ) използва 1246 различни облачни услуги, което е с 22% повече в сравнение с предходната година. 1246 облачни услуги!!! 175 от тях са свързани с HR услуги, 170 с маркетинг, 110 — в областта на комуникациите и 76 в финансите и CRM. В Cisco се използват "всичко" 700 външни облачни услуги. Затова мен малко ме смущават тези числа. Но в крайна сметка проблемът не е в тях, а в това, че облаците все по-активно започват да се използват от все повече компании, които биха искали да имат същите възможности за наблюдение на облачната инфраструктура, както и в собствената мрежа. И тази тенденция нараства — по данни на американската сметна палата към 2023 г. в САЩ се планира да бъдат закрити 1200 ЦОД (6250 вече са затворени). Но преминаването към облака не е просто "да прехвърлим сървърите си на външен доставчик". Нова ИТ архитектура, нов софтуер, нови процеси, нови ограничения… Всичко това внася съществени промени в работата не само на ИТ, но и на ИБ. И ако с осигуряването на сигурността на самото облако доставчиците успяха по някакъв начин да се справят (слава богу, че има достатъчно препоръки), то с облачния мониторинг на ИБ, особено на SaaS платформи, има съществени трудности, за които ще поговорим.

Представете си, че вашата компания е преместила част от инфраструктурата си в облака… Стоп. Не така. Ако инфраструктурата е преместена, а вие сега се чудите как ще я наблюдавате, то вие вече сте загубили. Ако не става въпрос за Amazon, Google или Microsoft (и то с уговорки), вероятно няма да имате много възможности за мониторинг на вашите данни и приложения. Добре е, ако ви предоставят възможност да работите с логовете. Понякога данни за събития на сигурността може да са налични, но вие няма да имате достъп до тях. Например, при Office 365. Ако имате най-евтината лицензия E1, събитията на сигурността изобщо няма да са достъпни. При наличие на лицензия E3 вашите данни се съхраняват само за 90 дни, а само с E5 — продължителността на логовете е достъпна за една година (въпреки че тук също има свои нюанси, свързани с необходимостта да поискате отделни функции за работа с логовете от поддръжката на Microsoft). Между другото, лицензия E3 е значително по-слаба откъм функции за мониторинг в сравнение с корпоративния Exchange. За да постигнете същото ниво, ще ви е нужна лицензия E5 или допълнителна лицензия Advanced Compliance, които могат да изискват допълнителни пари, които не са били предвидени във вашата финансова модел за преминаване към облачна инфраструктура. И това е само един пример за недооценяване на проблемите, свързани с мониторинга на облачната информационна безопасност. В тази статия, без да претендирам за изчерпателност, бих искал да насоча вниманието към някои нюанси, които е добре да се вземат предвид при избора на облачен доставчик от гледна точка на сигурността. А в края на статията ще бъде предоставен списък с проверки, който е добре да изпълните, преди да считате, че въпросите на мониторинга на облачната информационна безопасност са решени.

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

Сигурностните логове не съществуват. Това е доста разпространена ситуация, особено при начинаещи играчи на пазара на облачни решения. Но не трябва веднага да се отказвате от тях. Малките играчи, особено местните, са по-чувствителни към изискванията на клиентите и могат бързо да реализират някои търсени функции, променяйки одобрения роадмап на своите продукти. Да, това няма да е аналог на GuardDuty от Amazon или модул за “Проактивна защита” от Битрикс, но поне нещо.
ИБ не знае къде се съхраняват логовете или няма достъп до тях. Тук е необходимо да се водят преговори с доставчика на облачни услуги — възможно е той да предостави такава информация, ако счита клиента за важен. Но като цяло, не е хубаво, когато достъпът до логовете се предоставя "по специално решение".
Случва се логовете при облачния доставчик да са налични, но те предлагат ограничен мониторинг и регистрация на събития, недостатъчни за откритие на всички инциденти. Например, можете да получите само логове на промени на сайта или логове на опити за удостоверяване на потребители, но други събития, например, свързани с мрежовия трафик, не се предоставят, което ще скрие от вас значителна част от събитията, характеризиращи опити за пробив в облачната ви инфраструктура.
Логовете са налични, но достъпът до тях трудно се автоматизира, което налага мониторинг не в реално време, а по график. А ако не може да се направи автоматичен износ на логовете, например, във формат Excel (както правят някои местни доставчици на облачни решения), това може да доведе до нежелание от страна на корпоративната ИБ служба да се занимава с тях.
Няма мониторинг на логовете. Това вероятно е най-неясната причина за възникване на инциденти в ИБ в облачни среди. Логовете поне са налични, и достъпът до тях може да бъде автоматизиран, но никой не го прави. Защо?

Концепция за споделена сигурност в облака

Преходът към облака е винаги търсене на баланс между желанието да се запази контрол над инфраструктурата и прехвърлянето й в по-професионални ръце на облачен доставчик, който се специализира в нейното поддържане. И в областта на сигурността на облачните среди, този баланс също трябва да се търси. Особено, че в зависимост от използвания модел на предоставяне на облачни услуги (IaaS, PaaS, SaaS), този баланс ще бъде различен през цялото време. При всякакви обстоятелства трябва да помним, че всички облачни доставчици днес следват така наречения модел на споделена отговорност и споделена информационна безопасност. За нещо отговаря облакът, за нещо отговаря клиентът, който е разположил своите данни, приложения, виртуални машини и други ресурси в облака. Необмислено би било да се разчита, че при преминаване към облака, ще прехвърлим цялата отговорност на доставчика. Но също така не е разумно да изграждаме цялата сигурност самостоятелно при преминаването към облака. Необходим е баланс, който ще зависи от множество фактори: — стратегии за управление на риска, модели на заплахи, налични защитни механизми на облачния доставчик, законодателство и др.

Например, класификация на данните, разположени в облака, винаги е отговорност на клиента. Облачният провайдер или външният доставчик на услуги може само да помогне с инструменти, които да улеснят маркирането на данните в облака, откритие на нарушения, изтриване на данни, нарушаващи законодателството, или тяхното маскиране по някакъв начин. От друга страна, физическата сигурност винаги е отговорност на облачния провайдер, която той не може да сподели с клиентите. А всичко, което се намира между данните и физическата инфраструктура, е именно предмет на обсъждане в тази статия. Например, наличността на облака е отговорност на провайдера, а настройките за правила за сигурност или включването на криптиране са отговорност на клиента. В тази статия ще опитаме да видим какви механизми за мониторинг на сигурността предлагат днес различни популярни облачни провайдери в България, какви са особеностите на тяхното прилагане и кога е целесъобразно да се обърнете към външни решения (например, Cisco E-mail Security), които разширяват възможностите на вашето облако в областта на киберсигурността. В някои случаи, особено при следване на мултиоблачна стратегия, няма да имате избор освен да използвате външни решения за мониторинг на сигурността в няколко облачни среда (например, Cisco CloudLock или Cisco Stealthwatch Cloud). В редица случаи ще осъзнаете, че избраният от вас (или наложен) облачен провайдер въобще не предлага възможности за мониторинг на сигурността. Това е неприятно, но също така предоставя възможност за адекватна оценка на нивото на риск, свързано с работата с това облако.

Жизнен цикъл на мониторинга на сигурността в облака

За да наблюдавате сигурността на използваните от вас облаци, имате само три възможности:

да разчитате на инструментите, предоставени от вашия облачен провайдер,
да се възползвате от решения на трети страни, които ще наблюдават използваните от вас IaaS, PaaS или SaaS платформи,
да изградите собствена инфраструктура за мониторинг на облачните среди (само за IaaS/PaaS платформи).

Нека да видим какви особености има всеки от тези варианти. Но преди това трябва да разберем общата схема, която ще се използва при мониторинга на облачните платформи. Ще подчертая 6 основни компонента на процеса на мониторинг на ИБ в облака:

Подготовка на инфраструктурата. Определяне на необходимите приложения и инфраструктура за събиране на събития, важни за ИБ, в хранилището.
Събиране. На този етап събитията за сигурност се агрегат от различни източници за последваща обработка, съхранение и анализ.
Обработка. На този етап данните се преобразуват и обогатяват, за да се улесни последващият им анализ.
Съхранение. Този компонент отговаря за краткосрочно и дългосрочно съхранение на събраните обработени и 'сурови' данни.
Анализ. На този етап имате възможност да откриете инциденти и да реагирате на тях в автоматичен или ръчен режим.
Отчетност. Тази стъпка помага да се създадат ключови показатели за заинтересованите страни (ръководство, одитори, облачен доставчик, клиенти и т.н.), които да ни помогнат да вземем решения, например, смяна на доставчика или засилване на ИБ.

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

Вградени възможности на облачните услуги

Вече споменах, че много облачни услуги днес не предлагат никакви възможности за мониторинг на информационната сигурност. Всъщност, те не отделят особено внимание на темата за ИС. Например, един от популярните руски услуги за изпращане на отчети до държавните органи през интернет (специално не ще спомена името му). Целият раздел за сигурността на този сервис акцентира на прилагането на сертифицирани криптографски средства. Разделът за ИС на друга родна облачна услуга за електронен документооборот е много по-обширен. В него се говори за сертификати на публични ключове, сертифицирана криптография, отстраняване на уеб уязвимости, защита от DDoS атаки, прилагане на МСЕ, резервно копиране и дори регулярно провеждане на одити на ИС. Но за мониторинг няма нито дума, както и за възможността за получаване на достъп до събития от ИС, които биха могли да интересуват клиентите на този доставчик на услуги.

Всъщност, по начина, по който облачният доставчик описва на сайта и в документацията въпросите на ИС, може да се разбере, колко сериозно се отнася към този въпрос. Например, ако прочетете ръководствата на продуктите „Моят офис“, там не се споменава нито дума за сигурност, а в документацията на отделния продукт “Моят офис. КС3”, предназначен за защита от неразрешен достъп, има обичайно изброяване на пунктовете от 17-ти заповед на ФСТЕК, които изпълнява “Моят офис.КС3”, но не е описано как ги изпълнява и, най-вече, как да се интегрират тези механизми с корпоративна ИС. Възможно е такава документация да съществува, но в публичен достъп на сайта “Моят офис” не я намерих. Възможно е просто да нямам достъп до тази секретна информация?

При същия Битрикс ситуацията е значително по-добра. В документацията са описани форматите на журналите на събитията и, което е интересно, журнала на нахлуванията, който съдържа събития, свързани с потенциални заплахи за облачната платформа. Оттам можете да извлечете IP адрес, потребителско име или име на гост, източник на събитие, време, User Agent, тип на събитието и т.н. Вярно е, че работата с тези събития може да се извършва или от контролния панел на облака, или чрез експортиране на данните в формат MS Excel. Автоматизацията на работата с логовете на Битрикс в момента е затруднена и ще трябва да извършвате част от работата ръчно (експортиране на отчета и зареждане му в вашия SIEM). Но ако се припомни, че преди не толкова време дори и такава възможност нямаше, то това е голям напредък. В същото време искам да отбележа, че много чуждестранни облачни доставчици предлагат сходна функционалност "за начинаещи" — или гледайте логовете с очите си през контролния панел, или изтегляйте данни при вас (въпреки че повечето изтеглят данни в .csv формат, а не в Excel).

Ако не вземете предвид вариант с липса на логове, облачните доставчици обикновено предлагат три варианта за мониторинг на събитията по сигурността — контролни панели, експортиране на данни и достъп до тях чрез API. Първото, изглежда, решава много проблеми вместо вас, но не е точно така — при наличие на няколко журнала се налага да превключвате между екраните, които ги показват, загубвайки цялостната картина. Освен това, облачният доставчик едва ли ще ви предостави възможност за корелация на събитията по сигурността и в общи линии анализирането им от гледна точка на безопасността (обикновено имате работа със сурови данни, в които трябва да се ориентирате сами). Има изключения, за които ще говорим по-нататък. Накрая, струва си да попитате какви събития записва вашият облачен доставчик, в какъв формат и колко отговарят на вашите процеси за мониторинг на информационната безопасност. Например, идентификацията и автентикацията на потребители и гости. Същият Битрикс ви позволява да записвате датата и часа на събитието, името на потребителя или госта (при наличието на модула "Уеб-аналитика"), обекта, до който е осъществен достъп, и други типични за уебсайта елементи. Но корпоративните служби по информационна безопасност може да се нуждаят от информация за това, дали потребителят е влязъл в облака от доверено устройство (например в корпоративната мрежа, такава задача реализира Cisco ISE). А такава проста задача, като функцията за гео-IP, която ще помогне да се определи дали акаунтът на потребителя в облачната услуга не е откраднат? И дори ако облачният доставчик ви я предостави, това е недостатъчно. Например, Cisco CloudLock не просто анализира геолокацията, а използва машинно обучение и анализира историческите данни за всеки потребител, проследявайки различни аномалии в опитите за идентификация и автентикация. Подобна функционалност имат само MS Azure (при наличие на съответната абонаментна услуга).

Има още една трудност — тъй като за много от облачните доставчици мониторингът на киберсигурността е нова тема, с която едва сега започват да се занимават, те постоянно променят решенията си. Днес имат една версия на API, утре друга, вдругиден трета. Нужно е да бъдем готови за това. Същото важи и за функционалността, която може да се променя и трябва да се взема предвид в нашата система за мониторинг на киберсигурността. Например, Amazon първоначално предложи отделни услуги за мониторинг на събития в облака — AWS CloudTrail и AWS CloudWatch. След това се появи отделна услуга за мониторинг на киберсигурността — AWS GuardDuty. След известно време Amazon стартира нова управляваща система Amazon Security Hub, която включва анализ на данни, получени от GuardDuty, Amazon Inspector, Amazon Macie и редица други. Друг пример е инструментът за интеграция на логовете на Azure с SIEM — AzLog. Много доставчици на SIEM активно го използваха, докато през 2018 г. Microsoft не обяви прекратяването на развитието и поддръжката му, което постави много клиенти, използващи този инструмент, пред проблем (как беше решен, ще обсъдим по-късно).

Затова внимателно следете всички функции за мониторинг, които предлага вашият облачен доставчик. Или се доверете на външни доставчици на решения, които ще служат като посредници между вашия SOC и облака, който искате да мониторите. Да, това ще бъде по-скъпо (въпреки че не винаги), но така ще прехвърлите цялата отговорност на чужди плещи. Или не цялата?.. Нека си спомним за концепцията за споделена сигурност и да разберем, че не можем да прехвърлим нищо — ще трябва сами да се запознаем с това как различните облачни доставчици осигуряват мониторинг на киберсигурността на вашите данни, приложения, виртуални машини и други ресурси, разположени в облака. И ще започнем с това, което предлага Amazon в тази част.

Пример: Мониторинг на киберсигурността в IaaS на базата на AWS

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

Първо трябва да кажем, че Amazon не е непристъпна крепост. С нейните клиенти редовно се случват различни инциденти. Например, в Deep Root Analytics бяха откраднати имената, адресите, датите на раждане и телефоните на 198 милиона избиратели. Израелската компания Nice Systems е загубила 14 милиона записи за абонати на Verizon. В същото време вградените възможности на AWS ви позволяват да откривате широк спектър от инциденти. Например:

въздействие върху инфраструктурата (DDoS)
компрометиране на възел (инжектиране на команди)
компрометиране на акаунт и неупълномощен достъп
грешна конфигурация и уязвимости
незащитени интерфейси и API.

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

За идентифициране на инциденти може да се използва широк спектър от различни услуги за мониторинг, разработени от Amazon (макар че често се допълват с външни инструменти, например, osquery). В AWS се проследяват всички действия на потребителите, независимо от това как са извършени — чрез конзолата за управление, командния ред, SDK или други услуги на AWS. Всички записи за действията на всяка AWS сметка (включително име на потребителя, действие, услуга, параметри на активността и нейния резултат) и използването на API са достъпни чрез услугата AWS CloudTrail. Можете да преглеждате тези събития (например, вход в конзолата AWS IAM) от конзолата CloudTrail, да ги анализирате с помощта на Amazon Athena или да ги „предадете“ на външни решения, например, Splunk, AlienVault и др. Самите логове на AWS CloudTrail се съхраняват в вашето хранилище AWS S3.

Две други услуги на AWS предоставят още редица важни възможности за мониторинг. Първо, Amazon CloudWatch — това е услуга за мониторинг на ресурсите и приложенията на AWS, която позволява между другото да се идентифицират различни аномалии във вашето облако. Всички вградени услуги на AWS, като Amazon Elastic Compute Cloud (сървъри), Amazon Relational Database Service (бази данни), Amazon Elastic MapReduce (анализ на данни) и още 30 други услуги на Amazon, използват Amazon CloudWatch за съхранение на своите логове. Разработчиците могат да използват публичния API на Amazon CloudWatch, за да добавят функциите за мониторинг на логове в потребителските приложения и услуги, което позволява разширяване на обхвата на анализираните събития в контекста на ИБ.

Второ, услугата VPC Flow Logs позволява анализ на мрежовия трафик, изпращан или получаван от вашите AWS сървъри (отвън или отвътре), както и между микросервизите. Когато някой от ресурсите на вашето AWS VPC взаимодейства с мрежата, услугата VPC Flow Logs записва информация за мрежовия трафик, включително мрежовия интерфейс на източника и дестинацията, както и IP адресите, портовете, протокола, количеството байтове и количеството пакети, които сте видели. Тези, които имат опит с локалната мрежова сигурност, признават това за аналог на потоците. NetFlow, които могат да се създават от мрежови суичове, рутери и корпоративни защитни стени. Тези журнали са важни за мониторинг на ИБ, тъй като в противовес на събитията, свързани с действията на потребителите и приложенията, позволяват да не се пропуска и мрежовата активност в облачна среда AWS.

Следователно, тези три услуги на AWS — AWS CloudTrail, Amazon CloudWatch и VPC Flow Logs — заедно предоставят достатъчно ефективно представяне на използването на вашия акаунт, поведението на потребителите, управлението на инфраструктурата, активността на приложенията и услугите, както и мрежовата активност. Например, чрез тях могат да се открият следните аномалии:

Опити за сканиране на сайта, търсене на бекдори, търсене на уязвимости чрез изблици на 'грешки 404'.
Инжекционни атаки (например, SQL injection) чрез изблици на 'грешки 500'.
Известни инструменти за атаки: sqlmap, nikto, w3af, nmap и т.н. чрез анализ на полето User Agent.

Amazon Web Services разработи и други услуги за киберсигурност, които помагат да се решават много различни задачи. Например, AWS предлага вграден сервис за одит на политики и конфигурации — AWS Config. Тази услуга осигурява непрекъснат одит на вашите AWS ресурси и техните конфигурации. Нека разгледаме прост пример: представете си, че искате да се уверите, че паролите на потребителите са деактивирани на всичките ви сървъри и достъпът е възможен само на базата на сертификати. AWS Config позволява лесно да проверите това за всичките си сървъри. Има и други политики, които могат да бъдат приложени към вашите облачни сървъри: "Нито един сървър не може да използва порт 22", "Само администратори могат да променят правилата на защитната стена" или "Само потребителят Ивашко може да създава нови потребителски акаунти, и той може да го прави само в първите дни от седмицата". През лятото на 2016 година услугата AWS Config беше разширена за автоматизиране на откритията за нарушения на разработените политики. AWS Config Rules по същество представляват непрекъснати конфигурационни запитвания на използваните от вас услуги на Amazon, които генерират събития при нарушения на съответните политики. Например, вместо да се извършват периодични запитвания към AWS Config, за да се провери дали всички дискове на виртуалния сървър са криптирани, AWS Config Rules могат да се използват за постоянно наблюдение на сървърните дискове относно изпълнението на това условие. И, най-важно, в контекста на тази публикация, всяко нарушение генерира събития, които могат да бъдат анализирани от вашата служба за информационна сигурност.

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

откриване на прониквания — AWS GuardDuty
контрол на изтичане на информация — AWS Macie
EDR (макар да звучи малко странно за крайни устройства в облака) — AWS Cloudwatch + решения с отворен код osquery или GRR
анализ на Netflow — AWS Cloudwatch + AWS VPC Flow
анализ на DNS — AWS Cloudwatch + AWS Route53
AD — AWS Directory Service
управление на акаунти — AWS IAM
SSO — AWS SSO
анализ на сигурността — AWS Inspector
управление на конфигурации — AWS Config
WAF — AWS WAF.

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

Във всеки случай всичко започва с източниците на данни, които предоставят събития за ИБ. Към тези източници могат да се отнесат сред другото:

CloudTrail — използване на API и действия на потребители
Trusted Advisor — проверка на сигурността за спазване на най-добри практики
Config — инвентаризация и конфигурация на акаунти и настройки на услугите
VPC Flow Logs — свързаност с виртуални интерфейси
IAM — услуга за идентификация и автентикация
ELB Access Logs — журнали на балансировача на натоварването
Inspector — уязвимости в приложенията
S3 — файлово хранилище
CloudWatch — активност на приложенията
SNS — услуга за уведомления.

Amazon, предлагащ такъв спектър от източници на събития и инструменти за тяхното генериране, е силно ограничен в възможностите си за анализ на събраните данни в контекста на ИБ. Ще трябва самостоятелно да проучите наличните логове, търсейки в тях съответните индикатори за компрометиране. AWS Security Hub, който Amazon наскоро стартира, е предназначен да реши този проблем, като служи като облачно SIEM за AWS. Но в момента той е само в началото на своя път и е ограничен както по брой източници, с които работи, така и от други ограничения, наложени от архитектурата и подредбите на самия Amazon.

Пример: Мониторинг на ИБ в IaaS на базата на Azure

Не искам да влизам в дълга полемика относно това, кой от трите облачни провайдера (Amazon, Microsoft или Google) е по-добър (особено след като всеки от тях има своя специфична област и е подходящ за решаване на различни задачи); ще се съсредоточим върху възможностите за мониторинг на ИТ сигурността, които предлагат тези играчи. Трябва да признаем, че Amazon AWS беше един от първите в този сегмент и поради това напредна най-далеч в частта свои функции за ИТ сигурност (въпреки че много хора признават, че тяхното ползване е трудно). Но това не означава, че ще игнорираме възможностите, които ни предоставят Microsoft и Google.

Продуктите на Microsoft винаги се отличават с тяхната „отвореност“ и ситуацията в Azure е аналогична. Например, докато AWS и GCP винаги изхождат от концепцията „всичко, което не е разрешено, е забранено“, то подходът на Azure е напълно противоположен. Например, при създаването на виртуална мрежа в облака и виртуална машина в нея, всички портове и протоколи по подразбиране са отворени и разрешени. Следователно, ще трябва да похарчите малко повече усилия за първоначалната настройка на системата за ограничаване на достъпа в облака на Microsoft. И това налага по-строги изисквания относно мониторинга на активността в облака Azure.

AWS има особеност, свързана с това, че когато наблюдавате виртуалните си ресурси, ако те са в различни региони, срещате затруднения в обединяването на всички събития и тяхния единен анализ. За да разрешите това, трябва да прибегнете до различни хитрости, като например създаването на собствен код за AWS Lambda, който ще прехвърля събития между регионите. В Azure такъв проблем няма — механизмът Activity Log проследява всяка активност в рамките на цялата организация без ограничения. Същото важи и за AWS Security Hub, който наскоро беше разработен от Amazon за консолидиране на множество функции за сигурност в рамките на единен център за сигурност, но само в рамките на своя регион, което, за съжаление, не е актуално за Русия. В Azure съществува свой Security Center, който не е обвързан с регионални ограничения, предоставяйки достъп до всички функции за сигурност на облачната платформа. Освен това, за различни локални екипи, той може да предостави свой набор от защитни възможности, включително управляеми от тях събития за сигурност. AWS Security Hub все още се стреми да стане подобен на Azure Security Center. Но трябва да добавим и капка в горчилката — можете да извлечете много от Azure, което е било описано по-рано за AWS, но най-удобно това става само за Azure AD, Azure Monitor и Azure Security Center. Всички останали защитни механизми на Azure, включително анализ на събития за сигурност, все още не се управляват по най-удобния начин. Отчасти проблемът се решава чрез API, който прониква във всички услуги на Microsoft Azure, но това ще изисква допълнителни усилия от ваша страна за интегриране на облака с вашето SOC и наличие на квалифицирани специалисти (както и с всяка друга SIEM, работеща с облачни API). Някои SIEM, за които ще говорим по-късно, вече поддържат Azure и могат да автоматизират задачата за мониторинг, но и с тях има свои трудности — не всички те могат да поемат всички логове, налични в Azure.

Събирането на събития и тяхното наблюдение в Azure се осъществява с помощта на услугата Azure Monitor, която е основният инструмент за събиране, съхранение и анализ на данни в облака на Microsoft и неговите ресурси — репозитории Git, контейнери, виртуални машини, приложения и др. Всички данни, събирани от Azure Monitor, се делят на две категории — метрики, събирани в реално време и описващи ключовите показатели за ефективност на облака Azure, и регистрационни журнали, съдържащи данни, организирани в записи, характеризиращи определени аспекти на дейността на ресурсите и услугите на Azure. Освен това, с помощта на Data Collector API услугата Azure Monitor може да събира данни от всякакви REST източници, за да изгражда собствени сценарии за наблюдение.

Ето няколко източника на събития за сигурност, които Azure предлага и до които можете да получите достъп чрез Azure Portal, CLI, PowerShell или REST API (а някои само чрез Azure Monitor / Insight API):

Дневници на активността — този дневник отговаря на класическите въпроси "кой", "какво" и "кога" във връзка с всяка операция за запис (PUT, POST, DELETE) над облачните ресурси. Събития, свързани с достъп до четене (GET), не попадат в този дневник, както и редица други.
Дневници за диагностика — съдържа данни за операциите с определен ресурс, включен в вашата абонаментна услуга.
Доклади на Azure AD — съдържа както потребителска активност, така и системна активност, свързана с управлението на групи и потребители.
Windows Event Log и Linux Syslog — съдържа събития от виртуални машини, разположени в облака.
Метрики — съдържа телеметрия за състоянието на производителността и "здравето" на вашите облачни услуги и ресурси. Измерват се на всеки една минута и се съхраняват в продължение на 30 дни.
Дневници на потока за мрежова сигурност — съдържа данни за мрежови събития за сигурност, събирани с помощта на услугата Network Watcher и наблюдение на ресурси на ниво мрежа.
Дневници за съхранение — съдържа събития, свързани с достъпа до хранилищата.

За мониторинг може да се използват външни SIEM или вградения Azure Monitor и неговите разширения. За системите за управление на събитията в областта на информационната сигурност ще говорим по-късно, а сега нека да разгледаме какво предлага самият Azure за анализа на данни в контекста на сигурността. Основният екран за всичко, свързано със сигурността в Azure Monitor, е Log Analytics Security and Audit Dashboard (безплатната версия поддържа съхранение на ограничен обем събития само за една седмица). Тази панел е разделена на 5 основни области, визуализиращи обобщената статистика за това, което се случва в използваната от вас облачна среда:

Security Domains — ключови количествени показатели, свързани с информационната сигурност — брой инциденти, брой компрометирани възли, немодифицирани възли, събития от мрежовата сигурност и т.н.
Notable Issues — показва броя и важността на активните проблеми с информационната сигурност
Detections — показва шаблоните на атаките, използвани срещу вас
Threat Intelligence — показва географската информация за външните възли, които атакуват вас
Common security queries — типични запитвания, които ще ви помогнат по-добре да наблюдавате вашата информационна сигурност.

Както разширения на Azure Monitor могат да се посочат Azure Key Vault (защита на криптографски ключове в облака), Malware Assessment (анализ на защитата от злонамерен софтуер на виртуалните машини), Azure Application Gateway Analytics (анализ, наред с другото, на журналите на облачния защитен стенд) и т.н. Тези инструменти, обогатени с определени правила за обработка на събития, позволяват визуализиране на различни аспекти от дейността на облачните услуги, включително и сигурността, и откриване на определени отклонения от нормалната работа. Но, както често се случва, всяка допълнителна функционалност изисква съответна платена подписка, което ще наложи планиране на финансовите ви инвестиции предварително.

Azure предлага множество вградени функции за мониторинг на заплахи, които са интегрирани в Azure AD, Azure Monitor и Azure Security Center. Например, те включват откриване на взаимодействия на виртуални машини с известни зловредни IP адреси (чрез интеграцията с услугите Threat Intelligence на Microsoft), откриване на зловреден софтуер в облачната инфраструктура благодарение на алармени сигнали от виртуални машини, разположени в облака, атаки тип “грутване на пароли” на виртуални машини, уязвимости в конфигурацията на системата за идентификация на потребителите, влизане в системата от анонимизатори или заразени възли, течове на акаунти, вход от необичайни местоположения и др. Днес Azure е един от малкото облачни доставчици, които предлагат вградени функции за Threat Intelligence за обогатяване на събраните събития за информационна безопасност.

Както бе споменато по-горе, защитният функционал и, следователно, генерираните от него събития за сигурност не са налични за всички потребители еднакво, а изискват определена абонаментна програма, която включва необходимия функционал, генериращ съответните събития за мониторинг на информационната безопасност. Например, част от функциите за мониторинг на аномалии в акаунтите, описани в предишния абзац, са достъпни само с премиум лиценз P2 за Azure AD. Без него, както и в случая с AWS, ще трябва да анализирате събраните събития за сигурност „ръчно“. И също така, в зависимост от типа лиценз за Azure AD, не всички събития ще бъдат налични за анализ.

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

Ако имате нужда не само от работа с логовете, но и от всеобхватен център за сигурност на вашата облачна платформа Azure, включително управление на политиките за информационна безопасност, то може да говорим за необходимостта от работа с Azure Security Center, повечето полезни функции на което са достъпни срещу допълнително заплащане, например, откриване на заплахи, мониторинг извън Azure, оценка на съответствието и т.н. (в безплатната версия имате достъп само до оценка на сигурността и препоръки за отстраняване на откритите проблеми). Той консолидира всички въпроси на сигурността на едно място. Всъщност може да се говори за по-високо ниво на информационна безопасност, отколкото това, което ви предоставя Azure Monitor, тъй като в този случай събраните данни от цялата ви облачна фабрика биват обогатявани с множество източници, такива като Azure, Office 365, Microsoft CRM онлайн, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) и Microsoft Security Response Center (MSRC), на които се налагат различни сложни алгоритми за машинно обучение и поведенческа аналитика, което в крайна сметка трябва да увеличи ефективността на откритие на заплахи и реакцията към тях.

Azure разполага и със свой SIEM — той се появи в началото на 2019 г. Това е Azure Sentinel, който се опира на данните от Azure Monitor и може да се интегрира с външни решения за сигурност (например, NGFW или WAF), списъкът на които постоянно се допълва. Освен това, чрез интеграцията на Microsoft Graph Security API имате възможност да свързвате свои собствени фийдове с Threat Intelligence към Sentinel, което обогатява възможностите за анализ на инциденти в облака ви Azure. Може да се твърди, че Azure Sentinel е първият „роден“ SIEM, който се появи при облачните доставчици (от типа на Splunk или ELK, които могат да бъдат разположени в облака, например, AWS, все пак са разработени не от доставчиците на традиционни облачни услуги). Azure Sentinel и Security Center могат да бъдат наречени SOC за облака Azure, и те биха могли да бъдат единственото решение (с някои уточнения), ако няма да имате никаква друга инфраструктура и всичките си изчислителни ресурси сте преместили в облак и този облак е Microsoft Azure.

Но тъй като вградените възможности на Azure (дори при наличие на абонамент за Sentinel) често не са достатъчни за целите на мониторинга на ИБ и интеграцията на този процес с други източници на събития за сигурност (както облачни, така и вътрешни), се явява необходимостта от експортиране на събраните данни в външни системи, които могат да включват и SIEM. Това се прави както с помощта на API, така и чрез специални разширения, които официално са налични в момента само за следните SIEM — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight и ELK. Още наскоро имаше повече такава SIEM, но от 1 юни 2019 година Microsoft прекрати поддръжката на Azure Log Integration Tool (AzLog), който в началото на съществуването на Azure и при отсъствието на нормална стандартизация на работата с логове (Azure Monitor дори не съществуваше) позволяваше лесна интеграция на външни SIEM с облака на Microsoft. Сега ситуацията се е променила и Microsoft препоръчва платформата Azure Event Hub като основен инструмент за интеграция с другите SIEM. Много вече осъществиха такава интеграция, но бъдете внимателни — те може да не улавят всички логове на Azure, а само някои (проверете в документацията на вашата SIEM).

Завършвайки краткия обзор на Azure, искам да дам обща препоръка за този облачен сервис — преди да твърдите нещо относно функциите за мониторинг на ИБ в Azure, е необходимо да ги настроите много внимателно и да тествате дали работят така, както е описано в документацията и как са ви обяснили консултантите на Microsoft (а те може да имат различни мнения относно функционалността на Azure). При наличие на финансови възможности, можете да извлечете много полезно от Azure в частта на мониторинга на ИБ. Ако ресурсите ви са ограничени, както и в случая с AWS, ще трябва да разчитате само на собствени сили и сурови данни, предоставени от Azure Monitor. И помнете, че много функции за мониторинг струват пари и е добре предварително да се запознаете с ценовата политика. Например, безплатно можете да съхранявате данни за 31 дни с обем не повече от 5 ГБ на клиент — превишаването на тези стойности ще изисква допълнителни разходи (приблизително 2+ долара за съхранение на всеки допълнителен ГБ от клиента и 0,1 долара за съхранение на 1 ГБ на всеки допълнителен месец). Работата с телеметрия на приложения и метрики може също да изисква допълнителни финансови средства, подобно на работата с алерти и уведомления (безплатно е наличен определен лимит, който може да не е достатъчен за вашите нужди).

Пример: Мониторинг на ИБ в IaaS на базата на Google Cloud Platform

Google Cloud Platform изглежда доста млад в сравнение с AWS и Azure, но това отчасти е и положително. За разлика от AWS, който постепенно увеличаваше своите възможности, включително и защитни, и имаше проблеми с централизацията; GCP, подобно на Azure, се управлява много по-добре централизирано, което намалява броя на грешките и времето за внедряване в предприятието. От гледна точка на безопасността, GCP странно достатъчно се намира между AWS и Azure. Има също така единна регистрация на събития за цялата организация, но тя е непълна. Някои функции все още са в бета-режим, но постепенно този недостатък трябва да бъде отстранен и GCP ще стане по-зряла платформа от гледна точка на мониторинга на ИБ.

Основният инструмент за регистриране на събития в GCP е Stackdriver Logging (аналог на Azure Monitor), който позволява събиране на събития в цялата облачна инфраструктура (включително и от AWS). От гледна точка на сигурността в GCP, всяка организация, проект или папка разполага с четири регистрационни журнала:

Admin Activity — съдържа всички събития, свързани с административен достъп, например създаване на виртуална машина, промяна на права за достъп и др. Този журнал се записва винаги, независимо от желанието ви и съхранява данните си за 400 дни.
Data Access — съдържа всички събития, свързани с работата с данни от облачни потребители (създаване, промяна, четене и др.). По подразбиране този журнал не се записва, тъй като обемът му много бързо нараства. Поради тази причина срокът му на съхранение е само 30 дни. Освен това, в този журнал не се записват събитията, свързани с публично достъпни ресурси за всички потребители или такива, които са достъпни без вход в GCP.
System Event — съдържа системни събития, несвързани с потребителите, или действия на администратора, който променя конфигурацията на облачните ресурси. Записва се винаги и се съхранява за 400 дни.
Access Transparency — това е уникален пример за регистрационен журнал, който записва всички действия на служителите на Google (но за момента не за всички услуги на GCP), които получават достъп до вашата инфраструктура в рамките на изпълнението на служебните си задължения. Този журнал се съхранява 400 дни и не е достъпен за всеки клиент на GCP, а само при спазване на определени условия (или поддръжка Gold или Platinum, или наличие на 4 роли от определен тип в рамките на корпоративната поддръжка). Подобна функция съществува и в Office 365 — Lockbox.

Пример на журнал: Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "САЩ"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "Канада"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Номер на делото: bar123"
 type: "CUSTOMER_INITIATED_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

Достъпът до посочените журнали е възможен по няколко начина (по същия начин, както при Azure и AWS) — чрез интерфейса Log Viewer, чрез API, чрез Google Cloud SDK или чрез страницата Activity на проекта ви, който ви интересува за събития. По същия начин те могат да бъдат експортирани в външни решения за допълнителен анализ. Последното се прави чрез експортиране на логовете в хранилището BigQuery или Cloud Pub/Sub.

Освен Stackdriver Logging, платформата GCP предлага и функционалността Stackdriver Monitoring, която позволява проследяване на ключови метрики (производителност, наработка на отказ, общо състояние и т.н.) на облачните услуги и приложения. Обработените по специален начин и визуализирани данни могат да улеснят намирането на проблеми в облачната ви инфраструктура, включително в контекста на сигурността. Но е важно да отбележим, че тази функционалност ще бъде ограничена именно в контекста на информационната сигурност, тъй като към настоящия момент GCP няма аналог на AWS GuardDuty и не може да изолира сред всички регистрирани събития именно лошите (Google разработи Event Threat Detection, но в момента той е в бета и е рано да говорим за полезността му). Stackdriver Monitoring би могъл да бъде използван като система за откриване на аномалии, които след това ще бъдат разследвани за намиране на причините за тяхното възникване. Но при условията на недостиг на квалифициран персонал в областта на информационната сигурност на GCP, тази задача в момента изглежда предизвикателна.

Също така е важно да се подчертае списък с някои модули по информационна сигурност, които могат да бъдат приложени в контекста на вашето облако GCP и които са сходни с предлаганите от AWS:

Cloud Security Command Center — това е аналог на AWS Security Hub и Azure Security Center.
Cloud DLP — автоматично откриване и редактиране (например, маскиране) на данни, разположени в облака, по повече от 90 предварително зададени политики за класификация.
Cloud Scanner — скенер на известни уязвимости (XSS, Flash Injection, непатчнати библиотеки и т.н.) в App Engine, Compute Engine и Google Kubernetes.
Cloud IAM — управление на достъпа до всички ресурси на GCP.
Cloud Identity — управление на потребителски акаунти, устройства и приложения на GCP от единен интерфейс.
Cloud HSM — защита на криптографските ключове.
Cloud Key Management Service — управление на криптографските ключове в GCP.
VPC Service Control — създаване на защитена периметра около вашите ресурси GCP, за да ги защитите от изтичане.
Titan Security Key — защита от фишинг.

Много от тези модули генерират събития за сигурност, които могат да бъдат изпратени в хранилище BigQuery за анализ или експорт в други системи, включително SIEM. Както беше споменато по-горе, GCP е активно развиваема платформа и в момента Google разработва серия нови модули за киберсигурност за своята платформа. Сред тях е Event Threat Detection (в момента наличен в бета версия), който сканира логовете на Stackdriver за следи от неразрешена активност (аналог на GuardDuty в AWS), или Policy Intelligence (наличен в алфа версия), който ще осигури разработване на интелигентни политики за достъп до ресурсите на GCP.

Направих малък преглед на вградените възможности за мониторинг в популярните облачни платформи. Но имате ли специалисти, които могат да работят с "сурови" логове на IaaS доставчика (не всички са готови да купуват разширени възможности на AWS или Azure или Google)? Освен това, много хора знаят поговорката "доверявай, но проверявай", която в областта на сигурността е по-валидна от всякога. Насколько вие доверявате на вградените възможности на облачния доставчик, които ви предоставят събития за киберсигурност? До каква степен те изобщо се фокусират върху киберсигурността?

Понякога е разумно да се обърнем към интегрирани решения за мониторинг на облачни инфраструктури, които могат да допълнят вградената сигурност на облака. В някои случаи тези решения са единственият начин да получите информация за сигурността на вашите данни и приложения, разположени в облака. Освен това те са по-удобни, тъй като поемат всички задачи по анализа на необходимите логове, генерирани от различни облачни услуги на различни доставчици. Пример за такова интегрирано решение е Cisco Stealthwatch Cloud, което се фокусира върху единствената задача—мониторинг на аномалии в областта на информационната сигурност в облачни среди, включително Amazon AWS, Microsoft Azure и Google Cloud Platform, както и частни облаци.

Пример: Мониторинг на информационната сигурност с помощта на Stealthwatch Cloud

AWS предлага гъвкава платформа за изчисления, но тази гъвкавост води до по-лесни за компаниите грешки, които могат да доведат до проблеми със сигурността. И споделената модел на информационната сигурност само подпомага това. Стартиране на софтуер в облака с неизвестни уязвимости (с известни може да се справи, например, AWS Inspector или GCP Cloud Scanner), слаби пароли, неправилни конфигурации, инсайдери и т.н. И всичко това оставя отпечатък върху поведението на облачните ресурси, които Cisco Stealthwatch Cloud може да наблюдава; това е система за мониторинг на информационната сигурност и откриване на атаки в публични и частни облаци.

Една от ключовите характеристики на Cisco Stealthwatch Cloud е възможността за моделиране на обекти. С негова помощ можете да създадете софтуерна модел (тоест симулация практически в реално време) на всеки от вашите облачни ресурси (независимо дали става въпрос за AWS, Azure, GCP или нещо друго). Те могат да включват сървъри и потребители, както и типове ресурси, специфични за вашата облачна среда, като групи за сигурност и групи за автоматично мащабиране на услуги (auto-scale). Тези модели използват като входни данни структурирани потоци от данни, предоставени от облачните услуги. Например, за AWS това ще бъдат VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda и AWS IAM. Моделирането на обекти автоматично открива ролята и поведението на всеки от вашите ресурси (може да говорим за профилиране на всичката облачна активност). Сред тези роли са мобилни устройства от Android или Apple, сървър Citrix PVS, RDP сървър, пощенски шлюз, VoIP клиент, терминален сървър, контролер на домейн и т.н. След това той непрекъснато проследява поведението им, за да определи кога настъпва рисковано или заплашително поведение за сигурността. Можете да идентифицирате подбора на пароли, DDoS атаки, изтичане на данни, незаконен отдалечен достъп, действие на зловреден код, сканиране на уязвимости и други заплахи. Например, ето как изглежда откритие на опит за отдалечен достъп от нетипична за вашата организация страна (Южна Корея) към Kubernetes клъстера по SSH:

А ето как изглежда предполагаемото изтичане на информация от базата данни Postgress в страна, с която преди това не е имало взаимодействие:

Накрая, ето как изглежда твърде голямо количество неуспешни опити за достъп по SSH от Китай и Индонезия с външно отдалечено устройство:

Или, да предположим, че инстанцията на сървъра в VPC, според политиката, никога не трябва да бъде цел за дистанционен достъп. Нека предположим, че на този компютър е извършен дистанционен достъп поради неправилна промяна на политиката на правилата на защитната стена. Функцията за моделиране на същности ще открие и съобщи за тази активност ("Необичаен дистанционен достъп") почти в реално време и ще посочи конкретния API повикване AWS CloudTrail, Azure Monitor или GCP Stackdriver Logging (включително името на потребителя, дата и час, сред други детайли), които са предизвикали промяната в правилото на защитната стена. След това информацията може да бъде предадена на SIEM за анализ.

Подобни възможности се реализират за всяка облачна среда, поддържана от Cisco Stealthwatch Cloud:

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

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

Откритото събитие за киберсигурност може да бъде предадено като съответен тикет в Slack, Cisco Spark, системата за управление на инциденти PagerDuty, а също така може да бъде предадено на различни SIEM, сред които са Splunk или ELK. В заключение, ако вашата компания използва многооблачна стратегия и не е ограничена до един облачен доставчик, възможностите за мониторинг на киберсигурността, описани по-горе, правят Cisco Stealthwatch Cloud добро решение за получаване на унифициран пакет от възможности за наблюдение на водещите облачни играчи - Amazon, Microsoft и Google. Най-интересното е, че при сравнението на цените на Stealthwatch Cloud с напредналите лицензи за мониторинг на киберсигурността в AWS, Azure или GCP, може да се окаже, че решението на Cisco е дори по-евтино от вградените възможности на Amazon, Microsoft и Google. Парадоксално, но вярно. И колкото повече облаци и техните възможности използвате, толкова по-очевидно ще бъде предимството на консолидираното решение.

Освен това, Stealthwatch Cloud може да наблюдава и частни облаци, развърнати във вашата организация, например, на база контейнери Kubernetes или чрез мониторинг на потоци Netflow или мрежов трафик, получен чрез зеркализация в мрежово оборудване (дори родно производство), данни от AD или DNS сървъри и т.н. Всички тези данни ще бъдат обогатени с информация от Threat Intelligence, събирана от подразделението Cisco Talos, което е най-голямата неправителствена група изследователи на заплахи за киберсигурност в света.

Това ви позволява да реализирате единна система за мониторинг както на публични, така и на хибридни облаци, които вашата компания може да използва. Събраната информация след това може да бъде анализирана с вградените възможности на Stealthwatch Cloud или изпратена в вашия SIEM (по подразбиране се поддържат Splunk, ELK, SumoLogic и редица други).

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

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