Wer steckt hinter „admin“?
Admin-Rechte sind in KRITIS unvermeidbar. Ohne sie lassen sich Systeme nicht warten, Störungen nicht beheben oder Konfigurationen ändern. Zum Risiko werden sie, wenn sie dauerhaft bestehen oder sich selbst einfache Fragen nicht mehr beantworten lassen: Wer durfte wann worauf zugreifen? Und was wurde während dieses Zugriffs gemacht?
In KRITIS-Umgebungen kann das schnell kompliziert werden: Systeme laufen rund um die Uhr, Teams arbeiten im Schichtbetrieb und nicht jeder Zugriff erfolgt vom festen Büroarbeitsplatz aus. Für Wartungen kommen externe Spezialisten hinzu und bei Störungen müssen Techniker kurzfristig auf Systeme zugreifen. Dazu kommen Service Accounts, Notfallzugänge oder gemeinsam genutzte Konten. Ein Benutzername wie „admin“ hilft bei der späteren Aufklärung wenig, wenn sich dahinter fünf interne Mitarbeiter und drei externe Dienstleister verbergen können.
Das Problem ist also nicht der Administrator an sich. Es ist die fehlende Zuordnung von Person, Berechtigung, Zeitpunkt und Aktion.
Auch regulatorisch rückt das stärker in den Fokus. NIS2 nennt Zugriffskontrolle und (wo angemessen) Multi-Faktor- oder kontinuierliche Authentifizierung ausdrücklich als Teil des Cyberrisikomanagements. Für regulierte Finanzunternehmen geht DORA noch weiter: Die technischen Standards verlangen unter anderem Least Privilege und Need-to-use und adressieren privilegierte, Notfall- und Administratorzugriffe sowie generische und gemeinsam verwendete Accounts explizit.
Für KRITIS-Unternehmen folgt daraus eine ziemlich praktische Konsequenz: MFA kann absichern, wer sich anmeldet. Sie beantwortet aber nicht, wie weit dessen Rechte reichen, wie lange sie bestehen und was damit passiert. Genau diese Lücke wird bei privilegierten Konten schnell kritisch.
Admin-Rechte brauchen ein Ablaufdatum
Besonders heikel sind Rechte, die für einen konkreten Anlass vergeben wurden und danach einfach bestehen bleiben. Ein externer Techniker braucht für eine Wartung vielleicht zwei Stunden Zugriff. Daraus müssen keine Admin-Rechte für die nächsten sechs Monate werden. Denn jeder zusätzliche Dauerzugang ist ein Zugang mehr, der gestohlen, missbraucht oder schlicht vergessen werden kann.
Wie real dieses Risiko ist, zeigt ein Fall aus dem Gesundheitswesen: Ein medizinischer Betreiber musste rund 2.000 privilegierte Zugangsdaten in einer Infrastruktur mit unter anderem 850 Servern verwalten. 2019 und 2020 trafen das Unternehmen Ransomware-Angriffe. Bei der anschließenden Analyse stellte sich heraus: Die Angreifer waren über ein kompromittiertes Konto mit privilegierten Rechten in die Systeme gelangt.
Privilegierte Konten sollten also sicherheitstechnisch anders betrachtet werden als normale User-Accounts. Wird ein solches Konto übernommen, erhält der Angreifer nicht nur Zugang zum System, sondern unter Umständen direkt weitreichende Handlungsmöglichkeiten.
Florian Kraus, General Manager der DAGMA GmbH, sieht hier eine Schwachstelle vieler Security-Konzepte: „Wir schauen bei Security sehr stark darauf, ob vor dem Login alles stimmt. Bei Admin-Zugängen müssen wir aber genauso wissen, was nach dem Login möglich ist. Wenn ein Konto praktisch überall hinkommt, hilft mir auch eine saubere Authentifizierung nur bedingt.“
Hinzu kommt ein Problem, das gerade in gewachsenen Infrastrukturen bekannt sein dürfte. „Kritisch sind oft gar nicht die wenigen Admin-Accounts, die jeder kennt“, so Kraus. „Es sind die Zugänge, die irgendwann einmal eingerichtet wurden: für einen Dienstleister, ein Projekt oder einen Notfall. Wenn niemand mehr genau weiß, warum sie noch existieren, werden sie zum Risiko.“
PAM für KRITIS: Die logische Konsequenz?
Die Konsequenz daraus ist nicht, privilegierte Zugriffe grundsätzlich zu vermeiden. Das wäre im laufenden Betrieb unrealistisch. Sie müssen aber kontrollierbar bleiben: eindeutig zugeordnet, auf das notwendige Maß begrenzt und nicht länger aktiv als erforderlich.
Privileged Access Management (PAM) schafft einen Rahmen dafür, privilegierte Zugriffe gezielter zu vergeben und ihre Nutzung nachvollziehbar zu machen.
Mit PAM lässt sich nachvollziehen, wer einen privilegierten Zugang genutzt hat und was während der Sitzung passiert ist. Gerade bei geteilten Admin-Konten oder externen Dienstleistern ist das entscheidend: Aus einem anonymen „admin“ wird wieder ein konkreter, nachvollziehbarer Zugriff.
„PAM ist kein neues Thema, das erst aus den neusten Compliance-Anforderungen entstanden ist“, sagt Kraus. „Unser Hersteller Segura® beschäftigt sich seit mehr als zwölf Jahren mit privilegierten Zugriffen. Systeme und Anforderungen verändern sich; die Grundfrage bleibt erstaunlich konstant: Wer braucht welche Rechte, für welchen Zweck und für wie lange? Mit Segura® PAM beantworten wir die meisten dieser Fragen.“
Für KRITIS sollte PAM deshalb weniger als zusätzliches Security-Tool verstanden werden. Es bietet viel mehr die Antwort auf eine grundlegende Herausforderung: Admin-Rechte sollten kein Dauerzustand sein.
(Dieser Artikel wurde mit KI modifiziert. Inhalte wurden fachlich auf Richtigkeit geprüft.)
Als Boutique-Distribution für Cybersecurity mit Sitz in Berlin und Teil der DAGMA Sp. z o.o., die 1987 in Katowice gegründet wurde, unterstützt die DAGMA GmbH mit fast 40 Jahren Markterfahrung Partner und Kunden bei der Auswahl und Umsetzung moderner Sicherheitslösungen. Das Portfolio umfasst bewusst ausgewählte europäische und internationale Hersteller mit klarer technologischer Differenzierung. Neben der Distribution bietet DAGMA umfassende Unterstützung entlang des gesamten Projektzyklus: von Presales, Consulting und Schulungen bis hin zu technischem Support.
Weitere Informationen zum Portfolio unter https://dagma.eu/de/it-security
DAGMA GmbH
Storkower Str. 115a
10407 Berlin
Telefon: +49 (30) 69206298-0
http://dagma.eu/de
Marketing
E-Mail: dagma.dach@dagma.eu
![]()