CAS Cybersecurity, Weiterbildung

Möglichkeiten und Gefahren von Identity in der Cloud

14. April 2019

Benutzen Sie auch gerne die Schaltflächen „Facebook login“ oder „Twitter login“, wenn Sie sich bei einem neuen Onlinedienst, einer App, Webseiten etc. registrieren? Oder loggen Sie sich zuhause an Ihrem privaten Windows PC mit Ihrem Microsoft Konto und nicht mehr mit einem lokal angelegten Benutzer ein? Benutzen Sie Ihre Google- oder Apple-ID um Daten von Ihrem Android oder iOS Gerät zu sichern oder mit anderen Geräten zu synchronisieren? Dann haben Sie bereits Erfahrung mit „Identity in der Cloud“!

Auch wenn die „Identity in der Cloud“ kein scharf definierter Begriff ist und sich die Angebote und Möglichkeiten je nach Anbieter stark voneinander unterscheiden, haben sie eines gemein: Ein Anbieter gibt Ihnen die Möglichkeit, eine Identität bei ihm anzulegen, mit der Sie dann verschiedene Dienste des Anbieters oder von bei ihm eingebundenen Dritten nutzen können.

Vielleicht setzen Sie bereits das „Identity-in-der-Cloud“-Verfahren von Google für Ihre Kunden ein um ihnen mühsame Registrierungsprozedere zur Benutzung der Internet-Dienste Ihres Unternehmens zu ersparen?

„Identity in der Cloud“ ist aber nicht nur etwas für Endanwender und Endanwenderinnen. Auch die Identitäten der Mitarbeitenden eines Unternehmens können in der Cloud verwaltet werden, von wo aus sie dann für die Nutzung von Cloud-Diensten zur Verfügung stehen, z.B. für die Verwendung mit „Software as a service“ (SaaS). So bieten unter anderem Google, IBM und Oracle „Cloud ID“ Dienste, oder „Identity as a service“ (IDaaS), an (siehe die Links unten). Diese Angebote sind dediziert für Unternehmen gedacht und beschränken sich dabei nicht nur auf das Verwalten von Identitäten zur Verwendung mit SaaS oder anderen Cloud-Diensten: auch Programmierschnittstellen, vorgefertigte Templates, standardisierte Single-Sing-On-Protokolle wie SAML oder andere Mechanismen werden unterstützt, um bestehende „in house-/on-premise“-Anwendungen einbinden zu können. So lassen sich z.B. Bring Your Own Device-(BYOD)-Szenarien, aber auch Single Sign On (SSO) in historisch gewachsenen, heterogenen Anwendungslandschaften von Unternehmen umsetzen.

Sowohl als Endanwender und Endanwenderin, als auch als Unternehmen, kann, bzw. muss man sich zwei Fragen bei der Benutzung von „Identity in der Cloud“ stellen:

  • Wie bedenklich ist es, wenn (andere) Unternehmen wissen, was ich wo mache und wer kann diese Informationen einsehen?
  • Wie sicher sind meine persönlichen Daten, bzw. die Daten der Mitarbeitenden, wie gross sind die Auswirkungen auf mich, sollten die Daten von unberechtigten Dritten eingesehen oder manipuliert werden (Datendiebstahl, Hacker etc.) und wie kann ich mich davor schützen?

Als Endanwender hat man in Bezug auf die erste Frage meist keine grosse Wahl, möchte man entsprechende Geräte und/oder Anwendungen überhaupt, bzw. in vollem Umfang nutzen. So muss man sich z.B. zu einem iPhone eine Apple-ID anlegen oder das mehr oder weniger konkurrenzlose Facebook lässt sich ohne Facebook-ID nicht benutzen. Das Durchlesen der umfangreichen AGBs und Nutzungsbedingungen hilft erkennen, auf was man sich dabei einlässt. Als Unternehmen wird es evtl. schwieriger, gesetzlichen Auflagen gerecht zu werden, wenn z.B. nicht klar ist, in welchem Land die Daten und damit die Identitäten gespeichert und ihr Gebrauch protokolliert werden und/oder, ob und welche Behörden oder andere Parteien dann unter welchen Umständen darauf Zugriff erhalten könnten. Bei Endanwendern und Endanwenderinnen wie auch bei Unternehmen sind einzelne Informationen für sich in der Regel meist belanglos. Was aber wenn eine Endanwenderin eine IDaaS beim gleichen Anbieter benutzt, wie sie als Mitarbeitende eines Unternehmens eine „Identity in der Cloud“ besitzt? Wenn so an zentraler Stelle verschiedenste Daten gesammelt, miteinander verknüpft und ausgewertet werden, können Zusammenhänge und Informationen preisgeben werden, die von aussen, bzw. vom Urheber weder wahrgenommen, noch kontrolliert werden können.

