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)

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.