Felhőbiztonsági monitorozás

Az adatok és alkalmazások felhőbe való áttelepítése új kihívás elé állítja a vállalati SOC-okat, amelyek nem mindig készülnek fel mások infrastruktúrájának monitorozására. A Netoskpe adatai szerint egy átlagos vállalat (valószínűleg 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!!! 175 ezek közül HR-szolgáltatásokkal, 170 a marketinggel, 110 pedig a kommunikációval és 76 a pénzügyekkel és CRM-mel kapcsolatos. A Cisco esetében „csak” 700 külső felhőszolgáltatást használnak. Ezért kicsit zavarba ejt ezek a számok. De mindenesetre a probléma nem magukban a számokban rejlik, hanem abban, hogy a felhők fokozatosan egyre több cég által kezdtek el alkalmazásra kerülni, amelyek szeretnék ugyanazokat a monitorozási lehetőségeket biztosítani a felhőinfrastruktúrájukban, mint a saját hálózatukban. És ez a tendencia növekszik — a az amerikai számvevőszék adatai szerint 2023-ra az Egyesült Államokban 1200 adatközpontot kívánnak bezárni (6250 már bezárult). De a felhőre való áttérés nem csupán annyit jelent, hogy „akkor most áthelyezzük a szervereinket egy külső szolgáltatóhoz”. Új IT-architektúra, új szoftver, új folyamatok, új korlátok... Mindez lényeges változásokat hoz a nemcsak az IT, hanem az információbiztonság működésébe is. És ha a felhőbiztonság biztosításában a szolgáltatók valahogy megtalálták a módját (szerencsére rengeteg ajánlás áll rendelkezésre), akkor a felhőmonitorozás, különösen a SaaS-platformokon, jelentős nehézségeket hordoz, amelyről most beszélni fogunk.

Tegyük fel, hogy a vállalata áthelyezte az infrastruktúrájának egy részét a felhőbe... Állj. Nem így. Ha az infrastruktúra már átkerült, és csak most kezd el gondolkodni azon, hogy hogyan fogja azt megfigyelni, akkor már veszítettél. Ha nem az Amazon, a Google vagy a Microsoft (és ezt is fenntartásokkal), akkor valószínűleg nem lesz sok lehetőséged az adataid és alkalmazásaid monitorozására. Jó, ha adnak lehetőséget a naplók kezelésére. Néha a biztonsági események adatai elérhetők lesznek, de te nem fogsz hozzáférni ezekhez. Például az Office 365. Ha a legolcsóbb E1 licenccel rendelkezel, akkor a biztonsági események számodra teljesen elérhetetlenek. E3 licenc birtokában az adatok csak 90 napig tárolódnak, és csak E5 licenc esetén elérhetők az eszköznaplók egy évig (itt is vannak saját nüanszok, amelyek a Microsoft támogatásának keresleti funkcióival kapcsolatosak). Érdekesség, hogy az E3 licenc sokkal gyengébb a megfigyelési funkciók terén, mint a vállalati Exchange. Ugyanazt a szintet elérni E5 licencre vagy az Advanced Compliance további licencére lesz szükséges, amelyek plusz költségeket igényelhetnek, amelyeket nem számoltak bele a felhőinfrastruktúrára való áttérés pénzügyi modelljébe. És ez csak egy példa a felhőbiztonság monitorozási kérdéseinek alábecsülésére. Ebben a cikkben, a teljesség igénye nélkül, szeretném felhívni a figyelmet néhány olyan nüanszra, amelyet figyelembe kell venni a felhőszolgáltató kiválasztásakor a biztonság szempontjából. A cikk végén egy ellenőrzőlistát is megadok, amelyet érdemes elvégezni, mielőtt azt gondolnád, hogy a felhőbiztonsági monitorozás kérdése megoldódott.

Több tipikus problémát lehet kiemelni, amelyek felhőalapú környezetekben incidensekhez vezetnek, amelyekre a biztonsági szolgáltatások nem reagálnak, vagy egyáltalán nem látják őket:

• A biztonsági naplók nem léteznek. Ez egy elég elterjedt helyzet, különösen a felhőmegoldások piacon kezdők körében. De azonnal nem érdemes leckét vonni belőlük. A kisebb szereplők, különösen a hazaiak, érzékenyebbek az ügyfél igényeire, és képesek gyorsan megvalósítani valamilyen igényelt funkciót, változtatva a jóváhagyott ütemtervüket a termékeikre. Igen, ez nem fogja helyettesíteni az Amazon GuardDuty-t vagy a Bitrix „Proaktív Védelem” modulját, de mégis valami.
• A biztonsági csapat nem tudja, hol tárolják a naplókat, vagy nincs hozzáférése azokhoz. Itt el kell kezdeni a tárgyalásokat a felhőszolgáltatóval — lehet, hogy megadja az információt, ha fontosnak tartja az ügyfelet. De összességében nem túl jól van, ha a naplókhoz való hozzáférés „különleges döntés” alapján történik.
• Előfordulhat, hogy a felhőszolgáltató rendelkezik naplókkal, de ezek korlátozott nyomonkövetést és eseménynaplózást biztosítanak, amelyek nem elegendőek minden incidens észlelésére. Például csak a weboldalon történő változásokról vagy a felhasználói hitelesítési kísérletekről adhatnak információt, míg más események, például a hálózati forgalom, nem kerülnek kiadásra, ami elrejti a betörési kísérletek jellemző eseményeit, amelyek a felhő infrastruktúrája ellen irányulnak.
• A naplók rendelkezésre állnak, de a hozzáférésük automatizálása nehézkes, így a megfigyelést nem folyamatosan, hanem ütemezett módon végzik. Ha a naplók automatikus betöltése sem lehetséges, akkor a naplók például Excel formátumban (ami számos hazai felhőmegoldások szolgáltatójánál elérhető) való exportálása nemcsak időigényes, hanem a vállalati biztonsági szolgálat részéről is elriasztó lehet.
• Nincs a naplók megfigyelése. Ez talán a legkevésbé érthető oka a biztonsági incidensek előfordulásának felhőalapú környezetekben. Úgy tűnik, hogy vannak naplók, és a hozzáférés automatizálása is lehetséges, mégsem történik meg. Miért?

A felhő megosztott biztonságának koncepciója

A felhőbe való áttérés mindig egyensúly keresése a vágy között, hogy megőrizzük az irányítást az infrastruktúra felett, és átadjuk azt a felhőszolgáltatónak, aki szakosodott annak fenntartására. A felhőalapú környezetek biztonságának terén is keresni kell ezt az egyensúlyt. Különösen, hogy a felhőszolgáltatások nyújtásának használt modellje (IaaS, PaaS, SaaS) folyamatosan változtatni fog ezen az egyensúlyon. Bármilyen helyzetben emlékezni kell arra, hogy a mai napon minden felhőszolgáltató követi az úgynevezett megosztott felelősségi és megosztott informatikai biztonsági modellt. A felhőért a felhőszolgáltató, míg az adatok, alkalmazások, virtuális gépek és egyéb erőforrások felhőbe helyezéséért a kliens felelős. Óvatlan lenne azt várni, hogy a felhőbe lépve minden felelősséget áthárítunk a szolgáltatóra. De az is ésszerűtlen, hogy a felhőbe való áttéréskor teljes egészében magunkra vállaljuk a biztonságot. Meg kell találni az egyensúlyt, amely számos tényezőtől függ: – a kockázatkezelési stratégiától, a fenyegetési modelltől, a felhőszolgáltató által biztosított védelmi mechanizmusoktól, a jogszabályoktól stb.

Például a felhőben tárolt adatok klasszifikálása mindig az ügyfél felelőssége. A felhőszolgáltató vagy külső szolgáltató csak abban tud segíteni, hogy olyan eszközöket biztosítson, amelyek segítenek az adatok címkézésében a felhőben, a jogsértések azonosításában, a jogellenes adatok törlésében vagy azok eltakarásában különböző módszerekkel. Másrészt a fizikai biztonság mindig a felhőszolgáltató felelőssége, amelyet nem oszthat meg az ügyfelekkel. Azt, ami az adatok és a fizikai infrastruktúra között található, a cikk tárgyalja. Például a felhő elérhetősége a szolgáltató felelőssége, míg a MSZÉ szabályok beállítása vagy a titkosítás engedélyezése már az ügyfél felelőssége. Ebben a cikkben megpróbáljuk megnézni, hogy milyen kibervédelmi megfigyelő mechanizmusokat kínálnak ma a népszerű felhőszolgáltatók Oroszországban, milyen sajátosságokkal rendelkeznek, és mikor érdemes külső megoldások (például a Cisco E-mail Security) felé fordulni, amelyek javítják a felhő kibervédelmi lehetőségeit. Számos esetben, különösen a multi-felhő stratégia követésénél, nem lesz más választása, mint használni a kibervédelem megfigyelésére szolgáló külső megoldásokat több felhő környezetben (például a Cisco CloudLock vagy a Cisco Stealthwatch Cloud). Néhány esetben pedig rájön, hogy a választott (vagy Önnek ajánlott) felhőszolgáltató egyáltalán nem kínál lehetőségeket a kibervédelem megfigyelésére. Ez kellemetlen, de mégis hasznos, mert lehetővé teszi a kockázati szint megfelelő értékelését a felhővel való együttműködés során.

A felhőbiztonsági megfigyelés élete

A használt felhők védelmének megfigyelésére három lehetőség áll rendelkezésére:

• bízzon a felhőszolgáltató által biztosított eszközökben,
• használjon harmadik fél megoldásait, amelyek a használt IaaS, PaaS vagy SaaS platformok megfigyelésére szolgálnak,
• építse fel saját felhőmegfigyelő infrastruktúráját (csak IaaS/PaaS platformokhoz).

Nézzük meg, milyen jellemzői vannak ezeknek a lehetőségeknek. De előbb meg kell értenünk a fő sémát, amelyet a felhőplatformok megfigyelésére fognak használni. Hat alapvető összetevőt emelnék ki a felhőbeli IT biztonsági megfigyelés folyamatában:

• Infrastruktúra előkészítése. A szükséges alkalmazások és infrastruktúra meghatározása az IT biztonság szempontjából fontos események gyűjtéséhez.
• Gyűjtés. Ezen a lépésen a biztonsági események különböző forrásokból aggregálódnak, hogy később feldolgozásra, tárolásra és elemzésre kerüljenek.
• Feldolgozás. Ezen a lépésen az adatok átalakulnak és gazdagodnak a későbbi elemzés megkönnyítése érdekében.
• Tárolás. Ez az összetevő felelős az összegyűjtött és feldolgozott, valamint a 'nyers' adatok rövid távú és hosszú távú tárolásáért.
• Elemzés. Ezen a lépésen lehetősége van észlelni az incidenseket és reagálni rájuk automatikus vagy manuális módon.
• Jelentés. Ez a lépés segít létrehozni a kulcsfontosságú mutatókat az érdekelt felek (vezetőség, auditorok, felhőszolgáltató, ügyfelek stb.) számára, amelyek segítenek nekünk döntéseket hozni, például szolgáltatóváltás vagy az IT biztonság fokozása.

Ezeknek az összetevőknek a megértése lehetővé teszi, hogy előre meghatározza, mit kérhet a szolgáltatójától, és mit kell magának vagy külső tanácsadók bevonásával megtennie.

Beépített felhőszolgáltatások lehetőségei

Már korábban írtam, hogy sok felhőszolgáltatás ma már nem biztosít semmiféle lehetőséget a kiberbiztonsági monitoringra. Általában véve a kiberbiztonság kérdésére nem fordítanak nagy figyelmet. Például az egyik népszerű orosz szolgáltatás, amely az állami szervek felé történő jelentések internetes benyújtásával foglalkozik (szándékosan nem említem a nevét). A szolgáltatás biztonsággal kapcsolatos szakasza teljes mértékben a tanúsított kriptográfiai eszközök alkalmazására összpontosít. Egy másik hazai felhőszolgáltatás, amely elektronikus dokumentumkezelésre specializálódott, sokkal részletesebb kiberbiztonsági szakaszt tartalmaz. Itt szó esik a nyílt kulcsú tanúsítványokról, a tanúsított kriptográfiáról, a websebezhetőségek megszüntetéséről, a DDoS támadások elleni védelemről, a MSE alkalmazásáról, a biztonsági mentésről és még a rendszeres kiberbiztonsági auditokról is. De a monitoringról egy szó sem esik, ahogyan arról sem, hogy a szolgáltató ügyfelei hozzáférést kaphatnának a kiberbiztonsággal kapcsolatos eseményekhez.

Egyáltalán, hogy a felhőszolgáltató hogyan írja le a weboldalán és a dokumentációjában a kiberbiztonsággal kapcsolatos kérdéseket, azt meg lehet érteni, hogy mennyire komolyan veszi ezt a témát. Például, ha elolvassuk a "Moj irodá" termékek útmutatóit, akkor ott egy szó sem esik a biztonságról, míg a "Moj irodá. KS3" nevű, illetéktelen hozzáférés elleni védelemre szánt termék dokumentációjában a 17-es számú FSTEC rendelet pontjainak szokásos felsorolása található, amelyet a "Moj irodá.KS3" végrehajt, de nem írja le, hogyan valósítja meg, és ami a legfontosabb, hogyan integrálhatók ezek a mechanizmusok a vállalati kiberbiztonsággal. Lehetséges, hogy ilyen dokumentáció létezik, de a "Moj irodá" weboldalán nem találtam meg. Talán egyszerűen nincs hozzáférésem ehhez a titkos információhoz?

A Bitrix esetében a helyzet sokkal jobb. A dokumentációban le vannak írva az eseménynapló formátumai, és ami érdekes, a behatolási napló, amely olyan eseményeket tartalmaz, amelyek potenciális fenyegetésekkel kapcsolatosak a felhőplatform számára. Innen kinyerheti az IP-címet, a felhasználó vagy vendég nevét, az esemény forrását, az időt, a felhasználói ügynököt, az esemény típusát stb. Igaz, hogy ezekkel az eseményekkel vagy a felhőirányítóból dolgozhat, vagy az adatokat MS Excel formátumban exportálhatja. Jelenleg nehézkes a Bitrix naplók automatizálása, és sajnos a munka egy részét manuálisan kell elvégeznie (az jelentés exportálása és betöltése a SIEM rendszerébe). De ha visszagondolunk arra, hogy még viszonylag nemrég ilyen lehetőség sem volt, akkor ez jelentős előrelépés. Ezen kívül szeretném megjegyezni, hogy sok külföldi felhőszolgáltató is hasonló funkciókat kínál „kezdőknek” – vagy nézze meg a naplókat a felügyeleti panelen, vagy töltse le az adatokat a saját gépére (bár a legtöbb esetben az adatokat .csv formátumban, nem pedig Excelben exportálják).

Ha nem veszik figyelembe a naplók hiányát, a felhőszolgáltatók általában három lehetőséget kínálnak a biztonsági események monitorozására – irányítópultra, adatexportra és API-hozzáférésre. Az első viszonylag sok problémát megold, de ez nem teljesen igaz – ha több naplóval találkozunk, akkor át kell váltani a kedves képernyők között, elveszítve a nagyobb képet. Ezenkívül a felhőszolgáltatók valószínűleg nem kínálnak lehetőséget a biztonsági események korrelálására vagy az ilyen események biztonsági szempontból történő elemzésére (rendszerint nyers adatokkal dolgoznak, amelyeket neked kell önállóan értelmezni). Vannak kivételek, ezekről később beszélünk. Végül érdemes megkérdezni, hogy milyen eseményeket rögzít a felhőszolgáltatód, milyen formátumban, és mennyire illeszkednek a te IT-biztonsági monitorozási folyamatodhoz? Például a felhasználók és vendégek azonosítása és hitelesítése. A Bitrix segítségével ezekből az eseményadatokból rögzíthető az esemény dátuma és ideje, a felhasználó vagy vendég neve (ha van „Web-analitika” modul), a hozzáférési objektum, valamint más, a webhelyekre jellemző elemek. De a vállalati IT-biztonsági szolgáltatások számára szükséges lehet az információ arról, hogy a felhasználó megbízható eszközről lépett-e be a felhőbe (például vállalati hálózaton ezt a Cisco ISE valósítja meg). De egy olyan egyszerű feladat, mint a geo-IP funkció, amely segít meghatározni, hogy a felhasználó felhőszolgáltatásának fiókját nem lopták-e el? És még ha a felhőszolgáltató ezt biztosítja számodra, az még mindig kevés. A Cisco CloudLock nemcsak a geolokációt elemzi, hanem gépi tanulást is alkalmaz, és történeti adatokat elemez minden felhasználóra vonatkozóan, figyelemmel kísérve a különböző anomáliákat az azonosítási és hitelesítési kísérletek során. Hasonló funkcióval csak az MS Azure rendelkezik (a megfelelő előfizetés birtokában).

Van még egy nehézség — mivel sok felhőszolgáltató számára az IT-biztonság monitorozása még új téma, amellyel éppen csak most kezdik foglalkozni, folyamatosan változtatnak a megoldásaikon. Ma van egy API verziójuk, holnap egy másik, holnapután egy harmadik. Erre is fel kell készülni. Ugyanez vonatkozik a funkcionalitásra is, amely szintén változhat, ezt figyelembe kell venni a monitorozó rendszerünkben. Például az Amazon kezdetben külön monitorozó szolgáltatásokat kínált az események figyelésére a felhőben — AWS CloudTrail és AWS CloudWatch. Aztán megjelent egy külön IT-biztonsági eseményfigyelő szolgáltatás is — AWS GuardDuty. Néhány idő elteltével az Amazon elindította az Amazon Security Hub új kezelőrendszerét, amely tartalmazza az GuardDuty, az Amazon Inspector, az Amazon Macie és más forrásokból származó adatok elemzését. Egy másik példa a Azure logok SIEM-be integrálását végző eszköz — AzLog. Ezt sok SIEM-szolgáltató aktívan használta, amíg 2018-ban a Microsoft be nem jelentette a fejlesztés és támogatás megszüntetését, amely sok ügyfelet nehéz helyzetbe hozott (hogy ezt hogyan oldották meg, arról később beszélünk).

Ezért figyelmesen kövesse nyomon az összes monitorozási funkciót, amelyet a felhőszolgáltatójától kap. Vagy bízza egy külső megoldásszállítóra, amely közvetítőként fog működni a SOC-ja és a monitorozni kívánt felhő között. Igen, ez drágább lesz (bár nem mindig), de így az összes felelősséget más vállára rakja. Vagy talán nem az összeset?.. Emlékezzünk a megosztott biztonság koncepciójára, és értsük meg, hogy semmit sem tudunk teljesen áthárítani — magunknak kell kiderítenünk, hogyan biztosítják a különböző felhőszolgáltatók az adataink, alkalmazásaink, virtuális gépeink és egyéb felhőben elhelyezett erőforrásaink IT-biztonsági monitorozását. Ezzel kezdjük, amit az Amazon ezen a területen kínál.

Példa: IT-biztonsági monitorozás IaaS-ban AWS alapú

Igen, értem, hogy az Amazon nem a legjobb példa, mivel ez egy amerikai szolgáltatás, és blokkolhatják az extremizmus elleni harc és a Oroszország területén tiltottnak számító információk terjesztése miatt. De ebben a publikációban szeretném csak megmutatni, mennyire eltérőek a különböző felhőplatformok az IT-biztonság monitoring lehetőségeiben, és mire érdemes figyelni, amikor a kulcsfontosságú folyamatokat a felhőbe helyezzük biztonsági szempontból. Nos, ha valamelyik orosz felhőmegoldás-fejlesztő hasznos dolgot tanul ebből, az már tökéletes lenne.

Először is fontos megemlíteni, hogy az Amazon nem egy megközelíthetetlen vár. Az ügyfeleivel rendszeresen történnek különféle incidensek. Például a Deep Root Analytics esetében 198 millió szavazónak ellopták a nevét, címét, születési dátumát és telefonszámát. Az izraeli Nice Systems cégtől 14 millió Verizon-előfizető adatait lopták el. A beépített AWS lehetőségek segítségével azonban széles spektrumú incidenseket észlelhet.

• infrastruktúrára gyakorolt hatás (DDoS)
• csomópont kompromittálása (parancsok befecskendezése)
• fiók kompromittálás és jogosulatlan hozzáférés
• helytelen konfiguráció és sebezhetőségek
• védtelen interfészek és API-k.

Ez az eltérés abból adódik, hogy az ügyfélnek kell felelősséget vállalnia az adatok biztonságáért, ahogyan azt korábban világossá tettük. Ha nem gondoskodik védelmi mechanizmusok aktiválásáról és monitorozó eszközökről, akkor az incidensről csak a médiából vagy a saját ügyfeleitől értesül.

Incidensek észlelésére széles körű különböző monitoring szolgáltatásokat használhatunk, amelyeket az Amazon fejlesztett ki (bár ezek gyakran kiegészülnek külső eszközökkel, például az osquery-vel). Az AWS-ben minden felhasználói tevékenységet nyomon követnek, függetlenül attól, hogy hogyan történik — a kezelő konzolon, parancssorban, SDK-n vagy más AWS szolgáltatásokon keresztül. Minden AWS-fiókhoz tartozó tevékenységi adat (felhasználónév, tevékenység, szolgáltatás, aktivitási paraméterek és eredmények) és az API használat elérhető az AWS CloudTrail szolgáltatáson keresztül. Ezeket az eseményeket (például AWS IAM konzolba való belépés) megtekintheti a CloudTrail konzolján, elemezheti az Amazon Athena segítségével, vagy átadhatja külső megoldásoknak, például a Splunknak, AlienVaultnak stb. Maguk az AWS CloudTrail naplók az AWS S3 tárolójába kerülnek.

Két másik AWS szolgáltatás számos fontos monitoring lehetőséget biztosít. Először is, az Amazon CloudWatch — ez egy AWS erőforrások és alkalmazások monitoring szolgáltatás, amely lehetővé teszi többek között a különböző anomáliák észlelését a felhőben. Minden beépített AWS szolgáltatás, mint az Amazon Elastic Compute Cloud (szerverek), Amazon Relational Database Service (adatbázisok), Amazon Elastic MapReduce (adatfeldolgozás) és még 30 másik Amazon szolgáltatás az Amazon CloudWatch-t használja naplóik tárolásához. A fejlesztők használhatják az Amazon CloudWatch nyílt API-ját a naplómonitorozási funkciók hozzáadására a felhasználói alkalmazásokhoz és szolgáltatásokhoz, ezáltal bővítve az elemzett események körét a kiberbiztonság kontextusában.

Másodszor, a VPC Flow Logs szolgáltatás lehetővé teszi a hálózati forgalom elemzését, amelyet az AWS szerverei (kívülről vagy belülről) vagy a mikroszolgáltatások között küldenek vagy kapnak. Amikor bármely AWS VPC erőforrás kommunikál a hálózattal, a VPC Flow Logs szolgáltatás rögzíti a hálózati forgalom adatait, beleértve a forrás- és célhálózati interfészt, valamint az IP-címeket, portokat, protokollt, látott bájtok számát és csomagok számát. Azok, akik tapasztalattal rendelkeznek a helyi hálózati biztonságban, ezt a folyamatok analógiájának ismerik. NetFlow, amelyek vállalati szintű kapcsolók, routerek és tűzfalak által generálhatóak. Ezek a naplók fontosak a kiberbiztonsági monitorozás szempontjából, mivel ellentétben a felhasználói és alkalmazási aktivitás eseményeivel, lehetővé teszik a hálózati interakciók figyelését is, különösen egy virtuális magánfelhő környezetben az AWS-nél.

Így ezek a három AWS szolgáltatás — AWS CloudTrail, Amazon CloudWatch és VPC Flow Logs — együttesen hatékony képet nyújtanak a fiókjának használatáról, a felhasználói viselkedésről, az infrastruktúra kezeléséről, az alkalmazások és szolgáltatások aktivitásáról, valamint a hálózati forgalomról. Például segítségükkel az alábbi rendellenességeket lehet észlelni:

• A weboldal szkennelésére tett kísérletek, hátsó ajtók keresése, valamint sebezhetőségek felkutatása ‘404-es hibák’ kiugrása révén.
• Injection támadások (például SQL injection) ‘500-as hibák’ kiugrása révén.
• Ismert eszközök SQL-lel kapcsolatos támadásokhoz, mint például sqlmap, nikto, w3af, nmap stb. a User Agent mező elemzése által.

Az Amazon Web Services a kibervédelmi célokra más szolgáltatásokat is kifejlesztett, amelyek lehetővé teszik számos egyéb feladat megoldását. Például az AWS rendelkezik egy beépített szolgáltatással a politikák és konfigurációk auditálására — az AWS Config. Ez a szolgáltatás folyamatosan auditálja az AWS erőforrásait és azok konfigurációit. Vegyünk egy egyszerű példát: tegyük fel, hogy meg szeretné győződni arról, hogy a felhasználók jelszavai le vannak tiltva az összes szerverén, és a hozzáférés csak tanúsítványalapú. Az AWS Config lehetővé teszi, hogy ezt könnyen ellenőrizze az összes szerverén. Más politikák is alkalmazhatók a felhőszervereire: „Egyetlen szerver sem használhatja a 22-es portot”, „Csak az adminisztrátorok módosíthatják a tűzfal szabályait” vagy „Csak Ivashko felhasználó hozhat létre új felhasználói fiókokat, és ezt csak kedden teheti meg.” 2016 nyarán az AWS Config szolgáltatást kiterjesztették a kidolgozott politikák megsértésének automatizált észlelésére. Az AWS Config Rules lényegében folyamatos konfigurációs lekérdezések az Ön által használt Amazon szolgáltatásokra, amelyek eseményeket generálnak a vonatkozó politikák megsértése esetén. Például ahelyett, hogy időről időre lekérdezéseket végezne az AWS Config segítségével annak ellenőrzésére, hogy az összes virtuális szerver lemeze titkosított-e, az AWS Config Rules folyamatosan ellenőrizheti a szerverek lemezeit ezen feltétel teljesítése érdekében. És ami a legfontosabb, a jelen publikáció kontextusában, minden megsértés eseményeket generál, amelyeket az IT biztonsági szolgáltatása elemezhet.

Az AWS-ben találhatók olyan közelítői a hagyományos vállalati informatikai megoldásoknak, amelyek szintén generálnak olyan biztonsági eseményeket, amelyeket elemeznie kell:

• betörés-észlelés — AWS GuardDuty
• információszivárgás-ellenőrzés — AWS Macie
• EDR (bár furcsa az ablakon keresztüli eszközökről a felhőben) — AWS Cloudwatch + nyílt forráskódú megoldások, mint az osquery vagy a GRR
• Netflow-elemzés — AWS Cloudwatch + AWS VPC Flow
• DNS-elemzés — AWS Cloudwatch + AWS Route53
• AD — AWS Directory Service
• fiókkezelés — AWS IAM
• SSO — AWS SSO
• sebezhetőségek elemzése — AWS Inspector
• konfigurációkezelés — AWS Config
• WAF — AWS WAF.

Nem fogom részletesen felsorolni az összes Amazon-szolgáltatást, amelyek hasznosak lehetnek az információbiztonság kontextusában. A legfontosabb, amit meg kell érteni, hogy mindegyik generálhat eseményeket, amelyeket elemeznünk kell az információbiztonság szempontjából, kihasználva az Amazon beépített lehetőségeit, valamint külső megoldásokat, például SIEM-et, amely képes begyűjteni a biztonsági eseményeket a figyelő központba, és elemezni őket más felhőszolgáltatások vagy a belső infrastruktúra, perem vagy mobil eszközök eseményeivel együtt.

Minden esetben az adatok forrásaival kezdődik, amelyek biztosítják Önnek az információbiztonsági eseményeket. Ezek közé tartozhatnak többek között a következők:

• CloudTrail — API-k és felhasználói műveletek nyomon követése
• Trusted Advisor — biztonsági audit a legjobb gyakorlatoknak megfelelően
• Config — a fiókok és szolgáltatásbeállítások leltározása és konfigurációja
• VPC Flow Logs — csatlakozások virtuális interfészekhez
• IAM — az azonosításhoz és hitelesítéshez használható szolgáltatás
• ELB Access Logs — terheléselosztó naplói
• Inspector — alkalmazássebezhetőségek
• S3 — fájltároló
• CloudWatch — alkalmazások aktivitása
• SNS — értesítési szolgáltatás.

Az Amazon, amely ilyen széles spektrumú eseményforrásokat és generáló eszközöket kínál, ugyanakkor erősen korlátozott az összegyűjtött adatok információbiztonsági szempontú elemzésében. Önnek magának kell átnéznie a rendelkezésre álló naplókat, keresve a megfelelő kompromittáló indikátorokat. Az AWS Security Hub, amelyet nemrégiben indított el az Amazon, arra hivatott, hogy megoldja ezt a problémát, és egyfajta felhő SIEM legyen az AWS számára. De egyelőre még csak az útja elején jár, és korlátozott a források számában, amelyekkel dolgozik, valamint a maga architektúrája és előfizetései által beállított egyéb korlátozásokban.

Példa: Információbiztonság megfigyelése IaaS alapján Azure-on

Nem szeretnék hosszasan érvelni, hogy a három felhőszolgáltató közül (Amazon, Microsoft vagy Google) melyik a legjobb (főleg, hogy mindegyiknek megvan a maga sajátossága, amely a különböző feladatok megoldására alkalmas); inkább a biztonsági monitoring lehetőségeire összpontosítunk, amelyeket ezek a szereplők kínálnak. El kell ismerni, hogy az Amazon AWS volt az egyik első a piacon, ezért a biztonsági funkciók terén a legmesszebb jutott (bár sokan elismerik, hogy használatuk kissé bonyolult). De ez nem azt jelenti, hogy figyelmen kívül hagyjuk a Microsoft és a Google által nyújtott lehetőségeket.

A Microsoft termékei mindig is a "nyitottságukkal" tűntek ki, és az Azure esetében is hasonló a helyzet. Például míg az AWS és a GCP mindig az "ami nincs megengedve, az tilos" elve alapján működik, addig az Azure megközelítése éppen ellenkező. Például, amikor létrehoz egy virtuális hálózatot az felhőben és egy virtuális gépet benne, alapértelmezés szerint minden port és protokoll nyitva van és engedélyezett. Ezért egy kicsit több erőfeszítést kell tennie az Azure-beli hozzáférés-ellenőrzési rendszer kezdeti beállításához. Ez szigorúbb követelményeket is támaszt a felhőbeli aktivitás monitorozásával kapcsolatban.

Az AWS-nek van egy sajátos jellemzője, miszerint amikor virtuális erőforrásait figyeli, ha azok különböző régiókban vannak, nehézségei adódnak az események összegyűjtésével és egységes elemzésével, aminek megoldásához különféle trükkökhöz kell folyamodnia, mint például egy saját AWS Lambda kód létrehozása, amely az eseményeket átviszi a régiók között. Az Azure esetében ilyen probléma nincs — az Activity Log mechanizmusa nyomon követi a szervezet egészében zajló tevékenységeket korlátok nélkül. Ugyanez vonatkozik az AWS Security Hub-ra is, amelyet az Amazon nemrégiben fejlesztett ki a sok biztonsági funkció egyetlen biztonsági központba való konszolidálására, de csak a saját régióján belül, ami valóban nem releváns Oroszország számára. Az Azure rendelkezik a saját Security Center-jével, amely nem kötődik regionális korlátozásokhoz, és hozzáférést biztosít a felhőplatform összes biztonsági funkciójához. Sőt, különféle helyi csapatok számára képes biztosítani a saját védelmi lehetőségeik készletét, beleértve az általuk kezelt biztonsági eseményeket is. Az AWS Security Hub még csak arra törekszik, hogy hasonlítson az Azure Security Center-hez. De érdemes megemlíteni egy árnyoldalt — az Azure-ból igencsak sok mindent ki lehet hozni, ami korábban az AWS-nél volt leírva, de ez legjobban csak az Azure AD, Azure Monitor és Azure Security Center esetében érhető el. Az Azure többi védelmi mechanizmusa, beleértve a biztonsági események elemzését is, jelenleg nem a legkényelmesebb módon működik. Részben ezt a problémát orvosolja az API, amely áthatja a Microsoft Azure összes szolgáltatását, de ez további erőfeszítéseket követel meg az Ön felhőjének integrálásához a SOC-jával, és szükséges hozzá képzett szakemberek megléte (ahogy bármely más SIEM esetében, amely felhőalapú API-kkal dolgozik). Néhány SIEM, amelyekről a következő részben szó lesz, már támogatja az Azure-t és automatizálhatja a monitorozási feladatot, de velük is vannak nehézségek — nem mindegyik képes begyűjteni az összes logot, amely az Azure-ban található.

Az események gyűjtése és figyelemmel kísérése az Azure-ban az Azure Monitor szolgáltatáson keresztül történik, amely a Microsoft felhőjében és erőforrásaiban - Git tárolók, konténerek, virtuális gépek, alkalmazások stb. - az adatok gyűjtésére, tárolására és elemzésére szolgáló alapvető eszköz. Az Azure Monitor által gyűjtött összes adat két kategóriára oszlik - az első a valós időben gyűjtött metrikák, amelyek az Azure felhő kulcsfontosságú teljesítménymutatóit írják le, a második pedig a naplóbejegyzések, amelyek olyan adatokat tartalmaznak, amelyek különböző erőforrások és szolgáltatások működésének vonatkozásait jellemzik. Ezen kívül az Azure Monitor Data Collector API segítségével bármilyen REST forrásból gyűjthet adatokat a saját figyelési forgatókönyveinek kialakításához.

Íme néhány biztonsági eseményforrás, amelyet az Azure kínál, és amelyhez hozzáférhet az Azure Portal, az CLI, a PowerShell vagy a REST API segítségével (sőt, egyesek csak az Azure Monitor / Insight API-n keresztül):

• Activity Logs - ez a napló válaszol a klasszikus „ki”, „mit” és „mikortól” kérdésekre bármilyen írási művelet (PUT, POST, DELETE) kapcsán a felhő erőforrásaival. Az olvasási hozzáféréssel (GET) kapcsolatos események nem kerülnek be a naplóba, akárcsak számos más esemény.
• Diagnostic Logs - tartalmazza a különböző erőforrásokkal végzett műveletek adatait, amelyek a feliratkozásában találhatók.
• Azure AD reporting - tartalmazza a felhasználói tevékenységet és a rendszertevékenységet a csoportok és felhasználók kezelésével kapcsolatban.
• Windows Event Log és Linux Syslog - tartalmazza a felhőben elhelyezett virtuális gépek eseményeit.
• Metrics - tartalmazza a felhőszolgáltatások és erőforrások teljesítményének és 'egészségének' telemetriáját. Ezeket egy percenként mérik és 30 napig tárolják.
• Network Security Group Flow Logs - tartalmazza a Network Watcher szolgáltatás révén gyűjtött hálózati biztonsági események adatait, valamint a hálózati szintű erőforrások figyelését.
• Storage Logs - tartalmazza a tárolókhoz való hozzáféréssel kapcsolatos eseményeket.

A monitoring system can include external SIEMs or the built-in Azure Monitor and its extensions. We will discuss security event management systems later, but for now, let's explore what Azure offers for data analysis in the security context. The main screen for everything related to security in Azure Monitor is the Log Analytics Security and Audit Dashboard (the free version supports storing a limited volume of events for only one week). This dashboard is divided into five key areas, visualizing summary statistics about what is happening in your cloud environment:

• Security Domains — key quantitative metrics related to security, including the number of incidents, number of compromised nodes, unpatched nodes, network security events, etc.
• Notable Issues — displays the number and significance of active security problems
• Detections — shows patterns of attacks that have been used against you
• Threat Intelligence — presents geographical information about external nodes that are attacking you
• Common security queries — typical queries that will help you better monitor your security.

Azure Monitor extensions include Azure Key Vault (protecting cryptographic keys in the cloud), Malware Assessment (analyzing malware protection on virtual machines), Azure Application Gateway Analytics (analyzing, among other things, logs of the cloud firewall), etc. These tools, enriched with specific event handling rules, allow visualization of various aspects of cloud services, including security, and identifying deviations in operations. However, as is often the case, any additional functionality requires an appropriate paid subscription, necessitating financial planning in advance.

Az Azure számos beépített lehetőséggel rendelkezik a fenyegetések figyelésére, amelyek integrálva vannak az Azure AD, Azure Monitor és Azure Security Center szolgáltatásokba. Ezek között például megtalálható a virtuális gépek ismert kártékony IP-kkel való interakciójának észlelése (a Microsoft Threat Intelligence szolgáltatásaival való integráción keresztül), a kártékony szoftverek észlelése a felhős infrastruktúrában a felhőben elhelyezett virtuális gépektől érkező riasztások alapján, a virtuális gépekkel szembeni “jelszó feltörés” típusú támadások, a felhasználói azonosító rendszer konfigurációjának sérülékenységei, bejelentkezések anonymizálókból vagy fertőzött csomópontokból, fiókok kiszivárgása, bejelentkezések szokatlan helyekről stb. Az Azure ma az egyik olyan kevés felhőszolgáltató, amely beépített Threat Intelligence lehetőségeket kínál a begyűjtött IT-biztonsági események gazdagítására.

Ahogyan már említettük, a védelmi funkciók és az azokból származó biztonsági események nem minden felhasználó számára elérhetők egyformán, és bizonyos előfizetést igényelnek, amely magában foglalja a szükséges funkciókat, amelyek generálják a megfelelő eseményeket az IT-biztonság figyelésére. Például a fiókok anomáliáinak figyelésére vonatkozó, az előző bekezdésben említett funkciók közül néhány csak a P2 prémium licenc keretein belül érhető el az Azure AD szolgáltatás esetében. Enélkül, akárcsak az AWS esetében, Önnek manuálisan kell elemeznie a begyűjtött biztonsági eseményeket. Továbbá, az Azure AD licenc típusa alapján nem minden esemény áll majd rendelkezésére az elemzéshez.

Az Azure portálon kezelheti a keresési lekérdezéseket az Önt érdeklő naplózási adatokhoz, valamint testre szabhatja a műszerfalakat a kulcsfontosságú IT-biztonsági teljesítménymutatók vizualizálására. Ezen kívül ott választhatja az Azure Monitor kiterjesztéseit, amelyek lehetővé teszik a Azure Monitor naplózásának funkcionalitásának bővítését, és mélyebb elemzést kínálnak az események biztonsági szempontjából.

Ha nemcsak a naplók kezelésére van szüksége, hanem egy átfogó biztonsági központra az Azure felhőplatformján, beleértve a biztonsági politikák kezelését, akkor érdemes megfontolnia az Azure Security Center használatát, amelynek a legtöbb hasznos funkciója külön díj ellenében érhető el, például fenyegetés-észlelés, Azure-n kívüli monitoring, megfelelőségértékelés stb. (a ingyenes verzióban csak a biztonsági értékelés és a javaslatok állnak rendelkezésre a feltárt problémák megoldására). Ez egyesíti az összes biztonsági kérdést egy helyen. Valójában egy magasabb szintű biztonságot kínál, mint amit az Azure Monitor nyújt, mivel ebben az esetben az Ön felhőgyárában összegyűjtött adatokat számos forrással gazdagítják, mint például Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) és a Microsoft Security Response Center (MSRC), amelyekre különféle fejlett gépi tanulási algoritmusokat és viselkedéselemzést alkalmaznak, ami végső soron javítja a fenyegetések észlelésének és kezelésének hatékonyságát.

