Auch maschinelle Identitäten brauchen Schutz! Sieben Arten nicht-menschlicher Identitäten und wie man sie schützt

Anbieter zum Thema

CyberArk Software (DACH) GmbH

netfiles GmbH

Cloudgermany.de GmbH

Auf jede menschliche Identität kommen inzwischen 45 nicht-menschliche Identitäten, unter anderem in Bots, IoT-Geräten, Automations­lösungen und Skripten, Cloud-Umgebungen und Anwendungen. Häufig nutzen sie privilegierte Zugangsdaten für den Zugriff auf kritische Ressourcen und benötigen daher einen besonderen Schutz. Aufgrund der großen Vielfalt nicht-menschlicher Identitäten ist das für Unternehmen allerdings mit einigen Herausforderungen verbunden.

Nicht-menschliche Identitäten, auch maschinelle Identitäten genannt, sind überall. Sie sorgen dafür, dass die unzähligen smarten Geräte, die es heutzutage gibt, untereinander und mit den zugehörigen Cloud-Services kommunizieren können. Sie garantieren, dass sich Microservices in der Cloud reibungslos austauschen und Automatisierungstools ungehindert ihren Dienst verrichten können. Und sie erlauben modernen, selbst entwickelten Enterprise-Anwendungen die Zusammenarbeit mit Kauf-Software und Legacy-Applikationen – kurz gesagt: Sie halten die digitale Welt am Laufen und sind deshalb unverzichtbar.

In den vergangenen Jahren ist die Zahl der nicht-menschlichen Identitäten aufgrund der schnell voranschreitenden Digitalisierung geradezu explodiert. In einem durchschnittlichen Unternehmen finden sich laut dem Identity Security Threat Landscape Report von CyberArk inzwischen 45-mal so viele nicht-menschliche wie menschliche Identitäten. Da knapp die Hälfte (45 Prozent) auf kritische Ressourcen zugreift, kommt dem Schutz der verwendeten Passwörter, API-Keys und anderer Secrets eine ebenso große Bedeutung zu wie dem Schutz privilegierter Zugangsdaten von menschlichen Benutzern. Dabei stellt jedoch nicht nur die schiere Menge der nicht-menschlichen Identitäten viele Unternehmen vor Herausforderungen, sondern auch ihre Vielfalt hinsichtlich verwendeter Techniken und Zugriffsvarianten.

Cloud-Umgebungen und Cloud-native Apps

Viele Unternehmen nutzen mehrere Cloud-Anbieter, um Workloads flexibel dorthin verschieben zu können, wo Performance-Anforderungen am besten erfüllt werden, die Kosten am niedrigsten sind oder spezielle Funktionen zur Verfügung stehen. Allerdings nutzt jeder Anbieter eigene Methoden für das Secrets-Management, was die Cloud-übergreifende Verwaltung erschwert. Das ist insofern problematisch, als dass in der Cloud eine Vielzahl von Secrets benötigt wird – etwa für die Automatisierung des Container-Deployments, die Kommunikation zwischen verschiedenen Microservices und die kontinuierliche Aktualisierung der Anwendungen im Rahmen von CI/CD-Prozessen (Continuous Integration/Continuous Delivery). Da Entwicklungsabteilungen oft unter Druck stehen, neue Funktionen oder Anwendungen möglichst schnell einzuführen, kann es durchaus vorkommen, dass sie Secrets hart kodiert hinterlegen oder Sicherheitsanforderungen ignorieren. Security-Teams können das verhindern, indem sie Lösungen für das Secrets-Management einsetzen, die nahtlos mit Cloud-nativen Anwendungen zusammenarbeiten und keine zusätzliche Arbeit verursachen. Gerade in Multi-Cloud-Umgebungen helfen SaaS-Lösungen, die Secrets einheitlich und zentralisiert zu verwalten und sicherzustellen, dass Anwendungen in allen Clouds funktionieren, ohne dass Entwickler Code anpassen oder Workflows umstellen müssen.

