🥇Моніторинг безпеки хмар

Перенесення даних та додатків у хмари є новою проблемою для корпоративних 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 основних компонентів процесу моніторингу ІБ у хмарі:

Підготовка інфраструктури. Визначення необхідних програм та інфраструктури для збору подій, важливих для ІБ, у сховищі.
Збір. На цьому етапі події безпеки агрегуються з різних джерел для їхньої подальшої передачі для обробки, зберігання та аналізу.
Обробка. На цьому етапі дані перетворюються та збагачуються для полегшення їх подальшого аналізу.
Зберігання. Цей компонент відповідає за короткострокове та довгострокове зберігання зібраних оброблених та “сирих” даних.
Аналіз. На цьому етапі ви маєте можливість виявляти інциденти та реагувати на них в автоматичному або ручному режимі.
Звітність. Цей етап допомагає сформувати для зацікавлених сторін (керівництва, аудиторів, хмарного провайдера, клієнтів тощо) ключові показники, які допомагають нам приймати ті чи інші рішення, наприклад зміна провайдера або посилення ІБ.

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

Вбудовані можливості хмарних сервісів

Вище я вже написав, що дуже багато хмарних сервісів сьогодні не надають жодної можливості з моніторингу ІБ. Взагалі, темі ІБ вони приділяють невелику увагу. Наприклад, один з популярних російських сервісів з відправки до державних органів звітності через Інтернет (спеціально не згадуватиму його ім'я). Весь розділ про безпеку цього сервісу обертається навколо використання сертифікованих СКЗІ. Розділ по ІБ іншого вітчизняного хмарного сервісу з електронного документообігу значно більше. У ньому йдеться про сертифікати відкритих ключів, сертифіковану криптографію, усунення web-уразливостей, захист від 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".
Injection-атаки (наприклад, SQL injection) через сплески "помилок 500".
Відомі інструменти для атак sqlmap, nik, 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 + рішення open source 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):

Activity Logs - цей журнал відповідає на класичні питання "хто", "що" і "коли" щодо будь-якої операції запису (PUT, POST, DELETE) над хмарними ресурсами. Події, пов'язані з доступом на читання (GET) до цього журналу не потрапляють, як і низка інших.
Diagnostic Logs — містить дані про операції з тим чи іншим ресурсом, що входить до вашої передплати.
Azure AD reporting — містить як активність користувача, так і системну активність, пов'язану з управлінням групами і користувачами.
Windows Event Log і Linux Syslog - містить події з віртуальних машин, що розміщуються у хмарі.
Metrics - містить телеметрію про стан продуктивності та "здоров'я" ваших хмарних сервісів та ресурсів. Вимірюються щохвилини та зберігаються. протягом 30 днів.
Network Security Group Flow Logs — містить дані щодо мережевих подій безпеки, які збираються за допомогою сервісу Network Watcher та моніторингу ресурсів на рівні мережі.
Storage Logs – містить події, пов'язані з доступом до сховищ.

Для моніторингу можна використовувати зовнішні 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 online, 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 у вас з'являється можливість підключати до Sentinel власні фіди Threat Intelligence, що збагачує можливості аналізу інцидентів у вашій хмарі 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:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: 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.com%2Faccess_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

Моніторинг безпеки хмар