Active Directory Certificate Services: prednostne naloge pri penetracijskem testu in odprava tveganj

Pregled virov: 13. september 2026. Spodnji postopki in tabele so predlogi za pooblaščen pregled. Sklici utemeljujejo tehnične lastnosti in priporočila virov; ne pomenijo, da vir predpisuje točno ta obseg ali obliko evidence.

Active Directory Certificate Services (AD CS) izdaja in upravlja potrdila za avtentikacijo ter varno komunikacijo. Dovoljenja in identitetne nastavitve predlog vplivajo na to, kdo lahko potrdilo pridobi in katero identiteto lahko predstavlja. Pregled mora zato povezati nastavitve izdaje s sistemi, ki infrastrukturi javnih ključev (PKI) zaupajo. 1

Članek je namenjen skrbnikom in pooblaščenim izvajalcem varnostnih pregledov. Opisuje, kaj je smiselno preveriti v konfiguraciji in postopkih upravljanja ter kako odpraviti vzroke tveganja. Ne vsebuje navodil za zlorabo. Pri javnem besedilu je treba razlikovati med stanjem, ki smo ga v konkretnem okolju potrdili, in splošnim primerom, ki ga je treba šele preveriti. 1

Najprej določite meje zaupanja

Pregled AD CS naj se ne začne samo s seznamom strežnikov CA. Popisati je treba korensko in podrejene overitelje, izdajoča potrdilna telesa, predloge potrdil, storitve za vpis potrdil, postopke odobritve in sisteme, ki sprejemajo potrdila za prijavo, podpisovanje, šifriranje ali dostop naprav. V obseg sodijo tudi odvisnosti, kot so VPN-povezava, brezžično omrežje, Windows Hello for Business, omrežne naprave in aplikacije drugih ponudnikov. 3 1

Osrednje vprašanje je, kdo lahko pridobi posamezno vrsto potrdila, pod katerimi pogoji in kaj z njim lahko naredi sistem, ki mu zaupa. Potrdilo za spletni strežnik nima enakega pomena kot potrdilo, ki ga domena sprejme pri avtentikaciji. Predloga, pri kateri se podatki o imetniku prevzamejo iz nadzorovanega atributa imenika, potrebuje drugačen pregled kot predloga, ki vlagatelju omogoča vnos dela identitete. 3 1

Za pregled so uporabni izvoz nastavitev CA, seznam objavljenih predlog, dovoljenja predlog, nastavitve storitev za vpis, dnevniki izdanih potrdil, postopki za varnostne kopije in konfiguracija sistemov, ki potrdila preverjajo. Široka razpoložljivost predloge sama po sebi še ne pomeni pomanjkljivosti. Odločilni so predvidena uporaba, vezava identitete, odobritve in dejanski krog upravičencev. 3 1

Predloge potrdil so pravila avtorizacije

Predloge potrdil niso le administrativna podrobnost PKI. Določajo, kateri račun lahko zaprosi za potrdilo in s kakšnim namenom ga lahko uporabi. Prednost imajo objavljene predloge, ki omogočajo avtentikacijo odjemalca, delovanje agenta za vpis, upravljanje CA ali drugo širšo uporabo. 1

Pri vsaki predlogi je treba preveriti štiri stvari. Kateri uporabniki in skupine lahko potrdilo zahtevajo, samodejno pridobijo ali spremenijo predlogo? Katere razširjene uporabe ključa določajo namen potrdila? Kako se izpolnita ime imetnika in alternativno ime imetnika? Kateri pogoji veljajo za odobritev, podpis, obnovitev in veljavnost? 1

Tveganje se poveča, kadar lahko uporabnik z osnovnimi pravicami pridobi potrdilo, ki ga pomemben sistem sprejme kot identiteto drugega računa. Posebno pozornost zahtevajo možnosti, pri katerih vlagatelj določi podatke o identiteti. Enako velja za pravice, ki skrbnikom zunaj skrbništva PKI omogočajo spremembo predloge, njeno objavo ali nastavitev CA. Omejen seznam za vpis ne odpravi preširokih pravic za upravljanje predloge. Zahteva po odobritvi ne pomaga, če je obnova potrdila izvzeta iz enakega preverjanja. 1

