Hoe stoppen Conditional Access en PIM aanvallen werkelijk?

Wachtwoordbeleid stopt gisaanvallen. Het doet niets tegen een gestolen sessietoken, een ge-phished MFA-prompt of een permanent admin-account dat twee jaar lang met Global Administrator-rechten actief is. Conditional Access en Privileged Identity Management (PIM) zijn de twee Azure AD / Entra ID-besturingselementen die deze gaten werkelijk aanpakken, en zij werken het beste samen.

Wat Conditional Access onder de motorkap doet

Conditional Access is een als-dit-dan-dat-engine die op aanmeldingstijd wordt geëvalueerd. De "als"-kant (signalen) omvat lidmaatschap van gebruiker/groep, compatibiliteitsstatus van apparaat, netwerklocatie, aanmeldingsrisico (van Identity Protection), toepassing die wordt geopend en clientapp-type (browser vs. oudere protocol). De "dan"-kant (besturingselementen) omvat: MFA vereisen, een compatibel apparaat vereisen, een goedgekeurde client-app vereisen, toegang volledig blokkeren of acceptatie van gebruiksvoorwaarden vereisen.

Een beleid dat in bijna elke tenant belangrijk is: oudere verificatie blokkeren. Protocollen zoals POP, IMAP en oudere SMTP ondersteunen moderne MFA-challenges niet, dus zijn zij het eerste wat credential-stuffing-tools proberen. Controleer aanmeldingslogboeken gefilterd op "Client App = Other clients" voordat je blokkeert — je zult vaak een oudere scanner of een oude multifunctionele printer vinden die nog steeds met basic auth verifieert.

Een tweede die van dag één de moeite waard is: MFA voor alle gebruikers vereisen, met een uitsluitingsgroep alleen voor break-glass-accounts. Beperk MFA niet tot "alleen admins." Gecompromitteerde standaardgebruikersaccounts zijn hoe aanvallers hun eerste voet tussen de deur krijgen voordat escalatie van bevoegdheden zelfs maar begint.

Aanmeldingsrisico vs. gebruikersrisico — verschillende signalen, verschillende reacties

Identity Protection (onderdeel van Entra ID P2) genereert twee aparte risicoscores en het is makkelijk om ze door elkaar te halen:

• Aanmeldingsrisico — deze specifieke verificatiepoging ziet er afwijkend uit (onmogelijke reis, anoniem IP-adres, onbekende aanmeldingseigenschappen).
• Gebruikersrisico — dit account is gemarkeerd om een reden gekoppeld aan de identiteit zelf (gelekte inloggegevens gevonden in een inbreukenverzameling, bevestigde compromitteringsactiviteit).

Een Conditional Access-beleid dat reageert op aanmeldingsrisico moet doorgaans met MFA uitdagen — als de echte gebruiker de uitdaging kan voltooien, laat hen door. Een beleid dat reageert op gebruikersrisico moet een wachtwoordreset forceren, omdat MFA alleen niet helpt als de inloggegevens zelf al zijn aangetast.

Waarom permanent admin-toegang het grotere probleem is

Zelfs met waterdicht Conditional Access is een account dat permanent Global Administrator bezit een doelwit dat duidelijk in de directory ligt. Iedereen die het compromitteert erft volledige tenantcontrole zonder extra stap. PIM verwijdert het "permanent"-gedeelte.

Met PIM worden admin-rollen toegewezen als geschikt in plaats van actief. De gebruiker moet de rol expliciet activeren, wat een vereiste toelichting, optionele goedkeuringswerkstroom, MFA-herbevestiging en een tijdsgebonden venster triggert — meestal 1 tot 8 uur — waarna de rol automatisch wordt gedeactiveerd. Niemand, inclusief de eigenaar van het account, heeft permanent Global Admin tenzij zij het actief gebruiken.

Een minimale PIM-configuratie die werkelijk bruikbaar is

• Elke rol boven Helpdesk Administrator: geschikt, niet permanent.
• Global Administrator en Privileged Role Administrator: goedkeuring vereisen van een tweede admin, niet alleen zelfactivering.
• Activerings-MFA vereist, geen uitzonderingen.
• Maximale activatieduur van 4 uur forceert mensen opnieuw te activeren voor werkelijk aparte werksessies, wat ook schonere audittrails oplevert.
• Toegangsbeoordelingen elke 90 dagen op alle geschikte toewijzingen — accounts worden voor één project toegevoegd en nooit verwijderd.

Waar teams dit fout doen

De meest voorkomende mislukking is niet beleidsontwerp, het is de uitsluitingslijst. Een Conditional Access-beleid met een steeds groter wordende "sluit deze gebruikers uit omdat de app MFA niet ondersteunt"-groep sluit uiteindelijk de helft van de tenant uit. Houd uitsluitingen bij als backlog-item met een eigenaar en een verwijderingsdatum, niet als permanente verzameling.

De tweede mislukking is break-glass-accounts die niet werkelijk zijn getest. Twee noodaccounts, uitgesloten van Conditional Access en PIM, met lange willekeurige wachtwoorden offline opgeslagen en waarschuwingen bij elke aanmelding — en iemand zou er elk kwartaal in moeten inloggen om te bevestigen dat zij nog steeds werken.

Conditional Access en PIM zijn niet een vinkje voor een complianceaudit. Zij zijn het verschil tussen een ge-phished inloggegevens die een ongemak zijn en het zijn een volledige tenantcompromittering. Als je identiteitsbesturingselementen in kaart brengt als onderdeel van een Blue Team-opbouw, dekken Korra Studio's Cloud- en Blue Team-segmenten de detectiekant — wat Identity Protection-risicobeurtenissen werkelijk in Sentinel uitzien en hoe je waarschuwt op onmogelijke PIM-activeringspatronen.