Sicherer Zugang zu Cloudanwendungen

02.05.2018 / Cornelius Höchel-Winter /Referent

Cornelius Höchel-Winter

aus Netzwerk-Insider-Ausgabe Mai 2018

Mit der rasanten Zunahme von Anwendungen aus der Cloud (Software as a Service) und der verbreiteten Nutzung mobiler Endgeräte, rückt ein altes Thema erneut in den Vordergrund: die Absicherung des Zugriffs auf Unternehmensdaten. Cloudanwendungen greifen per Design sowieso nur auf Daten in der Cloud zu und die Nutzung von mobilen Endgeräten setzt voraus, dass auf die Daten von der jeweiligen Anwendung aus zugegriffen werden kann – unabhängig davon, wo sich diese Daten befinden: On-premises oder in der Cloud.

Natürlich gibt es eine Reihe von technischen Lösungen den direkten Zugriff von Endgeräten außerhalb des Unternehmensnetzes auf Daten innerhalb zu unterbinden, aber selbst wenn Sie auf VPNs (Virtual Private Networks) oder Application Streaming setzen, am zugrunde liegenden Problem ändert das nichts: Endgeräte haben von außerhalb Ihres Unternehmensnetzes Zugriff auf Ihre Daten.

Vorbemerkung
Wie immer, wenn es um die Sicherung von Zugängen geht, gibt es eine drastische Lösung: die komplette Blockierung des Zugriffs auf die Daten von unsicheren Netzbereichen aus.

Solange Ihre Daten innerhalb Ihres Netzes liegen, ist das technisch vergleichsweise einfach: Solange Ihre Perimeter-Firewall das tut, was sie soll, sind Zugriffe von außen nach innen blockiert und Ausnahmen, zum Beispiel VPN, müssen explizit freigegeben werden. Und die Frage, wie man verhindert, dass Daten von innen nach draußen kommen, liegt außerhalb dessen, was wir in diesem Artikel beleuchten wollen. Themen hier sind: Virenschutz, Data Loss Prevention (DLP), Gerätemanagement.

Liegen Ihre Daten aber sowieso schon in der Cloud, weil Sie beispielsweise CRM-Anwendungen wie Salesforce oder Kollaborationsplattformen wie Office 365 oder die Google G-Suite nutzen, müssen zusätzliche Funktionen eingeführt bzw. aktiviert werden, um den, in diesen Fällen ja standardmäßig erlaubten Zugriff auf diese Daten doch noch einzuschränken. Im Wesentlichen stehen Ihnen hier drei Möglichkeiten zur Verfügung:

  1. Der Service-Provider bzw. die Anwendung selbst bieten Funktionen an, um den Zugriff einzuschränken.
  2. Der Service-Provider bietet SSO-Funktionalität (Single Sign-On) an und Ihre SSO-Lösung bietet Funktionen an, um den Zugriff einzuschränken.
  3. Sie verschlüsseln die Daten so, dass Entschlüsselungsfunktionen nur innerhalb Ihres Netzwerks zur Verfügung stehen. Auch das geht meist nur mit der Unterstützung des Service-Providers, Azure Rights Management (Azure RMS) zusammen mit einem selbst verwalteten Schlüsselmanagement (HSM – Hardware Security Module) ist ein Beispiel für eine als HYOK (Hold Your Own Key) bezeichnete Lösung.

Wir werden die beiden erstgenannten Fälle weiter unten noch diskutieren.

So oder so, in beiden Fällen muss klar sein, dass Sie letztlich die Produktivität Ihrer Mitarbeiter zugunsten der Sicherheit Ihrer Daten einschränken! Hierfür mag es in besonderen Umgebungen oder bestimmten Situationen Gründe geben, Sie sollten solche Einschränkungen aber auf Ausnahmen beschränken, die Idee von Cloud-Anwendungen sowie der Nutzen von mobilen Endgeräten liegen im unbeschränkten Einsatz „jederzeit und von überall“ und der damit verbundenen Produktivitätssteigerung.

Anforderungen

Kommen wir zurück zum eigentlichen Thema: Wie sichere ich den – generell erlaubten – Zugriff auf Unternehmensdaten zuverlässig ab?

Im Zeitalter der Cloud bedeutet das zweierlei:

  1. Wie verhindere ich den nicht autorisierten Zugriff auf Endgeräte, auf denen gegebenenfalls Unternehmensdaten (zwischen)gespeichert sind, oder die Zugang zu Unternehmensanwendungen zum Beispiel via VPN haben?
  2. Wie sichere ich den Zugang zu Clouddaten respektive die Nutzung von Cloudanwendungen ab?

Sichere Passwörter

Beginnen wir ganz generisch. Egal ob Endgerät oder Anwendung, die klassische Authentifizierung – also die Prüfung der Authentizität des Benutzers – geschieht nach wie vor über Benutzername und Passwort. Die Nutzung sicherer Passwörter ist also essentiell für jedes Sicherheitskonzept, das Passwörter nutzt. Ansonsten könnte man gleich darauf verzichten.

Sichere Passwörter gerade für Endgeräte – auch für den Zugang zum Arbeitsplatzrechner – sind im Übrigen kein übertriebener Selbstzweck, um zu verhindern, dass sich die Kollegen Ihre Urlaubsbilder anschauen. Der Gesetzgeber verlangt sehr deutlich, dass es klare (und dokumentierte!) Regeln gibt, wer wann auf welche Daten zugreifen darf. Nachweisen können Sie das nur, wenn Sie ein paar offensichtliche Grundregeln einhalten:

  1. Sie verwenden ausschließlich persönliche Benutzerkonten.Mit funktionalen Benutzerkonten haben Sie in der Regel keine Möglichkeit nachzuweisen, wer tatsächlich an dem Rechner gearbeitet hat.

    Spannend in diesem Zusammenhang ist im Übrigen der Umgang mit sogenannten Administrator-Konten! Einerseits ist es zwar übliche Best-Practice, auch Administratoren und andere Mitarbeiter nicht standardmäßig mit administrativen Rechten auszustatten, andererseits sehen einige spezielle Geräte und auch eine Reihe von Cloud-anwendungen nur ein einziges Administrator-Konto vor. In diesen Fällen ist es angebracht, über Logging und Dokumentationspflichten (Stichwort „Change Management“) den Zugang und die Nutzung solcher Konten extra zu protokollieren.

  2. Kurze Inaktivitätszeitspannen bis der Bildschirm gesperrt ist. Benutzer neigen dazu, selbst in die Mittagspause oder abends nach Hause zu gehen, ohne ihren Arbeitsplatz zu sperren.
  3. Sichere Passwörter und der sichere Umgang damit. Selbstverständlich sollten Passwörter auch unter Kollegen nicht weitergegeben werden oder auf einem Post-it am Bildschirm kleben.

