A minimális jogosultságon alapuló felügyeleti modellek megvalósítása

Az alábbi részlet a Rendszergazdai fiókok biztonsági tervezési útmutatójából származik, amely először 1999. április 1-jén jelent meg:

"A legtöbb biztonsággal kapcsolatos tanfolyam és dokumentáció a minimális jogosultság elve megvalósítását tárgyalja, a szervezetek azonban ritkán követik azt. Az alapelv egyszerű, és a helyes alkalmazás hatása jelentősen növeli a biztonságot, és csökkenti a kockázatot. Az alapelv szerint minden felhasználónak olyan felhasználói fiókkal kell bejelentkeznie, amely rendelkezik az aktuális feladat elvégzéséhez szükséges minimális engedélyekkel, és semmi több. Ezzel többek között védelmet nyújt a rosszindulatú kódok ellen. Ez az elv a számítógépekre és a számítógépek felhasználóira vonatkozik. "Ennek az alapelvnek az egyik oka, hogy belső kutatásra kényszerít. Meg kell határoznia például azokat a hozzáférési jogosultságokat, amelyekre egy számítógép vagy felhasználó valóban szüksége van, majd implementálnia kell őket. Sok szervezet esetében ez a feladat kezdetben sok munkának tűnhet; ez azonban elengedhetetlen lépés a hálózati környezet sikeres biztonságossá tételéhez. "Minden tartományi rendszergazda számára meg kell adnia a tartományi jogosultságokat a legkevésbé jogosultság fogalma szerint. Ha például egy rendszergazda kiemelt fiókkal jelentkezik be, és véletlenül vírusprogramot futtat, a vírus rendszergazdai hozzáféréssel rendelkezik a helyi számítógéphez és a teljes tartományhoz. Ha a rendszergazda ehelyett nemprivilegált (nemminisztratív) fiókkal jelentkezett be, a vírus sérülési hatóköre csak a helyi számítógép lenne, mert helyi számítógép-felhasználóként fut. "Egy másik példában azok a fiókok, amelyeknek tartományi szintű rendszergazdai jogokat ad meg, nem lehetnek emelt szintű jogosultságok egy másik erdőben, még akkor sem, ha az erdők között megbízhatósági kapcsolat áll fenn. Ez a taktika segít megelőzni a kiterjedt károkat, ha egy támadónak sikerül feltörnie egy felügyelt erdőt. A szervezeteknek rendszeresen auditálniuk kell a hálózatukat a jogosultságok jogosulatlan eszkalálása elleni védelem érdekében."

A következő részlet a Microsoft Windows biztonsági erőforráskészletéből származik, amelyet először 2005-ben tettek közzé:

"Mindig gondoljon a biztonságra a feladat végrehajtásához szükséges minimális jogosultságok biztosítása szempontjából. Ha egy túl sok jogosultsággal rendelkező alkalmazást feltörnek, akkor a támadó képes lehet kiterjeszteni a támadást azon túl, amit megtehetne, ha az alkalmazás a lehető legkevesebb jogosultsággal rendelkezne. Vizsgálja meg például annak a következményeit, hogy egy hálózati rendszergazda akaratlanul megnyit egy vírust megnyitó e-mail-mellékletet. Ha a rendszergazda a tartományi rendszergazdai fiókkal van bejelentkezve, a vírus rendszergazdai jogosultságokkal fog rendelkezni a tartomány összes számítógépén, és így korlátlan hozzáféréssel rendelkezik a hálózat szinte összes adatához. Ha a rendszergazda helyi rendszergazdai fiókkal van bejelentkezve, a vírus rendszergazdai jogosultságokkal rendelkezik a helyi számítógépen, így hozzáférhet a számítógépen lévő adatokhoz, és rosszindulatú szoftvereket, például kulcsütemű naplózási szoftvereket telepíthet a számítógépre. Ha a rendszergazda normál felhasználói fiókkal van bejelentkezve, a vírus csak a rendszergazda adataihoz fér hozzá, és nem fog tudni rosszindulatú szoftvereket telepíteni. Ebben a példában az e-mailek olvasásához szükséges minimális jogosultságokkal jelentősen csökken a kompromisszum lehetséges hatóköre."

A jogosultsági probléma

Az előző részletekben ismertetett alapelvek nem változtak, de az Active Directory-telepítések értékelésekor mindig azt tapasztaljuk, hogy túl sok olyan fiók kapott jogosultságot és engedélyt, amely messze meghaladja a napi munka elvégzéséhez szükséges jogosultságokat és engedélyeket. A környezet mérete befolyásolja a túlzottan nagy jogosultsággal rendelkező fiókok számát, de nem az arányt - a középméretű címtárakban több tucat fiók lehet a legmagasabb szintű jogosultsággal rendelkező csoportokban, míg a nagy telepítésekben akár több száz vagy akár több ezer is lehet. Néhány kivételtől eltekintve, függetlenül a támadó képességeinek és arzenáljának kifinomultságától, a támadók általában a legkisebb ellenállás útját követik. Csak akkor növelik az eszközhasználat és a megközelítés összetettségét, ha és amikor az egyszerűbb mechanizmusok meghiúsulnak, vagy a védők meghiúsítják őket.

Sajnos számos környezetben a legkevésbé ellenálló út a széles körű és mély jogosultságokkal rendelkező fiókok túlzott használatának bizonyult. A széles körű jogosultságok olyan jogosultságok és engedélyek, amelyek lehetővé teszik a fiókok számára, hogy meghatározott tevékenységeket hajtsanak végre a környezet nagy keresztmetszetében, például a Segélyszolgálat munkatársai olyan engedélyeket kaphatnak, amelyek lehetővé teszik számukra a jelszavak alaphelyzetbe állítását számos felhasználói fiókban.

A mély jogosultságok olyan hatékony jogosultságok, amelyek a lakosság egy szűk szegmensére vonatkoznak, például rendszergazdai jogosultságokat adnak a mérnököknek egy kiszolgálón, hogy elvégezhessenek javításokat. Sem a széles körű jogosultság, sem a mély jogosultság nem feltétlenül veszélyes, de ha a tartomány számos fiókja véglegesen széles és mély jogosultságot kap, ha csak az egyik fiók sérül, gyorsan újrakonfigurálhatja a környezetet a támadó céljaira, vagy akár az infrastruktúra nagy szegmenseinek elpusztítására is.

A pass-the-hash támadások, amelyek a hitelesítő adatok ellopására irányuló támadások egy típusa, mindenütt jelen vannak, mivel a végrehajtásukra szolgáló eszköz szabadon elérhető és könnyen használható, és mivel számos környezet sebezhető a támadásokkal szemben. A pass-the-hash támadások azonban nem az igazi probléma. A probléma lényege kettős:

1. A támadók általában egyszerűen szerezhetnek mély jogosultságot egyetlen számítógépen, majd széles körben propagálják ezt a jogosultságot más számítógépekre.
2. Általában túl sok állandó fiók rendelkezik magas szintű jogosultságokkal a számítási környezetben.

Még akkor is, ha a pass-the-hash támadások megszűnnek, a támadók egyszerűen más taktikát használnak, nem pedig egy másik stratégiát. A hitelesítő adatok ellopására szolgáló eszközöket tartalmazó kártevők telepítése helyett előfordulhat, hogy olyan kártevőket ültetnek, amelyek billentyűleütéseket naplóznak, vagy bármilyen más módszert használnak a környezetben hatékony hitelesítő adatok rögzítésére. A taktikától függetlenül a célok változatlanok maradnak: széles körű és mély jogosultsággal rendelkező fiókok.

A túlzott jogosultság megadása nem csak az Active Directoryban található sérült környezetekben. Amikor egy szervezet kifejlesztette azt a szokást, hogy a szükségesnél több jogosultságot adjon, az általában az infrastruktúra egészében megtalálható, ahogy az a következő szakaszokban is szerepel.

Az Active Directoryban

Az Active Directoryban gyakran előfordul, hogy az EA, a DA és a BA csoportok túlzott számú fiókot tartalmaznak. A szervezet EA-csoportja általában a legkevesebb tagot tartalmazza, a DA-csoportok általában a felhasználók számának szorzóját tartalmazzák az EA-csoportban, a Rendszergazdák csoportok pedig általában több tagot tartalmaznak, mint a többi csoport populációi. Ez gyakran annak a meggyőződésnek köszönhető, hogy a rendszergazdák valahogy "kevésbé kiemeltek", mint a DAs vagy az EAs. Bár az egyes csoportoknak biztosított jogok és engedélyek eltérnek egymástól, hatékonyan ugyanolyan erős csoportoknak kell tekinteni őket, mivel az egyik tag a másik kettő tagjának tekintheti magát.

