Um Prozesse zu beschleunigen und somit effizienter zu arbeiten, ist die Verfügbarkeit von Remote-Diensten über das Internet heute unabdingbar. Doch dies birgt beispielsweise bei fehlender Verschlüsselung höhere Risiken für das Unternehmen. In der klassischen Konfiguration wird oft nur auf Benutzername und Passwort zur Anmeldung gesetzt, während die Verbindung zwischen Endnutzer und Rechenzentrum nicht gesichert ist. Häufig befinden sich die Remote-Desktop-Sitzungshosts und virtuellen Desktops aber mitten im Herzen des eigenen Rechenzentrums oder einer in die Cloud ausgelagerten Infrastruktur. Ein unbefugter Zugriff darauf hätte sehr schnell fatale Folgen für die IT, die Daten oder das Geschäft. Zur Absicherung konnten IT-Verantwortliche bisher externe Authentifizierungs-Provider nutzen. Mit Microsoft Azure ist nun die Bereitstellung von Remote-Desktops sowie die Authentifizierung aus einer Hand möglich.
Seit der grundlegenden Überarbeitung der Remote-Desktop-Dienste mit Windows Server 2012 und dem stetigen Ausbau von Microsoft Azure gibt es zahlreiche Nutzungsszenarien, auch für große Unternehmen. In vielen Fällen sind dafür nicht einmal zusätzliche Citrix-Lizenzen erforderlich, um die gestellten Anforderungen zu erfüllen. Die Dienste können heute sehr flexibel betrieben werden, von On-Premise über hybride Szenarien bis hin zu rein Cloud-basierten Lösungen. Besonders einfach ist es beispielsweise, Remote-Desktop-Sitzungshosts (klassische Terminalserver) und virtuelle Desktops per Internet für die Endanwender des Unternehmens bereitzustellen. Auch für Dienste, die dem Datenschutz unterliegen, ergeben sich, nach der Ankündigung von Microsoft, Azure Dienste direkt aus deutschen Rechenzentren beziehen zu können, demnächst neue Möglichkeiten.
Neuer Ansatz für Remote-Desktop-Dienste
Die ersten Remote-Desktop-Dienste gab es bereits 1970 auf Mainframes und ohne Internet. Heute nehmen sie, egal ob Microsoft mit oder ohne Citrix, oder auf einer ganz anderen Plattform, beim IT-Betrieb eine zentrale Rolle ein. Denn im Gegensatz zu Virtual Private Networks (VPN) bleibt die eigentliche Ressource im Rechenzentrum. Nur das Abbild samt den Ein- und Ausgaben wird über die Leitung geschickt. Eine gesicherte Veröffentlichung jedoch war zu Beginn nur gegen Aufpreis mit dem Microsoft-eigenen Firewall Produkt ISA Server (später TMG) möglich. Gerade in kleinen Unternehmen und im Mittelstand kam es deshalb mitunter vor, dass das unsichere Remote Desktop Protokoll (RDP) per NAT direkt im Web veröffentlicht wurde.
Mit Windows Server 2008 bestand erstmals die Möglichkeit der sicheren Veröffentlichung von Remote-Desktop-Ressourcen über das Remote-Desktop-Gateway als Teil des Betriebssystems. Sichere Veröffentlichung bedeutet die Kapselung des RDP in HTTP. Seitdem wurde die gesamte Technologie stark weiterentwickelt und mit Windows Server 2012 auf ein neues Level gehoben. Während die Konfiguration früher mühsam war, übernehmen heute Assistenten den Großteil der Arbeit. Server-Manager können heute als "Single Point of Administration" auch komplexe Remote-Desktop-Farmen im Überblick behalten.
Aus technischer Sicht spielt es keine Rolle mehr, ob die Dienste On-Premise, in einer Cloud oder sogar in beidem zu Hause sind - die gestellten Anforderungen sind nahezu identisch. Das Ziel: Remote-Ressourcen sollen möglichst kostengünstig, sicher und von überall erreichbar sein.
Der Weg zur Mehrfach-Authentifizierung
In der heutigen, digitalen Welt haben Informationen und Daten einen unschätzbaren Wert - der besonders geschützt werden muss. Deshalb reichen E-Mail und Passwort oft nicht mehr aus. Denn für Kriminelle ist das Ausspähen dann eine der leichteren Übungen. Gefälschte E-Mails an die Buchhaltung sind schnell gesendet und schon stehen Tür und Tor offen, um sich am Remote Desktop WebAccess anzumelden und eine Verbindung direkt in das Rechenzentrum aufzubauen. Während es bei Transaktionen im Online-Banking ganz normal ist, uns mit einer weiteren Komponente zu schützen, brauchen Angreifer durch Single-Sign-On meist keine separaten Passwörter mehr und können direkt mit dem Ausspähen von Informationen beginnen.
Multi-Faktor-Authentifizierung ist eigentlich bereits Branchenstandard im Netz. Doch es verwundert mitunter, dass sogar große Anbieter mit der Umsetzung des zusätzlichen Sicherheitsfaktors noch hinterherhinken. Beim Onlinehändler Amazon beispielsweise besteht erst seit Kurzem die Möglichkeit, das Konto durch einen weiteren Faktor zu schützen.
Multi-Faktor-Authentifizierung in Microsoft Azure einrichten
2012 hat Microsoft Phonefactor gekauft, einen Spezialisten für Multi-Faktor-Authentifizierung. Etwa ein Jahr später wurde der Dienst als Azure Multi-Factor Authentication (MFA) in das Azure Portfolio integriert. Mit Azure Remote-App verfolgt Microsoft seit 2015 einen rein Cloud-basierten Ansatz zum Betrieb dieses Dienstes. Klassische Remote Desktops oder virtuelle Desktops hingegen können immer noch komplett On-Premise sein, aber auch als VMs in Azure ausgeführt werden. Seit der Veröffentlichung der beiden Dienste lässt sich bei Microsoft von einem ganzheitlichen Ansatz sprechen.
Foto: Fritz & Macziol
Bisher konnte man auf On-Premise oder Cloud-basierte Authentifizierungsprovider setzen. Beide zogen in der Regel hohe Lizenz- und Hardwarekosten nach sich. So kostet allein der Hardwaretoken schnell einige Euro pro Benutzer pro Monat. Genau hier setzt Microsoft mit seinem Preis- Leistungsverhältnis an und bietet drei verschiedene Versionen: Office 365, Azure Administratoren und Azure Multi-Factor Authentication. Die ersten beiden sind jeweils für das benannte Produkt und werden in der Cloud direkt zum Service angeboten. Azure Multi-Factor Authentication bezeichnet die Version, die auch On-Premise installiert werden kann. Warum eigentlich On-Premise und dann doch in der Cloud? Dazu muss man sich die Architektur des Dienstes anschauen.
Die Dienst-Architektur im Detail
In der On-Premise Variante besteht der Dienst aus einem lokalen MFA Server und einem MFA Service in der Azure Cloud. Dabei gliedert sich der MFA Server in verschiedene Rollen:
- MFA Server - Hauptkomponente
- MFA Userportal (Optional) - Self Service Portal für Benutzer
- MFA SDK (Optional) - Integration in eigene Cloud oder On-Premise Anwendungen
- MFA Mobile App (Optional) - Softwaretoken für Smartphones
Im MFA Server selbst wird das Produkt konfiguriert. Neben der Benutzerpflege, können unternehmensweite Richtlinien, Sicherheitsfragen oder zur Verfügung stehende Anmeldemethoden konfiguriert werden. Darüber hinaus werden Schnittstellen für die Anwendungen zur Verfügung gestellt, welche letztlich den Dienst nutzen sollen. Weiterhin sind das Logging sowie der automatische E-Mail-Versand einzustellen, beispielsweise die Willkommens-E-Mail bei neu angelegten Benutzern. Dies ist sehr komfortabel, denn jede E-Mail-Vorlage kann individuell angepasst werden. Im Azure Portal stehen weitere Konfigurationsoptionen bereit. So können Reports zur Nutzung erzeugt oder individuelle Sprachansagen hochgeladen werden. Innerhalb des Portal lässt sich auch einstellen, wie mit Betrugswarnungen und Kontosperrungen umzugehen ist. Der Dienst bietet verschiedene Überprüfungsmethoden an, die zentral oder individuell pro Benutzer festgelegt werden können.
- Telefonanruf mit Bestätigung durch Drücken der # Taste
- Telefonanruf mit zusätzlichem PIN
- Textnachricht mit sechsstelligem Code der eingegeben werden muss
- Textnachricht mit zusätzlichem PIN
- Mobile App
- Mobile App mit zusätzlichem PIN
- OATH-Tokens von Drittanbietern
Folgende Schritte laufen bei der Nutzeranmeldung ab.
(1) Der Benutzer will auf eine On-Premise App zugreifen und meldet sich mit seinen Benutzernamen und Passwort an.
(2) Die App kommuniziert nicht direkt mit dem Active Directory, sondern gibt die Anfrage an den MFA Server weiter.
(3) Der MFA Server sendet die Anmeldedaten an das Active Directory.
(4) Der MFA Server erhält eine positive oder negative Antwort vom Active Directory.
(5) Sind die Anmeldedaten korrekt, fordert der MFA Server die zusätzliche Authentifizierung des Benutzers an, dazu werden folgende Daten in die Cloud übertragen:
- Eindeutige ID: Benutzername oder interne ID des MFA-Servers
- Vor- und Nachname: optional
- E-Mail-Adresse: optional
- Rufnummer: für eine Anruf- oder SMS-Authentifizierung
- Gerätetoken: für die Authentifizierung einer mobilen App
- Authentifizierungsmodus
- Authentifizierungsergebnis
- Name des MFA-Servers
- MFA-Server-IP
- Client-IP - falls verfügbar
(6) Der Cloud Service kontaktiert entsprechend der gewählten Methode den Benutzer.
(7) Der Benutzer authentifiziert sich am MFA Cloud-Dienst.
(8) Die Antwort wird zurück an den lokalen MFA Server geschickt.
(9) Der MFA Server meldet der On-Premise den Erfolg oder die Ablehnung.
(10) Die Authentifizierung wird abgeschlossen und der Benutzer kann auf die App zugreifen.
Dank des Authentication-SDK gibt es zahllose Nutzungsszenarien. Es ist verfügbar für C#, Visual Basic (.NET), Java, Perl, PHP und Ruby. Damit kann der Dienst wunderbar in eigene Anwendungen integriert werden. Aber auch zahlreiche Standardkonfigurationen, wie Active Directory-Verbunddienste (ADFS), RADIUS-Authentifizierung, IIS-Authentifizierung, Windows-Authentifizierung und LDAP-Authentifizierung stehen bereit.
Foto: Fritz & Macziol
Insbesondere RADIUS ermöglicht eine hohe Anzahl an Nutzungsszenarien, ob wie im Beispiel zur Sicherung des Remote Desktop Gateway / Citrix NetScaler, oder gleich für VPN Server. Die IIS-Authentifizierung eignet sich wiederum sehr gut zur Absicherung von SharePoint oder Outlook Web App Veröffentlichungen.
Azure Multi-Factor Authentication ist im Lieferumfang von Azure Active Directory Premium enthalten, kann aber auch separat lizenziert werden. Bei der separaten Lizenzierung gibt es zwei Abrechnungsmodelle. Entweder pro Benutzer und Monat 1,1807 Euro für unbegrenzte Authentifizierungen, oder 1,1807 Euro pro zehn Authentifizierungen (Stand: 22.11.2015). Entscheidend bei der Benutzerlizenzierung sind die im MFA Server aktivierten Benutzer. Das Abrechnungsmodell kann im Nachhinein nicht mehr geändert werden.
Grund-Installation
Die Installation startet mit der Standardinstallation einer Remote-Desktop-Umgebung. Im Testaufbau (Bildergalerie) werden die Funktionen dediziert jeweils auf einem Server ausgeführt. Nachdem auf dem zukünftigen Verbindungsbroker alle Server im Server-Manager hinzugefügt sind, erfolgt die Installation über den Assistenten für Rollen und Funktionen. Es wird eine sitzungsbasierte Bereitstellung gewählt, die einer klassischen Terminalserverumgebung entspricht. Die Installation des Remote-Desktop-Gateway und Lizenzservers sind optionale Schritte, die im Nachgang über die Übersicht der Remote-Desktop-Dienste im Server-Manager gestartet werden. Der Testaufbau zeigt die am meisten verbreitete Variante. Die interne und externe Domäne sind unterschiedlich. Für die externe Domäne ist Split DNS im Einsatz. Das Gateway befindet sich in der Demilitarized Zone (DMZ) und wird ausschließlich mit Port 443 und 3391 im Internet veröffentlicht. Es kommt lediglich ein externes Zertifikat zum Einsatz, das zwei Namen beinhalten muss: rdgw.<ExterneDomäne> und rdcb.<ExterneDomäne>. Wenn das Zertifikat über den Servermanager an die Rollen gebunden wurde, muss der interne Name auf den externen Namen umgebogen werden, weil die Zertifikatskette sonst nicht stimmt. Dabei hilft ein Skript aus der Technet Gallery. Abschließend wird die Sicherheit durch einige Einschränkungen weiter erhöht, wie in den zehn Tipps (Infokasten) beschrieben.
Installation des Multi-Faktor-Providers
Nun geht es an die Installation des Multi-Faktor-Providers. Zu Beginn muss der Dienst im Microsoft Azure Portal im Menüpunkt Active Directory erstellt werden. Anschließend kann die lokale Serverkomponente heruntergeladen, installiert und mithilfe der generierten E-Mail und des Passwortes registriert werden. Damit ist die eigentliche Installation bereits abgeschlossen. Sollen Benutzer selbst Änderungen vornehmen können, wie die Handynummer, den PIN oder die Methode ändern, wird das User Portal benötigt. Soll nun noch die Mobile App (eine Art Software Token) zur Anwendung kommen, benötigt man das Web Service SDK und das Portal der mobilen App. Alle drei Komponenten sind im Installationspfad des Servers zu finden. Die drei Rollen werden idealerweise auch in der DMZ betrieben und sind über Port 443 aus dem Internet erreichbar. Der MFA Server zieht die Benutzerdaten aus dem Active Directory nicht automatisch. Es empfiehlt sich einen Synchronisierungsjob einzurichten, der eine Active Directory Gruppe, zum Beispiel. "MFA-User" filtert. Das Verfahren setzt voraus, dass die Rufnummern der Benutzer im Active Directory gepflegt sind. Alternativ kann auch zugelassen werden, dass sich Benutzer ohne hinterlegte Rufnummer über das User Portal anmelden, um anschließend ihre private Handynummer direkt im MFA Server, abseits des Active Directory, zu hinterlegen. Im sichersten Verfahren verwendet der Benutzer bei der Authentifizierung zusätzlich eine PIN, die er bei der ersten Anmeldung kennen muss. Der PIN kann automatisiert in einer individualisierten Willkommens-E-Mail verschickt werden.
Im letzten Teil der Konfiguration muss das RD Gateway noch dazu gebracht werden, dass es erst verbinden soll wenn die Freigabe des MFA Providers erfolgte. Dazu wird die CAP des RD Gateway auf einen zentralen NPS umgestellt. Der MFA Server und der NPS Server werden nun untereinander zur Verwendung von RADIUS konfiguriert. Nach Freigabe der benötigten Ports ist der Zugriff auf die Ressourcen aus dem Internet nun durch Benutzername, Kennwort, den Azure MFA Dienst und optional durch eine PIN geschützt. Nachdem der Benutzer sich am RD Webaccess angemeldet hat und eine App startet, wird beim Verbindungsaufbau des RDP Kanals der zusätzliche Faktor abgefragt.
Multi-Faktor-Authentifizierung als Branchenstandard
Multi-Faktor-Authentifizierung sollte bei jeder Veröffentlichung sensibler Daten ins Internet Branchenstandard sein. Auch wenn der Benutzerkomfort durch die Eingabe zusätzlicher Daten minimal sinkt, ist die zusätzliche Sicherheit unverzichtbar - egal ob beim Wartungszugang oder dem permanenten Zugriff für Benutzer. Darüber hinaus findet mit den beiden Preismodellen eigentlich jedes Unternehmen die passende Lösung. (hal)