Az Azure-nak van saját SIEM megoldása is, amely 2019 elején jelent meg. Ez az Azure Sentinel, amely az Azure Monitor adataira támaszkodik, és integrálható külső biztonsági megoldásokkal (például NGFW vagy WAF), amelyek listája folyamatosan bővül. Ezen kívül a Microsoft Graph Security API integrálásával lehetősége nyílik saját Threat Intelligence feedjeit csatlakoztatni a Sentinellel, ami gazdagítja az események elemzésének lehetőségeit az Azure felhőjében. Azt lehet állítani, hogy az Azure Sentinel az első „nativa” SIEM, amely a felhőszolgáltatók körében megjelent (míg a Splunk vagy az ELK, amelyeket a felhőben lehet futtatni, például az AWS-n, valójában nem tradicionális felhőszolgáltatók fejlesztették). Az Azure Sentinel és a Security Center egy SOC-ként is felfogható az Azure felhő számára, és ezekre támaszkodhat, ha nincs más infrastruktúrája, és valamennyi számítási erőforrását a felhőbe helyezte, amely Microsoft Azure felhőként üzemel.

Mivel az Azure beépített funkciói (még a Sentinel előfizetés megléte esetén is) gyakran nem elegendőek az IT biztonság monitorozási céljaira és ennek a folyamatnak a más biztonsági eseményforrásokkal való integrálásához (akár felhőalapú, akár helyi), szükség van az összegyűjtött adatok exportálására külső rendszerekbe, beleértve a SIEM-et is. Ez API-n keresztül, valamint speciális bővítmények segítségével történik, amelyek jelenleg hivatalosan csak a következő SIEM-ekhez elérhetők: Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight és ELK. Nem is olyan régen több ilyen SIEM volt, de 2019. június 1-jétől a Microsoft megszüntette az Azure Log Integration Tool (AzLog) támogatását, amely az Azure korai létrejöttekor, amikor még nem volt normális szabványosítás a naplókkal való munkára (az Azure Monitor még nem létezett), lehetővé tette a külső SIEM-ek egyszerű integrálását a Microsoft felhőjével. A helyzet most megváltozott, és a Microsoft az Azure Event Hub-ot ajánlja, mint az integráció fő eszközét a többi SIEM-hez. Sokan már végrehajtották ezt az integrációt, de legyünk óvatosak – nem biztos, hogy az összes Azure naplót rögzítik, csak néhányat (ellenőrizd a SIEM-dokumentációban).