Tagkiszolgálókon

Amikor sok környezetben lekérjük a helyi Rendszergazdák csoport tagságát a tagkiszolgálókon, a tagság néhány helyi és tartományi fióktól kezdve több tucat beágyazott csoportig terjed, amelyek kibontásakor több száz, akár több ezer, helyi rendszergazdai jogosultsággal rendelkező fiókot fednek fel a kiszolgálókon. A nagy tagsággal rendelkező tartománycsoportok sok esetben a tagkiszolgálók helyi Rendszergazdák csoportjába vannak ágyazva, anélkül, hogy figyelembe veszik, hogy a tartomány ezen csoportjainak tagságát módosító felhasználók rendszergazdai ellenőrzést kaphatnak minden olyan rendszer felett, amelyen a csoport egy helyi Rendszergazdák csoportba van ágyazva.

Munkaállomásokon

Bár a munkaállomások általában lényegesen kevesebb taggal rendelkeznek a helyi rendszergazdák csoportjában, mint a tagkiszolgálók, sok környezetben a felhasználók a helyi Rendszergazdák csoporthoz tartoznak a személyes számítógépeiken. Ha ez történik, akkor is, ha az UAC engedélyezve van, ezek a felhasználók fokozott kockázatot jelentenek a munkaállomásaik integritására.

Fontos

Alaposan meg kell fontolnia, hogy a felhasználók igényelnek-e rendszergazdai jogosultságokat a munkaállomásaikon, és ha igen, akkor jobb megoldás lehet egy külön helyi fiók létrehozása a számítógépen, amely a Rendszergazdák csoport tagja. Ha a felhasználók jogosultságszint-emelést igényelnek, bemutathatják a helyi fiók hitelesítő adatait a jogosultságszint-emeléshez, de mivel a fiók helyi, nem használható más számítógépek veszélyeztetésére vagy tartományi erőforrások elérésére. A helyi fiókokhoz hasonlóan azonban a helyi kiemelt fiók hitelesítő adatainak egyedinek kell lenniük; ha több munkaállomáson azonos hitelesítő adatokkal rendelkező helyi fiókot hoz létre, a számítógépeket kivonatos támadásoknak teszi ki.

Alkalmazásokban

Azokban a támadásokban, amelyekben a cél egy szervezet szellemi tulajdona, az alkalmazásokon belül nagy jogosultságokkal rendelkező fiókok célzottak lehetnek, hogy lehetővé tegyék az adatok kiszivárgását. Bár a bizalmas adatokhoz hozzáféréssel rendelkező fiókok nem kaptak emelt szintű jogosultságokat a tartományban vagy az operációs rendszerben, azok a fiókok, amelyek képesek az alkalmazás konfigurációjának módosítására vagy az alkalmazás által biztosított információkhoz való hozzáférésre, kockázatot jelentenek.

Adattárakban

Más célokhoz hasonlóan a szellemi tulajdonhoz dokumentumok és más fájlok formájában hozzáférést kérő támadók megcélzhatják a fájltárolókhoz való hozzáférést vezérlő fiókokat, a fájlokhoz közvetlen hozzáféréssel rendelkező fiókokat, vagy akár a fájlokhoz hozzáféréssel rendelkező csoportokat vagy szerepköröket. Ha például egy fájlkiszolgálót használ a szerződéses dokumentumok tárolására, és egy Active Directory-csoport használatával hozzáférést kap a dokumentumokhoz, a csoporttagság módosítására jogosult támadó feltört fiókokat adhat hozzá a csoporthoz, és hozzáférhet a szerződés dokumentumaihoz. Azokban az esetekben, amikor a dokumentumokhoz való hozzáférést olyan alkalmazások biztosítják, mint a SharePoint, a támadók a korábban ismertetett módon célba vehetik az alkalmazásokat.

A jogosultságok csökkentése

Minél nagyobb és összetettebb egy környezet, annál nehezebb kezelni és biztonságossá tenni. A kis szervezetekben a jogosultságok áttekintése és csökkentése viszonylag egyszerű javaslat lehet, de a szervezeten belül használatban lévő minden további kiszolgáló, munkaállomás, felhasználói fiók és alkalmazás hozzáad egy másik objektumot, amelyet védeni kell. Mivel a szervezet informatikai infrastruktúrájának minden aspektusát nehéz vagy akár lehetetlen is megfelelően biztonságossá tenni, először azokra a fiókokra kell összpontosítania, amelyek jogosultsága hozza létre a legnagyobb kockázatot, amelyek jellemzően az Active Directory beépített kiemelt fiókjai és csoportjai, valamint a munkaállomásokon és tagkiszolgálókon lévő kiemelt helyi fiókok.

Helyi rendszergazdai fiókok védelme munkaállomásokon és tagkiszolgálókon

Bár ez a dokumentum az Active Directory védelmére koncentrál, ahogyan már korábban is említettük, a címtár elleni támadások többsége az egyes gazdagépekkel szembeni támadásokként kezdődik. A tagrendszerek helyi csoportjainak biztonságossá tételére vonatkozó teljes irányelveket nem lehet megadni, de az alábbi javaslatok segítségével biztonságossá teheti a helyi rendszergazdai fiókokat a munkaállomásokon és a tagkiszolgálókon.

Helyi rendszergazdai fiókok védelme

A Jelenleg általános támogatásban lévő Windows összes verziójában a helyi rendszergazdai fiók alapértelmezés szerint le van tiltva, így a fiók használhatatlanná válik a hitelesítő adatok átengedésével és más hitelesítő adatokkal kapcsolatos lopási támadások esetén. Az örökölt operációs rendszereket tartalmazó vagy helyi rendszergazdai fiókokat tartalmazó tartományokban azonban ezek a fiókok a korábban ismertetett módon használhatók a biztonsági rések tagkiszolgálók és munkaállomások közötti propagálására. Ezért a tartományhoz csatlakoztatott rendszerek összes helyi rendszergazdai fiókjához a következő vezérlők használata ajánlott.

Ezeknek a vezérlőknek a végrehajtására vonatkozó részletes utasításokat a H függelék tartalmazza: A helyi rendszergazdai fiókok és csoportok védelme. A beállítások implementálása előtt azonban győződjön meg arról, hogy a helyi rendszergazdai fiókok jelenleg nem használhatók a környezetben a szolgáltatások számítógépeken való futtatásához, vagy egyéb olyan tevékenységek végrehajtásához, amelyekhez ezeket a fiókokat nem szabad használni. Ezeket a beállításokat alaposan tesztelje, mielőtt éles környezetben implementálja őket.

Helyi rendszergazdai fiókok vezérlői

A beépített rendszergazdai fiókok soha nem használhatók szolgáltatásfiókként a tagkiszolgálókon, és nem használhatók helyi számítógépekre való bejelentkezésre (kivéve csökkentett módban, amely akkor is engedélyezett, ha a fiók le van tiltva). Az itt ismertetett beállítások implementálásának célja, hogy megakadályozza az egyes számítógépek helyi rendszergazdai fiókjának használhatóságát, kivéve, ha a védelmi vezérlők először vissza lettek fordítva. Ezeknek a vezérlőknek a implementálásával és a rendszergazdai fiókok módosításokkal való figyelésével jelentősen csökkentheti a helyi rendszergazdai fiókokat megcélzó támadás sikerességének valószínűségét.

GPO-k konfigurálása a rendszergazdai fiókok korlátozására Domain-Joined rendszereken.

A tartományokban létrehozott és a munkaállomások, valamint a tagkiszolgálók szervezeti egységeihez csatolt egy vagy több csoportházirend-objektumban adja hozzá a rendszergazda fiókot az alábbi felhasználói jogokhoz a Számítógép konfigurációja\Házirendek\Windows-beállítások\Biztonsági beállítások\Helyi házirendek\Felhasználói jogok hozzárendelése részben:

• A számítógép hálózati hozzáférésének megtagadása
• Bejelentkezés megtagadása ütemezett feladatként
• Szolgáltatásként való bejelentkezés megtagadása
• Bejelentkezés megtagadása távoli asztali szolgáltatásokon keresztül

