Nicht erst seit dem Beginn der zweiten Amtszeit Donald Trumps wird diskutiert, ob die Abhängigkeit von nichteuropäischen Cloud-Anbietern zu groß ist – von Hyperscalern wie AWS und Azure ebenso wie von Alibaba oder Huawei Cloud. Insbesondere für sicherheitskritische Anwendungen der öffentlichen Verwaltung und für Betreiber kritischer Infrastrukturen und Dienstleistungen gilt: Auf der Suche nach performanten und unabhängigen Lösungen gibt es viele Versprechungen – doch bei den Kriterien gibt es oft wenig Klarheit. Ist eine Cloudlösung souverän, wenn sie technisch sicher in der EU betrieben wird? Unabhängig von der Infrastruktur eines US-Unternehmens? Ohne Abhängigkeit von Instanzen außerhalb? Technische IT-Sicherheit ist das eine, technische Souveränität ein nicht immer deckungsgleiches Anforderungsprofil.

Die engeren Sicherheitseigenschaften von Cloud-Diensten definiert bereits der kürzlich aktualisierte Cloud Computing Compliance Criteria Catalogue (C5). Der nun vorgestellte Vorschlag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) setzt beim zweiten Begriff an: Die Fachleute der Bonner Bundesbehörde haben mit ihren heute veröffentlichten „Criteria Enabling Cloud Computing Autonomy“ (C3A) einen Vorschlag vorgelegt. Nutzer sollen damit von vornherein prüfen können, ob ein Dienst tatsächlich zu ihrem jeweiligen Souveränitäts-Risiko passt. Die Behörde begleitet die Diskussionen seit vielen Jahren als IT-Sicherheitsdienstleister der Bundesverwaltung. Sie will damit vor allem eines leisten: „Es geht uns um technisch tragfähige Lösungen, die konkrete Bedingungen formulieren“, sagt Thomas Caspers, Vizepräsident des BSI.

Weniger diplomatisch interpretiert: Statt politisch lange über die Unabhängigkeit eines Anbieters zu diskutieren, will die Behörde mit einem konkreten Vorschlag in die Debatte um die Folgen des Cloud and AI Development Act (CADA) einsteigen. Den CADA will die EU-Kommission nach aktueller Zeitplanung am 27. Mai vorlegen; anschließend beraten ihn Mitgliedstaaten und Europaparlament. Denn Beobachter erwarten, dass EU-Vizekommissionspräsidentin Henna Virkkunen mit dem CADA klarere Kriterien für Cloud-Souveränität vorgibt – und Diskussion und Lobbying mit der Vorstellung des Vorhabens im Mai erst richtig beginnen.

Praxiserfahrungen und EU-Kriterien

Dabei baut das BSI unter anderem auf sechs der acht Kriterien auf, die die eigentlich nur für die EU-Kommissions-eigene IT zuständige Generaldirektion DIGIT im vergangenen Jahr definiert hatte und konkretisiert diese um breitere Erfahrungen. Vor allem die französische IT-Sicherheitsbehörde ANSSI und das BSI haben umfangreiche Erfahrungen mit verschiedenen Abhängigkeitsvariationen gesammelt – in Deutschland zum Beispiel mit der SAP-Microsoft-Kooperation DelosCloud, mit Stackit von Schwarz-Digits oder der T-Systems-Sovereign-Cloud in Kooperation mit Google, mit Anforderungen etwa für „Polizei 2020“ (P20) oder für Amazons European Sovereign Cloud-Angebot. Parallel testete die dem französischen Premierminister unterstellte Behörde einen anderen Pfad, bei dem für die öffentliche Verwaltung stets französische Unternehmen beteiligt sind – beispielsweise der Rüstungskonzern Thales beim im Dezember nach den französischen SecNumCloud-Anforderungen zertifizierten S3NS, das zusammen mit Google betrieben wird oder etwa SAP auf OVH-Hardware.

