Enterprise-Low-Code-Plattformen mit KI — wie Retool, OutSystems, Mendix und ähnliche — sind leistungsstarke Werkzeuge zur Erstellung interner Tools, operativer Dashboards und Administrationspanels. Das konkrete Risiko besteht darin, dass Anwendungen, die eigentlich zur Beschleunigung von Betriebsabläufen entwickelt wurden, am Ende mit höheren Berechtigungen als nötig auf Datenbanken, CRM-, ERP-Systeme und interne APIs zugreifen, oft ohne dass dies explizit geplant wurde.

Dieser Artikel richtet sich an CTOs, CISOs, IT-Manager und Operations-Verantwortliche. Der Fokus liegt auf internen Tools, Admin-Panels, dem Zugriff auf Unternehmensdatenbanken, übermäßigen Berechtigungen, Rollentrennung, Logging sowie IT- und Sicherheitsfreigabeprozessen.

Warum eine funktionierende App nicht zwangsläufig sicher ist

KI-Tools reduzieren die Zeit, die für die Erstellung von Code, Schnittstellen, Workflows und Konfigurationen benötigt wird. Diese Geschwindigkeit kann jedoch die Schritte verkürzen, die Software normalerweise zuverlässig machen: Threat Modeling, Code-Reviews, Geheimnisverwaltung (Secrets Management), Rollenprüfungen, Eingabevalidierung, Überprüfung von Abhängigkeiten und manuelle Tests kritischer Pfade.

Eine Demo funktioniert mit einem einzigen Benutzer, fiktiven Daten und impliziten Berechtigungen. Dieselbe Logik kann versagen, wenn echte Kunden, mehrere Mandanten (Tenants), verschiedene Rollen, öffentliche APIs, Integrationen, personenbezogene Daten, Zahlungen oder Automatisierungen mit externen Auswirkungen hinzukommen. Sicherheit muss am tatsächlichen Verhalten der App bewertet werden, nicht am Versprechen des Tools, das sie generiert hat.

Internes Tool bedeutet nicht geringes Risiko

Ein internes Tool kann Bestellungen, Kunden, Verträge, Tickets, Zahlungen, Stammdaten oder HR-Daten ändern. Wenn es mit KI generiert oder angepasst wurde, müssen nicht nur die Benutzeroberfläche, sondern auch die zugrunde liegenden Abfragen, Berechtigungen, Anmeldedaten und Workflows überprüft werden. Das Fehlen einer öffentlichen Exposition verringert das Risiko nicht: Oft konzentriert es sich auf einen weniger überwachten Bereich.

Konnektoren und Unternehmensdatenbanken

Retool, OutSystems, Mendix und ähnliche Plattformen arbeiten oft über Konnektoren mit privilegiertem Zugriff auf Unternehmenssysteme. Das Schlüsselprinzip besteht darin, Anmeldedaten nach Umgebung zu trennen, Abfragen und APIs auf das notwendige Minimum zu beschränken, Benutzeraktionen nachzuverfolgen und keine gemeinsam genutzten Konten mit übermäßigem Zugriff zu verwenden. Jeder Konnektor sollte einen definierten und überprüfbaren Geltungsbereich (Scope) haben und keine Berechtigungen von einem generischen Administratorkonto erben.

Governance für CISOs und IT-Manager

Eine effektive Governance für Low-Code-Apps erfordert ein aktuelles Inventar der aktiven Anwendungen, einen verantwortlichen Eigentümer für jede Anwendung, die Klassifizierung der verarbeiteten Daten und einen Freigabeprozess vor der Veröffentlichung. Hinzu kommen die regelmäßige Überprüfung der Berechtigungen und die Verfügbarkeit von Logs, die im Falle eines Vorfalls oder Audits eingesehen werden können. Ohne diese Elemente kann selbst ein scheinbar einfaches Tool zu einem blinden Fleck im Sicherheitsperimeter des Unternehmens werden.

Hauptrisiken, die überprüft werden müssen

• Konnektoren mit übermäßigen Berechtigungen: Überprüfung der Konfiguration, des Laufzeitverhaltens und der Auswirkungen auf echte Daten.
• Abfragen, die ohne rollenbasierte Einschränkungen generiert wurden: Überprüfung, ob die Abfragen die Berechtigungen des authentifizierten Benutzers respektieren und nicht nur die des Konnektors.
• Gemeinsam genutzte Konten für Datenbanken oder APIs: Ersetzung durch dedizierte Konten mit minimalem Scope.
• Interne Tools, die ohne Genehmigung veröffentlicht wurden: Einführung eines Review-Prozesses vor dem Go-Live.
• Unzureichendes Logging bei administrativen Aktionen: Gewährleistung einer vollständigen Rückverfolgbarkeit kritischer Vorgänge.
• Sensible Daten, die in Dashboards kopiert oder exportiert werden: Überprüfung, ob die Anzeige und der Export den Zugriffsrichtlinien entsprechen.
• Schwache Rollentrennung: Überprüfung, ob Kontrollen serverseitig angewendet werden und nicht nur in der Benutzeroberfläche.

Diese Risiken müssen mit dem konkreten Perimeter verknüpft werden. Eine exponierte App erfordert manuelle Anwendungstests; eine kritische Codeänderung erfordert ein Review; ein interner Workflow erfordert die Kontrolle von Berechtigungen und Anmeldedaten. Die richtige Kombination hängt von der tatsächlichen Auswirkung ab, nicht vom Namen des verwendeten Tools.

Mindestkontrollen vor dem Go-Live

• Zuordnung von Benutzern, Rollen, echten Daten, Integrationen, Umgebungen und Service-Eigentümern.
• Identifizierung, welche Teile mit KI generiert oder modifiziert wurden und wer sie überprüft hat.
• Überprüfung serverseitiger Autorisierungen, Mandantentrennung (Tenant Isolation) und administrativer Funktionen.
• Suche nach Geheimnissen (Secrets) in Code, Prompts, Logs, Umgebungsvariablen, Builds und Repository-Verläufen.
• Überprüfung von Abhängigkeiten, Lizenzen, Paketen, Vorlagen, Plugins und generierten Komponenten.
• Testen von feindseligen Eingaben, Fehlerbehandlung, Logging, Ratenbegrenzung und nicht vorgesehenen Pfaden.
• Trennung von blockierenden Korrekturen, geplanter Sanierung und akzeptiertem Restrisiko.
• Wiederholung des Tests oder Retests nach Korrekturen, die kritische Abläufe betreffen.

Wann eine unabhängige Überprüfung erforderlich ist

Eine unabhängige Überprüfung ist erforderlich, wenn die App oder der Workflow echte Daten, externe Benutzer, Rollen, APIs, Unternehmensintegrationen, Zahlungen, Speicher oder kritischen, mit KI generierten Code verarbeitet. Sie ist auch dann notwendig, wenn das Team nicht nachweisen kann, welche Teile überprüft wurden und welche Kontrollen Regressionen oder Missbrauch verhindern.

In diesen Fällen umfasst der von ISGroup empfohlene Perimeter: Risikobewertung (Risk Assessment) zur Identifizierung und Priorisierung von Risiken, Schwachstellenanalyse (Vulnerability Assessment) zur Erkennung bekannter Schwachstellen, bevor diese ausgenutzt werden, und Virtual CISO für eine wiederkehrende Governance, wenn die Low-Code-KI-Nutzung in mehreren Abteilungen zunimmt. Das beste Review ist nicht generisch: Es muss reproduzierbare Ergebnisse, Prioritäten für die Sanierung, Angaben zum Restrisiko und bei Bedarf einen Retest nach den Korrekturen liefern.

Operative Fragen für Gründer, CTOs und Sicherheitsteams

• Welche echten Daten gelangen in das System und wo werden sie gespeichert, protokolliert oder gesendet?
• Welche Rollen existieren und welche Aktionen werden serverseitig blockiert, nicht nur in der Benutzeroberfläche?
• Welche Geheimnisse, Token, Webhooks oder Anmeldedaten würden den Zugriff auf kritische Systeme ermöglichen?
• Welche Teile wurden von der KI generiert oder modifiziert und welche wurden von einer kompetenten Person überprüft?
• Welche Tests decken Missbrauch, Fehler, verschiedene Rollen und verschiedene Mandanten ab, nicht nur den “Happy Path”?
• Welche Nachweise können Kunden, Auditoren, dem Einkauf oder der Geschäftsführung vorgelegt werden?

Nützliche weiterführende Informationen

• Durch KI generierte Shadow IT: Vertieft, wie die unkontrollierte Nutzung von KI-Tools Anwendungen außerhalb des IT-Perimeters des Unternehmens schafft.
• Richtlinien und Risiken beim KI-Coding: Leitfaden zur Definition interner Richtlinien für die sichere Nutzung von Code-Generierungstools.
• Authentifizierung und Autorisierung in KI-Apps: Analyse spezifischer Zugriffskontrollen für Anwendungen, die KI-Komponenten integrieren.

FAQ

• Warum ist ein internes Low-Code-Tool aus Sicherheitssicht kritisch?
• Weil es oft direkten Zugriff auf Unternehmensdaten und -systeme mit hohen Berechtigungen hat, auch wenn es nicht im Internet exponiert ist. Das Fehlen externer Sichtbarkeit verringert das Risiko nicht: Es konzentriert es auf einen weniger überwachten und schwerer zu prüfenden Bereich.
• Was muss der CISO bei diesen Anwendungen kontrollieren?
• Aktuelles Inventar, verantwortlicher Eigentümer, Klassifizierung der verarbeiteten Daten, Konfiguration der Konnektoren, Verwaltung der Anmeldedaten, Rollentrennung, Protokollierung kritischer Aktionen, Freigabeprozess und regelmäßige Überprüfung der Berechtigungen.
• Ist ein Penetrationstest für ein internes Tool erforderlich?
• Das hängt von der Exposition und der Auswirkung ab. Für interne Tools mit Zugriff auf sensible Daten sind oft eine Risikobewertung, eine Schwachstellenanalyse und eine architektonische Überprüfung der Berechtigungen angemessener, bevor ein vollständiger Anwendungstest in Betracht gezogen wird.
• Wie werden die Berechtigungen von Konnektoren begrenzt?
• Durch die Verwendung dedizierter Konten mit minimalem Scope, rollenbasierte Allowlists für Abfragen, Trennung von Entwicklungs- und Produktionsumgebungen sowie Protokollierung der über den Konnektor ausgeführten Aktionen.
• Wann sollte der Virtual CISO einbezogen werden?
• Wenn die Einführung von Low-Code-KI-Tools in mehreren Abteilungen zunimmt und eine wiederkehrende Governance erforderlich ist, nicht nur eine punktuelle technische Kontrolle. Der vCISO kann Richtlinien definieren, Freigabeprozesse überwachen und Kontinuität im Risikomanagement gewährleisten.

[Callforaction-RA-Footer]

Quellen und Referenzen

• OWASP Top 10 2021
• OWASP ASVS
• OWASP Code Review Guide
• NIST SP 800-218 SSDF
• Retool — Sicherheitsdokumentation
• OutSystems — Plattform-Sicherheit