Amikor rendszergazdai fiókokat ad hozzá ezekhez a felhasználói jogosultságokhoz, adja meg, hogy a fiók címkéje alapján adja-e hozzá a helyi rendszergazdai fiókot vagy a tartomány rendszergazdai fiókját. Ha például az NWTRADERS tartomány rendszergazdai fiókját szeretné hozzáadni ezekhez a megtagadási jogosultságokhoz, írja be a fiókot NWTRADERS\Rendszergazdaként, vagy keresse meg az NWTRADERS tartomány rendszergazdai fiókját. A helyi rendszergazdai fiók korlátozásának biztosításához írja be a Rendszergazda kifejezést a csoportházirend objektumszerkesztőjének felhasználói jogosultsági beállításaiba.

Megjegyzés:

A házirendek akkor is érvényesek lesznek, ha a helyi rendszergazdai fiókokat átnevezik.

Ezek a beállítások biztosítják, hogy a számítógép rendszergazdai fiókja nem használható a többi számítógéphez való csatlakozáshoz, még akkor sem, ha véletlenül vagy rosszindulatúan engedélyezve van. A helyi rendszergazdai fiókot használó helyi bejelentkezések nem tilthatók le teljesen, és nem is érdemes ezt megtenni, mert a számítógép helyi rendszergazdai fiókja vészhelyreállítási forgatókönyvekben való használatra lett kialakítva.

Ha egy tagkiszolgáló vagy munkaállomás nem csatlakozik a tartományhoz, és nincs más rendszergazdai jogosultsággal rendelkező helyi fiók, a számítógép csökkentett módban indítható, engedélyezhető a rendszergazdai fiók, és a fiók ezután a számítógépen végzett javítások végrehajtására használható. Ha a javítás befejeződött, a rendszergazdai fiókot ismét le kell tiltani.

Helyi kiemelt fiókok és csoportok védelme az Active Directoryban

Hatodik törvény: A számítógép csak olyan biztonságos, mint a rendszergazda megbízható. - Tíz nem módosítható biztonsági törvény (2.0-s verzió)

Az itt megadott információk célja, hogy általános irányelveket adjanak az Active Directory legmagasabb jogosultságú beépített fiókjainak és csoportjainak biztonságossá tételéhez. Részletes részletes útmutatást a D függelékben is talál: Built-In rendszergazdai fiókok védelme az Active Directoryban, E függelék: Vállalati rendszergazdai csoportok védelme az Active Directoryban, F függelék: Tartománygazdák csoportjainak védelme az Active Directoryban és a G függelékben: Rendszergazdák csoportok védelme az Active Directoryban.

A beállítások implementálása előtt alaposan tesztelje az összes beállítást annak megállapításához, hogy azok megfelelnek-e a környezetének. Nem minden szervezet fogja tudni implementálni ezeket a beállításokat.

Beépített rendszergazdai fiókok védelme az Active Directoryban

Az Active Directory minden tartományában létrejön egy rendszergazdai fiók a tartomány létrehozása során. Ez a fiók alapértelmezés szerint a tartomány Tartománygazdák és rendszergazdai csoportjainak tagja, és ha a tartomány az erdő gyökértartománya, akkor a fiók a Vállalati rendszergazdák csoport tagja is. A domain helyi rendszergazdai fiókjának használata kizárólag a kezdeti telepítési tevékenységekhez, és esetleg katasztrófa utáni helyreállítási forgatókönyvekhez legyen fenntartva. Annak érdekében, hogy egy beépített rendszergazdai fiók használható legyen a javítások javítására abban az esetben, ha más fiókok nem használhatók, ne módosítsa a rendszergazdai fiók alapértelmezett tagságát az erdő egyik tartományában sem. Ehelyett útmutatást kell követnie, hogy biztonságossá tegye a rendszergazdai fiókot az erdő minden tartományában. A vezérlők végrehajtására vonatkozó részletes utasításokat a D függelék tartalmazza: Built-In rendszergazdai fiókok védelme az Active Directoryban.

Beépített rendszergazdai fiókok vezérlői

Az itt ismertetett beállítások megvalósításának célja, hogy megakadályozza az egyes tartományok rendszergazdai fiókjának (nem egy csoportnak) a használhatóságát, kivéve, ha több vezérlőt megfordítanak. Ezeknek a vezérlőknek a implementálásával és a rendszergazdai fiókok módosításokkal történő monitorozásával jelentősen csökkentheti a sikeres támadás valószínűségét a tartomány rendszergazdai fiókjának használatával. Az erdő minden tartományában található rendszergazdai fiók esetében konfigurálja az alábbi beállításokat.

"A fiók bizalmas, és nem delegálható" jelző engedélyezése a fiókon

Alapértelmezés szerint az Active Directory összes fiókja delegálható. A delegálás lehetővé teszi a számítógép vagy szolgáltatás számára, hogy a számítógép vagy szolgáltatás által hitelesített fiók hitelesítő adatait más számítógépekre mutassa be, hogy a fiók nevében szolgáltatásokat szerezzen be. Ha engedélyezi a fiók bizalmas, és nem delegálható attribútum egy tartományalapú fiókhoz, a fiók hitelesítő adatai nem adhatók meg a hálózat más számítógépeinek vagy szolgáltatásainak, ami korlátozza a delegálást használó támadásokat a fiók hitelesítő adatainak más rendszereken való használatára.

Az "Intelligens kártya szükséges az interaktív bejelentkezéshez" jelző engedélyezése a fiókban

Ha engedélyezi az intelligens kártyát egy fiók interaktív bejelentkezési attribútumához , a Windows visszaállítja a fiók jelszavát egy 120 karakteres véletlenszerű értékre. Ha ezt a jelzőt a beépített rendszergazdai fiókokra állítja, győződjön meg arról, hogy a fiók jelszava nem csak hosszú és összetett, de egyik felhasználó számára sem ismert. Az attribútum engedélyezése előtt technikailag nem szükséges intelligens kártyákat létrehozni a fiókokhoz, de ha lehetséges, az intelligens kártyákat minden rendszergazdai fiókhoz létre kell hozni a fiókkorlátozások konfigurálása előtt, és az intelligens kártyákat biztonságos helyeken kell tárolni.

Bár az intelligens kártya beállítása kötelező az interaktív bejelentkezési jelölőhöz , visszaállítja a fiók jelszavát, de nem akadályozza meg, hogy a jogosultsággal rendelkező felhasználók a fiók jelszavát ismert értékre állítsa, és a fiók nevének és új jelszavának használatával hozzáférjenek a hálózati erőforrásokhoz. Emiatt az alábbi további vezérlőket kell implementálnia a fiókon.

Csoportházirend-objektumok konfigurálása a tartományok rendszergazdai fiókjainak korlátozásához Domain-Joined rendszereken

Bár a rendszergazdai fiók letiltása egy tartományban hatékonyan használhatatlanná teszi a fiókot, további korlátozásokat kell bevezetnie a fiókra, ha a fiók véletlenül vagy rosszindulatúan engedélyezve van. Bár ezeket a vezérlőket a rendszergazdai fiók végül megfordíthatja, a cél olyan vezérlők létrehozása, amelyek lelassítják a támadó előrehaladását, és korlátozzák a fiók által okozott károkat.

Az egy vagy több csoportházirend-objektumban, amelyeket létrehoz és a munkaállomás- és tagkiszolgáló szervezeti egységekhez kapcsol az egyes tartományokban, adja hozzá az adott tartomány rendszergazdai fiókját a következő felhasználói jogokhoz a Számítógép konfigurációja\Házirendek\Windows-beállítások\Biztonsági beállítások\Helyi házirendek\Felhasználói jogok hozzárendelése alatt:

• A számítógép hálózati hozzáférésének megtagadása
• Bejelentkezés megtagadása ütemezett feladatként
• Szolgáltatásként való bejelentkezés megtagadása
• Bejelentkezés megtagadása távoli asztali szolgáltatásokon keresztül

Megjegyzés:

