Cloud Security Monitoring

Az adatok és alkalmazások felhőbe helyezése új kihívást jelent a vállalati SOC-k számára, amelyek nem mindig állnak készen mások infrastruktúrájának figyelésére. A Netoskope szerint egy átlagos vállalat (nyilván az Egyesült Államokban) 1246 különböző felhőszolgáltatást használ, ami 22%-kal több, mint egy évvel ezelőtt. 1246 felhőszolgáltatás!!! Ebből 175 a HR szolgáltatásokhoz, 170 a marketinghez, 110 a kommunikációhoz és 76 a pénzügyekhez és CRM-hez kapcsolódik. A Cisco „csak” 700 külső felhőszolgáltatást használ. Szóval kicsit összezavartak ezek a számok. De mindenesetre nem velük van a probléma, hanem azzal, hogy a felhőt egyre több olyan cég kezdi elég aktívan használni, amelyek a saját hálózatukkal megegyező képességekkel szeretnének felügyelni a felhő infrastruktúráját. És ez a tendencia növekszik - szerint az Amerikai Számvevőszék szerint 2023-ra 1200 adatközpontot zárnak be az Egyesült Államokban (6250 már bezárt). A felhőre való áttérés azonban nem csupán „áthelyezzük a szervereinket egy külső szolgáltatóhoz”. Új informatikai architektúra, új szoftverek, új folyamatok, új megszorítások... Mindez jelentős változásokat hoz nemcsak az informatika, hanem az információbiztonság munkájába is. És ha a szolgáltatók megtanulták valahogy megbirkózni magának a felhőnek a biztonságának biztosításával (szerencsére sok ajánlás van), akkor a felhő információbiztonsági felügyeletével, különösen a SaaS platformokon, jelentős nehézségek adódnak, amelyekről beszélni fogunk.

Tegyük fel, hogy cége infrastruktúrájának egy részét a felhőbe helyezte át... Állj. Nem így. Ha az infrastruktúra átadásra került, és csak most gondolkodik azon, hogyan fogja azt felügyelni, akkor már vesztett. Hacsak nem az Amazon, a Google vagy a Microsoft (és akkor fenntartásokkal), valószínűleg nem lesz sok lehetősége az adatok és alkalmazások figyelésére. Jó, ha lehetőséget kap a rönkökkel való munkavégzésre. Néha a biztonsági események adatai elérhetők lesznek, de Ön nem fog hozzáférni. Például az Office 365. Ha a legolcsóbb E1 licenccel rendelkezik, akkor a biztonsági események egyáltalán nem érhetők el. Ha E3-as licenccel rendelkezik, az adatait csak 90 napig tároljuk, és csak E5-licenc esetén a naplók időtartama egy évig elérhető (azonban ennek is megvannak a maga árnyalatai a külön szükségesség miatt kérhet számos funkciót a naplókkal való munkához a Microsoft támogatásától). Az E3 licenc egyébként a felügyeleti funkciók tekintetében sokkal gyengébb, mint a céges Exchange. Ugyanezen szint eléréséhez E5 licencre vagy további Advanced Compliance licencre van szüksége, ami további pénzt igényelhet, amelyet nem vettek figyelembe a felhőinfrastruktúrára való átálláshoz. És ez csak egy példa a felhőalapú információbiztonság megfigyelésével kapcsolatos problémák alábecsülésére. Ebben a cikkben a teljesség színleltsége nélkül szeretném felhívni a figyelmet néhány árnyalatra, amelyeket figyelembe kell venni a felhőszolgáltató kiválasztásakor biztonsági szempontból. A cikk végén pedig egy ellenőrző lista kerül bemutatásra, amelyet érdemes kitölteni, mielőtt azt gondolnánk, hogy a felhő információbiztonságának felügyelete megoldódott.

A felhőkörnyezetekben számos tipikus probléma vezet olyan incidensekhez, amelyekre az információbiztonsági szolgálatoknak nincs idejük reagálni, vagy egyáltalán nem látják őket:

• Biztonsági naplók nem léteznek. Ez meglehetősen gyakori helyzet, különösen a felhőmegoldások piacának kezdő szereplői körében. De nem szabad azonnal lemondani róluk. A kis szereplők, különösen a hazaiak, érzékenyebbek a vevői igényekre, és gyorsan megvalósíthatnak néhány szükséges funkciót a termékeik jóváhagyott ütemtervének megváltoztatásával. Igen, ez nem az Amazon GuardDuty vagy a Bitrix „Proaktív védelem” moduljának analógja, de legalább valami.
• Az információbiztonság nem tudja, hol tárolják a naplókat, vagy nincs hozzáférésük hozzájuk. Itt tárgyalásokat kell kezdeni a felhőszolgáltatóval – talán ő ad ilyen tájékoztatást, ha fontosnak tartja az ügyfelet. De általában nem túl jó, ha a naplókhoz való hozzáférést „külön döntés alapján” biztosítják.
• Az is előfordul, hogy a felhőszolgáltató rendelkezik naplókkal, de korlátozottan biztosítanak megfigyelést és eseményrögzítést, ami nem elegendő az összes incidens észleléséhez. Például előfordulhat, hogy csak a webhelyen végrehajtott módosítások naplóit vagy a felhasználói hitelesítési kísérletek naplóit kapja meg, de más eseményeket, például hálózati forgalmat nem, amelyek elrejtik Ön elől a felhő-infrastruktúra feltörési kísérleteit jellemző események egész rétegét.
• Vannak naplók, de az ezekhez való hozzáférés nehezen automatizálható, emiatt nem folyamatosan, hanem ütemezetten kell figyelni őket. Ha pedig nem tudja automatikusan letölteni a naplókat, akkor a naplók például Excel formátumban történő letöltése (mint számos hazai felhőmegoldás szolgáltatója esetében) akár a vállalati információbiztonsági szolgálat vonakodásához is vezethet a trükközéstől.
• Nincs naplófigyelés. Talán ez a leginkább tisztázatlan oka az információbiztonsági incidensek felhőkörnyezetekben történő előfordulásának. Úgy tűnik, vannak naplók, és lehetséges automatizálni a hozzáférést, de ezt senki sem teszi meg. Miért?

Megosztott felhő biztonsági koncepció

A felhőre való átállás mindig az egyensúly keresése az infrastruktúra feletti irányítás fenntartása és az infrastruktúra karbantartására szakosodott felhőszolgáltató professzionálisabb kezeibe való átadása között. És a felhőbiztonság területén is ezt az egyensúlyt kell keresni. Sőt, az alkalmazott felhőszolgáltatás-szolgáltatási modelltől (IaaS, PaaS, SaaS) függően ez az egyenleg mindig eltérő lesz. Mindenesetre emlékeznünk kell arra, hogy ma minden felhőszolgáltató az úgynevezett megosztott felelősség és megosztott információbiztonsági modellt követi. Egyes dolgokért a felhő a felelős, másokért pedig a kliens, aki a felhőben helyezi el adatait, alkalmazásait, virtuális gépeit és egyéb erőforrásait. Meggondolatlanság lenne azt várni, hogy a felhőbe lépve minden felelősséget a szolgáltatóra hárítunk. De az sem bölcs dolog, ha a felhőbe költözéskor maga építi fel a biztonságot. Egyensúlyra van szükség, ami sok tényezőtől függ: - kockázatkezelési stratégia, fenyegetési modell, a felhőszolgáltató rendelkezésére álló biztonsági mechanizmusok, jogszabályok stb.

