Mastra-Plattform von Build-Ausfall und Sicherheitsvorfall bei Railway betroffen

Zwei Vorfälle an einem Tag

Mastra beschreibt den Tag als schwerwiegenden Vorfall, der in zwei Teilen ablief. Der erste begann am frühen Morgen Pacific Time, als das Build-System der Plattform ausfiel. Um 02:27 Uhr PT eröffnete Mastra auf seiner Statusseite einen Vorfall und führte die fehlgeschlagenen Builds auf einen Ausfall bei einem vorgelagerten Anbieter zurück.

Der zweite Teil war gravierender. Gegen 14:50 Uhr PT gab Railway einen Sicherheitsvorfall bekannt. Mastra zufolge könnten damit Umgebungsvariablen von Nutzern der Mastra-Plattform in die Hände Dritter gelangt sein. Das Unternehmen betont, dass es derzeit keine Belege dafür hat, dass Nutzer kompromittiert wurden. Zudem stellt Mastra klar, dass der Vorfall nur die Plattform betrifft und nicht das Open-Source-Projekt Mastra.

Das Dilemma bei der Schlüsselrotation

Als schwierigsten Teil des Vorfalls bezeichnet Mastra die Zwickmühle, in der seine Nutzer steckten. Als Railway den Sicherheitsvorfall öffentlich machte, war das Build-System von Railway und damit auch das von Mastra noch ausgefallen. Laut Mastra konnten Nutzer ihre Schlüssel deshalb mehrere Stunden lang nicht rotieren, ohne ihre Produktionsanwendung lahmzulegen.

Weil Umgebungsvariablen während des Ausfalls nicht in die Produktion übertragen wurden, riet das Unternehmen nicht dazu, Schlüssel zu erneuern, solange Nutzer keine verdächtigen Aktivitäten bemerkten. Stattdessen empfahl es, auf Anzeichen unbefugten Zugriffs zu achten. Um 18:14 Uhr PT forderte Mastra die Nutzer der Plattform auf, die Logs von Diensten zu prüfen, deren Schlüssel auf der Plattform gespeichert sind, und nannte drei Schritte:

• Zugriffsprotokolle prüfen.
• Prüfen, ob neue, unbekannte Nutzer oder Tokens angelegt wurden.
• Guthaben und Aktivität der API-Tokens von KI-Inferenzanbietern prüfen, die Sie konfiguriert haben.

Chronologie der Reaktion

Mastra meldete den Vorfall intern erstmals um 02:11 Uhr PT. Um 13:32 Uhr PT rechnete der vorgelagerte Anbieter damit, dass die Builds innerhalb einer Stunde wieder laufen, und Mastra hatte begonnen, an einem Ausweich-Deployment-System zu arbeiten. Um 14:59 Uhr PT bestätigte die Statusseite von Railway den Sicherheitsvorfall, und Railway teilte dies Mastra per Slack-Direktnachricht mit.

Um 16:38 Uhr PT warnte Mastra seine Kunden auf der Statusseite, nach Untersuchungen gemeinsam mit Railway und verwandten Anbietern, API-Schlüssel und zugehörige Systeme auf verdächtige Aktivitäten zu überwachen. Um 20:59 Uhr PT war bestätigt, dass die Builds wieder laufen. Railway gab Mastra grünes Licht für den Neuaufbau, und das Team kündigte an, zunächst interne Projekte zu testen und dann die plattformspezifischen Mastra-Schlüssel für jedes Projekt zu rotieren.

Um 21:18 Uhr PT schickte Mastra den Plattformnutzern über gemeinsame Slack-Kanäle und per E-Mail einen aktualisierten Bericht mit Anleitungen, wie und wann Schlüssel zu rotieren sind. Um 22:44 Uhr PT wechselte der Vorfall in den Überwachungsstatus, das Team unterstützte weiterhin Kunden bei der Rotation ihrer Schlüssel.

Was sich für Nutzer der Mastra-Plattform ändert

Mastra will nach eigenen Angaben bereits geplante Arbeiten an der Control Plane in den kommenden Wochen beschleunigen. Ziel ist es, das Hosting bei anderen Anbietern zu ermöglichen und ein Failover-System aufzubauen, um lang anhaltende Ausfälle zu vermeiden. Das Unternehmen erwägt, Railway komplett zu verlassen oder Railway auf einen Teil der Nutzer des kostenlosen Tarifs zu beschränken.

Mastra erwartet in den nächsten Tagen weitere Details von Railway und will diese weitergeben. Plattformnutzer, die es noch nicht getan haben, sollten den Empfehlungen des Unternehmens zur Log-Prüfung und Schlüsselrotation folgen. Mastra entschuldigte sich für die Störung und bat Nutzer, sich bei Fragen zu melden.