Ha helyi rendszergazdai fiókokat ad hozzá ehhez a beállításhoz, meg kell adnia, hogy a helyi rendszergazdai vagy tartományi rendszergazdai fiókokat konfigurálja-e. Ha például hozzá szeretné adni az NWTRADERS tartomány helyi rendszergazdai fiókját ezekhez a megtagadási jogosultságokhoz, be kell gépelnie a fiókot NWTRADERS\Rendszergazdaként, vagy meg kell keresnie az NWTRADERS tartomány helyi rendszergazdai fiókját. Ha a csoportházirend-objektumszerkesztőben beírja a rendszergazda kifejezést ezekbe a felhasználói jogosultsági beállításokba, a csoportházirend-objektumszerkesztő minden olyan számítógépen korlátozza a helyi rendszergazdai fiókot, amelyre a csoportházirend-objektumot alkalmazza.

Javasoljuk, hogy a helyi rendszergazdai fiókokat a tagkiszolgálókon és munkaállomásokon ugyanúgy korlátozza, mint a tartományalapú rendszergazdai fiókokat. Ezért általában hozzá kell adnia a rendszergazdai fiókot az erdő minden tartományához, valamint a helyi számítógépek rendszergazdai fiókját ezekhez a felhasználói jogosultsági beállításokhoz.

Csoportházirend-objektumok konfigurálása a tartományvezérlők rendszergazdai fiókjainak korlátozásához

Az erdő minden tartományában módosítani kell az alapértelmezett tartományvezérlők házirendjét vagy a tartományvezérlők szervezeti egységéhez csatolt házirendet, hogy az egyes tartományok rendszergazdai fiókját a következő felhasználói jogosultságokhoz adja hozzá a Számítógép konfigurációja\Házirendek\Windows-beállítások\Biztonsági beállítások\Helyi házirendek\Felhasználói jogok hozzárendelései területen:

• A számítógép hálózati hozzáférésének megtagadása
• Bejelentkezés megtagadása ütemezett feladatként
• Szolgáltatásként való bejelentkezés megtagadása
• Bejelentkezés megtagadása távoli asztali szolgáltatásokon keresztül

Megjegyzés:

Ezek a beállítások biztosítják, hogy a helyi rendszergazdai fiók ne legyen használható tartományvezérlőhöz való csatlakozáshoz, bár a fiók, ha engedélyezve van, helyileg bejelentkezhet a tartományvezérlőkre. Mivel ezt a fiókot csak vészhelyreállítási forgatókönyvekben szabad engedélyezni és használni, várhatóan legalább egy tartományvezérlőhöz fizikai hozzáférés lesz elérhető, vagy hogy a tartományvezérlők távoli elérésére jogosult egyéb fiókok is használhatók lesznek.

Beépített rendszergazdai fiókok naplózásának konfigurálása

Ha biztosította az egyes tartományok rendszergazdai fiókját, és letiltotta azt, a naplózást úgy kell konfigurálnia, hogy figyelje a fiók módosításait. Ha a fiók engedélyezve van, a jelszava alaphelyzetbe áll, vagy bármilyen más módosítás történik a fiókon, riasztásokat kell küldeni az AD DS felügyeletéért felelős felhasználóknak vagy csapatoknak a szervezet incidenskezelési csapatai mellett.

Rendszergazdák, tartományi rendszergazdák és vállalati rendszergazdák csoportjainak védelme

Vállalati rendszergazdai csoportok védelme

A Vállalati Rendszergazdák csoportnak, amely az Active Directory erdő gyökértartományában található, napi rendszerességgel nem szabad felhasználókat tartalmaznia, kivéve a tartomány helyi rendszergazdai fiókját, feltéve, hogy az a korábban ismertetettek szerint van megvédve, és a D függelékben: Built-In rendszergazdai fiókok védelme az Active Directoryban.

Ha EA-hozzáférésre van szükség, azokat a felhasználókat, akiknek a fiókja EA-jogosultságokat és engedélyeket igényel, ideiglenesen a Vállalati rendszergazdák csoportba kell helyezni. Bár a felhasználók magas jogosultsági szintű fiókokat használnak, a tevékenységeket naplózni kell, és lehetőleg úgy kell elvégezni, hogy egy felhasználó végrehajtja a módosításokat, egy másik felhasználó pedig megfigyeli a módosításokat, hogy minimalizálja a véletlen visszaélés vagy helytelen konfiguráció valószínűségét. A tevékenységek befejezése után a fiókokat el kell távolítani az EA-csoportból. Ez manuális eljárásokkal és dokumentált folyamatokkal, külső kiemelt identitás-/hozzáférés-kezelési (PIM/PAM) szoftverekkel vagy a kettő kombinációjával érhető el. Az Active Directoryban a kiemelt csoportok tagságának szabályozására használható fiókok létrehozására vonatkozó irányelveket a Hitelesítő adatok ellopására szolgáló vonzó fiókok című témakörben találja, a részletes utasításokat pedig az I. függelék tartalmazza: Felügyeleti fiókok létrehozása védett fiókokhoz és csoportokhoz az Active Directoryban.

A vállalati rendszergazdák alapértelmezés szerint a beépített Rendszergazdák csoport tagjai az erdő minden tartományában. A Vállalati rendszergazdák csoport eltávolítása az egyes tartományok Rendszergazdák csoportjából nem megfelelő módosítás, mert erdős vészhelyreállítási forgatókönyv esetén valószínűleg EA-jogosultságokra lesz szükség. Ha a Vállalati rendszergazdák csoportot eltávolították az erdőtartományok Rendszergazdák csoportjából, azt minden tartományban hozzá kell adni a Rendszergazdák csoporthoz, és a következő ellenőrzéseket kell végrehajtani:

• A korábban leírtaknak megfelelően a Vállalati rendszergazdák csoportnak napi szinten nem szabad felhasználókat tartalmaznia, kivéve az erdő gyökértartományának rendszergazdai fiókját, amelyet a D. függelékben leírtak szerint kell biztosítani: Built-In rendszergazdai fiókok védelme az Active Directoryban.
• Az egyes tartományokban tagkiszolgálókat és munkaállomásokat tartalmazó szervezeti egységekhez csatolt csoportházirend-objektumokban az EA-csoportot a következő felhasználói jogosultságokhoz kell hozzáadni:
  • A számítógép hálózati hozzáférésének megtagadása
  • Bejelentkezés megtagadása ütemezett feladatként
  • Szolgáltatásként való bejelentkezés megtagadása
  • Helyi bejelentkezés megtagadása
  • A távoli asztali szolgáltatásokon keresztüli bejelentkezés megtagadása.

Ez megakadályozza, hogy az EA-csoport tagjai bejelentkezhessenek a tagkiszolgálókra és munkaállomásokra. Ha a tartományvezérlők és az Active Directory felügyeletére ugrókiszolgálók szolgálnak, győződjön meg arról, hogy a ugrókiszolgálók olyan szervezeti egységben találhatók, amelyhez a korlátozó csoportházirend-objektumok nincsenek csatolva.

• A naplózást úgy kell konfigurálni, hogy riasztásokat küldjön, ha bármilyen módosítás történt az EA-csoport tulajdonságain vagy tagságán. Ezeket a riasztásokat legalább az Active Directory felügyeletéért és incidenskezeléséért felelős felhasználóknak vagy csapatoknak kell elküldeni. Emellett meg kell határoznia az EA-csoport ideiglenes feltöltésére vonatkozó folyamatokat és eljárásokat, beleértve az értesítési eljárásokat is, amikor a csoport jogszerű, végleges feltöltése megtörténik.

Tartományi rendszergazdák csoportjainak védelme

A Vállalati rendszergazdák csoporthoz hasonlóan a tartományi rendszergazdák csoporttagságára csak buildelési vagy vészhelyreállítási forgatókönyvekben lehet szükség. A tartomány helyi rendszergazdai fiókjának kivételével nem lehetnek napi szintű felhasználói fiókok a DA-csoportban, ha az a D függelékben leírtak szerint lett biztosítva : Built-In rendszergazdai fiókok védelme az Active Directoryban.

Ha da-hozzáférésre van szükség, az ilyen szintű hozzáférést igénylő fiókokat ideiglenesen a szóban forgó tartomány DA-csoportjába kell helyezni. Bár a felhasználók magas jogosultsági szintű fiókokat használnak, a tevékenységeket naplózni kell, és lehetőleg úgy kell elvégezni, hogy egy felhasználó végrehajtja a módosításokat, egy másik felhasználó pedig megfigyeli a módosításokat, hogy minimalizálja a véletlen visszaélés vagy helytelen konfiguráció valószínűségét. A tevékenységek befejezése után a fiókokat el kell távolítani a Tartománygazdák csoportból. Ez manuális eljárásokkal és dokumentált folyamatokkal, külső kiemelt identitás-/hozzáférés-kezelési (PIM/PAM) szoftverekkel vagy a kettő kombinációjával érhető el. Az Active Directoryban a kiemelt csoportok tagságának szabályozására használható fiókok létrehozásának irányelveit az I. függelék tartalmazza: Felügyeleti fiókok létrehozása védett fiókokhoz és csoportokhoz az Active Directoryban.

