MFA ved PAM-check-out: Bekræft identiteten i det øjeblik, det betyder noget

Privilegerede konti bliver ikke kompromitteret på login-skærmen. De bliver kompromitteret efter login: når en session bliver kapret, en enhed bliver efterladt ulåst, eller legitimationsoplysninger bliver delt lidt for skødesløst. Det er det hul, MFA ved PAM-check-out er bygget til at lukke: I stedet for at stole på den, der allerede er inden for perimeteren, bekræfter Devolutions nu identiteten igen, lige i det øjeblik nogen anmoder om adgang til en privilegeret konto.

Problemet, som MFA ved check-out løser

Almindelig MFA ved login beviser, hvem der godkendte sig ved dagens begyndelse. Den beviser ikke, hvem der sidder ved tastaturet en time senere, når en anmodning om privilegeret check-out kommer ind. For følsomme konti — domæneadministratorer, tjenestekonti, alt med udvidede rettigheder — betyder det hul noget. Kravet om en ny MFA-kontrol i det præcise øjeblik, check-outen sker, lukker det: Bekræftelsen følger nu selve adgangsanmodningen og ikke kun det første login.

Aktivering af MFA ved check-out

I Devolutions Server:

1. Sørg for, at brugerne har en MFA-metode konfigureret, enten pr. bruger (Administration – Users – Multifactor) eller håndhævet globalt via Administration – Configuration – Server Settings – Security – Conditional Access Policies (sæt MFA-målet til Required, Optional per user eller Skipped).
2. Åbn egenskaberne for PAM-udbyderen eller posten, og gå til fanen Checkout policy.
3. Aktivér muligheden for at kræve MFA ved check-out.
4. Gem. Kravet gælder, næste gang posten bliver checket ud.

I Devolutions Cloud: Den samme logik gælder via Administration – Configuration – Security – Authentication, hvor MFA-bekræftelse kan aktiveres ved start af følsomme poster. Understøttede metoder omfatter e-mail og TOTP, og flere identitetsudbydere er dækket gennem platformens bredere MFA-muligheder (Yubikey, Duo, Radius og andre, afhængigt af din opsætning).

Hvad der sker, når en bruger tjekker en konto ud

Selve check-out-forløbet ændrer sig ikke på overfladen: En bruger vælger posten, vælger en varighed og angiver en begrundelse eller et sagsnummer, hvis det er påkrævet. Det nye sker lige der, før anmodningen overhovedet kommer videre. Hvis MFA er påkrævet for den post, skal brugeren bekræfte sig — med en TOTP-kode, en kode sendt på e-mail eller SMS — som en del af indsendelsen af anmodningen. Uden gyldig MFA når anmodningen aldrig frem til godkenderen: Identiteten bekræftes ved kilden i stedet for at blive tilføjet bagefter.

Hvad godkenderen ser

Godkenderne skal ikke gætte på, om identiteten blev bekræftet. Når en check-out-anmodning når frem til dem til gennemgang, er MFA-bekræftelsen allerede sket — anmoderen kunne ikke have indsendt anmodningen uden den. Godkendelsesskærmen afspejler det, så godkenderen har én usikkerhed mindre i beslutningen og ét datapunkt mere i revisionssporet, hvis check-outen senere bliver gennemgået.

Hvorfor det betyder noget

MFA ved check-out erstatter ikke godkendelser, sessionsoptagelse eller dine eksisterende check-out-politikker. Den ligger ved siden af dem som endnu et kontrolpunkt, placeret præcis der, hvor risikoen er højest: i det øjeblik nogen får adgang til en privilegeret konto. For teams, der allerede bruger Devolutions PAM, er det en politikindstilling, du slår til, ikke et nyt system, der skal udrulles.

Hvis du kører Devolutions PAM, er det værd at slå til. Se dokumentationen nedenfor for den fulde opsætning, og fortæl os, hvordan det virker for dit team.

Ressourcer:

• Multifaktorgodkendelse – Devolutions Server
• Politikker for betinget adgang – Devolutions Server
• Check-out-politikker – Devolutions Server
• Godkendelse – Devolutions Cloud
• Multifaktorgodkendelse – portalen til Devolutions Cloud
• Check-out-politikker – Devolutions Cloud