DevOps-Tools und die Software-Lieferkette

Angriffe auf die Software-Lieferkette sind bei Cyberkriminellen beliebt, weil sie auf einen Schlag unzählige Unternehmen infiltrieren können, die die Software nutzen – ein ungeschützter Zugang zu einem Code-Repository oder ein falsch konfiguriertes CI/CD-Tool reicht schon. Da in der Regel viele unterschiedliche Tools zum Einsatz kommen, die üblicherweise von Entwicklungsabteilungen ausgewählt werden, tun sich Security-Teams häufig schwer, Sicherheitsrichtlinien durchzusetzen. Zudem bringen viele Tools ein eigenes Secrets-Management mit, das unter Umständen keine Secrets-Rotation unterstützt und den Wildwuchs aus Secrets und Management-Lösungen im Unternehmen vergrößert. Security-Teams sollten deshalb eng mit Entwicklungsabteilungen zusammenarbeiten, um das Bewusstsein für die Risiken eines solchen Wildwuchses zu schärfen und Sicherheit von Anfang an in Entwicklungsprozesse zu integrieren. Dazu zählt beispielsweise, hart kodierte Secrets und Default-Passwörter zu entfernen und Passwort-Rotationen sowie Multifaktor-Authentifizierung einzuführen.

Automatisierungstools und Skripte

Automatisierungstools und Skripte sind wertvolle Helfer im Arbeitsalltag von Administratoren, Entwicklern und anderen Spezialisten, weil sie komplexe oder repetitive Aufgaben vereinfachen und viel Zeit sparen. Manche Tools und Skripte sind extrem mächtig, benötigen aber weitreichende Rechte, um zu funktionieren – sie stellen ein enormes Sicherheitsrisiko dar, insbesondere wenn Secrets fest in ihnen hinterlegt sind. Dazu kommt, dass Skripte oft kopiert, geteilt und nicht selten irgendwann vergessen werden, sodass schnell der Überblick verloren geht, wo sich welche privilegierten Zugangsdaten verstecken. Security-Teams müssen daher alles daransetzen, hart kodierte Secrets zu verhindern und die benötigten Passwörter und Co. über ein zentrales Secrets-Management zuzuweisen. Mit diesem können sie dann idealerweise auch Best Practices wie Zero Trust, Just-in-Time-Zugriffe und menschliche Freigaben umsetzen.

Software von externen Anbietern

Standardsoftware und andere von externen Anbietern bezogene Anwendungen benötigen häufig umfangreiche Rechte: IT- und Security-Tools zum Beispiel für die Überwachung und Steuerung anderer Systeme, Analytics-Tools hingegen für den Zugriff auf sensible Daten, die sie auswerten sollen. Business-Applikation wie ERP- und HR-Lösungen wiederum speichern gleich selbst sehr sensible Daten und müssen diese vor unberechtigten Zugriffen schützen. Aus diesem Grund sollten Unternehmen darauf achten, dass sich Drittanbieter-Anwendungen nahtlos in ihre Lösungen für das Secrets-Management integrieren, damit Security-Teams die Zugangsdaten zentralisiert verwalten und rotieren können. Darüber hinaus helfen Just-in-Time-Zugriffe, Risiken weiter zu reduzieren, weil die Anwendungen nicht dauerhaft auf Systeme, Anwendungen und Daten zugreifen können, sondern nur dann, wenn der Zugriff für eine konkrete Aufgabe notwendig ist. Sollten Cyberkriminelle eine Anwendung kompromittieren, haben sie nur eingeschränkte Handlungsmöglichkeiten und können sich nicht weiter innerhalb der Infrastruktur vorarbeiten.

Bots aus der Prozessautomatisierung

