Docker Image Security – Teil 3: Minimale, sichere Container-Images selbst bauen
Minimale Container-Images verzichten auf Komponenten wie Shells oder Paketmanager, die zur Laufzeit normalerweise nicht gebraucht werden. Sie sind auch als „distroless“ oder „chiseled“ Images bekannt. Weil weniger Komponenten weniger Schwachstellen bedeuten, reduzieren diese Images die Angriffsfläche und erhöhen dadurch die Sicherheit.
Weiterlesen nach der Anzeige
Dr. Marius Shekow war über 10 Jahre als Forscher und Softwareentwickler bei Fraunhofer tätig. Seit 2022 ist er Lead DevOps- & Cloud-Engineer bei SprintEins in Bonn. Dort baut er für Konzerne und KMUs individuelle Cloud-Umgebungen, inkl. CI/CD-Automatisierung, Observability und Security-Absicherung.
Schlüsselfertige Images für ein Basis-Linux sowie die Sprachen PHP, Python, Java, C# und Node.js hat Teil 2 der Artikelserie vorgestellt. Diese vorkonfektionierten Images passen jedoch nicht immer zu den eigenen Anforderungen und es kann notwendig sein, eigene zu erstellen. Dieser Artikel zeigt, wie Softwareentwicklerinnen und -entwickler eigene minimale Images basierend auf den Angeboten Ubuntu Chiseled, Chainguard/WolfiOS und Azure Linux bauen (siehe die folgende Tabelle).
Drei Anbieter minimaler Images im Vergleich
Bewertungskriterium
Ubuntu Chiseled
WolfiOS / Chainguard
Azure Linux
Verfügbare Pakete
~500
~3000
~3000
Qualität der Dokumentation / Schwierigkeit der Nutzung
➕➕
➕➕➕
➕
Integrationsgeschwindigkeit von Paket-Versionsupdates (Upstream)
Langsam
Schnell
Mittel
Reproduzierbare Image-Builds / Pinnen der zu installierenden Paket-Versionen
❌
✅
❌
Kommerzieller Support
✅
✅
❌
Bauen von Ubuntu Chiseled Images
Canonical verwendet die Bezeichnung „Chiseled“ für minimale, Ubuntu-basierte Images. Ein Blogbeitrag stellt das Chisel-CLI von Ubuntu vor. Chisel ist ein Build-Tool, das Entwickler mit der gewünschten Ubuntu-Version (beispielsweise „24.04“) und einer Liste von „Slices“ aufrufen, die Chisel zu einem neuen Root-Filesystem zusammenbaut. Dieses Filesystem kopiert man anschließend in ein leeres scratch-Image, wie der Ablaufplan in Abbildung 1 verdeutlicht:
Bau eines Chiseled-Image via Multi-Stage Dockerfile (Abb.1)
Das Ubuntu-Team hat einige (jedoch nicht alle) der offiziellen Ubuntu-Pakete in mehrere Slices aufgeteilt und diese auf GitHub veröffentlicht. Falls Slices für ein gewünschtes Paket fehlen, sollte man auf andere im Artikel erwähnte Ansätze wechseln. Denn bestehende GitHub Issues zeigen, dass reine Feature-Requests lange oder gänzlich ignoriert werden, und der Zeitinvest für die Einarbeitung für eigene Pull Requests (PRs) hoch ist.
Weiterlesen nach der Anzeige
Aufbauend auf Chisel stellt Canonical zudem das Rockcraft-Tool zur Verfügung, das auf einer höheren Abstraktionsebene arbeitet.
Verwenden des Chisel CLI
Bevor Entwickler tiefer in den Build-Prozess von Ubuntu Chiseled-Images einsteigen, sollten sie sich der folgenden zwei Einschränkungen bewusst sein:
Es lassen sich nur Pakete installieren, für die das Ubuntu-Team bereits Slice-Definitionen erstellt hat. Die Slices unterscheiden sich je nach Ubuntu-Version (beispielsweise hat 22.04 andere Slices als 24.04). Das ist insbesondere beim Erstellen eines Image für einen Interpreter einer Programmiersprache wie Java, Node.js oder Python relevant. Dabei stehen lediglich die in der jeweiligen Distro-Version mitgelieferten Interpreter-Versionen zur Verfügung. So gibt es bei Python im neuesten Ubuntu-LTS-Release (24.04) nur Python 3.12.3. Neuere 3.12-Versionen (oder 3.13) fehlen. Für Python 3.12.3 hat Ubuntu jedoch zumindest die seit dieser Version 3.12.3 bekannt gewordenen Schwachstellen behoben (sogenannte „Backports“).
Es ist nicht möglich, die Versionen der Pakete oder Slices zu pinnen! Das Chisel CLI installiert immer die aktuelle Version des Pakets, die zum Zeitpunkt der Chisel-Ausführung im offiziellen Ubuntu-Repo verfügbar ist.
Der einfachste Weg, ein Chiseled-Image zu erstellen, ist ein Docker Multi-Stage Build. Wie man für ein Python-Image (mit Python 3.12.3) auf Basis von Ubuntu 24.04 vorgeht, erklärt das offizielle Chisel-Tutorial.
Da Schwachstellenscanner wie Trivy oder Grype die Pakete im frisch gebauten Image leider nicht korrekt identifizieren können, sind weitere Anpassungen am Dockerfile nötig. Der Grund dafür, warum die Scanner relevante Schwachstellen übersehen, geht aus einem GitHub Issue hervor: Ubuntu hat entschieden, für Chisel-Images ein eigenes proprietäres Paket-Manifest-Format zu erfinden, das Scanner wie Trivy bisher nicht verstehen.
Ubuntu versucht daher mit Scanner-Anbietern zusammenzuarbeiten, wie beispielsweise eine GitHub-Diskussion zu Trivy zeigt. Bis es so weit ist, können Entwickler einen Workaround nutzen: Das chisel-wrapper-Skript generiert Metadaten im Standard-Debian-Paket-Format, das Scanner wie Trivy verstehen. Dazu sind im Dockerfile des Multi-Stage-Builds (vom offiziellen Tutorial) folgende Änderungen vorzunehmen:
# Einfügen der folgenden 3 RUN-Zeilen, irgendwo vor dem "chisel cut" Befehl des Tutorials:
# "file" wird vom chisel-wrapper script benötigt
RUN apt-get update && apt-get install -y git file
RUN git clone --depth 1 -b main /rocks-toolbox && mv /rocks-toolbox/chisel-wrapper /usr/local/bin/ && rm -rf /rocks-toolbox
RUN mkdir -p /staging-rootfs/var/lib/dpkg
# Ersetzen der RUN-Zeile, die den "chisel cut" Befehl ausführt, mit folgender Zeile:
RUN chisel-wrapper --generate-dpkg-status /staging-rootfs/var/lib/dpkg/status -- --release "ubuntu-$UBUNTU_RELEASE" --root /staging-rootfs
Ein vollständiges Beispiel für Python 3 liegt im GitHub-Repository des Autors öffentlich parat. Es veranschaulicht den Build einer Flask-basierten Demo-Anwendung. Zudem demonstriert es, wie man ein Problem löst, das dadurch entsteht, dass der Python-Interpreter im Chiseled Basis-Image an einem anderen Pfad liegt als beim python-Image, das in der Build-Stage verwendet wird. Ein weiteres GitHub-Gist des Autors zeigt, wie man ein Chiseled Java JRE-Image erstellt und darin die Springboot-Petclinic-Anwendung ausführt.
Verwendung des Rockcraft CLIs
Ein weiterer Ansatz, Ubuntu Chiseled Images zu erstellen, ist das Rockcraft-CLI, das auf einer höheren Abstraktionsebene als Chisel arbeitet.
Rockcraft greift intern auf Chisel zurück, um das Root-Filesystem zu erstellen. Über eine von Rockcraft eingelesene YAML-Datei legt man deklarativ die folgenden Aspekte fest:
Die Ubuntu-Version, deren Slices verwendet werden sollen
Die Liste der zu installierenden Slices
Die CPU-Architekturen, für die Rockcraft das Image erstellen soll (für Multiplattform-Builds)
Welcher Nicht-Root-Linux-User erstellt und automatisch beim Image-Start verwendet werden soll
Welche Linux-Services zum Image-Start mit dem Pebble Service-Manager gestartet werden sollen (Pebble ist eine Alternative zu systemd)
Mit Rockcraft erstellte, vorgefertigte Images lassen sich mit dem Suchbegriff „chisel“ in der Canonical GitHub-Organisation finden, beispielsweise:
Die größten Nachteile von Rockcraft sind:
Rockcraft macht den Build-Prozess durch zusätzliches Tooling komplexer (verglichen mit einem direkten Chisel-CLI-Aufruf).
Es erzwingt die Nutzung des Pebble Service Managers, der als ENTRYPOINT für das Image gesetzt wird. Dies ist unnötig, denn im Gegensatz zur Vorgehensweise bei virtuellen Maschinen (VMs) sind Service-Manager bei Containern nicht üblich. In diesen Umgebungen ist es gewollt, dass der gesamte Container beendet wird, wenn das im ENTRYPOINT festgelegte Programm abstürzt. Denn Container Runtimes wie Docker Compose oder Kubernetes überwachen den Container-Status und starten ihn dann neu. Zudem finden Schwachstellenscanner wie Trivy im Pebble-Binary häufig CVEs. Diese stellen zwar meistens keine Bedrohung dar, verursachen allerdings unnötigen Diagnose-Aufwand.
Die von Rockcraft generierten Images verwenden den chisel-wrapper-Trick für Schwachstellenscanner nicht. Folglich können diese die im Image installierten Komponenten nicht korrekt identifizieren und keine Schwachstellen melden.
Um sichere, minimale Images zu erstellen, ist es daher empfehlenswert, direkt das Chisel-CLI statt Rockcraft zu verwenden. Dennoch lohnt sich ein Blick in die stage-packages-Einträge der rockcraft.yaml-Dateien in den oben gelisteten Repositorys (beispielsweise für Python), um eine Idee dafür zu bekommen, welche Slices im eigenen Image sinnvoll sind.
Bundestrojaner: BND soll zur Spyware-Installation in Wohnungen eindringen dürfen
Das Bundeskanzleramt treibt eine umfangreiche Reform des Gesetzes für den Bundesnachrichtendienst (BND) voran. Ziel ist es, den Auslandsgeheimdienst technologisch wie operativ aufzurüsten. Das berichten WDR, NDR und Süddeutsche Zeitung. Ein Kernpunkt der Initiative ist demnach die Befugnis für die Agenten, physisch in Wohnungen einzudringen, um Spionagesoftware wie den Bundestrojaner heimlich direkt auf IT-Systemen von Zielpersonen zu installieren. Das soll helfen, technische Hürden wie Verschlüsselung und die Abschottung von Endgeräten zu umgehen. Das spiegelt einen Trend wider, der sich auf Länderebene abzeichnet: Erst jüngst beschloss das Berliner Abgeordnetenhaus: Die dortige Polizei darf Wohnungen heimlich betreten, um Staatstrojaner zu platzieren.
Weiterlesen nach der Anzeige
Brisant ist auch die vorgesehene Einführung „operativer Anschlussmaßnahmen“, die den BND zur Sabotage im Ausland ermächtigen würden. Bisher war die Arbeit der Behörde darauf beschränkt, Erkenntnisse zu gewinnen und diese für die politische Entscheidungsfindung aufzubereiten. Nach den Plänen soll der Dienst eigenständig handeln dürfen, um die Angriffsfähigkeit gegnerischer Akteure zu schwächen. Dies reicht von der Störung feindlicher Kommunikationsnetze bis hin zur Unschädlichmachung von Waffensystemen durch gezielte Cyberoperationen. Bei Cyberangriffen auf deutsche Ziele soll es dem BND so laut den Berichten erlaubt werden, im Rahmen der umstrittenen „Hackbacks“ aktiv zurückzuschlagen. Die Spione dürften etwa Datenströme umleiten oder die für die Attacken genutzte IT-Infrastruktur im Ausland direkt selbst angreifen.
Sabotage nicht nur im Cyberraum
Der Entwurf sieht vor, dass BND-Mitarbeiter physisch an gegnerischen Geräten oder Waffensystemen Manipulationen vornehmen dürfen. Dies könnte die Sabotage von Raketentechnik oder Zentrifugen umfassen, um deren Einsatz oder Weitergabe in Krisenstaaten zu verhindern. Das Kanzleramt setzt ferner auf moderne Analysewerkzeuge: Der Einsatz von KI zur Datenauswertung soll ebenso verankert werden wie die Nutzung von Gesichtserkennungssoftware. Der Dienst könnte zudem künftig Standort- und Routendaten direkt bei Fahrzeugherstellern oder Werkstätten abrufen. Damit diese weitreichenden Befugnisse greifen, müsste der Nationale Sicherheitsrat zuvor eine Sonderlage feststellen, die eine systematische Gefährdung der Bundesrepublik beschreibt. Der BND würde damit in einer Grauzone zwischen klassischer Spionage und militärischer Verteidigung agieren.
Insgesamt umfasst der Entwurf 139 Paragraphen, was einer Verdopplung des bisherigen Normenwerks entspricht und den Anspruch der Reform unterstreicht. Der BND dürfte künftig so auch verdächtige Drohnen über seinen Liegenschaften mit „geeigneten Mitteln“ abwehren. Das Kanzleramt betont, mit der Leistungsfähigkeit internationaler Partnerdienste wie der NSA Schritt halten zu müssen, um in einer veränderten Weltlage handlungsfähig zu bleiben. Die Vorgaben des Bundesverfassungsgerichts zur Datenübermittlung sollen zwar umgesetzt werden, doch der Fokus liegt auf einer offensiven Ausrichtung. Mit dem Mix aus physischer Infiltration, digitaler Sabotage und KI-Überwachung will die Regierungszentrale den Nachrichtendienst als schlagkräftiges Instrument einer „hemdsärmeligeren“ Sicherheitspolitik positionieren. Zunächst müssen aber die anderen Ressorts zustimmen, damit das parlamentarische Verfahren starten kann.
Noch viel Unkenntnis über die elektronische Patientenakte
Die elektronische Patientenakte (ePA) ist inzwischen einem Großteil der Bevölkerung bekannt. Gleichzeitig kursieren aber noch viele falsche Informationen über sie. Und nur etwa jede:r Zehnte nutzt die eigene Akte aktiv.
Das sind zentrale Ergebnisse einer „Datenbarometer-Befragung“ der Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI), Louisa Specht-Riemenschneider. In ihrem Auftrag hat das Meinungsforschungsinstitut info im November rund 1.500 gesetzlich Versicherte zur ePA befragt.
Vier Fünftel sind passive Nutzer:innen
Seit Januar haben die Krankenkassen für alle gesetzlich Versicherten, die nicht widersprachen, eine digitale Patientenakte angelegt. Nach einer Pilotphase wurde die ePA im Frühjahr schrittweise bundesweit ausgerollt. Seit Oktober sind alle Ärzt:innen, Apotheken und Krankenhäuser dazu verpflichtet, die ePA zu nutzen.
Nach knapp einem Jahr kennen 95 Prozent der Befragten die ePA zumindest dem Namen nach. Allerdings verfügen nur 12 Prozent über einen Zugang zu ihrer Akte. Das heißt, sie haben etwa eine Gesundheits-ID und sich mit Hilfe der App ihrer Krankenkasse in die persönliche ePA eingeloggt. Zu den aktiven Nutzer:innen zählen laut Datenbarometer vor allem jüngere Menschen unter 40 und Menschen mit höherem Bildungsabschluss.
Knapp 80 Prozent der Befragten haben ihre ePA noch nicht aktiviert, sie gelten als „passiv Nutzende“. Als Grund führen sie einen fehlenden Bedarf (42 Prozent) und Zeitgründe (26 Prozent) an.
7 Prozent der Befragten haben der ePA widersprochen, 5 Prozent wollen dies noch tun, 3 Prozent sind unentschieden – in der Summe sind das 15 Prozent der Befragten. Die BfDI schließt daraus, dass 85 Prozent der gesetzlich Versicherten ihre ePA behalten möchten.
Viele Falschannahmen kursieren
Auch wenn der Bekanntheitsgrad der ePA steigt, zeigt die Umfrage, dass derzeit noch zahlreiche Fehlannahmen über sie kursieren.
Demnach glauben 43 Prozent der Befragten fälschlicherweise, dass die ePA erst eingerichtet werde, wenn sich Versicherte registriert und die entsprechende App auf ihrem Endgerät installiert haben. Und nur gut ein Drittel von ihnen weiß, dass Versicherte eigenständig Dokumente aus der digitalen Patientenakte löschen dürfen.
Uns fehlen dieses Jahr noch 173.723 Euro.
Bist Du auch Feuer und Flamme für Grundrechte? Dann unterstütze jetzt unsere Arbeit mit einer Spende.
Bist Du auch Feuer und Flamme für Grundrechte? Dann unterstütze jetzt unsere Arbeit mit einer Spende.
Immerhin geben 60 Prozent der Befragten korrekt an, dass die ePA nicht verpflichtend ist. Und knapp 90 Prozent wissen, dass der Arbeitgeber die in der Akte hinterlegten Daten nicht einsehen darf.
Unzureichende Informationen
Diese Zahlen stützen die Kritik an der Informationspolitik des Gesundheitsministeriums und vieler Krankenkassen. Schon vor dem bundesweiten Roll-out im April hatten Nichtregierungsorganisationen und Patientenschützer:innen deren Vorgehen als intransparent und irreführend gerügt.
Auch die Bundesdatenschutzbeauftragte Louisa Specht-Riemenschneider kritisierte jüngst im Interview mit netzpolitik.org die Informationspolitik der Krankenkassen:
Damit Menschen sich wirklich befähigt fühlen, informierte Entscheidungen zu treffen, muss ich anders informieren als in einem fünfseitigen Brief, den Versicherte bekommen und dann achtlos in den Müll schmeißen, weil sie denken, das es eine weitere Beitragsanpassung ist.
Laut der Datenbarometer-Befragung haben rund 70 Prozent der Befragten das Informationsschreiben der Krankenkassen zur ePA ganz oder teilweise gelesen; jede*r Zehnte sagt, den Brief nicht erhalten zu haben.
Insgesamt sei „viel zu spät und mit viel zu geringer Priorität informiert“ worden, sagt Louisa Specht-Riemenschneider. Eine Informationskampagne zur ePA unter dem Motto „ePA? Na sicher!“ startete das Bundesgesundheitsministerium Anfang Dezember.
Versicherte wünschen sich mehr Einstellungsmöglichkeiten
Insgesamt wollen 42 Prozent der Befragten die ePA in den kommenden sechs Monaten aktiv nutzen. Gleichzeitig gaben mehr als vier Fünftel (83 Prozent) von ihnen an, sich umfangreichere Einstellungsmöglichkeiten in der digitalen Patientenakte zu wünschen. Diese Einstellungen können unter anderem steuern, wer Befunde oder verschriebene Medikamenten einsehen darf.
Zugleich ist die Bereitschaft unter den Befragten, ihre Gesundheitsdaten weiterzugeben, relativ hoch: Mehr als zwei Drittel der Befragten würde demnach wichtige medizinische Unterlagen mit behandelnden Ärzt:innen teilen. Genauso viele von ihnen wären dazu bereit, pseudonymisierte Daten zu wissenschaftlichen Zwecken bereitzustellen.
Die Bundesdatenschutzbeauftragte sieht hier einen Zusammenhang. „Die Funktionen und Einstellungsmöglichkeiten bei der ePA müssen für alle verständlich und nachvollziehbar sein“, so Louisa Specht-Riemenschneider. „Das ist die Grundvoraussetzung für einen selbstbestimmten Umgang mit den eigenen Gesundheitsdaten, den sich die Menschen wünschen.“
Ein Weihnachtswunder der internationalen Digitalpolitik
Eine Woche vor Heiligabend hat die UN-Generalversammlung in New York City einen Konsens zur Zukunft der Internet Governance und der internationalen Digitalpolitik gefunden. Dabei stand viel auf dem Spiel. Denn die sogenannte WSIS+20-Resolution entscheidet nicht nur über die Zukunft des Internet Governance Forums (IGF), sondern darüber, wer künftig Macht über das Internet ausübt. Das sorgte für Zündstoff. Auch wenn die Aufmerksamkeit nur in dieser Woche auf der Resolution lag, waren Stakeholder aus der ganzen Welt schon das ganze Jahr mit dem Prozess beschäftigt.
Dabei zeichneten sich viele Spannungsfelder ab. Eines davon: Welche Rolle sollen Akteure aus der Zivilgesellschaft künftig spielen? Zwanzig Jahre nach dem Weltgipfel zur Informationsgesellschaft in Genf und Tunis (World Summits on the Information Society 2003/2005) stand nicht weniger auf dem Spiel als die Frage, wie das Internet künftig gestaltet wird.
Aus Sicht der digitalen Zivilgesellschaft war dabei besonders wichtig: Welche Zukunft hat das Internet Governance Forum? Und wie wird es künftig gestaltet? Denn das IGF ist einer der letzten Orte, an dem Zivilgesellschaft, Wissenschaft, Wirtschaft, Jugend, technische Community, Politik und Verwaltung gemeinsam über die Zukunft des Internets beraten. Für die digitale Zivilgesellschaft ist es eines der wenigen globalen Foren, in denen ihre Perspektiven institutionell verankert sind und tatsächlich Einfluss entfalten können.
Offenheit des Internets steht auf dem Spiel
Am Vortag der Abstimmung hat Karsten Wildberger, Bundesminister für Digitales und Staatsmodernisierung, eine Rede gehalten. “Wir sind hier, um unser Engagement für das freie, offene und interoperable globale Internet zu bekräftigen. Seine größte Stärke ist die Offenheit.”
Diese Worte sind ein wichtiges Signal für die Prinzipien, für die sich die digitale Zivilgesellschaft einsetzt. Fast noch wichtiger: Die Bundesregierung will Worten auch Taten folgen lassen. Wildberger kündigte an, dass eine Million Euro aus dem Bundeshaushalt an das globale IGF gehen werden.
Der Hauptstreitpunkt im Prozess war die Zukunft des globalen IGF. In diesem kurzen Zeitfenster ist es gelungen, dass Staaten wie die Ukraine und Russland einen Konsens darüber finden konnten, wie es mit dem Internet weitergeht. Sie haben sich sogar darauf verständigt, das IGF als permanentes Forum der Vereinten Nationen zu etablieren. Dass sich am Ende eine breite Unterstützung für eine Verstetigung des IGF abgezeichnet hat, ist zwar eine wichtige Errungenschaft. Das Ergebnis ist jedoch ambivalent.
Die Diskussionen über neue, primär staatlich geprägte Formate im IGF zeigen, wie brüchig der Konsens für das Multistakeholder-Modell geworden ist. Ein starkes IGF braucht keine geschlossenen Räume, in denen ausschließlich staatliche Akteure verhandeln. Es braucht bessere Modalitäten, eine nachhaltige Finanzierung und eine klare Anerkennung der Relevanz aller Stakeholder-Gruppen als gleichwertige Teilnehmende. Der erzielte Konsens darf nicht darüber hinwegtäuschen, wie umkämpft der Prozess war.
Der Konflikt kulminierte schließlich in Absatz 101 der WSIS+20-Resolution, der eine stärkere Rolle von Regierungen im IGF vorsieht. Das war ein Anliegen der „Gruppe der 77“, in der sich Länder der globalen Mehrheitsgesellschaft zusammengeschlossen haben, dem die EU mit ihrem Festhalten am Multistakeholder-Ansatz entgegen trat. Die Bundesregierung hat sich im Einklang mit den NETmundial+10-Prinzipien kontinuierlich für die Beteiligung von Stakeholder-Gruppen im internationalen Kontext bemüht.
Dabei besteht jedoch durchaus eine Doppelmoral. Denn auf nationaler Ebene verfolgt die Regierung diesen Anspruch nicht so konsequent. Beim Beteiligungsverfahren zum Deutschland-Stack etwa wurde die Zivilgesellschaft erst nach freundlichen Hinweisen neben Wirtschaftsverbänden als Zielgruppe für Workshops aufgeführt. Auch beim deutsch-französischen Gipfel zur digitalen Souveränität im November in Berlin spielte die digitale Zivilgesellschaft eine Nebenrolle.
Der Weg zur Resolution
Sophia Longwe ist Projektmanagerin Politik bei Wikimedia Deutschland e. V. und arbeitet an internationaler Digitalpolitik, digitaler Infrastruktur und gemeinwohlorientierter Datenpolitik. Sie studierte Global Studies und Public Policy in Maastricht, Berlin und Austin. – CC-BY-SA 2.0 Wikimedia
Um zu verstehen, wie viel umfangreicher die digitale Zivilgesellschaft in die internationale Digitalpolitik eingebunden ist – im Vergleich zur nationalen und europäischen Ebene –, lohnt sich ein Rückblick auf die zahlreichen Beteiligungsmöglichkeiten bei der Vorbereitung der Verhandlungen zur WSIS+20-Resolution.
In Deutschland begann dies mit einer vom Bundesministerium für Digitales und Verkehr (BMDV) organisierten virtuellen Stakeholder-Konsultation im März 2025, die dort als Prozess für “Feinschmecker” bezeichnet wurde. Bereits im April und Mai fand eine umfangreiche Veranstaltungsreihe zum WSIS+20-Prozess statt, organisiert von zivilgesellschaftlichen Organisationen, an der nun auch das neu geschaffene Bundesministerium für Digitales und Staatsmodernisierung (BMDS) teilnahm.
Hinzu kam ein offenes Konsultationsverfahren der Ko-Fazilitatoren aus Albanien und Kenia, die den UN-Verhandlungsprozess leiteten – wenngleich das Verfahren daraus bestand, dass die Beteiligten drei Minuten ein Statement verlesen konnten, dem meist nur Gleichgesinnte zuhörten.
Zudem setzte sich die EU für die Einrichtung eines Informellen Multistakeholder Sounding Boards ein, welches auch eigene Konsultationen ausgerichtet und kontinuierlich Feedback gegeben hat. Anknüpfend daran konnte die Position der Bundesregierung, die als Gruppe über die EU verhandelt wurde, beeinflusst werden. Informiert bleiben konnte man über die regelmäßigen Updates des BMDS über eine Community-Mailing-Liste.
Uns fehlen dieses Jahr noch 173.723 Euro.
Bist Du auch Feuer und Flamme für Grundrechte? Dann unterstütze jetzt unsere Arbeit mit einer Spende.
Bist Du auch Feuer und Flamme für Grundrechte? Dann unterstütze jetzt unsere Arbeit mit einer Spende.
Wie es weitergehen sollte
Für den deutschen Kontext bedeutet WSIS+20 vor allem eines: Der Multistakeholder-Ansatz muss auch national konsequent umgesetzt werden. Andernfalls droht der Ansatz zu einem reinen außenpolitischen Lippenbekenntnis zu verkommen. Die über 170 nationalen, regionalen und Jugend-Internet-Governance-Foren und Initiativen (NRIs), die nun auch in der Resolution hervorgehoben werden, spielen dabei eine Schlüsselrolle.
NRIs sind Orte, an denen globale Aushandlungsprozesse übersetzt, diskutiert und weiterentwickelt werden können, um in nationale und regionale Gesetzgebungsverfahren einzufließen. Die Voraussetzung dafür ist allerdings, dass sie ausreichend finanziell und personell ausgestattet und offen gestaltet sind.
Positiv hervorzuheben ist die signifikante Unterstützung des globalen IGFs durch das BMDS. Gleichzeitig zeigt sich, dass Beteiligung weiterhin zu oft projektbezogen und situativ erfolgt. Gerade vor dem Hintergrund der fehlenden Einbeziehung in Diskussionen rund um digitale Souveränität und Verwaltungsdigitalisierung ist es bedeutsam, zivilgesellschaftliche Expertise frühzeitig und strukturell in alle Bereiche einzubinden.
Das Internet Governance Forum Deutschland steht bislang auf einer fragilen Grundlage. Um seiner Rolle gerecht zu werden, braucht es eine stärkere institutionelle Verankerung, verlässliche Finanzierung und eine klare politische Anerkennung als zentraler Ort für Internet Governance in Deutschland. Nur so kann es langfristig dazu beitragen, internationale Prozesse wie WSIS und den Global Digital Compact mit nationalen Diskursen zu verzahnen.
Außerdem fehlen Räume, in denen in Deutschland über das Domain Name System und kritische Internetressourcen gesprochen wird, für die Internet Corporation for Assigned Names and Numbers (ICANN) und Regional Internet Registries (RIRs) zuständig sind. Auch Diskussionen über die grundlegende Arbeit der Internet Engineering Task Force oder des World Wide Web Consortiums (W3C) fallen zu oft hinten runter. Dort sucht man oft vergeblich nach zivilgesellschaftlicher Expertise. Genau darin besteht die Stärke des IGFs. Es führt all diese Stränge, Gremien und Prozesse zusammen und schafft Räume für Themen der Internet Governance.
Dementsprechend ist die WSIS+20-Resolution kein Endpunkt, sondern lenkt notwendige Aufmerksamkeit auf internationale Digitalpolitik. Die entscheidenden Weichenstellungen stehen noch bevor: bei der Reform des IGF und der anstehenden Diskussion über dessen Modalitäten, bei der weiteren Umsetzung des Global Digital Compacts und bei der Verankerung digitaler Zusammenarbeit in den Nachhaltigkeitszielen (Sustainable Development Goals). In den kommenden Jahren wird sich entscheiden, ob Multistakeholder-Governance weiter ausgehöhlt oder nachhaltig gestärkt wird.
Eines bleibt dabei klar: Ohne Zivilgesellschaft am Verhandlungstisch gibt es keine legitime und zukunftsfähige Digitalpolitik – weder in New York noch in Berlin.