Befejezve egy rövid áttekintést az Azure-ról, szeretnék általános ajánlást adni ezzel a felhőszolgáltatással kapcsolatban — mielőtt bármit is állítanánk az Azure biztonsági monitoring funkcióiról, nagyon figyelmesen be kell állítani őket, és tesztelni, hogy úgy működnek, ahogyan azt a dokumentációban leírták, és ahogyan azt a Microsoft tanácsadói mondták (akiknek eltérő nézeteik lehetnek az Azure funkciók működéséről). Ha pénzügyi lehetőségek vannak, az Azure-ból nagyon sok hasznos dolgot ki lehet hozni a biztonsági monitoring terén. Ha azonban a forrásaid korlátozottak, akkor, ahogy az AWS esetében is, csak a saját erődben és az Azure Monitor által megadott nyers adatokra támaszkodhatsz. És ne feledd, hogy sok monitoring funkció pénzbe kerül, és jó előre érdemes megismerkedni az árazási politikájukkal. Például ingyenesen tárolhatsz 31 napig legfeljebb 5 GB adatot megrendelőnként — ezek a határok túllépése további költségeket vonhat maga után (kb. 2+ dollár minden egyes további GB-ért a megrendelőnél, és 0,1 dollár egy GB ingyenes tárolásáért minden további hónapban). Az alkalmazások telemetriájával és metrikáival való munka szintén további pénzügyi forrást igényelhet, akárcsak a riasztásokkal és értesítésekkel való munka (ingyenesen elérhető egy bizonyos határ, ami esetleg nem elegendő a szükségleteidhez).