Mit Inkrafttreten der neuen Datenschutzgrundverordnung (DSGVO) der EU in ein paar Tagen sind Probleme in diesen Bereichen zumindest im Zusammenhang mit personenbezogenen Daten mit happigen Bußgeldern belegt! Übersehen Sie nicht, dass Sie als Unternehmen hier in der Beweispflicht stehen, alle Vorkehrungen getroffen zu haben, dass Ihre eigenen Regeln auch eingehalten werden. Bußgelder werden aber immer nur gegen natürliche Personen verhängt. Das heißt, auch Sie als Mitarbeiter stehen in der Verantwortung. Bei einem Fehlverhalten oder dem fahrlässigen Umgang mit sensiblen Daten trifft Sie nicht nur der Zorn Ihres Arbeitgebers, Sie müssen auch ganz persönlich mit rechtlichen und finanziellen Konsequenzen rechnen.

Rein formal haben Sie aber, unter Beachtung der oben aufgeführten Grundregeln, mit einer klassischen Zugangssteuerung via Benutzernamen und Passwort Ihre Anforderungen erfüllt. Der Großteil der Produkte bietet ja auch gar keine andere Form der Authentifizierung an.

Wie aber stellt man „sichere Passwörter“ sicher – und was ist das überhaupt?

Jahrzehntelang wurden wir mit Passwortrichtlinien gequält, die sicherstellen sollten, dass wir möglichst komplexe Passwörter nutzen und die dann auch noch alle paar Wochen wechseln. Ob und wie man sich solche Passwörter merken kann, bleibt üblicherweise unberücksichtigt.

Merkwürdigerweise hat kaum jemand diese Richtlinien je hinterfragt – und trotzdem wird man schon von jedem zweitklassischen Webshop aufgefordert, sein Passwort mit „mindestens einem Sonderzeichen, zwei Ziffern und drei Buchstaben“ auszustatten.

Erst in den letzten Jahren setzt hier ein Überdenken (von einem Umdenken sind wir noch etwas entfernt) ein.

Das NIST (National Institute of Standards and Technology) hat beispielsweise im vergangenen Jahr seine Richtlinie „Digital Identity Guidelines“ (800-63-3) komplett überarbeitet und eine Reihe klassischer Empfehlungen für den Umgang mit Passwörtern komplett gekippt. Hierzu gehören:

  • Regeln zur Zusammensetzung von Passwörtern wie mindestens ein Sonderzeichen und eine Ziffer oder sowohl Groß- als auch Kleinbuchstaben,
  • feste Zeiträume, in denen Passwörter ablaufen und ersetzt werden müssen,
  • sogenannte Hinweise zum Passwort oder die bekannten Fragen zum Geburtsnamen der Mutter oder Kosename des Haustiers.

Tatsächlich hat sich die Vorstellung „komplexe“ Passwörter (mit einem Mix aus großen, kleinen Buchstaben, Ziffern und Sonderzeichen) seien per se sicher als weniger komplexe Passwörter als nicht haltbar herausgestellt. (siehe Abbildung 1)

NIST: Digital Identity Model

Abbildung 1: NIST: Digital Identity Model

Die Motivation, die hinter dieser Regel steht, ist die Annahme, dass Angriffe auf Passwörter in erster Linie Brute-Force-Angriffe sind. Das ist falsch. Die Mehrzahl der erfolgreichen Angriffe basiert auf Angriffen auf schlecht gesicherte Datenbanken, über Schwachstellen der Serverbetriebssysteme, über Dictionary Angriffe, bei denen Sammlungen bekannter Passwörter ausprobiert werden, und über sogenanntes Social Engineering. Letzteres erstreckt sich von einfachen Phishing-Mails („Wir haben ein XY-Problem festgestellt, geben Sie hier Ihr Passwort ein.“), unverlangt zugesandten Gutscheinen für personalisierte Kaffeebecher (womit der Angreifer schon mal die Namen der Familienangehörigen kennt) bis zum konkreten Ausspähen des Arbeitsplatzes (wo ja auch gerne die Zettel mit den Passwörtern „versteckt“ werden).

Darüber hinaus zerschellen Forderungen nach komplexen Passwörtern aber auch geradezu an der Realität. Benutzer neigen dazu, leicht zu merkende Passwörter zu wählen. Aber „Pa$$w0rd“ ist eben kein besonders gutes Passwort, auch wenn alle vier Kategorien von Zeichensätzen verwendet werden. Das NIST empfiehlt in den neuen Richtlinien, keine übertriebenen Forderungen an Passwörter zu stellen. Tatsächlich kann man nachweisen, dass der Sicherheitsgewinn durch komplexe oder etwas längere Passwörter marginal ist – auch wenn solche Policies auf dem Papier durchaus gut aussehen und ein hohes Sicherheitsniveau vorgaukeln.

Wesentlich schwerer wiegt jedoch der Schaden, der mit solchen Richtlinien angerichtet wird. Frustrierte Benutzer sind erfindungsreich und suchen nach leichten Auswegen. Also werden Passwörter wie „FranzJosef-01“ oder „Pa$$word1“ gewählt und die hinteren Ziffern bei Ablauf des Passworts einfach hochgezählt. Offensichtlich erreicht man so kein sicheres Passwort. Ganz im Gegenteil: Solche schwachen Passwörter sind das Einfallstor zu öffentlich erreichbaren Systemen. Und spannenderweise kommen sehr viele Benutzer auf sehr ähnliche, wenn nicht gar gleiche Passwörter.

