BSides Sofia 2022: Common security pitfalls in AWS Public cloud for highly regulated industries

2:23↗самата операционна система, не вие сте отговорни. Дейтата, да я инкрипнете, вие сте отговорни. Много е важно, ключово е да познавате shared responsibility модела, който публичните кладоставчици правят и доставят за вас. Тук е едно много бързо припомняне.

2:44↗Ако управляваме workload върху on-premises среда, кои са отговорностите, които ние имаме, Целият стек, който е най-вляво, on-premises, ние отговаряме за дейта центровете, за физическата сигурност, за укабеляването, за бондинга на интерфейсите, за ракста, когато изгорият хард дискове, ние ги сменяме и прочее. Нагоре по целият стек, да сложим хипервайзор, да сложим виртуалната машина отгоре, да енкриптваме и да правим всичко. Ако изберем публичен клауд в инфраструкчъра за сервис модела, Това, което виждаме, че част от тези отговорности и когато дойдат аудитори да ни питат тук сигурна ли е вашата сведая, отговоря ли на този комплианс фреймворки и чеклист, вече един сет от отговорности не е наш. Вече делегираме, показваме как повечният клад вендор го прави, но не ни аудитират нас. Тоест намалява ни оверхед, който иначе ние имаме.

3:43↗Ако пък използваме PAS тип система, вижте, още по-голяма част е плета от публичен клад доставчик. Нашите отговорности са доста намалени. В сервер лес света, когато използваме контейнери или пък ламда функции в контекст на AWS, отговорността са на още по-малко. Ние отговаряме само за кода. Може да си им правим сканиране на кода, той сигурен ли е статик код анализ и прочее. Но за цялата инфраструктура отдолу нас не ни аудитират. Аудитират публичният клад. т.е. кой имаме audit или security check, който трябва да минем, хенд офваме, което много ни улеснява. Това ни позволява ние по-бързо да вървим, да доставим фичери като бизнес. Делегираме тежката non-value adding работа на някой друг. И вече в SaaS модела е ясен. Ето тук един много бърз пример искам да дам, ако трябва да управляваме релационна база данни. Ако ние трябва да го правим в он-премисът с дейта център, имаме

4:44↗захранване, рак на серварите, мейнтенънс, инсталиване на операционна система патчове, инсталиване на базата данни, инсталиване на патчовете на базата данни, правене на high availability,

4:57↗така, скейлинг и ап оптимизейшн. Ако изберем да инсталираме

5:02↗Релационна база данни. Върху публичният клауд в вид на виртуална машина или Infrastructure as a Service модела, част от тези отговорности остават на публичният клауд доставчик, което е окей. Едновременно с това ние имаме и немалка част, за която трябва да отговаряме. Ако излезе следващ бък в и операционната система, но и в базата ни данни, ние сме отговорни да го пачнем. Това, което повечето публикова доставчици предлагат са менеджед услуги. И в случая AWS има Relational Database Service, който изцяло менажира на услуга от тях. Ако сравним това, за което те отговарят, ние можем да се фокусираме единствено върху това да доставим по-бързо, по-качествен код и по-качествен сервис. Те се грижат... да апдейтват операционната система, да пачват базата данни и прочее, което много ни улеснява и ни отмята от тази non-value adding работа, която иначе може би ни се намага

6:07↗да правим. Втората тема, когато искаме да постигнем сигурност върху публичният клад и върху AWS, това е да използваме отделни акаунти. Може би имаме един, може би имаме няколко, може би имаме повече. И добра идея е да използваме AWS аккаунт per workload. Може би да сложим един за development, един за production, един за sandbox. Има компании, които оперират с десетки, има компании, които оперират дори с хиляди AWS аккаунти. Има компании, в които всеки от микросървисите работи изолиран в AWS аккаунт, други пък правят

6:39↗акаунти на всеки от служителите си, за да може да се упражнява в такъв изолиран, дедикейтнат акаунт за всеки от нас. В AWS един акаунт е напълно изолиран от друг AWS акаунт. Тоест имаме абсолютно пълна независимост между ресурсите, които пускаме.