A tartományi rendszergazdák alapértelmezés szerint a helyi Rendszergazdák csoport tagjai a saját tartományuk összes tagkiszolgálóján és munkaállomásán. Ezt az alapértelmezett beágyazást nem szabad módosítani, mert az hatással van a támogatottságra és a vészhelyreállítási lehetőségekre. Ha a Tartománygazdák csoportot eltávolították a tagkiszolgálók helyi Rendszergazdák csoportjából, akkor a csatolt csoportházirend-objektumokban található korlátozott csoportbeállítások használatával hozzá kell adni őket a tartomány minden tagkiszolgálójának és munkaállomásának Rendszergazdák csoportjához. Az F függelékben részletesen ismertetett alábbi általános vezérlőket is végre kell hajtani : Tartománygazdák csoportjainak védelme az Active Directoryban .

Az erdő minden tartományában található Tartománygazdák csoport esetében:

1. Távolítsa el az összes tagot a DA-csoportból, kivéve a tartomány beépített rendszergazdai fiókját, feltéve, hogy az a D függelékben leírtak szerint lett védve : Built-In rendszergazdai fiókok védelme az Active Directoryban.

2. Az egyes tartományok tagkiszolgálóit és munkaállomásait tartalmazó szervezeti egységekhez csatolt csoportházirend-objektumokban a DA-csoportot hozzá kell adni a következő felhasználói jogosultságokhoz:

   • A számítógép hálózati hozzáférésének megtagadása
   • Bejelentkezés megtagadása ütemezett feladatként
   • Szolgáltatásként való bejelentkezés megtagadása
   • Helyi bejelentkezés megtagadása
   • Bejelentkezés megtagadása távoli asztali szolgáltatásokon keresztül

   Ez megakadályozza, hogy a DA-csoport tagjai bejelentkezhessenek a tagkiszolgálókra és munkaállomásokra. Ha a tartományvezérlők és az Active Directory felügyeletére ugrókiszolgálók szolgálnak, győződjön meg arról, hogy a ugrókiszolgálók olyan szervezeti egységben találhatók, amelyhez a korlátozó csoportházirend-objektumok nincsenek csatolva.

3. A naplózást úgy kell konfigurálni, hogy riasztásokat küldjön, ha bármilyen módosítás történt a DA-csoport tulajdonságain vagy tagságán. Ezeket a riasztásokat legalább az AD DS felügyeletéért és incidenskezeléséért felelős felhasználóknak vagy csapatoknak kell elküldeni. Emellett be kell határoznia a DA-csoport ideiglenes feltöltésére vonatkozó folyamatokat és eljárásokat, valamint az értesítési eljárásokat, amelyek akkor lépnek életbe, amikor a csoport jogosan kerül feltöltésre.

Rendszergazdák csoportjainak védelme az Active Directoryban

Az EA- és DA-csoportokhoz hasonlóan a Rendszergazdák (BA) csoport tagságára csak buildelési vagy vészhelyreállítási forgatókönyvekben lehet szükség. A Rendszergazdák csoportban nem lehetnek napi szintű felhasználói fiókok, kivéve a tartomány helyi rendszergazdai fiókját, ha az a D függelékben leírtak szerint lett biztosítva : Built-In rendszergazdai fiókok védelme az Active Directoryban.

Ha rendszergazdai hozzáférésre van szükség, az ilyen szintű hozzáférést igénylő fiókokat ideiglenesen a szóban forgó tartomány Rendszergazdák csoportjába kell helyezni. Bár a felhasználók magas jogosultsági szintű fiókokat használnak, a tevékenységeket naplózni kell, és lehetőleg a módosításokat végrehajtó felhasználóval és egy másik felhasználóval kell elvégezni a módosításokat, hogy minimalizálják a véletlen visszaélés vagy helytelen konfiguráció valószínűségét. A tevékenységek befejezése után a fiókokat azonnal el kell távolítani a Rendszergazdák csoportból. Ez manuális eljárásokkal és dokumentált folyamatokkal, külső kiemelt identitás-/hozzáférés-kezelési (PIM/PAM) szoftverekkel vagy a kettő kombinációjával érhető el.

A rendszergazdák alapértelmezés szerint a saját tartományaikban lévő AD DS-objektumok többségének tulajdonosai. Ebben a csoportban tagságra lehet szükség olyan buildelési és vészhelyreállítási forgatókönyvekben, amelyekben tulajdonjogra vagy az objektumok tulajdonjogának átvételére van szükség. Emellett a rendszergazdák és az EA-k számos jogosultságukat és engedélyüket öröklik a Rendszergazdák csoport alapértelmezett tagsága alapján. Az Active Directoryban a kiemelt csoportok alapértelmezett beágyazását nem szabad módosítani, és minden tartomány Rendszergazdák csoportját a G függelékben leírtak szerint kell védeni : Rendszergazdák csoportok védelme az Active Directoryban, valamint az alábbi általános utasításokban.

1. Távolítsa el az összes tagot a Rendszergazdák csoportból, kivéve a tartomány helyi rendszergazdai fiókját, feltéve, hogy az a D függelékben leírtak szerint lett védve : Built-In rendszergazdai fiókok védelme az Active Directoryban.

2. A tartomány Rendszergazdák csoportjának tagjainak soha nem kell bejelentkezni a tagkiszolgálókra vagy munkaállomásokra. Az egyes tartományokban a munkaállomásokkal és tagkiszolgálókkal kapcsolt szervezeti egységekhez tartozó egy vagy több Csoportházirend-objektumban (GPOk) a Rendszergazdák csoportot a következő felhasználói jogosultságokhoz kell hozzáadni:

   • A számítógép hálózati hozzáférésének megtagadása
   • A bejelentkezés megtagadása kötegelt feladatként,
   • Szolgáltatásként való bejelentkezés megtagadása
   • Ez megakadályozza, hogy a Rendszergazdák csoport tagjai bejelentkezzenek, vagy csatlakozzanak tagkiszolgálókhoz vagy munkaállomásokhoz (hacsak először több vezérlés nem sérül meg), ahol a hitelesítő adataik gyorsítótárazódhatnak, és ezáltal veszélybe kerülhetnek. A kiemelt fiókok soha nem használhatók a kevésbé kiemelt rendszerekbe való bejelentkezéshez, és ezeknek a vezérlőknek a kényszerítése számos támadással szemben biztosít védelmet.

3. Az erdő minden tartományában a tartományvezérlők szervezeti egységénél a Rendszergazdák csoportnak a következő felhasználói jogosultságokat kell biztosítani (ha még nem rendelkeznek ezekkel a jogosultságokkal), ami lehetővé teszi a Rendszergazdák csoport tagjai számára az erdőszintű vészhelyreállítási forgatókönyvhöz szükséges funkciókat:

   • A számítógép elérése a hálózatról
   • Helyi bejelentkezés engedélyezése
   • Bejelentkezés engedélyezése távoli asztali szolgáltatásokon keresztül

4. A naplózást úgy kell konfigurálni, hogy riasztásokat küldjön, ha bármilyen módosítás történt a Rendszergazdák csoport tulajdonságain vagy tagságán. Ezeket a riasztásokat legalább az AD DS felügyeletéért felelős csapat tagjainak kell elküldeni. Riasztásokat is el kell küldeni a biztonsági csapat tagjainak, és meg kell határozni a Rendszergazdák csoport tagságának módosítására vonatkozó eljárásokat. Konkrétan ezeknek a folyamatoknak tartalmazniuk kell egy eljárást, amely biztosítja, hogy a biztonsági csapat értesítést kapjon, amikor a Rendszergazdák csoportot módosítani fogják, hogy így a riasztások küldésekor számítanak rájuk, és ne okozzanak váratlan riasztást. Emellett végre kell hajtani azokat a folyamatokat is, amelyek értesítik a biztonsági csapatot a Rendszergazdák csoport használatáról, és a használt fiókokat eltávolították a csoportból.