Példa: Biztonsági monitoring IaaS szinten a Google Cloud Platformon

A Google Cloud Platform az AWS és az Azure mellett még fiatalnak tűnik, de ez részben jó is. Míg az AWS fokozatosan bővítette a lehetőségeit, beleértve a védelmi funkciókat is, de központosítási problémái voltak; a GCP, akárcsak az Azure, sokkal jobban központilag kezelhető, ami csökkenti a hibák számát és a bevezetési időt a vállalatnál. A biztonság szempontjából a GCP meglepő módon az AWS és az Azure között helyezkedik el. Van egy egységes eseményregisztráció az egész szervezet számára, de ez nem teljes. Néhány funkció még beta állapotban van, de fokozatosan ezt a hátrányt el kell hárítani, és a GCP érettebb platformmá válik a biztonsági monitoring szempontjából.

A GCP eseményeinek regisztrálásához használt fő eszköz a Stackdriver Logging (az Azure Monitor megfelelője), amely lehetővé teszi az események gyűjtését az Ön felhőinfrastruktúrájában (valamint az AWS-ről is). A GCP biztonsági szempontjából minden szervezet, projekt vagy mappa négy naplóval rendelkezik:

• Admin Activity — tartalmazza az összes eseményt, amely az adminisztrátori hozzáféréssel kapcsolatos, például virtuális gép létrehozása, jogosultságok módosítása stb. Ez a napló mindig rögzítésre kerül, függetlenül a kívánságától, és az adatait 400 napig tárolja.
• Data Access — tartalmazza az összes eseményt, amely a felhőhaszná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 mérete nagyon gyorsan megnő. Emiatt a megőrzési ideje csupán 30 nap. Ezen kívül nem minden esemény íródik be. Például a köztulajdonban lévő, minden felhasználó számára elérhető erőforrásokkal kapcsolatos események, vagy azok, amelyek a GCP-be való bejelentkezés nélkül is elérhetők, nem kerülnek be.
• System Event — olyan rendszereseményeket tartalmaz, amelyek nem kapcsolódnak felhasználókhoz, vagy olyan adminisztrátorok által végzett tevékenységeket, akik megváltoztatják a felhőerőforrások konfigurációját. Ez mindig rögzítésre kerül, és 400 napig tárolják.
• Access Transparency — ez egyedülálló példa a naplózásra, amely rögzíti a Google munkatársainak minden tevékenységét (de egyelőre nem minden GCP szolgáltatás esetében), akik a hivatalos feladataik ellátása során hozzáférnek az Ön infrastruktúrájához. Ez a napló 400 napig tárolódik, és nem minden GCP ügyfél számára elérhető, csak bizonyos feltételek teljesülése esetén (vagy Gold vagy Platinum szintű támogatás, vagy négy bizonyos típusú szerep megléte a vállalati támogatás keretében). Hasonló funkcióval rendelkezik például az Office 365 is — Lockbox.