Például a felhőben tárolt adatok osztályozása mindig az ügyfél felelőssége. Egy felhőszolgáltató vagy egy külső szolgáltató csak olyan eszközökkel tud neki segíteni, amelyek segítenek az adatok felhőben történő megjelölésében, a jogsértések azonosításában, a törvénysértő adatok törlésében, illetve ilyen vagy olyan módszerekkel történő elfedésében. Másrészt a fizikai biztonság mindig a felhőszolgáltató felelőssége, amelyet nem tud megosztani az ügyfelekkel. De minden, ami az adatok és a fizikai infrastruktúra között van, pontosan ennek a cikknek a témája. Például a felhő elérhetősége a szolgáltató felelőssége, a tűzfalszabályok beállítása vagy a titkosítás engedélyezése pedig az ügyfél felelőssége. Ebben a cikkben megpróbáljuk megvizsgálni, milyen információbiztonsági felügyeleti mechanizmusokat biztosítanak ma a különböző népszerű oroszországi felhőszolgáltatók, melyek azok használatának jellemzői, és mikor érdemes a külső overlay megoldások felé fordulni (például Cisco E- mail Security), amelyek kibővítik a felhő képességeit a kiberbiztonság terén. Bizonyos esetekben, különösen, ha többfelhős stratégiát követ, nincs más választása, mint külső információbiztonsági megfigyelési megoldások használata több felhőkörnyezetben egyszerre (például Cisco CloudLock vagy Cisco Stealthwatch Cloud). Nos, bizonyos esetekben rájössz, hogy az Ön által választott (vagy rájuk kényszerített) felhőszolgáltató egyáltalán nem kínál információbiztonsági megfigyelési képességeket. Ez kellemetlen, de nem is kevés, mivel lehetővé teszi, hogy megfelelően felmérje a felhővel való munkavégzéssel kapcsolatos kockázati szintet.

Cloud Security Monitoring Lifecycle

A használt felhők biztonságának nyomon követésére csak három lehetőség közül választhat:

• támaszkodjon a felhőszolgáltató által biztosított eszközökre,
• harmadik felektől származó megoldások használata, amelyek figyelik az Ön által használt IaaS, PaaS vagy SaaS platformokat,
• saját felhőfelügyeleti infrastruktúráját építheti fel (csak IaaS/PaaS platformokhoz).

Nézzük meg, hogy ezeknek a lehetőségeknek milyen jellemzői vannak. Először azonban meg kell értenünk az általános keretrendszert, amelyet a felhőplatformok figyelésekor használunk. A felhőben zajló információbiztonság-felügyeleti folyamat 6 fő összetevőjét emelném ki:

• Infrastruktúra előkészítése. Az információbiztonság szempontjából fontos események tárba gyűjtéséhez szükséges alkalmazások és infrastruktúra meghatározása.
• Gyűjtemény. Ebben a szakaszban a biztonsági eseményeket különböző forrásokból összesítik a későbbi feldolgozás, tárolás és elemzés céljából.
• Kezelés. Ebben a szakaszban az adatokat átalakítják és gazdagítják a későbbi elemzés megkönnyítése érdekében.
• Tárolás. Ez az összetevő felelős az összegyűjtött feldolgozott és nyers adatok rövid és hosszú távú tárolásáért.
• Elemzés. Ebben a szakaszban képes észlelni az eseményeket, és automatikusan vagy manuálisan reagálni rájuk.
• Jelentés. Ez a szakasz segít olyan kulcsindikátorok megfogalmazásában az érintettek (menedzsment, auditorok, felhőszolgáltató, ügyfelek, stb.) számára, amelyek segítenek bizonyos döntések meghozatalában, például szolgáltatóváltás vagy információbiztonság erősítése esetén.

Ezen összetevők megértése lehetővé teszi, hogy a jövőben gyorsan eldöntse, mit vehet át szolgáltatójától, és mit kell tennie saját maga vagy külső tanácsadók bevonásával.

Beépített felhőszolgáltatások

Fentebb már írtam, hogy manapság sok felhőszolgáltatás nem nyújt semmilyen információbiztonsági felügyeleti lehetőséget. Általában nem fordítanak különösebb figyelmet az információbiztonság témájára. Például az egyik népszerű orosz szolgáltatás, amely jelentéseket küld a kormányzati szerveknek az interneten keresztül (a nevét nem említem meg). A szolgáltatás biztonságáról szóló teljes szakasz a tanúsított CIPF használata körül forog. Nincs ez másként egy másik hazai felhőszolgáltatás elektronikus dokumentumkezelésre szánt információbiztonsági részlegénél sem. Szó esik a nyilvános kulcsú tanúsítványokról, a hitelesített kriptográfiáról, a webes sebezhetőségek kiküszöböléséről, a DDoS támadások elleni védelemről, a tűzfalak használatáról, a biztonsági mentésekről, sőt a rendszeres információbiztonsági auditokról is. De szó sincs monitorozásról, sem arról, hogy a szolgáltató ügyfeleit érdeklő információbiztonsági eseményekhez hozzá lehet jutni.

Általánosságban elmondható, hogy abból, ahogy a felhőszolgáltató leírja az információbiztonsági problémákat a webhelyén és a dokumentációjában, megértheti, mennyire komolyan veszi ezt a problémát. Például, ha elolvassa a „My Office” termékek kézikönyveit, akkor a biztonságról egy szó sem esik, hanem a külön termék „My Office” dokumentációjában. A jogosulatlan hozzáférés elleni védelemre tervezett KS3-ban az FSTEC 17. rendjébe tartozó pontok szokásos listája található, amelyet a „My Office.KS3” megvalósít, de nincs leírva, hogyan valósítja meg, és ami a legfontosabb, hogyan integrálni ezeket a mechanizmusokat a vállalati információbiztonsággal. Talán létezik ilyen dokumentáció, de nem találtam nyilvánosan, a „My Office” weboldalon. Bár lehet, hogy nem férek hozzá ehhez a titkos információhoz?

Bitrix esetében sokkal jobb a helyzet. A dokumentáció leírja az eseménynaplók formátumait, és érdekes módon a behatolási naplót, amely a felhőplatformot fenyegető potenciális veszélyekkel kapcsolatos eseményeket tartalmazza. Innen kihúzhatja az IP-címet, a felhasználó vagy a vendég nevét, az esemény forrását, idejét, felhasználói ügynökét, eseménytípusát stb. Igaz, ezekkel az eseményekkel akár magáról a felhő vezérlőpultjáról dolgozhat, vagy adatokat tölthet fel MS Excel formátumban. Most már nehéz automatizálni a Bitrix naplókkal végzett munkát, és a munka egy részét manuálisan kell elvégeznie (a jelentés feltöltése és a SIEM-be való betöltése). De ha emlékszünk arra, hogy viszonylag a közelmúltig nem létezett ilyen lehetőség, akkor ez nagy előrelépés. Ugyanakkor szeretném megjegyezni, hogy sok külföldi felhőszolgáltató kínál hasonló funkciókat „kezdőknek” - vagy nézze meg a naplókat a szemével a vezérlőpulton keresztül, vagy töltse fel az adatokat saját magának (a legtöbb adat azonban . csv formátum, nem Excel).