Auf dem Backend unseres Webservers werden pro Tag zwischen 1.000 und 5.000 fehlgeschlagene Login-Versuche registriert. Circa 80 % dieser Logins versuchen Standardbenutzernamen wie admin, administrator, siteadmin und Passwörter wie admin111, admin222, admin333 etc. Ab und an kann man auch Angriffe beobachten, die sogar Passwörter wie comconsult111, comconsult222 etc. testen. Der Rest sind klassische Dictionary-Angriffe, wo englische und deutsche Begriffe der Reihe nach ausprobiert werden – übrigens inklusive des oben genannten pa$$w0rd oder auch p@ssw0rd. Einen echten Brute-Force-Angriff habe ich in den letzten Jahren nicht beobachtet.

Ein weiterer Aspekt ist, dass nach aktuellen Untersuchungen heutzutage jeder zwischen 15 bis weit über 40 Benutzerkonten besitzt. Auch hier reagieren Benutzer typischerweise eher leichtfertig: Die einen schreiben die Passwörter auf – womit das zugrundliegende Konzept „Passwörter sind geheim und nur dem Benutzer bekannt.“ hochgradig gefährdet ist – und die anderen nutzen „Ihr“ Standardpasswort einfach immer wieder für die unterschiedlichsten Dienste im Internet. Aber gerade diese wiederholte Nutzung von Passwörter macht es Angreifern leicht, nach dem Hack eines eher unbedeutenden Web-Shops auch in gut geschützte Unternehmensnetze einzudringen.

Das NIST empfiehlt daher die „Usability“ der Systeme wieder stärker in den Vordergrund zu rücken und die Benutzer bei der Wahl sicherer Passwörter zu unterstützen, statt sie mit strengen Forderungen in die Verzweiflung zu treiben.

Hierzu gehört auch, dass Passwörter nur noch dann geändert werden sollen, wenn die Vermutung besteht, das Passwort könne kompromittiert worden sein oder wenn es einen anderen Sicherheitsvorfall gab, der es angeraten erscheinen lässt, das Passwort zu wechseln. Zur Identifizierung solcher Situationen werden bereits heute von einigen Internet-Providern und Cloud-anwendungen eine Reihe von Kriterien zum Teil sogar unter zur Hilfenahme von KI (künstlicher Intelligenz) ausgewertet.

Dazu gehören:

  • Aus welchem Land kommt der Anmeldeversuch?
  • In welchem Abstand kommen Anmeldeversuch von unterschiedlichen Geräten?
  • Wie weit ist der Ort des aktuellen Anmeldeversuchs vom Ort des letzten (erfolgreichen) Logins entfernt und wie viel Zeit ist seitdem vergangen?
  • Welche Tageszeit herrscht am Ort des aktuellen Anmeldeversuchs?
  • Wurde das Endgerät oder der Browsertyp geändert?
  • U. a. m.

Die Möglichkeit, selbst solche Risikoabschätzungen vorzunehmen oder gar hierbei einzugreifen, ist dagegen eher selten anzutreffen. Die einzigen Parameter, die man bei einigen wenigen Cloudanwendungen konfigurieren kann, sind Ort (selten) und Zeit (sehr selten). Immerhin können Sie damit die Nutzung solcher Anwendungen beispielsweise auf Ihr Unternehmensnetzwerk beschränken. Für weitergehende Parameter und insbesondere, wenn Sie auch Anwendungen einbeziehen wollen, die solches nicht aus sich heraus unterstützen, müssen Sie eine SSO-Lösung (siehe unten) verwenden.

Der Schutz gegen Brute-Force-Angriffe kann (und wird) mit den gleichen Mechanismen geführt werden, nämlich indem

  • entweder das Benutzerkonto nach einer bestimmten Anzahl von Fehlversuchen komplett gesperrt wird und der Benutzer zu einer Password-Recovery aufgefordert wird
  • oder eine künstliche Verzögerung eingeführt wird, die die Zeit, bis ein erneuter Login-Versuch zugelassen wird, sukzessive verlängert.

Darüber hinaus ist es gerade bei öffentlich erreichbaren Systemen durchaus sinnvoll, auf Benutzernamen wie admin, administrator, system etc. zu verzichten – am besten inklusive der Fehlermeldung „Dieser Benutzername ist hier nicht bekannt“. Warum sollte man Angreifern freiwillig über diese erste, wenn auch niedrige Hürde helfen?

Ansonsten unterstreicht das NIST ganz klar, dass Passwörter schon vom Konzept her eher schwache Authentifizierungsmerkmale sind. Vergleicht man Passwörter beispielsweise mit asymmetrischen oder symmetrischen Schlüsselverfahren, muss man schnell einsehen, dass man das mit den Schlüsselverfahren verbundene Sicherheitsniveau nie mit Passwörtern erreichen kann: Schlüssel sind zum einen komplett zufällig erzeugt und zum anderen deutlich länger als Passwörter. Das bedeutet, während kryptografische Schlüssel in der Regel so ausgelegt sind, dass ein Angriff über das Netzwerk ausgeschlossen ist, sind Passwörter deutlich leichter angreifbar und erfordern zusätzliche Maßnahmen.
Das NIST setzt daher verstärkt auf Multifaktor-Authentifizierung (MFA).

Multifaktor-Authentifizierung

Klassischerweise unterscheidet man drei Faktoren bei der Authentifizierung:

  • etwas, das man weiß (z. B. ein Passwort oder eine PIN),
  • etwas, das man besitzt (z. B. ein bestimmtes Gerät, einen kryptografischen Schlüssel oder, außerhalb der digitalen Welt üblich, einen Ausweis),
  • etwas, das man ist (z. B. Fingerabdruck oder Iris-Scan).

MFA bezeichnet jetzt ein Authentifizierungsverfahren, bei dem mehr einer dieser Faktor überprüft wird. Offensichtlich ist das Verfahren umso strenger je mehr Faktoren genutzt werden. Üblich sind heutzutage Verfahren, bei den zwei Faktoren überprüft werden. Man spricht dementsprechend auch von Zweifaktor-Authentifizierung (2FA). Auch das NIST bezeichnet eine Zweifaktor-Authentifizierung als ausreichend selbst für hohe Sicherheitsanforderungen.