Genau solche Erfahrungen sollen nun für die Zukunft relevant werden. Dass das BSI die C3A-Systematik nicht im luftleeren Raum entwickelt hat, sondern auch mit Anbietern gesprochen hat, zeigen auch eng daran angelehnte eigene Bewertungsstandards aus der Branche. „Wir haben unter anderem am Beispiel der AWS European Sovereign Cloud gesehen, wie viele Mechanismen eine Rolle spielen, um eine Cloud betriebsfähig zu halten“, erklärt Caspers. „Komplett entkoppelt wird man solche Angebote aber nicht über Jahre weiterbetreiben können.“

Kriterien vom Disconnect bis zum Verteidigungsfall

In den C3A sieht das dann beispielsweise so aus: SOV-4-09-C der C3A definiert, was bei einem Disconnect – also der Abkopplung von der außereuropäischen Betreibercloud – gewährleistet sein muss: Im Kern muss der Betrieb weiterlaufen, ohne dass Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit leiden. Zudem muss es einen dokumentierten Prozess für das Vorgehen und die Durchführung der Abkopplung geben und der Betreiber muss dies mindestens einmal jährlich getestet und dokumentiert haben, inklusive der Ergebnisse des Tests. Wer das weitergehende Kriterium SOV-4-09-AC erfüllen will, muss zudem seine Dokumentation mit den zuständigen IT-Sicherheitsbehörden am Ort des Rechenzentrums auf deren Verlangen hin teilen.

Ähnlich konkret sind auch die Vorgaben in juristischer Hinsicht, etwa wenn es darum geht, dass die Anbieter keiner Nicht-EU-Jurisdiktion unterliegen dürfen oder bei der Frage, von wo aus Mitarbeiter die wesentlichen IT-Pflegemaßnahmen durchführen. Und auch bei der Auswahl der Mitarbeiter gibt es entsprechend gestufte Kriterien: So verlangt SOV-4-01-C1, dass alle Mitarbeiter, die logischen oder physischen Zugang zu Betriebsmitteln des Clouddienstleisters haben, eine EU-Staatsbürgerschaft und einen EU-Wohnsitz haben müssen – noch schärfer ist die Anforderung nach SOV-4-01-C2: dann müssen alle Mitarbeiter nicht nur EU-Bürger sein, sondern auch ihren Wohnsitz innerhalb der Bundesrepublik haben.

Dieses Kriterium kommt insbesondere für Hochsicherheitsanwendungen in Frage, etwa für Sicherheitsbehörden oder auch die Bundeswehr. Für die hat das BSI zwar keine direkte gesetzliche Zuständigkeit. Doch für den Fall der Fälle enthalten die C3A ebenfalls Prüfkriterien. Denn was im grundgesetzlich geregelten Verteidigungsfall erfüllt sein sollte, wird nun auch klar definiert: entsprechend dem Muster aller Notstandsgesetzgebung müssen Clouddienstleister in der Lage sein, den Betrieb an die Bundesbehörden zu übergeben – „inklusive des notwendigen Materials und Personals“.

Potenziell weitreichende Auswirkungen

So wie ursprünglich auch beim C5-Katalog, der zwischenzeitlich jedoch etwa im Sozialgesetzbuch für die Gesundheits-IT qua Gesetz für verbindlich erklärt wurde, ist das bei den C3A ebenfalls nicht direkt der Fall. „Die Criteria Enabling Cloud Computing Autonomy sind aus sich heraus nicht verbindlich“, erklärt Caspers. „Sie können aber natürlich im Rahmen von Gesetzgebung oder bei Ausschreibungen zu Mindestanforderungen erklärt werden.“ Die C3A können jedoch, meint der Vizepräsident des Bundesamtes für Sicherheit in der Informationstechnik, „zur Benchmark der Bundesverwaltung werden.“

