Teil 15: Identifizierung

Identifizierung bei Websystemen: Sie sollten wissen, mit wem Sie es zu tun haben

Daniel Takai, Gion Manetsch

© Shutterstock / Arthimedes

Bei der Bildung einer digitalen Vertrauensbeziehung für den E-Commerce, bei sozialen Interaktionen oder bei Vertragsabschlüssen ist die korrekte Identifizierung unabdingbar. Damit ist sie ein essenzieller Bestandteil jeder Strategie zum Schutz von Informationen und Ressourcen vor unbefugtem Zugriff.

Die Sicherheit eines Websystems ist ein Basismerkmal [1]. Es wird von den Stakeholdern erwartet, ohne dass sie mit Ihnen darüber sprechen. Im Falle der Speicherung personenbezogener Daten ist die Sicherheit sogar von Rechts wegen vorgeschrieben. Dass Identifizierung nicht immer einfach ist und selbst bei Milliardenprojekten stümperhaft gelöst wird, hat unlängst Volkswagen demonstriert. Deren Autoschlüssel lassen sich in weniger als einer Sekunde knacken.

Dabei benötigt die sichere Authentifizierung keine Investitionen in Milliardenhöhe, wird aber auch nicht gratis geliefert. Zunächst müssen wir aber die Terminologie etwas auseinandernehmen, damit die Unterschiede und Zusammenhänge klar werden. Nicht verwechseln sollte man Authentisierung und Authentifizierung. Die Begriffe klingen ähnlich, aber die Authentisierung ist eine rechtskräftige Bestätigung und meint deswegen etwas völlig anderes. Authentifizierung ist hingegen die Bestätigung, dass etwas echt ist, also beispielsweise ein Passwort stimmt. Ob ein richtiges Passwort ausreicht, um einen Akteur zu identifizieren oder nicht, hängt davon ab, wie sicher das System sein soll. Der Grad an Sicherheit variiert über die Anzahl von Faktoren, wie Passwörter oder MTAN, die im Rahmen der Identifizierung authentifiziert werden (Abb. 1).

Identifizierung und Identifikation sind sich ähnlich wie Authentifizierung und Authentisierung. Die Identifikation ist ein Begriff aus der Psychologie, der den Vorgang beschreibt, sich in einen anderen Menschen einzufühlen. Identifizieren wird als Vorgang beschrieben, der zum eindeutigen Erkennen einer Person oder eines Objekts dient. Der letzte Begriff in diesem babylonischen Reigen ist die Autorisierung, also die Berechtigung einer Person nach der Identifizierung.

Abb. 1: Prozesse der Identifizierung

Abb. 1: Prozesse der Identifizierung

Faktoren der Sicherheit

Die Techniken zur Authentifizierung werden nach Faktoren kategorisiert. Ein Identifizierung, die mehrere Faktoren benötigt, heißt Multi-Faktor-Authentifizierung. Die folgenden Faktoren gibt es:

  1. Etwas, das man weiß (Passwort)
  2. Etwas, das man besitzt (Mobiltelefon)
  3. Etwas, das man ist (Retinascan oder Fingerabdruck)

Eine Identifizierung gilt heute als sicher oder stark authentifiziert, wenn zwei oder mehr Faktoren involviert sind. Der heute verbreitete Marktstandard ist immer noch die Verwendung eines Benutzernamens und eines Passworts, was als schwache Authentifizierung gilt. Immer verbreiteter werden mittlerweile die Zwei-Faktor-Authentifizierungen, kurz 2FA, die deutlich mehr Sicherheit bieten. Die FIDO-Allianz hat 2014 einen Standard für eine universelle und lizenzfreie 2FA veröffentlicht. Der Trend geht aber heute bereits weiter zu Mehrfaktorauthentifizierung (MFA), da bereits erfolgreiche Man-in-the-Middle-Angriffe auch gegen 2FA festgestellt werden konnten. Die 2FA ist in unterschiedlichen Ausprägungen möglich, je nach Anwendungsfall.

Bei der mittelbaren 2FA wird üblicherweise der Besitz mit einem Hardwaretoken, z. B. einer Smartcard oder einem Schlüsselgenerator, analog RSA oder VASCO, definiert. Neben dieser klassischen Variante verbreitete sich in den letzten Jahren die tokenlose Authentifizierung. Bei dieser wird dem Benutzer per SMS, E-Mail oder Apps wie dem Google Authenticator ein dynamischer Passcode zugestellt. Eine Spezialität, die in Europa wenig verbreitet ist, ist die Zustellung eines Faktors über einen Telefonanruf. Mittelbare 2FA ist im Onlinebankingbereich oder auch bei Google mittlerweile Standard. Neben der mittelbaren 2FA sind auch halbautomatische oder vollautomatische Faktoren wie Near Field Communication (NFC) möglich. Bei einem automatischen Faktor ist keine Aktion durch den Benutzer notwendig, es muss also nichts eingegeben werden. Die Authentifizierung erfolgt hier beispielsweise über ein zuvor personalisiertes Mobilgerät.

Prozesse der Identifizierung

Wesentlich für die Qualität der Identifizierung sind die Prozesse, die die Identifizierung möglich machen. Dabei ist der Initialisierungsprozess (Onboarding) wohl der wichtigste. Dieser knüpft das Individuum an ein Credential, respektive einen Account. Für diesen Prozess bestehen je nach Land und Anwendungsfall unterschiedliche rechtliche Anforderungen, die es zu beachten gilt. Die Eröffnung eines Bankkontos hat andere Anforderungen als die Eröffnung eines Accounts in einem Onlineshop, bei der im Minimum die Angabe einer E-Mail-Adresse notwendig ist.

Ein Account hat einen Lifecycle, von seiner Erzeugung bis hin zur Löschung. Ein Account muss sich anpassen lassen (Modifikation), da sich beispielsweise Name, E-Mail-Adresse oder andere Daten ändern können (Anpassung der Identität). Weitere Prozesse wären die Überprüfung (Account Assurance), die Sperrung oder Suspendierung inklusive Entsperrung sowie die Löschung eines Accounts. Kernbestandteil der Prozesse ist die wiederkehrende Prüfung, um die Sicherheit zu erhöhen (Abb. 2).

Im Rahmen der Identifizierung sollte man zwischen der Identity Assurance und der Credential Assurance unterscheiden. Die Identity Assurance ist die Gewissheit, ob eine Verbindung zu einem bestimmten Individuum hergestellt wurde. Die Credential Assurance ist die Gewissheit, dass aufgrund des Besitzes und der Kenntnis eines nicht kompromittierenden Faktors die Verbindung zu einem Individuum besteht. Im Fall der Identity Assurance müssen neben dem Besitz und der Kenntnis von Credentials auch die behaupteten Attribute des Individuums überprüft werden – je nach regulatorischen Anforderungen auf unterschiedliche Art und Weise. In der Praxis wird meistens nur überprüft, ob Credentials benutzt sind. In den wenigsten Fällen wird auch überprüft, ob sie noch zu dem ursprünglich zugeordneten Benutzer gehören. Die folgenden Verfahren haben sich bewährt und sollten nach Möglichkeit berücksichtigt werden: mehrstufige Prozesse und Rückfragen bei Anpassungen.

Zum einen haben wir die mehrstufigen Prozesse, insbesondere bei der Modifikation, dem Entsperren und dem Löschen von Credentials. Bei mehrstufigen Prozessen, wird die gewünschte Aktion erst ausgeführt, wenn eine Bestätigung durch den betroffenen Benutzer erfolgt. Dies kann sowohl mit einer 2FA erfolgen – analog einer Transaktionssignatur – als auch über einfache Bestätigungsprozesse, beispielsweise mittels E-Mail oder Telefonanruf. Zum anderen kann es Rückfragen bei Anpassungen geben. Sollen keine aufwendigen mehrstufigen Prozesse verwendet werden, so hilft in jedem Fall eine Information des Benutzers, dass an seinen Faktoren Anpassungen vorgenommen wurden. Der Benutzer hat so die Möglichkeit, sich im Fall von Unklarheiten zu melden, um eine Veränderung rückgängig zu machen. Ein Fallstrick ist hierbei die Anpassung der E-Mail-Adresse, denn die Information muss natürlich auf die alte E-Mail-Adresse des Benutzers erfolgen. Generell gilt, dass im Rahmen der Auditierung von Veränderungen auch die alten Werte eingesehen werden können.

