Sicherheit bei Transloadit

Transloadit verwendet UUIDv4 ohne Bindestriche, um diese IDs zufällig zu generieren. Eine solche ID zu erraten oder eine UUID zu generieren, die mit einer unserer IDs übereinstimmt, wäre genauso wahrscheinlich wie eine Kollision. Das ist so unwahrscheinlich, dass es nicht als praktikabler Angriffsvektor gilt⁠.

Da wir zu jedem Zeitpunkt etwa 5.000.000 Assemblies im aktiven Speicher vorhalten, ist die Wahrscheinlichkeit einer Kollision zugegebenermaßen 5.000.000-mal höher. Da wir die Rate jedoch auf 250 Vorgänge pro Minute begrenzen, würden Maschinen weiterhin länger brauchen, als die Menschheit auf der Erde existiert, um genügend UUIDs für eine Wahrscheinlichkeit von 50 % zu erzeugen, dass eine davon mit einer UUID übereinstimmt, die Transloadit jemals 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 dafür erläutern wir hier.

Neben dem Erraten von Datei- oder Assembly-URLs besteht natürlich auch das Risiko, dass diese Adressen auf irgendeine Weise offengelegt werden. Wir betrachten eine Assembly-ID und eine Datei-URL als vertraulich. Sie sind ein Geheimnis, das Transloadit, unser Kunde und je nach Ihrer Integration der jeweilige Endnutzer teilen, für den der Kunde die Dateien bereitstellt und in Ihrem Auftrag die Assembly ausführt.

Die Kommunikation zwischen diesen Parteien erfolgt über HTTPS, wofür wir bei SSL Labs durchweg die Bewertung A+ EN (English) erhalten. Wenn für alle beteiligten Anfragen bei der Integration zwischen Transloadit und dem Endnutzer HTTPS verwendet wird, können die URLs zu Assemblies und Dateien nicht über diese vertrauenswürdigen Parteien hinaus offengelegt werden und somit kaum zu einem praktikablen Angriffsvektor werden.

Somit 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 stellen ihnen dabei Secrets bereit. Wenn ein Angreifer also in den Besitz dieser Secrets gelangt, bedeutet dies, dass er auf irgendeine Weise Root-Zugriff auf unsere Systeme erhalten hat. In diesem Fall würde die Verschlüsselung der Datei-Buckets nicht ausreichen: Mit den Zugangsdaten für den vollständigen Zugriff auf den Bucket hätte der Angreifer mit hoher Wahrscheinlichkeit auch Zugriff auf unsere Entschlüsselungsschlüssel. Das wäre ebenso der Fall, wenn wir davon ausgehen müssten, dass Amazon gehackt wurde. Glücklicherweise legen sowohl Amazon als auch Transloadit größten Wert darauf, unsere Systeme sicher zu halten. Es stimmt jedoch: Wer Ihnen hier eine 100%ige Sicherheitsgarantie gibt, versteht Sicherheit nicht vollständig. 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-Richtlinien zu erstellen, die für Ihre Buckets nur Put- und List-Berechtigungen gewähren. Eine aktuelle und genaue Liste der erforderlichen Berechtigungen finden Sie in der Dokumentation zu S3 Store. Lassen Sie Transloadit diese Zugangsdaten ausschließlich zum Schreiben verwenden. Falls Ihre Zugangsdaten jemals gestohlen würden und die Kriminellen sie ebenfalls entschlüsseln könnten, könnten sie dennoch nur weitere Dateien zu diesem bestimmten Bucket hinzufügen, bis wir dies bemerken und eingreifen.

Auch wenn 100%ige Sicherheit, wie bereits erwähnt, ein Mythos ist, besteht unsere Sicherheitsphilosophie darin, es jedem so schwer wie möglich zu machen, Zugriff auf Ihre Zugangsdaten und die zu deren Entschlüsselung erforderlichen Schlüssel zu erhalten. Falls es dennoch gelingt, sollen diese so nutzlos wie möglich sein.

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.