Példa a naplóra: 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: "Eset szám: bar123"
 type: "CUSTOMER_INITIATED_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

A megadott naplókhoz többféleképpen is hozzáférhet (hasonlóan az Azure és az AWS által korábban bemutatottakhoz) — a Log Viewer felületen, az API-n keresztül, a Google Cloud SDK használatával, vagy a projekt Activity oldalán, ahol az eseményeket keresheti. Ugyanezen a módon exportálhatók külső megoldásokba is további elemzés céljából. Az utóbbi a naplók exportálásával történik a BigQuery vagy Cloud Pub/Sub tárolóba.

A Stackdriver Logging mellett a GCP platform további funkciókat is kínál a Stackdriver Monitoring révén, amely lehetővé teszi a kulcsfontosságú metrikák (teljesítmény, hibásodás, általános állapot stb.) figyelését a felhőszolgáltatásokban és alkalmazásokban. A különleges módon feldolgozott és vizualizált adatok megkönnyíthetik a problémák felkutatását a felhőinfrastruktúrájában, beleértve a biztonság szempontjából is. De meg kell jegyezni, hogy ez a funkció nem túl gazdag a kiberbiztonság kontextusában, mivel a GCP jelenleg nem kínál analógot az AWS GuardDuty-hoz, és nem képes kiragadni a regisztrált események közül a potenciálisan rosszakat (a Google kifejlesztette az Event Threat Detection-t, de az még bétában van, ezért a hasznosságáról túl korai beszélni). A Stackdriver Monitoringot anomáliák észlelésére lehetne használni, amelyeket aztán kivizsgálnak az okai megtalálása érdekében. De a piac Kiberbiztonság területén tapasztalható szakemberhiányában ez a feladat jelenleg nem tűnik könnyűnek.

