🧠Editorial
Abhängigkeiten sind bequem. Bis sie wehtun.
AWS Bahrain zeigt gerade, dass Multi-AZ kein Backup ersetzt. Angreifer umgehen Passkeys über die schwächeren Prozesse daneben. Und ausgerechnet Google, OpenAI und Anthropic diskutieren darüber, sich bei KI-Sicherheit gegenseitig zu kontrollieren.
Der gemeinsame Nenner: Digitale Souveränität zeigt sich nicht im Normalbetrieb, sondern wenn etwas ausfällt, gesperrt wird oder plötzlich alternativlos erscheint.
Dazu gibt es einen konkreten VMware-Exit, unsere Cloudflare-Alternative aus Deutschland und Neues aus Kubernetes v1.37.
Viel Spaß beim Weekly Backlog.
📰 Tech-News:
AWS Bahrain: Kein Backup, kein Mitleid
Im Krieg mit dem Iran wurde die AWS-Region in Bahrain schwer beschädigt. Mehrere Availability Zones sind betroffen. AWS erklärt inzwischen, dass Daten und Ressourcen, die ausschließlich in Bahrain gespeichert waren, nicht wiederhergestellt werden können.
Die Daten sind weg.
Aber keine Sorge: Sie waren redundant.
Zumindest so lange, bis ein Ereignis eintrat, das größer war als die eingeplante Failure Domain.
Souverän ist, wer seine Daten auch dann noch besitzt, wenn ein Rechenzentrum, eine Region oder ein kompletter Provider ausfällt.
Wer Original und Redundanz innerhalb derselben Failure Domain betreibt, hat Hochverfügbarkeit gebaut. Keine Unabhängigkeit.
AWS hatte nach den ersten Angriffen sogar empfohlen, Workloads in andere Regionen zu verschieben. Kunden mit Backups oder Kopien außerhalb Bahrains konnten wiederherstellen.
Es lag also nicht an geheimem Hyperscaler-Wissen.
Man musste lediglich auf die geradezu revolutionäre Idee kommen, ein Backup dort aufzubewahren, wo nicht auch das Original zerstört wird.
Multi-AZ ist nicht Multi-Region. Multi-Region ist nicht Multi-Provider. Und ein Cloud-Anbieter ist kein Ersatz für eine Backup-Strategie.
Wer über digitale Souveränität spricht, muss deshalb auch über Redundanz, geografische Trennung und Provider-Unabhängigkeit sprechen.
Alles andere ist Abhängigkeit mit SLA.
Kein Backup, kein Mitleid.
🔗 https://www.heise.de/news/Iran-Krieg-Alle-AWS-Daten-in-Bahrain-sind-zerstoert-11454487.html
Passkey-Phishing: Angreifer umgehen phishing-resistente Anmeldung
Passkeys gelten als phishing-resistente Alternative zu Passwörtern und klassischen MFA-Verfahren. Aktuelle Angriffe zeigen jedoch, dass damit nicht automatisch der gesamte Anmeldeprozess gegen Phishing geschützt ist.
Wie The Hacker News unter Berufung auf Microsoft berichtet, setzen Angreifer auf Social Engineering, um bestehende Sicherheitsmechanismen zu umgehen. Dabei wird nicht der Passkey selbst kompromittiert. Stattdessen versuchen die Angreifer, Nutzer auf alternative Authentifizierungswege zu lenken oder legitime Anmelde- und Autorisierungsprozesse für die Kontoübernahme zu missbrauchen.
Teil der beobachteten Kampagnen sind gefälschte IT-Support-Anrufe und nachgebildete Microsoft-Seiten. In bestimmten Fällen werden legitime Device-Code-Abläufe eingesetzt. Nach erfolgreicher Kompromittierung können Angreifer zusätzliche Authentifizierungsmethoden registrieren und auf Dienste und Unternehmensdaten in Microsoft 365 zugreifen.
Der entscheidende Unterschied: Die kryptografischen Eigenschaften von Passkeys werden dabei nicht gebrochen. Angegriffen werden die Prozesse, die parallel zur eigentlichen Passkey-Authentifizierung bestehen.
Damit rücken insbesondere alternative Anmeldeverfahren, die Registrierung neuer Authentifizierungsmethoden, Account-Recovery und Helpdesk-Prozesse in den Fokus.
Für Unternehmen bedeutet das: Die Einführung von Passkeys ist ein wichtiger Schritt, reicht allein aber nicht aus. Phishing-resistente Authentifizierung muss über den gesamten Identity-Lifecycle hinweg umgesetzt werden. Bleiben schwächere Alternativen verfügbar, können sie weiterhin zum Angriffspunkt werden.
Der aktuelle Fall zeigt damit weniger eine Schwäche von Passkeys als eine grundsätzliche Herausforderung moderner Identity-Systeme: Entscheidend ist nicht nur die Sicherheit der stärksten Authentifizierungsmethode, sondern auch die der verbleibenden Ausweichwege.
🔗https://thehackernews.com/2026/09/attackers-use-passkey-phishing-to.html
Huthi sollen Claude für die Entwicklung von Raketensoftware eingesetzt haben
Eine mutmaßlich mit den Huthi verbundene Gruppe im Jemen soll die KI Claude für die Entwicklung von Software für Raketensysteme eingesetzt haben. Das berichtet Golem unter Berufung auf einen aktuellen Threat-Intelligence-Bericht von Anthropic.
Nach Angaben des KI-Unternehmens arbeitete die Gruppe an drei Waffenprogrammen. Dazu gehörten eine mehrstufige ballistische Rakete und eine gelenkte Rakete.
Claude Code soll unter anderem beim Schreiben von Steuerungs-, Navigations- und Kontrollsoftware eingesetzt worden sein. Zudem nutzten die Akteure das System laut Anthropic zur Integration eines Open-Source-Autopiloten, zur Optimierung von Parametern, zur Erstellung von Firmware und für Flugsimulationen.
Dabei kamen mehrere Claude-Instanzen parallel zum Einsatz. Die Aufgaben wurden auf verschiedene Sitzungen verteilt, etwa für Programmierung, Recherche und die Überprüfung von Code.
Anthropics Schutzmechanismen blockierten nach Angaben des Unternehmens einen Teil der Anfragen. Die Akteure sollen jedoch versucht haben, den eigentlichen Verwendungszweck zu verschleiern und ihre Arbeit auf mehrere Sitzungen zu verteilen.
Für die erfolgreiche Entwicklung eines einsatzfähigen Waffensystems gibt es bislang keinen Beleg. Laut Anthropic wurde eine gelenkte Rakete bei einem Feldversuch getestet, der offenbar scheiterte. Anschließend soll Claude auch für die Analyse möglicher Fehler genutzt worden sein.
Anthropic sperrte die betreffenden Accounts und erklärte, zusätzliche Schutzmaßnahmen eingeführt zu haben.
Google, OpenAI und Anthropic wollen sich bei KI-Sicherheit gegenseitig kontrollieren
Google, OpenAI und Anthropic sprechen offenbar seit Juli darüber, eine gemeinsame Organisation zu gründen, die Sicherheitsstandards für die Entwicklung von KI überwachen soll.
Das berichtet heise unter Berufung auf The Information. Bemerkenswert ist weniger, dass diese Gespräche stattfinden. Bemerkenswert ist, wer hier mit wem über Kontrolle spricht.
Google, OpenAI und Anthropic gehören zu den Unternehmen, die sich derzeit eines der teuersten und aggressivsten technologischen Wettrennen liefern. Entwicklungszyklen werden verkürzt, Milliarden in Rechenleistung investiert und neue Modelle in immer kürzeren Abständen veröffentlicht. Sicherheit konkurriert dabei zwangsläufig mit Geschwindigkeit – und Geschwindigkeit ist ein erheblicher Wettbewerbsvorteil.
Nun sollen ausgerechnet interne Gespräche zwischen diesen Unternehmen die Grundlage für eine Organisation schaffen, die Sicherheitsstandards überwacht.
Parallel dazu mehren sich die Warnsignale aus der Branche selbst. Ein Anthropic-Mitarbeiter verließ das Unternehmen vergangene Woche und warf ihm öffentlich vor, Sicherheitsaspekte nicht ausreichend zu berücksichtigen. CEO Dario Amodei fordert inzwischen eine temporäre Verlangsamung der KI-Entwicklung, um bei der Sicherheit aufzuholen. Auch Sam Altman soll bei OpenAI intern bereits über eine Drosselung des Entwicklungstempos nachgedacht haben.
Wenn selbst die Verantwortlichen der führenden KI-Unternehmen feststellen, dass das Entwicklungstempo die Fähigkeit zur Absicherung überholt, ist das keine abstrakte Debatte über zukünftige Risiken mehr. Es ist eine Aussage über den gegenwärtigen Zustand dieser Industrie.
Eine staatliche Kontrollorganisation war laut heise in den USA bereits vorgesehen, scheiterte unter der Trump-Regierung jedoch offenbar an mangelnder Unterstützung. Meta soll sich gegenüber Trump zudem kritisch zu einer nationalen Kontrollbehörde geäußert haben.
An ihre Stelle könnten nun Strukturen treten, an deren Ausgestaltung diejenigen maßgeblich beteiligt sind, die kontrolliert werden sollen.
Man kann das Kooperation nennen. Man kann darauf vertrauen, dass Unternehmen im direkten Wettbewerb miteinander freiwillig Regeln entwickeln, die im Zweifel das eigene Entwicklungstempo begrenzen.
Selbstregulierung hat schließlich schon immer hervorragend funktioniert.
Dass Google, OpenAI und Anthropic miteinander über Sicherheit sprechen, ist sinnvoll. Dass solche internen Gespräche als Antwort auf ein strukturelles Kontrollproblem ausreichen könnten, ist es nicht.
Wer verbindliche Sicherheitsstandards für eine Technologie will, deren Entwickler selbst vor dem eigenen Entwicklungstempo warnen, braucht unabhängige Kontrolle – nicht nur einen größeren Konferenztisch.
🗣️Gastbeitrag:
Raus aus der Lizenzfalle: Wie ein führender Mittelständler den souveränen #VMwareExit meisterte.
Ein Gastbeitrag von Tobias Link (NMMN)
Vom Lizenz-Schock zur digitalen Souveränität: Der VMware-Exit im gehobenen Mittelstand
Der Markt bebt. Seit den massiven Umstrukturierungen und Preisexplosionen bei VMware (Broadcom) fragen sich IT-Verantwortliche in mittelständischen und Großunternehmen gleichermaßen: Wie entkommen wir dem Vendor-Lock-in, ohne unsere geschäftskritische Infrastruktur zu gefährden?
Dass dieser Schritt nicht nur ein Befreiungsschlag aus der Lizenzfalle ist, sondern gleichzeitig ein gewaltiger Sprung nach vorne bei IT-Sicherheit, Performance und Wirtschaftlichkeit sein kann, zeigt ein aktuelles Kundenprojekt der NMMN für ein etabliertes Handelsunternehmen aus dem norddeutschen Raum.
Die Ausgangslage: On-Premise-Serverraum trifft auf Lizenz-Willkür
Bislang betrieb das Unternehmen seine IT-Landschaft auf einem lokalen VMware-Cluster mit eigener Hardware am Firmenhauptsitz. Die Herausforderungen entsprachen dem Klassiker im deutschen Mittelstand:
- Infrastruktur-Grenzen: Hausinterne Serverräume können physische Schutzmechanismen (wie automatisierte Gaslöschanlagen, biometrische Zutrittsschleusen, zertifizierten BSI-Grundschutz oder 2N+1 USV-Konzepte) wirtschaftlich kaum noch abbilden.
- Kosten-Explosion: Die angekündigten Modellumstellungen und drastischen Preissteigerungen im VMware-Ökosystem bedrohten die Budgetplanbarkeit massiv.
Der Plan: Managed Private Cloud mit Proxmox VE
Gemeinsam mit der NMMN entschied sich die IT-Führung für einen konsequenten Paradigmenwechsel. Statt nur die Software zu wechseln, wurde die gesamte Infrastruktur auf ein neues Level gehoben: Ein Umzug in die NMMN Managed Private Cloud - gehosted über mindestens 3 Knoten in hochsicheren, zertifizierten Rechenzentren in Deutschland – angetrieben von der Open-Source-Alternative Proxmox VE. Als physische Basis hierfür dient das NMMN City-Netz unser eigenes High-Speed-Fundament, auf dem moderne Cloud-Services absolut ausfallsicher hochgezogen und geclustert werden können.
Warum dieser Schritt strategisch so wertvoll ist:
- Digitale Souveränität & Budget-Sicherheit:
Proxmox VE basiert auf bewährten Open-Source-Standards (KVM/LXC). Statt Lizenz-Willkür ausgesetzt zu sein, profitiert das Unternehmen von planbaren, support-basierten Subskriptionen. Sogar teure Zusatzlizenzen für Backup-Lösungen entfallen durch die native Integration des Proxmox Backup Servers (PBS). - Die "Nabelschnur" ins Rechenzentrum (LAN-Performance):
Durch eine dedizierte Standleitung vom Firmensitz zum Rechenzentrum fühlt sich die externe Infrastruktur für die Anwender wie das lokale LAN an – bei zeitgleicher Nutzung maximaler physischer Sicherheit (ISO 27001, BSI-IT Grundschutz, EN 50600 Level 3, PUE < 1,3 etc.). - Ganzheitliche TCO-Optimierung:
In der Gesamtkostenbetrachtung schlägt der Wechsel voll zu Buche: Eigenes Facility Management, lokale Wartungsverträge für Kühlung/USV, hohe Versicherungsprämien und interne IT-Personalkapazitäten werden drastisch reduziert. Die IT-Abteilung kann sich endlich wieder auf wertschöpfende Kernprojekte konzentrieren.
Geräuschlose Migration: Die Roadmap in der Praxis
Ein Infrastrukturwechsel im laufenden Betrieb erfordert höchste Präzision. Die NMMN-Experten steuerten die Migration über einen strukturierten Phasenplan:
- Phase 1 (Infrastruktur): Bereitstellung der dedizierten Compute-Nodes im RZ und Schaltung der redundanten Standleitung zum Firmensitz.
- Phase 2 (Setup): Inbetriebnahme des hochverfügbaren Proxmox HA-Clusters inklusive Ceph-Storage und automatisierter Sicherungsumgebung.
- Phase 3 (Migration): Schrittweise, unterbrechungsfreie Überführung der bestehenden VMs von der VMware-Umgebung auf die Proxmox-Plattform via Layer-2-Kopplung.
- Phase 4 (Managed Service): Übergabe in den dauerhaften NMMN Managed Service: Private-Cloud-Betrieb bis Hypervisor-Oberkante, Routing, 24/7-Monitoring, Patch-Management und Support.
Fazit
Der VMware-Exit ist weit mehr als eine Reaktion auf steigende Software-Kosten – er ist eine strategische Weichenstellung. Unternehmen aus dem gehobenen Mittelstand beweisen damit, wie man aus einem Marktdruck gestärkt hervorgeht: Mit voller Kontrolle über die eigene Roadmap, modernster High-Availability-Architektur und kalkulierbarer Kostenstruktur. Auch beim Auditierungsprozess steht das Unternehmen nicht mehr alleine da, sondern hat ein Expertenteam und direkte persönliche Ansprechpartner, die 24/7 telefonisch erreichbar sind.
📰 Short News:
1. Nvidia, Palantir und Cisco bauen KI-Stack für Behörden
Gemeinsame KI-Referenzarchitektur für sensible Regierungsdaten erhöht staatliche Kontroll- und Beschaffungsabhängigkeiten von Hyperscalern.
🔗 https://www.heise.de/news/Nvidia-Palantir-und-Cisco-bauen-KI-Stack-fuer-Behoerden-11453448.html
2. Cloud-Wettbewerb: Broadcom ist weiter auf Rot, SAP gerät wegen KI unter Druck
Wettbewerbsbarometer warnt vor Lizenzpraktiken und API-Sperren, stärkt europäische Alternativen und Plattformsouveränität.
3. Softwareprojekte in Gefahr: BSI warnt vor laufenden Angriffen auf Gitlab
Selbst gehostete Code-Infrastruktur riskiert Zugangsdaten; betont Abhängigkeiten von Open-Source-Tools und souveräne Governance.
4. Österreich: Alterskontrollen im Netz als Doppelblindverfahren
==Österreich setzt Doppelblindverfahren bei Alterskontrollen im Netz ein; kryptografische Lösung schützt Datenteilung zwischen Identitätsanbietern und Plattformen. Regulatorischer Weg zu mehr Datenschutz und Souveränität.==
💚In eigener Sache:
Cloudflare-Alternative aus Deutschland – ab 49,95 € im Monat
Cloudflare ist für viele Unternehmen fast schon der Standard, wenn Anwendungen zuverlässig erreichbar sein, Traffic verteilt und der Ingress geschützt werden soll.
Aber Standard heißt nicht alternativlos.
Mit unserer ayedo Edge Cloud bieten wir genau für diesen Bereich eine Alternative aus Deutschland: eine hochverfügbare Edge-Proxy- und DNS-Infrastruktur für Anwendungen, die zuverlässig erreichbar bleiben sollen – unabhängig davon, ob die eigentlichen Workloads bei ayedo, bei einem anderen Provider oder On-Premises laufen.
Los geht es ab 49,95 € im Monat.
Im Kern übernimmt die Edge Cloud drei Aufgaben: DNS, Loadbalancing und Schutz am Ingress. Traffic und DNS werden über mehrere Standorte bereitgestellt. Fällt ein Point of Presence aus, kann ein anderer übernehmen. Anfragen werden dabei zum nächstgelegenen Edge-Standort geleitet, um Latenzen niedrig und die Verbindung zu den Backends stabil zu halten.
Dazu kommt Anycast DNS mit Multi-Region-Betrieb und API-Anbindung für Infrastructure as Code, CI/CD und GitOps.
Für das Loadbalancing setzen wir ebenfalls auf Anycast. Layer-4-Verbindungen werden über mehrere PoPs auf die jeweiligen Backends verteilt. Endpoint Monitoring ist integriert, eigene IP-Präfixe lassen sich per Bring Your Own IP einbinden.
Für HTTP(S)-Workloads ergänzt eine Web Application Firewall den Schutz am Edge. Regeln und Schutzmechanismen greifen damit bereits, bevor der Traffic das eigentliche Cluster erreicht.
Ein Punkt ist uns dabei besonders wichtig: Edge und Compute sind bewusst voneinander entkoppelt. Niemand muss seine Workloads in unsere Compute Cloud verschieben, um die Edge Cloud nutzen zu können. Das Backend kann an einem anderen Standort, bei einem anderen Provider oder im eigenen Rechenzentrum laufen.
Und genau hier unterscheidet sich unser Ansatz auch strategisch von den großen US-Plattformen.
Die Edge-Infrastruktur wird von ayedo in der EU betrieben. Routing, DNS-Zonen und Traffic-Pfade bleiben damit unter europäischer Kontrolle. ayedo selbst sitzt in Deutschland und weist die Edge Cloud als DSGVO-konform sowie ISO-27001- und ISO-9001-zertifiziert aus.
Cloudflare hat Edge-Infrastruktur extrem einfach nutzbar gemacht. Wir finden: Dafür sollte man sich nicht zwangsläufig von einem US-Hyperscaler abhängig machen müssen.
Unsere Alternative beginnt bei 49,95 € im Monat. Made in Germany, betrieben in der EU und gebaut für eine souveränere Cloud-Infrastruktur.
🔗
☸️Kubernetes-Updates:
Kubernetes v1.37: Memory QoS erreicht Beta
Mit Kubernetes v1.37 erreicht Memory QoS den Beta-Status und ist im kubelet standardmäßig aktiviert. Das Feature wurde bereits mit Kubernetes v1.22 als Alpha eingeführt und in v1.36 um eine abgestufte Speicherreservierung erweitert.
Für bestehende Cluster bedeutet die Aktivierung allerdings nicht, dass sich das Speicherverhalten nach einem Upgrade automatisch ändert. In der Standardkonfiguration setzt der kubelet weder memory.high noch memory.min oder memory.low. Memory Throttling und Memory Reservation müssen weiterhin explizit konfiguriert werden.
Eine wichtige Änderung betrifft memoryThrottlingFactor. In früheren Alpha-Versionen lag der Standardwert bei 0.9. Dadurch führte die Aktivierung von Memory QoS dazu, dass der kubelet über memory.high den Speicherverbrauch von Containern begrenzte. Mit v1.37 steht der Wert standardmäßig auf null. Damit soll verhindert werden, dass bislang ungedrosselte Workloads allein durch das Upgrade auf v1.37 plötzlich einem Memory Throttling unterliegen. Bereits explizit konfigurierte Werte bleiben beim Upgrade erhalten.
Wer Throttling nutzen möchte, kann memoryThrottlingFactor weiterhin mit einem Wert zwischen 0 und 1 konfigurieren. Für eine abgestufte Speicherreservierung steht zusätzlich memoryReservationPolicy: TieredReservation zur Verfügung. Dabei erhalten Guaranteed Pods eine Absicherung über memory.min, während für Burstable Pods memory.low verwendet wird. Beide Mechanismen lassen sich gemeinsam oder unabhängig voneinander aktivieren.
Eine Einschränkung bleibt: Die Reservation Policy gilt immer für den gesamten Node. Einzelne Pods können derzeit nicht gezielt ein- oder ausgeschlossen werden. Zudem umfasst die Reservierung sämtliche dem cgroup eines Containers zugerechneten Speicherbereiche, einschließlich des Page Cache. Gerade bei Nodes mit unterschiedlichen Workload-Anforderungen kann das relevant werden.
Nach dem Beta-Status ist für Memory QoS als nächster Entwicklungsschritt die Graduierung zu General Availability vorgesehen. Erfahrungen aus dem Beta-Einsatz sollen in die verbleibenden Anpassungen einfließen.
🔗https://kubernetes.io/blog/2026/09/14/kubernetes-v1-37-memory-qos-graduates-to-beta/
😄Meme der Woche:
