Software Archive - RDDZ

PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab

dennis_rddz — Thu, 22 Oct 2026 21:16:55 +0000

SICHERHEIT · PHP · STAND 22.10.2026

PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab

Die kritischen PHP-Schwachstellen PHP2Shell (CVE-2026-109618 und CVE-2026-109619) sind öffentlich bekannt, Sicherheitsanbieter berichten von Ausnutzungsversuchen. Wer inzwischen aktualisiert hat, sollte noch eine Frage klären: Gibt es Hinweise darauf, dass vor dem Update bereits jemand versucht hat, die Lücken auszunutzen? Wir zeigen, welche Spuren sich prüfen lassen, welche Befehle helfen und wo die Grenzen liegen.

SPURENSUCHE · PHP2SHELL

● Erste Orientierung

17.10.2026

Frühester beobachteter Versuch

3 Stufen

Exploit, Versuch, Erfolg

Mehrere

Datenquellen kombinieren

Webserver-Logs● Body oft nicht geloggt

PHP-Fehlerlogs● Fehler auch ohne Angriff

Prozesse● nur Momentaufnahme

Dateien● Zeitstempel manipulierbar

Netzwerk● nur aktueller Zustand

Jede Quelle hat Grenzen. Erst das Zusammenspiel liefert belastbare Hinweise.

✓ Praxisbefehle für Debian und Ubuntu

✓ Prüfzeitraum ab 17. Oktober 2026

✓ Mit ehrlichen Grenzen der Analyse

✓ Vorgehen bei konkretem Verdacht

LAGE

Was ist über tatsächliche Angriffsversuche bekannt?

Ein erfolgreiches Update behebt die bekannte Schwachstelle in der aktualisierten PHP-Laufzeit. Es kann aber nicht rückwirkend ausschließen, dass ein Angreifer vorher bereits Code ausgeführt, Dateien verändert oder weitere Zugänge eingerichtet hat. Die Hintergründe zu den Schwachstellen und den korrigierten Versionen findest du in unserem PHP2Shell-Hauptbeitrag.

PHP2Shell umfasst zwei kritische Schwachstellen im PHP-Kern. Unter bestimmten Voraussetzungen kann ein nicht authentifizierter Angreifer darüber Code auf einem verwundbaren System ausführen. Am 21. Oktober 2026 wurden die korrigierten PHP-Versionen veröffentlicht.

Amazon Threat Intelligence berichtet von einem Ausnutzungsversuch gegen die eigene Honeypot-Infrastruktur bereits am 17. Oktober sowie von weiteren Aktivitäten am 21. Oktober. Die ersten öffentlich kursierenden Proofs of Concept tauchten laut Amazon noch am 21. Oktober gegen 02:00 UTC auf, also vor der Veröffentlichung der Updates um 14:00 UTC. Das PHP-Projekt erklärte laut Tenable allerdings, in den ihm bekannten PoCs zum Zeitpunkt der Veröffentlichung keine funktionsfähigen Exploits gefunden zu haben. Die Funktionsfähigkeit einzelner Codes ist also nicht unabhängig bestätigt, und angeblicher Exploit-Code im Netz kann selbst Schadsoftware enthalten.

Es geht damit nicht mehr nur um eine theoretische Angriffsmöglichkeit, denn es gibt konkrete Berichte über Versuche. Allerdings müssen drei Dinge auseinandergehalten werden:

Ein Exploit ist verfügbar

Ein technischer Ansatz zur Ausnutzung ist beschrieben oder im Umlauf. Ob konkreter Code funktioniert, ist damit noch nicht gesagt.

Ein Angriff wurde beobachtet

Ein System hat eine Anfrage oder Aktivität erkannt, die mit dem Exploit zusammenhängt. Das beweist keine erfolgreiche Kompromittierung.

Ein Angriff war erfolgreich

Es gibt belastbare Hinweise, dass tatsächlich Code ausgeführt oder das System kompromittiert wurde.

Diese Aussagen sind nicht gleichbedeutend. Umgekehrt lässt sich eine frühere Kompromittierung nicht allein deshalb ausschließen, weil keine offensichtlichen Fehlermeldungen gefunden werden.

SCHRITT 1

Zuerst feststellen, welche Systeme betroffen waren

Bevor Logs ausgewertet werden, sollte klar sein, welche PHP-Installationen überhaupt exponiert waren. Dabei reicht es nicht, nur den Hauptwebserver zu betrachten. PHP kann auf einem System in mehreren Versionen und Betriebsarten installiert sein, und Anwendungen können ihre eigene Runtime mitbringen. Relevant sind insbesondere:

PHP-FPM hinter Nginx oder Apache
Apache mit mod_php
php-cgi
PHP innerhalb von Docker-Containern
PHP-basierte Verwaltungsoberflächen
Drittanbieterprodukte mit integrierter PHP-Laufzeit
ältere Anwendungen auf nicht mehr unterstützten PHP-Versionen

Die PHP-Sicherheitsmeldung nennt diese Betriebsarten ausdrücklich. Besonders kritisch ist laut PHP die Konfiguration mit Apache mod_php, weil ein präparierter Request die Schwachstelle auslösen kann, bevor der eigentliche Anwendungscode ausgeführt wird.

🔍

Installierte Versionen und Prozesse

Auf Debian und Ubuntu liefern diese Befehle eine erste Übersicht:

Bash

php -v

dpkg -l | grep -E 'php[0-9.]|php-fpm|libapache2-mod-php'

ps -eo pid,ppid,user,lstart,args \
  | grep -E '[p]hp-fpm|[p]hp-cgi|[a]pache2|[h]ttpd'

Wichtig: php -v zeigt die Version der PHP-CLI. Diese muss nicht der Version entsprechen, die eine Website tatsächlich verwendet. Auch Paketlisten reichen nicht, um PHP in Containern oder Drittanbieterprodukten zu erfassen.

📦

Docker

Zeigt zunächst nur laufende Container und deren Images:

Bash

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Ob und welche PHP-Version enthalten ist, muss anschließend innerhalb der jeweiligen Runtime oder anhand des Images geprüft werden, etwa mit docker exec php -v.

SCHRITT 2

Webserver-Logs auf auffällige Requests untersuchen

Ein wichtiger Ansatzpunkt sind die HTTP-Zugriffe. Bei PHP2Shell sind insbesondere POST-Anfragen mit multipart/form-data relevant, das Format, das etwa bei Datei-Uploads verwendet wird. Außerdem ist das Feld PHP_SESSION_UPLOAD_PROGRESS von Interesse: Amazon Threat Intelligence empfiehlt ausdrücklich, nach POST-Anfragen zu suchen, die dieses Feld enthalten, und Webserver-Logs auf verdächtige Aktivitäten zu prüfen.

Das bedeutet nicht, dass jede solche Anfrage bösartig ist. Uploads gehören bei vielen Anwendungen zum normalen Betrieb. Entscheidend sind Kontext, Häufigkeit, Aufbau der Anfrage und mögliche Folgeaktivitäten.

Die Grenze klassischer Access-Logs

Klassische Access-Logs enthalten die HTTP-Methode, den Pfad, den Statuscode und die Antwortgröße, aber weder den Content-Type noch den Inhalt des Request-Bodys. Ein einfacher Textfilter nach multipart/form-data findet dort deshalb nichts, und ein Filter nach POST liefert auf aktiven Websites Tausende Treffer. Wenn der Inhalt einer Anfrage nicht protokolliert wurde, kann ein einfacher Textfilter den Angriff nicht erkennen.

Systeme mit zentraler Protokollierung, vorgeschaltetem Reverse Proxy, CDN oder Web Application Firewall müssen gegebenenfalls an mehreren Stellen untersucht werden.

🔒

POST-Anfragen mit Serverfehler

Als grobe Orientierung lassen sich POST-Anfragen herausfiltern, die mit HTTP 500 endeten. Das Beispiel geht vom üblichen Combined-Log-Format aus, bei dem der Statuscode das neunte Feld ist:

Bash

sudo zgrep -h '"POST ' \
  /var/log/nginx/access.log* \
  /var/log/apache2/access.log* 2>/dev/null \
  | awk '$9 == 500' | head -50

Ein Treffer ist kein Beweis, Treffer häufen sich aber auch bei fehlerhaften Anwendungen. Abweichende Log-Formate müssen angepasst werden.

🔍

Nach PHP_SESSION_UPLOAD_PROGRESS suchen

Das funktioniert nur dort, wo Request-Bodys oder WAF-Ereignisse protokolliert werden, etwa in ModSecurity-Audit-Logs (Pfad je nach Setup) oder in einer vorgeschalteten WAF:

Bash