6:55↗Акаунта, структурата и винаги когато правим акаунт структура, имаме така наречен Organizations Account, който управлява другите. И аз осъзнавам, че тук графиката е малко по-малка, но исках да покажа най-отгоре. Имаме един Organizations Account, който контролира и налага, има правото да налага security ограничения на всеки един от другите акаунти. То е така нареченето Organizations Account. Ще минам през част от сервисите, които препоръчвам да бъдат пуснати във всеки организационал акаунт, чисто практически. Сървис контрол полиси и SCP като абревиатура, виждам, че се повтаря и от предишни презентации. Но това е моделът, в който ние можем да кажем в определени акаунти, да са достъпни определени сервиси, но други да не са достъпни. Веднъж прилагайки SCP, сервис контрол политика към един аккаунт, никой в този аккаунт, нито дори рулот потребителя не може да излезе

7:54↗от това нещо. Изключително силен подход. Ако искате нещо да не се случва във вашия AWS аккаунт, може да му наложите SCP. Изключително силен подход. AWS Single Sign-On решава проблемата ни с Identity and Access Management. Централно място има възможност да го интегрираме с външни Identity Providerи, независимо окта или пинк или активна директория. Ние можем да го направим. Тоест, едно централно място, което да управляваме целият Identity and Access Management по множеството си акаунти. AWS Cloud Trail е сервис, който записва всеки API call, който се случва към публичният клауд. И

8:33↗дава ни пълна проследимост. Кой, какво, кога е направил. Тоест пълен audit,

8:39↗пълно проследяване. Един от плюсовете на това CloudTrail да бъде пуснат в организацията е, че той каскадно се пуска във всички акаунти и никой не може да го спре. Тоест в случай, в който нашия AWS аккаунт бъде пробит и ние искаме да разберем какво се е случило, никой не може да изтрия логовето. Ние вече ги имаме и ги събираме на едно централно място. което е супер.

9:06↗Access Analyzer е от по-новите сервиси в AWS, които ни позволяват да събираме, когато наши потребители достъпват или правят API колове, Access Analyzer го събира и ни помага да направи Fine-grained Access. Какво е Fine-grained Access? Наблюдава какво потребителите са правили в

9:31↗назад във времето. В последните три месеца какво правят потребителите ни или определени сервиси, след това автоматично генерира политика, която каза позволявам само това, защото три месеца назад потребителят не е правил нищо друго. Тоест позволява ни автоматично да намаляваме сколпа на привилегии, които иначе ние може да сме по погрешка, може би и по-снали по-широк. Тоест много силен сервис. Security Hub, може би също задължителен, го намирам. Красив дашборд работи в два модела, т.е. всъщност в три режима може да го пуснем. Автоматизирани чекове, които веднъж на ден проверяват един голям сет от правила. Може да го пуснем с CIS фреймворка, т.е. всичките правила, които идват от Center for Internet Security или Foundational Security Best Practices, които идват пък от Amazon. Това е красив дашборд, Security Hub, ние го пускаме във всеки акаунт,

10:30↗в който оперираме и също може да се пусне на организационно ниво, така че да събира информацията и да показва къде какво не е наред. Като примерно имаме Object Storage или S3, който е публичен, имаме Firewall, който позволява 22

10:46↗порт, че е отворен към света и прочее. Едно централно място с предефинивани правила, които

10:54↗да ни го покажат. AWS Conformance Pack и аз осъзнавам, че набързо минавам през тези тулове, после ще го имам в презентацията и разбира се, сега нямаме време да навлезем във всеки един от тях, но само като идея. AWS Config представлява услуга, в която можем и ние да пишем правила, но има и вече готови дефинирани от AWS. Има готови пакове от правила и като правило може да бъде нека проверяваме всеки ден сториджът на виртуалните ни машини, инкрипнат ли е. Нека да проверяваме лолд балансърите, достъпни ли само по HTP S без HTTP. Въобще всичко, което искаме, можем да си напишем правила, които да бъдат проверявани. Conformance паковете е съсед от правила, които на готово AWS дава за нас и има такива готови, независимо от индустрията, в която оперираме. Имаме за PCI DSS, ако сме в финансовата индустрия, имаме в HIP, ако сме в healthcare

11:49↗индустрията, прочие, прочие. Препоръчвам да се обърне внимание, ако имате да...