Abb. 2: Prozesse der Identifizierung

Abb. 2: Prozesse der Identifizierung

Ick sitze da und esse Klops

Da nachfolgend Protokolle und Verfahren für die Authentifizierung erklärt werden, ist es notwendig, den grundlegenden Ablauf einer Identifizierung und die dazu notwendigen Komponenten zu erklären. Da sich dieser Artikel mehrheitlich mit der Sicherheit von Websystemen befasst, gehen wir davon aus, dass sich der Benutzer über einen Browser auf ein Websystem verbindet. Der hier beschriebene Ablauf ist sehr rudimentär und soll als Beispiel für die nachfolgend beschriebenen Verfahren und Protokolle dienen. Der Austausch der Informationen zwischen Benutzer und Webanwendung (Credentials oder Session-Token) erfolgt jeweils verschlüsselt und ist vor Manipulation geschützt. Jede Webanwendung, die eine vorherige Authentifizierung verlangt (Log-in), hat auch einen Log-out. Dies wird oft sträflich vernachlässigt. Die Schritte (Abb. 3) sind im Einzelnen:

  1. Der Benutzer möchte sich auf eine geschützte Webseite verbinden.
  2. Die Webanwendung stellt fest, dass für die geschützte Webseite eine Authentifikation notwendig ist. Sie sendet dem Benutzer ein Formular zur Eingabe der Credentials.
  3. Der Benutzer füllt das Formular aus, bei MFA können dies auch mehrere Formulare sein, und sendet es an die Webanwendung.
  4. Die Webanwendung prüft gegen ein Verzeichnis, ob der Benutzer vorhanden, ob er für die entsprechenden Webseiten berechtigt ist und ob seine Credentials stimmen.
  5. Ist soweit alles in Ordnung, wird dem Benutzer ein Session-Token gesendet, das für die aktuelle Session gültig ist.
  6. Mithilfe des Session-Tokens wird die Authentifizierung aufrechterhalten, ohne dass sich der Benutzer für jede Anfrage, die er zur Webanwendung sendet, wieder authentifizieren muss.

Tatsache ist, dass bezüglich des sicheren Handhabens von Sessions wohl am meisten Fehler gemacht werden und diese Punkte deshalb bei der Erstellung von Websystemen großer Sorgfalt bedürfen. OWASP gibt hier sehr gute Richtwerte für die Einhaltung von Sicherheitsanforderungen von Websystemen.

Abb. 3: Grundlegender Ablauf der Authentifizierung

Abb. 3: Grundlegender Ablauf der Authentifizierung

Authentifizierung als Dienstleistung beziehen

Der Markt für Authentication as a Service (AaaS) wächst stark, denn es gibt eine klare Abhängigkeit zur zunehmenden Digitalisierung der Gesellschaft und der Unternehmen. Es gibt hier viele verschiedene Produkte, wie Azure AD oder SafeNet. An dieser Stelle möchten wir auf die Eigenschaften von SaaS-Angeboten eingehen, die heute am Markt erhältlich sind. Dabei geht es uns also um die reine Authentifizierung als Serviceangebot. Wir grenzen dieses hier genau ab, da es auch komplette IAM-(Identity-und-Access-Management-)Lösungen gibt, die neben der Authentifizierung auch den gesamten Account-Lifecycle und die Provisionierung zum Ziel haben.

Viele Firmen sind heute eine Zweiklassengesellschaft, was die Identifizierung von Mitarbeitern angeht: Mitarbeiter mit und Mitarbeiter ohne Accounts. Da beispielsweise Personalprozesse zunehmend digitalisiert werden, steigt der Bedarf an digitaler Identifizierung. Vor einer Anschaffung einer solchen Software oder der Transformation in einen Cloud-Service müssen diverse Überlegungen angestellt werden, um die richtige Lösung für eine Organisation zu finden.