sudo zgrep -Ein \
  'PHP_SESSION_UPLOAD_PROGRESS' \
  /var/log/nginx/* \
  /var/log/apache2/* \
  2>/dev/null

Ein Treffer ist ein Anlass zur näheren Untersuchung, kein Beweis. Ein fehlender Treffer ist keine Entwarnung, denn bei nicht geloggtem Body kann der Begriff schlicht nicht vorkommen.

SCHRITT 3

PHP- und Webserver- Fehlerlogs prüfen

Beide Schwachstellen betreffen interne Abläufe in PHP. Deshalb können Fehler rund um die Verarbeitung einer Anfrage Hinweise liefern, zum Beispiel:

Auffällige Häufungen von Speicherfehlern und Meldungen über Speichererschöpfung
Ungewöhnliche Abstürze oder Segmentation Faults
Neustarts von PHP-FPM-Workern
Wiederholte HTTP-500-Antworten
Ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies (Hinweis von Wiz)
Zeitlich auffällige Kombinationen aus HTTP-Anfragen und PHP-Fehlern

Solche Ereignisse sind nicht automatisch ein Angriff. Speicherfehler können auch durch reguläre Last, fehlerhafte Anwendungen oder zu knapp konfigurierte Ressourcen entstehen. Umgekehrt weist Datadog darauf hin, dass erfolgreiche Ausnutzung den Worker nicht zwingend zum Absturz bringt. Fehlende Fehlermeldungen sind deshalb keine Entwarnung.

📜

Systemmeldungen durchsuchen

Auf Systemen mit systemd lassen sich die vergangenen Tage so untersuchen. Den Zeitraum bitte an den tatsächlichen Untersuchungszeitraum anpassen:

Bash

sudo journalctl \
  --since "2026-10-17 00:00:00" \
  --until "2026-10-22 23:59:59" \
  | grep -Ei \
  'php|php-fpm|out of memory|memory exhausted|segfault|fatal error'

📁

Eigene Logdateien nicht vergessen

PHP kann Fehler auch in eigene Dateien schreiben. Auf Debian und Ubuntu liegen die Logs von PHP-FPM meist unter /var/log/php-fpm.log (zum Beispiel /var/log/php8.4-fpm.log), bei Apache mit mod_php landen PHP-Fehler im Apache-Error-Log, etwa /var/log/apache2/error.log.

Der genaue Speicherort hängt von der Konfiguration (error_log) ab und sollte pro System geprüft werden.

Worauf kommt es bei der Auswertung an?

Ein einzelner PHP-Fehler ist noch kein Nachweis einer Kompromittierung. Verdächtiger wäre eine zeitliche Abfolge aus (1) einer ungewöhnlichen POST-Anfrage, (2) einem auffälligen PHP-Fehler, (3) dem Start eines bislang nicht beobachteten Prozesses und (4) einer unerwarteten Dateiänderung oder ausgehenden Netzwerkverbindung. Eine solche Kette ist ein Ansatzpunkt für eine Incident-Response-Untersuchung und sollte anhand der vorhandenen Daten verifiziert werden.

SCHRITT 4

Prüfen, ob PHP ungewöhnliche Prozesse gestartet hat

Eine erfolgreiche Remote-Code-Ausführung kann dazu führen, dass ein PHP-Prozess weitere Programme startet. Deshalb lohnt sich ein Blick auf die Prozesshierarchie. Auch die Erkennungsansätze etwa von Elastic setzen genau hier an: Auffällig sind Shells, Skript-Interpreter oder Download-Werkzeuge (curl, wget), die von PHP-FPM oder einem Webserver-Prozess gestartet werden, sowie Programme, die aus /tmp, /dev/shm oder dem Webroot laufen. Aufklärungsbefehle wie id, whoami oder uname -a unter dem Webserver-Benutzer sind ebenfalls ein Warnsignal. Sie können in legitimen Anwendungen vorkommen und müssen im Kontext des Dienstes bewertet werden.

Bash

ps -eo pid,ppid,user,lstart,args --forest

Achte auf unerwartete Kindprozesse von PHP-FPM oder Apache, Prozesse unter dem Webserver-Benutzer, die nicht zum Betrieb gehören, unbekannte Skripte oder ausführbare Dateien, ungewöhnliche Prozessketten und Prozesse, deren Startzeit zu verdächtigen HTTP-Anfragen passt.

Der Befehl zeigt nur eine Momentaufnahme: Bereits beendete Prozesse erscheinen nicht mehr. Wer vor dem Angriff keine Prozessaktivitäten protokolliert hat, kann einen beendeten Prozess normalerweise nicht allein durch eine nachträgliche Abfrage rekonstruieren. Hilfreicher sind historische Daten aus Prozessüberwachung, Audit-Protokollierung oder einem Endpoint-Detection-System, sofern sie schon vor dem Vorfall aktiv waren.

SCHRITT 5

Webverzeichnisse auf unerwartete Änderungen prüfen

Wenn ein Angreifer Code ausführen konnte, könnte er Dateien verändert oder zusätzliche Skripte abgelegt haben. Untersucht werden sollten insbesondere Webroots und Upload-Verzeichnisse, Verzeichnisse mit PHP-Skripten, temporäre Verzeichnisse, vom Webserver beschreibbare Verzeichnisse sowie Konfigurationsdateien und geplante Aufgaben. Dabei sind reguläre Änderungen durch Deployments, CMS-Updates, Uploads und Wartung von unbekannten Änderungen zu unterscheiden.

📄

Kürzlich veränderte Dateien

Für ein Webverzeichnis unter /var/www lassen sich Skripte suchen, die seit dem 17. Oktober geändert wurden. Das ist genauer als ein relativer Zeitraum wie -mtime -7, der mit jedem Tag verrutscht:

Bash

sudo find /var/www -type f \
  \( -name '*.php' -o -name '*.phtml' \) \
  -newermt '2026-10-17' -ls

⏰

Geplante Aufgaben

Neue Cron-Einträge können auf Persistenz hinweisen:

Bash

ls -la /etc/cron.d /var/spool/cron/crontabs

Besonders prüfenswert sind unbekannte PHP-Dateien, unerwartete Änderungen an vorhandenen Skripten sowie neue Dateien in Verzeichnissen, in denen normalerweise keine ausführbaren Skripte liegen. Eine große Trefferliste ist bei aktiv betriebenen Websites normal, vergleiche sie deshalb mit bekannten Deployments, Paketupdates und Backups.

Was dieser Dateicheck nicht leisten kann

Ein Angreifer kann Dateien verändern, Zeitstempel beeinflussen oder Code an vorhandene Dateien anhängen. Umgekehrt erzeugen normale Updates viele legitime Änderungen. Der Befehl ist deshalb nur eine erste Bestandsaufnahme. Belastbarer sind bekannte Sollzustände, Versionskontrolle, vertrauenswürdige Backups oder Integritätsprüfungen.

SCHRITT 6

Ausgehende Netzwerkverbindungen untersuchen

Ein kompromittierter Webserver könnte versuchen, weitere Systeme zu erreichen, Daten zu übertragen oder zusätzliche Dateien abzurufen. Deshalb sollte geprüft werden, ob PHP-Prozesse oder andere Prozesse unter dem Webserver-Benutzer ungewöhnliche ausgehende Verbindungen aufbauen.

Bash

sudo ss -tpn

Der Befehl zeigt aktuelle TCP-Verbindungen und, soweit verfügbar, die zugehörigen Prozesse. Auch hier gilt: Es ist nur der aktuelle Zustand, eine bereits beendete Verbindung lässt sich damit nicht nachweisen. Für eine rückwirkende Untersuchung sind vorhandene Firewall-, DNS-, Proxy-, NetFlow- oder EDR-Protokolle wesentlich wertvoller. Ein Webserver kann außerdem durch reguläre API-Aufrufe, Updates oder externe Dienste legitime Verbindungen aufbauen, auffällige Verbindungen müssen deshalb im Zusammenhang mit Prozessen und dem jeweiligen Dienst bewertet werden.

ZEITRAUM

Den Zeitraum vor dem Patch nicht vergessen

Wer am 21. Oktober oder später aktualisiert hat, sollte bei einer rückwirkenden Untersuchung nicht nur die Zeit nach dem Update betrachten. Amazon Threat Intelligence hat einen Ausnutzungsversuch bereits am 17. Oktober 2026 beobachtet und empfiehlt, Untersuchungen ab diesem Datum zu beginnen. Je nach Systemhistorie kann ein sinnvoller erster Prüfzeitraum deshalb bis zum 17. Oktober zurückreichen, bei konkreten Hinweisen auch weiter. Angreifer könnten eine Schwachstelle außerdem schon vor der öffentlichen Bekanntgabe gekannt haben.

Eine sinnvolle Zeitleiste umfasst:

den Zeitraum vor der öffentlichen Veröffentlichung,
den Tag der Veröffentlichung und der Verfügbarkeit von Exploits,
den Zeitpunkt der eigenen Aktualisierung,
die Zeit nach dem Update, falls weiterhin verdächtige Aktivitäten auftreten.

Die Grenzen sind klar: Wenn Logs bereits rotiert wurden, Request-Bodys nicht protokolliert wurden oder keine Prozessüberwachung existierte, kann die rückwirkende Prüfung unvollständig bleiben.

VERDACHT

Was tun bei einem konkreten Verdacht?

Wenn mehrere Indikatoren zusammenpassen, sollte die Untersuchung nicht bei einzelnen Shell-Befehlen enden.

Beweise sichern

Webserver-, PHP-, System-, Firewall- und Sicherheitslogs sichern. Zeitstempel, betroffene Systeme und auffällige Ereignisse dokumentieren. Vorschnelle Bereinigungen vermeiden, sie können Beweise zerstören.

System bewerten und isolieren

Ist eine erfolgreiche Kompromittierung wahrscheinlich, das System nach einem geeigneten Incident-Response-Verfahren isolieren und dabei die Auswirkungen auf produktive Dienste berücksichtigen.

Nicht nur nach Schadsoftware suchen

Ein Angreifer muss keine dauerhafte Datei hinterlassen. Auch Prozesse, Benutzerkonten, SSH-Zugänge, geplante Aufgaben, Dienste, Konfigurationsänderungen und ausgehende Verbindungen gehören in die Untersuchung.

Zugangsdaten und Geheimnisse bewerten

Bei bestätigter oder stark vermuteter Kompromittierung prüfen, welche Zugangsdaten, Tokens oder API-Schlüssel das System erreichen konnte. Je nach Befund ist eine Rotation nötig.

Wiederherstellung nicht mit Patchen verwechseln

Ein Sicherheitsupdate behebt die bekannte Schwachstelle. Bei bestätigter Kompromittierung müssen zusätzlich unerwünschte Änderungen und Persistenzmechanismen beseitigt werden. In schwerwiegenden Fällen kann ein Neuaufbau aus einem vertrauenswürdigen Zustand sicherer sein, als nur verdächtige Dateien zu löschen.

GRENZEN

Warum es keine einfache Entwarnung gibt

Die beschriebenen Prüfungen liefern Hinweise, aber keine universelle Garantie. Angriffsspuren können in Webserver-Logs fehlen, weil der Request-Body nicht protokolliert wurde. Laut Wiz laufen die Schwachstellen unterhalb der Anwendungsebene, Anwendungslogs zeigen deshalb oft wenig. Prozessinformationen gehen verloren, wenn keine historischen Daten aufgezeichnet wurden, und Dateien können verändert oder entfernt worden sein, bevor die Untersuchung beginnt.

Umgekehrt können legitime Uploads, PHP-Fehler und reguläre Deployments einzelne Indikatoren auslösen, ohne dass ein Angriff stattgefunden hat. Die beste Bewertung entsteht aus mehreren unabhängigen Datenquellen: HTTP-Zugriffen, PHP-Fehlern, Prozessaktivitäten, Dateiänderungen, Netzwerkdaten und bekannten Änderungen am System.

Liegen konkrete Hinweise auf eine Kompromittierung vor, ist eine strukturierte Incident-Response-Untersuchung sinnvoller als der Versuch, mit einem einzelnen Befehl Sicherheit zu beweisen.

BEI RDDZ

Was wir bei RDDZ empfehlen

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr gepatcht. Das war der entscheidende Schritt, um die bekannten Schwachstellen in den aktualisierten Umgebungen zu beheben. Eine rückwirkende Prüfung auf frühere Ausnutzung ist davon getrennt zu betrachten.

Wir empfehlen Betreibern deshalb, nicht nur die installierten PHP-Versionen zu kontrollieren, sondern auch die vor dem Update verfügbaren Protokolle und Systeminformationen zu prüfen. Bei öffentlich erreichbaren Systemen sollten insbesondere ungewöhnliche HTTP-Anfragen, auffällige PHP-Fehler, unerwartete Prozesse und unbekannte Dateiänderungen untersucht werden.

Ein erfolgreiches Update ist notwendig. Eine belastbare Aussage über eine mögliche frühere Kompromittierung erfordert jedoch eine separate Untersuchung.

FAZIT

Patchen ist der Anfang, nicht die gesamte Untersuchung

PHP2Shell zeigt, wie schnell eine kritische Schwachstelle in einer weit verbreiteten Laufzeitumgebung zu einem praktischen Sicherheitsproblem werden kann. Die verfügbaren Updates sollten unverzüglich installiert werden. Zusätzlich lohnt sich eine rückwirkende Prüfung, insbesondere wenn Systeme vor dem Patch öffentlich erreichbar waren und relevante Logs noch vorhanden sind.

Webserver- und PHP-Logs, Prozessaktivitäten, Dateisystemänderungen und ausgehende Netzwerkverbindungen liefern zusammen mögliche Hinweise auf einen Angriff. Keine dieser Quellen reicht für sich allein aus, um eine Kompromittierung sicher nachzuweisen oder auszuschließen. Wer verdächtige Aktivitäten findet, sollte die Hinweise sichern, zeitlich korrelieren und bei konkretem Verdacht eine strukturierte Incident-Response-Untersuchung durchführen.

QUELLEN

Weiterführende Quellen

Verdacht auf einen Angriff oder Hilfe bei der Prüfung?

Logs, Prozesse und Dateien sauber auswerten ist Aufwand. Sprechen Sie uns an, wir unterstützen bei Prüfung, Absicherung und Betrieb.

Der Beitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab erschien zuerst auf RDDZ.

WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen

dennis_rddz — Mon, 19 Oct 2026 20:56:30 +0000

WG TUNNEL · ANDROID · 19.10.2026

WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen

WG Tunnel für Android hat ein weiteres Update erhalten. Mit Version 5.8.2, veröffentlicht am 19. Oktober 2026, verbessert der Open-Source-VPN-Client nicht nur die Bedienung, sondern behebt auch mehrere Fehler aus den vorherigen Versionen. Dazu kommen ein dynamisches AMOLED-Design und eine neue Möglichkeit, Server direkt vom Hauptbildschirm aus anzupingen – auch dann, wenn gerade kein VPN-Tunnel aktiv ist.

WG TUNNEL 5.8.2

● Seit 19.10.2026

AMOLED

dynamisches Theme

Ping

ohne aktiven Tunnel

Fixes

TV, Split Tunneling

Neu ✓ AMOLED-Theme, Ping

Android TV ✓ Import & Backup korrigiert

Split Tunneling ✓ Speichern korrigiert

Empfehlung ✓ Update für Android-Nutzer

Update → Tunnel starten → Sonderfunktionen kurz prüfen

✓ Release: 19. Oktober 2026

✓ Dynamisches AMOLED-Theme

✓ Server-Ping ohne aktiven Tunnel

✓ Fixes für Android TV und Split Tunneling

✓ Open-Source-VPN-Client für Android

NEUERUNGEN

Was ist neu in WG Tunnel 5.8.2?

Bereits Version 5.8.0 hatte mit Multihop-Tunneln und Tunnel-Gruppen größere Neuerungen eingeführt. Die nachfolgenden Updates konzentrieren sich nun stärker auf Stabilität, Bedienkomfort und die Korrektur konkreter Probleme.

🌙

Dynamisches AMOLED-Design

Wer auf dem Smartphone ein dunkles Erscheinungsbild bevorzugt, bekommt mit 5.8.2 eine weitere Option: ein dynamisches AMOLED-Theme. Gerade auf Geräten mit OLED-Display kann eine konsequent dunkle Darstellung angenehm sein und den Energieverbrauch reduzieren, abhängig von Display und Nutzung.

Das neue Theme ist eine Ergänzung zu den vorhandenen Darstellungsmöglichkeiten und gehört zu den sichtbaren Neuerungen dieser Version.

📡

Server direkt vom Hauptbildschirm anpingen

Eine praktische Verbesserung für die Fehlersuche: WG Tunnel kann Server jetzt direkt vom Hauptbildschirm aus anpingen, selbst wenn kein Tunnel aktiv ist.

Das erleichtert die erste Diagnose bei Verbindungsproblemen. So lässt sich beispielsweise prüfen, ob ein Ziel grundsätzlich erreichbar ist, bevor man sich mit der VPN-Konfiguration beschäftigt. Ein erfolgreicher Ping beweist allerdings nicht automatisch, dass auch der WireGuard-Handshake oder der gesamte Tunnel funktioniert.

📺

Verbesserungen für Android TV

Auch Nutzer von Android TV profitieren vom Update. Die Entwickler haben Fehler beim Importieren von Konfigurationen korrigiert. Außerdem wurden Probleme rund um Backup und Wiederherstellung behoben und die Unterstützung für Android TV dabei verbessert.

Das ist insbesondere dann hilfreich, wenn Tunnel-Konfigurationen auf einem Fernseher oder einer TV-Box eingerichtet, gesichert oder auf ein anderes Gerät übertragen werden sollen.

🔀

Korrekturen bei Split Tunneling

Version 5.8.2 behebt außerdem Probleme mit veralteten beziehungsweise nicht korrekt gespeicherten Änderungen an der Split-Tunnel-Konfiguration. Die Bedienung wurde in diesem Bereich ebenfalls verbessert.

Beim Split Tunneling wird festgelegt, welche Apps oder Verbindungen den VPN-Tunnel verwenden und welche davon ausgenommen sind. Gerade bei solchen Einstellungen ist es wichtig, dass Änderungen zuverlässig gespeichert werden und anschließend tatsächlich der gewünschten Konfiguration entsprechen.

SEIT VERSION 5.8.0

Was wurde seit Version 5.8.0 korrigiert?

Nicht alle Änderungen stecken direkt in 5.8.2. Bereits die Zwischenversion 5.8.1 brachte eine wichtige Fehlerkorrektur mit.

WG Tunnel 5.8.1: SOCKS5-Proxy und Lockdown-DNS

In Version 5.8.0 waren Fehler bei der DNS-Auflösung im Zusammenhang mit dem SOCKS5-Proxy und dem Lockdown-Modus eingeführt worden. Version 5.8.1 korrigierte diese Probleme. Wer diese Funktionen nutzt, sollte deshalb mindestens eine korrigierte Version verwenden. Die aktuelle Version 5.8.2 enthält diese Korrektur ebenfalls.

Rückblick: Die größeren Neuerungen aus 5.8.0

Mit Version 5.8.0 kamen unter anderem folgende Funktionen hinzu:

Multihop-Tunnel

VPN-Verbindungen lassen sich hintereinander schalten.

Tunnel-Gruppen

Mehrere Tunnel können übersichtlicher organisiert und verwaltet werden.

IPv6- und Proxy-Korrekturen

Fehler beim lokalen Proxy und bei IPv6-bezogenen Einstellungen wurden behoben.

Auto-Tunnel

Verbesserungen bei der Netzwerkerkennung, bei Android Auto und bei gerätespezifischen Besonderheiten.

Bedienung

Überarbeitungen an Split-Tunnel- und DNS-Einstellungen.

Wer bereits Version 5.8.0 nutzt, erhält mit 5.8.2 also nicht nur neue Komfortfunktionen, sondern auch die nachfolgenden Fehlerkorrekturen.

EMPFEHLUNG

Sollte man auf WG Tunnel 5.8.2 aktualisieren?

Ja, das Update ist für bestehende Android-Nutzer empfehlenswert. Besonders interessant ist es für alle, die den SOCKS5-Proxy, den Lockdown-Modus, Split Tunneling oder Android TV verwenden.

Auch wer WG Tunnel nur mit einer einzelnen WireGuard-Verbindung nutzt, profitiert von den allgemeinen Verbesserungen und Fehlerkorrekturen. Die neuen Funktionen für AMOLED-Darstellung und Ping-Tests sind zusätzliche Vorteile, aber nicht für jeden Einsatzzweck zwingend erforderlich.

Nach einem Update lohnt es sich, kurz zu prüfen, ob die eigenen Tunnel wie erwartet starten und ob besondere Einstellungen – etwa Split Tunneling, DNS oder Proxy – weiterhin korrekt funktionieren.

DOWNLOAD

Wo gibt es WG Tunnel 5.8.2?

Die Android-Version ist über verschiedene Bezugsquellen verfügbar. Welche Version bereits angeboten wird, kann je nach Store und Veröffentlichungszeitpunkt variieren.

📦

GitHub

Die offiziellen Releases und die APK-Dateien direkt aus dem Projekt.

📱

IzzyOnDroid

Ein alternativer Store für freie Android-Apps.

▶

Google Play

Verfügbarkeit und Aktualisierungsstand bitte direkt im Store prüfen.

Wer die APK direkt herunterlädt, sollte darauf achten, dass sie aus dem offiziellen Projekt stammt. Für Version 5.8.2 nennt der Entwickler folgenden SHA-256-Fingerabdruck des Signaturzertifikats:

SHA-256 (Signaturzertifikat)

5204d82e766e8aa14dcbb06dc70aebae2bdd812d4d6203cd521a8a685d7d3d80

Die Signatur lässt sich nach dem Download beispielsweise mit apksigner prüfen:

Bash

apksigner verify --print-certs [Pfad zur APK] | grep SHA-256

Der ausgegebene Fingerabdruck muss mit dem vom Projekt veröffentlichten Wert übereinstimmen.

ANDROID & DESKTOP

Android und Desktop künftig getrennt betrachten

WG Tunnel ist inzwischen nicht mehr nur ein Android-Projekt. Mit dem Desktop-Client gibt es auch Varianten für Windows, Linux und macOS. Die Desktop-Version besitzt eigene Releases und plattformspezifische Installationswege.

Deshalb werden wir die beiden Varianten künftig getrennt behandeln: Dieser Beitrag konzentriert sich auf WG Tunnel für Android. Ein eigener Artikel für WG Tunnel Desktop kann dann die jeweiligen Neuerungen, Installationswege und Besonderheiten unter Windows, Linux und macOS behandeln.

QUELLEN

Quellen und Links

VPN, Netzwerk oder Fernzugriff einrichten?

Von WireGuard-Anbindungen bis zur Netzwerkplanung: Sprechen Sie uns an, wir unterstützen bei Konzept, Einrichtung und Betrieb.

Der Beitrag WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen erschien zuerst auf RDDZ.

UniFi Network 11: Alle Neuerungen und wichtige Upgrade-Hinweise

dennis_rddz — Tue, 13 Oct 2026 16:04:38 +0000

RDDZ NEWS · UBIQUITI · NETZWERK

UniFi Network 11: Alle Neuerungen und wichtige Upgrade-Hinweise

Mit UniFi Network Application 11.0.83 veröffentlicht Ubiquiti einen umfangreichen Versionssprung: neue Oberfläche, aber auch eine veränderte technische Grundlage. PostgreSQL-Datenbank, Live Flows, externe Network Lists, WLAN als Backup-Internetzugang und Matter-Thread-Monitoring gehören zu den größten Neuerungen – dazu kommen wichtige Einschränkungen, die vor einem Upgrade bekannt sein sollten.

UNIFI NETWORK 11 · EINGEORDNET VON RDDZ

● Release Candidate – noch keine stabile Version

PostgreSQL

Neue Datenbank-Grundlage

Live Flows

Verbindungen live kontrollieren

Zone-Based FW

Automatische Migration aller Sites

Statistik-HistorieGeht beim Update verloren

USG-GatewaysNicht mehr unterstützt

FirewallAutomatische Umstellung

Stand: Release Candidate 11.0.83, Oktober 2026.

✓ Neue Datenbank-Grundlage mit PostgreSQL und skalierbarer Statistik-Engine

✓ Live Flows: aktive Verbindungen direkt am Gateway anzeigen und beenden

✓ Externe Network Lists und WLAN als Backup für den Internetzugang

✓ Matter-Thread-Monitoring für Smart-Home-Geräte im Netzwerk

✓ USG-Support und klassischer Network Application Server entfallen

TECHNISCHE GRUNDLAGE

PostgreSQL und neue Statistik-Engine: der Unterbau wird ausgetauscht

Eine der größten Änderungen betrifft nicht eine sichtbare Funktion, sondern die interne Architektur von UniFi Network.

🗃

Datenbank wird auf PostgreSQL umgestellt

Die bisherige Anwendungsdatenbank wird durch PostgreSQL abgelöst – eine deutlich belastbarere Grundlage für größere Installationen.

📊

Skalierbarere Statistik-Engine

Ubiquiti führt parallel eine neue Engine für die Verarbeitung von Statistiken ein, inklusive Fehlerkorrekturen bei Installationen mit vielen Sites.

⚙

Mehr Stabilität im Hintergrund

Der neue Unterbau soll die Anwendung insgesamt stabiler machen – gerade bei Umgebungen mit vielen verwalteten Standorten.

⚠

Wichtig: Statistik-Historie geht verloren

Beim Update wird die vorhandene Statistik-Historie gelöscht, die Anwendung beginnt danach mit dem Aufbau neuer Daten. Wer langfristige Auswertungen oder historische Netzwerkdaten für Vergleiche braucht, sollte diesen Verlust vor der Migration einplanen.

Unsere Einordnung

Ein Datenbankwechsel dieser Größenordnung ist kein kosmetisches Update. Wer auf historische Statistiken angewiesen ist, sollte vorab einen eigenen Export oder Screenshot der relevanten Zeiträume anlegen.

NEUE FUNKTIONEN

Mehr Kontrolle im Netzwerkalltag

Neben dem technischen Unterbau bringt Version 11 auch eine Reihe praktischer Funktionen für den laufenden Betrieb mit.

📡

Live Flows

Aktive Verbindungen lassen sich direkt am Gateway anzeigen und bei Bedarf gezielt beenden – praktisch bei der Fehlersuche. Voraussetzung: UniFi OS 6.0.10 oder neuer.

🔍

Externe Network Lists

Domain- und IP-Listen lassen sich aus externen Quellen importieren, statt sie nur manuell zu pflegen. Ebenfalls ab UniFi OS 6.0.10.

📶

WiFi Uplink als Backup

Unterstützte Gateways mit eigenem WLAN-Radio können sich mit einem WLAN in der Umgebung verbinden und dieses als Ausweichmöglichkeit nutzen, falls der reguläre Internetzugang ausfällt. Unterstützt werden Dream Router 7 (UDR7), Dream Router 5G Max (UDR-5G-Max), UniFi Express 7 (UX7) und Cloud Gateway Industrial (UCG-Industrial) – jeweils mit UniFi OS 6.0.10 oder neuer.

SMART HOME & CLIENTS

Matter-Thread-Monitoring und mehr Kontrolle bei Clients

Dort, wo Netzwerkverwaltung und Smart-Home-Infrastruktur zusammenkommen, erweitert UniFi Network 11 die Sichtbarkeit deutlich.

Matter-Thread-Geräte lassen sich hinsichtlich Status und Verbindung überwachen – vorausgesetzt, das UniFi OS Gateway läuft mit Version 6.0.10 oder neuer, mDNS ist aktiviert und IPv6 ist in dem Netzwerk eingeschaltet, in dem sich die Thread Border Router befinden. Da IPv6 in UniFi standardmäßig deaktiviert ist, lohnt sich gerade bei IoT-Netzen ein Blick in die Einstellungen.

UniFi beobachtet die Geräte dabei nur – eine Steuerung findet nicht statt. Parallel wird die Client-Verwaltung ausgebaut: Icons für Client-Geräte lassen sich jetzt generieren, mehrere Clients gleichzeitig bearbeiten, entfernen oder blockieren, und ein neuer Alarm informiert über Verbindungsänderungen.

Wichtig: Die Release Notes sprechen ausdrücklich vom Generieren von Client-Icons – nicht vom Hochladen eigener Bilder als Gerätebild. Beide Funktionen sollten nicht verwechselt werden.

ANALYSE & ROUTING

Topology, SD-WAN und Traffic Flows im Detail

Auch bei Netzwerkübersicht und Routing-Entscheidungen hat sich mit Version 11 einiges verändert.

🌐

Topology und Time Machine

Time Machine wurde in die Topology-Seite integriert, die Animationen des Netzwerkverkehrs verbessert und das Laden bei großen Sites optimiert. Der zuletzt genutzte Zustand (geöffnet/geschlossen) wird sich nun gemerkt.

🛡

SD-WAN: ziel- und leistungsbasiert

Neue Richtlinien ermöglichen Routing nach Hub-Auswahl, WAN-Priorität sowie Schwellenwerten für Paketverlust, Latenz und Jitter. Voraussetzung ist Site Manager 5.10.2 oder neuer.

🌎

IPIP-WAN für Japan

Zusätzlich ergänzt Ubiquiti IPIP-WAN-Unterstützung für japanische IPv4-over-IPv6-Dienste – ein eher regionales, aber nicht unerhebliches Detail.

Traffic Flows und Firewall: mehr Kontext

Erlaubte Verbindungen zeigen jetzt den Namen der zugehörigen Firewall-Policy, eine neue Anwendungsspalte samt Filter erleichtert die Zuordnung, Flows lassen sich direkt in Firewall Policies protokollieren und lokale DNS-Anfragen werden korrekt als DNS erkannt. Die neuen Firewall-Policy-Namen und der Anwendungsfilter setzen UniFi OS 6.0.10 oder neuer voraus.

IM DETAIL

Weitere Verbesserungen im Überblick

Netzwerk, WLAN & Switching

Verbessertes Channel AI inkl. Länderauswahl, korrigierte Kanalempfehlungen für Outdoor-APs, stabilere Switch-Stacks, bessere Validierung des IGMP-Snooping, höhere VLAN-Grenze ohne adoptiertes Gateway sowie System-Logs für Subnet-Overlaps.

VPN, Routing & Firewall

Überarbeitete Bedienung bei VPN- und Routing-Einstellungen, neue Verschlüsselungsoptionen AES-192-CBC und AES-128-CBC für Site-to-Site-OpenVPN, behobene Fehler bei SD-WAN-Hub-Spoke-Tunneln nach WAN-Änderungen sowie bei der Isolation von Netzwerken gegenüber der VPN-Zone.

VOR DEM UPDATE

Was vor dem Upgrade zu beachten ist

UniFi Network 11.0.83 ist ein Release Candidate und benötigt mindestens UniFi OS 6.0. Diese Schritte sollten vorher geprüft werden:

Backup erstellen

Konfiguration sichern und prüfen, wie eine Wiederherstellung im Fehlerfall abläuft.

Hardware kontrollieren

Prüfen, ob noch USG-Gateways oder ein klassischer Network Application Server im Einsatz sind.

Statistikverlust einplanen

Wichtige historische Auswertungen vorher sichern – die Statistik-Historie wird beim Update gelöscht.

Firewall-Konfiguration prüfen

Alle Sites werden automatisch auf die Zone-Based Firewall migriert. Besonders bei Kombinationen mit Fremd-Routern oder individuellen LAN-In/LAN-Local-Regeln lohnt ein genauer Blick danach.

Voraussetzungen prüfen

UniFi OS und, für die neuen SD-WAN-Richtlinien, Site Manager müssen die geforderten Mindestversionen erfüllen.

Release-Status beachten

11.0.83 ist ein Release Candidate, kein stabiles Release. In produktiven Umgebungen sollte man damit entsprechend vorsichtig umgehen.

Genug Zeit einplanen

Das Upgrade selbst kann laut Ubiquiti bis zu 20 Minuten dauern, einzelne Geräte können danach noch etwas länger für die Neuprovisionierung brauchen.

FAZIT

UniFi Network 11 ist ein größerer Umbau

UniFi Network 11 ist deutlich mehr als ein gewöhnliches Funktionsupdate. Die Migration auf PostgreSQL, die neue Statistik-Engine, Live Flows, externe Network Lists und WiFi Uplink erweitern die Plattform technisch wie funktional. Auch SD-WAN, die Analyse von Traffic Flows, die Topology-Ansicht und die Verwaltung von Clients werden weiterentwickelt.

Gleichzeitig bringt die Version wichtige Einschränkungen mit: Die Statistik-Historie geht verloren, USG-Gateways werden nicht mehr unterstützt und selbst gehostete Installationen sollen auf UniFi OS Server umgestellt werden. Die automatische Migration auf die Zone-Based Firewall verdient dabei besondere Aufmerksamkeit.

Unsere Empfehlung: Hardware, bestehende Firewall-Regeln und benötigte Statistiken vor dem Upgrade prüfen. Da 11.0.83 aktuell als Release Candidate geführt wird, sollte die Version in produktiven Umgebungen nicht unüberlegt installiert werden.

FAQ

Häufige Fragen zu UniFi Network 11

Ist UniFi Network 11.0.83 schon stabil?

Nein. Ubiquiti führt die Version aktuell als Release Candidate, also als Vorabversion. Das Update wird schrittweise verteilt und ist deshalb möglicherweise nicht bei jeder Installation sofort verfügbar. Für produktive Umgebungen empfiehlt sich ein vorsichtiger Umgang.

Was passiert mit meinen bisherigen Statistiken?

Die vorhandene Statistik-Historie wird beim Update gelöscht, da die Datenbank auf PostgreSQL migriert und die Statistik-Engine ausgetauscht wird. Danach beginnt die Anwendung mit dem Aufbau neuer Daten.

Kann ich mit einer USG-Gateway auf Version 11 updaten?

Nein. Die Unterstützung für USG-Gateways wurde entfernt. Laut Ubiquiti ist Network 10.6 die letzte Version, die USG unterstützt – wer noch USG-Hardware betreibt, sollte vor einem Update die weitere Planung klären.

Welche Gateways unterstützen WiFi Uplink?

Aktuell Dream Router 7 (UDR7), Dream Router 5G Max (UDR-5G-Max), UniFi Express 7 (UX7) und Cloud Gateway Industrial (UCG-Industrial) – jeweils mit UniFi OS 6.0.10 oder neuer. Gateways ohne eigenes WLAN-Radio unterstützen die Funktion nicht.

Was ändert sich bei selbst gehosteten Installationen?

Der bisherige Network Application Server wird nicht mehr unterstützt. Ubiquiti empfiehlt für Self-Hosting den Wechsel auf UniFi OS Server, für alle anderen Installationen weiterhin ein UniFi Cloud Gateway.

QUELLEN

Quellen und Links

UniFi-Netzwerk sicher auf Version 11 bringen?

Ob Bestandsaufnahme der Hardware, Prüfung der Firewall-Konfiguration oder begleitetes Update: RDDZ unterstützt dich dabei, UniFi Network 11 kontrolliert einzuführen – statt Überraschungen im produktiven Betrieb zu riskieren.

Der Beitrag UniFi Network 11: Alle Neuerungen und wichtige Upgrade-Hinweise erschien zuerst auf RDDZ.

Welches CMS ist das richtige? Worauf es bei der Auswahl wirklich ankommt

dennis_rddz — Tue, 13 Oct 2026 06:20:53 +0000

RDDZ RATGEBER · CMS · WEBDESIGN

Welches CMS ist das richtige? Worauf es bei der Auswahl wirklich ankommt

WordPress, Joomla, individuelle Lösungen oder ein Shop-System – die Auswahl ist groß, und auf den ersten Blick scheint die Entscheidung einfach: Funktionen vergleichen, ein paar Demos ansehen, zuschlagen. In der Praxis zeigt sich schnell, dass es auf mehr ankommt als auf die längste Featureliste.

CMS-AUSWAHL · VON RDDZ

● Aus eigener Projekterfahrung

WordPress

Unser Hauptsystem bei RDDZ

Joomla → WP

Mehrfach erfolgreich migriert

Woo & Magento

Beide Shop-Systeme im Einsatz

FunktionenNur was wirklich gebraucht wird

BedienungWer pflegt die Website später?

BetriebKosten, Wartung, Sicherheit

Aus unserer Erfahrung mit Unternehmenswebsites und Online-Shops.

✓ Funktionsumfang an echten Anforderungen statt an Feature-Listen ausgerichtet

✓ Bedienbarkeit im Redaktionsalltag selbst getestet, nicht nur in der Demo

✓ Shop-Anforderungen mit WooCommerce und Magento abgedeckt

✓ Gesamtkosten über mehrere Jahre statt nur Einstiegspreis betrachtet

✓ Wartung, Updates und Sicherheit von Anfang an mitgeplant

FUNKTIONSUMFANG

Welche Funktionen werden tatsächlich gebraucht?

Mehrsprachigkeit, Benutzerrechte, Formulare, Schnittstellen – viele CMS werben mit einer langen Liste an Möglichkeiten. Die wichtigere Frage lautet: Was davon braucht die Website wirklich?

📋

Anforderungen zuerst festhalten

Für eine klassische Unternehmenswebsite mit Leistungsseiten, Kontaktformular und Newsbereich reicht oft ein überschaubarer Funktionsumfang.

🧩

Nicht jede Funktion per Plugin lösen

Auch bei WordPress gilt: Jede zusätzliche Erweiterung muss zum Projekt passen und lässt sich auf Dauer nicht von allein pflegen.

📋

Redaktionsportale brauchen mehr

Ein großes Portal mit vielen Autoren, Freigaben und komplexen Inhaltsstrukturen stellt ganz andere Anforderungen als eine Unternehmensseite.

🔄

Muss das bestehende CMS ersetzt werden?

Nicht immer. Manchmal reicht eine Überarbeitung der bestehenden Installation. Entscheidend ist, was konkret stört: die Pflege, fehlende Funktionen, die technische Basis – oder soll die Seite ohnehin neu gestaltet werden?

Ein Beispiel aus unserer Praxis

Ein gemeinnütziger Verein kam mit einer in die Jahre gekommenen Joomla-Seite zu uns, die sich kaum noch pflegen ließ. Im Rahmen eines großen Redesigns haben wir ein komplett neues WordPress-Setup realisiert, Inhalte sauber übernommen und die Redaktion danach selbstständig arbeiten lassen können.

ALLTAGSTAUGLICHKEIT

Wer soll später mit der Website arbeiten?

Die Bedienbarkeit wird bei der CMS-Auswahl häufig unterschätzt, entscheidet im Alltag aber darüber, ob Inhalte schnell aktualisiert werden oder jede kleine Änderung Zeit kostet.

✏

Ohne Fachkraft pflegbar

Neue Leistungen, geänderte Kontaktdaten oder aktuelle Meldungen sollten sich unkompliziert einpflegen lassen.

🏗

Aufbau entscheidet mit

Ein System kann grundsätzlich einfach sein und trotzdem kompliziert wirken, wenn der Seitenaufbau unübersichtlich ist oder zu viele Werkzeuge im Einsatz sind.

✅

Typische Aufgaben vorher testen

Einen Beitrag veröffentlichen, ein Bild austauschen, eine Leistungsseite aktualisieren: Klappt das reibungslos, ist das ein gutes Zeichen.

PRAXISBEISPIEL

Vom alten Joomla-Auftritt zum neuen WordPress-Setup

Ein gemeinnütziger Verein, dessen Website seit Jahren auf einer veralteten Joomla-Installation lief, ist ein gutes Beispiel dafür, wann ein Wechsel wirklich sinnvoll ist.

Die alte Seite war technisch veraltet, die Redaktion kam mit dem Backend kaum noch zurecht, und kleine Änderungen landeten regelmäßig bei uns, statt dass der Verein sie selbst hätte erledigen können.

Im Rahmen eines größeren Redesigns haben wir die Seite komplett neu auf WordPress aufgebaut: bestehende Inhalte übernommen, Struktur und Bedienung an den Alltag des Vereins angepasst und ein System übergeben, das die Redaktion seither eigenständig pflegt.

Der Fall zeigt gut, worauf es bei einer Migration ankommt: nicht der reine Systemwechsel steht im Vordergrund, sondern dass die neue Website hinterher leichter zu pflegen ist als die alte.

GESAMTKOSTEN

Was kostet das CMS wirklich?

Ein kostenloses CMS ist nicht automatisch die günstigste Lösung. Der Lizenzpreis ist nur ein Teil der Rechnung.

💵

WordPress ist Open Source

Trotzdem entstehen Kosten, etwa für Premium-Plugins, individuelle Entwicklung, technische Betreuung oder Sicherheitsmaßnahmen.

🛒

Bei Shops kommt mehr hinzu

Zahlungs- und Versandlösungen, Schnittstellen oder spezielle Shop-Funktionen schlagen je nach System unterschiedlich zu Buche.

🔍

Der Pflegeaufwand zählt mit

Eine günstig wirkende Lösung kann teuer werden, wenn Anpassungen kompliziert sind oder ständig externe Unterstützung nötig ist.

Erweiterungen mit Bedacht wählen

Plugins sparen Zeit, solange sie sorgfältig ausgewählt werden. Zu viele Erweiterungen machen eine Website unnötig komplex, müssen aktuell gehalten werden und zueinander passen. Wird eine wichtige Erweiterung nicht mehr gepflegt, entsteht schnell zusätzlicher Aufwand.

ONLINE-SHOPS

Bei Shops gelten andere Anforderungen

WooCommerce für integrierte Inhalte

Baut auf WordPress auf und eignet sich besonders, wenn neben dem Verkauf auch Ratgeber oder andere redaktionelle Inhalte eine Rolle spielen.

Magento für umfangreichere Shops

Kommt bei uns ins Spiel, wenn Sortiment, Geschäftsprozesse und Schnittstellen entsprechend umfangreich sind.

SICHERHEIT & WARTUNG

Mit der Veröffentlichung fängt die Arbeit erst an

CMS, Plugins und andere Komponenten müssen laufend aktualisiert werden. Worauf es dabei ankommt:

Updates zeitnah einspielen

Sicherheitslücken werden regelmäßig bekannt und geschlossen.

Backups prüfen, nicht nur erstellen

Eine Sicherung, die im Ernstfall nicht einspielbar ist, hilft niemandem.

Benutzerrechte sauber verwalten

Jeder Zugang nur mit den Rechten, die tatsächlich gebraucht werden.

Erweiterungen aktuell halten

Veraltete Plugins sind eine der häufigsten Einfallstore.

Zuständigkeit vorab klären

Wer kümmert sich um Updates, Monitoring und Notfälle?

Shops besonders im Blick behalten

Technische Probleme wirken sich hier direkt auf Bestellungen und Umsatz aus.

Notfallplan bereithalten

Ein nachvollziehbarer Ablauf, falls doch einmal etwas schiefgeht.

FAZIT

Das System muss zum Projekt passen

Ob WordPress, Joomla, WooCommerce oder Magento: Kein System ist automatisch für jedes Projekt die beste Wahl. Für viele Unternehmenswebsites ist WordPress eine vielseitige Grundlage, bei Online-Shops können WooCommerce oder spezialisierte Lösungen wie Magento infrage kommen.

Auch ein Wechsel von einem bestehenden CMS sollte gut überlegt sein. Er lohnt sich, wenn er konkrete Probleme löst, so wie bei dem Verein, der von Joomla auf WordPress umgezogen ist – nicht, weil ein System gerade im Trend liegt.

Unser Tipp: Anforderungen zuerst festhalten, dann die infrage kommenden Systeme daran messen. So entsteht eine Entscheidung, die zum Projekt passt, statt eine nach Bauchgefühl oder Featureliste.

FAQ

Häufige Fragen zur CMS-Auswahl

Ist WordPress für jede Website geeignet?

Für viele Unternehmenswebsites ist WordPress eine vielseitige und bewährte Grundlage. Bei sehr großen Redaktionsportalen mit komplexen Freigabeprozessen kann aber auch ein anderes System die bessere Wahl sein.

Lohnt sich ein Wechsel von Joomla zu WordPress?

Das hängt davon ab, was konkret stört. Wenn die Pflege umständlich ist, die technische Basis veraltet ist oder die Website ohnehin neu gestaltet werden soll, kann eine Migration sinnvoll sein – wie bei einem Verein, den wir so von Joomla auf WordPress umgezogen haben.

WooCommerce oder Magento: Was passt besser?

WooCommerce baut auf WordPress auf und eignet sich gut, wenn Verkauf und redaktionelle Inhalte zusammenspielen sollen. Magento kommt eher bei umfangreicheren Shops mit komplexeren Geschäftsprozessen infrage. Welches System passt, hängt vom Einzelfall ab.

Was kostet eine CMS-Website wirklich?

Neben Lizenz- oder Abonnementkosten gehören Einrichtung, Hosting, Erweiterungen, Wartung und der laufende Pflegeaufwand zur Rechnung. Ein niedriger Einstiegspreis sagt wenig über die Gesamtkosten über mehrere Jahre aus.

Wer kümmert sich nach dem Launch um Updates und Sicherheit?

Das sollte vor der CMS-Auswahl geklärt sein, nicht erst beim ersten größeren Update. RDDZ übernimmt auf Wunsch die laufende technische Betreuung, von Updates über Backups bis zur Fehlerbehebung.

QUELLEN

Quellen und Links

Neue Website oder CMS-Wechsel geplant?

Du planst eine neue Website, möchtest dein bestehendes CMS ablösen oder deinen Online-Shop weiterentwickeln? RDDZ unterstützt dich bei der Planung und Umsetzung – von der Auswahl des passenden Systems bis zur technischen Realisierung.

Der Beitrag Welches CMS ist das richtige? Worauf es bei der Auswahl wirklich ankommt erschien zuerst auf RDDZ.

WG Tunnel 5.8.0 released: Multihop, Tunnel-Gruppen und wichtige Fixes

dennis_rddz — Mon, 12 Oct 2026 06:15:10 +0000

WG Tunnel · Release · 11.10.2026

WG Tunnel 5.8.0 released: Multihop, Tunnel-Gruppen und wichtige Fixes

Erst vor wenigen Wochen ging es bei WG Tunnel 5.7.3 vor allem um Fehlerbehebungen beim Auto-Tunnel und DNS. Jetzt legt der Android-Client nach: Am 11. Oktober 2026 ist WG Tunnel 5.8.0 erschienen – diesmal mit zwei neuen Funktionen für Nutzer mit mehreren VPN-Verbindungen.

WG TUNNEL 5.8.0 · RELEASE

● Seit 11.10.2026 verfügbar

Multihop

Mehrere VPN-Verbindungen verketten

Tunnel-Gruppen

Übersichtliche Verwaltung mehrerer Tunnel

IPv6 & DNS

Weitere Fehlerbehebungen

5.7.3 (18.09.2026)Auto-Tunnel & DNS Fixes

5.8.0 (11.10.2026)Multihop & Tunnel-Gruppen

5.7.3 (18.09.2026) war vor allem Bugfixes für Auto-Tunnel und DNS.

✓ Multihop-Tunnel: VPN-Verbindungen hintereinander schalten

✓ Neue Tunnel-Gruppen zur übersichtlichen Verwaltung

✓ Fehlerbehebungen bei IPv6-Proxy und DNS-/Proxy-Betrieb

✓ Weitere Korrekturen am Auto-Tunnel (Gerätehersteller, Standortberechtigungen, Android Auto)

✓ Freier Android-Client für WireGuard und AmneziaWG

WAS IST NEU

Was steckt in WG Tunnel 5.8.0?

Mehrere VPN-Verbindungen miteinander verbinden: Die größte Neuerung ist die Unterstützung für Multihop-Tunnel. Damit lassen sich VPN-Verbindungen hintereinander schalten, der Datenverkehr läuft also über mehrere Tunnel statt nur über eine einzelne Verbindung. Das kann interessant sein, wenn man bewusst mehrere VPN-Stationen nutzen möchte. Der praktische Nutzen hängt dabei von der jeweiligen Konfiguration ab, mehrere Tunnel bedeuten nicht automatisch mehr Sicherheit oder bessere Geschwindigkeit.

Tunnel-Gruppen: Neu sind außerdem Tunnel-Gruppen. Damit lassen sich Tunnel übersichtlicher zusammenfassen und verwalten. Wer mehrere Konfigurationen für unterschiedliche Standorte oder Einsatzzwecke nutzt, bekommt damit eine bessere Ordnung in seine Verbindungsliste.

Verbesserungen bei IPv6 und DNS: Auch unter der Haube wurde gearbeitet. Die Entwickler nennen mehrere Fehlerbehebungen rund um den lokalen IPv6-Proxy sowie den DNS- und Proxy-Betrieb, dazu gehören Korrekturen an der IPv6-Bind-Adresse und am zugrunde liegenden Kern der App.

Der Auto-Tunnel wird weiter verbessert: Betroffen sind unter anderem die Netzwerkerkennung bei bestimmten Geräteherstellern, die Behandlung fehlender Standortberechtigungen und Probleme mit Android Auto. Gerade bei Android-Geräten können solche Sonderfälle im Alltag entscheidend sein: Der VPN-Tunnel soll zuverlässig auf Änderungen der Netzwerkverbindung reagieren, ohne dass man ständig selbst eingreifen muss.

Überarbeitete Einstellungen: Die Bedienung der Split-Tunnel- und DNS-Einstellungen wurde ebenfalls verbessert, dazu kommen weitere kleinere Änderungen und Fehlerkorrekturen.

EMPFEHLUNG

Soll man updaten?

Das Update ist besonders interessant, wenn Sie mehrere Tunnel verwalten oder Multihop nutzen möchten. Auch wer in den vorherigen Versionen Probleme mit dem Auto-Tunnel, IPv6 oder DNS hatte, sollte sich die neue Version ansehen. Wer WG Tunnel einfach nur mit einer einzelnen VPN-Verbindung nutzt und bisher keine Probleme hatte, bekommt ebenfalls Verbesserungen, die beiden neuen Funktionen sind für diesen Einsatz aber nicht zwingend erforderlich.

DOWNLOAD

Wo gibt es die Version?

📦

GitHub

Die APK direkt vom Entwickler. Release 5.8.0 ist dort als „Latest“ markiert: Release 5.8.0.

📱

IzzyOnDroid

Der F-Droid-kompatible Store zieht neue Releases in der Regel zeitnah nach. Ein Client wie Neo Store oder Droid-ify hält die App aktuell: WG Tunnel bei IzzyOnDroid.

▶

Google Play

Ob die neue Version dort schon angekommen ist, haben wir nicht geprüft: WG Tunnel bei Google Play.

APK-Signatur prüfen

Wer die APK direkt von GitHub lädt, sollte darauf achten, sie aus dem offiziellen Projekt zu beziehen. Laut Release Notes lautet der SHA-256-Fingerprint des Signaturzertifikats für Version 5.8.0:

5204d82e766e8aa14dcbb06dc70aebae2bdd812d4d6203cd521a8a685d7d3d80

So lässt er sich prüfen (den Pfad zur APK anpassen):

apksigner verify --print-certs [Pfad zur APK] | grep SHA-256

MEHR

Mehr zu WG Tunnel

WG Tunnel ist ein freier Android-Client für WireGuard und AmneziaWG. Neben dem Auto-Tunnel gibt es einen Lockdown-Modus als eigenen Kill-Switch und einen lokalen Proxy (SOCKS5/HTTP).

Was es bei der Vorgängerversion zu beachten gab, steht in diesem Beitrag: WG Tunnel 5.7.3: Feinschliff für Auto-Tunnel und DNS.

QUELLEN

Quellen und Links

VPN und Fernzugriff sauber aufsetzen?

Ob WireGuard, Firewall oder Fernzugriff: Nutzen Sie unsere IT-Leistungen.

Der Beitrag WG Tunnel 5.8.0 released: Multihop, Tunnel-Gruppen und wichtige Fixes erschien zuerst auf RDDZ.

Weg von der Excel-Tabelle: Netzwerk-Doku mit NetBox

dennis_rddz — Sun, 11 Oct 2026 06:50:22 +0000

RDDZ EIGENE INFRASTRUKTUR · NETZWERK-DOKUMENTATION · OPEN SOURCE

Weg von der Excel-Tabelle: Netzwerk-Doku mit NetBox

Zwei 24-Port-Patchfelder, zwei Switches, dokumentiert in LibreOffice – irgendwann wusste bei uns keiner mehr, welche Tabellenversion gerade stimmt. Statt eine eigene Lösung zu bauen, steigen wir auf NetBox um, ein etabliertes Open-Source-Tool für genau diesen Zweck.

NETZWERK-DOKU · VON RDDZ

● Umstieg auf NetBox aktuell im Aufbau

2×24

Patchfeld-Ports im Zugriff

Switches dokumentiert

Apache 2.0

Lizenz von NetBox

Schritt 1Racks & Geräte angelegt

Schritt 2Portbelegung in Übertragung

Schritt 3Verkabelung & IP-Adressen folgen

Eigene Infrastruktur, Umstieg noch nicht abgeschlossen.

✓ Offene NetBox-Instanz statt Excel- oder LibreOffice-Tabelle

✓ Racks, Verkabelung und IP-Adressen in einer durchsuchbaren Datenbank

✓ Jede Änderung protokolliert, inklusive wer und wann

✓ REST-API für Automatisierung, zum Beispiel mit Ansible

✓ Quelloffen unter Apache-2.0-Lizenz, selbst gehostet

DAS PROBLEM

Warum die Tabelle irgendwann nicht mehr reicht

Eine Tabelle für Patchfeld-Belegung funktioniert eine Weile gut. Sobald mehrere Leute draufzugreifen oder sich an der Verkabelung etwas ändert, fängt das Problem erst richtig an.

⚠

Keine Versionierung

Wer hat zuletzt geändert, und ist das wirklich die aktuelle Version? In einer Tabelle lässt sich das kaum nachvollziehen.

👥

Mehrere Hände am selben Dokument

Zwei Personen bearbeiten gleichzeitig, und eine Änderung überschreibt die andere, ohne dass es jemand merkt.

📱

Schlecht mobil nutzbar

48 Zeilen auf dem Handy im Serverraum durchscrollen, um einen freien Port zu finden, ist kein Vergnügen.

🔌

Schnell veraltet

Wird kurzfristig umgesteckt und die Tabelle „später“ aktualisiert, ist die Doku von diesem Moment an falsch.

Was am Ende dabei herauskommt

Eine Doku, der niemand mehr ganz traut – und die im Zweifel vor Ort nachgeprüft wird, statt sich auf sie zu verlassen. Genau das will man bei einem Patchfeld nicht.

DIE LÖSUNG

NetBox statt Tabelle

NetBox ist ein Open-Source-Tool für Netzwerk- und Rechenzentrums-Infrastruktur (DCIM) zusammen mit IP-Adressverwaltung (IPAM). Racks, Geräte, Kabel, Ports, VLANs und IP-Adressen liegen dort in einer zusammenhängenden Datenbank statt in einzelnen Tabellenblättern.

🔗

Ein zusammenhängendes Datenmodell

Vom Rack zum Gerät zum Port navigieren und sofort sehen, welches Kabel wohin führt – ohne die passende Zeile in einer Tabelle zu suchen.

📋

Protokollierte Änderungen

Jede Erstellung, Änderung und Löschung wird mit Nutzer und Zeitstempel festgehalten, zusammengefasst nach Vorgang.

⚙

REST-API

Daten automatisiert abfragen oder in andere Systeme einspeisen, etwa in Ansible-Playbooks oder eigene Skripte.

FUNKTIONEN IM DETAIL

Was NetBox mitbringt

Das Datenmodell steht direkt nach der Installation, ganz ohne eigenes Datenbank-Setup.

Die wichtigsten Bausteine im Überblick:

Zusätzliche Funktionen lassen sich über Plugins nachrüsten, etwa für DNS-Zonen oder BGP-Daten:

DCIM           Racks, Geräte, Cable-Tracing
IPAM           Prefixe, IP-Adressen, VLANs, VRFs
Vorlagen       Jinja2-Konfigurationsvorlagen per API
Erweiterbar    Custom Fields, Tags, Plugins (DNS, BGP, Branching)
Rechte         Rollen pro Nutzer, Gruppe oder Tenant
Change-Log     jede Änderung inkl. Nutzer und Zeitstempel

Lizenz und Betrieb:

Lizenz         Apache License 2.0, Quellcode frei einsehbar
Betrieb        selbst gehostet, keine Pflicht zu Cloud-Angeboten
Optional       NetBox Cloud / NetBox Enterprise (kommerziell)

EIGENE ERFAHRUNG

Der Zwischenstopp, den wir selbst gegangen sind

Bevor wir auf NetBox gestoßen sind, hatten wir überlegt, so etwas selbst zu bauen.

📱

RackPlaner: unser eigener Versuch

Eine native Android-App in Kotlin, Projektname RackPlaner, gebaut auf unserer eigenen Entwicklerinstanz.

📋

Was die App können sollte

Racks und Patchfelder dokumentieren, VLANs mit eigenen Farben verwalten, Suche über mehrere Racks hinweg.

⏳

Warum wir sie zurückgestellt haben

Alles, was wir uns vorgenommen hatten, gibt es in NetBox bereits fertig und seit Jahren von einer aktiven Community weiterentwickelt.

Nicht jedes Problem braucht eine Eigenentwicklung

Das RackPlaner-Projekt existiert weiterhin als Codebasis, wird aber aktuell nicht weiterverfolgt. Eine eigene App hätte an diesem Punkt nur nachgebaut, was es längst gibt – mit weniger Funktionen und ohne eine Community dahinter.

AKTUELLER STAND

Wo wir gerade stehen

Racks und Geräte angelegt

Für unsere eigene Infrastruktur – zwei 24-Port-Patchfelder und zwei Switches – steht die NetBox-Instanz, Racks und Geräte sind bereits erfasst.

Portbelegung in Übertragung

Die Patchfeld-Belegung wird gerade Port für Port aus der alten Tabelle übertragen. Schon jetzt lässt sich ein einzelner Port in Sekunden finden, statt eine Tabelle durchzuscrollen.

FAHRPLAN

Vom ersten Rack zur vollständigen Doku

So gehen wir den Umstieg Schritt für Schritt an.

NetBox-Instanz aufsetzen

Selbst gehostet, ohne zusätzliches Datenbank-Setup.

Standorte und Racks anlegen

Die physische Struktur im System nachbilden.

Geräte und Switches erfassen

Jedes Gerät im passenden Rack mit Modell und Rolle hinterlegen.

Patchfeld-Portbelegung übertragen

Jeden Port aus der alten Tabelle einzeln eintragen.

Kabelverbindungen verknüpfen

Cables zwischen Patchfeld- und Switch-Ports anlegen, inklusive Cable-Tracing.

IP-Adressen und VLANs eintragen

Prefixe und VLANs im IPAM-Teil hinterlegen.

Zugriffsrechte einrichten

Rollen vergeben, damit nicht jeder an der Verkabelung selbst etwas ändern kann.

FAZIT

Nicht jedes Werkzeug muss selbst gebaut werden

Wer Netzwerkinfrastruktur betreut, kommt an Kabeln, Switches und IP-Adressen nicht vorbei – ein eigenes Werkzeug dafür muss es aber nicht sein. NetBox deckt das meiste davon bereits ab, kostenlos und offen.

Bei uns ist der Umstieg noch nicht abgeschlossen. Sobald die Patchfeld-Doku komplett in NetBox liegt, berichten wir hier, wie es gelaufen ist.

Hinweis: Dieser Beitrag beschreibt unsere eigene Infrastruktur, nicht ein abgeschlossenes Kundenprojekt. Details zu Ihrer eigenen Umgebung sollten Sie vorher prüfen.

FAQ

Häufige Fragen zu NetBox

Was ist NetBox eigentlich?

NetBox ist ein Open-Source-Tool für Netzwerk- und Rechenzentrums-Infrastruktur (DCIM) zusammen mit IP-Adressverwaltung (IPAM). Es bildet Racks, Geräte, Kabelverbindungen, Ports, VLANs und IP-Adressen in einer zusammenhängenden Datenbank ab.

Ist NetBox kostenlos?

Ja, NetBox selbst steht unter der Apache-2.0-Lizenz und lässt sich kostenlos selbst hosten. NetBox Cloud und NetBox Enterprise sind zusätzliche kommerzielle Angebote des Herstellers NetBox Labs, aber keine Voraussetzung.

Ersetzt NetBox eine normale Tabelle komplett?

Für Netzwerk-Infrastruktur wie Racks, Patchfelder, Switches und IP-Adressen: ja. NetBox bildet genau diese Daten strukturiert ab, inklusive Suche, Historie und API – Dinge, die eine Tabelle nicht bietet.

Braucht man Programmierkenntnisse, um NetBox zu nutzen?

Für die normale Nutzung über die Weboberfläche nicht. Erst wer die REST-API für Automatisierung nutzen oder eigene Plugins schreiben möchte, braucht entsprechende Kenntnisse.

Was ist aus der eigenen App RackPlaner geworden?

Das Projekt existiert als Codebasis, wird aktuell aber nicht weiterverfolgt. Der Grund: NetBox deckt die geplanten Funktionen bereits ab, gepflegt von einer aktiven Community statt einem Einzelprojekt.

Für wen lohnt sich NetBox?

Für alle, die Netzwerk-Infrastruktur dauerhaft und nachvollziehbar dokumentieren möchten – vom Homelab mit ein paar Racks bis zu IT-Dienstleistern, die das für mehrere Kunden gleichzeitig pflegen.

QUELLEN

Quellen und Links

GitHub-Repository: netbox-community/netbox (README, Datenmodell, Lizenz)
NetBox Labs – Hersteller und Hauptentwickler von NetBox

Netzwerk-Infrastruktur dokumentieren oder NetBox einführen?

Ob Umstieg von einer bestehenden Tabelle, Ersteinrichtung oder laufende Betreuung Ihrer Netzwerk-Dokumentation – sprechen Sie uns an.

Der Beitrag Weg von der Excel-Tabelle: Netzwerk-Doku mit NetBox erschien zuerst auf RDDZ.

US CLOUD Act: Warum „Daten liegen in Deutschland“ nicht die ganze Wahrheit ist

dennis_rddz — Fri, 25 Sep 2026 14:51:12 +0000

Datenschutz · US CLOUD Act · Compliance

US CLOUD Act: Warum „Daten liegen in Deutschland" nicht die ganze Wahrheit ist

Ein Microsoft-365-Tenant kann seine Daten in deutschen Rechenzentren speichern und trotzdem mit einem Anbieter betrieben werden, der US-Recht unterliegt. Im Juni 2025 musste ein Microsoft-Manager vor dem französischen Senat unter Eid einräumen, dass er das nicht ausschließen kann. Wir ordnen ein, was der CLOUD Act tatsächlich regelt, was er nicht regelt, und warum der Speicherort allein die Frage nicht beantwortet.

US CLOUD ACT

● Seit 2018 in Kraft

Speicherort

nicht entscheidend

DE-Abkommen

existiert nicht

DPF

kein CLOUD-Act-Schutz

CLOUD-Act-Abkommen mit DE/EU ✓ existiert nicht

Nur UK und Australien ✓ haben ein Abkommen

Microsoft 365 ✓ laut HBDI konform nutzbar möglich

Selbst-Hosting ✓ reduziert Risiko, kein Freifahrtschein

Serverstandort → US-Jurisdiktion → CLOUD Act → DSGVO/DPF

✓ Microsoft: keine Garantie möglich

✓ § 2713: Speicherort nicht entscheidend

✓ Kein CLOUD-Act-Abkommen mit DE/EU

✓ HBDI: M365 konform nutzbar möglich

✓ DPF ist kein CLOUD-Act-Schutz

EIN SATZ VOR DEM SENAT

Was der CLOUD Act tatsächlich regelt

Am 10. Juni 2025 wurde Anton Carniaux, Director of Public and Legal Affairs bei Microsoft France, vor einer Untersuchungskommission des französischen Senats vereidigt. Die Frage: Kann Microsoft garantieren, dass Daten französischer Bürger niemals aufgrund einer US-Anordnung ohne Zustimmung französischer Behörden herausgegeben werden?

„Non, je ne peux pas le garantir."

Carniaux antwortete mit diesem Satz und ergänzte direkt, ein solcher Fall sei bei europäischen Kunden bislang nicht vorgekommen. Das bedeutet nicht, dass Microsoft europäische Daten an die USA weitergibt, das lässt sich aus dieser Aussage nicht ableiten. Es bedeutet: Microsoft kann nicht garantieren, dass eine rechtmäßige US-Anordnung unter allen Umständen ausgeschlossen werden kann. Genau darum geht es beim CLOUD Act.

Der Clarifying Lawful Overseas Use of Data Act, kurz CLOUD Act, stammt aus 2018. Sein Hintergrund war ein Rechtsstreit zwischen Microsoft und US-Behörden um E-Mails eines Kontos, die auf einem Server in Dublin lagen. Microsoft argumentierte, eine US-Anordnung könne nicht auf außerhalb der USA gespeicherte Daten angewendet werden. Der Fall erreichte den US Supreme Court, noch bevor dieser entscheiden konnte, verabschiedete der Kongress den CLOUD Act, und der Supreme Court erklärte den Rechtsstreit für erledigt.

Der entscheidende Punkt steht heute in 18 U.S.C. § 2713: Ein erfasster Anbieter muss Daten herausgeben, die sich in seiner possession, custody or control befinden, unabhängig davon, ob sie innerhalb oder außerhalb der USA gespeichert sind. Der physische Standort des Servers ist damit nicht automatisch entscheidend.

KEIN AUTOMATISCHER SCHUTZ

Deutschland als Speicherort ist kein Freibrief

Ein einfacher Fall: Ein deutsches Unternehmen nutzt Microsoft 365, Exchange-Postfächer und OneDrive-Daten liegen in einem deutschen Rechenzentrum, SharePoint läuft in einer europäischen Region. Technisch liegen die Daten damit in Europa.

Die entscheidende zusätzliche Frage lautet aber: Wer kontrolliert diese Daten, und welchem Recht unterliegt der Anbieter? Bei einem Anbieter, der dem relevanten US-Rechtsrahmen unterliegt, kann eine US-rechtliche Herausgabeanordnung grundsätzlich auch außerhalb der USA gespeicherte Daten betreffen, sofern die gesetzlichen Voraussetzungen erfüllt sind. § 2713 stellt gerade nicht auf den physischen Speicherort ab.

Das bedeutet nicht, dass jede US-Tochter oder jede europäische Gesellschaft eines US-Konzerns automatisch jeder US-Anordnung folgen muss. Die konkrete US-Gerichtsbarkeit und die tatsächliche Kontrolle über die Daten spielen eine Rolle. Das vom Bundesinnenministerium beauftragte Rechtsgutachten der Universität zu Köln beschäftigt sich ausführlich mit genau diesen Fragen.

Wichtig ist auch, was der CLOUD Act nicht bedeutet: Ein häufiger Irrtum ist, ihn als eine Art dauerhaften Direktzugriff der US-Behörden auf europäische Microsoft-Server zu verstehen. Das besagt das Gesetz nicht. Es schafft gesetzliche Möglichkeiten, von bestimmten Anbietern im Einzelfall die Herausgabe von Daten zu verlangen. Welche rechtliche Maßnahme dafür erforderlich ist, hängt unter anderem von der Art der Daten und der jeweiligen Rechtsgrundlage ab.

DIE WICHTIGSTE EINORDNUNG

§ 2703(h): Ein spezieller Schutzmechanismus – aber nicht für Deutschland

Für bestimmte Herausgabeanordnungen betreffend Kommunikationsinhalte enthält § 2703(h) einen besonderen Mechanismus für Konflikte mit dem Recht bestimmter ausländischer Staaten. Danach kann ein Anbieter beantragen, eine Anordnung zu ändern oder aufzuheben, wenn die Herausgabe gegen das Recht einer „qualifying foreign government“ verstoßen würde.

Die entscheidende Einschränkung

Als „qualifying foreign government“ gilt nach § 2703(h) nur ein Staat, mit dem die USA ein Executive Agreement nach § 2523 abgeschlossen haben und dessen Rechtsordnung weitere gesetzliche Voraussetzungen erfüllt. Aktuell nennt das US-Justizministerium zwei solche CLOUD-Act-Abkommen: mit dem Vereinigten Königreich (unterzeichnet 2019) und mit Australien (unterzeichnet 2021, in Kraft seit 2024).

Ein entsprechendes Abkommen mit Deutschland oder einem EU-Mitgliedstaat besteht derzeit nicht. Die EU und die USA verhandeln zwar seit Jahren über grenzüberschreitenden Zugang zu elektronischen Beweismitteln, das ist aber nicht dasselbe wie ein in Kraft befindliches CLOUD-Act-Executive-Agreement.

Für deutsche Unternehmen bedeutet das: Der spezielle gesetzliche Konfliktmechanismus nach § 2703(h) steht ihnen mangels eines entsprechenden Abkommens derzeit nicht zur Verfügung. Das bedeutet nicht, dass ein Anbieter keinerlei andere rechtliche Einwendungen gegen eine US-Anordnung haben kann, das Kölner Gutachten bewertet die Rechtsschutzmöglichkeiten europäischer Unternehmen insgesamt aber als eingeschränkt.

Das ist kein theoretisches Detail: Der CLOUD Act sieht diesen Mechanismus zwar vor, Deutschland gehört aber derzeit nicht zu den Staaten mit einem entsprechenden Abkommen.

ZWEI WEITERE BAUSTEINE

Benachrichtigung und das Kölner Gutachten

Muss der Kunde von einem Zugriff erfahren?

Es stimmt nicht, dass US-Recht grundsätzlich jede Information verbietet. Es gibt aber Möglichkeiten, eine Benachrichtigung zu verzögern oder einem Anbieter zu untersagen, andere Personen zu informieren, § 2705 regelt entsprechende Verfahren. Für einen Kunden bedeutet das: Eine Benachrichtigung kann eingeschränkt oder verzögert sein, das ist etwas anderes als die pauschale Aussage „der Kunde erfährt nie etwas“.

Das Kölner Gutachten: Serverstandort ist nur ein Teil der Betrachtung

Das Rechtsgutachten der Universität zu Köln, im Auftrag des damaligen Bundesministeriums des Innern und für Heimat, wurde am 21. März 2025 vorgelegt und untersucht die US-Rechtslage zum weltweiten Datenzugriff bei Cloud-Diensten. Die Kurzfassung: US-Sicherheitsbehörden verfügen über weitreichende Herausgabe- und Zugriffsrechte, das betrifft nicht nur Daten auf US-Servern, unter bestimmten Voraussetzungen auch ausländische Server und Cloud-Anbieter, nicht immer ist dafür ein klassischer gerichtlicher Durchsuchungsbeschluss erforderlich.

Gleichzeitig ist das Gutachten keine Aussage darüber, dass jede solche Herausgabe nach deutschem oder europäischem Recht zulässig wäre. US-Recht und EU-Recht stehen nicht in einer Hierarchie: Ein US-Anbieter kann nach US-Recht zur Herausgabe verpflichtet und gleichzeitig nach europäischem Recht mit Datenschutzanforderungen konfrontiert sein. Genau daraus entsteht der mögliche Konflikt zwischen zwei Rechtsordnungen.

ZWEI VERSCHIEDENE FRAGEN

CLOUD Act, DSGVO und das Data Privacy Framework

Der CLOUD Act beantwortet eine Frage des US-Rechts: Kann ein Anbieter zur Herausgabe verpflichtet werden? Die DSGVO beantwortet eine andere: Unter welchen Voraussetzungen dürfen personenbezogene Daten in Drittländer übermittelt werden? Das eine hebt das andere nicht automatisch auf.

Die Europäische Kommission hat im Juli 2023 das EU-US Data Privacy Framework (DPF) als Angemessenheitsmechanismus beschlossen, er ist weiterhin in Kraft. Das Gericht der EU wies eine Klage dagegen am 3. September 2025 ab, ein Rechtsmittel (C-703/25 P, Latombe/Kommission) ist im September 2026 weiter anhängig. Am 31. Juli 2026 bat die EDSA-Vorsitzende Anu Talus die Kommission zusätzlich um eine Bewertung, ob das US-Urteil Trump v. Slaughter vom 29. Juni 2026 Auswirkungen auf die Unabhängigkeit der Federal Trade Commission (FTC) hat, die für das DPF zentral ist.

Der wichtigste Satz zur Einordnung: Das Data Privacy Framework ist kein Schutzmechanismus gegen den CLOUD Act. Es regelt die datenschutzrechtliche Zulässigkeit bestimmter Übermittlungen in die USA, es verhindert nicht, dass ein US-Anbieter einer rechtmäßigen US-Anordnung unterliegt. DPF und CLOUD Act beantworten unterschiedliche Fragen und lösen sich gegenseitig nicht auf.

DIE ANDERE SEITE

HBDI und DSK: nicht nur Warnungen

Microsoft 365 kann datenschutzkonform eingesetzt werden

Der Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI) veröffentlichte im November 2025 einen 137-seitigen Bericht zu Microsoft 365 und kam zu dem Ergebnis: Microsoft 365 kann datenschutzkonform genutzt werden. Er hatte zuvor mit Microsoft sieben frühere Kritikpunkte der Datenschutzkonferenz am Microsoft-Datenschutznachtrag untersucht. Der HBDI kommt in seinem Bericht zu dem Ergebnis, dass personenbezogene Daten inzwischen weitgehend im Europäischen Wirtschaftsraum verarbeitet werden und verbleibende Übermittlungen über Angemessenheitsbeschlüsse beziehungsweise Standardvertragsklauseln abgesichert sind.

Zwei Einschränkungen: Der HBDI hat ausdrücklich keine technische Untersuchung einzelner Microsoft-365-Dienste durchgeführt, er bewertet vertragliche und rechtliche Rahmenbedingungen. Und er trifft damit keine Aussage, dass Microsoft 365 vor einem Zugriff aufgrund US-amerikanischen Rechts geschützt wäre.

DSK: Vorsicht bei „Confidential Cloud Computing"

Die Datenschutzkonferenz verabschiedete am 16. Juni 2025 eine Entschließung zu „Confidential Cloud Computing“ und weist darauf hin, dass der Begriff nicht einheitlich definiert ist. Die Aussage, Daten könnten sogar vor dem Cloud-Betreiber geheim gehalten werden, hängt vom konkreten Angreifermodell ab und greift als pauschales Werbeversprechen zu kurz.

Das Kölner Gutachten weist ergänzend darauf hin, dass technische Maßnahmen wie Verschlüsselung eine US-rechtliche Zugriffsmöglichkeit nicht automatisch ausschließen, relevant ist unter anderem, ob der Anbieter selbst noch Zugriff auf die Daten oder die zur Entschlüsselung erforderlichen Schlüssel hat.

ZUSAMMENGEFASST

Drei Aussagen, die nicht dasselbe bedeuten

Daten liegen in Deutschland	Physischer bzw. vertraglich zugesicherter Speicherort
Daten werden innerhalb der EU/EWR verarbeitet	Regionale Datenverarbeitung bzw. Datenresidenz
Anbieter unterliegt keinem relevanten US-Recht	Frage der rechtlichen Zugriffsmöglichkeit

CHANCEN UND GRENZEN

Warum Selbst-Hosting hier interessant wird

Self-Hosting ist nicht automatisch sicherer, aber es verändert den Rechts- und Kontrollrahmen. Eine Nextcloud auf eigener Hardware in Deutschland ist eine andere Konstellation als OneDrive bei einem US-Hyperscaler.

✓

Was sich ändert

Ein selbst betriebener Mailserver wie mailcow unterscheidet sich grundsätzlich von Exchange Online, bei Vaultwarden kontrolliert der Betreiber die Infrastruktur und Datenablage selbst.

◐

Kein Freifahrtschein

Steht der Server bei einem US-Cloudanbieter, liegen Backups bei einem US-Anbieter, läuft Monitoring über einen US-Dienst, ist die Infrastruktur nicht vollständig aus diesem Rechtsraum herausgelöst.

↻

Die ganze Kette zählt

„Der Anbieter sitzt in Deutschland“ ist genauso wenig eine vollständige Prüfung wie „der Server steht in Deutschland“. Entscheidend sind Betreiber, Zugriff, Backup-Ziel, Subunternehmer und Supportsysteme zusammen.

Die saubere Formulierung: Eine vollständig europäisch betriebene Infrastruktur ohne US-rechtlich relevante Anbieter in der Verarbeitungskette reduziert dieses konkrete CLOUD-Act-Risiko erheblich. Genau deshalb setzen wir bei RDDZ konsequent auf europäische, quelloffene Bausteine: Nextcloud statt SharePoint/OneDrive, mailcow statt Exchange Online, Vaultwarden statt einem US-Passwortmanager, UniFi OS Server statt Cloud-verwaltetem Netzwerk-Controller. Und auch bei vollständig selbst betriebener Infrastruktur bleiben Sicherheitsupdates, Backup, Restore-Tests und Dokumentation Aufgabe des Betreibers. Self-Hosting verschiebt Verantwortung, es hebt sie nicht auf.

CHECKLISTE

Was Unternehmen praktisch mitnehmen sollten

Nicht nur auf den Speicherort schauen

„Die Daten liegen in Deutschland“ beantwortet nicht, wem der Anbieter rechtlich verpflichtet ist.

Die ganze Verarbeitungskette prüfen

Nicht nur die Hauptanwendung: Backup-Ziel, CDN, Monitoring, Support, Mailrelay.

Datensensibilität einordnen

Nicht jede Verarbeitung braucht dieselbe Vorsicht, bei Gesundheitsdaten oder Berufsgeheimnissen lohnt eine strengere Betrachtung.

Bestehendes nicht pauschal verteufeln

Microsoft 365 kann laut HBDI unter den geprüften vertraglichen und rechtlichen Rahmenbedingungen datenschutzkonform genutzt werden.

Bei Selbst-Hosting den Betrieb ernst nehmen

Sonst verschiebt man nur das Risiko, statt es zu senken: Updates, Backups, Zugriffsschutz bleiben Pflicht.

Bei Bedarf fachlich beraten lassen

Gerade bei regulierten Branchen oder besonders sensiblen Daten lohnt eine individuelle Prüfung der eigenen Infrastruktur.

FAZIT

Kein Mythos, aber auch kein Papiertiger

Der CLOUD Act ist kein Mythos und kein automatischer Zugriff, aber auch kein Papiertiger. Microsoft selbst hat unter Eid eingeräumt, eine vollständige Garantie nicht geben zu können, während der spezielle gesetzliche Konfliktmechanismus nach § 2703(h) mangels eines entsprechenden CLOUD-Act-Exekutivabkommens für Deutschland derzeit nicht zur Verfügung steht. Gleichzeitig hält eine deutsche Aufsichtsbehörde Microsoft 365 unter bestimmten Bedingungen für datenschutzkonform nutzbar, und das Data Privacy Framework ist trotz laufender rechtlicher Entwicklung weiterhin gültig.

Für Unternehmen bedeutet das: keine Panik, aber auch keine blinde Beruhigung durch „die Daten liegen doch in Deutschland“. Wer besonders sensible Daten verarbeitet oder das Risiko grundsätzlich nicht eingehen will, findet mit einer konsequent europäischen, selbst gehosteten Infrastruktur den Weg, der dieses spezielle Risiko am wirksamsten reduziert, verbunden mit der eigenen Verantwortung, diese Infrastruktur auch sauber zu betreiben. Mehr zum Zusammenhang mit dem Speicherort selbst: Microsoft 365: Datenstandort Deutschland ändert sich.

FAQ

Häufige Fragen zum US CLOUD Act

Bedeutet der CLOUD Act, dass US-Behörden jederzeit auf europäische Microsoft-Server zugreifen können?

Nein. Der CLOUD Act schafft gesetzliche Möglichkeiten, von bestimmten Anbietern im Einzelfall die Herausgabe konkreter Daten zu verlangen, kein dauerhaftes Zugriffsrecht. Welche Maßnahme nötig ist, hängt von der Art der Daten und der Rechtsgrundlage ab.

Schützt es, wenn meine Daten in Deutschland gespeichert werden?

Es reduziert bestimmte Risiken und erfüllt organisatorische Anforderungen, ist aber kein vollständiger Schutz. § 2713 CLOUD Act stellt nicht auf den physischen Speicherort ab, sondern auf possession, custody or control des Anbieters.

Kann sich ein Anbieter gegen eine US-Anordnung wehren?

Der CLOUD Act sieht mit § 2703(h) einen Mechanismus dafür vor, er gilt aber nur gegenüber Staaten mit einem CLOUD-Act-Executive-Agreement. Das haben aktuell nur Großbritannien und Australien, Deutschland und die EU nicht.

Schützt mich das EU-US Data Privacy Framework vor dem CLOUD Act?

Nein. Das DPF regelt die datenschutzrechtliche Zulässigkeit von Datenübermittlungen in die USA, es verhindert nicht, dass ein US-Anbieter einer rechtmäßigen US-Anordnung nach dem CLOUD Act unterliegt. Beides sind unterschiedliche Rechtsfragen.

Ist Microsoft 365 deshalb nicht DSGVO-konform?

Diese pauschale Aussage lässt sich nicht halten. Der Hessische Beauftragte für Datenschutz kam 2025 zu dem Ergebnis, dass Microsoft 365 unter bestimmten vertraglichen und rechtlichen Bedingungen datenschutzkonform genutzt werden kann, allerdings ohne eigene technische Prüfung einzelner Dienste.

Löst Selbst-Hosting das Problem vollständig?

Es reduziert das konkrete CLOUD-Act-Risiko erheblich, wenn die gesamte Verarbeitungskette ohne US-rechtlich relevante Anbieter auskommt, ist aber kein Freifahrtschein. US-CDN, US-Backup oder US-Monitoring in der Verarbeitungskette können wiederum einen Anbieter einbeziehen, der einem relevanten US-Rechtsrahmen unterliegt, und die eigene Betriebsführung bleibt Pflicht.

QUELLEN

Quellen und Rechtsgrundlagen

18 U.S.C. § 2713, § 2703(h), § 2705 (CLOUD Act / Stored Communications Act)
Sénat français: Anhörung Anton Carniaux (Microsoft France), 10. Juni 2025
Rechtsgutachten der Universität zu Köln im Auftrag des BMI, 21. März 2025
US Department of Justice: CLOUD Act Agreements (UK, Australien)
HBDI: Bericht zu Microsoft 365, November 2025
Datenschutzkonferenz: Entschließung „Confidential Cloud Computing“, 16. Juni 2025
EuG, Urteil vom 3. September 2025; EuGH C-703/25 P (Latombe/Kommission), anhängig
EDSA: Schreiben an die EU-Kommission zu Trump v. Slaughter, 31. Juli 2026

Europäische Infrastruktur statt US-Cloud?

Ob Nextcloud, mailcow oder Vaultwarden: Nutzen Sie unsere IT-Leistungen.

Der Beitrag US CLOUD Act: Warum „Daten liegen in Deutschland“ nicht die ganze Wahrheit ist erschien zuerst auf RDDZ.

Microsoft 365: Datenstandort Deutschland ändert sich

dennis_rddz — Fri, 25 Sep 2026 14:43:51 +0000

Microsoft 365 · Datenschutz · Compliance

Microsoft 365: Datenstandort Deutschland ändert sich

Microsoft ändert 2026 die Regeln für den Datenstandort bestimmter Microsoft-365-Daten. Seit dem 14. September 2026 gibt es für bestimmte Tenants in Deutschland eine neue Einstellung im Admincenter, die entscheidet, ob Daten weiterhin in Deutschland oder regional innerhalb der EU-Datengrenze gespeichert werden. Die Frist ist der 14. Dezember 2026, keine Panikmeldung, aber eine Konfigurations- und Compliance-Frage.

DATENSTANDORT 2026

● Frist 14.12.2026

Sichtbar

seit 14.09.2026

Wirksam

ab 14.12.2026

Standard

Off (EU-weit)

Verlässt die EU? ✓ nein

DSGVO-Pflicht zu „nur Deutschland“? ✓ nein

Rückmigration falls „On“ später ✓ ~6 Monate

Betroffen ✓ Exchange, SharePoint, OneDrive, Teams, Copilot

Deutschland ≠ EU-Datengrenze ≠ „nur“ Deutschland

✓ Neue Einstellung seit 14.09.2026

✓ Frist: 14.12.2026

✓ Standard: Off (EU-weit möglich)

✓ Betrifft DE, FR, NO, SE, CH

✓ Keine DSGVO-Pflicht zu „nur DE“

DIE ÄNDERUNG

Was Microsoft konkret geändert hat

Microsoft nennt die neue Option „Store Microsoft 365 customer data in-country“, zu finden im Admincenter unter Admin → Einstellungen → Organisationseinstellungen → Organisationsprofil → Datenspeicherort → Verpflichtungen.

14.09.2026: sichtbar

Die Einstellung steht seither zur Prüfung bereit. Die bestehende Datenposition soll während dieser rund dreimonatigen Prüfphase nicht verändert werden.

14.12.2026: wirksam

Die hinterlegte Auswahl wird verbindlich. Microsoft weist ausdrücklich darauf hin, dass nicht alle Daten an diesem einen Tag verschoben werden.

Nicht für jeden Tenant

Betroffen sind berechtigte kommerzielle Tenants mit Standardgeografie in Deutschland, Frankreich, Norwegen, Schweden oder der Schweiz. Tenants mit Advanced Data Residency oder Multi-Geo sehen die Einstellung nicht.

ON ODER OFF

Der wichtigste Unterschied

Was bedeutet „On“ und „Off“?

On: Microsoft hält die betroffenen Core-Service-Daten im Ruhezustand in der zugeordneten Länder-Geografie, für einen deutschen Tenant also in Deutschland.

Off (Standard): Microsoft darf diese Daten regional innerhalb der EU-Datengrenze speichern und verschieben. Microsoft formuliert ausdrücklich, dass das Ausschalten die bisherige In-Country-Data-at-Rest-Zusage für diese Dienste entfernt.

WICHTIGE KLARSTELLUNG

EU-Datengrenze bedeutet nicht Deutschland

Die EU Data Boundary ist eine von Microsoft definierte geografische Grenze, sie umfasst die EU- und die EFTA-Staaten. Damit können Daten künftig auch innerhalb verschiedener europäischer Rechenzentrumsstandorte liegen, ohne dass Deutschland weiterhin zwingend der Speicherort sein muss.

◐

Deutschland

Eine konkrete Länder-Geografie: ein einzelnes Land als zugesagter Speicherort.

▤

EU Data Boundary

Eine größere regionale Geografie innerhalb EU und EFTA. Das ist nicht dasselbe wie Deutschland.

✓

Kein neues Konstrukt

Die EU-Datengrenze existiert bereits seit 2023 für Microsoft 365, Azure, Power Platform und Dynamics 365. Sie wird hier nicht verlassen, nur die engere Zusage „nur Deutschland“ steht zur Wahl.

Wichtig: Die Daten bleiben in jedem Fall innerhalb der EU-Datengrenze, unabhängig davon, ob die Einstellung an- oder ausgeschaltet ist. Es geht nicht darum, ob Daten Europa verlassen, sondern nur darum, ob sie ausschließlich in einem Land oder regional innerhalb der EU/EFTA gespeichert werden dürfen.

DIENSTE UND GRENZEN

Betroffene Dienste und die Grenzen der Grenze

Die neue Einstellung gilt nur für die sogenannten Microsoft 365 Core Services.

◐

Betroffen

Exchange Online
SharePoint
OneDrive for Business
Microsoft Teams
Microsoft 365 Copilot / Copilot Chat

✎

Nicht daraus ableiten

„Alle Microsoft-365-Daten liegen ab jetzt in Deutschland“ ist falsch. Genauso falsch: „Alle Daten werden ab Dezember irgendwo in Europa gespeichert.“ Andere Microsoft-Dienste können eigenen Datenresidenz-Regeln unterliegen, ein Blick auf die konkrete Data Location Card lohnt sich immer.

↗

Data at rest ≠ Verarbeitung

Microsoft spricht von Customer Data at rest, also Daten im Ruhezustand. Das ist nicht dasselbe wie „diese Daten werden ausschließlich in Deutschland verarbeitet“.

Auch die EU-Datengrenze ist keine absolute technische Grenze

Microsoft dokumentiert selbst begrenzte Situationen, in denen Daten trotz EU-Datengrenze außerhalb übertragen werden können: Remotezugriff durch Microsoft-Mitarbeiter außerhalb der Grenze, vom Kunden selbst ausgelöste Übertragungen, bestimmte Sicherheits- und Schutzmaßnahmen, begrenzte Replikation von Verzeichnisdaten, bestimmte Netzwerktransits sowie Service-, Plattform- und Resilienzmaßnahmen. Diese Szenarien sind Teil der von Microsoft beschriebenen Bedingungen und über die entsprechenden Vertrags- und Datenschutzmechanismen abgedeckt. Für Administratoren heißt das: EU-Datengrenze bedeutet nicht „kein Byte verlässt jemals Europa“.

DIE ENTSCHEIDENDE FRAGE

Und was bedeutet das für die DSGVO?

Kurz und direkt: Es gibt keine DSGVO-Pflicht zur ausschließlichen Speicherung in Deutschland, weder vorher noch nachher.

Die DSGVO regelt in den Artikeln 44 ff. Übermittlungen personenbezogener Daten in Länder außerhalb der EU und des EWR (sogenannte Drittländer). Datenverkehr zwischen EU-/EWR-Mitgliedstaaten fällt gar nicht unter diese Drittland-Regeln, er ist datenschutzrechtlich innerhalb der Union frei möglich. Eine Speicherung „irgendwo in der EU-Datengrenze“ statt „nur in Deutschland“ berührt diese Vorschriften deshalb grundsätzlich nicht.

Das heißt aber nicht, dass der Speicherort für Datenschutz und Compliance völlig egal ist. Die DSGVO-Konformität eines Microsoft-365-Tenants hängt nicht allein davon ab, ob Daten in Deutschland oder beispielsweise Frankreich liegen. Relevant sind unter anderem: welche personenbezogenen Daten verarbeitet werden, welche Microsoft-Dienste eingesetzt werden, welche Unterauftragsverarbeiter beteiligt sind, welche vertraglichen Grundlagen gelten (Microsoft stellt dafür ein Data Protection Addendum und EU-Standardvertragsklauseln bereit) und welche technischen und organisatorischen Maßnahmen eingesetzt werden.

Ein Fall, in dem es doch relevant wird: Wenn ein Unternehmen gegenüber Kunden, Mitarbeitern oder Geschäftspartnern vertraglich ausdrücklich eine bestimmte, engere Datenresidenz zugesichert hat (zum Beispiel „ausschließlich Deutschland“), kann die Änderung dieser Microsoft-Einstellung diese eigene Zusage berühren, unabhängig von der DSGVO selbst.

FOLGEN UND ALTERNATIVEN

Was passiert, wenn man nichts tut?

Nichts tun bedeutet: Off bleibt aktiv

Bei einem berechtigten Tenant bleibt die Einstellung zunächst deaktiviert. Ab dem 14. Dezember 2026 kann Microsoft bei solchen Tenants mit der regionalen Speicherung beziehungsweise Verschiebung innerhalb der EU-Datengrenze beginnen, nicht zwingend vollständig an diesem einen Tag.

Die Einstellung lässt sich später wieder auf „On“ stellen, Microsoft verpflichtet die Daten dann wieder auf die ursprüngliche Geografie und beginnt mit der Rückmigration. Diese kann laut Microsoft rund sechs Monate dauern. Wer die Länder-Geografie wichtig findet, sollte deshalb vor dem 14. Dezember entscheiden, statt später „einfach zurückzustellen“.

Das ist nicht dasselbe wie Advanced Data Residency

Advanced Data Residency (ADR) ist ein kostenpflichtiges Add-on mit weitergehenden Datenresidenz-Zusagen für bestimmte Dienste und Länder, Deutschland gehört zu den unterstützten Geografien. Tenants mit ADR, ADR for Education oder Multi-Geo sehen die neue „in-country“-Einstellung gar nicht, weil deren Datenresidenz bereits über diese kostenpflichtigen Angebote gesteuert wird.

CHECKLISTE

So prüfst du deinen Microsoft-365-Tenant

Im Admincenter: Admin → Einstellungen → Organisationseinstellungen → Organisationsprofil → Datenspeicherort → Verpflichtungen. Zusätzlich lohnt der Blick auf die Data Location Card, sie unterscheidet zwischen der aktuellen Current Geography und der zugesicherten Committed Geography.

Tenant prüfen

Ist der Tenant betroffen? Ist die Einstellung vorhanden, und steht sie auf On oder Off? Welche Committed Geography wird angezeigt?

Datenschutzvorgaben prüfen

Nicht nur „wo liegt die Datei“, sondern auch: Welche Datenresidenz wurde Kunden, Mitarbeitern oder Geschäftspartnern zugesichert?

Dienste klassifizieren

Nicht jede Microsoft-365-Komponente fällt unter dieselbe Zusage, besonders bei Copilot, Entra ID, Sicherheitsprodukten und Drittanbieter-Integrationen lohnt ein eigener Blick.

Bei strengeren Compliance-Anforderungen prüfen, ob die vorhandene Konfiguration tatsächlich ausreicht, und die Entscheidung vor dem 14. Dezember treffen, nicht erst danach, wegen der rund sechsmonatigen Rückmigration.

RICHTIGSTELLUNG

Was Microsoft damit nicht sagt

Microsoft sagt nicht: „Ab Dezember liegen deutsche Microsoft-365-Daten irgendwo in den USA.“ Die neue Option verschiebt die Datenresidenz von Deutschland auf die EU-Datengrenze, nicht in die USA.

Microsoft sagt auch nicht: „Ab Dezember sind deutsche Microsoft-365-Daten nicht mehr DSGVO-konform.“ Dafür gibt es keine Grundlage.

Ebenso falsch wäre die Annahme: „Die Daten sind garantiert ausschließlich in Deutschland und werden niemals außerhalb Deutschlands verarbeitet.“ Auch das lässt sich aus der Einstellung nicht ableiten, unabhängig von On oder Off.

FAZIT

Eine Konfigurationsfrage, keine Panikmeldung

Wer einen deutschen Microsoft-365-Tenant betreibt und Wert darauf legt, dass die betroffenen Core-Service-Daten weiterhin der deutschen Geografie zugeordnet bleiben, sollte die neue Einstellung im Admincenter vor dem 14. Dezember 2026 prüfen. Wer nichts ändert, bekommt bei einem betroffenen Tenant künftig eine regionale Speicherung innerhalb der EU-Datengrenze, mehr Flexibilität für Microsoft, aber Deutschland ist dann nicht mehr als konkrete Datenresidenz zugesichert.

Deutschland ≠ EU-Datengrenze ≠ ausschließliche Verarbeitung in Deutschland. Für Datenschutz und Compliance entscheidend ist deshalb nicht nur, wo Microsoft die Daten speichert, sondern auch, welche Dienste betroffen sind, welche Verarbeitung stattfindet und welche vertraglichen Zusagen für den konkreten Tenant gelten, unabhängig davon, dass eine DSGVO-Pflicht zu „nur Deutschland“ nie bestanden hat.

FAQ

Häufige Fragen zum Datenstandort

Verlangt die DSGVO, dass Daten ausschließlich in Deutschland gespeichert werden?

Nein. Die DSGVO regelt nur Übermittlungen in Länder außerhalb der EU/des EWR. Datenverkehr zwischen EU-Mitgliedstaaten fällt nicht unter diese Regeln. Eine Speicherung innerhalb der EU-Datengrenze statt nur in Deutschland ist datenschutzrechtlich grundsätzlich unproblematisch.

Werden meine Daten ab Dezember 2026 in die USA verschoben?

Nein. Die neue Einstellung verschiebt die Datenresidenz höchstens von Deutschland auf die EU-Datengrenze (EU und EFTA), nicht in die USA oder andere Drittländer.

Was bedeutet die Einstellung „On“ und „Off“ konkret?

On: Microsoft hält die betroffenen Daten im Ruhezustand in Deutschland. Off (Standard): Microsoft darf sie regional innerhalb der EU-Datengrenze speichern und verschieben.

Welche Dienste sind betroffen?

Nur die Microsoft 365 Core Services: Exchange Online, SharePoint, OneDrive for Business, Microsoft Teams sowie Microsoft 365 Copilot und Copilot Chat. Andere Microsoft-Dienste können eigenen Regeln unterliegen.

Was passiert, wenn ich die Frist verpasse?

Die Einstellung bleibt auf Off, Microsoft kann ab dem 14. Dezember 2026 mit der regionalen Speicherung beginnen. Die Einstellung lässt sich später ändern, die Rückmigration nach Deutschland dauert dann aber laut Microsoft rund sechs Monate.

Warum sehe ich die Einstellung in meinem Tenant gar nicht?

Sie gilt nur für berechtigte kommerzielle Tenants mit Standardgeografie in Deutschland, Frankreich, Norwegen, Schweden oder der Schweiz. Tenants mit Advanced Data Residency oder Multi-Geo sehen sie nicht, weil deren Datenresidenz bereits anders geregelt ist.

QUELLEN

Quellen und Links

Microsoft Learn: Data residency in Microsoft 365 (Committed Geography, Data Location Card)
Microsoft Learn: EU Data Boundary Übersicht und Ausnahmen
Microsoft Message Center: MC1470878 (Store Microsoft 365 customer data in-country)
Microsoft: Product Terms und Data Protection Addendum (DPA)

Microsoft 365 datenschutzkonform betreiben?

Ob Tenant-Prüfung, Datenschutz oder IT-Infrastruktur: Nutzen Sie unsere IT-Leistungen.

Der Beitrag Microsoft 365: Datenstandort Deutschland ändert sich erschien zuerst auf RDDZ.

Windows 10 – Updates bis Oktober 2027

dennis_rddz — Thu, 25 Jun 2026 22:23:35 +0000

Windows 10 - Microsoft verlängert Support bis Oktober 2027

Juni 26, 2026
00:23

ESU Programm für Privatkunden

Microsoft Windows 10 wird für Privatpersonen im Rahmen des ESU Programmes kostenlos weiter mit Sicherheitsupdates bis Oktober 2027 versorgt.

Ursprünglich sollten die Sicherheitsupdates für Windows 10 im Oktober 2026 auslaufen. Microsoft hat in seinem Supportartikel darauf hingewiesen das der letzte Patch dann wohl am 12. Oktober 2027 ausgerollt wird.

Für alle Privat Anwender ist dieses ESU Programm kostenlos wenn man sich in seinem Microsoft Konto anmeldet – ansonsten werden einmalig 30 Euro fällig.

ESU Programm für Firmenkunden

Firmenkunden haben keinerlei Möglichkeit diese Sicherheitsupdates kostenlos zu erhalten.

Es besteht jedoch die Möglichkeit diese Updates für bis zu drei Jahre zu kaufen.

Jahr 1 / pro Rechner: 60 Euro
Jahr 2 / pro Rechner: 120 Euro
Jahr 3 / pro Rechner: 240 Euro

Der Beitrag Windows 10 – Updates bis Oktober 2027 erschien zuerst auf RDDZ.