Die oben genannten Zusatzinformationen wie Ort, Zeit oder Gerätetyp können natürlich weiterhin genutzt werden, um das Risiko eines Zugriffs zu bewerten, sie gelten aber nicht als eigenständige Authentifizierungsfaktoren.

Für Authentifizierungsverfahren, die über ein (in der Regel unsicheres) Netzwerk ausgeführt werden, ist es nun wichtig, dass jeder Faktor ein sogenanntes Geheimnis beinhaltet, welches der Benutzer nutzt, um seine Authentizität nachzuweisen. Diese Geheimnisse können entweder asymmetrische Schlüsselpaare sein oder sogenannte Shared Secrets, also symmetrische Schlüssel, Passwörter, PIN-Codes etc.

Offensichtlich beinhalten klassische Ausweise (Führerschein, Pass etc.) kein Geheimnis und sind damit zur Authentifizierung über das Internet nicht geeignet. Das NIST führt an dieser Stelle aber auch die bekannten Fragen zum Geburtsnamen der Mutter oder dem Namen des ersten Schulorts auf, die gerne zur Password-Recovery genutzt werden. Auch diese Fragen enthalten per se kein Geheimnis und sind damit zur Authentifizierung ungeeignet.

Gleiches gilt im Übrigen auch für biometrische Faktoren wie Fingerabdrücke. Auch diese Faktoren enthalten im oben aufgeführten Sinn kein Geheimnis und dürfen daher nach den NIST-Richtlinien nicht über Netzwerke ausgetauscht werden. Biometrische Faktoren werden vom NIST ausschließlich dann zugelassen, wenn es bei der Authentifizierung eine unmittelbare Bindung an ein physisches Gerät gibt, also beispielsweise zur Entsperrung eines Smartphones oder zum Zugriff auf einen Sicherheitstoken.

In diesem Sinne ist eine Zweifaktor-Authentifizierung also auf zwei Arten möglich:

  1. Der Benutzer weist der überprüfenden Stelle nach, dass er im Besitz von zwei Authentifizierungsfaktoren ist.
    Typisches Beispiel: Der Benutzer meldet sich mit Passwort an (etwas, was er weiß) und erhält einen Rückruf auf sein Handy (etwas, was er besitzt), den er bestätigt.
  2. Der Benutzer weist der überprüfenden Stelle zwar nur einen Faktor nach, dieser Faktor muss aber über eine zweite Stelle und über einen zweiten Faktor erst freigegeben werden.
    Beispiel: Der Benutzer schaltet via Fingerabdruck einen Sicherheitstoken frei, dieser Token enthält einen Schlüssel, der zur Authentifizierung genutzt wird.

Die Möglichkeit zur Multifaktor-Authentifizierung ist mittlerweile in einer ganzen Reihe von Cloudanwendungen vorhanden. In der Regel stehen jedoch nur sehr einfache Authentifizierungsverfahren zur Verfügung wie:

  • Es wird ein Bestätigungscode via E-Mail zugeschickt, dieser muss zusätzlich zum Passwort eingegeben werden.
  • Es wird ein Bestätigungscode via SMS zugeschickt, dieser muss zusätzlich zum Passwort eingegeben werden.

An dieser Stelle sei darauf hingewiesen, dass das NIST ausgerechnet diese Verfahren explizit ausschließt:

„The out-of-band device SHOULD be uniquely addressable and communication over the secondary channel SHALL be encrypted unless sent via the public switched telephone network (PSTN). … Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.”

Fortschrittlichere Verfahren, die in der Regel auch den Kriterien des NIST entsprechen, sind

  • Das Smartphone des Benutzers wird angerufen, der Benutzer beantwortet diesen Anruf.
    Smartphone respektive SIM-Karten gelten beim NIST als vertrauenswürdige und einzelnen Personen zugeordnete Geräte. Nichtsdestotrotz wird meist die verwendete Telefonnummer nicht weiter analysiert, so dass man problemlos auch eine Festnetznummer angeben kann.
  • Auf dem Smartphone des Benutzers ist eine eigene App installiert, die einen sicheren, verschlüsselten Kanal zum Zielsystem aufbaut. In der Regel muss der Benutzer dann die Frage „Zugriff auf xy zulassen“ nur noch mit einem Klick bestätigen.

Hier haben sich im Wesentlichen die beiden Authenticator-Apps von Google und Microsoft durchgesetzt, die mitunter auch von Dritten genutzt werden.

  • Über ein Hardware-Token oder passende Software (zum Beispiel die eben genannten Authenticator-Apps) werden sogenannte One-Time Passwords (OTP) generiert, die innerhalb des Geltungszeitraums zusätzlich zum Benutzerpasswort eingegeben werden müssen. OTPs haben typischerweise einen sehr kurzen Geltungszeitraum von weniger als einer Minute.
  • Smart-Cards oder ähnliche Systeme, die in eine Public-Key-Infrastruktur (PKI) eingebunden sind.

Beachten Sie bitte, dass bei dem speziellen und sehr sensiblen Thema Password-Recovery das einfache Anfordern und Zusenden eines neuen Passworts oder Recovery-Codes zum Beispiel per E-Mail keine Zweifaktor-Authentifizierung ist! Für 2FA muss das Zurücksetzen des Passworts über einen zusätzlichen Kanal wie beispielsweise ein Mobiltelefon bestätigt werden.

Cloud Security
09.03.-10.03.2020 in Seeheim

Cloud Sicherheit ist der Schwerpunkt dieses Seminars. Cloud Computing ist inzwischen zum entscheidenden Instrument für das Angebot von IT-Diensten geworden. Es gibt immer mehr Produkte, die ausschließlich als Cloud-Dienst angeboten werden. Damit muss auch die Informationssicherheit integraler Bestandteil von Cloud Computing sein. Dieses Seminar liefert das notwendige Wissen, wie Cloud-Infrastrukturen nachhaltig abgesichert und wie Anforderungen der Informationssicherheit bei der Beschaffung von Cloud-Diensten berücksichtigt werden können. Praxisbeispiele runden das Seminar ab.

Usability

Was bleibt ist trotzdem die Usability oder nennen wir es die Benutzerfreundlichkeit.
Die Benutzer verwenden weiterhin Passwörter als primären Authentifizierungsfaktor, womit das Thema „Sicheres Passwort“ keineswegs vom Tisch ist, und die Benutzer verwenden weiterhin viele bis sehr viele unterschiedliche Dienste und Anwendungen.

