Zugriffe statt Benutzerkonten personalisieren Privileged Identity Management beseitigt Risiken persönlicher Accounts

Autor / Redakteur: Jochen Koehler, Cyber-Ark / Stephan Augsten

Privileged Identity Management ermöglicht es, einheitliche Richtlinien zur Verwaltung privilegierter Benutzerkonten in der IT zu definieren und zu überwachen. Statt persönlicher Benutzerkonten gibt es einen personalisierten Zugriff. Benutzer kommen dann nicht mehr direkt mit den Konten in Berührung.

Spielwiese: Im Falle privilegierter Konten lässt sich die Nutzeridentität nur schwer nachvollziehen.
Spielwiese: Im Falle privilegierter Konten lässt sich die Nutzeridentität nur schwer nachvollziehen.

In einer typischen IT-Umgebung gibt es Hunderte oder gar Tausende von Servern, Datenbanken, Netzwerkelementen sowie Applikationen. Alle werden durch eine Vielzahl privilegierter und gemeinsam genutzter Konten verwaltet.

Privilegierte Benutzerkonten verfügen über weitreichende Berechtigungen und werden von vielen IT-Mitarbeitern zur Administration genutzt. Deshalb werden die mit ihnen verbundenen Passwörter auch nur äußerst selten geändert.

Typische Beispiele für privilegierte Konten sind „root“ und „oracle“ bei Unix/Linux, Administrator bei Windows, Cisco Enable, Oracle database system/sys, MSSQL SA und einige mehr. Zu den „Privilegien“ gehören etwa der Zugriff auf vertrauliche Informationen, die Installation und Ausführung von Applikationen und die Veränderung von Konfigurationseinstellungen.

Die drohende Gefahr des Machtmissbrauchs

Der verantwortungsvolle Umgang mit diesen privilegierten Konten und ein Zugriffsmanagement, das die Sicherheitsrisiken beseitigt, sind vielfach aber noch die Ausnahme. Die Gefahren, die sich dabei ergeben, liegen auf der Hand:

  • Über privilegierte Benutzerkonten ist ein unbeschränkter Zugriff auf eine Vielzahl von Systemen möglich. Missbrauch bedeutet dabei nicht zwingend einen Hackerangriff von außen. Das kann auch ein Mitarbeiter sein, der in der Zwischenzeit die Abteilung wechselte und noch Zugriff auf privilegierte Konten hat.
  • Ein weiteres Problem besteht darin, dass es bei gemeinsam verwendeten Benutzerkonten (Shared Accounts) keine Nachvollziehbarkeit gibt. Hat eine größere Gruppe von Administratoren Zugriff auf Passwörter, lässt sich nicht eindeutig und revisionssicher feststellen, wer eine privilegierte Benutzerkennung wann und wozu verwendet hat.

Diese Shared Accounts stellen für jedes Unternehmen ein erhebliches Sicherheitsrisiko dar. Vielfach sind sie deshalb bestrebt, diese Accounts zu eliminieren. Jedem Administrator einen eigenen personalisierten Account einzurichten, stellt jedoch auch keine Lösung dar. Denn dies würde zur Folge haben, dass gegebenenfalls Hunderte, oft sogar Tausende Accounts geschaffen werden müssten, deren Verwaltung extrem aufwändig und kostenintensiv wäre.

Eine einfach zu implementierende und zu verwaltende Alternative hierzu ist eine Privileged-Identity-Management-Variante, die einen anderen Lösungsansatz verfolgt: nämlich die Personalisierung des Zugriffs auf Accounts und nicht die Personalisierung des Kontos selbst.

Wie sich Superuser-Konten schützen lassen

Beispielhaft lassen sich die Herausforderungen – und auch eine Lösung – an Unix zeigen. Der Superuser mit dem Konto „root“ oder „oracle“ für die Datenbanken wird oft durch Benutzerkonten ersetzt, die dann von einer größeren Gruppe von Entwicklern, Datenbank- oder anderen Administratoren genutzt werden können.

Diese Konten fungieren dann wie der Generalschlüssel zu allen missionskritischen Systemen. Der Schutz dieser Passwörter vor zufälligem oder absichtlichem Missbrauch hat absolute Priorität. Eine Lösung muss vier zentrale Anforderungen erfüllen:

Personalisierung gemeinsam genutzter privilegierter und Superuser-Konten: Damit lässt sich ermitteln, wer was wann und warum getan hat.

