Datenschutz & Sicherheit
AWS-Ausfall: Amazon legt vollständigen Ursachenbericht vor
Der Ausfall von Amazons AWS-Cloud-Diensten am Montag dieser Woche bereitete nicht nur IT-Experten schlaflose Nächte, sondern etwa auch Besitzern von vernetzten Matratzen. Nun haben Amazons Techniker eine vollständige Analyse der Vorfälle veröffentlicht, die erklärt, wie es zu so weitreichenden Störungen kommen konnte.
Weiterlesen nach der Anzeige
Bereits der Titel der Amazon-Analyse weist auf einen Single-Point-of-Failure: „Zusammenfassung der Amazon DynamoDB-Dienst-Störung in der Region Nord Virginia (US-EAST-1)“. Der dort aufgetretene Fehler sorgte nicht nur für Ausfälle von Amazon-Diensten wie Streaming mit Prime oder Amazon Music, sondern legte etwa den Messenger Signal über Stunden lahm. Umso spannender ist, wie es dazu kommen konnte.
AWS-Ausfall: Detaillierter Fehlerverlauf
Während die Techniker bei Wiederherstellung des Normalbetriebs, den Amazon gegen kurz nach Mitternacht zum Dienstag, 21. Oktober, verkündete, bereits eine erste knappe Zusammenfassung des Vorfalls bereitgestellt haben, geht die jetzige Analyse deutlich in die Tiefe. Aus Amazons Sicht hat sich die Fehlerkaskade in drei Etappen abgespielt. Zwischen 8:48 Uhr mitteleuropäischer Sommerzeit am 20. Oktober 2025 und 11:40 Uhr lieferte Amazons DynamoDB erhöhte Fehlerraten bei API-Zugriffen in der Region Nord Virginia (US-EAST-1). Das war laut Amazon die erste Phase der Störung.
Die zweite Phase folgte zwischen 14:30 Uhr und 23:09 Uhr, während der der Network Load Balancer (NLB) erhöhte Verbindungsfehler bei einigen Load Balancern in Nord Virginia aufwies. Dies ging auf Health-Check-Fehler in der NLB-Flotte zurück, die zu diesen erhöhten Verbindungsfehlern führten. Zudem kam die dritte Phase von 11:25 Uhr bis 19:36 Uhr, in der das Starten neuer EC2-Instanzen nicht klappte. Bei einigen der EC2-Instanzen, die ab 19:37 Uhr anliefen, kam es jedoch zu Verbindungsproblemen, die ihrerseits bis 22:50 Uhr andauerten.
DynamoDB-Fehler
Die Probleme mit der DynamoDB erklärt Amazon mit „einem latenten Defekt“ im automatischen DNS-Management, wodurch die Namensauflösung der Endpunkte für die DynamoDB fehlschlug. „Viele der größten AWS-Dienste stützen sich in hohem Ausmaß auf DNS, um nahtlose Skalierbarkeit, Fehlerisolierung und -behebung, geringe Latenz und Lokalität zu gewährleisten. Dienste wie DynamoDB verwalten Hunderttausende von DNS-Einträgen, um eine sehr große heterogene Flotte von Load Balancern in jeder Region zu betreiben“, schreiben die Techniker. Automatisierung ist nötig, um zusätzliche Kapazitäten hinzuzufügen, sofern sie verfügbar sind, und um etwa korrekt mit Hardwarefehlern umzugehen. Zwar sei das System auf Resilienz ausgelegt, jedoch war die Ursache für die Probleme eine latente Race-Condition im DynamoDB-DNS-Management-System, die in einen leeren Eintrag für den regionalen Endpunkt „dynamodb.us-east-1.amazonaws.com“ mündete. Interessierte erhalten in der Analyse dazu einen tiefen Einblick in die DNS-Management-Struktur.
Sowohl der eigene als auch der Traffic von Kunden, die auf DynamoDB aufsetzen, war davon betroffen, da diese mangels korrekter Namensauflösung nicht mehr zu der DynamoDB verbinden konnten. Um 9:38 Uhr haben die ITler den Fehler im DNS-Management gefunden. Erste temporäre Gegenmaßnahmen griffen um 10:15 Uhr und ermöglichten die weitere Reparatur, sodass gegen 11:25 Uhr alle DNS-Informationen wiederhergestellt wurden.
Weiterlesen nach der Anzeige
Nicht startende EC2-Instanzen
Die EC2-Instanzen starteten ab 8:48 Uhr nicht mehr, da dieser von sogenannten DropletWorkflow Manager (DWFM) auf verschiedene Server verteilt werden. Die DWFM überwachen den Status der EC2-Instanzen und prüfen, ob etwa Shutdown- oer Reboot-Operationen korrekt verliefen in sogenannten Leases. Diese Prüfungen erfolgen alle paar Minuten. Dieser Prozess hängt jedoch von der DynamoDB ab und konnte aufgrund deren Störung nicht erfolgreich abschließen. Statusänderungen benötigen einen neuen Lease. Die DWFM versuchten, neue Leases zu erstellen, die jedoch zwischen 8:48 Uhr und 11:24 Uhr zunehmend in Time-Outs liefen. Nachdem die DynamoDB wieder erreichbar war, konnten die EC2-Instanzen jedoch mit dem Fehler „insufficient capacity errors“ nicht starten. Das Backlog der ausstehenden Leases erzeugte einen Flaschenhals, sodass neue Anfragen dennoch in Time-Out-Situationen kamen. Gegen 14:28 Uhr konnten die DWFM alle Leases zu allen Droplets genannten Instanzen wieder herstellen, nachdem Neustarts der DWFMs die Warteschlangen geleert hatte. Aufgrund einer temporären Anfragendrosselung, die die IT-Mitarbeiter zur Reduktion der Gesamtlast eingerichtet hatten, kam es jedoch etwa zu Fehlermeldungen der Art „equest limit exceeded“.
Die Droplets/EC2-Instanzen erhalten von einem Network Manager Konfigurationsinformationen, die ihnen die Kommunikation mit anderen Instanzen in der gleichen Virtual Private Cloud (VPC), mit VPC-Appliances und dem Internet erlaubt. Die Verteilung hatte durch die Probleme mit den DWFM ein großes Backlog erzeugt. Ab 15:21 Uhr kam es dadurch zu größeren Latenzen. Zwar starteten neue EC2-Instanzen, sie konnten mangels gültiger Netzwerkkonfigurationen jedoch nicht im Netzwerk kommunizieren. Das haben die ITler gegen 19:36 Uhr in den Griff bekommen, sodass EC2-Starts wieder „normal“ verliefen.
Verbindungsfehler durch Network Load Balancer
Die Network Load Balancer (NLB) von AWS nutzen ein Überwachungssystem (Health-Check-System). Sie umfassen Lastverteilung-Endpoints und verteilen Traffic auf die Backend-Systeme, bei denen es sich typischerweise um EC2-Instanzen handelt. Das Health-Check-System überprüft regelmäßig alle NLB-Knoten und entfernt alle Systeme, die dabei als „ungesund“ auffallen. Die Prüfungen schlugen bei der Störung jedoch zunehmend fehl, da die vom Health-Check-System neu gestarteten EC2-Instanzen keinen Netzwerk-Status melden konnten. Die Prüfungen schlugen in einigen Fällen fehl, obwohl NLB-Knoten und die Backen-Systeme korrekt funktionierten. Die Ergebnisse der Prüfung lieferten abwechselnd korrekten Status und Fehler zurück, wodurch NLB-Knoten und Backend-Systeme aus dem DNS entfernt wurden, um beim nächsten erfolgreichen Durchlauf wieder hinzugefügt zu werden. Das fiel in der Netzwerküberwachung gegen 15:52 Uhr auf.
Die Last im Health-Check-System stieg durch die alternierenden Prüfergebnisse an, wodurch es langsamer wurde und Verzögerungen bei Health-Checks auftraten. Dadurch wurden schließlich Lord-Balance-Kapazitäten reduziert, da diese außer Dienst gestellt wurden. Dadurch kam es zu vermehrten Verbindungsfehlern von Anwendungen, wenn die übriggebliebene noch laufende Kapazität nicht zum Verarbeiten der Anwendungslast ausreichte. Um 18:36 Uhr hat das IT-Team die automatischen Prüfungen für die NLB deaktiviert, wodurch alle verfügbaren, noch in Funktion befindlichen NLB-Knoten und Backend-Systeme wieder in Dienst gestellt werden konnten. Nachdem auch die EC2-Systeme sich erholt hatten, konnten die Health-Checks gegen 23:09 Uhr wieder aktiviert werden.
Im Weiteren erörtert Amazon noch, wie von den gestörten Hauptsystemen abhängige Amazon-Services der zeitliche Störungsverlauf aussah. Das IT-Team will einige Änderungen als Folge der größeren Cloud-Störungen umsetzen. Etwa der DynamoDB „DNS Planner“ und „DNS Enactor“-Automatismus wurde weltweit deaktiviert. Das soll so bleiben, bis unter anderem die aufgetretene Race-Condition gelöst wurde. Die Network Load Balancer sollen eine Geschwindigkeitskontrolle erhalten, die begrenzt, wie viele Kapazitäten ein einzelner NLB nach fehlschlagenden Health-Checks entfernen kann. Für die EC2-Systeme entwickelt Amazon zusätzliche Test-Suites, um etwa den DWFM-Workflow zu analysieren und künftige Regressionen zu vermeiden.
(dmk)
Datenschutz & Sicherheit
Die Woche, in der wir uns über das Scheitern einer Verordnung gefreut haben.
Liebe Leser:innen,
mehr als eine Woche ist es her, dass Friedrich Merz als Antwort auf eine Frage von „diesem Problem“ im „Stadtbild“ sprach. Um dieses – was auch immer genau – zu lösen, wolle Innenminister Dobrindt in großem Stil abschieben. Oder in den Worten von Merz: „Rückführungen“ durchführen.
Ich hätte erwartet, dass die Auslassung von Merz in all den leider alltäglich gewordenen Entgleisungen bis heute längst wieder vergessen ist. Doch immer noch erscheinen täglich Artikel, Kommentare und Nachrichtenbeiträge, die sich auf die „Stadtbild“-Antwort beziehen.
Das ist gut. Es ist gut, dass Menschen demonstrieren und für eine Brandmauer und ein buntes Stadtbild auf die Straße gehen. Es ist gut, dass die rassistische Äußerung eines Bundeskanzlers sich nicht so versendet, als habe der betrunkene, rechte Onkel beim Stammtisch schwadroniert. Es ist gut, dass Menschen wütend werden, wenn er dann noch raunend irgendwelche „Töchter“ vorschiebt, die man fragen solle, wenn man mehr über „das Problem“ wissen will.
Es ist aber auch wichtig, dass wir die Taten der Regierung Merz mindestens mit dem gleichen Maß messen wie ihre Worte. Wenn sie trans Menschen per Verordnung zum lebenslangen Zwangsouting auf Behörden zwingen will – was glücklicherweise momentan der Bundesrat stoppt. Oder wenn das Bürgergeld gestrichen werden soll und Grenzkontrollen von der Ausnahme zur Regel werden.
Das alles offenbart ein Weltbild, das im Gegensatz zu unseren Städten und Dörfern ein echtes Problem ist. Es zeigt eine Angst vor allen, die nicht dem sauerländischen Idealbild entsprechen, das Merz auf Instagram inszeniert. Und es zeigt eine tiefe Unfähigkeit, ein Land zu regieren, das nicht nur aus mittelalten, gut situierten, männlichen Unternehmern im Einfamilienhaus besteht.
Wer mit einem bunten, manchmal dreckigen und lauten, aber niemals langweiligen Stadtbild nicht zurechtkommt, sollte sich fragen, ob Bundeskanzler der richtige Job für ihn ist. Vielleicht hätte er lieber erstmal Erfahrungen als Bürgermeister sammeln sollen. Dann hätte er eines erfahren: Dieses eine Stadtbild, von dem Merz wohl träumt, gibt es nicht. Und wer versucht, all das Bunte in unsren Städten zu verwischen, erntet nichts als Braun.
Ein schönes Wochenende wünscht euch
anna
Wir sind ein spendenfinanziertes Medium
Unterstütze auch Du unsere Arbeit mit einer Spende.
Datenschutz & Sicherheit
WSUS-Lücke: Bereits Attacken beobachtet | heise online
Microsoft hat am Freitagmorgen dieser Woche Notfallpatches außer der Reihe veröffentlicht, die eine kritische Sicherheitslücke in den WSUS-Diensten schließt. IT-Sicherheitsforscher haben erste Angriffe auf die Schwachstelle beobachtet. IT-Verantwortliche sollten spätestens jetzt die Aktualisierung anwenden.
Weiterlesen nach der Anzeige
Der IT-Sicherheitsforscher Kevin Beaumont hat mit der Schwachstelle „herumgespielt“ und kommt zu dem Ergebnis, dass die sich sehr einfach missbrauchen lässt. Es war ofenbar leicht, SChadcode über die Lücke einzuschleusen. Dazu lasse sich zudem auf bereits existierende Forschung aufsetzen, um bösartig manipulierte Update-Pakete mit Schadcode über den kompromittierten WSUS im Netzwerk zu verteilen, schreibt er auf Mastodon.
Angriffe auf Sicherheitslücke beobachtet
Die IT-Forscher von Huntress haben derweil bereits Angriffe auf die WSUS-Sicherheitslücke im Internet beobachtet. Die attackierten WSUS-Dienste haben die TCP-Ports 5830 und 5831 offen im Internet zugänglich gemacht. „Die Angreifer nutzten exponierte WSUS-Endpunkte, um speziell präparierte Anfragen (mehrere POST-Aufrufe an WSUS-Webdienste) zu senden, die eine Deserialisierung-RCE [Remote Code Execution] gegen den Update-Dienst auslösten“, schreiben sie in ihrer Analyse.
Sie erörtern weiter, dass ein Base64-kodiertes Skript in PowerShell dekodiert und ausgeführt wurde. Das Skript durchsucht Server nach sensiblen Netzwerk- und Benutzerinformationen auf und überträgt die Ergebnisse in einen Remote-Webhook. Die Angreifer setzten zudem auf Proxy-Netze, um ihre Angriffe auszuführen und verschleiern, erklären die Huntress-Forscher.
Die Analyse listet noch einige Indizien für Angriffe (Indicators of Compromise, IOCs) auf, anhand derer Admins prüfen können, ob auch die von ihnen betreuten Systeme bereits im Visier von Cyberkriminellen sind. Dazu zählen einige auffällige Einträge in den Weblogs und WSUS-Protokollen zur Softwareverteilung.
Weiterlesen nach der Anzeige
Am Freitagmorgen hat Microsoft die Verteilung der Notfallupdates für die WSUS-Dienste angekündigt. Die konkrete Beschreibung lautet: „Die Deserialisierung nicht vertrauenswürdiger Daten im Windows Server Update Service ermöglicht es einem nicht autorisierten Angreifer, Code über ein Netzwerk auszuführen“ (CVE-2025-59287, CVSS 9.8, Risiko „kritisch„). Die Sicherheitsmeldung dazu von Microsoft wird derzeit häufiger aktualisiert Inzwischen stellt Microsoft auch Stand-alone-Updates etwa für Server bereit, die Hotpatching verwenden. Die benötigen nach Installation jedoch einen Neustart, sofern sie WSUS-Dienste anbieten.
(dmk)
Datenschutz & Sicherheit
Elektronische Patientenakte: Mit Sicherheitsrisiken und Nebenwirkungen
Die meisten von uns besitzen einen Haustürschlüssel. Und die meisten von uns wissen, wer sonst noch Zugang zu unserer Wohnung hat. Bei den Gesundheitsdaten, die in der elektronischen Patientenakte hinterlegt sind, ist das offenkundig nicht so klar. Das zeigen die Antworten der Bundesregierung auf eine Kleine Anfrage der Bundestagsfraktion „Die Linke“.
Die Abgeordneten haben die Regierung unter anderem gefragt, welche Vorkehrungen verhindern sollen, dass etwa die US-Regierung an sensible Gesundheitsdaten von deutschen Versicherten gelangt. Die Antworten der Bundesregierung sind mitunter missverständlich, in Teilen unvollständig und fehlerhaft.
Nachfragen bei dem zuständigen Gesundheitsministerium, verschiedenen Krankenkassen und der Gematik haben nur wenig Licht ins Dunkel gebracht. Offenkundig sollen die Versicherten weitgehend bedingungslos darauf vertrauen, dass ihre sensiblen Daten in der ePA sicher sind.
Krankenkassen verweigern Auskunft
Anlass der Kleinen Anfrage war eine Aussage des Chefjustiziars von Microsoft Frankreich im Juni dieses Jahres. Er hatte in einer öffentlichen Anhörung vor dem französischen Senat nicht ausschließen können, dass der Tech-Konzern Microsoft auf Anordnung US-amerikanischer Behörden auch Daten europäischer Bürger:innen weitergeben müsse.
Hintergrund ist unter anderem der US-amerikanische Clarifying Lawful Overseas Use of Data Act, kurz CLOUD Act, aus dem Jahr 2018. Das Gesetz verpflichtet US-Tech-Anbieter unter bestimmten Voraussetzungen zur Offenlegung von Daten gegenüber US-Behörden – auch wenn sich diese Daten außerhalb der Vereinigten Staaten befinden.
Die Abgeordneten der Linksfraktion fragten die Bundesregierung, ob sie ein ähnliches Szenario bei den in der ePA hinterlegten Gesundheitsdaten ausschließen könne. Die Regierung erwidert, dass sie nichts über die Verträge zwischen den Betreibern der ePA und den Krankenkassen wisse. Sie kenne daher die Regelungen nicht, mit denen die Daten der Versicherten geschützt würden. Betreiber von ePA-Infrastrukturen sind spezialisierte IT-Dienstleister wie IBM Deutschland und das österreichische Unternehmen RISE.
Wir haben uns bei den drei größten gesetzlichen Krankenkassen in Deutschland erkundigt, welche vertraglichen Vereinbarungen sie mit ihren externen Anbietern getroffen haben. Weder die Techniker Krankenkasse noch die Barmer oder die DAK wollten unsere Frage beantworten. Sie verweisen auf die Gematik, die als Nationale Agentur für Digitale Medizin für die Spezifikationen zur technischen Ausgestaltung der ePA zuständig sei. Der Barmer-Sprecher bittet zudem um Verständnis, dass er sich „aus Wettbewerbsgründen“ nicht weiter zu den Vertragsbedingungen äußern könne.
Es ist also unklar, ob es entsprechende Regelungen zum Schutz der Versichertendaten gibt, von denen die Bundesregierung spricht.
Der Schlüssel liegt bei den Betreibern
Desweiteren verweist die Bundesregierung auf „umfangreiche technische und organisatorische Sicherheitsmaßnahmen“, die zum Schutz der Gesundheitsdaten umgesetzt worden seien. So dürften die in der ePA hinterlegten Daten nur verschlüsselt bei den Betreibern gespeichert werden. Ohne „den Schlüssel der Versicherten“ könnten Unbefugte die Daten nicht lesen, betont die Regierung.
Diese Antwort ist mindestens missverständlich formuliert. Tatsächlich verfügt die ePA derzeit über keine patientenindividuelle Verschlüsselung, bei der jede:r Versicherte die eigene Patientenakte mit einem persönlichen Schlüssel absichert. Ältere Versionen der ePA sahen noch eine Ende-zu-Ende-Verschlüsselung der in der Patientenakte hinterlegten Daten vor; die aktuelle „ePA für alle“ bietet dieses Mehr an Sicherheit allerdings nicht mehr.
Außerdem sind die Schlüssel nicht, wie noch bei früheren ePA-Versionen, auf der elektronischen Gesundheitskarte der Versicherten hinterlegt, sondern sie liegen auf den Servern des ePA-Betreibers. Sogenannte Hardware Security Modules in einer „vertrauenswürdigen Ausführungsumgebung“ würden gewährleisten, dass die Betreiber keinen direkten Zugriff auf diese Schlüssel haben, schreibt das Gesundheitsministerium auf Nachfrage von netzpolitik.org.
„Diese speziell abgesicherten Komponenten sind dafür ausgelegt, kryptografische Schlüssel sicher zu verwalten und sensible Daten vor unbefugtem Zugriff zu schützen“, sagt eine Gematik-Sprecherin auf Anfrage. Ein direkter Zugriff auf die Schlüssel, auch durch die Betreiber der ePA, sei technisch ausgeschlossen. Die Schlüssel werden etwa dann zur Entschlüsselung der Gesundheitsdaten verwendet, wenn die Versicherten ihre elektronische Gesundheitskarte beim Besuch einer Praxis oder einer Apotheke in ein Lesegerät schieben.
Offene Eingangstüren
Zwei Aspekte lassen das Gesundheitsministerium und die Gematik bei ihren Ausführungen jedoch unter den Tisch fallen.
Zum einen ist den Sicherheitsfachleuten des Chaos Computer Clubs Bianca Kastl und Martin Tschirsich in den vergangenen Monaten wiederholt gelungen, die Zugriffskontrolle der ePA zu überwinden.
Bei den von ihnen beschriebenen Angriffsszenarien hilft Verschlüsselung nicht mehr viel. „Es ist vollkommen egal, dass das irgendwie verschlüsselt gespeichert wird, wenn an der Eingangstür ein paar Wissensfaktoren reichen, um jede ePA in Zugriff zu bekommen“, sagt Bianca Kastl, die auch Kolumnistin bei netzpolitik.org ist.
Wir sind ein spendenfinanziertes Medium
Unterstütze auch Du unsere Arbeit mit einer Spende.
Die von ihr und Tschirsich aufgezeigten Sicherheitslücken bestehen teilweise noch immer fort. Eine „endgültige technische Lösung“ will das Bundesamt für Sicherheit in der Informationstechnik (BSI) erst im kommenden Jahr implementieren.
Trügerische Sicherheit
Zum anderen behauptet die Bundesregierung, dass die bestehenden Sicherheitsvorkehrungen einen „technischen Betreiberausschluss“ gewährleisten, „sodass selbst ein fremdbestimmter Betreiber keinen Zugriff auf die Daten der ePA erlangen würde“.
Hauptbetreiber von elektronischen Patientenakten ist die IBM Deutschland GmbH. Unter anderem die Techniker Krankenkasse, die Barmer Ersatzkasse und die AOK haben das Unternehmen damit beauftragt, die ePA und die dazugehörigen Aktensysteme gemäß der von der Gematik gemachten Spezifikationen umzusetzen. Mehr als zwei Drittel aller digitalen Patientenakten laufen auf IBM-Systemen, aus Sicherheitsgründen seien die Daten „über zahlreiche, geographisch voneinander getrennte Rechenzentrums-Standorte in der IBM Cloud in Deutschland verteilt“, so das Unternehmen.
Dieses Sicherheitsversprechen ist jedoch trügerisch. Denn die IBM Deutschland GmbH ist eine Tochter der US-amerikanischen IBM Corp. – und damit potenziell ein „fremdbestimmter Betreiber“. Gemäß CLOUD Act können US-Behörden IBM dazu zwingen, die Daten von deutschen Versicherten an sie auszuleiten.
Gefahr erkannt, Gefahr gebannt?
Welche Risiken der CLOUD Act birgt, hat etwa das baden-württembergische Innenministerium erkannt. Im Juli räumte es in einer Stellungnahme ein, dass US-Behörden theoretisch auf Daten zugreifen könnten, die in der Verwaltungscloud Delos gespeichert sind. Delos Cloud ist ein Tochterunternehmen von SAP und fußt auf Microsoft Azure und Microsoft 365. Dem Ministerium zufolge könnten US-Behörden den Tech-Konzern anweisen, „einen Datenabfluss in seine Software zu integrieren, ohne dass der Kunde darüber in Kenntnis gesetzt wird.“
Dennoch plant die Bundesregierung nach eigenem Bekunden nicht, die technologische Abhängigkeit von nicht-europäischen ePA-Betreibern zu prüfen – obwohl sie die digitale Patientenakte explizit als eine kritische Infrastruktur einstuft.
Anne Mieke-Bremer, Sprecherin für Digitale Infrastruktur der Fraktion Die Linke im Bundestag, kritisiert diese Weigerung der Regierung. „Statt klare Prüfpflichten festzuschreiben, versteckt sie sich hinter lückenhaften Vorgaben“, so Mieke-Bremer. „Und sie gibt sich damit zufrieden, dass die Verträge zwischen Betreibern und Kassen eine Blackbox bleiben.“
Die ePA wirke „zunehmend wie ein mangelhaftes und fahrlässiges Prestigeprojekt“, das voller Lücken und Risiken ist, sagt Stella Merendino, Sprecherin der Linken für Digitalisierung im Gesundheitswesen. „Was mit unseren sensibelsten Gesundheitsdaten passiert, bleibt dabei im Dunkeln.“
-
UX/UI & Webdesignvor 2 MonatenDer ultimative Guide für eine unvergessliche Customer Experience
-
UX/UI & Webdesignvor 2 MonatenAdobe Firefly Boards › PAGE online
-
Social Mediavor 2 MonatenRelatable, relevant, viral? Wer heute auf Social Media zum Vorbild wird – und warum das für Marken (k)eine gute Nachricht ist
-
Entwicklung & Codevor 2 MonatenPosit stellt Positron vor: Neue IDE für Data Science mit Python und R
-
Entwicklung & Codevor 2 MonatenEventSourcingDB 1.1 bietet flexiblere Konsistenzsteuerung und signierte Events
-
UX/UI & Webdesignvor 1 MonatFake It Untlil You Make It? Trifft diese Kampagne den Nerv der Zeit? › PAGE online
-
UX/UI & Webdesignvor 1 WocheIllustrierte Reise nach New York City › PAGE online
-
Social Mediavor 1 MonatSchluss mit FOMO im Social Media Marketing – Welche Trends und Features sind für Social Media Manager*innen wirklich relevant?