A naplózás nélküli opció figyelembevétele nélkül a felhőszolgáltatók általában három lehetőséget kínálnak a biztonsági események figyelésére – irányítópultok, adatfeltöltés és API-hozzáférés. Úgy tűnik, hogy az első sok problémát megold Önnek, de ez nem teljesen igaz - ha több magazinja van, váltania kell az ezeket megjelenítő képernyők között, elveszítve az összképet. Ezenkívül a felhőszolgáltató valószínűleg nem fogja biztosítani az Ön számára a biztonsági események összefüggésbe hozásának és általános elemzésének lehetőségét biztonsági szempontból (általában nyers adatokkal van dolgunk, amelyeket magának kell megértenie). Vannak kivételek, róluk a továbbiakban fogunk beszélni. Végül érdemes megkérdezni, hogy a felhőszolgáltató milyen eseményeket rögzít, milyen formátumban, és ezek hogyan felelnek meg az Ön információbiztonsági felügyeleti folyamatának? Például a felhasználók és a vendégek azonosítása és hitelesítése. Ugyanez a Bitrix lehetővé teszi, hogy ezen események alapján rögzítse az esemény dátumát és időpontját, a felhasználó vagy a vendég nevét (ha rendelkezik a „Web Analytics” modullal), az elért objektumot és a webhelyre jellemző egyéb elemeket. . A vállalati információbiztonsági szolgáltatásoknak azonban információra lehet szüksége arról, hogy a felhasználó megbízható eszközről férhetett-e hozzá a felhőhöz (például vállalati hálózatban ezt a feladatot a Cisco ISE valósítja meg). Mi a helyzet egy olyan egyszerű feladattal, mint a geo-IP funkció, amely segít meghatározni, hogy ellopták-e a felhőszolgáltatás felhasználói fiókját? És még ha a felhőszolgáltató biztosítja is Önnek, ez nem elég. Ugyanez a Cisco CloudLock nemcsak a földrajzi helymeghatározást elemzi, hanem gépi tanulást is használ ehhez, és elemzi az egyes felhasználók előzményadatait, valamint figyeli az azonosítási és hitelesítési kísérletek különböző anomáliáit. Csak az MS Azure rendelkezik hasonló funkciókkal (ha rendelkezik a megfelelő előfizetéssel).

Van még egy nehézség - mivel sok felhőszolgáltató számára az információbiztonsági megfigyelés új téma, amivel még csak most kezdenek foglalkozni, ezért folyamatosan változtatnak valamit a megoldásain. Ma van az API egyik verziója, holnap egy másik, holnapután egy harmadik. Erre is fel kell készülni. Ugyanez igaz a funkcionalitásra is, amely változhat, amit figyelembe kell venni az információbiztonsági felügyeleti rendszerében. Például az Amazonnak kezdetben különálló felhőesemény-figyelő szolgáltatásai voltak – az AWS CloudTrail és az AWS CloudWatch. Aztán megjelent egy külön szolgáltatás az információbiztonsági események figyelésére - az AWS GuardDuty. Egy idő után az Amazon elindított egy új felügyeleti rendszert, az Amazon Security Hubot, amely magában foglalja a GuardDutytól, az Amazon Inspectortól, az Amazon Macie-től és másoktól kapott adatok elemzését. Egy másik példa az Azure napló integrációs eszköze a SIEM-mel – AzLog. Sok SIEM-szállító aktívan használta, mígnem 2018-ban a Microsoft bejelentette fejlesztésének és támogatásának leállítását, ami sok, ezt az eszközt használó ügyfelet problémába ütközött (a megoldásról később beszélünk).

Ezért gondosan kövesse nyomon a felhőszolgáltató által kínált összes megfigyelési funkciót. Vagy támaszkodjon külső megoldásszolgáltatókra, akik közvetítőként működnek a SOC és a figyelni kívánt felhő között. Igen, drágább lesz (bár nem mindig), de minden felelősséget valaki más vállára hárít. Vagy nem az egészet?.. Emlékezzünk a megosztott biztonság fogalmára, és értsük meg, hogy semmit nem változtathatunk meg – egymástól függetlenül meg kell értenünk, hogyan biztosítják a különböző felhőszolgáltatók az Ön adatai, alkalmazásai, virtuális gépei és egyéb erőforrásai információbiztonságának felügyeletét. a felhőben tárolt. És kezdjük azzal, amit az Amazon kínál ebben a részben.

Példa: Információbiztonsági figyelés az IaaS-ben AWS-en alapuló

Igen, igen, megértem, hogy az Amazon nem a legjobb példa, mivel ez egy amerikai szolgáltatás, és a szélsőségesség elleni küzdelem és az Oroszországban tiltott információterjesztés részeként blokkolható. Ebben a kiadványban azonban csak azt szeretném bemutatni, hogy a különböző felhőplatformok miben térnek el információbiztonsági megfigyelési képességeikben, és mire érdemes odafigyelni, amikor biztonsági szempontból kulcsfontosságú folyamatait a felhőkbe viszi át. Nos, ha a felhőmegoldások orosz fejlesztői közül néhányan tanulnak valami hasznosat maguknak, akkor az nagyszerű lesz.

Az első dolog, amit el kell mondani, hogy Amazon nem egy áthatolhatatlan erőd. Ügyfeleivel rendszeresen történnek különféle incidensek. Például 198 millió szavazó nevét, címét, születési dátumát és telefonszámát lopták el a Deep Root Analytics szolgáltatásból. Az izraeli Nice Systems cég 14 millió Verizon-előfizető rekordját lopta el. Az AWS beépített képességei azonban lehetővé teszik az incidensek széles körének észlelését. Például:

• infrastruktúrára gyakorolt ​​hatás (DDoS)
• csomópont kompromittálás (parancsinjektálás)
• fiók kompromittálódása és jogosulatlan hozzáférés
• helytelen konfiguráció és biztonsági rések
• nem biztonságos interfészek és API-k.

Ez az eltérés abból adódik, hogy – mint fentebb megtudtuk – maga az ügyfél felelős az ügyféladatok biztonságáért. És ha nem vette a fáradságot a védőmechanizmusok bekapcsolásával, és nem kapcsolta be a megfigyelő eszközöket, akkor csak a médiától vagy az ügyfeleitől fog értesülni az esetről.

Az incidensek azonosításához az Amazon által kifejlesztett különféle megfigyelési szolgáltatások széles skáláját használhatja (bár ezeket gyakran kiegészítik külső eszközök, például az osquery). Tehát az AWS-ben minden felhasználói művelet figyelhető, függetlenül attól, hogy hogyan hajtják végre őket - a felügyeleti konzolon, parancssoron, SDK-n vagy más AWS-szolgáltatásokon keresztül. Az egyes AWS-fiókok tevékenységeinek összes rekordja (beleértve a felhasználónevet, a műveletet, a szolgáltatást, a tevékenység paramétereit és az eredményt) és az API-használatot az AWS CloudTrail szolgáltatáson keresztül érheti el. Ezeket az eseményeket (például az AWS IAM-konzol bejelentkezéseit) megtekintheti a CloudTrail konzolról, elemezheti őket az Amazon Athena segítségével, vagy „kiszervezheti” azokat külső megoldásokhoz, például Splunkhoz, AlienVaulthoz stb. Maguk az AWS CloudTrail naplók az AWS S3 tárolójában helyezkednek el.

Két másik AWS-szolgáltatás számos egyéb fontos megfigyelési képességet biztosít. Először is, az Amazon CloudWatch az AWS-erőforrások és -alkalmazások megfigyelő szolgáltatása, amely többek között lehetővé teszi a felhőben lévő különféle rendellenességek azonosítását. Minden beépített AWS-szolgáltatás, mint például az Amazon Elastic Compute Cloud (szerverek), az Amazon Relational Database Service (adatbázisok), az Amazon Elastic MapReduce (adatelemzés) és 30 másik Amazon-szolgáltatás, az Amazon CloudWatch szolgáltatást használja naplóik tárolására. A fejlesztők használhatják az Amazon CloudWatch nyílt API-ját, hogy naplófigyelő funkciót adhassanak egyéni alkalmazásokhoz és szolgáltatásokhoz, lehetővé téve számukra, hogy biztonsági kontextusban bővítsék az eseményelemzés hatókörét.

