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 jederzeit etwa 5.000.000 Assemblies im aktiven Speicher halten, ist die Wahrscheinlichkeit einer Kollision zugegebenermaßen 5.000.000-mal höher. Zufällige UUIDv4-Kennungen machen das Erraten einer aktiven Assembly-ID dennoch rechnerisch unpraktikabel. Ratenbegrenzungen bieten zusätzlichen Schutz, aber das Kontingent für die Erstellung von Assemblies ist kein Limit für Assembly-Status-Abfragen. Zufälliges Erraten betrachten wir daher bei Weitem nicht als 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+ 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 unsere Prozesse als nicht privilegierte Benutzer aus und stellen ihnen die benötigten Zugangsdaten bereit. Ein kompromittierter Prozess kann die ihm übergebenen Zugangsdaten auch ohne Root-Zugriff offenlegen. Der Zugriff auf verschlüsselte Daten hängt von den Berechtigungen der gestohlenen Zugangsdaten und vom Zugriff auf die entsprechenden Entschlüsselungsschlüssel ab. Eine Verschlüsselung ruhender Daten schützt nicht vor einem Angreifer, der einen autorisierten Lesezugriff nutzen kann. Begrenzte Berechtigungen und der Schutz von Prozessen bleiben wichtig, und kein System kann eine Sicherheitsgarantie von 100% bieten.