Robotic Process Automation (RPA) hat sich zweifelsohne als ein Enabler für effiziente und fehlerfreie Abläufe entpuppt. Die Technologie wurde entwickelt, um die Produktivität zu steigern. Sie ist agil, um die Datenverarbeitung mit mehreren Anwendungen zu ermöglichen sowie den internen und externen Systemzugriff zu verwalten. Die Technologie hat leider aber auch einen Nachteil. Denn ganz nebenbei öffnet sie auch Türen für entsprechende Cyber-Bedrohungen. Ohne angemessene Kontrollen kann RPA zu einem Sicherheitsrisiko werden.
Rollen regeln Zugriffsrechte
Generell gibt es im Unternehmen zwei Haupttypen von Identitäten: Benutzeridentitäten und Dienstkontenidentitäten. Im Rahmen der Benutzeridentität hat jeder Benutzer eine Rolle. Rollen organisieren Personen nach ihrer Geschäftsfunktion und ihren benutzerbasierten Attributen, um zu klären, worauf die Benutzer Zugriff haben sollten. Jede Rolle kann eine oder mehrere Berechtigungen für Anwendungen haben. Berechtigungen sind zum Ausführen bestimmter Aktionen in einer Anwendung erforderlich. Wenn ein neuer Mitarbeiter in ein Unternehmen mit rollenbasierter Zugriffssteuerung kommt, wird ihm eine Rolle zugewiesen. Basierend auf der Rolle erhält er automatisch Berechtigungen bzw. Zugriff auf bestimmte Funktionen in verschiedenen Anwendungen innerhalb des Unternehmens. Sie werden dann normalerweise direkt oder über Microsoft Active Directory mit den Zielanwendungen verbunden, um diese Berechtigungen zu speichern und zu verwalten.
Bot-ID als privilegiertes Konto
Während der einfachste Weg bei einer Bot-Implementierung darin besteht, sie in einem beaufsichtigten Modus unter Verwendung der Benutzer-ID der Person durchzuführen, die den RPA-Bot ausführt, ermöglicht diese Option das Skalieren und Ausführen der Anwendung in einem unbeaufsichtigten Modus. Da in einigen Unternehmen der Benutzer aber seine Identitätsdaten angeben muss, um Bots in einem unbeaufsichtigten Modus ausführen zu können, ist die Option gefährlich. Denn sie ist mit Sicherheitslücken behaftet und hält einer Sicherheitsprüfung nicht stand.
Um Bots unbeaufsichtigt ausführen zu können, versuchen Unternehmen für Bots eigene Identitäten bereitzustellen, die zwischen einer Benutzeridentität und einer Dienstidentität liegen. Diese Bot-IDs werden als privilegierte Konten behandelt und erhalten Anwendungsberechtigungen für die Anwendungen, die sie verwenden bzw. aufrufen. Dies geschieht ähnlich wie bei einer Service-ID, da eine Bot-ID keiner Person zugeordnet ist.
Keine ID mit nicht ablaufenden Kennwörtern
Die wichtigsten RPA-Software-Anbieter speichern die Bot-ID-Anmeldeinformationen mithilfe einer 256-Bit-Verschlüsselung in ihren Datenbanken. Das verursacht allerdings eine Reihe von Problemen im Zusammenhang mit sicheren Anmeldeinformationen. So unterstützt dieser Mechanismus zum Speichern von Kennwörtern keine Zwei-Faktor- / Multifaktor-Authentifizierung. Wie bei allen Anmeldeinformationen für Dienstkonten, die in einer Datenbank bzw. Konfigurationsdatei gespeichert sind, ist das Ändern der Kennwörter außerdem sehr mühsam. Infolgedessen werden diese IDs mit nicht ablaufenden Kennwörtern eingerichtet, was zu Schwachstellen führt. Wenn Kennwörter nicht ordnungsgemäß geschützt sind, können unberechtigte Personen leicht die Kontrolle über eine Bot-ID übernehmen. Bot-IDs sollten deshalb als privilegierte Konten behandelt werden, da das Risiko einer Sicherheitskompromittierung hoch ist. Da Bot-IDs im Netzwerk authentifiziert sind, kann ein Hacker die Befehlszeilenschnittstelle (Command Line Interface, CLI) als Einstiegspunkt verwenden, um das Netzwerk nach interessanten und wichtigen Informationen für ihn zu durchforsten. Privilegierte Konten werden dagegen proaktiv überwacht.
Privileged Access Management schafft Sicherheit
Mit sogenannten PAM-Tools (Privileged Access Management), wie z. B. CyberArk, BeyondTrust, CA PAM oder Thycotic, können privilegierte Konten verwaltet werden. Neben einem sicheren Tresor zum Speichern der Kennwörter, Multifaktorauthentifizierung mit gegenseitigem TLS-Zertifikat, Whitelist des Hostnamens und der IP-Adresse, für die der Berechtigungsnachweis freigegeben wird, sowie der Anforderung, das Verzeichnis der Quelle der ausführbaren Datei anzuzeigen, können auch Sitzungen, die der Bot ausführt, kontinuierlich überwacht, angehalten oder beendet werden, sollte der Bot einen Befehl außerhalb seiner autorisierten Verwendung ausführen. Darüber hinaus kann das PAM-Tool das Kennwort nach jeder Verwendung drehen, wodurch das Risiko einer kompromittierten ID erheblich verringert wird.
Whitepaper "Robotic Operations Center für RPA Monitoring und Maintenance"
Erfahren Sie, wie Sie über ein Robotic Operations Center den reibungslosen Betrieb einer unternehmensweiten Digital Workforce – vom Development über die Inbetriebnahme bis zur Wartung der RPA Bots – sicherstellen.
SOD für nachhaltiges Risikomanagement
Die Aufgabentrennung (SOD – separation of duties) ist ein grundlegender Baustein für ein nachhaltiges Risikomanagement und interne Kontrollen für ein Unternehmen. Das Prinzip der SOD sieht die Verteilung kritischer Funktionen eines Prozesses auf mehr als eine Person oder Abteilung vor. Innerhalb der Produktionsumgebung sollten wichtige Funktionen innerhalb eines Workflows auf mehrere Personen verteilt werden. Zum Beispiel sollte sich ein Benutzer, der berechtigt ist, eine Rückerstattung zu erstellen, von der Person unterscheiden, die berechtigt ist, die Rückerstattung für die Zahlung zu genehmigen.
Unterschiedliche Bot-IDs für unterschiedliche Workflow-Parts
Für Bot-IDs sollten deshalb dieselben Regeln gelten wie für normale Benutzer-IDs. Beim Entwickeln und Testen eines Bots sollte eine andere Bot-ID verwenden als die, die für die Produktion verwendet wird. Wenn in der Produktion bei der Automatisierung eines Prozesses zwei verschiedene Bots für verschiedene Teile des Workflows benutzt werden, sollten für die Bots verschiedene Rollen und verschiedene IDs verwendet werden, die diesen Rollen zugeordnet sind. Ein Bot, der berechtigt ist, eine Rückerstattung zu erstellen, sollte eine andere ID besitzen als der Bot, der die Rückerstattung genehmigt.
Audit-Abteilung einbinden
Es sollte auch unbedingt bedacht werden, dass ein Audit die Prozesse und die aus diesen Prozessen resultierenden Artefakte und Daten überprüft. Es ist daher wichtig, die drei Grundsätze eines Audits beim Entwerfen von Bots zu berücksichtigen. Für ein Audit sollte es keine Rolle spielen, ob ein Workflow-Prozess von einem Menschen oder einem Bot ausgeführt wird, solange der Prozess und die Artefakte als wiederholbar und von hoher Qualität angezeigt werden können. Um den automatisierten Prozess, den Code, die Logik und die zugehörigen Parameter überprüfen und nachvollziehen zu können, ist es wichtig, die Audit-Organisation des Unternehmens und den Chief Audit Executive (CAE) am Entwurf und an der Erstellung eines Bots zu beteiligen. Die Überwachung von Bots wird durch die Verwendung von PASM (Privileged Access Session Management), das Teil einer PAM-Lösung ist, bei der die gesamte vom Bot ausgeführte Sitzung aufgezeichnet wird, erheblich vereinfacht.
Stellen Sie den langfristigen Erfolg Ihrer RPA-Initiative sicher
Die Wartungs- und Verwaltungsstrategie eines Robotic Operations Center (ROC) bildet ein solides Fundament für eine Skalierung Ihrer Digital Workforce. Gerne sorgen wir auch in Ihrem Unternehmen für den reibungslosen Betrieb der Bots.
7 Kontroll-Punkte, die Unternehmen kennen sollten
Die wichtigsten Kontrollen für die Identity Governance von Bots sind:
-
Authentifizierung: Anstatt die Bot-Anmeldeinformationen in Code oder Software zu speichern, ist ein Tresor für Anmeldeinformationen oder eine PAM-Lösung die bevorzugte Wahl.
-
Autorisierung und Aufgabentrennung: Die Anmeldeinformationen von Softwarerobotern sollten auf bestimmte Aufgaben, Prozesse, Systeme und Umgebungen beschränkt sein. Zudem sollte der Entwicklungsprozess für Software-Roboter, seine Rolle und die Berechtigungen klar definiert werden.
-
Lebenszyklusmanagement: Das Bot Identity-Lebenszyklusmanagement sollte ähnlich einem Kontingentarbeiter in einer Organisation modelliert sein. Jeder Software-Roboter muss einen Verwalter und einen Sponsor haben. Der Sponsor erstellt und wartet den RPA Bot, während die Depotbank die Ergebnisse der vom Bot durchgeführten Prozesse ausführt und auswertet.
-
Eindeutige Kennung: Software-Roboter müssen eine eindeutige Kennung haben. Diese eindeutige Kennung ermöglicht effektive Überwachungs-, Berichts-, Zertifizierungs- und Analysefunktionen.
-
Ownership Management: Der Eigentümer von Softwarerobotern sollte identifiziert werden können, um die Verantwortlichkeit für Softwareroboteraktionen sicherzustellen. Die Abtretung und Übertragung des Eigentums sollte auch nachverfolgt werden können, wenn beispielsweise Depotbanken ihre Verantwortung an eine andere Person delegieren oder wenn eine Depotbank deaktiviert wird.
-
Verwaltung von Anmeldeinformationen: Anmeldeinformationen von Softwarerobotern sollten in Tresoren für Anmeldeinformationen geschützt werden. Dies kann mit Single Sign-On kombiniert werden, um den Zugriff zu vereinfachen.
-
Abmeldung: Softwareroboteridentitäten sollten abgemeldet werden, wenn die Funktionalität des Bots nicht benötigt wird. Dies ist wichtig, um verwaiste Softwareroboterkonten zu verhindern, die zu potenziellen Zugriffsschwachstellen in der Umgebung führen können.
Fazit:
Software-Roboter können sich als Personen ausgeben, um in ihrem Namen auf Ressourcen zuzugreifen, oder sie können ein freigegebenes Konto verwenden, um auf einige Ressourcen zuzugreifen. In beiden Fällen sollten Softwareroboter eine eigene, nicht abgelehnte eindeutige Identität haben, um Zugriff auf IT-Ressourcen zu erhalten. Kommerzielle Vaulting-Lösungen für Anmeldeinformationen helfen, die Verwendung von Anmeldeinformationen durch Softwareroboter zu steuern. Die Implementierung einer PAM-Lösung ist eine sehr gute Methode zur Steuerung und Überwachung von Bot-IDs.