11:56↗гарантирате пред аудитори всиче отговаряме на управлени правила. GuardDuty Intrusion Detection система в AWS, тя е напълно автоматизирана. Това е нещо, което само пускаме и ни праща нотификации. Не е превеншен система, само детекшен такава. И приключвам вече с разглеждането на сервиси. На Systems Manager, ако имате флотили от виртуални машини, които трябва да наблюдавате, има ли последните патчове, какво е инсталирано на тях, inventory management, ако искаме да се берем на едно централно място, Systems Manager може да направи това нещо. Може да направи още много други неща, но още повече, въпреки че AWS услуга, може да инсталираме агента в нашата он-премисе с сведа, т.е. кои имаме дейта центрове, може да си инсталираме агента и в клауда, в AWS, да видим по кои машини, кои патчове са инсталивани,

12:51↗можем включително да направим политики за автоматични апдейтвани патчове, което отнема от доста ръчната работа, иначе... Супер, една по-различна тема. Винаги когато създаваме ресурс в публичният облак, това резултира в API call. Независимо дали създаваме база данни, виртуална машина, лол балансер, секьюрити група или каквото и да е било, независимо дали го правим през веб конзолата, където кликаме с мишката, през SDK-то или пък през CLI-ът, това резултира в API call.

13:26↗Щом е таката, ние можем да го автоматизираме. Щом е API Call, ние можем да инвестираме достатъчно. Най-простото е да си кажем, щом създаването на мрежови слой и компют слой, API Call, аз мога да си напиша скриптове. Разбира се, скриптовете не винаги са достатъчно. Има готови тулове, които правят dependency management-а между услугите. така че да се създадат в правилният ред. И подходът е познат като инфраструкция разкод и ако не го използваме, много силно препоръчвам да му обърнем внимание. Инфраструкция разкод, част от плюсовете, разбира се, сигурност. Цялата ни инфраструктура отново е описана като код, като source код. Никой не ходи да цъка на ръка, каквото и да е било. Представете си сега силата на това нещо. Ние първо пишем кода, Можем, защо е по-сигурно, можем да си вкараме вътрешни peer review процес. Може да видим, че

14:21↗определени security групи или това е рълва правила не спазват политиката в компанията ни. И това е още преди да стигне до production. Това е още ниво, докато го пишем. Auditable and traceable, разбира се, source code от ни е в version control, git repository, може би, така че имаме пълна проследимост. Кой кога, какво е променил, кой го е одобрил, кой го е ревюирал. Репитабл и консистент пък ни позволява една и съща инфраструктура с Infrastructure as Code да я пусне множество пъти. Ако искаме и в историята си назад, аз съм виждал production downtime, може би всеки от вас, заради неконсистентност между production, staging, development следите. Infrastructure as Code решава и този проблем, кода, услугите е еднакъв навсякъде, може би DEF и Staging са по-даунскейлнати, просто като компьютер, за да не се плаща толкова много. Документирана, разбира се, по...

15:18↗всичко е като код, така че е документирано, може да бъде част от нашия CI-CD процес, така че вече има автоматизирани тулове, които да проверяват нашата инфраструктура, още преди да сме качили, още преди да сме аплайнали, преди да се е появил проблема, може да сканираме и да ни кажем да, ето тук имате проблем. И кост ефективна, както има тулове, които да проверяват за сигурността в нашия код, вече има тулове, които сканират в момента най-вече Terraform, които казват, новият код, който сте написали, ще струва допълнително 300 долара на месец. Тоест, отново, създаваме повече предвидимост за нашата инфраструктура. Или пък ще струва по-малко, защото правим оптимизации. И това е още преди да сме го опуснали в продъкшн. Преди да въобще да сме създали тази инфраструктура, ние имаме информацията, колко ще струва и колко е сигурна на

16:11↗сведата ни. Чеков е може би един от най-известните тулове, много добра интеграция с Terraform. За момента при мен е най-доказалият се ту, който аз и ползвам за сканиране на Terraform кода и на Infrastructure as Code кода.

16:30↗Друго нещо, с което публицията клад доставчици ни помагат и ако стаминавали през ODI, по някакъв път може да виждате неща, които може би ни се струват безумни, просто контрол чек-листа. Там е дефинирано от аудитора или от

16:48↗фреймворка по-скоро какво трябва да бъде изпълнено, но как това резултира към техническата имплементация, не винаги е едно към едно, не винаги има директен мапинг. Публичните клад доставчици, в случая AWS, дават security control мапинг матрица, буквално за повечето. В случая съм показал за HIPA, който е валиден в healthcare индустрията, но превеждат audit правило към техническа реализация, какво те смятат, че е приложено, което пести страшно много време, когато ние искаме да постигнем също нещо. Темата за управлението на нашата дейта, разбира се, тя е ключова. Data residency and sovereignty, къде се намира нашата дейта, независимо дали трябва да отговаряме на GDPR или Калифорния, Customer Privacy Act.