Megjegyzés:

Amikor korlátozásokat vezet be a rendszergazdák csoportra a csoportházirend-objektumokban, a Windows a beállításokat a tartomány Rendszergazdák csoportján túl a számítógép helyi Rendszergazdák csoportjának tagjaira is alkalmazza. Ezért a Rendszergazdák csoportra vonatkozó korlátozások végrehajtásakor körültekintően kell eljárni. Bár a Rendszergazdák csoport tagjai számára ajánlott tiltani a hálózati, köteg- és szolgáltatás-bejelentkezéseket, bár megvalósítható, ne korlátozza a helyi bejelentkezéseket vagy bejelentkezéseket távoli asztali szolgáltatásokon keresztül. Ezeknek a bejelentkezési típusoknak a letiltása blokkolhatja a számítógép jogszerű felügyeletét a helyi Rendszergazdák csoport tagjai számára. Az alábbi képernyőképen olyan konfigurációs beállítások láthatók, amelyek letiltják a beépített helyi és tartományi rendszergazdai fiókok helytelen használatát a beépített helyi vagy tartományi rendszergazdák csoportokkal való visszaélés mellett. Vegye figyelembe, hogy a Távoli asztali szolgáltatások felhasználói jogán keresztüli bejelentkezés megtagadása nem tartalmazza a Rendszergazdák csoportot, mert ha ebbe a beállításba belefoglalja, akkor a helyi számítógép Rendszergazdák csoportjának tagjai fiókok esetében is letiltaná ezeket a bejelentkezéseket. Ha a számítógépek szolgáltatásai úgy vannak konfigurálva, hogy az ebben a szakaszban ismertetett kiemelt csoportok bármelyikének környezetében fussanak, ezeknek a beállításoknak a megvalósítása a szolgáltatások és alkalmazások meghiúsulását okozhatja. Ezért az ebben a szakaszban szereplő összes javaslathoz hasonlóan alaposan tesztelje a környezet alkalmazhatósági beállításait.

Role-Based Hozzáférés-vezérlés (RBAC) az Active Directoryhoz

Általánosságban elmondható, hogy a szerepköralapú hozzáférés-vezérlés (RBAC) a felhasználók csoportosításának és az erőforrásokhoz való hozzáférés üzleti szabályokon alapuló biztosításának mechanizmusa. Az Active Directory esetében a szerepkör-alapú hozzáférés-szabályozás (RBAC) implementálása az AD DS-hez olyan szerepkörök létrehozása, amelyekhez a jogosultságokat és engedélyeket delegáljuk, hogy a szerepkör tagjai napi szintű adminisztrációs feladatokat végezhessenek anélkül, hogy indokolatlan mértékű jogosultságot kapnának. Az Active Directoryhoz készült RBAC megtervezhető és implementálható natív eszközökkel és interfészekkel, a már meglévő szoftverek használatával, külső termékek vásárlásával vagy e megközelítések bármely kombinációjával. Ez a szakasz nem nyújt részletes útmutatást az RBAC Active Directoryhoz való implementálásához, hanem azokat a tényezőket ismerteti, amelyeket érdemes megfontolnia az RBAC AD DS-telepítésekben való implementálásához.

Az Active Directory RBAC natív megközelítései

A legegyszerűbb RBAC-implementációban AD DS-csoportokként implementálhat szerepköröket, és jogosultságokat és engedélyeket delegálhat azoknak a csoportoknak, amelyek lehetővé teszik számukra a napi felügyelet elvégzését a szerepkör kijelölt hatókörén belül.

Bizonyos esetekben az Active Directoryban meglévő biztonsági csoportok a feladatfüggvénynek megfelelő jogosultságok és engedélyek megadására használhatók. Ha például az informatikai szervezet bizonyos alkalmazottai felelősek a DNS-zónák és -rekordok felügyeletéért és karbantartásáért, a felelősségek delegálása olyan egyszerű lehet, mintha minden DNS-rendszergazda számára létrehozna egy fiókot, és hozzáadja azt az Active Directory DNS-rendszergazdák csoportjához. A DNS-rendszergazdák csoport a magasabb szintű jogosultságokkal rendelkező csoportokkal ellentétben kevés hatékony jogosultsággal rendelkezik az Active Directoryban, bár a csoport tagjai delegált engedélyeket kaptak, amelyek lehetővé teszik számukra a DNS felügyeletét, és továbbra is veszélybe kerülnek, és a visszaélés a jogosultságok emeléséhez vezethet.

Más esetekben előfordulhat, hogy biztonsági csoportokat kell létrehoznia, és jogosultságokat és engedélyeket kell delegálnia Active Directory-objektumokra, fájlrendszer-objektumokra és beállításjegyzék-objektumokra, hogy lehetővé tegye a csoportok tagjainak a kijelölt rendszergazdai feladatok elvégzését. Ha például az ügyfélszolgálati operátorok felelősek az elfelejtett jelszavak alaphelyzetbe állításáért, a felhasználók csatlakozási problémáinak elhárításáért és az alkalmazásbeállítások hibaelhárításáért, előfordulhat, hogy egyesítenie kell az Active Directory felhasználói objektumainak delegálási beállításait olyan jogosultságokkal, amelyek lehetővé teszik, hogy a Help Desk-felhasználók távolról csatlakozzanak a felhasználók számítógépéhez a felhasználók konfigurációs beállításainak megtekintéséhez vagy módosításához. Minden definiált szerepkörhöz meg kell határoznia a következőket:

1. A szerepkör tagjai mely tevékenységeket hajtják végre naponta, és mely tevékenységeket ritkábban hajtják végre.
2. Mely rendszereken és mely alkalmazásokban kell jogokat és engedélyeket adni egy szerepkör tagjainak.
3. Mely felhasználóknak kell tagságot biztosítani egy szerepkörben.
4. A szerepkör-tagságok kezelésének menete.

Számos környezetben kihívást jelenthet az Active Directory-környezetek felügyeletére szolgáló szerepköralapú hozzáférés-vezérlők manuális létrehozása. Ha egyértelműen meghatározott szerepkörei és feladatai vannak az informatikai infrastruktúra felügyeletéhez, érdemes lehet további eszközöket használnia a kezelhető natív RBAC-környezet létrehozásához. Ha például a Forefront Identity Manager (FIM) használatban van a környezetben, a FIM használatával automatizálhatja a felügyeleti szerepkörök létrehozását és populációját, ami megkönnyíti a folyamatos felügyeletet. Ha a Microsoft Endpoint Configuration Managert és a System Center Operations Managert (SCOM) használja, alkalmazásspecifikus szerepkörökkel delegálhat felügyeleti és figyelési funkciókat, valamint konzisztens konfigurációt és naplózást kényszeríthet ki a tartomány rendszerei között. Ha nyilvános kulcsú infrastruktúrát (PKI) implementált, intelligens kártyákat állíthat ki és igényelhet a környezet felügyeletéért felelős informatikai személyzet számára. A FIM Credential Management (FIM CM) használatával a rendszergazdai munkatársak szerepköreinek és hitelesítő adatainak felügyeletét is kombinálhatja.

Más esetekben előnyösebb lehet, ha a szervezet fontolóra veszi a külső RBAC-szoftverek üzembe helyezését, amelyek "házon kívül" funkciót biztosítanak. Az Active Directoryhoz, a Windowshoz és a nem Windows-címtárakhoz és operációs rendszerekhez készült RBAC kereskedelmi, off-the-shelf (COTS) megoldásait számos gyártó kínálja. A natív megoldások és a külső termékek közötti választáskor a következő tényezőket kell figyelembe vennie:

1. Költségvetés: Ha az RBAC fejlesztésébe olyan szoftverekkel és eszközökkel fektet be, amelyeket már birtokolhat, csökkentheti a megoldás üzembe helyezésének szoftverköltségeit. Ha azonban nem rendelkezik natív RBAC-megoldások létrehozásában és üzembe helyezésében jártos munkatársakkal, előfordulhat, hogy tanácsadási erőforrásokat kell bevonnia a megoldás fejlesztéséhez. Gondosan mérlegelje az egyéni fejlesztésű megoldások várható költségeit a "házon kívül" megoldások üzembe helyezésének költségeivel, különösen akkor, ha a költségvetése korlátozott.
2. Az informatikai környezet összetétele: Ha a környezet elsősorban Windows-rendszerekből áll, vagy ha már használja az Active Directoryt a nem Windows rendszerű rendszerek és fiókok kezelésére, az egyéni natív megoldások optimális megoldást nyújthatnak az Igényeinek. Ha az infrastruktúra számos olyan rendszert tartalmaz, amelyek nem Windows rendszert futtatnak, és nem az Active Directory felügyeli, előfordulhat, hogy a nem Windows rendszerű rendszerek felügyeletének lehetőségeit az Active Directory-környezettől elkülönítve kell megfontolnia.
3. Jogosultsági modell a megoldásban: Ha egy termék a szolgáltatásfiókjainak az Active Directoryban magas jogosultsági szintű csoportokba való elhelyezésére támaszkodik, és nem kínál olyan lehetőségeket, amelyek nem igényelnek túlzott jogosultságot az RBAC-szoftver számára, akkor nem csökkentette igazán az Active Directory támadási felületét, csak a címtár legjogosabb csoportjainak összetételét módosította. Ha egy alkalmazásszolgáltató nem tud olyan vezérlőket biztosítani a szolgáltatásfiókokhoz, amelyek minimalizálják a fiókok feltörésének és rosszindulatú felhasználásának valószínűségét, érdemes megfontolnia más lehetőségeket is.

Kiváltságos identitáskezelés

A kiváltságos identitáskezelés (PIM), amelyet néha kiváltságos fiókkezelésnek (PAM) vagy kiváltságos hitelesítőadat-kezelésnek (PCM) is neveznek, a kiváltságos fiókok infrastruktúrabeli kezelésének megtervezése, kialakítása és megvalósítása. Általánosságban elmondható, hogy a PIM olyan mechanizmusokat biztosít, amelyek révén a fiókok ideiglenesen megkapják az építési vagy hibajavítási feladatok ellátásához szükséges jogosultságokat és engedélyeket, ahelyett, hogy a jogosultságokat véglegesen a fiókokhoz csatolnák. Akár a PIM funkciókat manuálisan hozzák létre, akár külső szoftver üzembe helyezésével implementálják, egy vagy több funkció lehet elérhető az alábbiak közül:

• Hitelesítő adatok "tárolói", ahol a kiemelt fiókok jelszavai "ki vannak véve", és hozzárendelnek egy kezdeti jelszót, majd a tevékenységek befejezésekor "be vannak jelentkezve", és ekkor a jelszavak ismét alaphelyzetbe állnak a fiókokon.
• A kiemelt hitelesítő adatok használatára vonatkozó időkorlátos korlátozások
• Egyszeri használatú hitelesítő adatok
• A munkafolyamat által létrehozott jogosultság biztosítása az elvégzett tevékenységek monitorozásával és jelentésével, valamint a jogosultság automatikus eltávolításával, ha a tevékenységek befejeződnek, vagy a kiosztott idő lejárt
• A kódolt hitelesítő adatok, például a felhasználónevek és jelszavak cseréje szkriptekben olyan alkalmazásprogramozási felületekkel (API-kkal), amelyek lehetővé teszik a hitelesítő adatok szükség szerinti lekérését a tárolókból
• Szolgáltatásfiók hitelesítő adatainak automatikus kezelése

Nem emelt szintű fiókok létrehozása emelt szintű fiókok kezeléséhez

A kiemelt fiókok kezelésének egyik kihívása, hogy alapértelmezés szerint a kiemelt és védett fiókokat és csoportokat kezelő fiókok kiemelt és védett fiókok. Ha megfelelő RBAC- és PIM-megoldásokat implementál az Active Directory-telepítéshez, a megoldások olyan megközelítéseket is tartalmazhatnak, amelyekkel hatékonyan kiürítheti a címtár legjogosultabb csoportjainak tagságát, és csak ideiglenesen és szükség esetén feltöltheti a csoportokat.

Ha azonban natív RBAC-t és PIM-et implementál, érdemes lehet olyan fiókokat létrehoznia, amelyek nem rendelkeznek jogosultsággal, és ha szükséges, az Active Directoryban csak a kiemelt csoportok feltöltésének és kiürítésének egyetlen funkciója. I. függelék: Felügyeleti fiókok létrehozása védett fiókokhoz és csoportokhoz az Active Directoryban részletes útmutatást nyújt, amelyekkel fiókokat hozhat létre erre a célra.

Robusztus hitelesítési vezérlők implementálása

Hatodik törvény: Tényleg van valaki odakint, aki próbálja kitalálni a jelszavaidat. - 10 A biztonsági adminisztráció nem módosítható törvényei

A pass-the-hash és egyéb hitelesítő adatok ellopására irányuló támadások nem jellemzőek a Windows operációs rendszerekre, és nem is újak. Az első pass-the-hash támadást 1997-ben hozták létre. Korábban azonban ezek a támadások testreszabott eszközöket igényeltek, sikerük kiszámíthatatlan volt, és a támadóknak viszonylag magas szintű jártasságra volt szükség. A hitelesítő adatokat natív módon kinyerő, szabadon elérhető, könnyen használható eszközök bevezetése exponenciális növekedést eredményezett a hitelesítő adatok ellopásával kapcsolatos támadások számában és sikerességében az elmúlt években. A hitelesítő adatok ellopására irányuló támadások azonban egyáltalán nem az egyetlen olyan mechanizmus, amellyel a hitelesítő adatok célba kerülnek és sérülnek.

Bár vezérlőket kell implementálnia a hitelesítő adatok ellopásával szembeni védelem érdekében, azonosítsa a környezet azon fiókjait is, amelyeket a támadók valószínűleg megcélznak, és robusztus hitelesítési vezérlőket implementáljon ezekhez a fiókokhoz. Ha a legtöbb kiemelt fiók egyetlentényezős hitelesítést használ, például felhasználóneveket és jelszavakat (mindkettő "valami, amit tud", ami egy hitelesítési tényező), ezek a fiókok gyengén védettek. A támadónak csak a felhasználónév és a fiókhoz társított jelszó ismeretére van szüksége, és a kivonatoló támadások nem szükségesek ahhoz, hogy a támadó felhasználóként hitelesíthesse magát az egytényezős hitelesítő adatokat elfogadó rendszereken.

Bár a többtényezős hitelesítés megvalósítása nem nyújt védelmet a pass-the-hash támadások ellen, a többtényezős hitelesítés védett rendszerekkel kombinálva is megvalósítható. A védett rendszerek implementálásáról további információt a Biztonságos felügyeleti gazdagépek implementálása című témakörben talál, a hitelesítési lehetőségeket pedig a következő szakaszok ismertetik.

Általános hitelesítési vezérlők

Ha még nem hajtott végre többtényezős hitelesítést, például intelligens kártyákat, fontolja meg ezt. Az intelligens kártyák a privát kulcsok hardveresen kikényszerített védelmét valósítják meg egy nyilvános-privát kulcs párban, megakadályozva a felhasználó titkos kulcsának elérését vagy használatát, kivéve, ha a felhasználó a megfelelő PIN-kódot, pin-kódot vagy biometrikus azonosítót adja meg az intelligens kártyának. Még akkor is, ha egy felhasználó PIN-kódját vagy pin-kódját egy kulcsleütés-naplózó elfogja egy feltört számítógépen, ahhoz, hogy a támadó újra felhasználhassa a PIN-kódot vagy a pin-kódot, a kártyának fizikailag is jelen kell lennie.

Azokban az esetekben, amikor a hosszú, összetett jelszavak a felhasználói ellenállás miatt nehezen implementálhatók, az intelligens kártyák olyan mechanizmust biztosítanak, amellyel a felhasználók viszonylag egyszerű PIN-eket vagy pin-kódokat implementálhatnak anélkül, hogy a hitelesítő adatok ne legyenek érzékenyek a találgatásos vagy szivárványtáblás támadásokra. Az intelligenskártya-azonosítók nem az Active Directoryban vagy a helyi SAM-adatbázisokban vannak tárolva, bár a hitelesítő adatok kivonatai továbbra is LSASS által védett memóriában tárolhatók azon számítógépeken, amelyeken intelligens kártyákat használtak a hitelesítéshez.

További vezérlési lehetőségek VIP-fiókokhoz