Érdemes megemlíteni néhány kiberbiztonsági modult, amely alkalmazható a GCP felhőjében, és amelyek hasonlóak az AWS kínálatához:

• A Cloud Security Command Center az AWS Security Hub és az Azure Security Center analógja.
• Cloud DLP — automatikus adatok felfedezése és szerkesztése (például maszkolás) felhőben, több mint 90 előre beállított osztályozási szabály alapján.
• Cloud Scanner — ismert sebezhetőségek (XSS, Flash Injection, javítatlan könyvtárak stb.) vizsgálata az App Engine, Compute Engine és Google Kubernetes rendszerében.
• Cloud IAM — hozzáféréskezelés a GCP összes erőforrásához.
• Cloud Identity — felhasználói, eszköz- és alkalmazásfiókok kezelése a GCP egyetlen konzoljából.
• Cloud HSM — kriptográfiai kulcsok védelme.
• Cloud Key Management Service — kriptográfiai kulcsok kezelése a GCP-n.
• VPC Service Control — biztonságos perem létrehozása a GCP erőforrásai körül az adatlopások védelmére.
• Titan Security Key — védelem a phishing ellen.

Sok ezekből a modulokból biztonsági eseményeket generálnak, amelyeket a BigQuery tárolóba küldhetünk elemzés céljából, vagy exportálhatók más rendszerekbe, beleértve a SIEM-et is. Ahogy már említettük, a GCP egy aktívan fejlesztett platform, és jelenleg a Google számos új biztonsági modult fejleszt a platformjára. Köztük az Event Threat Detection (jelenleg béta verzióban elérhető), amely a Stackdriver naplóit szkennelve keresi a jogosulatlan tevékenység nyomait (hasonló a GuardDuty-hoz az AWS-ben), vagy a Policy Intelligence (alpha verzióban elérhető), amely lehetővé teszi az intelligens hozzáférési szabályok kidolgozását a GCP erőforrásaihoz.