Generell lassen sich von AaaS die gleichen kritischen Anmerkungen wie bei anderen Cloud-Lösungen anbringen. In vielen Fällen kommt bei Firmen heute bereits ein Dienstleister für die Authentifizierung zum Einsatz, z. B. wenn SMS-Tokens verwendet werden, sodass der Einbezug eines Dienstleisters nicht kategorisch ausgeschlossen werden sollte. Denn es ist auch möglich, einen DDoS-Angriff auf einen SMS-Provider vorzunehmen. Wichtig ist, dass man sich bewusst ist, was man dem Service-Provider anvertraut, und wie weit dieses dann Risiken für das eigene Geschäft nach sich zieht. Generell können hier die Richtlinien und Checklisten beispielsweise der Cloud Security Alliance für Detailfragen konsultiert werden. Dabei gibt es hier mehrere Punkte, die besonderer Aufmerksamkeit bedürfen, wie im Folgenden beschrieben.

Zunächst gibt es Anforderungen an die Verfügbarkeit. Bei der Verwendung von AaaS ist zu beachten, dass der Service mindestens dasselbe Servicelevel erfüllt wie die Services, die damit bedient werden sollen. Wird der Service über das Internet bezogen, so ist es möglich, dass der Provider des Diensts einem DDoS-Angriff ausgesetzt wird. Wird die AaaS nur von Webapplikationen verwendet, die lediglich über das Internet verfügbar sind, sind diese über einen DDOS-Angriff auch angreifbar. Fakt bleibt aber, dass ich beim Einsatz von AaaS nur noch den Authentication-Provider angreifen muss, um alle meine Applikationen lahmzulegen. Es lohnt sich hier, die Maßnahmen des Service-Providers hinsichtlich solcher Szenarien zu prüfen. Wird der Service auch für interne Applikationen eingesetzt, wird dies meist über interne Komponenten abgewickelt, z. B. MFA-Server. Die Kommunikation zum Service-Provider wird in diesen Fällen meist nicht über das Internet, sondern über eine Mietleitung erfolgen.

Auch an die Performance werden Anforderungen gestellt. Wichtig ist, dass die Performance den Anforderungen entspricht und eine maximale Skalierung für die eigenen Bedürfnisse geprüft wird. Das bedeutet, dass der Anbieter ausreichend Kapazität für eine bestimmte Latenz bei einer maximalen Anzahl von Authentifizierungen pro Sekunde sicherstellt. Die Auslieferung von Tokens über SMS kann je nach Land etwas dauern. Bei eigenen Websystemen kann man dem Rechnung tragen (Authentication Time-out). Bei eingekauften Services, z. B. VPN-Client, oder SaaS-Applikationen muss hier der Anbieter der Software im Zweifelsfall notwendige Anpassungen vornehmen. Diese Punkte sollten vor der Beschaffung eines Authentifizierungsservice geprüft und auch getestet werden.

Die Vertraulichkeit ist auch ein wesentlicher Punkt. Die Anforderungen an die Vertraulichkeit der technischen Lösungen unterscheiden sich nicht, egal ob diese intern bereitgestellt oder als Service bezogen wird. Bei der Bereitstellung von AaaS ist aber zu beachten, wie sie genau erfolgt. Da ein Serviceanbieter viele Kunden hat, ist genau zu beachten, wie die Trennung der Mandanten erfolgt. Erfolgte Zertifizierungen helfen, diese Bewertung vorzunehmen.

Zudem gibt es Anforderung an die Nachweisbarkeit. Wichtig ist bei einem Bezug eines Service, dass eine lückenlose Nachweisbarkeit (oder Nichtabstreitbarkeit, engl. Non-repudiation) der Authentifizierungsvorgänge und der Konfigurationen vorliegen.

Zu den vertraglichen Aspekten: Setzt man einen Authentication-Provider beispielsweise für die Authentifizierung von Cloud-(SaaS-)Applikationen eines weiteren Providers ein, kann eine Dreiecksbeziehung bestehen. Diese muss vertraglich sauber definiert werden, damit im Fall eines Falles beispielsweise geklärt ist, wer auf die Logs zugreifen darf. Es könnte ja sein, dass eingebrochen wird, und dies wird durch den SaaS-Anbieter untersucht. Dann muss er eben auf die Daten des Authentication-Providers zugreifen dürfen.