17:42↗Публичен клаут ни задава възможността ние да избираме в кой регион по света да пуснем нашата инфраструктура, къде да се намира. Compute Power Storage също където, който използваме. В момента AWS има над 24 региона, с 6 вече анонснати още по света, които са им прогрес. Така че имаме избора на това спрямо дейта, регулацията и закона и индустрията, в която се намираме, ние да изберем

18:11↗правилната локация. Още нещо, с което пък ни помага публичният клауд са така речените референтни архитектури, готови архитектури. Ако си мислим, че ние сме първите, които искаме да правим PCI DSS върху публичния клауд, това не е така. Много компании вече са минали през този процес, ами това, което правят от AWS е да кажат, вижте, препоръчваме ви, когато вие правите PCI DSS, когато правите HIPA, когато правите други видове workload-и, използвайте тези темплейти. може да ги преизползваме директно или може да се...

18:49↗просто да ги възгледаме и да ги преизползваме по начин, по който ни харесват. Независимо от домейна отново, в който се намират, Security Identity Compliance, Analytics Big Data, Compute, още много готови референтни архитектури има, които да ни помогнат да деплойнем workload-а по правилният за compliance framework, на който трябва да отговаряме начин.

19:12↗Част от compliance програмата на AWS, тук виждате и Solar, разбира се, стандартите, и HIPAA, и PCI DSS, може би се вижда някъде. Department of Defense също, FedRAMP, пък ако работите с компании или клиентите, вие работите с Американското правителство, също е ключово нещо.

19:38↗Можем да реферираме към Клиентите, просто да видим кейс-стъдитата, има банки, които оперират изцяло върху AWS. Тоест не е в хибриден режим. Почти от всеки бизнес домейн има компании, които оперират върху AWS изцяло. И тук, Насдак пък, в тази година, Насдак ще пусне първият си пазар на опции върху AWS, което е още по-впечатляващо.

20:11↗като информация. Иначе да, редица услуги. Робин Худ, може би ви е позната също.

20:18↗Окей, и разбира се, ако искаме да изградим наистина сигурна сведа, без културният елемент, без това да работим заедно, с секьюрити хората, с хората, които доставят или изграждат софтуера, с девелопмент, с оперейшн хората, е по-трудно ако работим само в отделни силузи. Преди говорихме за това да щупим стената между Dev и Ops и тази DevOps култура, вече и го наричаме DevSecOps. Това да работим повече, да щупим, буквално да седнем на едно бюро заедно и да работим, това ще доведе до по-бързи резултати, до по-сигурна сведа. Тоест да работим повече. В крайна сметка всички ние имаме една обща цел. По-сигурен работещ софтуер, който да обслужва нашите клиенти или клиентите на клиентите ни.

21:10↗Нещо натиснах. И само последно нещо, което може би изглежда сложно тук, но искам да го спомена. Всичко в публичният клауд е въпрос на API calls. Том API call, то ние можем включително да автоматизираме нашите incident response процедури и процеси.

21:28↗Обичайно какво правим? Имаме инцидент, да кажем виртуална машина, антивирусната е засекла, че има вирус. Какво правим? Ами ако беше ръчен режима, щяхме да се свържем към машината, може би да започнем да разглеждаме, да направим снапшот на тази машина, може би memory dump. Ами един такъв playbook, същото може да го автоматизираме. и да оставим да се екзекютне сега, независимо от част от botnet, изпраща спам, прочее. Това, което може да автоматизираме, е автоматично тази машина, една виптована машина, да ѝ се направи снапшот на диска, да се свържем към нея, да направим memory dump, този memory dump, също да го запазим, за да ги предоставим на forensics екипа, да капсулуваме тази машина, чрез така наречен security група, т.е. да спрем изходящия и иначе входящ трафик към нея,

22:17↗и да я загасим в последствие, след като сме събрали данните за флоренцика с екипа. И това нещо може да е напълно автоматизирано. Не е нужно ние в два часа да се чудим какво да правим. Отново, всичко е въпрос на API Call и публичният клаут ни позволява да направим такива автоматизирани инцидент респонси.

