Az Active Directoryban rejlő eredendő kockázatok a hibrid rendszereknél, amikor színre lép az azure-os AD, hatványozottan jelentkeznek. Vannak azonban bevált módszerek a kezelésükre.

Minden kibertámadást meg lehet akadályozni. Bár a rosszfiúk kezdeményezőként mindig lépéselőnyben vannak, hiszen egy (vagy több) gyenge pont ismeretében támadnak, de az átgondolt biztonsági folyamatok, a naprakész biztonsági tudás és tudatosság, valamint a kockázatokkal (és a védendő értékkel) arányos védelmi rendszer már fél siker. Ha a kiberbűnözők át is jutnak a védelmi vonalakon, kellően rövid TTD (time to detect) után még rövidebb TTR (time to respond) következik. Ez pedig a gyakorlatban azt jelentheti a vállalatnak, hogy még az előtt sikerül elhárítania a támadást, hogy végzetes adatszivárgás, rombolás vagy egyéb károkozás történne.

Tematikus összeállításunk korábbi két cikkében egyrészt megvizsgáltuk, miért kap egyre gyakrabban szerepet az Active Directory a kibertámadásokban, másrészt a leggyakoribb kockázati tényezőket is összegyűjtöttük. Az alábbiakban pedig megnézzük: melyek azok a lépések, amikkel csökkenthető a vállalati rendszerek kitettsége a címtárszolgáltatás hordozta kockázatoknak.

Mint azt korábban megállapítottuk, az Active Directory/Azure Active Directory (AD/AAD) azért követel kiemelt védelmet, mert aki hatalmat szerez fölötte, lényegében a teljes rendszer fölött szerez fennhatóságot. Az AD/AAD ellenőrzi ugyanis, hogy ki férhet hozzá a kritikus rendszerekhez és adatokhoz. Ezért mind a folyamatokban, mind az architektúrában olyan elveket kell érvényesíteni, ami maximális védelmet biztosít a a címtárszolgáltatásnak.

Zero Trust architektúra

A szakértők buzzwordje ezzel kapcsolatban most a zero trust. A zero trust alapelve nagyon vonzó. Azt ígéri ugyanis, hogy mindig tudja a következő három tényezőt: ki akar hozzáférni egy erőforráshoz (identitásellenőrzés, azaz a felhasználó hitelesítése), milyen állapotú eszközről (az eszköz fertőzött vagy sem) és mihez (a hozzáférési jogosultság ellenőrzésére). És ezáltal garantálja, hogy mindenki csak az adott feladathoz adott pillanatban szükséges jogosultságokat fogja megkapni az adott feladat elvégzésének időtartamára. (Apró probléma, hogy a vállalatok kis hányada használ zero trust modellre épülő technológiákat és eljárásokat. A nagy többség nem alkalmazza a mikroszegmentálást, és még remote módban sem teszi kötelezővé a többfaktoros azonosítást.)

Ha valamire, akkor a jogosultságokra hangsúlyozottan igaz: rendkívül szigorúan kell kezelni, különösen a kiemelt felhasználókét. Intő jel, ha az admin jogokkal rendelkezők listája túl hosszú – a domainszintű admin csoport esetében pedig egyenesen életveszélyes. Tételesen és rendszeresen át kell vizsgálni, hogy munkaköréből adódóan kinek, mikor és milyen hozzáférésekre van szüksége. Ha generálisan nem is lehet bevezetni a zero trust működési elvet, a jogosultságok kiosztásánál mindenképpen érdemes követni a "legkisebb jogosultság" vagy PoLP (Principle of Least Privilege) szabályát (lásd a sorozat előző részét).

Ideális esetben minden fiókot akkor szüntetünk meg vagy módosítunk – mégpedig azonnal –, amikor az fölöslegessé válik, vagy tartalma érvényét veszti: pl. amikor használója távozik a vállalattól, vagy más beosztásba/területre kerül a szervezeten belül, ezért más jogosultságokra (csoportra stb.) lesz szüksége. Mint korábban írtuk, az inaktív fiókok különösen veszélyesek, hiszen minden szempontból megfelelhetnek a belső biztonsági szabályzatnak – leszámítva, hogy a fiókokhoz tartozó felhasználók már nem tagjai a szervezetnek –, így egy tevékenységfigyelő rendszer sem feltétlenül szúrja ki az azokon keresztül folytatott tevékenységet.

