Amikor a Microsoftot a közelmúltban az amerikai kongresszus illetékes bizottsága elé citálták azzal kapcsolatban, hogy rendszerei hibáinak mekkora szerepe volt a SolarWinds-támadásokban, a vállalat elnöke, Brad Smith szemrebbenés nélkül jelentette ki: semmi. A támadáshoz vezető problémákat az ügyfeleknél a rendszerek hibás konfigurálása és egyéb problémák okozták. Ha a széf vagy az autó kulcsát elöl hagyják, akkor azok lényegében nyitva vannak, példálózott Smith.

Ezzel nem mindenki ért egyet, az érintett felhasználók biztosan nem. De George Kurtz, a kibervédelmi megoldásokat szállító CrowdStrike vezérigazgatója, szintén másban látja a kiberbűnözők sikerének okait: a Windows hitelesítési architektúrájának rendszerszintű gyengeségeire vezeti vissza a kiterjedt támadást. Szerinte a Microsoftnak sürgősen kellene kezdenie valamit az Active Directory (AD) és az Azure Active Directory (AAD) hitelesítési architektúrájának a korlátaival, vagy ha ez nem oldható meg, át kellene térnie egy másik módszertanra. (Kurtz szerint ez sürgetős, hiszen a világ egyik legszélesebb körben használt hitelesítési platformjáról lehetne kiküszöbölni egy jelentős fenyegetésvektort.)

Az igazság, mint az esetek többségében, itt is középen lehet. Az egy dolog, hogy a Microsoft sokkal többet is tehetne az on-premise és a felhős Active Directory biztonságának javításáért, de az ügyfelei szintén sokat tehetnének azért, hogy csökkentsék az azokban rejlő kockázatokat. Előbbi esetben a Microsoftra kell hagyatkoznunk. Utóbbi esetben azonban mi vagyunk a cselekvő fél: kereshetünk olyan kiegészítő megoldásokat, melyekkel magunk is csökkenthetjük windowsos rendszereink kitettségét a kibertámadásoknak.

De az első lépés mindig a kockázatok felmérése. Az alábbiakban a teljesség igénye nélkül számba veszünk néhány fontosabb problémát.

A struktúrából eredő hibalehetőségek

Számos nehézséggel kell megküzdeniük a rendszeradminisztrátornak, amikor párhuzamosan működtetnek felhős és on-premise címtárszolgáltatást. Mint azt cikksorozatunk előző részében írtuk, az AD és az AAD nem egymás helyi és felhős tükörképe: két egymástól független címtárszolgáltatás önálló menedzsmenteszközökkel. Ha a beállításokat-módosításokat a két helyen ad hoc módon, manuálisan kell végrehajtani, a két rendszer konzisztenciája biztosan sérül: előbb-utóbb követhetetlenné válik, hogy ki, hol és melyik felhasználói csoportba lett sorolva, nem követhető a jogosultságok kiosztásában a "legkisebb jogosultság" elve stb. Egyébként a third party megoldások zöme sem segít ezen, ha nem lehet kezelni velük egyszerre az AD belső azonosság- és hozzáférés-menedzselő eszközét, az ADUC-ot (Active Directory Users and Computers), valamint az AAD ugyanezen funkcióit.

Ilyenkor a rendszeradminisztrátorok egy része hajlamos a lovak közé dobni a gyeplőt... A címtárszolgáltatás ugyanis csábító lehetőség arra, hogy olyan struktúra jöjjön létre, amely csökkenti az adminok leterheltségét, ezért sokszor olyan feladatokat delegálnak a nem rendszergazda jogosultságú felhasználóknak, melyek érzékeny adatok kezelésével járnak. Meglehet, erre az adott felhasználónak szüksége van, ám a jogosultságkiosztás mögött nincs megfelelő értékelés és nyomon követés. Könnyen belátható, hogy ez súlyos incidensekhez vezethet.

De az sem szerencsés, ha az adminisztrátorok jogait terjesztik ki, hiszen esetükben is igaz: ha valakinek olyasmihez van jogosultsága, amire semmi szüksége, az könnyen visszaélésekhez vezethet. Kimutatható, hogy ilyen esetekben gyakoribb az adatszivárgás (ennek a jelenségnek pszichológiai okai is vannak, ám azok taglalása jelen témánktól messze vezetne). Ráadásul az AD/AAD egyik komoly hiányossága, hogy natív menedzsmenteszközeiben minden művelethez rendszergazdai fiók kell, amit viszont jellemzően többen is használhatnak, mert nem egy személyhez, hanem a címtárhoz kapcsolódik. Azaz akinek van rendszergazdai jogosultsága az adott AD-hoz és AAD-hoz, bármit megcsinálhat. Így sok bába között elvész a gyerek, hiszen teljesen kiiktatódik a rendszerből az egyéni felelősség korlátozó ereje.

Arra megint csak külön kell figyelni, hogy miközben az Active Directory menedzselését valójában egy-két rendszeradminisztrátor végzi, minden domainszintű admin megkapja hozzá a teljes jogosultságot. Ezek összességében átgondolt intézkedéscsomagot kívánnak.

Az egyszerűbben kezelhető ügyek

Vannak azonban olyan problémák is, amiket egyszerűen a folyamatok átgondoltabbá tételével is orvosolhatunk. Ráadásul ezek triviák, amikkel ennek ellenére sokan mégsem foglalkoznak.

Ilyen evidencia például, hogy fel kell számolni a gyenge jelszavakat (rövid, könnyen kitalálható stb.) – egyáltalán: miért nem álltak még át a többfaktoros azonosításra?! Egy kompromittálódott jelszó az Active Directory egészét veszélybe sodorhatja. A gyakran cserélődő jelszavak előírása viszont nem feltétlenül jó irány, erről évek óta komoly polémia folyik szakértői körökben.

A fiókokat karban kell tartani. Nem maradhat magára hagyott inaktív fiók (pl. távozott alkalmazott, akinek az AD/AAD szerint továbbra is hozzáférése van akár távolról is bizalmas belső anyagokhoz). Ha valaki megy, akkor a hozzáféréseit is azonnal törölni kell. Ahol kaphatnak felhasználók ideiglenesen is jogosultságot vendégként vagy anonim felhasználóként, csak erősen korlátozott jogokat szabad biztosítani számukra. Az egyébként a belsős munkatársakra és a kiemelt jogosultsággal rendelkező felhasználókra is igaz: csak a munkájukhoz szükséges minimum jogokat szabadna megkapniuk (legkisebb jogosultság elve). Ez az AD/AAD esetében súlyosbítja a csoportok működése, amely szülő-gyermek hierarchián alapul. Ha például egy csoportot hozzáadnak egy adminisztrátori jogokkal rendelkező csoporthoz, a hozzáadott csoport minden tagja megkapja az adminisztrátori jogokat.

A következő részben megnézzük, hogyan lehet mindezeket a problémákat kezelni.