Das kommt auch durch eine Wechselwirkung der Vorgaben. „Stellen des Bundes sind verpflichtet, den IT-Grundschutz des BSI umzusetzen“, erklärt Martin Bierwirth, Referatsleiter Cloud-Sicherheit beim BSI. „Sofern sie externe Cloud-Dienste nutzen, müssen sie in diesem Rahmen auch den Baustein OPS 2.2 anwenden und erfüllen.“ Auf diesem baue auch der Mindeststandard zur Nutzung externer Cloud-Dienste (MST-NCD) auf. Die C3A wiederum würden auf dem C5 aufbauen und dessen Kriterien zur Informationssicherheit mit dem Thema digitale Souveränität ergänzen. Wer also nicht nur sichere, sondern auch souveräne Vorgaben erfüllen muss, wird darum in der Bundesrepublik absehbar schwer herumkommen. Ob große Hyperscaler diese erfüllen können, dürfte vom jeweiligen Anforderungsprofil der Kunden abhängen – und vom Druck, souveräne Lösungen wählen zu müssen.

Je nachdem, wie sich die europäische Diskussion weiterentwickelt, könnten die neuen Kriterien aber auch jenseits von Rhein und Oder eine maßgebliche Rolle spielen. Sollten mit dem Cloud and AI Development Act der EU solche Kriterien Einzug in die Anhänge der IT-Sicherheitsgesetze wie NIS2 oder Cybersecurity Act finden, würde wohl kaum ein Weg an dem deutschen Vorschlag vorbeiführen.

(fo)

Die Phishing-Attacke über den Messenger Signal hat die höchste Ebene der Politik erreicht. Zwei Ministerinnen und die Bundestagspräsidentin sind offenbar auf den Trick hereingefallen – und haben damit ihre Kontakte, Telefonnummern, Netzwerke und vermutlich auch Chat-Inhalte dem Angreifer offengelegt. Zahlreiche Signal-Gruppen im parlamentarischen Raum sollen derzeit von den Angreifern nahezu unbemerkt ausgelesen werden können, sagen Sicherheitskreise gegenüber dem Spiegel.

Deutsche Medien berichten aufgeregt von einem „Signal-Hack“. Nur ist Phishing eben gerade kein üblicher „Hack“. Es handelt sich hier nicht um ein Softwareproblem oder eine Sicherheitslücke im Code, sondern einen Angriff auf die gutgläubige Person am Smartphone. Die vertraut dem sicheren Messenger so sehr, dass sie den mehr oder weniger plumpen Nachrichten eines gefälschten Signal-Supports Glauben schenkt und dann freigiebig und naiv ihre privaten Sicherheitscodes an die Angreifer herausgibt. Gleich zwei Mal hintereinander.

Das kann passieren, denn die Angreifer spielen mit der Angst des Ziels, setzen es unter Druck. Wer nicht mit den Grundlagen der IT-Sicherheit vertraut ist, kann darauf hereinfallen. So bitter das ist.

Umso mehr würde man von einer Spionageabwehr erwarten, dass sie vor solchen Attacken warnt – und vor allem auf höchster Ebene mit Nachdruck und frühzeitig sagt: „Wenn Sie ein vermeintlicher Signal-Support anschreibt, folgen Sie niemals dessen Anweisungen. Finger weg, das ist gefährlich! Der Signal-Support schreibt niemanden auf Signal an.“

Haben die Behörden versagt?

Wir wissen, dass diese Art der Phishing-Attacke seit mindestens September 2025 im Umlauf ist und schon früh auch Abgeordnete des Bundestages im Visier waren. Eine große Frage ist, wann die für die Abwehr von solchen Attacken zuständigen Behörden BSI und Verfassungsschutz selbst aktiv geworden sind und Regierung und Parlament gewarnt haben. Erst nach unserer Berichterstattung im Januar gab es Anfang Februar eine offizielle Mitteilung der beiden Behörden. Haben diese erst so spät reagiert?

Daran schließt sich die Frage an: Wann sind die mittlerweile angeblich 300 Betroffenen, die Bundestagspräsidentin und die beiden Ministerinnen auf das Phishing hereingefallen? Funktionieren hier Warnmechanismen nicht oder werden ignoriert? Und was hilft in Zukunft gegen solche geschickten, aber doch trivialen Angriffe?