Másodszor, a VPC Flow Logs szolgáltatás lehetővé teszi az AWS-kiszolgálók által küldött vagy fogadott hálózati forgalom elemzését (külsőleg vagy belsőleg), valamint a mikroszolgáltatások között. Amikor bármely AWS VPC-erőforrás kölcsönhatásba lép a hálózattal, a VPC Flow Logs rögzíti a hálózati forgalom részleteit, beleértve a forrás és cél hálózati interfészt, valamint az IP-címeket, portokat, protokollt, a bájtok számát és a csomagok számát. fűrész. A helyi hálózat biztonságában jártasak ezt a szálakhoz hasonlónak fogják felismerni NetFlow, amely kapcsolókkal, útválasztókkal és vállalati szintű tűzfalakkal hozható létre. Ezek a naplók fontosak az információbiztonság felügyelete szempontjából, mivel a felhasználók és alkalmazások tevékenységeivel kapcsolatos eseményekkel ellentétben lehetővé teszik, hogy ne hagyja ki a hálózati interakciókat az AWS virtuális privát felhőkörnyezetben.

Összefoglalva, ez a három AWS-szolgáltatás – az AWS CloudTrail, az Amazon CloudWatch és a VPC Flow Logs – együtt meglehetősen hatékony betekintést nyújt a fiókhasználatba, a felhasználói viselkedésbe, az infrastruktúra kezelésébe, az alkalmazás- és szolgáltatástevékenységbe, valamint a hálózati tevékenységbe. Például a következő rendellenességek kimutatására használhatók:

• Kísérletek a webhely átvizsgálására, hátsó ajtók keresése, sebezhetőségek keresése a „404-es hibák” sorozatán keresztül.
• Injekciós támadások (például SQL injekció) „500 hiba” sorozaton keresztül.
• Ismert támadási eszközök az sqlmap, nikto, w3af, nmap stb. a Felhasználói ügynök mező elemzésével.

Az Amazon Web Services kiberbiztonsági célokra más szolgáltatásokat is kifejlesztett, amelyek sok más probléma megoldását teszik lehetővé. Például az AWS rendelkezik egy beépített szolgáltatással a házirendek és konfigurációk ellenőrzéséhez - AWS Config. Ez a szolgáltatás az AWS-erőforrások és konfigurációik folyamatos ellenőrzését biztosítja. Vegyünk egy egyszerű példát: Tegyük fel, hogy meg akar bizonyosodni arról, hogy a felhasználói jelszavak le vannak tiltva az összes kiszolgálón, és hogy a hozzáférés csak tanúsítványok alapján lehetséges. Az AWS Config megkönnyíti ennek ellenőrzését az összes kiszolgálón. Más házirendek is alkalmazhatók a felhőszerverekre: „Egy kiszolgáló sem használhatja a 22-es portot”, „Csak a rendszergazdák módosíthatják a tűzfalszabályokat” vagy „Csak Ivashko felhasználó hozhat létre új felhasználói fiókokat, és ő is megteheti. Csak keddenként. " 2016 nyarán az AWS Config szolgáltatást kibővítették, hogy automatizálják a kidolgozott házirendek megsértésének észlelését. Az AWS konfigurációs szabályok lényegében folyamatos konfigurációs kérések az Ön által használt Amazon-szolgáltatásokhoz, amelyek eseményeket generálnak, ha a megfelelő házirendeket megsértik. Például ahelyett, hogy rendszeres AWS-konfigurációs lekérdezéseket futtatnának annak ellenőrzésére, hogy a virtuális szerveren lévő összes lemez titkosítva van-e, az AWS-konfigurációs szabályok segítségével folyamatosan ellenőrizheti a kiszolgáló lemezeit, hogy megbizonyosodjon arról, hogy ez a feltétel teljesül. És ami a legfontosabb, a jelen kiadvány keretében minden jogsértés olyan eseményeket generál, amelyeket az Ön információbiztonsági szolgálata elemezhet.

Az AWS rendelkezik a hagyományos vállalati információbiztonsági megoldásokkal is megfelelővel, amelyek szintén generálnak biztonsági eseményeket, amelyeket elemezhet és érdemes elemezni:

• Behatolásészlelés – AWS GuardDuty
• Információszivárgás ellenőrzése - AWS Macie
• EDR (bár kicsit furcsán beszél a végpontokról a felhőben) - AWS Cloudwatch + nyílt forráskódú osquery vagy GRR megoldások
• Netflow elemzés - AWS Cloudwatch + AWS VPC Flow
• DNS-elemzés - AWS Cloudwatch + AWS Route53
• AD – AWS címtárszolgáltatás
• Fiókkezelés – AWS IAM
• SSO – AWS SSO
• biztonsági elemzés – AWS Inspector
• konfigurációkezelés – AWS Config
• WAF - AWS WAF.

Nem írom le részletesen az Amazon összes szolgáltatását, amely hasznos lehet az információbiztonsággal összefüggésben. A lényeg az, hogy megértsük, hogy mindegyik képes olyan eseményeket generálni, amelyeket az információbiztonság kontextusában elemezni tudunk és kell is, felhasználva erre a célra magának az Amazonnak a beépített képességeit és a külső megoldásokat, például a SIEM-et, amely vigye át a biztonsági eseményeket a megfigyelőközpontjába, és ott elemezze őket más felhőszolgáltatásokból vagy belső infrastruktúrából, peremről vagy mobileszközökről származó eseményekkel együtt.

Mindenesetre minden azokkal az adatforrásokkal kezdődik, amelyek információbiztonsági eseményeket biztosítanak Önnek. Ezek a források többek között, de nem kizárólagosan:

• CloudTrail – API-használat és felhasználói műveletek
• Megbízható tanácsadó – biztonsági ellenőrzés a legjobb gyakorlatokkal szemben
• Config - fiókok és szolgáltatásbeállítások leltár és konfigurálása
• VPC Flow Logs – kapcsolatok a virtuális interfészekhez
• IAM - azonosítási és hitelesítési szolgáltatás
• ELB hozzáférési naplók - Load Balancer
• Inspector – az alkalmazás biztonsági rései
• S3 - fájltárolás
• CloudWatch – Alkalmazástevékenység
• Az SNS egy értesítési szolgáltatás.

Noha az Amazon ilyen sokféle eseményforrást és eszközt kínál generálásukhoz, nagyon korlátozott a képessége az összegyűjtött adatok információbiztonsági összefüggésében történő elemzésére. Önállóan kell tanulmányoznia a rendelkezésre álló naplókat, keresve bennük a megfelelő kompromisszummutatókat. Az Amazon nemrégiben elindított AWS Security Hub célja a probléma megoldása azáltal, hogy felhőalapú SIEM-mé válik az AWS számára. Egyelőre azonban még csak az út elején jár, és korlátozza mind a források száma, amelyekkel dolgozik, mind pedig az Amazon architektúrája és előfizetései által meghatározott egyéb korlátozások.

Példa: Az Azure-alapú IaaS információbiztonsági figyelése

Nem szeretnék hosszas vitába bonyolódni arról, hogy a három felhőszolgáltató (Amazon, Microsoft vagy Google) közül melyik a jobb (főleg, hogy mindegyiknek megvan a maga sajátossága, és alkalmas a saját problémáinak megoldására); Koncentráljunk az információbiztonsági felügyeleti képességekre, amelyeket ezek a lejátszók nyújtanak. El kell ismerni, hogy az Amazon AWS az elsők között volt ebben a szegmensben, így információbiztonsági funkcióit tekintve a legmesszebb jutott (bár sokan elismerik, hogy ezek használata nehézkes). Ez azonban nem jelenti azt, hogy figyelmen kívül hagyjuk a Microsoft és a Google által kínált lehetőségeket.

