SaaS-Passwörter sind wie Kakerlaken

Und im Falle von Passwörtern ist jedes einzelne - vor allem jedes vergessene - ein kleines Sicherheitsrisiko, das im Schatten herumhuscht. Sie denken vielleicht, dass Sie sie losgeworden sind (oder sie zumindest auf eine überschaubare Anzahl reduziert haben), aber sie tauchen immer wieder auf. Und wie wir alle wissen, haben SaaS-Anwendungen, ob es sich nun um private oder soziale Anwendungen wie Facebook oder die Tausenden von Geschäftsanwendungen handelt, die heute im Einsatz sind, dazu geführt, dass sich dieses Problem, nun ja... schnell vervielfacht hat.

Der wichtigste Grund, warum Identitätsmanagement-as-a-Service (IDaaS) Angebote wie Azure Active Directory, Okta und andere heute so beliebt sind, ist, dass sie eine einmalige Anmeldung (SSO) bei SaaS-Anwendungen über den Browser des Benutzers ermöglichen. Außerdem sorgen sie für mehr Sicherheit, indem sie diese Benutzerkennungen und Passwörter verwalten. Der Benutzer greift einfach auf ein Unternehmensportal zu, das Symbole für die Anwendungen enthält, und klickt auf ein Symbol, um sich anzumelden.

Obwohl diese Möglichkeit eine Verbesserung gegenüber einer nicht verwalteten Anmeldung darstellt, gibt es immer noch erhebliche Sicherheitsrisiken, die Sie kennen sollten.

SaaS-Passwort-Wirrwarr: Vaulting und Replay

Zunächst ein wenig Hintergrundwissen darüber, wie IDaaS-Anwendungen mit Website-Anmeldedaten umgehen.

Die größten und beliebtesten SaaS-Apps für Unternehmen wie Salesforce, Workday, Concur und einige hundert andere unterstützen Identitätsverbund, der die Anmeldung bei einer App drastisch vereinfacht und ihre Sicherheit erhöht. Die überwiegende Mehrheit der SaaS-Anwendungen auf dem Markt erfordert jedoch eine Benutzerkennung und ein Passwort, um sich über den Browser des Benutzers anzumelden - eine chaotische Angelegenheit, die von vergessenen Passwörtern, zu einfachen Passwörtern und Klebeblöcken mit aufgeschriebenen Passwörtern geprägt ist.

IDaaS-Dienste verwenden zwei Haupttechniken, um diese Aufgabe für den Benutzer zu übernehmen. Erstens: Wenn sich ein Benutzer zum ersten Mal bei einer dieser "formularausfüllenden" Websites anmeldet, fragt eine Erweiterung zur Erfassung des Passworts in seinem Browser, ob er seine Anmeldedaten im Passwort-Tresor des IDaaS-Dienstes speichern möchte. Zweitens: Wenn sich der Benutzer das nächste Mal bei der SaaS-Anwendung anmelden möchte, kommuniziert die Browsererweiterung mit dem IDaaS-Dienst, um die Anmeldedaten des Benutzers in die Felder für die Benutzerkennung und das Kennwort einzutragen und sich so ohne Zutun des Benutzers anzumelden.

Die entlaufenen Passwörter

Die Speicherung von Passwörtern vereinfacht die Anmeldung bei diesen Anwendungen erheblich, vor allem im Vergleich zu dem Versuch des Benutzers, den Überblick über alles selbst zu behalten. Aber es ist aus fünf Gründen ein Kaugummi-und-Draht-Ansatz für die Sicherheit.

• Erstens bedeutet dies, dass die Anmeldedaten des Benutzers im Cloud-Service des IDaaS-Anbieters gespeichert werden, was für die IT-Sicherheitsrichtlinien vieler Unternehmen ein absolutes Tabu darstellt.
• Zweitens müssen die Zugangsdaten, egal wie verschlüsselt sie in der Cloud sind, während der Wiedergabe im Klartext an die SaaS-App übertragen werden. Es gibt keine Möglichkeit, das zu umgehen. Drittens ändern sich die Layouts der Anmeldeseiten für die App-Benutzer ständig, so dass der IDaaS-Anbieter versuchen muss, mit Tausenden dieser Änderungen Schritt zu halten, damit die Passwortwiedergabe korrekt funktioniert.
• Viertens: In den meisten Fällen kennt der Benutzer seine Benutzerkennung und sein Passwort für die App. (Das taten sie auf jeden Fall, bevor sie auf die App über das Benutzerportal des Unternehmens zugreifen mussten.) Das bedeutet, dass er das Portal jederzeit umgehen und sich direkt anmelden kann. Wenn es sich um eine neue App handelt, die in Betrieb genommen wird, unterstützen einige IDaaS-Anbieter den Administrator, der die Anmeldedaten des Benutzers für ihn hochlädt, so dass der Benutzer sie nicht kennt und daher das Portal verwenden muss - aber das funktioniert nur für das Onboarding neuer Apps. Einige IDaaS-Anbieter haben eine begrenzte Möglichkeit, das Passwort für einige wenige Apps zu ändern, und einige können die Anmelde-URL der App verschleiern, aber das ist nur eine kleine Minderheit. Um die Situation noch zu verschlimmern, bieten Browser wie Chrome oder Browser-Add-Ins wie LastPass an, das Passwort des Benutzers bei der Anmeldung zu speichern. Und warum sollte der Durchschnittsnutzer sein Passwort nicht speichern wollen, damit er es nicht noch einmal eingeben muss?