Immer mehr Spuren beim Messenger-Phishing weisen auf Russland

Aktionismus hilft nicht

Was auf jeden Fall nicht hilft, sind spontan aufgestellte Forderungen wie die der Bundestagsvizepräsidentin Andrea Lindholz (CSU). Sie will als Konsequenz aus dem Schlamassel den Messenger Signal im Bundestag verbieten. Stattdessen sollen die Abgeordneten den „Bundes-Messenger“ Wire nutzen. Das ist realitätsfern wie unsinnig.

Signal hat sich nicht ohne Grund als sicherer Messenger in Politik, Journalismus und Aktivismus etabliert. Er macht es endlich einfach, dass Menschen verschlüsselt, vertraulich und privat kommunizieren können – ohne sich in die Untiefen von E‑Mail-Verschlüsselung einarbeiten zu müssen. Das ist ein großer Gewinn an Sicherheit.

Phishing ist auf allen möglichen Kommunikationskanälen und Programmen möglich: Nicht ohne Grund hat noch niemand ernsthaft gefordert, E‑Mails zu verbieten, weil darüber Phishing stattfindet. Dieser Art des Angriffs begegnet man mit Aufklärung, Warnungen und vor allem digitaler Bildung, nicht mit unsinnigen Verboten.

Die Programmierer des DNS-basierten Werbeblockers Pi-hole haben am Wochenende aktualisierte Pakete veröffentlicht. Sie schließen zwei Sicherheitslücken, die als hochriskant gelten.

Die Updates gelten den Komponenten Pi-hole Core und FTL (Faster-Than-Light, der DNS-Server von Pi-hole). Eine Lücke betrifft beide Komponenten und ermöglicht Angreifern, ihre Rechte auf verwundbaren Systemen auszuweiten. Die Programmierer erklären, dass der Pi-hole-User Schreibzugriff auf die zentrale Konfigurationsdatei „/etc/pihole/pihole.toml“ hat. Zwei Shell-Skripte lesen den Pfad zur „files-pid“-Datei und nutzen ihn ohne weitere Prüfungen für Installation und Löschen – und laufen dabei als root („pihole-FTL-prestart.sh“ und „pihole-FTL-poststop.sh“). Angreifer mit Pi-hole-Rechten können dadurch Dateien mit root-Rechten löschen und anlegen, und das sogar außerhalb des geschützten Verzeichnisses. Ein Beispiel nennt das Advisory, das lokale root-Rechte durch Manipulation der Authorized-Keys-Datei für SSH erreicht (CVE-2026-41489, CVSS 8.8, Risiko „hoch“).

Eine unzureichende Filterung im „dns.interface“-Konfigurationsfeld in Pi-hole FTL führt dazu, dass Zeilenumbruch-Zeichen akzeptiert werden. Angreifer können beliebige Direktiven in die dnsmasq-Konfiguration schmuggeln. Die weitverbreitete Konfiguration ohne Admin-Passwort erlaubt den API-Zugriff ohne Zugangsdaten. Bösartige Akteure können eine „dhcp-script=“-Direktive einschmuggeln und DHCP aktivieren. Sofern ein Gerät im Netzwerk ein DHCP-Lease anfragt, können dadurch beliebige Befehle ausgeführt werden (CVE-2026-39849, CVSS 8.7, Risiko „hoch“).

Verwundbare Software

Verwundbar sind Pi-hole Core und Pi-hole FTL ab Version 6.0. Die Updates auf die neuen Fassungen Pi-hole Core 6.4.2 sowie Pi-hole FTL 6.6.1 oder neuer korrigieren die sicherheitsrelevanten Fehler. Auf dem Raspberry Pi, auf dem die Software standardmäßig läuft, führt der Befehl sudo pihole -up dazu, dass der Werbeblocker sich aktualisiert.

Zuletzt hatte das Pi-hole-Projekt Anfang April Sicherheitslücken geschlossen. Sie erlaubten Angreifern unter anderem das Einschleusen von Schadcode.

(dmk)