A Microsoft termékeit mindig is „nyitottságuk” jellemezte, és az Azure-ban is hasonló a helyzet. Például, ha az AWS és a GCP mindig a „ami nem megengedett, az tilos” koncepcióból indul ki, akkor az Azure pontosan az ellenkező megközelítést alkalmazza. Például amikor virtuális hálózatot hozunk létre a felhőben és egy virtuális gépet, minden port és protokoll alapértelmezés szerint nyitva van és engedélyezett. Ezért egy kicsit több erőfeszítést kell fordítania a hozzáférés-vezérlő rendszer kezdeti beállítására a felhőben a Microsofttól. Ez pedig szigorúbb követelményeket támaszt az Azure-felhőben végzett tevékenység megfigyelése tekintetében.

Az AWS sajátossága azzal a ténnyel jár, hogy ha virtuális erőforrásait figyeli, ha azok különböző régiókban helyezkednek el, akkor nehézségekbe ütközik az események kombinálása és azok egységes elemzése, amelyek kiküszöböléséhez különféle trükkökhöz kell folyamodnia, mint pl. Hozzon létre saját kódot az AWS Lambda számára, amely az eseményeket régiók között továbbítja. Az Azure-ban nincs ilyen probléma – tevékenységnapló-mechanizmusa korlátozások nélkül nyomon követi az összes tevékenységet a teljes szervezetben. Ugyanez vonatkozik az AWS Security Hub-ra, amelyet az Amazon nemrégiben fejlesztett ki, hogy számos biztonsági funkciót egyetlen biztonsági központon belül konszolidáljon, de csak a régión belül, ami azonban nem releváns Oroszország számára. Az Azure saját biztonsági központtal rendelkezik, amelyet nem kötnek regionális korlátozások, és hozzáférést biztosít a felhőplatform összes biztonsági funkciójához. Ezenkívül a különböző helyi csapatok számára saját védelmi képességeket biztosíthat, beleértve az általuk kezelt biztonsági eseményeket. Az AWS Security Hub még mindig azon van, hogy az Azure Security Centerhez hasonlóvá váljon. De megéri hozzátenni a legyet – az Azure-ból sokat kipréselhet abból, amit korábban az AWS-ben leírtak, de ez a legkényelmesebben csak az Azure AD, Azure Monitor és Azure Security Center esetében tehető meg. Az összes többi Azure biztonsági mechanizmus, beleértve a biztonsági eseményelemzést, még nem a legkényelmesebb módon kezelhető. A problémát részben megoldja az API, amely az összes Microsoft Azure szolgáltatást átszövi, de ehhez további erőfeszítésekre lesz szükség a felhő és az SOC integrálásához, valamint képzett szakemberek jelenlétére (sőt, mint minden más, felhővel működő SIEM esetében API-k). Egyes SIEM-ek, amelyekről később lesz szó, már támogatják az Azure-t, és automatizálhatják a figyelését, de ennek is megvannak a maga nehézségei – nem mindegyik képes összegyűjteni az Azure összes naplóját.

Az Azure-beli eseménygyűjtés és -figyelés az Azure Monitor szolgáltatással érhető el, amely a Microsoft felhőben és erőforrásaiban – Git-tárolókban, tárolókban, virtuális gépekben, alkalmazásokban stb. – található adatok gyűjtésének, tárolásának és elemzésének fő eszköze. Az Azure Monitor által gyűjtött összes adat két kategóriába van osztva: valós időben gyűjtött metrikák, amelyek az Azure-felhő fő teljesítménymutatóit írják le, valamint naplók, amelyek rekordokba rendezve tartalmazzák az Azure-erőforrások és -szolgáltatások tevékenységének bizonyos aspektusait jellemző adatokat. Ezenkívül a Data Collector API használatával az Azure Monitor szolgáltatás bármely REST-forrásból gyűjthet adatokat saját megfigyelési forgatókönyvek létrehozásához.

Íme néhány biztonsági eseményforrás, amelyet az Azure kínál Önnek, és amelyekhez az Azure Portalon, CLI-n, PowerShell-en vagy REST API-n keresztül (és néhányhoz csak az Azure Monitor/Insight API-n keresztül) férhet hozzá:

• Tevékenységnaplók – ez a napló válaszol a „ki”, „mi” és „mikor” klasszikus kérdéseire a felhőalapú erőforrásokon végzett írási műveletekkel (PUT, POST, DELETE) kapcsolatban. Az olvasási hozzáféréssel (GET) kapcsolatos események nem szerepelnek ebben a naplóban, mint sok másban.
• Diagnosztikai naplók – az előfizetésben szereplő adott erőforrással végzett műveletek adatait tartalmazza.
• Azure AD jelentéskészítés – a csoport- és felhasználókezeléssel kapcsolatos felhasználói és rendszertevékenységeket egyaránt tartalmazza.
• Windows Event Log és Linux Syslog – a felhőben tárolt virtuális gépekről származó eseményeket tartalmazza.
• Metrics – telemetriát tartalmaz a felhőszolgáltatások és erőforrások teljesítményéről és állapotáról. Percenként mérve és tárolva. 30 napon belül.
• Hálózati biztonsági csoportfolyamatnaplók – a Network Watcher szolgáltatással és a hálózati szintű erőforrás-felügyelettel gyűjtött hálózati biztonsági eseményekkel kapcsolatos adatokat tartalmazzák.
• Tárolási naplók – a tárolóhelyekhez való hozzáféréssel kapcsolatos eseményeket tartalmazza.

A megfigyeléshez külső SIEM-eket vagy a beépített Azure Monitort és annak bővítményeit használhatja. Az információbiztonsági eseménykezelő rendszerekről később fogunk beszélni, de most nézzük meg, mit kínál maga az Azure az adatelemzéshez a biztonsággal összefüggésben. Az Azure Monitor minden biztonsággal kapcsolatos fő képernyője a Log Analytics biztonsági és naplózási irányítópultja (az ingyenes verzió csak egy hétig támogat korlátozott mennyiségű eseménytárolást). Ez az irányítópult 5 fő területre van felosztva, amelyek összefoglaló statisztikákat jelenítenek meg arról, hogy mi történik az Ön által használt felhőkörnyezetben:

• Biztonsági tartományok - az információbiztonsággal kapcsolatos legfontosabb kvantitatív mutatók - az incidensek száma, a feltört csomópontok száma, a javítatlan csomópontok, a hálózatbiztonsági események stb.
• Figyelemre méltó problémák – megjeleníti az aktív információbiztonsági problémák számát és fontosságát
• Észlelések – az Ön ellen alkalmazott támadások mintáit jeleníti meg
• Threat Intelligence – földrajzi információkat jelenít meg az Önt támadó külső csomópontokon
• Gyakori biztonsági lekérdezések – tipikus lekérdezések, amelyek segítségével jobban figyelemmel kísérheti információbiztonságát.

Az Azure Monitor bővítmények közé tartozik az Azure Key Vault (kriptográfiai kulcsok védelme a felhőben), a Malware Assessment (a rosszindulatú kódok elleni védelem elemzése a virtuális gépeken), az Azure Application Gateway Analytics (többek között a felhőbeli tűzfalnaplók elemzése) stb. . Ezek az eszközök az események feldolgozására vonatkozó bizonyos szabályokkal gazdagítva lehetővé teszik a felhőszolgáltatások tevékenységének különböző aspektusainak megjelenítését, beleértve a biztonságot is, valamint a működéstől való bizonyos eltérések azonosítását. De ahogy gyakran megesik, minden további funkcióhoz megfelelő fizetős előfizetésre van szükség, amely megfelelő pénzügyi befektetéseket igényel Öntől, amelyeket előre meg kell terveznie.

