Wem vertraut die Cloud beim Login?

Der Zugriff auf rund 5.000 Dropbox-Konten über offenbar unzureichend geprüfte Lenovo-IDs rückt eine Ebene der Cloud-Sicherheit in den Fokus, die in der öffentlichen Diskussion meistens zu kurz kommt. Es geht dabei nicht um eine klassische Sicherheitslücke, sondern um die Frage, auf wessen Urteil ein Dienst vertraut, wenn er einen Login akzeptiert.

Dropbox erlaubt die Anmeldung mit einem eigenen Passwort oder über Konten bei anderen Anbietern, darunter Google, Apple und Lenovo, die dann als Authentifizierungsdienste fungieren. Wer sich auf diesem Weg anmeldet, bestätigt seine Identität gegenüber dem anderen Anbieter. Die E-Mail-Adresse ist das gemeinsame Bindeglied zwischen beiden Diensten.

Eine Lenovo-ID kann jede Person unter Angabe einer E-Mail-Adresse selbst anlegen. Lenovo prüfte jedoch nicht, ob die Person, die ein Konto anlegt, überhaupt Zugriff auf das angegebene Postfach hat. Wer also die bei Dropbox hinterlegte Adresse einer anderen Person kannte oder erriet, konnte damit eine neue Lenovo-ID anlegen und sich bei Dropbox anmelden. Dropbox akzeptierte das als ausreichenden Nachweis, sofern für das Konto keine Zwei-Faktor-Authentifizierung (2FA) eingerichtet war. Auf diesem Weg erhielt ein Angreifer Zugriff auf die betroffenen Konten.

Bei der Anmeldung an einem digitalen Dienst prüft häufig ein anderer Anbieter die Identität. Die Anwendung erhält anschließend nur die Information, dass eine bestimmte Person erfolgreich authentifiziert wurde. Für die beteiligten Systeme entstehen dabei gestaffelte Vertrauensbeziehungen: Die Anwendung verlässt sich auf den Authentifizierungsdienst und dieser auf die Qualität der zugrunde liegenden Konten und Nachweise, mit denen er arbeitet.

Und darin liegt die Bedeutung des Falls, denn es wurde kein Dropbox-Passwort erraten oder gestohlen. Es reichte eine bei Lenovo frei anlegbare Identität. Die damit erzielbare Bestätigung wurde von Dropbox übernommen, ohne dass ihre Qualität hinterfragt wurde. Ein erfolgreicher Login beantwortete hier also nicht die entscheidende Frage, ob die Person, die sich anmeldet, tatsächlich diejenige ist, für die sie sich ausgibt.

Bei einem privaten Konto ist ein solcher Vorfall bereits gravierend. Und wenn Unternehmen geschäftliche Daten in einem Cloud-Dienst speichern, geht es um Geschäftsgeheimnisse, personenbezogene Daten, interne Kommunikation und Informationen von Kunden und Partnern. Für den Zugang zum eigenen Firmennetz würde kaum eine Organisation eine Lenovo-ID akzeptieren. Beim Zugriff auf dieselben Daten in der Cloud gelten in der Praxis oft andere Maßstäbe, denn dort verlassen sich viele Organisationen auf die Authentifizierung des Anbieters.

Dabei müsste eigentlich folgende Mindestanforderung gelten: Ein Dienst darf Mitarbeiterinnen und Mitarbeiter ausschließlich gegen den Authentifizierungsdienst der eigenen Organisation authentifizieren, alle weiteren Anmeldewege müssen abschaltbar sein. Vor der Freigabe eines Dienstes wie Dropbox müssen Organisationen daher klären, welche Identitätsquellen er akzeptiert, wie diese Quellen Identitäten prüfen, ob sich zusätzliche Faktoren verbindlich durchsetzen lassen, wer diese Einstellungen ändern kann und wie Zugriffsrechte bei einem Rollenwechsel oder beim Ausscheiden entzogen werden. Größe und Bekanntheit eines Anbieters ersetzen diese Prüfung nicht.

Das gilt ebenso für externe Identitätsdienste wie Microsoft Entra ID oder Okta. Sie bilden oft zentrale Bestandteile einer modernen IT-Architektur, doch wissen wir nicht, ob sie ihrerseits Systemen vertrauen, die wir nicht kennen. Mit Einschränkungen gilt das auch für Verzeichnisdienste im eigenen Haus, etwa Active Directory. Auch dort lässt sich ohne Quellcode nicht vollständig überprüfen, ob es gewollte oder ungewollte Mechanismen gibt, um Authentifizierungsanforderungen zu umgehen. Der Betriebsstandort allein sagt darüber nichts aus.

Daraus folgt, dass gerade der Authentifizierungsdienst Open Source und unabhängig betreibbar sein muss. Nur bei zugänglichem Quellcode lässt sich prüfen, welche Umgehungsmechanismen vorhanden sind, welche Abhängigkeiten ein Dienst mitbringt und welche Anmeldewege er tatsächlich akzeptiert. Unabhängige Audits werden möglich, und Organisationen behalten je nach Lösung mehr Kontrolle über Betrieb und Weiterentwicklung. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) sagt mit Recht, dass der Einsatz freier Software zwar per se keine Gewähr für ein sicheres System bietet, denn auch Open Source muss sicher gepflegt und betrieben werden. Aber Open-Source-Software bietet laut des BSI im Sicherheitsprozess bedeutende strategische Vorteile. Und darin liegt der Wert: Open Source schafft eine zentrale Voraussetzung für hohe Sicherheit.

Digitale Souveränität wird häufig mit dem Speicherort von Daten oder der Wahl einer Cloud-Infrastruktur verbunden. Sie beginnt aber bereits bei der digitalen Identität. Eine Organisation muss nachvollziehen und kontrollieren können, wer Identitäten bestätigt, welche Systeme einander vertrauen und wer diese Beziehungen ändern oder widerrufen kann. Ohne diese Kontrolle bleibt unklar, auf welcher Grundlage Zugriffe auf die eigenen Daten entstehen.

Mit der Nutzung eines Cloud-Dienstes überträgt ein Unternehmen einen Teil des IT-Betriebs an einen externen Anbieter. Die Verantwortung für die eigenen Daten und die Zugriffe darauf bleibt bestehen. Der Dropbox-Lenovo-Fall ist deshalb mehr als ein einzelner Sicherheitsvorfall, weil er die Bedeutung von durch Cloud-Diensten verwendete Anmeldeverfahren zeigt: Ein System akzeptiert die Aussage eines anderen Systems und entscheidet damit über den Zugang zu Daten, ggf. ohne dass Anwenderorganisationen das selbst kontrollieren können. Die entscheidende Frage lautet daher: Wer bestimmt, wer auf unsere Daten zugreifen darf, und können wir diese Entscheidung überprüfen?

Quellenhinweis: Ausgangspunkt des Beitrags ist der heise-Bericht „Ich mach mir eine Lenovo-ID und hol mir Deine Dropbox-Dateien“ vom 2. September 2026: https://www.heise.de/news/Fremde-Dropbox-Konten-ueber-Lenovo-ID-zugaenglich-11437565.html.