Sichere Verwahrung der Benutzerkonten: Die Aufbewahrung der privilegierten Konten in einem Datentresor soll dafür sorgen, dass diese zu jeder Zeit verfügbar sind. Wer Benutzerkonten in einer Excel-Datei oder in einem Briefumschlag im Tresor aufbewahrt, muss befürchten, dass es im Notfall längere Zeit dauert, bis Passwörter zurückgesetzt sind und der reguläre Betrieb weitergehen kann. Werden die privilegierten Konten dagegen in einem zentral verwalteten digitalen Tresor aufbewahrt, automatisch verwaltet, regelmäßig geändert und sind sie integraler Bestandteil eines Disaster-Recovery-Plans, lassen sich diese Einwände leicht entkräften.

Zentrale und einfach zu verwaltende Definition von Sicherheitsrichtlinien: Je umfangreicher eine IT-Infrastruktur, desto komplexer ist auch die Verwaltung der Vielzahl privilegierter Benutzerkonten. Abhilfe schafft hier eine Lösung, die eine zentrale, automatische Verwaltung ermöglicht und für eine strikte Einhaltung von Sicherheitsrichtlinien sorgt. Gleichzeitig muss es Funktionen geben, um das Vier-Augen-Prinzip, einmalige, kurzfristig gültige Passwörter oder auch ein Privileged Single-Sign-on zu ermöglichen.

Revisionssichere Protokollierung: Mit einer detaillierten, revisionssicheren Protokollierung der Passwort-Nutzung und aller Zugriffe auf privilegierte Benutzerkonten können unternehmensinterne Security-Policies und gängige Compliance-Vorgaben zuverlässig erfüllt werden.

Privilegierte Identitäten ersetzen User Accounts

Einen wirksamen Schutz bieten Lösungen aus dem Bereich Privileged Identity Management, bei denen der Einsatz privilegierter Konten über einen zentral administrierten digitalen Datentresor gesteuert wird. Dieser ist klar vom Zugang zu den Mission-Critical-Informationen getrennt. Es gibt keine persönlichen Benutzerkonten mehr, wohl aber einen gesicherten persönlichen Zugang zu Betriebssystem-Funktionen und Applikationen.

Neben den privilegierten Konten auf Betriebssystemebene müssen auch die Administratorenpasswörter für Datenbanken und Applikationen beachtet werden. Hier gilt es jedoch, einen bedeutenden Unterschied zu beachten.

Während die privilegierten Benutzerkonten von Administratoren und damit von realen Menschen genutzt werden, greifen Anwendungen automatisch auf Backend-Systeme zu, die eine Authentifizierung erfordern. Meist stellt der Applikations-Server solche Software-Account-Passwörter im Programmcode, in Skripten oder in Config-Files bereit.

Die damit verbundenen Risiken sind nicht unbeträchtlich, da die Passwörter in der Regel nie geändert werden, oft im Klartext vorliegen und einer großen Zahl an Anwendern wie Applikations-Administratoren und Entwicklern zugänglich sind. Weitgehend unbemerkt erhält so ein nahezu unüberschaubarer Personenkreis die Zugriffsmöglichkeit auf unternehmenskritische Datenbestände.

Eine effektive Lösung besteht darin, die in Skripten oder Config-Files eingebetteten statischen Passwörter zu entsorgen und eine automatische Verwaltung und Änderung von Administratoren-Accounts in Anwendungen zu ermöglichen.

Passwörter sind dann nicht mehr in Anwendungen, Skripten oder Konfigurationsdateien gespeichert. Vielmehr werden die Zugangsdaten ebenfalls im zentralen digitalen Datentresor abgelegt, überprüft und verwaltet. Ein innovativer Ansatz ist es, wenn ein lokaler Caching-Proxy auf den Applikationsservern die Passwörter aus dem Datentresor abruft, verschlüsselt speichert und bereitstellt, wenn sie von der jeweiligen Anwendung benötigt werden.

Die damit einhergehenden Code-Änderungen an Skripten und Anwendungen bilden sicherlich eine beachtliche Aufgabe. Erfahrungen aus der IT-Praxis zeigen aber, dass solche Anpassungen des Programmcodes eine durchaus lösbare und keineswegs außergewöhnliche Aufgabe sind.

Jochen Koehler ist Deutschland-Chef von Cyber-Ark in Heilbronn.

(ID:30640520)