Unabhängig vom Gerät: Wer darf wo was?
Ohne Einschränkungen
Wer seine Geräte in einer einheitlichen Management-Struktur verwalten will, muss mit den Grundlagen seiner Architektur anfangen. Entscheidend ist: Wer soll mit welchen Geräten von wo auf was zugreifen können?
Niemand fängt heute ein IT-Projekt auf der grünen Wiese an. Die Architektur ist über lange Zeit gewachsen und entsprechend komplex. Da stehen eigene E-Mail-, App- und Fileserver im Rechenzentrum, das Unternehmensnetz ist durch eine Firewall gesichert und für mobile PCs gibt es ein VPN Gateway. PCs und Server verwaltet man mit dem SCCM (Systems Center Configuration Manager), die neuen Macs mit JAMF, iPhones und iPads mit MobileIron, und ein paar alte BlackBerrys hängen noch am BES.
Die heile Welt kommt ins Wanken, wenn auf einmal Cloud-Dienste auftauchen. Ein typisches Beispiel ist Microsoft 365, mit Windows 10 und Office 365. Gestern hing alles noch am Active Directory, aber jetzt taucht das Azure Active Directory auf. Und dann ist da noch die Schatten-IT mit Dropbox und Konsorten. Um die Kosten für die Flut neuer Rechner einzudämmen, sollen manche Mitarbeiter ihre privaten Geräte nutzen. Kurzum: Die Welt verkompliziert sich heillos, die IT-Truppe tritt beherzt auf die Bremse und die Chefetage gleichzeitig aufs Gas.
Hinaus in die Welt
Daten und Applikationen laufen heute nicht mehr nur versteckt hinter der Firewall, sondern zunehmend in Cloud-Datenzentren wie Microsoft Azure oder Amazon Web Services. Software as a Service (SaaS) ist längst Standard. Gleichzeitig erwarten Nutzer zunehmend einen mobilen Arbeitsplatz: Den festen Schreibtisch hinter hohen Firmenmauern ersetzen Smartphones, Tablets und Notebooks (siehe Seite 36). Dabei spielt es keine Rolle, ob sie im Meeting, im Café, zu Hause oder auf Geschäftsreise zum Einsatz kommen. Laufen unternehmenskritische Anwendungen wie bei Office 365 komplett im Browser, verschwindet die Bedeutung der vom Unternehmen bereitgestellten Endgeräte.
So faszinierend die Vorstellung einer konsequenten IT-Auslagerung in die Cloud und einer grenzenlosen Mobilisierung von Mitarbeitern sein mag, so sehr kommen auch Zweifel und Sicherheitsfragen auf. Wie lässt sich trotz all dieser Dynamik zwischen Nutzern, Clients und Diensten kontrollieren, wer unter welchen Bedingungen von welchem Endgerät und von wo auf welche Applikationen und Daten zugreifen darf? Einerseits darf ein gestohlenes Nutzerkonto nebst Passwort nicht ausreichen, um weitreichenden Zugriff auf Anwendungen in der Cloud zu erhalten, andererseits soll das Unternehmen seinen Mobilitätsgewinn nicht wieder dadurch einbüßen, dass sich wichtige Dienste grundsätzlich nur innerhalb des geschützten Firmennetzes verwenden lassen.
Kontrollgewinn mit Conditional Access
Gegen den Diebstahl von Identitäten hilft ein zweiter Anmeldefaktor, Multi-Factor Authentication (MFA) genannt. Der Anwender erhält hierzu zum Beispiel eine SMS mit einer Einmal-PIN (OTP) oder genehmigt die Anmeldung über eine Authenticator App auf seinem Smartphone. Auch Hardware wie RSA SecureID Token gehört zu diesem Zugangsschutz, der das Wissen (Kennwort) um den zweiten Faktor Besitz (Smartphone oder HW-Token) ergänzt.
Während MFA dabei hilft, das Wer zu kontrollieren, lässt sich so nicht ermitteln, von wo der Zugriff erfolgt. Handelt es sich um ein verwaltetes, vertrauenswürdiges Firmengerät mit aktuellem Virenscanner, einen geduldeten, privaten Rechner des Mitarbeiters mit begrenzter Absicherung des Unternehmensbereichs (BYOD) oder ein völlig unbekanntes System Dritter?
Gelingt es technisch zuverlässig, abgesicherte Unternehmensgeräte zu erkennen, lassen sie sich als alternativer Besitz für eine MFA heranziehen. Das weiß jeder zu schätzen, den die IT bei jedem Anwendungsaufruf selbst auf dem Firmengerät ständig zur Eingabe einer zusätzlichen Einmal-PIN zwingt. Dynamische Richtlinien können zum Beispiel sicherstellen, dass eine Anmeldung von einem firmenfremden System MFA fordert, sie beim Firmengerät hingegen benutzerfreundlicher ohne erfolgen kann.
Unterschiedliche Dienste stellen außerdem andere Anforderungen an ein Regelwerk zum Conditional Access. Während die unternehmenskritische SAP- oder BI-Anwendung aus der Cloud ausschließlich von verwalteten Firmengeräten erreichbar sein soll, möchte man der Zusammenarbeit förderliche Dienste wie Microsoft Teams ebenso auf privaten Systemen bereitstellen, hier aber zumindest die Identität des Anwenders per MFA gewährleisten. Höchst sensible Anwendungen, eingesetzt von privilegierten Nutzern mit weitreichenden Rechten, können schließlich eine Kombination von vertrauenswürdigem Firmengerät plus MFA erfordern.
Am Anfang steht Single Sign-On
Während der Bedarf für die bedingte Zugangskontrolle zu Unternehmensdiensten einleuchtet, stellt eine unternehmensweite und einheitliche Umsetzung für unterschiedliche Dienste und die gängigen Betriebssysteme Windows, macOS, iOS und Android eine Herausforderung dar.
Erste Erfahrungen mit Conditional Access haben viele Administratoren bereits bei der Absicherung des mobilen Zugriffs auf Exchange-Server in der Firma mit ActiveSync gesammelt: Ein ActiveSync-Proxy in der DMZ lässt hierzu ausschließlich die Mail-Agents passieren, die zuvor das MDM registriert hat und die zu diesem Zeitpunkt als konform zu den definierten Sicherheitsrichtlinien gelten.
Für eine unternehmensweite Conditional-Access-Strategie für Cloud-Dienste müssen aber andere Ansätze her. Weder möchte man den gesamten Payload-Traffic zum Cloud-Dienst – in diesem Beispiel Exchange Online als Teil von Office 365 – ineffizient durch die eigene IT-Infrastruktur schleusen noch individuelle Kontrollen für jedes Anwendungsprotokoll schaffen.