Bei der zweiten Frage muss man zwei Arten von Gefahren beachten:

  • Entweder wird die Identität derart manipuliert, dass sie nicht mehr brauchbar ist, z.B. Systemzugriffe damit nicht mehr möglich sind.
  • Oder sie wird „gestohlen“, so dass Unbefugte die Identität für Zwecke missbrauchen können, die nicht im Interesse des eigentlichen Besitzers der Identität liegen.

Bei der „Identity in der Cloud“ liegt der technische und physische Schutz der Identitäten primär beim Anbieter der IDaaS. Ein Unternehmen, das solche Services nutzt, hat auf diesen Schutz keinen Einfluss und wird sich in der Regel darauf verlassen, dass der Anbieter die bei ihm verwalteten Identitäten ordnungsgemäss schützt. Bei der Evaluation eines IDaaS-Anbieters kann es durchaus Sinn machen, die von ihm umgesetzten Sicherheitsstandards, bzw. die Zertifizierungen dazu (z.B. BSI IT-Grundschutz, ISO 27001 oder DSVGO) abzuklären. Sich selbst vor Ort beim Anbieter davon zu überzeugen bedeutet, wenn vom Anbieter überhaupt erlaubt, dass man selbst ein Sicherheitsaudit durchführen muss. Was dann wiederum entsprechende Kenntnisse in dieser Thematik voraussetzt und Zeit und Aufwand beansprucht.

Was bei einem Unternehmen, das den Weg der „Identiy in der Cloud“ für seine Mitarbeitenden gehen möchte weniger Sinn macht, kann bei einem Endanwender durchaus einen gewissen Schutz bieten: Diversifizierung durch die Verwendung verschiedener IDaaS-Anbieter und der damit zusammenhängenden Dienste. Wird eine Identität kompromittiert, kann eine andere für die alltäglichen Dinge weiterverwendet, bzw. damit ggf. sogar die kompromittierte Identität wiederhergestellt/gerettet werden (z.B. Zurücksetzen des Kennwortes via Email-Account eines anderen Anbieters).

Zu guter Letzt liegt es aber am Endanwender und jedem einzelnen Mitarbeitenden, dass er sich selbst und seine „Identity in der Cloud“ durch die Anwendung von allgemein gültigem „Good practice“-Verhalten bezüglich seiner Passwörter schützt, wie sie z.B. vom BSI (Bundesamt für Sicherheit in der Informationstechnik) empfohlen werden.

Über Passwörter allgemein:

https://www.bsi-fuer-buerger.de/BSIFB/DE/Empfehlungen/Passwoerter/passwoerter_node.html

Über den Umgang mit Passwörtern:

https://www.bsi-fuer-buerger.de/BSIFB/DE/Empfehlungen/Passwoerter/Umgang/umgang_node.html

Jeder zeitgemässe IDaaS-Anbieter sollte dieses technisch unterstützen können und die Mitarbeitenden müssen dahingehend geschult werden.

Mit der „Identity in der Cloud“ steigen sicherlich Chancen und Möglichkeiten. So wäre es denkbar, dass man sich bald mit der Google Cloud-ID auf Windows PCs einloggen kann (https://www.bleepingcomputer.com/news/google/you-may-soon-be-able-to-log-into-windows-10-using-a-google-account/) oder dass sich in Unternehmen Teile der „on-premise“ IT-Infrastruktur durch Cloud-Dienste wie IDaaS ablösen lassen. Diese Chancen und Möglichkeiten müssen aber mit einem gesunden Menschenverstand auf dem Hintergrund der wirklichen Bedürfnisse eines Unternehmens oder des Endanwenders betrachtet werden. Und man darf auch nicht vergessen, dass sich zwar Umsetzungen in die Cloud delegieren lassen, die Verantwortung dies korrekt zu tun aber nicht.

Links

Autor:
Frank Huber

Blogpost wurde erstellt
im Rahmen vom CAS Cybersecurity & Information Risk Management.

Dozenten in diesem sehr praxisorientierten Lehrgang sind:
Martina Dalla Vecchia (FHNW, Programmleitung)
Lukas Fässler (FSDZ Rechtsanwälte & Notariat AG)
Rainer Kessler (PwC)
Cristian Manganiello (PwC)
Andreas Wisler (goSecurity GmbH)

Beim nächsten CAS live dabei sein?
Hier der Link zur Ausschreibung:
CAS Cybersecurity & Information Risk Management
Starttermin ist jeweils im Frühjahr.

Persönliche Beratung für den Lehrgang gewünscht?
Einfach Prof. Martina Dalla Vecchia ein E-Mail schreiben und einen Termin vorschlagen.

Schlagworte: CAS Cybersecurity, Cloud

zurück zu allen Beiträgen
×