Hier geht Microsoft mit „Windows Hello“ einen durchaus interessanten Weg. Mit Windows Hello überträgt nämlich Microsoft die von Smartphones bekannten und üblichen Zugangsmethoden auf Windows Desktops und Notebooks: Biometrische Verfahren wie Fingerabdruck und Gesichtserkennung und eine PIN können genutzt werden, um sich an der Windows-Oberfläche anzumelden.

Das Besondere an diesem Verfahren ist:

  • Die PIN ist an dieses eine spezielle Gerät gebunden, für das sie festgelegt wurde. Nutzen Sie zusätzlich auch ein zweites Windows-Gerät, wird dort eine zweite PIN vereinbart.
  • Die PIN wird niemals über das Netzwerk ausgetauscht, sondern befindet sich immer lokal im Gerät.
  • Soweit verfügbar, wird die PIN durch ein Hardware-Modul (Trusted Platform Module – TPM) gesichert.
  • Zur Ersteinrichtung wird die PIN immer über eine zweistufige Authentifizierung abgesichert.

Das Verfahren ist also vergleichbar mit der PIN auf einer Bankkarte. Selbst wenn ein Angreifer Ihre PIN kennt, kann er damit nicht auf Ihr Konto zugreifen. Er benötigt zusätzlich Ihre Bankkarte – oder eben Zugang zu genau dem Rechner, für den diese PIN vereinbart wurde.

Damit unterscheint sich eine PIN deutlich von einem Passwort. Ein Passwort ist ein Shared Secret zum Beispiel mit Ihrem Active Directory und gestattet den Zugriff auf Ihr Benutzerkonto von überall, die PIN nur von einem speziellen Gerät.

Das Authentifizierungsverfahren selbst basiert auf Zertifikaten und asymmetrischen Schlüsselpaaren, die PIN wird lediglich gebraucht, um den Zugriff auf diese lokal gespeicherten Schlüssel zu bekommen.

Der Vorteil für den Benutzer liegt auf der Hand: Eine PIN ist wesentlich einfacher und kürzer als ein Passwort und damit auch einfacher und schneller eingegeben. Standardmäßig verlangt Microsoft lediglich vier Ziffern, aber wenn Sie unbedingt wollen, können Sie auch die PIN eine größere Länge oder komplexere Struktur auf einem Mix mit Buchstaben und Sonderzeichen durchsetzen.

Mit der Einführung von PINs konnten wir beispielsweise im Unternehmen motivieren, dass das Inaktivitäts-Timeout, nach dem der Bildschirm gesperrt wird, bei mobilen Endgeräten auf unter fünf Minuten gesetzt wurde. Ein wichtiger Schritt, um das Risiko unbeaufsichtigter Geräte zu reduzieren.

Single-Sign On

Der letzte Baustein, den Sie umsetzen müssen, ist eine Single-Sign-On-Lösung (SSO).
Die Idee hinter SSO ist, dass sich der Benutzer nur ein einziges Mal anmelden (authentisieren) muss und dann im Hintergrund und transparent für den Benutzer dafür gesorgt wird, dass er alle Anwendungen, die für ihn freigegeben sind, ohne erneute Authentifizierung nutzen kann.

Die zugrundeliegende Architektur ist dabei meist sehr ähnlich. Unterschieden werden drei Rollen:

  • der Benutzer, der einen bestimmten Dienst nutzen will,
  • der Dienstanbieter, der den gewünschten Dienst zur Verfügung stellt,
  • ein Authentifizierungsdienst, der den Benutzer identifizieren kann und dem der Dienstanbieter vertraut.

Die prinzipielle Funktionsweise folgt folgendem Schema (siehe auch Abbildung 2):

Der Benutzer will einen bestimmten Dienst nutzen, z. B. eine Flugreise buchen. Dazu wendet er sich an den Dienstanbieter, in unserem Beispiel ein Reisebüro. Das Reisebüro fordert ihn auf, sich auszuweisen. Falls der Benutzer noch keinen gültigen, vom Reisebüro akzeptieren Ausweis besitzt, wendet er sich an eine Authentifizierungsstelle, dem das Reisebüro vertraut, im Beispiel das Einwohnermeldeamt. Dort authentisiert er sich mit geeigneten Mittel und erhält von dem Amt einen Ausweis, mit dem er sich beim Reisebüro ausweisen kann.

Schematische Darstellung einer verteilten Authentifizierung

Abbildung 2: Schematische Darstellung einer verteilten Authentifizierung

Der Dienstanbieter wird jetzt in der Regel die ihm vorgelegten und vom Authentifizierungsdienst beglaubigten Daten selbstständig prüfen und eigenständig (!) entscheiden, welche Daten für ihn von Belang sind und welche Rechte er daraufhin dem Benutzer zugesteht. Im Beispiel könnte das Reisebüro beispielsweise zusätzlich zur prinzipiellen Identitätsbestätigung auch das Geburtsdatum des Kunden beachten. SSO-Protokoll wie SAML (siehe unten) erlauben die Weitergabe zusätzliche Attribute des Benutzerkontos wie E-Mail-Adresse oder Gruppenzugehörigkeiten.

Single Sign On (SSO) ist bei weitem nichts Neues und keineswegs auf die Cloud beschränkt. Gerade im Windows-Umfeld ist mit Kerberos eine standardisierte SSO-Lösung direkt in den Windows-Server-Betriebssystemen integriert.