A jogosultságok felülvizsgálatát időről időre el kellene végezni, hiszen a vállalati szervezet folyamatosan változik, új munkatársak érkeznek, régiek távoznak, beosztások és feladatkörök módosulnak és így tovább. Ezt a folyamatot a lehetőség szerint érdemes automatizálni, például hogy a szervezeti változás hatását a jogosultságokra ne kézzel kelljen átvezetni, hanem az automatikusan megtörténjen, amikor valakinek megváltozik a HR-rendszerben a státusza.

Átlátható biztonságmenedzsment

Ma a CISO-k előtt álló egyik legnagyobb kihívás, hogy megfelelő rálátást kapjanak az egyre komplexebb vállalati IT-infrastruktúrát védő, és ahhoz hasonlóan egyre komplexebb védelmi rendszerekről, valamint azok üzemeltetési folyamatairól. Egy tavalyi kutatás szerint még az egyszerűbb védelmet használó vállalatoknál is tucatnyi gyártótól származó megoldást használnak, a vállalatok egy kis része pedig 50-nél is több vendor IT-biztonsági eszközeivel küzd.

A biztonsági csapatnak ezek integrálása és egységes keretben történő üzemeltetése komoly nehézségeket okoz, amit egy hibrid (on-premise + felhő) rendszerben az AD és az AAD egymás mellett élése megfejel azzal a problémával, hogy a felhasználói fiókokat, a hozzáféréseket, a csoportos házirendet stb. – azaz a biztonság egyik kulcselemét – lényegében párhuzamosan kell két helyen karbantartani, ami eleve növeli az emberi hibák lehetőségét. Célszerű ezért olyan menedzsmenteszközt keresni, ami egységesíti az AD és az AAD menedzsmentjét, esetleg még automatizál is bizonyos folyamatokat.

A szállítók ráéreztek erre az igényre: egyre több ilyen termék jelenik meg a piacon. Amikor valaki ilyen eszközt választ, elsősorban arról kell meggyőződnie, hogy az adott megoldás valóban az AD és AAD menedzsmentjét egyesíti (ha ugyanis csak annyit tesz, hogy egy felületre összevonja a két címtárszolgáltatást, de a kettőt továbbra is egyenként kell menedzselni, igazából tyúklépésnél is kisebbet közeledtünk a megoldás felé). Ha még a vállalati IAM (Identity and Access Management) funkciókkal is össze lehet kapcsolni, az a biztonsági szint újabb emelkedését hozhatja.

Emellett fontos választási szempont lehet a változáskövetéses naplózásának lehetősége vagy az auditálás támogatása (pl. integrálhatóság auditeszközökkel). Vannak eszközök, melyek alkalmazáslicenc-menedzsmenttel és a szoftverszolgáltatások költségkezelésével még egyfajta licencoptimalizáló/költségoptimalizáló funkciót is ellátnak, de a biztonságos üzemeltetés szempontjából fontosabb a menedzsmenteszköz rugalmassága, testre szabhatósága, valamint az automatizálás lehetőségei.

Érdemes megvizsgálni ezeket az eszközöket. A SolarWinds-ügy ugyanis rávilágított arra, milyen súlyos támadások érkezhetnek a címtárszolgáltatáson keresztül. De arra is, hogy legfeljebb felkészületlenek vagyunk, de eszköztelenek semmiképpen.

Ez a cikk független szerkesztőségi tartalom, mely a Balasys támogatásával készült. Részletek »

 

Biztonság

A Tesla bármelyik másik márkánál több halálos balesetben érintett

Az elmúlt években gyártott járműveket vizsgálva kiderült, hogy az amerikai utakon a Teslák az átlagosnál kétszer gyakrabban szerepelnek végzetes ütközésekben a megtett mérföldek arányában.
 
Ezt már akkor sokan állították, amikor a Watson vagy a DeepMind még legfeljebb érdekes játék volt, mert jó volt kvízben, sakkban vagy góban.
Amióta a VMware a Broadcom tulajdonába került, sebesen követik egymást a szoftvercégnél a stratégiai jelentőségű változások. Mi vár az ügyfelekre? Vincze-Berecz Tibor szoftverlicenc-szakértő (IPR-Insights) írása.

Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak

Különösen az early adopter vállalatoknak lehet hasznos. De különbözik ez bármiben az amúgy is megkerülhetetlen tervezéstől és pilottól?

Sok hazai cégnek kell szorosra zárni a kiberkaput

Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizennegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2024 Bitport.hu Média Kft. Minden jog fenntartva.