rh2010 - stock.adobe.com
Low-Code/No-Code: Die Security-Risiken verringern
Unternehmen sollten keine Low-Code/No-Code-Entwicklung einführen, ohne sich intensiv mit der Security zu beschäftigen. Bewährte Verfahren können helfen, die Risiken zu minimieren.
Mehr Unternehmen als je zuvor übernehmen und verwenden Low-Code- und No-Code-Anwendungsentwicklungskonzepte. Dies ist vor allem auf die Einfachheit und problemlose Bereitstellung sowie auf die Effizienz bei der schnellen Erstellung von Anwendungen zurückzuführen. Diese Flexibilität und Einfachheit bringt jedoch auch eine Vielzahl potenzieller Sicherheitsrisiken mit sich, die zur Offenlegung von Daten, zur Kompromittierung von Systemen und/oder Konten und zu anderen erheblichen Sicherheitsproblemen führen können.
Um die Herausforderungen bei der Entwicklung von Low-Code/No-Code-Anwendungen zu mindern und Risiken von vornherein zu vermeiden, sollten Sie die folgenden Best Practices beachten.
Den richtigen Dienstanbieter wählen
Ein Hauptanliegen ist die Sicherheit der Betriebsumgebung, in der die Anwendungen entwickelt und potenziell ausgeführt werden. Unternehmen sollten No-Code- und Low-Code-Dienstleister einsetzen, die Sicherheitskontrollen und -garantien in ihrer Umgebung anbieten. Einige Anbieter bieten Kontrollen an, die der Kunde einsetzen kann, zum Beispiel Datenverschlüsselung, Identitätsföderation und Protokollierung, während andere wenig oder gar keine Sicherheit bieten.
Anmeldedaten begrenzen und sichern
Low-Code/No-Code-Ansätze sind anfällig für den Missbrauch von Anmeldeinformationen und die Ausnutzung von Berechtigungen. Dies gilt insbesondere, wenn der Code mit einem Entwicklerkonto verknüpft ist, das über weitreichende Berechtigungen in der Entwicklungsumgebung oder mit Verbindungen zu Datenbanken und anderen Komponenten verfügt.
Diese Risiken werden dadurch gemindert, dass die Sicherheits- und Identitätsteams nach Möglichkeit in den Prozess der Anwendungsentwicklung einbezogen werden. Überwachen Sie Low-Code/No-Code-Plattformen und alle Verbindungen auf übermäßige oder unerlaubte Nutzung von Berechtigungen. Verbindungsprotokolle zu anderen Systemen und Datenbanken können in vielen Fällen helfen, diese zu identifizieren. Wenn möglich, sollten Sie Konten und Verbindungen mit geringeren Rechten einrichten.
Datenexposition und -verluste verhindern
Ein weiteres Problem bei Low-Code-/No-Code-Anwendungen ist die Offenlegung von Daten sowie Datenlecks. Diese entstehen durch unsachgemäße Datenverarbeitungsmethoden und schlechte Anwendungslogik bei der Interaktion mit Datenspeichern.
Da die meisten Anbieter von Daten ihren Kunden keine expliziten Sicherheitskontrollen wie Verschlüsselung oder Datenmaskierung anbieten, ist es wichtig, die öffentliche Verfügbarkeit von Low-Code/No-Code-Apps so weit wie möglich zu begrenzen. Positionieren Sie die Anwendungen hinter einem Security-Brokering-System, zum Beispiel einem Content Delivery Network (CDN) oder einem Cloud Access Security Broker (CASB), das Datenüberwachung und Schutzkontrollen während der Übertragung bietet.
Wenn eine Monitoring-Funktion für die Low-Code/No-Code-Plattform verfügbar ist, sollten Sicherheits- und Betriebsteams diese aktivieren, um mögliche Datenflüsse und Verbindungen zu überwachen.
Durchführung von Tests zur Anwendungssicherheit und Anforderung von SBOMs
Einer der größten Risikobereiche bei Low-Code/No-Code-Anwendungen und Entwicklungsumgebungen ist der Code selbst, sowie die bei der Entwicklung verwendeten Komponenten, Backend-Pakete und Funktionen.
In traditionellen Entwicklungsumgebungen führen Unternehmen, die Wert auf Sicherheit legen, Sicherheitstests für die Codierung und für die Paketanwendungen durch - unter Verwendung von Tools für statische Anwendungssicherheitstests (SAST) beziehungsweise dynamische Anwendungssicherheitstests (DAST).
Diese Tools sind für die Entwicklung und den Einsatz von Low-Code/No-Code nicht immer ohne Weiteres verfügbar. Das Beste, was Unternehmen tun können, ist, SAST- und DAST-Ergebnisse für ihre Backend-Komponenten und den in den Bereitstellungen verwendeten Code anzufordern. Dies kann sich als erfolgreich erweisen, muss es aber nicht.
Eine weitere Taktik, die sich zunehmender Beliebtheit erfreut, ist die Forderung - oder sogar das Erfordernis - einer Software Bill of Materials (SBOM), in der der gesamte Code und alle Pakete aufgelistet sind, die in der Umgebung des Anbieters verwendet werden, sowie eine Bescheinigung über die kontinuierliche Überwachung von Bedrohungen und das Management von Schwachstellen. Wie die SAST- und DAST-Ergebnisse ist auch dies nicht immer erfolgreich.
Transparenz verbessern
Viele Sicherheitsteams haben das Gefühl, dass sie wenig bis gar keinen Einblick in Low-Code/No-Code-Anwendungen und -Umgebungen haben. Idealerweise setzen Unternehmen keine Plattformen ein, die überhaupt keine Protokollierung oder Überwachung bieten. Zumindest sollten Unternehmen Benutzerzugriffsprotokolle und Plattform-Auditprotokolle aktivieren, falls verfügbar. Oder eine vermittelte Zugriffsstrategie über CDNs implementieren, die Protokollierung und Überwachung für alle Zugriffe auf Anwendungen und/oder Plattformanbieter unterstützen, bei denen es sich hauptsächlich um SaaS handelt.
Mitarbeiter schulen
Zusätzlich zu den Abschwächungstaktiken ist es erwähnenswert, dass die Sicherheitsaufklärung für jeden, der mit Low-Code/No-Code-Tools entwickelt, von größter Bedeutung ist. Angesichts der relativ spärlichen Verfügbarkeit integrierter Sicherheitskontrollen und -funktionen in diesen Anbieterumgebungen obliegt es jedem, die potenziellen Risiken zu verstehen und daran zu arbeiten, sie nach Möglichkeit zu verringern oder zu vermeiden.
