Single Sign On: Fragen, die man stellen sollte

Opa hat immer gesagt: „Versuche nie etwas Neues. Warte ab und sieh zu, ob es jemanden umbringt.“ In letzter Zeit war ich an der Umsetzung mehrerer Single Sign On Projekte beteiligt, und seine Worte schwebten ständig im Hinterkopf. Ein Teil von mir sagt: „Es ist eine schlechte Idee, nur einen Benutzernamen und ein Passwort für alles zu haben.“ Wenn ein Hackerangriff stattfindet und der Eindringling an ihre Sachen kommt, hat er Zugang zu allem. Aber der andere Teil sieht es und sagt: „Die Benutzer werden das lieben.“ Es ist eine klassische Situation, dumm zu sein, wenn man es tut, und dumm, wenn man es nicht tut. Also, was tun Sie?

Was ist Single Sign On?

Wenn man sich Single Sign On (SSO) zum ersten Mal aus der Perspektive einer Person ansieht, die sich mit Sicherheit auskennt, aber die Feinheiten davon nicht versteht, erscheint SSO wie ein unternehmerischer Selbstmord. Der Name allein, Single Sign-On, ruft Bilder hervor, bei denen man ein und dieselben Anmeldeinformationen für alles verwendet, aber letztendlich ist es dazu gedacht, das Leben Ihrer Benutzer zu erleichtern, ohne die Sicherheit zu gefährden. Was Sie tun, ist, sich etwas zunutze zu machen, das SAML (Security Assertion Markup Language, nicht weniger) genannt wird. Dies ist ein XML-basiertes, Open-Source-Datenformat, das es uns ermöglicht, Authentifizierungs- und Autorisierungsdaten zwischen verschiedenen Anwendungen oder Parteien auszutauschen. Tatsächlich verstärkt es die Dinge ein wenig, indem es sozusagen eine weitere Ebene hinzufügt, indem es die Benutzerinformationen des AD oder LDAP nutzt.

Also haben wir die Sicherheit dadurch erhöht, dass wir untersuchen, wie sie bereits in AD gewährte Rechte beeinflussen. In den meisten Fällen, wenn eine separate Benutzername/Passwort-Kombination mit einer Anwendung verbunden ist, wird diese einmal eingegeben, und die SSO-App gewährt uns Zugang. Das klingt vielleicht ein wenig beängstigend, aber bedenken Sie, dass typische AD-Sperrungen immer noch funktionieren und wir den zusätzlichen Vorteil haben, dass, wenn das Konto kompromittiert ist, die meisten SSO-Software einige wirklich leistungsstarke Berichtsfunktionen bieten. So können wir kompromittierte Konten und aufgerufene Daten erkennen.

Fragen, die man stellen sollte, bevor man sich für Single Sign On entscheidet

Ich werde hier einmal mein eigener Advocatus Diaboli sein und die Frage stellen, die alle beschäftigt. Wie sicher ist es wirklich?

Nun, wie der Teufel, werde ich Sie mit der Antwort hinhalten und sagen, dass wir uns das in den kommenden Wochen ansehen werden. Gehen wir derzeit davon aus, dass Sie Single Sign On in Ihrer Organisation einführen möchten. Wenn Sie SSO in Ihrer Organisation wünschen, gibt es ein paar Dinge, über die Sie nachdenken sollten.

An erster Stelle, sprechen wir über etwas Neues oder etwas, das wir aktualisieren? Oft handelt es sich um ein neues SSO-Produkt, das ein altes ersetzt. Genau dort müssen Sie anfangen, über Schulungen und Kommunikation nachzudenken. Kommunikation – damit die Benutzer verstehen, was vor sich geht, Schulung (selbst wenn es nur ein Online-Video ist) – wie das neue Produkt verwendet wird.

Was versuchen wir damit zu erreichen? Versuchen wir den Zugriff zu zentralisieren? Versuchen wir die Sicherheit durch bessere Autorisierung zu verbessern? Oder geht es einfach nur um die gute alte Überwachung? Vielleicht versuchen wir alle drei Ziele zu erreichen. Letztendlich ist es sehr hilfreich für den Erfolg eines Projekts, wenn man weiß, was einen am Ende erwartet.

Es ist sehr wichtig, frühzeitig zu entscheiden, zu welchen Anwendungen wir Zugang gewähren möchten. Die meisten Anwendungen funktionieren problemlos mit einem SSO, aber andere nicht. Die „anderen“ könnten Ihnen das Leben wirklich schwer machen und Drittanbieter sowie einiges an Kreativität erfordern, um sie zum Laufen zu bringen. Rechnen Sie also damit.

Wer wird sich darum kümmern? Jemand muss für das System verantwortlich sein, und es kann sein, dass mehrere Personen auf verschiedenen Ebenen des Unternehmens damit betraut werden. Zum Beispiel war ich bei einem kürzlichen SSO-Projekt dafür verantwortlich, es auf den Servern einzurichten, bei der Verwaltung des Projekts zu helfen und die ersten Anwendungen sowie das Anlegen der Benutzer vorzunehmen. Es wurde jedoch frühzeitig festgelegt, dass in Zukunft neue Benutzer von den Mitarbeitern der Stufe 1 hinzugefügt werden würden. Also mussten wir sie bis zu diesem Punkt schulen. Anwendungen jedoch, sowie die Pflege und Wartung der Server (ganz zu schweigen von zukünftigen Upgrades und DR) würden fest in meiner Hand liegen.

Wahrscheinlich ist das mit Abstand wichtigste, auf das wir achten müssen, ob das SSO, das wir kaufen, weiter wächst und sich entwickelt, während das Unternehmen wächst und sich entwickelt.

Und wie man in den 60ern zu sagen pflegte, berühren Sie nicht den Drehknopf.