Маніторынг бяспекі аблокаў

Перанос дадзеных і прыкладанняў у аблокі ўяўляе сабой новую праблему для карпаратыўных 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. Першае накшталт як вырашае шматлікія праблемы за вас, але гэта не зусім так, - пры наяўнасці некалькіх часопісаў даводзіцца перамыкацца паміж якія адлюстроўваюць іх экранамі, губляючы агульную карціну. Акрамя таго, хмарны правайдэр наўрад ці падасць вам магчымасць карэляцыі падзей бяспекі і наогул аналізу іх з пункта гледжання бяспекі (звычайна вы маеце справу з волкімі дадзенымі, у якіх разбірацца вам трэба самастойна). Выключэнні ёсць і пра іх мы пагаворым далей. Нарэшце, варта пацікавіцца, а якія падзеі фіксуе ваш хмарны правайдэр, у якім фармаце, і наколькі яны адпавядаюць вашаму працэсу маніторынгу ИБ? Напрыклад, ідэнтыфікацыя і аўтэнтыфікацыя карыстальнікаў і гасцей. Той жа Бітрыкс дазваляе вам па дадзеных падзеях зафіксаваць дату і час дадзенай падзеі, імя карыстальніка або госця (пры наяўнасці модуля "Вэб-аналітыка"), аб'ект, да якога ажыццёўлены доступ і іншыя тыповыя для web-сайта элементы. Але карпаратыўным службам ИБ можа запатрабавацца інфармацыя аб тым, з ці даверанай прылады заходзіў карыстач у воблака (напрыклад, у карпаратыўнай сетцы такую ​​задачу рэалізуе 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, ніхто, 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 для 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