Aber Single-Sign On adressiert gerade in Cloudumgebungen drei wichtige – ich würde sogar sagen unverzichtbare – Ziele:

  1. Die Benutzer melden sich nur einmal beim führenden Authentifizierungsdienst an.
    Neben der offensichtlichen Tatsache, dass sich die Benutzer folglich nur ein Passwort merken müssen, ist dies für Integration unterschiedlicher Cloudanwendung essentiell. Nehmen Sie zum Beispiel eine CRM- oder eine Buchhaltungsanwendung, die kundenspezifische Dokumente wie Briefe, Angebote oder Rechnungen direkt aus der Anwendung heraus bei einem hiervon unabhängigen Storage-Provider wie Box.com ablegen möchten. Natürlich muss gewährleistet sein, dass der Besitzer des Dokuments eindeutig dem Nutzer der CRM-Anwendung zugeordnet werden kann, und umgekehrt. Das heißt, aus Sicht der CRM-Anwendung gehört das Dokument zu einem bestimmten CRM-Datensatz (Kunde), aus Sicht der Storage-Anwendung gehört das Dokument dem User, der dem CRM-User auf der Storage-Seite zugeordnet ist.
    Ohne SSO ist eine solche Integration meist sehr benutzerunfreundlich zu bedienen. Und die mitunter angebotene Möglichkeit, die Zugangsdaten zu Provider B bei Provider A zu hinterlegen, kommt Sicherheitsgründen ja in der Regel nicht in Frage.
  2. Die Benutzeradministration wird in einem System zusammengeführt.
    Die getrennte Administration mehrerer Cloudanwendungen mit getrennten Benutzerstammdaten, unterschiedlichen Gruppendefinitionen, unterschiedlichen Administrationsoberflächen etc. ist nicht nur unnötig aufwändig, sondern auch ungemein fehleranfällig.
    Da viele Unternehmen intern ein auf Active Directory basierendes Netzwerk betreiben, ist es von Vorteil, wenn die gewählte SSO-Lösung auf ein Active Directory als Benutzerbasis und Authentifizierungsdatenbank zu greifen kann. Da man es in der Regel ablehnen wird, dass ein externes, cloudbasierendes Produkt von außen auf das interne AD zugreifen darf, ist man hier auf andere Lösungen angewiesen, beispielsweise auf eine agentenbasierende Synchronisation von innen nach außen.
  3. Die meisten führenden SSO-Lösungen bieten Ihnen auch zusätzliche MFA-Fähigkeiten. Damit sind Sie in der Lage alle integrierten Anwendungen auf dieselbe Art und Weise freigeben und steuern, ohne darauf angewiesen zu sein, dass jede einzelne Anwendung genau das Authentifizierungsverfahren unterstützt, das Sie brauchen.
    Microsoft unterstützt mit „Conditional Access“ im Azure AD beispielsweise ein regelbasierendes System mit dem Sie Anforderungen umsetzen können wie:
    • Für Anfrage aus dem Unternehmensnetz ist kein MFA erforderlich.
    • Auf besonders kritische Anwendungen (z. B. Administration) darf von außerhalb nicht zugegriffen werden.
    • Nur Vertriebsmitarbeiter dürfen bestimmte Anwendung auch außerhalb des Unternehmensnetzes nutzen, dann jedoch mit zusätzlicher MFA.
    • Bestimmte oder alle Cloudanwendungen dürfen nur auf Endgeräten verwendet werden, die unter der Kontrolle Ihres Unternehmens stehen, entweder durch Integration in ein Active Directory oder ein Mobile Device Management (MDM).
    • …

Darüber hinaus bieten SSO-Lösungsanbieter rund um diesen Themenkomplex eine Vielzahl weiterer Funktionen, für die zum Teil eine lokale Installation nötig ist:

  • Administratoren können auf Anforderung MFA für einzelne Benutzer kurzzeitig (typischerweise 300 Sekunden) deaktivieren, zum Beispiel weil der Benutzer unterwegs ist und sein Handy vergessen hat.
  • Protokollierung aller Zugriffe, gegebenenfalls inklusive vorgefertigter Reports zur Auswertung.
  • Benutzer können Ihren eigenen Account zeitweise oder permanent sperren, weil ein Sicherheitsvorfall (z. B. Handy gestohlen) dessen Integrität gefährdet.

Damit Cloudanwendungen auf diese Weise zentral gesteuert werden können, müssen sie im Wesentlichen zwei Voraussetzungen erfüllen:

  1. Die Anwendung muss über eines der SSO-Protokolle gesteuert werden, die auch die SSO-Lösung unterstützt. Da die Auswahl bei den SSO-Protokollen nicht allzu groß ist, unterstützen praktisch alle marktrelevanten SSO-Lösungen die drei wesentlichen Protokolle SAML, WS-Federation und OpenID Connect.
    Das heißt, die Anforderung reduziert sich auf: Die betrachtete Anwendung muss SSO unterstützen. Hier ist der Markt schon recht weit, Sie müssen „lediglich“ damit rechnen, dass Sie mit der Forderung nach SSO in der höchsten und damit teuersten Lizenzstufe landen.
    Einige wenige Enterprise-Anwendungen sind uns begegnet, die bislang kein SSO unterstützen. Auf Anfrage hieß es jedoch immer, dass daran gearbeitet werde.
  2. Sobald die SSO-Anbindung erfolgreich aufgesetzt und getestet wurde, muss die direkte Anmeldung bei der Anwendung bzw. des Providers abgeschaltet werden!
    Dies wird oft übersehen, ist aber offensichtlich wichtig, da zentrale Policies der SSO-Lösung natürlich nicht durchgesetzt werden können, wenn die Benutzer sich weiterhin auch direkt anmelden können.

SAML

Das im Markt am weitesten verbreitete SSO-Protokoll ist SAML.

SAML steht für Security Assertion Markup Language und ist ein offener Standard zur Authentifizierung von Usern, Federation zwischen Dienstanbietern und Single-Sign-On-Szenarien. Schon an dieser Aufzählung können Sie erkennen, dass SAML ein sehr umfangreiches Framework ist, dessen voller Umfang den Rahmen dieses Artikels sprengen würde.

SAML wird vom Security Services Technical Committee (SSTC) der OASIS (Organization for the Advancement of Structured Information Standards) entwickelt. Die erste Version V1.0 wurde im November 2002 veröffentlicht, die aktuelle Version V2.0 stammt vom März 2005 und wird derzeit immer noch weiterentwickelt.

Im Gegensatz zu Kerberos basiert SAML auf XML und passt damit deutlich besser in die Cloud und zu HTML- und SOAP-basierenden Anwendungen.

Die Kernelemente von SAML sind sogenannte Assertions, zu Deutsch Erklärungen. Diese Assertions sind XML-Dokumente, in denen sowohl die Anfragen als auch die Antworten transportiert werden. Abbildung 3 zeigt ein typisches Assertion als Antwort auf eine Authentifizierungsanfrage.