Pri pregledu je treba upoštevati podedovana dovoljenja in članstvo v skupinah. Skupina »Authenticated Users« je lahko utemeljena pri strogo omejeni predlogi za delovne postaje, pri predlogi za avtentikacijo pa zahteva jasno odločitev lastnika storitve. Smiselno je popisati tudi predloge brez aktivne uporabe. Preverite, ali je stara predloga ohranila pravice in nastavitve iz prejšnjega projekta. 1

Preverite poti za vpis in upravljanje CA

Storitve za vpis potrdil izpostavljajo pravila uporabnikom in napravam. Preveriti je treba spletni vpis, storitve pravilnika za vpis, storitve za omrežne naprave in prilagojene portale. Preverite, ali stare komponente ostajajo omogočene brez aktualne poslovne potrebe. Če se potrdi, da niso potrebne, priporočamo njihov umik po preverjanju odvisnosti, preizkusu spremembe in odobritvi lastnika storitve. Pri preostalih je treba preveriti zaščito prenosa, meje avtentikacije, pravice storitvenih računov in omejitve pri izbiri predlog. 1

Upravljanje CA je samostojna meja z visokim vplivom. Popisati je treba račune in skupine, ki lahko upravljajo CA, odobravajo zahteve, dodeljujejo pravice uradnika, spreminjajo omejitve za agente, objavljajo predloge ali dostopajo do zasebnih ključev in varnostnih kopij. Dostop mora biti omejen, sledljiv in ločen od rednega upravljanja domene, kadar to dopušča način dela organizacije. 4

Enako pomembna je zaščita zasebnih ključev. Preveriti je treba, ali so ključi pri pomembnih CA zaščiteni s strojno opremo, kdo lahko začne varnostno kopiranje ali obnovitev, kako so kopije šifrirane in ali je obnovitveno gradivo shranjeno ločeno od CA. Pooblaščeni pregled lahko potrdi postopke in pravice brez pridobivanja ali uporabe zasebnih ključev. 4

Življenjski cikel lahko podaljša zaupanje

Pregled PKI naj zajame tudi spremembe po prvi namestitvi. Pregled naj zajame veljavnost potrdil, obnovitve, preklic, različice predlog ter postopek umika predloge ali CA. Pri vsakem ciljnem sistemu preverite odziv na spremembo računa ali vloge; sama veljavnost potrdila še ne pomeni, da je dostop še mogoč. 4

Preklic ščiti samo, če ga sistemi, ki potrdila preverjajo, lahko pridobijo in upoštevajo. Preveriti je treba objavo seznama preklicanih potrdil (CRL) in podatkov o izdajatelju, dosegljivost z ustreznih omrežij, urnik posodobitev, nadzor nad objavo in odziv odjemalcev ob nedosegljivosti. URL v potrdilu ni dokaz, da je preklic v praksi uporaben. Treba je potrditi, da ga pomembne storitve dosežejo in da skrbniki pravočasno zaznajo neuspešno objavo. 4

Popis naj vključuje potrdila privilegiranih računov, agentov za vpis, storitvenih računov in opuščenih sistemov. Namen ni množični preklic, temveč pripravljenost na nadzorovan odziv, če obstaja sum nepooblaščenega posega v nastavitve predloge ali kompromisa skrbniškega računa oziroma ključa CA. 4

Beleženje mora pomagati pri preiskavi

CA lahko beleži veliko dogodkov, vendar zapisi brez rednega pregleda ne zmanjšajo tveganja. Pomembne revizijske dogodke CA in storitev za vpis je smiselno poslati v osrednje okolje za beleženje. Zapisi naj vsebujejo vlagatelja, predlogo, serijsko številko izdanega potrdila, osebo, ki je zahtevo odobrila, izvorni sistem in rezultat zahteve. Povezati jih je treba s spremembami predlog, dovoljenj CA in članstva v skupinah. 2

Opozorila naj ciljajo dejanja, ki spreminjajo raven zaupanja: objavo nove predloge, spremembo dovoljenj za vpis ali upravljanje, uporabo agenta za vpis, neobičajno izdajo potrdila za pomembno predlogo, zamudo pri objavi CRL ter varnostno kopiranje ali obnovitev CA. Pragovi morajo odražati dejanski način uporabe. Okolje, ki dnevno izdaja več tisoč potrdil napravam, zahteva drugačna pravila kot manjša interna PKI. 2