22:39↗Много бърз. Рекап. Да познаваме shared responsibility модела, който ни задава публичният клауд, да използваме multi-account стратегия, да използваме повече менедж сервиси, защото това ни фокусира върху повече, върху това, което помагаме на бизнеса си да предоставя повече стойност на нашите клиенти, вместо да менеджираме сервери и да правим окабеляване.

23:02↗Security Hub е може би ключов за мен сервис, инфраструкция, резкоот и да работим заедно. Последни думи от мен, AWS имат Рейнфорс конференция, веднъж в годината се случва, тази година ще е в Бостон, ако някому е интересно, иначе и Рейнвент, която е годишната конференция, абсолютна темата за сигурност е много-много силно засегната и препоръчвам да се види. Ако някой вече работи в AWS и трябва да управляваме сигурни лърклоуди, много силно препоръчам сертификация. Има си official study guide, който си е от AWS около AWS security компетенция. И да, препоръчам го. Оставил съм така част от ресурсите и темата разбира се е голяма, така че и списъка с ресурси не е малък. Да, заповядайте на AWS Yousup-групата ни, където говорим и за сигурност, и за много други неща. Ако искате да поражим разговора, аз съм на линия. Благодаря ви.

24:11↗Ако има въпроси.

24:43↗Добър е въпросът, ще го преразкажа с мои думи. Въпросът е дали трябва да избираме един публичен клауд доставчик, в случай AWS, при положение, че видяхме тази година, Норд Вирджиния региона с Чупи за период от време, имаше бизнеси, то не малки, които претърпяха даун тайм. Спрямо альтернативът, която е да използвам мулти клауд доставчици. Добре ли го преразказах? Един от... Това по-скоро е бизнес проблем, той не е толкова много технически, но общото, да може къмън...

25:17↗най-малкото общо кратно между всичките публични доставчици е много малко. Тоест много е трудно да изградим мулти-клауд сведа, в която всички ние да имаме компетенциите, да следим новините, да следим security advisorите на всичко. Тоест има компании и то...

25:35↗не малки, Uber да кажем, които се опитват да правят, в смисъл компании с пари, с много пари, които искат да направят това нещо. По-скоро обратната гледна точка е

25:45↗по-добра. Нека да изберем един публичен клауд доставчик, върху който да бъдем специалисти и ако той фейлне след време, щупи се, вдигне ни цените, направи нещо огромно, цената за миграция от един на друг е по-ниска, отколкото цената да оперираме два клауда едновременно. Това е в Everage случая. Предполагам има и различни use case-и, но това е в общият случай. Е по-ефтимно да изберем едно, в което да бъдем професионалисти. Много е трудно да бъдем професионалисти на експертно ниво в два клауда. Работя в такъв екип, изгражда такъв екип и е много трудно. Това е общото мнение. Това не е моето мнение. По-скоро идва от ентерпрайз блоговете

26:32↗на публициите клауддоставчици. Темата е широка разбира се около вендор локин

26:39↗и широка е темата. Кубернетис някой може да каже да той решава всичко едновременно с това. Кубернетис създава абстракция донякъде, но ако мислим за словията, които са отдолу, Storage Encryption, World Balancing дори, мръжовия слой, SEL сертификати,

26:57↗мръжовия стек, ами Не е тривиално. Обърнете се, не е едно решение, което да го направи. Повечето компании, които говорят за Multicloud са такива, които печелят от Multicloud. Hercorp са една такава. Те произвеждат тулове, които са Multicloud тулове. В техният годишен репорт ще видите как Multicloud-ът все по-голяма adoption има. Който е...

27:21↗това, което те искат, за да продават по-добре тълува, което е супер. Също и мультиклауд

27:28↗силно се тръби от по-малки клауд вендори. Оркал има по-търни процент маркет шея по последните Гарднер доклади. Разбира се, че те ще тръбят, хе, използвайте мультиклауд. Защо? Защо това е начин за по-малък публичен клауд да вземе повече бизнес. Темата е голяма, но благодаря за въпроса.

28:51↗Въпросът е какво правят големите коладоставчици в случва AWS, така че по-лесно ние да ги използваме и да не трябва да сме експерти по всичко. Това, което големите коладоставчици правят са много-много инициативи. Сертификацията е една такава от тях. Компании, които когато започват да използват публичният клауд, смятат, че това е само технологична промяна, но това е грешно. И AWS, и Microsoft, и Google дефинират техни клауд adoption фреймворци. Клауд adoption фреймворка говори за 6 големи теми и само една от тях е технологична.

