Sean Deuby | Leitender Technologe, Amerika

Und was Passwörter angeht, stellt jedes einzelne – insbesondere jedes vergessene – ein kleines Sicherheitsrisiko dar, das im Verborgenen lauert. Sie mögen vielleicht glauben, Sie hätten sie losgeworden (oder zumindest auf eine überschaubare Anzahl reduziert), doch sie tauchen immer wieder auf. Und wie wir alle wissen, haben SaaS-Anwendungen – seien es private oder soziale Apps wie Facebook oder die Tausenden von Geschäftsanwendungen, die heute im Einsatz sind – dazu geführt, dass sich dieses Problem, nun ja … rasant 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 kennt der Benutzer in den meisten Fällen seine Benutzer-ID und sein Passwort für die App. (Dies war sicherlich der Fall, bevor er verpflichtet wurde, über das Benutzerportal des Unternehmens auf die App zuzugreifen.) Das bedeutet, dass er das Portal jederzeit umgehen und sich direkt anmelden kann. Handelt es sich um eine neue App, die in Betrieb genommen wird, unterstützen einige IDaaS-Anbieter die Möglichkeit, dass der Administrator die Anmeldedaten des Benutzers für diesen hochlädt, sodass der Benutzer diese nicht kennt und somit das Portal nutzen muss – dies funktioniert jedoch nur bei der Einbindung neuer Apps. Einige IDaaS-Anbieter bieten in begrenztem Umfang die Möglichkeit, das Passwort für wenige Apps zu ändern, und manche können die Anmelde-URL der App verschleiern, doch dies ist nur bei einer winzigen Minderheit der Fall. Erschwerend kommt hinzu, dass Browser wie Chrome oder Browser-Erweiterungen wie LastPass dem Nutzer bei der Anmeldung praktischerweise anbieten, sein Passwort zu speichern. Und warum sollte der durchschnittliche Nutzer das Passwort nicht speichern wollen, um es nicht erneut eingeben zu müssen?

Schließlich – und das ist der wichtigste Punkt – sind die SaaS-Anwendungen nicht in das System zur Verwaltung des Lebenszyklus von Unternehmensidentitäten eingebunden. Was bedeutet das? Es bedeutet: Wenn Sie einem Mitarbeiter kündigen und dessen Konto in Ihrem lokalen AD DS deaktivieren, kann sich der Benutzer nicht mehr im Unternehmensnetzwerk anmelden oder auf dessen Ressourcen zugreifen. Sobald diese Deaktivierung an den IDaaS-Dienst weitergeleitet wird, kann der Benutzer nicht mehr auf Cloud-Ressourcen zugreifen, die den IDaaS-Dienst erfordern, wie beispielsweise föderierte Anwendungen (Salesforce, Office 365). Dies ist vorteilhaft und stellt die Sicherheitsverantwortlichen zufrieden.

SaaS-Anwendungen zum Ausfüllen von Formularen sind jedoch nicht auf Ihre Unternehmenszugangsdaten angewiesen, wie dies bei föderierten SaaS-Anwendungen der Fall ist. Wenn dieses AD DS-Benutzerkonto deaktiviert oder gelöscht wird, hat dies keinerlei Auswirkungen auf die betreffende SaaS-Anwendung. Diese hat keine Kenntnis davon, was im Unternehmen geschehen ist. Sofern nicht ausdrücklich überprüft wird, auf welche Anwendungen der Benutzer Zugriff hat, und diese in jeder einzelnen Anwendung manuell deaktiviert werden, kann der Benutzer weiterhin darauf zugreifen. Warum? Der Benutzer benötigt lediglich seine Benutzer-ID, sein Passwort und die Anmelde-URL der Anwendung.

Ich möchte darauf hinweisen, dass diese Probleme nicht dem IDaaS-Anbieter anzulasten sind; dieser tut sein Bestes und greift dabei auf verschiedene Ablenkungsmanöver zurück, um die dem Anmeldeszenario einer SaaS-Anwendung zum Ausfüllen von Formularen innewohnenden Mängel zu kaschieren.

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 weitaus mehr ein Problem policy Prozesse als ein technologisches Problem.
  • Deaktivieren Policy den Chrome-Passwortmanager mithilfe Policy .
  • Verwenden Sie nach Möglichkeit eine Option, mit der das Passwort des Benutzers automatisch generiert und in einem Tresor gespeichert wird, sodass dieser 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.