Und schließlich und vor allem sind die SaaS-Anwendungen nicht mit dem Corporate Identity Lifecycle Management-System verbunden. Was bedeutet das? Wenn Sie einem Mitarbeiter kündigen und sein Konto in seinem lokalen AD DS deaktivieren, kann sich der Benutzer nicht mehr beim Unternehmensnetzwerk anmelden oder auf dessen Ressourcen zugreifen. Wenn sich diese Deaktivierung auf den IDaaS-Dienst überträgt, kann der Benutzer nicht mehr auf Cloud-Ressourcen zugreifen, für die der IDaaS-Dienst erforderlich ist, wie z. B. föderierte Anwendungen (Salesforce, Office 365). Das ist gut so und macht die Sicherheitsleute glücklich.

Aber SaaS-Anwendungen zum Ausfüllen von Formularen hängen nicht von Ihren Unternehmensanmeldeinformationen ab, wie dies bei SaaS-Anwendungen im Verbund der Fall ist. Wenn das AD DS-Benutzerkonto deaktiviert oder gelöscht wird, passiert bei dieser SaaS-Anwendung nichts. Sie hat keine Ahnung, was in Ihrem Unternehmen passiert ist. Es sei denn, jemand überprüft ausdrücklich, auf welche Anwendungen der Benutzer Zugriff hat, und deaktiviert sie manuell in jeder Anwendung. Und warum? Alles, was der Benutzer braucht, sind seine Benutzerkennung, sein Passwort und die Anmelde-URL der App.

Ich sollte darauf hinweisen, dass diese Probleme nicht die Schuld des IDaaS-Anbieters sind. Er tut sein Bestes, um mit verschiedenen Verschleierungstechniken die inhärenten Schwächen des Anmelde-Szenarios für SaaS-Apps auszugleichen.

Zusammenfassend lässt sich sagen, dass die Bereitstellung von Benutzern für Anwendungen relativ einfach ist. Die De-Provisionierung ist eine ganz andere Sache.

 Was Organisationen tun können

Dies ist ein Problem, das sich im Nachhinein nur schwer beheben lässt. Stattdessen müssen Sie es in Angriff nehmen:

• Überprüfen Sie die SaaS-Anwendungen, auf die ein Benutzer Zugriff hat, und speichern Sie diese in einer zentralen Berechtigungsdatenbank, damit Sie wissen, worauf jeder Zugriff hat. Dies ist eher ein Problem der Richtlinien und Prozesse als ein technologisches Problem.
• Verwenden Sie die Gruppenrichtlinie, um den Chrome Passwort-Manager zu deaktivieren.
• Verwenden Sie, wenn möglich, eine Option, um das Passwort des Benutzers automatisch zu generieren und zu sichern, damit er es nicht kennt.
• Wenn Ihr Unternehmen SaaS-Anwendungen evaluiert, sollte die föderierte Anmeldung eine Voraussetzung sein - kein "nice to have". Stellen Sie sicher, dass der ISV dies weiß. Nur die Anforderungen der Kunden (d.h. der Vertrieb) veranlassen die ISVs, Änderungen vorzunehmen.

IDaaS-Anbieter können für Ihre Benutzer von großem Nutzen sein, indem sie SSO für viele SaaS-Anwendungen über ein einziges Benutzerportal und mehrere Formfaktoren anbieten. Sie sind auch ein großer Vorteil für die Informationssicherheit, weil sie ein gewisses Maß an zentraler Verwaltung für diese Anwendungen bieten. Aber Sie müssen trotzdem Maßnahmen ergreifen, um diese Lösung sicher zu machen.