RDP-beveiligingsaudit checklist: 12 zaken om op te lossen vóór uw volgende pentest
RDP (Remote Desktop Protocol) verschijnt in de initiële toegangsfase van bijna elk groot ransomware-incident. Blootgestelde poort 3389, zwakke inloggegevens, geen MFA — aanvallers kennen het playbook. Uw volgende penetratietest zal deze problemen vinden als u deze nog niet hebt opgelost. Deze checklist vertelt u precies wat u moet repareren en hoe.
De 12-items checklist
Werk deze op volgorde door. Items 1–3 zijn kritiek; pak deze aan voordat u iets anders doet.
1. Blootgestelde RDP-poort (3389) rechtstreeks op het internet
Probleem: Uw Windows-servers accepteren RDP-verbindingen op poort 3389 vanaf het openbare internet.
Risico: Aanvallers scannen continu naar open poort 3389. Binnen enkele uren nadat een nieuwe server online komt, ontvangt deze brute-force- en credential-stuffing-aanvallen. Dit is de meest voorkomende ransomware-vector voor initiële toegang in enterprise-omgevingen.
Oplossing: Verwijder de firewallregel die binnenkomende 3389-verbindingen van het internet toestaat. Benader Windows-servers alleen via een PAM-oplossing (zoals VaultPAM) die de sessie bemiddelt — de RDP-poort blijft gesloten op de server, en de verbinding wordt uitgaand via de Connector tot stand gebracht.
2. Gedeelde admin-inloggegevens over servers heen
Probleem: Uw team gebruikt een gedeelde Administrator-account (of admin, of een enkele benoemde account) over meerdere servers, en meerdere personen kennen het wachtwoord.
Risico: Wanneer iemand vertrekt, staat u voor de onmogelijke keuze het wachtwoord te roteren en iedereen anders te verstoren, of de toegang van de vertrokken medewerker intact te laten. Wanneer u een incident hebt, kunt u niet bepalen wie welke actie heeft uitgevoerd, omdat alle activiteit aan een gedeelde account wordt toegewezen.
Oplossing: Ga over op individuele benoemde accounts voor alle bevoorrechte toegang. Gebruik een Vault om serverinloggegevens op te slaan en automatisch te roteren. Gebruik sessiebemiddeling zodat gebruikers verbinding kunnen maken zonder het daadwerkelijke wachtwoord te ontvangen — de Vault bewaart het.
3. Geen MFA op bevoorrechte accounts
Probleem: Beheerders authenticeren zich bij productiesystemen met alleen gebruikersnaam en wachtwoord.
Risico: Een enkele phishing-e-mail, inloggegevensdump of hergebruikt wachtwoord geeft een aanvaller volledige beheerdersrechten. MFA is het meest impactvolle control om aanvallen op basis van inloggegevens te stoppen.
Oplossing: Vereisen TOTP (Google Authenticator, Authy) of hardwaretoken (YubiKey, Touch ID, Windows Hello) voor elke bevoorrechte account. Verifieer afdwinging — beleidsdocumenten tellen niet; demonstreer dat een inloggingspoging zonder MFA wordt geweigerd.
4. Geen sessieopname
Probleem: Wanneer bevoorrechte sessies plaatsvinden, is er geen record van wat er in de sessie is gebeurd.
Risico: Forensische analyse na een incident is onmogelijk. Auditors kunnen niet verifiëren welke acties zijn uitgevoerd. Dreigingen van binnenuit laten geen spoor achter. Ransomware-aanvallers die admin-inloggegevens misbruiken, kunnen niet verder worden getraceerd dan de inloggebeurtenis.
Oplossing: Stuur alle bevoorrechte sessies via een PAM-oplossing die volledige sessievideo en activiteitenlogboeken opneemt (uitgevoerde opdrachten, overgedragen bestanden, klembord-inhoud). Bewaar opnamen met tamper-proof-integriteit (hashketens) gedurende minimaal 12 maanden.
5. Blijvende admin-rechten (geen JIT-toegang)
Probleem: Beheerders hebben 24/7/365 bevoorrechte toegang tot productiesystemen, zelfs als zij geen beheertaak uitvoeren.
Risico: Een aanvaller die het werkstation of de inloggegevens van een beheerder compromitteert, heeft onmiddellijke en blijvende toegang tot productie. Het aanvalsoppervlak is altijd maximaal.
Oplossing: Implementeer Just-in-Time (JIT) toegang. Rechten worden verleend voor een specifieke taak en tijdvenster, dan automatisch ingetrokken. Tussen taken heeft de account geen bevoorrechte toegang — of helemaal geen actieve account.
6. Geen doorsturen van auditlogboeken
Probleem: Servergebeurtenislogboeken (Windows Event Log, Linux auth log) bevinden zich op de server waar een aanvaller met beheerdersrechten ze kan wissen.
Risico: Een aanvaller met admin-toegang kan logboeken wissen en bewijzen van hun aanwezigheid uitwissen. Tijdens incident response kunnen kritieke forensische gegevens ontbreken.
Oplossing: Stuur alle bevoorrechte toegangsgebeurtenissen onmiddellijk naar een gecentraliseerde SIEM of onveranderbaar logboekarchief. Zorg ervoor dat de logboekdoorsturingservice als een service wordt uitgevoerd die niet kan worden gestopt zonder een waarschuwing te activeren.
7. Niet-geroteerde inloggegevens in gedeelde Vaults of spreadsheets
Probleem: Productiewachtwoorden worden opgeslagen in een gedeelde spreadsheet, een gedeelde wachtwoordmanager met meerdere gebruikers, of een IT-documentatieprogramma — en zijn niet geroost in maanden of jaren.
Risico: Ieder die ooit toegang tot die spreadsheet of wachtwoordmanager heeft gehad, is een mogelijk risico. Inloggegevens die in platte tekst worden gedeeld, zijn inloggegevens die uiteindelijk zullen lekken.
Oplossing: Verplaats alle productie-inloggegevens naar een Vault met automatische rotatie. Stel rotatieplanningen in die bij gevoeligheid passen (dagelijks voor kritieke productieaccounts, wekelijks voor andere). Configureer de Vault om inloggegevens na elke checkout te roteren.
8. Geen goedkeuringswerkstroom voor gevoelige doelen
Probleem: Elke beheerder kan op elk moment bij elke server zonder dat een ander persoon het weet of goedkeurt.
Risico: Laterale beweging door een insider threat of gecompromitteerde admin-account is ongecontroleerd. Onbedoelde wijzigingen in kritieke systemen hebben geen controle van een tweede oogenpaar.
Oplossing: Implementeer goedkeuringswerkstromen voor uw vijf meest gevoelige productiedoelen. Toegangsverzoeken vereisen gedocumenteerde goedkeuring van een tweede geautoriseerde persoon voordat de sessie begint. VaultPAM registreert het verzoek, de goedkeuring en elke actie die tijdens de goedgekeurde sessie wordt ondernomen.
9. Standaard admin-accountnamen (Administrator, admin, root)
Probleem: Uw servers gebruiken de standaard ingebouwde admin-accountnamen.
Risico: Credential-stuffing-aanvallen richten zich op standaardaccountnamen omdat deze voorspelbaar zijn. Elke Windows-server heeft een Administrator-account; aanvallers weten dit als eerste te proberen.
Oplossing: Hernoem de ingebouwde Windows Administrator-account op alle servers. Schakel op Linux directe root SSH-inloggeving uit (PermitRootLogin no in sshd_config). Maak benoemde beheerdersaccounts aan voor legitiem gebruik. Sla inloggegevens op in een Vault.
10. Geen timeout op niet-actieve sessies
Probleem: RDP-sessies blijven onbeperkt actief wanneer de gebruiker zijn bureau verlaat zonder de sessie te vergrendelen of te verbreken.
Risico: Een onbewaakt actieve sessie is een open deur. Fysiek tailgating of externe toegang tot het werkstation van de beheerder geeft volledige toegang tot elke systeem waarmee de beheerder is verbonden.
Oplossing: Configureer sessie-timeoutbeleidsregels — verbreek niet-actieve sessies na 15 minuten, meld zich af verbroken sessies na 30 minuten. Zorg voor afdwinging op zowel client- (GPO) als serverniveau. VaultPAM dwingt sessietime-outs af op het PAM-niveau, ongeacht de clientconfiguratie.
11. Alleen VPN-toegangsbeheer (geen PAM-laag)
Probleem: Uw toegangscontrolemodel is: "als u op de VPN bent, kunt u RDP naar elke server waarvoor u inloggegevens hebt."
Risico: VPN is netwerklaag-toegangsbeheer. Het beperkt niet welke servers een gebruiker kan bereiken, dwingt geen least privilege af, registreert geen sessies en vereist geen MFA per sessie. Een gecompromitteerde VPN-inloggeving geeft een aanvaller toegang tot uw gehele intern netwerk.
Oplossing: Voeg een PAM-laag boven de VPN toe (of vervang VPN-gebaseerde toegang volledig). Gebruikers authenticeren zich bij de PAM-oplossing, die op beleid gebaseerde toegang tot specifieke doelen afdwingt, MFA per sessie vereist en elke sessie registreert. De doelservers zijn niet bereikbaar via de VPN — alleen via de Connector.
12. Geen toegangsbeoordelingsproces
Probleem: Bevoorrechte toegangsrechten worden verleend maar nooit herzien. Gebruikers verzamelen tijd na verloop van tijd toegang; vertrekkers kunnen maanden na vertrek toegang behouden.
Risico: Privilege creep is een top audit-bevinding en een echt beveiligingsrisico. Inactieve accounts met bevoorrechte toegang zijn doelen van hoge waarde — aanvallers zoeken naar accounts die onlangs niet zijn aangemeld (niemand houdt toezicht).
Oplossing: Implementeer een driemaandelijks toegangsbeoordelingsproces. Exporteer de complete lijst met bevoorrechte accounts en hun toegangsrechten. Laat een aangewezen revisor bevestigen dat elke toegang nog steeds vereist en passend is. Intrek toegang die niet kan worden gerechtvaardigd. Documenteer de beoordeling met datum, naam van revisor en resultaat.
Waar u kunt beginnen
Als u zich voorbereidt op een pentest, prioriteer eerst items 1, 2 en 3 — dit zijn de meest waarschijnlijke initiële-toegangsbevindingen en het hoogste risico. Items 4, 5 en 6 zijn de meest waarschijnlijke post-exploitatiebevindingen. Items 7–12 zijn de meest voorkomende compliance audit-bevindingen.
Alle 12 items worden opgelost door een PAM-oplossing in te zetten. De pentest-bevindinglijst wordt niet korter zonder — deze wordt langer naarmate uw omgeving groeit.
VaultPAM lost al deze 12 bevindingen in één middag implementatie op. Geen agents om te installeren. Geen firewallwijzigingen nodig. Sessies worden bemiddeld via alleen-uitgaande Connectors; poort 3389 blijft gesloten.
Start gratis proefversie — zie hoe VaultPAM de top RDP pentest-bevindingen uit uw omgeving elimineert.