Készítettem egy rövid áttekintést a népszerű felhőplatformok beépített monitorozási lehetőségeiről. De van-e Önöknél olyan szakember, aki képes dolgozni az IaaS szolgáltató „nyers” naplóival (nem mindenki hajlandó megvásárolni az AWS, Azure vagy Google kiterjesztett lehetőségeit)? Ezenkívül sokan ismerik a mondást: „bízz, de ellenőrizz”, amely a biztonság terén soha nem volt ennyire érvényes. Mennyire bízik a felhőszolgáltató beépített biztonsági eseménykezelő képességeiben? Mennyire összpontosítanak egyáltalán a biztonságra?

Néha érdemes a felhőinfrastruktúrák monitorozására vonatkozó integrált megoldások felé figyelni, amelyek kiegészíthetik a felhő beépített biztonságát, és néha ezek a megoldások az egyetlen lehetőség a felhőben tárolt adatok és alkalmazások biztonságának nyomon követésére. Továbbá egyszerűbbek is, mivel átvállalják az olyan naplók elemzésével járó feladatokat, amelyeket különböző felhőszolgáltatók eltérő felhőszolgáltatásai generálnak. Ilyen integrált megoldás például a Cisco Stealthwatch Cloud, amely kizárólag a felhői környezetekben történő anomáliák IT biztonsági monitorozására összpontosít, így figyelemmel kísérheti az Amazon AWS, a Microsoft Azure és a Google Cloud Platform, valamint a magánfelhők által generált eseményeket.

