SafeNet Trusted Access und Microsoft MFA
„In meinem Microsoft Vertrag ist doch schon MFA enthalten, warum soll ich dafür noch eine eigene Lösung einsetzen?“
Eine Frage, mit der Partner heute sehr oft und immer häufiger konfrontiert werden – und wie so oft gibt es nicht die eine Antwort. Welche Lösung bei einem Endkunden am besten passt, ist abhängig von seiner Infrastruktur, seinen Zielen und Anforderungen.
Hybride Infrastrukturen
Microsoft MFA ist ausgelegt primär für eine „reinrassige“ Cloud-Infrastruktur und insbesondere für die eigenen Cloud-Dienste. Die Realität sieht aber oft anders aus: Kunden haben zumeist noch hybride Umgebungen und sind nur teilweise mit ihrer Infrastruktur oder Applikationen in der Cloud. Entweder, dass sie nur teilweise in Azure AD sind oder/und dass sie nach wie vor ihre klassischen On-Premise-Applikationen betreiben, wie z.B. ihre Remote-Access-Lösungen (VPN, Citrix, OWA). Für diese "Legacy" Applikationen ist Microsoft MFA in der Regel nicht geeignet. Mit den Agents, die STA zur Verfügung stellt, können dagegen neben den SAML/OICD-Webanwendungen (selbstverständlich integriert sich STA nahtlos in Microsoft-Umgebungen!) auch die klassischen Anwendungen mit MFA betrieben werden.Gleiches gilt auch für die Desktop-Anmeldung: Um Microsoft MFA hier nutzen zu können, müssen die entsprechenden Rechner zumindest in einer Azure Joined Domäne verwaltet werden, was oft nicht der Fall ist. Mit dem STA-Credential-Provider können User sich dagegen auch an Rechnern in einer lokalen Domäne mit MFA anmelden. Thales unterstützt dabei auch Apple-OSX und Linux sowie ältere Windows Versionen.
Token-Vielfalt
Die Multi-Faktor-Anmeldung in Microsoft MFA ist eigentlich auf die Verwendung einer Software-App wie dem Microsoft Authenticator ausgelegt. In Europa ist es aber nicht unbedingt üblich, dass Mitarbeiter, die über kein Firmen-Smartphone verfügen, sich eine solche App auf ihrem privaten Smartphone installieren und dieses dann für die Anmeldung im Unternehmen verwenden (was auch seitens der Unternehmen mangels Kontrollmöglichkeiten der Compliance solcher privaten Geräte auch nicht unbedingt gewünscht ist). Und viele weitere Szenarien sind vorstellbar, in denen eine Software-App nicht genutzt werden kann. Dann braucht es Alternativen – diese sind bei Microsoft MFA sehr beschränkt und z.B. im Falle von Hardware-Token mit teilweise erheblichem administrativen und logistischem Aufwand beim Rollout und in der Verwaltung verbunden.Bei Thales STA brauchen Sie sich darüber keine Gedanken zu machen:
Es gibt Software-OTP-Apps für iOS, Android, Windows Desktop, Mac OSX und Chrome OS; verschiedene Hardware-Token-Modelle und OTP-Karten im Scheckkartenformat – auch FIDO wird unterstützt. Einmal-Passwort über SMS oder E-Mail ist genauso möglich wie eine Web-basierte Anmeldung mit GrID Token; auch, wenn es sich ein bißchen verrückt anhört: es ist sogar möglich, einen „Anrufdienst“ zu nutzen und sich das gerade benötigte Einmalpasswort vorlesen bzw. buchstabieren zu lassen.
Der Rollout der Token kann komplett automatisiert werden, es stehen zahlreiche Selbsthilfe-Werkzeuge für die Benutzer zur Verfügung, so dass die Administration der Lösung und die Logistik für Hardware-Devices auch im laufenden Betrieb in einem überschaubaren Rahmen bleibt.
Management und Kosten von Hardware-Token
Im Gegensatz zu Thales STA mit der Fähigkeit, den Rollout von Token weitestgehend zu automatisieren und die Aktivierung/Provisionierung durch den Anwender selbst durchführen zu lassen, ist das Handling bei Microsoft nicht ganz unaufwändig.Zunächst sollte schon aus Sicherheitsaspekten kritisch betrachtet werden, dass für die Provisionierung der Hardware-Token in Azure MFA Globale Admin-Rechte benötigt werden.
Die Token werden über ein unverschlüsseltes csv-File in Azure importiert, dabei muss jedem Token der entsprechende Nutzer schon vorab innerhalb des csv zugewiesen werden, das vom Hersteller der Token gelieferte csv-File mit den Token Seeds muss also bearbeitet und ergänzt werden.
Nach dem Import der csv-Datei muss der Administrator jeden Token manuell aktivieren, jeder Token muss somit zuvor durch die Hände der Administration gehen, bevor er an den Benutzer ausgegeben wird. Dies mag bei kleinen Stückzahlen eine noch gerade akzeptable Vorgehensweise sein, bei größeren Stückzahlen aber eine echte Herausforderung darstellen.
Nebenbei: Microsoft selbst bietet keine Hardware-Token an, diese müssen bei Dritt-Anbieter vom Kunden zugekauft werden (auch von Thales sind Token für Microsoft MFA erhältlich). Allerdings werden diese mit der normalen Hersteller-Garantie ausgeliefert und müssen nach Ablauf der Garantie bei Defekt etc. kostenpflichtig ersetzt werden.
Hinzu kommt: Token lassen sich bei Microsoft MFA leider nicht re-synchronisieren, um einen während der Nutzungsdauer auftretenden Zeitversatz bei der Erzeugung der OTP's zu korrigieren - hier hilft dann nur ein Neukauf.
Vorteil STA: defekte Hardware-Token werden kostenlos ersetzt, solange ein Kunde STA im Einsatz hat und über eine gültige Subscription verfügt.
Nicht nur das: bei STA [Standard] und STA Premium stellt Thales die Hardware-Token OTP110 kostenlos zur Verfügung!
Und selbstverständlich lassen sich Token und STA Backend auch jederzeit wieder synchronisieren. Das kann der Benutzer mit Hilfe des Self-Service-Portales sogar selbst erledigen.
Software-Token ist nicht gleich Software-Token!
Eine App, die ein Einmal-Passwort erzeugt: was gibt es da schon zu beachten?Mit Sicherheit die Sicherheit!
Im Gegensatz zum Microsoft Authenticator (oder auch zum Google-Authenticator) verwendet Thales bei seiner Software-Token App, MobilePASS(+), für die Erzeugung und das Enrollment des Secrets das Dynamic Symmetric Key Provisioning Protocol (DSKPP). Dieses stellt sicher, dass das Secret sicher erzeugt, zwischen dem Backend von SafeNet Trusted Access und der MobilePASS(+)App beim Enrollment sicher ausgetauscht wird und nicht kopiert werden kann.
Bei Microsoft enthält der zum Enrolllment verschickte QR-Code das Secret - durch Kopieren dieses QR-Codes kann das Secret also jederzeit auf beliebig viele Smartphones ausgebracht werden. Bei MobilePASS(+) dagegen ist sichergestellt, dass ein ausgerollter Token auch nur auf dem Gerät verwendet werden kann, mit dem das Enrollment stattgefunden hat.
Der Teufel steckt im Detail
Manchmal muss man schon ganz genau hinschauen, um die Stolperdrähte zu entdecken. Hier ein Beispiel: Eine Anmeldung mit Microsoft MFA erfordert als Benutzernamen zwingend die E-Mail-Adresse des Benutzers. Erfordern Applikationen für das Login als Benutzernamen abweichende Formate oder einen dedizierten User-Namen, so kann Microsoft MFA dort nicht eingesetzt werden. Thales SafeNet Trusted Access unterstützt bei der Benutzeranmeldung auch andere Formate für das Usermapping. Es kann sogar genau definiert werden, für welche Applikation welches Benutzername-Format verwendet werden soll.
Tresor und Schlüssel im gleichen Raum aufbewahren?
Die Lösung, die den Zugang zu Ihren Daten schützen soll, befindet sich in der gleichen Infrastruktur wie die zu schützenden Daten selbst: Kunden nutzen die Azure-Cloud, um ihre Daten und Dienste auszulagern und schützen den Zugriff darauf durch Azure MFA. Wird diese Cloud-Infrastruktur kompromittiert, besteht die große Gefahr, dass auch die Schutzsysteme kompromittiert werden – aus diesen Überlegungen heraus ist es fast unabdingbar, Daten und Schutzsystem in unterschiedlichen Infrastrukturen zu betreiben.