Preizkus odziva naj zajame preklic, umik predloge in domneven kompromis ključa CA. Vnaprej je treba določiti, kdo odobri nujni preklic, kako se obvestijo sistemi, ki potrdilom zaupajo, in kako se ohrani delovanje odvisnih storitev. Postopek brez teh informacij lahko varnostni dogodek spremeni v izpad. 2

Praktičen zapis pregleda predloge

Izmišljeni primer poveže preverjanje predloge in vpisa z lastnikom, ukrepom ter dokazilom ponovnega pregleda. Oblika tabele je predlog za delo; pogoji konfiguracije izhajajo iz Microsoftovih ocen varnosti potrdil. Ugotovitev v konfiguraciji še ne dokazuje izvedenega lažnega predstavljanja. 1

Vrstni red odprave

Najprej potrdite lastnike, uporabo in odvisnosti objavljenih predlog ter storitev za vpis. Če se potrdi, da komponenta ni potrebna, priporočamo njen umik z odobreno in preizkušeno spremembo ter načrtom povrnitve. Nato omejite pravice za vpis in upravljanje predlog na najmanjše potrebne skupine. Pri predlogah za avtentikacijo naj imenik določa identitetne podatke, razen kadar obstaja dokumentiran razlog in ustrezen postopek odobritve za podatke, ki jih vnese vlagatelj. Predloge z večjo avtoriteto naj bodo namenjene točno določeni uporabi, zahteve po podpisu ali odobritvi pa naj se uporabljajo tam, kjer jih postopek lahko dejansko podpira. 1

V nadaljevanju ločite upravljanje CA od rednih skrbniških opravil, zaščitite ključe in varnostne kopije ter uvedite spremembni postopek za predloge in nastavitve CA. Spremljanje in obnovitev naj postaneta del storitve: preverjajte objavo preklicev, zbirajte revizijske dogodke in vadite odziv. 1

Ponovni pregled naj primerja objavljene predloge, dejanska dovoljenja in izdana potrdila z odobrenim načrtom. Preveri naj tudi, ali bi delegirane skupine, podedovana dovoljenja ali druge storitve za vpis lahko ponovno uvedle pomanjkljivost, ter zabeleži preverjeni obseg, rezultate in omejitve. Ponovni pregled ne zagotavlja, da se pomanjkljivost ne more ponoviti. 1

Pogosta vprašanja

Ali je AD CS pomemben samo pri uporabi pametnih kartic?

Ne. AD CS lahko podpira avtentikacijo uporabnikov, naprav, VPN-povezav, brezžičnih omrežij, strežnikov in aplikacij. Pregled naj sledi sistemom, ki potrdilom zaupajo, ne samo enemu načinu vpisa. 3 1

Ali mora vsaka predloga za avtentikacijo odjemalca zahtevati odobritev vodje?

Ne nujno. Odobritev lahko ovira avtomatizacijo in ne nadomesti pravilne vezave identitete ter omejenih dovoljenj. Uporabite jo, kadar raven zaupanja in postopek vpisa upravičujeta človeško odločitev. 1

Kateri ukrep je najboljši prvi korak?

Pripravite potrjen seznam objavljenih predlog ter razjasnite manjkajoče podatke o lastništvu in uporabi. Onemogočanje predloge priporočamo šele po potrditvi, da ni potrebna, ter preizkusu njenih odvisnosti in postopka povrnitve skupaj z lastnikom storitve. Tako postanejo preostale odločitve o avtorizaciji jasne. 1

Notranje povezave: Strokovno področje Active Directory · Vsebina o Kerberosu · Ločevanje skrbniških vlog

Sources / Viri

1. Microsoft Defender for Identity: Certificates security assessments — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
2. Joint guidance: Detecting and Mitigating Active Directory Compromises (PDF) — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
3. Microsoft: AD CS overview — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
4. Microsoft: PKI design considerations — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.

Za načrtovanje nadaljnjih ukrepov sta povezana članka Napadi NTLM Relay: Zakaj je vase omrezje odprta vrata in Ponovni varnostni pregled: od ugotovitev do preverjene odprave.