Az intelligens kártyák vagy más tanúsítványalapú hitelesítési mechanizmusok implementálásának másik előnye, hogy a hitelesítési mechanizmus garanciával védhetők a VIP-felhasználók számára elérhető bizalmas adatok. A hitelesítési mechanizmus garanciái olyan tartományokban érhetők el, ahol a működési szint a Windows Server 2012 vagy a Windows Server 2008 R2 rendszerre van állítva. Ha engedélyezve van, a hitelesítési mechanizmus garanciája rendszergazda által kijelölt globális csoporttagságot ad hozzá a felhasználó Kerberos-jogkivonatához, amikor a felhasználó hitelesítő adatai tanúsítványalapú bejelentkezési módszerrel hitelesítve vannak a bejelentkezés során.

Ez lehetővé teszi, hogy az erőforrás-rendszergazdák a használt tanúsítvány típusán kívül az erőforrásokhoz, például fájlokhoz, mappákhoz és nyomtatókhoz való hozzáférést is szabályozhatják attól függően, hogy a felhasználó tanúsítványalapú bejelentkezési módszerrel jelentkezik-e be. Ha például egy felhasználó intelligens kártya használatával jelentkezik be, a felhasználó hozzáférése a hálózaton lévő erőforrásokhoz másként határozható meg, mint amikor a felhasználó nem használ intelligens kártyát (vagyis amikor a felhasználó felhasználónév és jelszó megadásával jelentkezik be). A hitelesítési mechanizmus garanciával kapcsolatos további információkért tekintse meg az AD DS hitelesítési mechanizmusának garanciáit a Windows Server 2008 R2-ben, részletes útmutatóban.

Emelt szintű fiókhitelesítés konfigurálása

Az Active Directoryban az összes felügyeleti fiók esetében engedélyezze az Intelligens kártya megkövetelése interaktív bejelentkezési attribútumot, és ellenőrizze a fiók Fiók lapján (például cn, name, sAMAccountName, userPrincipalName és userAccountControl) található bármely attribútum módosítását.

Bár az intelligens kártya megkövetelése a fiókokon való interaktív bejelentkezéshez 120 karakteres véletlenszerű értékre állítja vissza a fiók jelszavát, és intelligens kártyákat igényel az interaktív bejelentkezésekhez, az attribútumot továbbra is felülírhatják a felhasználók olyan engedélyekkel, amelyek lehetővé teszik számukra a jelszavak módosítását a fiókokon, és a fiókok ezután használhatók nem interaktív bejelentkezések létrehozására csak felhasználónévvel és jelszóval.

Más esetekben az Active Directoryban lévő fiókok konfigurációjától és az Active Directory tanúsítványszolgáltatások (AD CS) tanúsítványbeállításaitól vagy egy külső PKI-hez tartozó egyszerű felhasználónév (UPN) attribútumtól függően a rendszergazdai vagy a VIP-fiókok egy adott típusú támadásra lehet célozni, az itt leírtak szerint.

UPN-eltérítés tanúsítványhamisításhoz

Bár a nyilvános kulcsú infrastruktúrák (PKI-k) elleni támadások alapos megvitatása kívül esik a dokumentum hatókörén, a nyilvános és magánjellegű PKI-k elleni támadások exponenciálisan növekedtek 2008 óta. A nyilvános PKI-k megsértését széles körben nyilvánossá tették, de a szervezet belső PKI-je elleni támadások talán még hatékonyabbak. Az egyik ilyen támadás az Active Directory és a tanúsítványok használatával teszi lehetővé, hogy a támadó más fiókok hitelesítő adatait olyan módon hamisítsa meg, amely nehezen észlelhető.

Amikor egy tartományhoz csatlakoztatott rendszer hitelesítéséhez tanúsítványt mutatnak be, a tanúsítvány Tárgy vagy Tárgy alternatív név (SAN) attribútumának tartalma használatos a tanúsítvány egy felhasználói objektumhoz való leképezéséhez az Active Directoryban. A tanúsítvány típusától és létrehozásának módjától függően a tanúsítvány Tulajdonos attribútuma általában egy felhasználó közös nevét (CN) tartalmazza, ahogyan az az alábbi képernyőképen látható.

Az Active Directory alapértelmezés szerint úgy hozza létre a felhasználó CN-jét, hogy összefűzi a fiók vezetéknevét + " " + vezetéknevét. Az Active Directoryban lévő felhasználói objektumok CN-összetevői azonban nem kötelezők vagy garantáltan egyediek, és a felhasználói fiók más helyre való áthelyezése a címtárban megváltoztatja a fiók megkülönböztető nevét (DN), amely a címtárban található objektum teljes elérési útja, ahogyan az az előző képernyőkép alsó paneljén látható.

Mivel a tanúsítvány tulajdonosnevei nem garantáltan statikusak vagy egyediek, a tulajdonos alternatív neve tartalma gyakran használatos a felhasználói objektum Active Directoryban való megkereséséhez. A vállalati hitelesítésszolgáltatók (Active Directory integrált hitelesítésszolgáltatók) által a felhasználók számára kibocsátott tanúsítványok SAN-attribútuma általában a felhasználó UPN-jét vagy e-mail-címét tartalmazza. Mivel az UPN-k garantáltan egyediek egy AD DS-erdőben, a felhasználói objektumok UPN-sel való keresése általában a hitelesítés részeként történik, a hitelesítési folyamatban részt vevő tanúsítványokkal vagy anélkül.

Az UPN-k san attribútumokban való használatát a hitelesítési tanúsítványokban a támadók kihasználhatják a hamis tanúsítványok beszerzéséhez. Ha egy támadó feltört egy fiókot, amely képes UPN-eket olvasni és írni a felhasználói objektumokon, a támadás a következőképpen történik:

A felhasználói objektum (például a VIP-felhasználó) UPN attribútuma ideiglenesen más értékre módosul. A SAM-fióknév attribútum és a CN jelenleg is módosítható, bár ez általában nem szükséges a korábban ismertetett okok miatt.

A célfiók UPN attribútumának módosításakor a rendszer egy elavult, engedélyezett felhasználói fiókot vagy egy frissen létrehozott felhasználói fiók UPN-attribútumát a célfiókhoz eredetileg hozzárendelt értékre módosítja. Az elavult, de még aktív felhasználói fiókok olyan fiókok, amelyek hosszú ideje nem jelentkeztek be, de nem kerültek letiltásra. A támadók a következő okokból "észrevétlen próbálnak maradni":

1. Mivel a fiók engedélyezve van, de a közelmúltban nem használták, a fiók használata nem valószínű, hogy a letiltott felhasználói fiók engedélyezéséhez hasonló riasztásokat vált ki.
2. A meglévő fiókok használatához nincs szükség új felhasználói fiók létrehozására, amelyet a rendszergazdai személyzet észrevehet.
3. Az elavult felhasználói fiókok, amelyek továbbra is engedélyezve vannak, általában különböző biztonsági csoportok tagjai, és hozzáférést kapnak a hálózaton lévő erőforrásokhoz, leegyszerűsítve a hozzáférést és a meglévő felhasználói sokasághoz való "beolvadást".

Az a felhasználói fiók, amelyen a cél UPN konfigurálva lett, egy vagy több tanúsítványt kér az Active Directory Tanúsítványszolgáltatásoktól.

Amikor tanúsítványokat szereztek a támadó fiókjához, a rendszer visszaadja az "új" fiók upN-eit és a célfiókot az eredeti értékükre.

A támadó most már rendelkezik egy vagy több tanúsítvánnyal, amelyek az erőforrások és alkalmazások hitelesítéséhez úgy jelenhetnek meg, mintha a felhasználó az a VIP-felhasználó, akinek a fiókját ideiglenesen módosították. Bár a dokumentumok hatókörén kívül esik a tanúsítványok és AKI-k célba vételével kapcsolatos összes módszer teljes körű megvitatása, ez a támadási mechanizmus azt mutatja be, hogy miért érdemes figyelnie a kiemelt és a VIP-fiókokat az AD DS-ben a módosításokért, különösen a fiók Fiók lapján található bármely attribútum módosítása esetén (például: cn, name, sAMAccountName, userPrincipalName és userAccountControl). A fiókok monitorozása mellett korlátoznia kell, hogy ki módosíthatja a fiókokat a lehető legkisebb rendszergazdai felhasználókra. Hasonlóképpen, a rendszergazda felhasználók fiókjait is védeni és figyelni kell a jogosulatlan módosítások esetén.