Auch der Datenschutz spielt eine Rolle. Generell braucht der Service-Provider minimale Angaben, um eine Authentifizierung durchführen zu können. Im Minimum handelt es sich dabei um eine Verbindung des Geräts (bzw. Telefonnummer oder E-Mail Adresse), das für die Authentifizierung eingesetzt wird (2FA) und den Benutzer, für den eine Authentifizierung durchgeführt werden soll. Wird der Benutzer für diesen Vorgang anonymisiert, bestehen keine datenschutzrechtlichen Bedenken. Sofern es sich bei der Telefonnummer um eine private Telefonnummer handelt, möchte der Benutzer meistens nicht, dass diese Nummer weiter bekannt gemacht wird. Dem ist Rechnung zu tragen, ansonsten kann die Akzeptanz des Service darunter leiden.

DevOps: Die AaaS sollte sich gut in die Systemlandschaft integrieren lassen. Hierfür sind APIs für die Automatisierbarkeit der Identifizierungsprozesse ebenso notwendig wie die Möglichkeit der Einbindung in das eigene Monitoring.

Vertrauen gegen Risiko: Die meisten Benutzer benötigen keinen Zugang zu Daten und Dokumenten mit hoher Vertraulichkeit, andere aber teilweise schon. Da Sicherheit und Bedienbarkeit einander behindern, ist es sinnvoll, nicht dasselbe Zugangsverfahren bei jeder Gelegenheit zu verwenden, sondern abhängig von Sicherheitsklassifikation, Zeit, Lokation, Gerät und Benutzer eine andere Methode einzusetzen. Man nennt das auch risikobasierte Authentifizierung oder kontextbasierte Log-ins.

Zuletzt betrachten wir die Kosten, die Usability, die Prozesse und die Architektur. Zu den Kosten: Für den Vergleich der Kosten bei einem Bezug eines Cloud-Service sollten Eins-zu-eins-Vergleiche erstellt werden. So lässt sich herausfinden, ob das Kostenmodell des Providers günstiger sein wird als der Eigenbetrieb. Eine Bewertung der Usability gegen die Anforderungen der Benutzer sollte durchgeführt werden. Hierbei sollte man auch auf die Usability für den Service Desk achten. Bei den Prozessen stellt sich die Frage: Wie werden die Prozesse der Identifizierung mit der neuen AaaS-Lösung funktionieren? Reicht auch hier die Usability aus? Und zuletzt die Architektur: Ist nur On Premise oder nur Off Premise möglich, oder gibt es auch eine gemischte Variante?

Fazit

Die korrekte Identifizierung ist für den digitalen Transformationsprozess unabdingbar. Ohne Identifizierung kein Geschäft, so lautet die einfache Formel, auf die immer mehr Organisationen Rücksicht nehmen müssen. Für die Evaluation eines Systems raten wir, einen Spezialisten zu bemühen. Ist ein Authentifizierungsdienst erst einmal ausgerollt, lässt er sich später praktisch nicht mehr ersetzen, da die Kosten hierfür zu hoch wären. Die Entscheidung hat also, wie viele andere Entscheidungen in der Architektur auch, eine große Tragweite und sollte mit Bedacht gefällt werden.

Verwandte Themen:

Geschrieben von
Daniel Takai
Daniel Takai
Daniel Takai ist Enterprise-Architekt, arbeitet in der Schweiz und ist auf die digitale Transformation spezialisiert. Er berichtet regelmäßig im Java Magazin über seine Erfahrungen und Erkenntnisse. Im Frühling 2016 erscheint sein Buch über Methoden der Entwicklung von Cloud-basierten und serviceorientierten Websystemen.
Gion Manetsch
Gion Manetsch
Gion Manetsch ist Security-Architekt und arbeitet in Bern. Seine Aufgabe ist es, die Sicherheit im Aufbau von IT-Lösungen sicherzustellen, unter der Berücksichtigung von Businessanforderungen und Wirtschaftlichkeit. Dabei sollen keine Insellösungen gebaut werden, sondern immer die Gesamtsicht im Vordergrund stehen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: