Letzten Monat habe ich geschrieben ein Artikel über die Art und Weise, wie Low-Code-/No-Code-Plattformen das Teilen von Anmeldeinformationen als Service anbieten, warum sie dies tun und wie dies aussieht die Perspektive eines Angreifers. In diesem Artikel konzentriere ich mich auf die Auswirkungen dieses Kompromisses und wie er sich auf Unternehmen von heute auswirkt.
Aus diesem Grund ist es eine schlechte Praxis, Ihre Unternehmensanmeldeinformationen mit jemand anderem zu teilen. Angenommen, ich möchte meine Anmeldeinformationen an einen Kollegen weitergeben, um Produktionsprotokolle für eine einmalige Analyse des Benutzerverhaltens abzufragen. In einem typischen Unternehmen kann das Erteilen von Berechtigungen zum Abfragen einer neuen Datenquelle einen langwierigen Zugriffsüberprüfungsprozess bedeuten, insbesondere wenn es um Produktionsdaten oder sensible Daten geht. Mein Kollege könnte leicht frustriert werden. „Alles, was ich wollte, war diese winzige, einmalige Abfrage, und ich warte schon seit einem Monat!“ könnten sie sagen. Ich könnte die Abfrage einfach für sie ausführen, aber ich bin mit meinen eigenen täglichen Aufgaben überfordert, und einmalige Abfragen werden in der Regel kompliziert.
Mir bleibt nur eine schnelle Lösung: Ich könnte einfach meinen Benutzernamen/mein Passwort mit meinem Kollegen teilen. Wenn sie eine MFA-Herausforderung erhalten, stimme ich gerne zu. Ich muss die Zeit nicht damit verbringen, die Abfrage auszuführen, und mein Kollege wird entsperrt. Alle gewinnen! Recht?
Nun, Sie hätten Recht mit Ihrer Analyse, aber Ihnen entgeht das Gesamtbild. Während es für das Unternehmen wichtig ist, dass Ihr Kollege eine Analyse des Benutzerverhaltens durchführt, ist es ebenso wichtig, wenn nicht sogar noch wichtiger, dass Ihr Unternehmen eine ganze Reihe von Datenschutz- und Sicherheitsstandards einhält und das Vertrauen der Kunden aufrechterhält, indem es die Verpflichtung des Unternehmens zur Sicherheit aufrechterhält .
Wenn übergeordnete Unternehmensziele Sie nicht überzeugen, ziehen Sie die zentralen Managementteams in IT oder Sicherheit in Betracht. Diese Teams stützen ihre Betriebs- und Sicherheitsstrategien auf die Tatsache, dass jeder Benutzer seine eigene einzigartige Identität hat. IT-Teams richten Netzwerk- und Zugriffsrichtlinien ein, die davon ausgehen, dass jeder Benutzer gleichzeitig von einer Unternehmens-IP oder einem Unternehmens-Laptop angemeldet wird; Sicherheitsteams korrelieren Ereignisse basierend auf der Benutzer-ID; Finanzteams könnten Kostenberichte pro Benutzer und ihrer persönlichen Cloud-Umgebung aggregieren. Das Teilen von Anmeldeinformationen untergräbt unter anderem all diese Annahmen. Es entfernt die grundlegende Bedeutung einer Online-Identität.
Ein Beispiel aus der Praxis
Wenden wir uns der Welt von Low-Code/No-Code zu und untersuchen ein reales Szenario. In einem großen Unternehmen erkannte Jane, eine begeisterte Mitarbeiterin des Kundenbetreuungsteams, dass, wenn Mitarbeiter im gesamten Unternehmen an einem Kundenfall teilnehmen, ihnen normalerweise wichtige Informationen über den Kunden fehlen, wie z. B. der Verlauf des Supportfalls und die letzten Einkäufe. Dies verschlechtert die Erfahrung des Kunden, da er sein Problem immer wieder erklären muss, während der Fall an den richtigen Mitarbeiter weitergeleitet wird, der sich um das Problem kümmern kann.
Um dies zu verbessern, hat Jane eine App entwickelt, mit der Mitarbeiter des Unternehmens diese wichtigen Informationen über Kunden anzeigen können, wenn diese Mitarbeiter Teil des Teams sind, das für die Bearbeitung des Supportfalls des Kunden verantwortlich ist. Nehmen wir uns zunächst einen Moment Zeit, um die Leistungsfähigkeit von Low-Code/No-Code anzuerkennen, die es Jane ermöglicht, einen Bedarf zu erkennen und sich selbst darum zu kümmern, ohne nach einem Budget zu fragen oder auf die Zuweisung von IT-Ressourcen zu warten.
Beim Erstellen der Anwendung musste Jane mehrere Probleme umgehen, von denen das größte die Berechtigungen waren. Mitarbeiter im gesamten Unternehmen haben keinen direkten Zugriff auf die Kundendatenbank, um die benötigten Informationen zu erhalten. Wenn ja, müsste Jane diese Anwendung nicht erstellen. Um dieses Problem zu lösen, meldete sich Jane bei der Datenbank an und bettete ihre authentifizierte Sitzung direkt in die Anwendung ein. Wenn die Anwendung eine Anfrage von einem Benutzer erhält, verwendet sie Janes Identität, um diese Abfrage auszuführen, und gibt die Ergebnisse dann an den Benutzer zurück. Diese Funktion zum Einbetten von Anmeldeinformationen wie wir letzten Monat erkundet haben, ist ein Schlüsselmerkmal von Low-Code/No-Code-Plattformen. Jane stellte sicher, dass die rollenbasierte Zugriffskontrolle (RBAC) in der Anwendung so eingerichtet wurde, dass jeder Benutzer nur auf Kundenvorgänge zugreifen kann, denen er zugewiesen ist.
Die Anwendung löste ein wichtiges Geschäftsproblem und gewann so schnell an Benutzerakzeptanz im gesamten Unternehmen. Die Leute waren froh, dass sie ihren Kunden einen besseren Service bieten konnten, indem sie den richtigen Kontext für das Gespräch hatten. Auch die Kunden waren zufrieden. Einen Monat, nachdem Jane die Anwendung erstellt hatte, wurde sie bereits von Hunderten von Benutzern im gesamten Unternehmen verwendet, wobei die Kundenzufriedenheitsraten stiegen.
In der Zwischenzeit wurde im SOC eine Warnung mit hohem Schweregrad ausgelöst, die ungewöhnliche Aktivitäten in der Produktionskundendatenbank anzeigte, und Amy, einer erfahrenen Sicherheitsanalystin, zugewiesen. Amys erste Untersuchung ergab, dass ein interner Benutzer versuchte, die gesamte Datenbank zu durchsuchen und Informationen über mehrere Kunden von mehreren IP-Adressen im gesamten Unternehmen abzufragen. Das Abfragemuster war sehr komplex; Anstelle eines einfachen Aufzählungsmusters, das Sie beim Scraping einer Datenbank erwarten würden, wurden dieselben Kundendaten mehrmals abgefragt, manchmal über verschiedene IP-Adressen und an verschiedenen Daten. Könnte dies ein Angreifer sein, der versucht, die Sicherheitsüberwachungssysteme zu verwirren?
Nach einer kurzen Untersuchung entdeckte Amy eine entscheidende Information: Alle diese Abfragen über alle IP-Adressen und Daten hinweg verwendeten eine einzige Benutzeridentität, jemand namens Jane vom Kundendienstteam.
Amy wandte sich an Jane, um sie zu fragen, was los sei. Zuerst wusste Jane es nicht. Wurden ihre Ausweise gestohlen? Hat sie auf den falschen Link geklickt oder der falschen eingehenden E-Mail vertraut? Aber als Jane Amy von der Anwendung erzählte, die sie kürzlich erstellt hatte, wurde beiden klar, dass es eine Verbindung geben könnte. Amy, die SOC-Analystin, war mit Low-Code/No-Code nicht vertraut, also wandten sie sich an das AppSec-Team. Mit Janes Hilfe fand das Team heraus, dass in Janes Bewerbung Janes Anmeldeinformationen eingebettet waren. Aus Sicht der Datenbank gab es keine Anwendung – es gab nur Jane, die eine ganze Menge Abfragen ausführte.
Jane, Amy und das AppSec-Team beschlossen, die Anwendung herunterzufahren, bis eine Lösung gefunden wurde. Anwendungsbenutzer im gesamten Unternehmen waren frustriert, seit sie sich darauf verlassen hatten, und die Kunden spürten das auch.
Während Amy das Problem schloss und ihre Ergebnisse dokumentierte, war der VP der Kundenbetreuung nicht erfreut, dass die Kundenzufriedenheitsrate sank, und baten Jane, nach einer dauerhaften Lösung zu suchen. Mithilfe der Dokumentation der Plattform und des Center of Excellence-Teams der Organisation entfernte Jane ihre eingebettete Identität aus der Anwendung, änderte die App so, dass sie die Identität jedes Benutzers zum Abfragen der Datenbank verwendet, und stellte sicher, dass Benutzer nur Berechtigungen für Kundenvorgänge erhalten, denen sie zugeordnet sind . In ihrer neuen und verbesserten Version verwendete die Anwendung die Identität jedes Benutzers, um die Kundendatenbank abzufragen. Jane und die Benutzer der Anwendung freuten sich, dass die Anwendung wieder online ist, Amy und das AppSec-Team freuten sich, dass Janes Identität nicht mehr geteilt wird, und das Unternehmen sah, dass die Kundenzufriedenheitsrate wieder zu steigen begann. Alles war gut.
Zwei Wochen später erhielt das SOC eine weitere Warnung über einen ungewöhnlichen Zugriff auf die Produktionskundendatenbank. Es sah der vorherigen Warnung in derselben Datenbank verdächtig ähnlich. Auch hier verwendeten IP-Adressen aus dem gesamten Unternehmen die Identität eines einzelnen Benutzers, um die Datenbank abzufragen. Auch dieser Benutzer war Jane. Aber dieses Mal wussten das Sicherheitsteam und Jane, dass die App die Identitäten ihrer Benutzer verwendet. Was ist los?
Die Untersuchung ergab, dass die ursprüngliche App implizit geteilt Janes authentifizierte Datenbanksitzung mit den Benutzern der App. Indem die App mit einem Benutzer geteilt wird, erhält dieser Benutzer direkten Zugriff auf die Verbindung, ein Wrapper um eine authentifizierte Datenbanksitzung, die von der Low-Code/No-Code-Plattform bereitgestellt wird. Über diese Verbindung konnten Benutzer die authentifizierte Sitzung direkt nutzen – sie mussten nicht mehr durch die App gehen. Es stellte sich heraus, dass mehrere Benutzer dies herausgefunden hatten und in der Annahme, dass dies das beabsichtigte Verhalten sei, Janes authentifizierte Datenbanksitzung zum Ausführen ihrer Abfragen verwendeten. Sie liebten diese Lösung, da sie über die direkte Verbindung vollen Zugriff auf die Datenbank hatten, nicht nur für Kundenfälle, denen sie zugewiesen waren.
Die Verbindung wurde gelöscht, und der Vorfall war vorbei. Der SOC-Analyst wandte sich an Benutzer, die Janes Verbindung verwendet hatten, um sicherzustellen, dass sie alle von ihnen gespeicherten Kundendaten verwarfen.
Bewältigung der Low-Code/No-Code-Sicherheitsherausforderung
Die obige Geschichte ist ein reales Szenario eines multinationalen B2C-Unternehmens. Zum Schutz der Privatsphäre wurden einige Details weggelassen oder angepasst. Wir haben gesehen, wie ein wohlmeinender Mitarbeiter seine Identität unwissentlich mit anderen Benutzern teilen konnte, was eine ganze Reihe von Problemen in der IT, der Sicherheit und im Unternehmen verursachte. Wie wir letzten Monat untersucht haben, ist die gemeinsame Nutzung von Anmeldeinformationen ein Schlüsselmerkmal von Low-Code/No-Code. Es ist die Norm, nicht die Ausnahme.
As Low-Code/No-Code blüht im Unternehmen weiter auf, bewusst oder unbewusst, ist es für Sicherheits- und IT-Teams von entscheidender Bedeutung, sich an Gesprächen über die Geschäftsentwicklung zu beteiligen. Low-Code/No-Code-Apps werden mit a einzigartige Reihe von Sicherheitsherausforderungen, und ihre produktive Natur bedeutet, dass diese Herausforderungen schneller als je zuvor akut werden.