SAML Response Assertion

Abbildung 3: SAML Response Assertion

Die dargestellte Antwort umfasst

  • den Aussteller (Issuer) dieser Erklärung,
  • das Datum, wann diese Erklärung erstellt wurde,
  • warum diese Erklärung erstellt wurde (InResponseTo),
  • wohin die Erklärung weitergeleitet werden soll (Destination),
  • den Status der Überprüfung (samlp:StatusCode, hier: Success),
  • wie die Überprüfung durchgeführt wurde (AuthnContext, hier: Password),
  • ein paar zusätzliche Attribute wie zum Beispiel den Benutzernamen des Users und
  • unter welchen Bedingungen (Anschnitt Conditions) die Erklärung benutzt werden soll (Im Beispiel ist ein Gültigkeitszeitrahmen von gut einer Stunde und der Ziel-Provider angegeben).

Außerdem ist das Dokument signiert (Abschnitt ds:Signature) und kann so vom Empfänger auf seine Glaubwürdigkeit überprüft werden. Zusätzlich kann seit SAML 2.0 auch das komplette Dokument oder Teile davon verschlüsselt werden.

Abbildung 4 zeigt das Funktionsprinzip von SAML:

  1. 1Es gibt wiederum drei miteinander kommunizierende Parteien: den Benutzer, einen „Identity Provider“, der den Benutzer authentifizieren kann, und einen „Service Provider“, den der Benutzer kontaktiert und der die Identität und gegebenenfalls weitere Details über den Benutzer wissen möchte. Daher wird der Identity Provider als ausstellende Stelle auch als „SAML Asserting Party“ bezeichnet und der Service Provider als auswertende Stelle als „SAML Relying Party“.
  2. Der Service Provider erstellt eine Anfrage (in Form eines XML-Dokuments) und der Identity Provider antwortet seinerseits mit einem XML-Dokument (Assertion), das die gewünschten Informationen enthält, und unterzeichnet dieses Dokument.
    Diese Assertion können, wie oben gezeigt, eingesetzt werden, um eine zentrale Authentifizierung und SSO zu implementieren, aber auch einfach zur Autorisierung, indem Benutzerrechte und Gruppenzugehörigkeiten abgefragt werden.
    Darüber hinaus ist auch ein Informationsaustausch zwischen verschiedenen Identity Providern möglich, um beispielsweise neue Benutzerkonten anzulegen, Benutzer zu sperren und ähnliches. Hierzu wird lediglich einer der Identity Providern als Service Provider betrachtet, der einen entsprechenden Dienst (z. B. „Benutzer anlegen“) anbietet.
  3. Wo und wie die Benutzerdaten gespeichert sind, ist für das Konzept unerheblich. Unterstützt werden die üblichen Verzeichnisdienste wie LDAP und AD, aber auch verteilte Konzepte sind realisierbar, indem eine Anfrage einfach weitergeleitet wird.
  4. Wie bei Kerberos werden Assertions nicht direkt zwischen Service und Identity Provider ausgetauscht, sondern immer über den Benutzer geleitet. SAML nutzt hierfür üblicherweise den Mechanismus HTTP-Redirect.
  5. Der Service Provider (= die Anwendung) bleibt bei seiner Entscheidung, wie er mit der Service-Anfrage des Benutzers umgehen soll, letztendlich autark. Das heißt, trotz einer SAML-Antwort entscheidet er selbst, welche Informationen des Assertions er wie oder gegebenenfalls überhaupt beachtet. So kann beispielsweise ein Provider einen kürzeren oder längeren Gültigkeitszeitrahmen akzeptieren als im Assertion vermerkt, oder er kann trotz Authentifizierung bestimmte Benutzer aus lizenzrechtlichen Gründen ablehnen.

Abbildung 4: SAML Funktionskonzept

SAML bietet damit nicht nur grundlegende SSO-Funktionalität der Art „Ist vertrauenswürdig: Ja – Nein“, sondern kann auch weitere Details des lokalen Benutzerkontos übertragen, um

  • neue Benutzer automatisch anzulegen,
  • Benutzerkonten automatisch zu löschen,
  • Benutzerkonten zu sperren,
  • Gruppenzugehörigkeiten und Lizenzrollen zu aktualisieren.

Kurz: SAML ist dazu in der Lage, einen Großteil der in der Cloud verteilten Benutzerverwaltung an einem Punkt zu zentralisieren – und dieser Punkt wird natürlich in der Regel Ihr lokales Active Directory sein. Die Krux ist, dass beide Seiten, Ihre SSO-Lösung und Ihre Cloudanwendungen dies unterstützen müssen. Ihre SSO-Lösung wird dies in der Regel können …

Fazit

Mit der zunehmenden Einbindung von Cloudanwendungen in moderne Geschäftsprozesse wird es unverzichtbar, die Zugänge zu diesen Anwendungen einerseits natürlich sicher, andererseits aber auch benutzerfreundlich zu gestalten. Unser bisheriger Umgang mit benutzerspezifischen Passwörtern ist dazu ungeeignet:

  • Komplexe Passwort-Policies mit kurzen Laufzeiten führen nicht zu sicheren Passwörtern – im Gegenteil, viele Benutzer wählen schwache Passwörter in Kombination mit einer fortlaufenden Nummerierung oder schreiben sich die Passwörter direkt aus.
  • Je mehr Clouddienste genutzt werden, desto mehr Passwörter müssen sich die Benutzer merken, was zur mehrfachen Nutzung derselben Passwörter bei unterschiedlichen Anbieter führt.
  • So oder so sind Passwörter eher schwache Authentifizierungsfaktoren.
  • Die Integration unterschiedlicher Clouddienste in eine gemeinsame Oberfläche (gegebenenfalls einer weiteren Cloudanwendung) kann nicht überzeugend gelingen, wenn jeder Dienst ein eigenes Authentifizierungsverfahren durchsetzt.

Da in vielen Bereichen noch auf längere Zeit die Kombination aus Benutzername und Passwort der primäre Authentifizierungsfaktor bleiben wird, schlägt das NIST in seinen neuen Sicherheitsrichtlinien vor, auf die zwangsweise Verwendung mutmaßlich komplexer Passwörter zu verzichten und die Laufzeit von Passwörter radikal zu verlängern.