Az Azure számos beépített fenyegetésfigyelési képességgel rendelkezik, amelyek integrálva vannak az Azure AD-be, az Azure Monitorba és az Azure Security Centerbe. Ezek közé tartozik például a virtuális gépek interakciójának észlelése ismert rosszindulatú IP-címekkel (a Microsoft Threat Intelligence szolgáltatásaival való integráció jelenléte miatt), rosszindulatú programok észlelése a felhő infrastruktúrájában a felhőben tárolt virtuális gépektől riasztások fogadásával, jelszó kitaláló támadások ” virtuális gépek ellen, a felhasználóazonosító rendszer konfigurációjának sebezhetősége, anonimizálókból vagy fertőzött csomópontokból történő bejelentkezés, fiókszivárgás, szokatlan helyről történő bejelentkezés stb. Az Azure ma azon kevés felhőszolgáltatók egyike, amely beépített Threat Intelligence-képességeket kínál az összegyűjtött információbiztonsági események gazdagításához.

Mint fentebb említettük, a biztonsági funkcionalitás és ennek következtében az általa generált biztonsági események nem egyformán érhetők el minden felhasználó számára, hanem egy bizonyos előfizetést igényel, amely tartalmazza a szükséges funkcionalitást, amely generálja a megfelelő eseményeket az információbiztonság megfigyeléséhez. Például az előző bekezdésben ismertetett, a fiókokban lévő anomáliák figyelésére szolgáló funkciók némelyike ​​csak az Azure AD-szolgáltatás P2 prémium licencében érhető el. Enélkül, mint az AWS esetében, „manuálisan” kell elemeznie az összegyűjtött biztonsági eseményeket. Ezenkívül az Azure AD-licenc típusától függően nem minden esemény lesz elérhető elemzésre.

Az Azure Portalon kezelheti az Önt érdeklő naplók keresési lekérdezését, és beállíthat irányítópultokat a legfontosabb információbiztonsági mutatók megjelenítéséhez. Ezenkívül ott kiválaszthatja az Azure Monitor-bővítményeket, amelyek lehetővé teszik az Azure Monitor naplóinak funkcióinak bővítését, és az események mélyebb elemzését biztonsági szempontból.

Ha nem csak a naplókkal való munkavégzés képességére van szüksége, hanem átfogó biztonsági központra van szüksége az Azure felhőplatformhoz, beleértve az információbiztonsági házirend-kezelést, akkor beszélhet arról, hogy együtt kell dolgoznia az Azure Security Centerrel, amelynek legtöbb hasznos funkciója némi pénzért elérhetők, például fenyegetésészlelés, Azure-on kívüli figyelés, megfelelőségértékelés stb. (az ingyenes verzióban csak egy biztonsági értékeléshez és az azonosított problémák kiküszöbölésére vonatkozó ajánlásokhoz férhet hozzá). Egy helyen egyesíti az összes biztonsági kérdést. Valójában magasabb szintű információbiztonságról beszélhetünk, mint amit az Azure Monitor nyújt Önnek, mivel ebben az esetben a felhőgyárban gyűjtött adatok számos forrásból gazdagodnak, például Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX. , outlook .com, MSN.com, a Microsoft Digital Crimes Unit (DCU) és a Microsoft Security Response Center (MSRC), amelyekre különféle kifinomult gépi tanulási és viselkedéselemző algoritmusok helyezkednek el, amelyek végső soron javítani fogják a fenyegetések észlelésének és az azokra való reagálás hatékonyságát .

Az Azure saját SIEM-mel is rendelkezik – 2019 elején jelent meg. Ez az Azure Sentinel, amely az Azure Monitor adataira támaszkodik, és integrálható vele. külső biztonsági megoldások (például NGFW vagy WAF), amelyek listája folyamatosan bővül. Ezenkívül a Microsoft Graph Security API integrációja révén saját fenyegetésintelligencia-hírcsatornáit is csatlakoztathatja a Sentinelhez, ami gazdagítja az Azure-felhőben előforduló incidensek elemzésének képességeit. Lehet vitatkozni, hogy az Azure Sentinel az első „natív” SIEM, amely megjelent a felhőszolgáltatóktól (ugyanazt a Splunkot vagy ELK-t, amely felhőben is tárolható, például az AWS-t továbbra sem fejlesztik a hagyományos felhőszolgáltatók). Az Azure Sentinel és Security Center elnevezése SOC az Azure felhőhöz, és korlátozható rájuk (bizonyos fenntartásokkal), ha már nem rendelkezik infrastruktúrával, és az összes számítási erőforrást a felhőbe helyezte át, és ez lenne a Microsoft felhő Azure.

Mivel azonban az Azure beépített képességei (még akkor is, ha Sentinel-előfizetéssel rendelkezik) gyakran nem elegendőek az információbiztonság figyeléséhez és ennek a folyamatnak a biztonsági események más forrásaival (felhővel és belsővel) való integrálásához, van egy az összegyűjtött adatokat külső rendszerekbe kell exportálnia, amelyek tartalmazhatják a SIEM-et is. Ez mind az API-val, mind pedig speciális bővítményekkel történik, amelyek jelenleg hivatalosan csak a következő SIEM-ekhez érhetők el: Splunk (Azure Monitor-kiegészítő a Splunkhoz), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight és ELK. Egészen a közelmúltig több ilyen SIEM volt, de 1. június 2019-től a Microsoft leállította az Azure Log Integration Tool (AzLog) támogatását, amely az Azure létezésének hajnalán és a naplókkal való munka normál szabványosításának hiányában (Azure) A monitor még nem is létezett) megkönnyítette a külső SIEM integrálását a Microsoft felhőjével. Most a helyzet megváltozott, és a Microsoft az Azure Event Hub platformot ajánlja más SIEM-ek fő integrációs eszközeként. Sokan már megvalósították ezt az integrációt, de legyen óvatos – előfordulhat, hogy nem rögzítik az összes Azure-naplót, csak néhányat (nézze meg a SIEM dokumentációját).

Egy rövid Azure-betekintést befejezve szeretnék egy általános ajánlást adni ezzel a felhőszolgáltatással kapcsolatban – mielőtt bármit is mondana az Azure információbiztonsági felügyeleti funkcióiról, nagyon körültekintően konfigurálja azokat, és tesztelje, hogy a dokumentációban leírtak szerint működnek-e. ahogy a tanácsadók elmondták a Microsoftnak (és eltérően vélekedhetnek az Azure-funkciók működéséről). Ha megvan a pénzügyi forrása, akkor sok hasznos információt kisajthat az Azure-ból az információbiztonság megfigyelése szempontjából. Ha az erőforrásai korlátozottak, akkor az AWS-hez hasonlóan csak saját erejére és az Azure Monitor által biztosított nyers adatokra kell támaszkodnia. És ne feledje, hogy sok felügyeleti funkció pénzbe kerül, és jobb, ha előre megismeri az árpolitikát. Például ingyenesen tárolhat 31 napnyi adatot ügyfelenként legfeljebb 5 GB-ig – ezen értékek túllépése további pénzt igényel (körülbelül 2 USD+ minden további GB tárolásáért az ügyféltől és 0,1 USD 1 GB tárolása minden további hónapban). Az alkalmazások telemetriájával és mérőszámaival végzett munka további forrásokat is igényelhet, valamint a riasztásokkal és értesítésekkel való munka (bizonyos korlát ingyenesen elérhető, ami nem biztos, hogy elég az Ön igényeinek).

Példa: A Google Cloud Platformon alapuló információbiztonsági figyelés az IaaS-ben

