Mehr als nur eine rein formale System-ID notwendig

Jeder Roboter braucht seine eigene ID

Schritt 1: Erstellung der technischen Roboter-ID

Im Rahmen der technischen Einrichtung einer Roboter-Benutzer-ID verlangt normalerweise der Process-Owner die Einrichtung einer neuen Roboter-Benutzer-ID. Diese ID sollte in einer speziellen Mitarbeitergruppe innerhalb des ERP-Systems angelegt werden, um sicherzustellen, dass die Roboter-ID nicht mit menschlichen IDs verwechselt wird. Es ist wichtig, diese aus statistischen Gründen und aus Gründen der Lohnabrechnung zu trennen – um zu vermeiden, dass ein Roboter irrtümlicherweise Lohn auf ein bestimmtes Bankkonto überwiesen bekommt.

Das ERP-System ist in der Regel mit dem Gruppenverzeichnis verbunden, das den Zugriff auf Anwendungen innerhalb des Unternehmens steuert. Innerhalb dieses Systems sollte ein geschützter Bereich für Roboter angelegt werden. Dadurch wird sichergestellt, dass nur Anwendungen, die auf einer Positivliste stehen, mit der Roboter-Benutzer-ID interagieren und dass der Bereich der Anwendungen eingeschränkt ist und kontrolliert werden kann.

Anzeige

Schritt 2: Bereitstellen der Rollen und Berechtigungen

Im Anschluss an die technische Einrichtung der Roboter-ID müssen roboterspezifische Rollen und Berechtigungen erstellt werden. Durch die Verwendung der bestehenden Methoden zur Beantragung und Genehmigung von Rollen und Rechten für einen Roboter wird die Einhaltung der Compliance-Richtlinien in jeder Phase des Prozesses sichergestellt. Der “Robot Lead” ist für die Zuweisung von Anwendungsrechten, Rollen und Berechtigungen für den Roboter verantwortlich. Diese Rechte und Berechtigungen decken den erforderlichen Umfang der einzelnen roboterbezogenen Prozesse ab.

Die Rechte müssen also pro Prozess festgelegt werden, um die Roboterauslastung zu erhöhen und die Compliance-Anforderungen zu gewährleisten. Es ist empfehlenswert, den Ansatz des minimalen Rechtesatzes zu verfolgen und keine Admin-Rechte für den Roboter festzulegen. Ihn wie einen normalen Mitarbeiter zu behandeln, führt zu den wenigsten Compliance-Problemen. Bei den meisten Tools kann eine Lizenz verschiedene Benutzer-IDs und Instanzen verwalten. Da ein Roboter kein menschlicher Mitarbeiter ist, benötigt er auch nicht die gleichen Rechte. Daher werden Roboter nicht von Verfahren berücksichtigt, die nur für Menschen relevant sind (Mitarbeiterzahl, Gehalt, Zugangskarte zur Kantine). Sie benötigen aber folgende allgemeine Attribute:

  • Unter HR-Gesichtspunkten: Zuordnung zu einem Vorgesetzten
  • Unter IT-Gesichtspunkten: Master-ID, individuelle IDs, Konto im Unternehmensverzeichnis (geschützter Bereich), Konto im ERP, E-Mail-Konto, Desktop (Windows)-Zugang/SSO, Zugriff auf alle relevanten Netzlaufwerke
  • Unter prozessindividuellen Gesichtspunkten: Benutzerzugriff und Berechtigungen für prozessrelevante Anwendungen (innerhalb der Artefakte zu definieren)
Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.

Bot-ID als Einfallstor für Hacker

In aller Regel werden Anmeldeinformationen der Bot-ID mit Hilfe einer 256-Bit-Verschlüsselung in Datenbanken gespeichert. Wie bei allen Anmeldeinformationen für Dienstkonten, die in einer Datenbank- /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 wiederum zu einem Sicherheitsrisiko führt. Bot-IDs sollten als privilegierte Konten behandelt werden, da das Risiko eines Sicherheitskompromisses hoch ist, wenn ein Angreifer die Kontrolle über eine Bot-ID bzw. das Kennwort, die nicht ordnungsgemäß geschützt ist, übernehmen kann.

Da eine kompromittierte Bot-ID im Netzwerk authentifiziert ist, kann ein Hacker die Befehlszeilenschnittstelle (Command Line Interface, CLI) aufrufen und als Einstiegspunkt / Sprungbrett verwenden, um das Netzwerk zu durchforsten und wichtige Informationen abgreifen. Eine relativ einfache Möglichkeit, die Bot-Anmeldeinformationen zu sichern, ist die Verwendung von PAM-Tools (Privileged Access Management), wie z. B. CyberArk, BeyondTrust, CA PAM oder Thycotic, die eine Vielzahl von Funktionen zum Verwalten privilegierter Konten einschließlich eines sicheren Tresors zum Speichern der Kennwörter Multi-Faktor-Authentifizierung bieten.

Fazit

Beschränken Sie die Anmeldeinformationen von Softwarerobotern auf bestimmte Aufgaben, sollten auch Prozesse, Systeme und Umgebungen begrenzt sein. Zudem sollte der Entwicklungsprozess für Softwareroboter, seine Rolle und die Berechtigungen klar definiert sein. Eine eindeutige Kennung ermöglicht effektive Überwachungs-, Berichts-, Zertifizierungs- und Analysefunktionen.

Die 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.

Wird der Software-Roboter nicht mehr benötigt, sollte die Roboter-ID abgemeldet werden. Somit werden verwaiste Softwareroboterkonten vermieden, die zu potenziellen Einfallstoren für gezielte Angriffe werden können.

Milad

Safar

Weissenberg Group -

Managing Partner

Milad Safar ist Managing Partner der Weissenberg Group, die er 2013 zusammen mit Marcel Graichen gegründet hat. Seit Beginn seiner Berater-Tätigkeit entwickelte er für namhafte Konzerne Lösungen zur Optimierung von Prozessen durch den Einsatz von IT-Systemen. Schwerpunktmäßig beschäftigt sich Milad Safar mit den Themen Digitalisierung, Robotic und Künstliche Intelligenz,
Anzeige

Artikel zu diesem Thema

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.