Neue Richtlinien könnten auf dieser Basis lauten:

  • Laufzeit: 1 – 2 Jahre,
  • Mindestlänge: 8 – 12 Stellen,
  • keine weiteren Vorgaben, aber Abgleich mit gängigen Passwort-Dictionaries.

Darüber hinaus brauchen Sie eine unternehmensweite Lösung, die es Ihnen ermöglicht die Benutzerverwaltung und Anwendungsfreigabe zentral zu halten und zu steuern, Ihren Benutzer eine automatische und transparente Authentisierung bei allen Anwendungen bereitzustellen und einfache Integrationen unterschiedlicher Produkte zu schaffen.

Eine solche Lösung besteht aus drei Bausteinen:

  1. Single Sign-On (SSO)
    Durch eine einmalige Anmeldung bei Ihrem Identity-Provider und die Einbindung aller genutzten Cloudanwendungen gibt es nur eine zentrale Instanz, die den Zugang zu den Anwendungen steuert. Voraussetzung ist, dass alle (wichtigen, heißt sicherheitsrelevanten) Cloudanwendungen SSO unterstützen.
  2. Multifaktor-Authentifizierung (MFA)
    Ein von Benutzern gewähltes Passwort als alleiniger Zugangsfaktor ist in aller Regel einfach zu schwach, um den Zugang zu öffentlich erreichbaren Diensten abzusichern. MFA ergänzt das Passwort um einen weiteren Faktor, dessen Besitz der Benutzer nachweisen muss. In den meisten Fällen wird es sich hierbei um ein Smartphone oder die App auf einem Smartphone handeln. E-Mail ist eher ungeeignet, weil man hierfür offensichtlich eine vom Unternehmenskonto unabhängige E-Mail-Adresse benötigt, deren Zugang dann zwangsläufig weniger gut abgesichert sein wird.
  3. Schulung der Mitarbeiter
    Ihre Mitarbeiter sind in jedem Sicherheitskonzept immer einer der zentralen Punkte. Gerade die diskutierte Entspannung der Passwort-Policies macht nur Sinn, wenn die Mitarbeiter ein Gefühl dafür entwickeln, was ein sicheres und leicht zu merkendes Passwort ausmacht.
    Gängige Hinweise sind:
    • Verbinden Sie mehre kurze Wörter, die untereinander in keinem Zusammenhang stehen.
    • Ersetzen Sie gegebenenfalls ein, zwei Buchstaben durch Ziffern oder Sonderzeichen.
    • Es spricht nichts dagegen, die Wörter durch Leerzeichen oder andere Zeichen zu trennen.
    • Mitunter liest man den Tipp, die Anfangsbuchstaben aller Wörter in einem Satz, den man sich merken kann, als Passwort zu wählen. Das ist weder neu noch besonders originell, vermeiden Sie daher unbedingt bekannte Zitate oder Songtexte.

Microsoft geht in Windows 10 bereits einen weiteren Schritt und ermöglicht mit Windows Hello und Active Directory einen PIN-basierenden und damit passwortfreien Zugang. Auch die integrierte Weitergabe der Windows-Authentifizierung durch die hauseigenen Browser Edge und Internet Explorer ist gerade im Zusammenhang mit Office 365 äußerst praktisch – es ist keine erneute Authentifizierung nötig –, drängt die Nutzer aber eben auch dazu, die in Azure integrierte SSO- und MFA-Lösung zu nutzen. Hier sollten Sie genau prüfen, wo Ihre konkreten Anforderungen liegen.

Und sagen Sie jetzt nicht „So weit, so gut, aber die Cloud ist für uns kein Thema“. Es gibt mittlerweile eine große Palette an Software, die nur noch als Cloudprodukte verfügbar sind. Gerade im Bereich Kommunikation und Kollaboration geht an Cloudprodukte kein Weg mehr vorbei, moderne Kollaboration auf Dokumentenebene ist ohne Cloud schlicht nicht möglich! Ignorieren Sie diese Entwicklung, provozieren Sie nur, dass Ihre Mitarbeiter ohne Ihr Wissen solche Produkte zur Verbesserung der eigenen Produktivität nutzen (Stichwort „Schatten-IT“).

Darüber hinaus sind wir fest davon überzeugt, dass in allen Branchen die Öffnung zur Cloud mit entscheidend für den unternehmerischen Erfolg sein wird. Und wir würden Sie als Kunde gerne behalten :-).

Der Netzwerk Insider vertritt monatlich mit seinen Artikeln die Sichtweise von Technologie-Anwendern und bewertet Produkte und Technologien im Sinne der wirtschaftlichen und erfolgreichen Umsetzbarkeit in der täglichen Praxis.

Der Bezug des Netzwerk Insiders ist kostenlos und wird Ihnen per E-Mail als PDF-Download und alternativ als Webversion zur Verfügung gestellt.

ComConsult Cloud Forum
25.11.-26.11.19 in Köln

Auf dem Kongress tragen projekterfahrene Referenten zu Nutzung von Software aus der Cloud, zu Nutzung der Cloud (PaaS, IaaS, Hybrid Cloud) für die Entwicklung, Bereitstellung und dem Betrieb eigener Lösungen und zu Cloud-Security vor. Die Fallstricke und Herausforderungen bei der Nutzung von SaaS-Angeboten wie Office 365 werden erklärt. Auf Cloud-basierende Anwendungen für IoT, Digitalisierung und Smart Technologies (zum Beispiel Smart Commercial Building) wird eingegangen. Die Anbindung an externe Clouds und die Konsequenzen für Netze bilden ebenfalls einen der Schwerpunkte des Forums. Anhand von Beispielen wird gezeigt, worin sich Cloud-basierte Bereitstellung und Betrieb von Anwendungen vom bisherigen IT-Betrieb on Premises unterscheidet. Ferner stehen Sicherheitsaspekte wie sicherer Cloud-Zugang, Schutz vor Datenverlust, Datensicherheit und Datenschutz auf der Agenda des Forums.

0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Wir freuen uns über Ihren Beitrag!

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.