29:32↗Темата за сигурност е една такава governance, управление на лицензии също. Темата около people, upskill и това хората могат ли да се справят? Ние супер

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

30:38↗все повече менещи услуги, които са все по-лесни за използване. Дали ще са промяни в UI интерфейса, така че когато пускаме виртуални машини, да кажем, те вече да са сигурни и порт 22 да не е публичен. Това също го правят. Или AWS

30:56↗направиха изключително трудно това един Object Storage на S3 да бъде направен публичен.

31:03↗Те го направиха труден, защото не по тяхна вина, разбира се, един клиент отива, слагат редица данни. С3 е най-големия Data Lake в света и компании започват да го използват. Това, което се случва е, че някой по погрешка го ставя публичен. Data leak, нещо, което е много лошо. И това, разбира се, човек, който го конфигурира е отговорен,

31:26↗прямо шерд респонсибилити модела, но едновременно с това вреди на цялата индустрия, защото индустрията си каза, о, използваме публичният клад и там не изтекоха данните, което не е по вина на публичният клад доставчик. Затова едно дълбоко разбиране на моделът и разбира се,

31:42↗това, което правят е точно такъв тип тулове, като security hub, които да ни дадат видимост върху енвармента, че имаме... Секюрити групи, отворени портове, не инкриптнат сторидж, лод балансъри, които не са по HPS, прочее, прочее, прочее. Тоест правят го още по-видимо. Ако до години назад беше само ето ви платформа, за да пускате виртуални машини. Вече има много редици това, които да ни улестат. Да.

32:44↗което се случва е, че когато казваме, че може да пуснем услугите си в различни региони, трябва да взем предвид, че регионите не са като хората и не се раждат равни. Т.е. те са различни. Всеки регион има по-нови региони и по-стари региони. Стари те са около 5, които са големи в нашия географска ширина. Ирландия е такъв. Те са в източния е западно от крайбрежие по един, Сингапур е още един такъв, където почти всички нови услуги отиват веднага, веднага с релиза им, що Майдал и УС го направят, отиват в големите региони. Те са най-големите въобще като дейта центрове, като компют мощности,

33:30↗дори като състейнабилити проекти. Тоест, доколко е негоефективни са, доколко е купена зелена енергия, която да се използва. По-малките региони, те съответно не поддържат всички сервиси, които иначе съществуват и това е нормално. Когато се започне или се строи Франкфурт, да кажем, като регион или Париж или Милано, регионите, те са по-малки, очакваният Compute World към тях е да бъде по-скоро регионален от Италия да използва в Милано. Тоест те нямат нужда от огромните Compute, които иначе има един по-голям регион. И не е толкова за GDPR, по-скоро е за точно Data Residence and Souverainity, темата къде седи нашата дейта. И ако вече виждаме и банки, и NASA, Department of Defense, Border Control, пък в UK използват AWS, т.е. и Government Agency, вече използват AWS, те искат данните им да не напускат страната много често. Това беше, затова отвориха и Лондон регион. Т.е.

34:32↗не е толкова за GDPR, колкото е за локалните

34:53↗Да. Да. Това е така. Това е технологично тема. Може да се адресира към AWS. Това е супер. Не знам, имаме ли време. Аз с удоволствие бих... Pino poč, biero poslije. Ne, ne, imame.

35:28↗Да, 99% и 97% от услугите. В AWS има близо 200 отделни сервиса. За всеки от тях го има с едно или две изключения. Това е така.

35:54↗Да, целта на CloudTrail, той е Да, CloudTrail е като нервната система в AWS. Когато има API Call, CloudTrail го записва. Тоест би трябвало да хващат всичко, всичко, всичко и ние сме правили редица оптимизации за всички сервиси, с които аз съм работил, е имало CloudTrail логове. Тоест аз сега не мога да се сети за сервис, който не се поддържа. И точно на база CloudTrail пак ивент, може да се направи тази автоматизация. Тоест прихващаме един ивент, че да кажем виртуална машина е пусната. Ами ние веднага може би искаме да проверим сториджа инкрипнат ли е, последните патчове ли има и прочее, когато имаме ID-то на тази машина. Тоест с по-висок процент отговорът ми е да.

36:48↗Супер, благодаря ви отново.