A Google Cloud Platform fiatalnak tűnik az AWS-hez és az Azure-hoz képest, de ez részben jó. Ellentétben az AWS-szel, amely fokozatosan növelte képességeit, beleértve a biztonságiakat is, és gondjai vannak a központosítással; A GCP az Azure-hoz hasonlóan sokkal jobban kezelhető központilag, ami csökkenti a hibákat és a megvalósítási időt a vállalaton belül. Biztonsági szempontból a GCP furcsa módon az AWS és az Azure között van. Egyetlen rendezvény regisztrációja is van az egész szervezetre vonatkozóan, de az hiányos. Egyes funkciók még béta módban vannak, de fokozatosan meg kell szüntetni ezt a hiányosságot, és a GCP kiforrottabb platformmá válik az információbiztonság felügyelete szempontjából.

Az események naplózásának fő eszköze a GCP-ben a Stackdriver Logging (hasonlóan az Azure Monitorhoz), amely lehetővé teszi az események gyűjtését a teljes felhőinfrastruktúrán (valamint az AWS-ből). A GCP biztonsági szempontból minden szervezetnek, projektnek vagy mappának négy naplója van:

• Adminisztrációs tevékenység – tartalmazza az adminisztrátori hozzáféréssel kapcsolatos összes eseményt, például virtuális gép létrehozását, hozzáférési jogok módosítását stb. Ez a napló az Ön kívánságától függetlenül mindig írásra kerül, és 400 napig tárolja az adatait.
• Adathozzáférés – tartalmazza az összes olyan eseményt, amely a felhőfelhasználók adatkezelésével kapcsolatos (létrehozás, módosítás, olvasás stb.). Alapértelmezés szerint ez a napló nem íródik, mivel a kötete nagyon gyorsan megduzzad. Emiatt az eltarthatósága mindössze 30 nap. Ráadásul ebben a magazinban nincs minden megírva. Például az összes felhasználó számára nyilvánosan elérhető vagy a GCP-be való bejelentkezés nélkül elérhető erőforrásokhoz kapcsolódó események nem íródnak rá.
• Rendszeresemény – olyan rendszereseményeket tartalmaz, amelyek nem kapcsolódnak a felhasználókhoz, vagy a felhő-erőforrások konfigurációját módosító rendszergazda műveleteihez. Mindig megírják és 400 napig tárolják.
• Az Access Transparency egyedülálló példa a naplóra, amely rögzíti azon Google-alkalmazottak összes tevékenységét (de még nem minden GCP-szolgáltatás esetében), akik munkaköri feladataik részeként hozzáférnek az Ön infrastruktúrájához. Ezt a naplót 400 napig tároljuk, és nem érhető el minden GCP-ügyfél számára, de csak akkor, ha számos feltétel teljesül (arany vagy platina szintű támogatás, vagy 4 bizonyos típusú szerepkör jelenléte a vállalati támogatás részeként). Hasonló funkció elérhető például az Office 365 - Lockboxban is.

Naplópélda: 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"
}

Ezekhez a naplókhoz többféle módon is hozzá lehet férni (nagyjából ugyanúgy, mint korábban tárgyaltuk az Azure-t és az AWS-t) – a Log Viewer felületen, az API-n keresztül, a Google Cloud SDK-n keresztül, vagy a projekt tevékenységi oldalán keresztül, amelyhez Ön érdeklődnek az események iránt. Ugyanígy exportálhatók külső megoldásokba további elemzés céljából. Ez utóbbi a naplók BigQuery vagy Cloud Pub/Sub tárhelyre történő exportálásával történik.

A Stackdriver Logging mellett a GCP platform Stackdriver Monitoring funkciót is kínál, amely lehetővé teszi a felhőszolgáltatások és alkalmazások kulcsfontosságú mérőszámainak (teljesítmény, MTBF, általános állapot stb.) figyelését. A feldolgozott és megjelenített adatok megkönnyíthetik a felhő-infrastruktúra problémáinak megtalálását, beleértve a biztonságot is. De meg kell jegyezni, hogy ez a funkció nem lesz túl gazdag az információbiztonság kontextusában, mivel ma a GCP nem rendelkezik ugyanannak az AWS GuardDutynak analógjával, és nem tudja azonosítani a rosszakat az összes regisztrált esemény között (a Google kifejlesztette az Event Threat Detection, de a béta még fejlesztés alatt áll, és még túl korai beszélni a hasznosságáról). A Stackdriver Monitoring rendszerként használható az anomáliák észlelésére, amelyeket azután megvizsgálnak, hogy megtalálják az előfordulásuk okát. De mivel a piacon hiányzik a GCP információbiztonság területén képzett személyzet, ez a feladat jelenleg nehéznek tűnik.

Érdemes felsorolni néhány olyan információbiztonsági modult is, amelyek a GCP-felhőben használhatók, és amelyek hasonlóak az AWS által kínálthoz:

• A Cloud Security Command Center az AWS Security Hub és az Azure Security Center analógja.
• Cloud DLP – A felhőben tárolt adatok automatikus felderítése és szerkesztése (például maszkolása) több mint 90 előre meghatározott besorolási házirend segítségével.
• A Cloud Scanner az App Engine, a Compute Engine és a Google Kubernetes ismert sebezhetőségeinek (XSS, Flash Injection, nem javított könyvtárak stb.) keresője.
• Cloud IAM – Az összes GCP-erőforráshoz való hozzáférés szabályozása.
• Cloud Identity – GCP-felhasználói, eszköz- és alkalmazásfiókok kezelése egyetlen konzolról.
• Cloud HSM - kriptográfiai kulcsok védelme.
• Cloud Key Management Service – kriptográfiai kulcsok kezelése a GCP-ben.
• VPC-szolgáltatásvezérlés – Hozzon létre egy biztonságos kerületet a GCP-erőforrások körül, hogy megvédje őket a szivárgásoktól.
• Titan biztonsági kulcs – adathalászat elleni védelem.

E modulok közül sok olyan biztonsági eseményeket generál, amelyeket el lehet küldeni a BigQuery tárhelyre elemzés céljából, vagy exportálni lehet más rendszerekbe, beleértve a SIEM-et is. Ahogy fentebb említettük, a GCP egy aktívan fejlődő platform, és a Google jelenleg számos új információbiztonsági modult fejleszt platformjához. Ezek közé tartozik az Event Threat Detection (most béta verzióban érhető el), amely átvizsgálja a Stackdriver naplóit, és keresi a jogosulatlan tevékenységek nyomait (hasonlóan az AWS-ben lévő GuardDuty-hoz), vagy a Policy Intelligence (alfában elérhető), amely lehetővé teszi intelligens házirendek kidolgozását hozzáférés a GCP-erőforrásokhoz.

Rövid áttekintést készítettem a népszerű felhőplatformok beépített monitorozási lehetőségeiről. De vannak olyan szakemberei, akik képesek „nyers” IaaS szolgáltatói naplókkal dolgozni (nem mindenki kész megvenni az AWS, az Azure vagy a Google fejlett képességeit)? Emellett sokan ismerik a „bízz, de ellenőrizd” mondást, amely minden eddiginél igazabb a biztonság területén. Mennyire bízik a felhőszolgáltató beépített képességeiben, amelyek információbiztonsági eseményeket küldenek Önnek? Mennyire foglalkoznak egyáltalán az információbiztonsággal?

Néha érdemes megnézni az overlay felhő-infrastruktúra-felügyeleti megoldásokat, amelyek kiegészíthetik a beépített felhőbiztonságot, néha pedig ezek a megoldások az egyetlen lehetőség arra, hogy betekintést nyerjünk a felhőben tárolt adatok és alkalmazások biztonságába. Ráadásul egyszerűen kényelmesebbek, mivel minden feladatot magukra vállalnak a különböző felhőszolgáltatók különböző felhőszolgáltatásai által generált szükséges naplók elemzésével kapcsolatban. Ilyen átfedési megoldás például a Cisco Stealthwatch Cloud, amely egyetlen feladatra összpontosít - a felhőkörnyezetek információbiztonsági anomáliáinak figyelésére, beleértve nemcsak az Amazon AWS-t, a Microsoft Azure-t és a Google Cloud Platformot, hanem a privát felhőket is.