Példa: IT biztonság monitorozása a Stealthwatch Cloud segítségével

Az AWS rugalmas számítási platformot kínál, ám ez a rugalmasság lehetővé teszi a cégek számára, hogy könnyebben kövessenek el olyan hibákat, amelyek biztonsági problémákhoz vezethetnek. A megosztott IT biztonsági modell csak hozzájárul ehhez. Ismeretlen sebezhetőségekkel rendelkező szoftver felhőben való futtatása (a már ismert sebezhetőségekkel az AWS Inspector vagy a GCP Cloud Scanner foglalkozik), gyenge jelszavak, helytelen konfigurációk, belső emberek stb. Mindezek az események ráférnek a Cisco Stealthwatch Cloud figyelésére, amely egy IT biztonsági monitorozó és támadásmegelőző rendszer a nyilvános és magánfelhőkben.

A Cisco Stealthwatch Cloud egyik kulcsfontosságú jellemzője az entitások modellezésének lehetősége. Ezzel szinte valós időben létrehozhat egy szoftveres modellt (tehát egy szimulációt) minden felhőbeli erőforrásáról (függetlenül attól, hogy AWS, Azure, GCP vagy más). Beleértve a szervereket és a felhasználókat, valamint az Ön felhőalapú környezetére jellemző erőforrás-típusokat, mint például a biztonsági csoportok és a szolgáltatások automatikus méretezésének csoportjai (auto-scale). Ezek a modellek a felhőszolgáltatók által biztosított strukturált adatfolyamokat használják bemenetként. Például AWS esetében ez VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda és AWS IAM. Az entitások modellezése automatikusan felfedi bármely erőforrása szerepét és viselkedését (lehetőség van a teljes felhőtevékenység profilozására). Ilyen szerepek lehetnek például Android vagy Apple mobil eszköz, Citrix PVS szerver, RDP szerver, e-mail átjáró, VoIP kliens, terminál szerver, domain vezérlő stb. Ezután folyamatosan nyomon követi a viselkedésüket, hogy meghatározza, amikor kockázatos vagy biztonságot fenyegető aktivitás zajlik. Azonosíthatja a jelszavak kitalálását, DDoS támadásokat, adatlopásokat, illegális távoli hozzáféréseket, rosszindulatú kódok tevékenységét, sebezhetőségek szkennelését és egyéb fenyegetéseket. Például így néz ki egy szokatlan, az Ön szervezetéhez tartozó országból (Dél-Koreából) egy SSH-n keresztüli távoli hozzáférés kísérlete a Kubernetes klaszterhez:

Így néz ki egy feltételezett információszivárgás a Postgress adatbázisból egy olyan országba, amely korábban nem létezett, itt látható a kölcsönhatás:

Végül így néz ki egy túl nagy számú sikertelen SSH-hozzáférési kísérlet Kínából és Indonéziából, egy külső távoli eszközről:

Tegyük fel, hogy egy VPC szerver példánynak a politikája szerint sosem szabadna a távoli bejelentkezés célpontjának lennie. Továbbá, tegyük fel, hogy ezen a számítógépen távoli bejelentkezés történt egy hibás tűzfal-szabályváltoztatás következtében. Az entitásmodellezési funkció észleli és jelenti ezt a tevékenységet („Szokatlan távoli hozzáférés”) szinte valós időben, és megjelöli a konkrét AWS CloudTrail, Azure Monitor vagy GCP Stackdriver Logging API hívást (beleértve a felhasználó nevét, a dátumot és az időt, több más részlet mellett), amely a tűzfalszabály megváltozását okozta. Ez az információ aztán továbbítható a SIEM rendszerbe elemzés céljából.

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

Az entitásmodellezés egy egyedülálló biztonsági automatizálás, amely képes észlelni a korábban ismeretlen problémákat az embereikkel, folyamatokkal vagy technológiáikkal. Például képes észlelni mások mellett az alábbi biztonsági problémákat:

• Felfedezett-e valaki hátsó ajtót a használt szoftverünkben?
• Van-e valamilyen külső szoftver vagy eszköz a felhőnkben?
• Visszaél-e egy jogos felhasználó a jogosultságaival?
• Következett-e be konfigurációs hiba, amely távoli hozzáférést vagy egyéb nem szándékos erőforrás-használatot eredményezett?
• Történt-e adatlopás a szervereinkről?
• Próbált-e valaki csatlakozni hozzánk szokatlan földrajzi helyről?
• Megfertőződött-e a felhőnk kártékony kóddal?

Az észlelt kiberbiztonsági esemény a Slack, a Cisco Spark, a PagerDuty incidenskezelő rendszer vagy különböző SIEM rendszerek, például a Splunk vagy az ELK segítségével megfelelő jegy formájában továbbítható. Összefoglalva, ha a cége többfelhős stratégiai megközelítést alkalmaz, és nem korlátozódik egyetlen felhőszolgáltatóra sem, akkor a biztonsági figyelési lehetőségek, amelyeket a fenti példa mutatott, a Cisco Stealthwatch Cloud alkalmazása jó módja lehet a vezető felhőszolgáltatók — Amazon, Microsoft és Google — figyelésének egyesített lehetőségeinek megszerzésére. A legérdekesebb pedig az, hogy ha a Stealthwatch Cloud árait összehasonlítjuk az AWS, Azure vagy GCP fejlettebb kiberbiztonsági monitoring engedélyeivel, kiderülhet, hogy a Cisco megoldása olcsóbb lehet, mint az Amazon, Microsoft és Google beépített rozwiązásainak lehetőségei. Paradox módon, de így van. Minél több felhőt és azok lehetőségeit használja, annál nyilvánvalóbbá válik a konszolidált megoldás előnye.

Ezenkívül a Stealthwatch Cloud képes figyelni a szervezetén belül telepített magánfelhőket is, például Kubernetes konténer alapú megoldásokat vagy a Netflow-áramok, illetve a hálózati forgalom figyelésével, amelyet a hálózati berendezések (még hazai gyártású) tükrözésével, AD adatokkal vagy DNS-szerverekkel stb. gyűjtenek. Mindezek az adatok a Cisco Talos által gyűjtött Threat Intelligence információkkal gazdagodnak, amely a világ legnagyobb kiberbiztonsági fenyegetéskutató csoportja.

Ez lehetővé teszi, hogy a cége különböző nyilvános és hibrid felhők monitorként használjon egységes rendszert. Az összegyűjtött információkat ezután az Stealthwatch Cloud beépített lehetőségeivel elemezheti, vagy elküldheti a SIEM rendszerébe (alapértelmezetten támogatott a Splunk, az ELK, a SumoLogic és számos egyéb).

Ezzel lezárjuk a cikk első részét, amelyben áttekintettem az IaaS/PaaS platformok beépített és külső biztonsági monitorozó eszközeit, amelyek lehetővé teszik számunkra, hogy gyorsan felfedezzük és reagáljunk a felhő környezetekben, ahol vállalatunk működik, előforduló incidensekre. A második részben folytatjuk a témát, és megvizsgáljuk a SaaS platformok monitorozási lehetőségeit a Salesforce és a Dropbox példáján, valamint megpróbáljuk összefoglalni és egyesíteni az összeset egy átfogó biztonsági monitorozó rendszer létrehozásával különböző felhőszolgáltatók esetében.

Forrás: habr.com