In vielen Unternehmen nimmt Robotic Process Automation (RPA) enorm an Fahrt auf – nicht zuletzt, weil dank komfortabler Tools inzwischen auch Fachbereichsspezialisten ohne Kenntnisse im Bereich der Software-Entwicklung, die sogenannten Citizen Developer, eigene Bots erstellen können. Diese Bots benötigen privilegierte Zugriffsrechte, um zu funktionieren, und da sie oft eigenständig – ohne menschliche Interaktion und Aufsicht – arbeiten, können die Secrets nicht manuell zu Laufzeit von einem Mitarbeiter eingegeben werden. Selbst bei beaufsichtigten Bots funktioniert die manuelle Eingabe nur bis zu einer gewissen Anzahl an Bots. Letztlich muss RPA deshalb Teil eines Secrets-Managements werden, das Secrets zentral verwaltet und rotiert.

Selbst entwickelte Legacy-Anwendungen

Die meisten Unternehmen nutzen nach wie vor eine Vielzahl selbst entwickelter Anwendungen, die in klassischen Umgebungen wie Java oder auf klassischen Betriebssystemen wie Unix laufen. Diese Anwendungen sind geschäftskritisch und müssen auf unterschiedlichste Systeme und Datenspeicher zugreifen. Dabei verfügen sie oft über (zu) hohe Berechtigungen, da sie noch aus einer Zeit stammen, da manche Entwickler ihren Anwendungen kurzerhand alle Rechte einräumten, statt für exakt angepasste Berechtigungen (Least-Privilege-Prinzip) zu sorgen. Diese oft hart kodierten Secrets aufzuspüren und zu entfernen und die Anwendungen in ein zentrales Secrets-Management zu integrieren, ist für Unternehmen die wichtigste Aufgabe in diesem Bereich – auch wenn das bisweilen aufwendig ist, weil die entsprechenden Integrationen erst entwickelt werden müssen.

Mainframe-Anwendungen

Mainfraime-Anwendungen bieten ganz ähnliche Herausforderungen wie die zuvor genannten Legacy-Anwendungen. Erschwerend kommt bei ihnen allerdings hinzu, dass ihre Prozesse in der Regel keinesfalls unterbrochen werden dürfen, da sonst Transaktionsdaten verloren gehen. Deshalb werden Passwörter häufig lokal zwischengespeichert, damit sie garantiert verfügbar sind. Binden Security-Teams Mainframe-Anwendungen in ein Secrets-Management ein, müssen sie das daher behutsam tun, um den Betrieb der Anwendungen nicht zu stören.

Ein zentralisierter Ansatz ist notwendig

Die große und schnell wachsende Menge an nicht-menschlichen Identitäten und zugehörigen Secrets können Unternehmen nur mit einem zentralisierten Secrets-Management in den Griff bekommen – andernfalls entstehen „Security-Inseln“ mit eigenen Management-Tools, die einen hohen Aufwand verursachen und durch inkonsistente Richtlinien womöglich Lücken im Schutz lassen. Zudem erleichtert ein zentralisierter Ansatz die Automatisierung, sodass sich Secrets innerhalb der gesamten Infrastruktur leichter rotieren oder entziehen lassen, wenn sie nicht mehr benötigt werden. Das Security-Team erhält einen umfassenden Überblick über alle Identitäten und Secrets und kann dank vollständiger Audit-Trails genau nachvollziehen oder nachweisen, welche Identitäten wann und mit welchen Secrets auf welche Ressourcen zugegriffen haben.

Natürlich lassen sich nicht alle nicht-menschlichen Identitäten auf einen Schlag sichern – dafür sind es zu viele. Unternehmen sollten daher Prioritäten setzen und sich zunächst auf Bereiche konzentrieren, die ein hohes Business-Risiko darstellen oder die in der Vergangenheit bereits mit Sicherheitsverletzungen zu kämpfen hatten. Ein guter Start ist erfahrungsgemäß auch die Suche nach hart kodierten Secrets oder der Dialog mit DevOps-Teams, um ihre Abläufe zu verstehen und Security-Best-Practices frühzeitig zu integrieren.

Über den Autor: Michael Kleist ist Area Vice President DACH bei CyberArk.

(ID:49950436)