A cikkben szereplő javaslatok az NBSZ NKI részéről nem tekintendőek ajánlásnak, különös tekintettel a VPN jelszóvisszaállításra vonatkozó javaslatokra.
A Microsoft Incident Response gyakran javasolja kiberbiztonsági incidensek során a tömeges jelszó-visszaállítást, mellyel fiókjainkat visszaszerezhetjük és megszakíthatjuk a támadók által létrehozott perzisztenciát. Azonban a nagyobb szervezeteknél a tömeges jelszó-visszaállítások koordinálása összetett feladat lehet. Ebben a bejegyzésben bemutatjuk ennek kihívásait, és azt, hogy lehet felkészülni rá a gyakorlatban.
A következőkben néhány példa arra vonatkozóan, hogy mely esetekben lehet jó megoldás a tömeges jelszó visszaállítás:
- Active Directory adatbázis kiszivárgása: ha bizonyított, hogy egy támadó kiszivárogtatta az Active Directory Domain Services (továbbiakban: AD DS) adatbázisát.
- Active Directory adatbázis előkészítése: ha bizonyíték van rá, hogy egy támadó ki fogja szivárogtatni az AD DS adatbázisát.
- Feltört fiókok: ha egy támadó feltörte például a domain, enterprise vagy „beépített” rendszergazdákhoz tartozó hitelesítő adatokat.
- Közbeékelődéses támadás: ha bizonyított, hogy közbeékelődéses (Attacker-in-the-Middle – AiTM) támadás során a támadó által kialakított proxy szolgáltatás felhasználói hitelesítő adatokat gyűjthetett.
- Felhő alapú, vagy harmadik féltől származó identitásplatform kompromittálódása: ha bizonyíték van arra, hogy egy hitelesítési platform, mint például a Microsoft Entra Connect, az AD FS (Active Directory Federation Services), a RADIUS (Remote Authentication Dial In User Service) szerverek vagy harmadik féltől származó identitáskezelési megoldás kompromittálódik.
- Ransomwarek telepítése: ha egy támadó sikeresen telepített zsarolóprogramokat azáltal, hogy feltörte a kiemelt Active Directory (AD) csoportokhoz tartozó fiókokat.
- Kiemelt hitelesítési adatok nyilvánosságra hozatala a Business Email Compromise (BEC) során: amikor az üzleti e-mailek kompromittálódnak.
- A kiszivárgott információkban található kiemelt hitelesítő adatok: ha például OneDrive vagy SharePoint adatszivárgás során privilegizált hitelesítő adatok kerültek nyilvánosságra.
- Kiemelt hitelesítő adatok felfedése a kódban: ha a jogosultsági szintű hitelesítő adatok elérhetővé váltak egy online kódban vagy verziókövetési repositoryban.
- Nemzetállamhoz vagy APT-hez (Advanced Persistent Threat) való tulajdonítás: ha egy támadás hátterében APT csoport vagy nemzetállam áll.
Felkészülés és megoldás
A probléma kezeléséhez a következő szempontokat kell figyelembe venni:
- Helyi felhasználók: elsősorban a helyszínen lévő felhasználók, akik közvetlen hozzáféréssel rendelkeznek a tartományvezérlőhöz.
- Távoli felhasználók: olyan felhasználók, akik elsősorban VPN szolgáltatást használnak (virtuális magán hálózatokat).
- Felügyeleti vezérlők: a jelszó-visszaállítást rendszergazdák vagy végfelhasználók hajtják-e végre.
- Szolgáltatásfiókok kezelése: a gyakran soha le nem járó jelszavakkal rendelkező szolgáltatásfiókok figyelembevétele.
- Kiemelt identitások: speciális szempontok a kiemelt felhő alapú és helyszíni fiókok kezeléséhez.
1. A tartományvezérlőkhöz közvetlen hozzáféréssel rendelkező felhasználók
Amikor a felhasználók megpróbálnak bejelentkezni az eszközeiken az irodában, egy bizonyos határidőn belül jelszóváltoztatást kell eszközölniük, különben a fiókjukat letiltják. A jelszavak fokozatos, de gyorsított lejárata a finomhangolt jelszószabályok (Fine Grained Password Policies – FGPP) használatával, valamint a jelszavak életkorának fokozatos csökkentése a tartományi házirendek módosításával alternatív módszereket kínál a tartományi felhasználók tömeges jelszó-visszaállításának kikényszerítésére. Ennek az a hátránya, hogy a támadó egy hitelesített munkameneten belül maradhat, amíg egy bejelentkezés ki nem kényszeríti a jelszó-visszaállítást.
2. Távoli felhasználók, akik VPN-t használnak a rendszerek eléréséhez
A legtöbb vállalatnál a távoli felhasználóknak a tartományi jelszavuktól elkülönülő hitelesítési mechanizmust kell használniuk (pl. tanúsítványalapú hitelesítés). Miután a hitelesítés megtörtént VPN-en keresztül, az előző forgatókönyvhöz hasonlóan kezelhető a helyzet.
A távoli felhasználók számára fontos kérdés, hogy végrehajthatnak-e egy rendszergazda által felügyelt jelszó-visszaállítást (ahol a rendszergazda visszaállítja a felhasználók hitelesítő adatait, és a felhasználóra bízza a jelszóváltoztatást (self-service password reset – SSPR).
Ez akkor jelent nagyobb gondot, ha a VPN-nel való bejelentkezés során a hitelesítés elsődlegesen a tartományi jelszóra támaszkodik, de a VPN nem támogatja a jelszó alaphelyzetbe állítását. Ilyen esetben, ha a szervezet az incidens bekövetkezése előtt beállította az SSPR-t, akkor sokkal könnyebben tudja kezelni a jelszó-visszaállítási folyamatot.
Ha egy szervezet nem használ SSPR-t, akkor a tömeges jelszó-visszaállítást manuálisan kell megoldania. Ezt úgy tehetik meg, hogy a felhasználók felhívják az ügyfélszolgálatot, azonosítják magukat és manuálisan végrehajtják a jelszóváltoztatást.
Olyan VPN szolgáltatásoknál, melyek nem támogatják a jelszó-visszaállítást a hitelesítési folyamat során, érdemes megfontolni a VPN hitelesítési forrásának átmigrálását a Microsoft Entra ID-re. Ez lehet ideiglenes, hogy a munkamenet megszakítható legyen a jelszó visszaállításával, vagy akár végleges, hogy pl. a feltételes hozzáférési házirendek (Conditional Access policies) előnyeit élvezhessük.
3. Elsősorban távoli felhasználók hibrid (helyszíni) azonosítással
Hibrid azonosítás esetén a szervezetnél a felhasználók és számítógépek már szinkronizálva vannak a Microsoft Entra ID-val. Ebben az esetben nem szükséges tartományban lenni a tömeges jelszó-visszaállításhoz. A Microsoft Entra ID támogatja a felhasználók flagelését, hogy a következő bejelentkezéskor visszaállítsák hitelesítő adataikat az Active Directoryhoz hasonlóan. A rendszergazdák a Microsoft Graph segítségével beállíthatják a felhasználói attribútumot “forceChangePasswordNextSignIn” vagy “forceChangePasswordNextSignInWithMfa” értékre a kívánt felhasználóknál, hogy megszakítsák a következő bejelentkezést, és lehetővé tegyék számukra a jelszavuk módosítását.
Ha a jelszóvisszaírási funkció engedélyezve van a Microsoft Entra ID-ben, és az SSPR is, akkor a MyAccount portálon vagy az SSPR portálon keresztül történő jelszó-visszaállítás biztosítja, hogy az újonnan alaphelyzetbe állított jelszó a helyszínen lesz szinkronizálva.
A leggyorsabb és legegyszerűbb módja a támadó eltávolításának az, ha a jelszó visszaírás és az SSPR már engedélyezve van, azonban vannak olyan esetek is, amikor előfordulhat, hogy egy szervezet nem szeretné használni az SSPR-t.
4. A szolgáltatásfiókokkal kapcsolatos szempontok
A soha le nem járó jelszavak akkor jelentenek problémát, ha tömeges jelszó-visszaállítást kell alkalmazni, és nincs olyan rendszer, amely az alkalmazásokat szolgáltatásfiókokhoz rendeli hozzá. Törekedni kell az összes szolgáltatásfiók, valamint a hozzájuk kapcsolódó szolgáltatások és alkalmazások ellenőrzésére. Ahol lehetséges, ezeket a fiókokat át kell helyezni csoportosan felügyelt szolgáltatásfiókokba (Group Managed Service Accounts – gMSA).
Ennek előnye, hogy a szolgáltatásfiókok kezelhetőbbé válnak, és a fiókok kevésbé lesznek leterheltek. Ez egy jó lehetőség arra is, hogy “megfelelő méretűvé” váljon a túlzottan privilegizált szolgáltatásfiók.
5. A kiemelt identitásokkal kapcsolatos szempontok
Minden kiemelt felhőalapú fiókban az adathalászat megelőzése érdekében be kell állítani az MFA-t. Emellett erősen ajánlott Just in Time (JIT) felügyeleti módszer használata, mint például a Microsoft Entra ID Privileged Identity Management (PIM). Emellett egyértelműen el kell különíteni a helyszíni és a felhőalapú felügyeletet, és minden tartományhoz külön azonosítót kell használni. A kiemelt jogosultságú helyszíni AD DS csoportokhoz tartozó identitásokat nem szabad szinkronizálni a Microsoft Entra azonosítóval. Ezzel szemben minden privilegizált felhő szerepkörnek a felhő natív identitásokhoz kell tartoznia, és azokat nem szabad szinkronizálni az AD DS-sel. A legtöbb szervezet dönthet úgy, hogy manuálisan alaphelyzetbe állítja a kiemelt jogosultságú hitelesítő adatokat a magas fokú biztonság és ellenőrizhetőség érdekében. Ebben az esetben fontos arra figyelni, hogy a jelszavak mikor lettek visszaállítva PowerShell-lel vagy a Microsoft Graph-fal, különben egyes fiókok kimaradhatnak.
Összefoglalva
A tömeges jelszó-visszaállítást megtehetjük számos módon és különböző szempontok alapján, viszont nincs olyan megoldás, ami minden szervezetre általánosítható. Azonban, ha megfelelően felkészülünk rá, akkor a folyamatot egyszerűbbé és gyorsabbá tehetjük.