Példa: Információbiztonsági megfigyelés Stealthwatch Cloud használatával

Az AWS rugalmas számítási platformot biztosít, de ez a rugalmasság megkönnyíti a vállalatok számára a biztonsági problémákhoz vezető hibák elkövetését. A megosztott információbiztonsági modell pedig ehhez csak hozzájárul. Felhőben futó szoftverek ismeretlen sebezhetőségekkel (az ismertek ellen például az AWS Inspector vagy a GCP Cloud Scanner segítségével lehet küzdeni), gyenge jelszavakkal, hibás konfigurációkkal, bennfentesekkel stb. Mindez pedig a felhő-erőforrások viselkedésében is megmutatkozik, amit a Cisco Stealthwatch Cloud figyelhet meg, amely egy információbiztonsági megfigyelő és támadásjelző rendszer. nyilvános és privát felhők.

A Cisco Stealthwatch Cloud egyik legfontosabb jellemzője az entitások modellezése. Ezzel szoftvermodellt (vagyis közel valós idejű szimulációt) hozhat létre minden felhő-erőforrásról (nem számít, hogy AWS, Azure, GCP vagy valami más). Ezek lehetnek kiszolgálók és felhasználók, valamint a felhőkörnyezetre jellemző erőforrástípusok, például biztonsági csoportok és automatikus skálázási csoportok. Ezek a modellek a felhőszolgáltatások által biztosított strukturált adatfolyamokat használják bemenetként. Például az AWS esetében ezek a következők: VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda és AWS IAM. Az entitásmodellezés automatikusan felfedezi bármely erőforrás szerepét és viselkedését (lehet beszélni az összes felhőtevékenység profilozásáról). Ezek a szerepkörök magukban foglalják az Android vagy Apple mobileszközt, a Citrix PVS-kiszolgálót, az RDP-kiszolgálót, a levelezési átjárót, a VoIP-klienst, a terminálkiszolgálót, a tartományvezérlőt stb. Ezután folyamatosan figyeli viselkedésüket, hogy megállapítsa, mikor történik kockázatos vagy biztonságot veszélyeztető viselkedés. Beazonosíthatja a jelszókitalálást, a DDoS-támadásokat, az adatszivárgást, az illegális távoli hozzáférést, a rosszindulatú kódtevékenységet, a sebezhetőségek vizsgálatát és egyéb fenyegetéseket. Például így néz ki egy távoli hozzáférési kísérlet észlelése egy szervezete számára atipikus országból (Dél-Korea) egy Kubernetes-fürthöz SSH-n keresztül:

És így néz ki az állítólagos információszivárgás a Postgress adatbázisból egy olyan országba, amellyel korábban nem találkoztunk interakcióval:

Végül így néz ki túl sok sikertelen SSH-kísérlet Kínából és Indonéziából egy külső távoli eszközről:

Vagy tegyük fel, hogy a VPC-ben lévő kiszolgálópéldány a házirend szerint soha nem lehet távoli bejelentkezési cél. Tegyük fel továbbá, hogy ez a számítógép távoli bejelentkezést tapasztalt a tűzfalszabályok házirendjének hibás módosítása miatt. Az Entitásmodellezés funkció szinte valós időben észleli és jelenti ezt a tevékenységet („Szokatlan távoli hozzáférés”), és az adott AWS CloudTrail, Azure Monitor vagy GCP Stackdriver Logging API-hívásra mutat (beleértve a felhasználónevet, a dátumot és az időt, többek között ). Ezután ezeket az információkat el lehet küldeni a SIEM-nek elemzés céljából.

Hasonló képességek valósulnak meg a Cisco Stealthwatch Cloud által támogatott bármely felhőkörnyezetben:

Az entitásmodellezés a biztonsági automatizálás egyedülálló formája, amely feltárhat egy korábban ismeretlen problémát az emberekkel, folyamatokkal vagy technológiával kapcsolatban. Lehetővé teszi például többek között az olyan biztonsági problémák észlelését, mint például:

• Valaki felfedezett egy hátsó ajtót az általunk használt szoftverben?
• Van harmadik féltől származó szoftver vagy eszköz a felhőnkben?
• Visszaél a jogosultságokkal a jogosult felhasználó?
• Volt olyan konfigurációs hiba, amely lehetővé tette a távoli hozzáférést vagy az erőforrások egyéb nem kívánt felhasználását?
• Adatszivárgás van a szervereinkről?
• Megpróbált valaki csatlakozni hozzánk egy atipikus földrajzi helyről?
• A felhőnk rosszindulatú kóddal fertőzött?

Az észlelt információbiztonsági esemény megfelelő jegy formájában elküldhető a Slacknek, a Cisco Sparknak, a PagerDuty incidenskezelő rendszernek, valamint elküldhető különböző SIEM-eknek, köztük a Splunknak vagy az ELK-nak. Összefoglalva azt mondhatjuk, hogy ha cége többfelhős stratégiát alkalmaz, és nem korlátozódik egyetlen felhőszolgáltatóra, a fent leírt információbiztonsági felügyeleti képességekre, akkor a Cisco Stealthwatch Cloud használata jó lehetőség az egységes felügyeleti készlet megszerzésére. képességek a vezető felhőszolgáltatók – Amazon, Microsoft és Google – számára. A legérdekesebb az, hogy ha összehasonlítja a Stealthwatch Cloud árait az AWS-ben, Azure-ban vagy a GCP-ben az információbiztonsági figyeléshez szükséges fejlett licencekkel, akkor kiderülhet, hogy a Cisco megoldás még az Amazon, a Microsoft beépített képességeinél is olcsóbb lesz. és a Google megoldásai. Paradox, de igaz. És minél több felhőt és azok képességeit használja, annál nyilvánvalóbb lesz a konszolidált megoldás előnye.

Ezenkívül a Stealthwatch Cloud felügyelheti a szervezetében telepített privát felhőket, például a Kubernetes-tárolók alapján vagy a hálózati eszközökben (akár hazai gyártású), AD-adatokban vagy DNS-kiszolgálókban való tükrözés révén kapott Netflow-folyamok vagy hálózati forgalom figyelésével. Mindezeket az adatokat a Cisco Talos, a világ legnagyobb kiberbiztonsági fenyegetések kutatóinak nem kormányzati csoportja által gyűjtött Threat Intelligence információkkal gazdagítják.

Ez lehetővé teszi, hogy egységes felügyeleti rendszert valósítson meg mind a nyilvános, mind a hibrid felhők számára, amelyeket vállalata használhat. Az összegyűjtött információk ezután elemezhetők a Stealthwatch Cloud beépített képességeivel, vagy elküldhetők a SIEM-nek (a Splunk, az ELK, a SumoLogic és számos más alapértelmezés szerint támogatott).

Ezzel befejezzük a cikk első részét, amelyben áttekintettem az IaaS/PaaS platformok információbiztonságának figyelésére szolgáló beépített és külső eszközöket, amelyek lehetővé teszik a felhőkörnyezetekben előforduló incidensek gyors észlelését és reagálását. vállalkozásunk választotta. A második részben folytatjuk a témát, és megvizsgáljuk a SaaS platformok figyelésének lehetőségeit a Salesforce és a Dropbox példáján keresztül, valamint megpróbálunk mindent összefoglalni és összerakni egy egységes információbiztonsági megfigyelő rendszer létrehozásával a különböző felhőszolgáltatók számára.

Forrás: will.com