Sicherheit bei Transloadit

Transloadit verwendet UUIDv4 ohne Bindestriche, um diese IDs zufällig zu erzeugen. Eine UUID zu erraten oder zu generieren, die einer unserer UUIDs entspricht, wäre so wahrscheinlich wie das Erzeugen einer Kollision. Das ist so unwahrscheinlich, dass es nicht als praktikabler Angriffsvektor gilt.

Da wir zu jedem Zeitpunkt etwa fünf Millionen Assemblies im aktiven Storage vorhalten, ist die Wahrscheinlichkeit, eine Kollision zu erzeugen, zugegebenermaßen fünf Millionen Mal höher. Dennoch begrenzen wir die Rate auf 250 Vorgänge pro Minute. Daher würden Maschinen länger brauchen, als die Menschheit auf der Erde existiert, um genügend UUIDs zu erzeugen, damit mit 50 % Wahrscheinlichkeit eine davon einer UUID entspricht, die Transloadit einmal generiert hat. Wir halten dies bei weitem nicht für einen praktikablen Angriffsvektor.

Bei Dateien ist das Zeitfenster noch kleiner, da wir sie nach 24 Stunden entfernen. Einige Gründe, warum wir uns dafür entscheiden, sind hier beschrieben.

Über das Erraten von Dateien oder Assembly URLs hinaus besteht natürlich die Sorge, dass diese Adressen irgendwie durchsickern könnten. Wir betrachten eine Assembly ID und eine Datei-URL als privat. Sie sind ein Geheimnis, das zwischen Transloadit, unserem Kunden und – je nach Integration – dem jeweiligen Endnutzer geteilt wird, für den der Kunde die Dateien bereitstellt und die Assembly in Ihrem Auftrag ausführt.

Die Kommunikation zwischen diesen Parteien erfolgt über HTTPS, wofür wir bei SSL Labs durchgängig ein A+ Rating haben. Wenn HTTPS für die Integration mit Transloadit und dem Endnutzer bei jeder beteiligten Anfrage verwendet wird, können die URLs zu Assemblies und Dateien nicht über diese vertrauenswürdigen Parteien hinaus durchsickern – zumindest nicht mit einer Wahrscheinlichkeit, die daraus einen praktikablen Angriffsvektor machen würde.

Dann ist Transloadit selbst als vertrauenswürdige Partei zu betrachten. Unsere Richtlinie lautet, dass nur unsere vertrauenswürdigen Kernteammitglieder zu Debugging-Zwecken Zugriff auf diese Dateien haben. Wir erhalten täglich Millionen von Dateien, und für uns sind sie nur UUIDs, bis ein Kunde uns bittet, genauer hinzusehen.

Wir führen alle unsere Prozesse als nicht privilegierte Benutzer aus und injizieren Secrets. Wenn ein Angreifer also in den Besitz dieser Secrets gelangt ist, bedeutet das, dass er auf irgendeine Weise Root-Zugriff auf unsere Maschinen erhalten hat. In diesem Fall würde die Verschlüsselung der Datei-Buckets nicht ausreichen: Mit den Zugangsdaten, die für vollständigen Zugriff auf den Bucket nötig sind, hätte der Angreifer höchstwahrscheinlich auch Zugriff auf unsere Entschlüsselungsschlüssel – so wie es der Fall wäre, wenn wir Amazon als gehackt betrachten müssten. Glücklicherweise legen sowohl Amazon als auch Transloadit sehr großen Wert darauf, unsere Systeme sicher zu halten. Es stimmt jedoch: Wer Ihnen hier eine 100%ige Sicherheitsgarantie gibt, versteht Sicherheit tatsächlich nicht vollständig – und Sie wären gut beraten, Abstand zu halten.

Unsere Plattform ist insofern sehr dynamisch, als heute 1000 Server online sein können, die morgen bereits nicht mehr existieren. Ihre Firewalls in diesem Tempo aktuell zu halten, führt zwangsläufig zu abgebrochenen Verbindungen.

Wir leiten ausgehende Verbindungen (z. B. /sftp/store, Notifications oder /http/import) aus Performance- und SPOF-Gründen nicht über einen einzigen Punkt. Eine Proxy-Flotte, die mit der Last skaliert, bringt uns zurück zum gleichen Problem; NAT hat wiederum aus Performance-Sicht untragbare Einschränkungen. Der Trade-off unserer Entscheidung für maximale Zuverlässigkeit und maximalen Durchsatz ist, dass sich unsere ausgehenden IPs schnell ändern.

Wenn Sie möchten, dass wir Dateien in Ihrem S3 Bucket speichern, empfehlen wir, die Credentials in einem Template in Ihrem Account zu speichern. Wir halten dieses Template verschlüsselt in unserer Datenbank vor.

Die Schlüssel, die zum Entschlüsseln benötigt werden, werden von einem anderen Systembenutzer in den Prozessspeicher injiziert. Das bedeutet: Selbst wenn jemand den Benutzer ausnutzen könnte, unter dem wir unsere API- oder Website-Prozesse ausführen, hätte diese Person weiterhin keinen Zugriff auf die Schlüssel. Würde sie versuchen, unseren Code so zu ändern, dass die Credentials angezeigt oder gesendet werden, müsste sie den Service neu starten (unter diesem Benutzer nicht erlaubt) und auf die Schlüsseldateien zugreifen (ebenfalls nicht erlaubt).

Wenn unsere Server gerootet werden, ist das eine andere Situation. Deshalb verwenden wir Firewalls, schützen SSH-Schlüssel und beschränken sudo. Doch wie Ihnen jeder Experte bestätigen wird: 100%ige Sicherheit ist ein Mythos, und es ist besser, sich auf den schlimmsten Fall vorzubereiten.

Deshalb empfehlen wir, IAM Policies zu erstellen, die nur Put- und List-Berechtigungen für Ihre Buckets haben (eine aktuelle und genaue Liste der erforderlichen Berechtigungen finden Sie in der S3 Store Dokumentation), und Transloadit diese nur zum Schreiben nutzen zu lassen. Falls Ihre Credentials also jemals gestohlen würden und die Kriminellen sie zudem entschlüsseln könnten, könnten sie dennoch nur weitere Dateien zu diesem bestimmten Bucket hinzufügen – bis wir es bemerken und eingreifen.

Auch wenn, wie gesagt, 100%ige Sicherheit ein Mythos ist, besteht unsere Sicherheitsphilosophie darin, es jedem so schwer wie möglich zu machen, Zugriff auf Ihre Credentials und die zu deren Entschlüsselung erforderlichen Schlüssel zu erhalten – und falls es doch gelingt, diese so nutzlos wie möglich zu machen.

Zunächst: Für Signaturauthentifizierung und alle anderen sicherheitsrelevanten Zwecke verwenden wir kein MD5. Wir stellen MD5-Hashes für Dateien bereit, um Duplikate aus vertrauenswürdigen Quellen zu erkennen, sowie für andere Zwecke, bei denen es keinen lohnenden Anwendungsfall für den Angriffsvektor der Berechnung kollidierender Hashes gibt.

Da MD5 schneller zu berechnen und noch breiter verfügbar ist als beispielsweise SHA1, haben wir uns bewusst dafür entschieden, MD5-Hashes für Encoding-Ergebnisse bereitzustellen. Da MD5 nicht sicher ist, sollten Sie diese Hashes selbstverständlich nicht als Bausteine für sicherheitsrelevante Funktionen in Ihrer Anwendung verwenden.