Les identifiants d’Assembly sont-ils sécurisés ?
Transloadit utilise des UUIDv4 sans tirets pour générer ces identifiants aléatoirement. Deviner ou générer un UUID correspondant à l’un des nôtres serait aussi probable que de générer une collision. C’est si improbable que ce n’est pas considéré comme un vecteur d’attaque viable.
Puisque nous conservons environ 5 000 000 Assemblies dans le stockage actif à tout moment, le risque de générer une collision est, il est vrai, 5 000 000 fois plus élevé. Avec des identifiants UUIDv4 aléatoires, deviner un identifiant d’Assembly actif reste toutefois impraticable sur le plan du calcul. Les limites de débit offrent une protection supplémentaire, mais le quota de création d’Assemblies ne constitue pas une limite pour les consultations d’Assembly Status. Nous estimons que les tentatives de deviner un identifiant au hasard sont loin de constituer un vecteur d’attaque viable.
Pour les fichiers, ce délai est encore plus court, car nous les supprimons après 24 heures. Quelques raisons qui motivent ce choix sont présentées ici (English).
Outre la possibilité de deviner les URL de fichiers ou d’Assembly, le risque que ces adresses soient divulguées d’une manière ou d’une autre est bien entendu préoccupant. Nous considérons qu’un ID d’Assembly et une URL de fichier sont privés. Ils constituent un secret partagé entre Transloadit, notre client et, selon votre intégration, l’utilisateur final concerné, pour lequel le client fournit les fichiers et exécute l’Assembly pour votre compte.
Cette communication entre ces parties s’effectue via HTTPS, pour lequel nous obtenons la note A+ sur SSL Labs (English) sur toute la ligne. Si HTTPS est utilisé pour l’intégration avec Transloadit et l’utilisateur final pour toutes les requêtes concernées, les URL des Assemblies et des fichiers ne peuvent pas fuiter en dehors de ces parties de confiance avec une probabilité suffisante pour constituer un vecteur d’attaque exploitable.
Il faut ensuite considérer Transloadit en tant que tiers de confiance. Notre politique prévoit que seuls les membres de confiance de notre équipe principale ont accès à ces fichiers à des fins de débogage. Nous recevons des millions de fichiers chaque jour et, pour nous, ils ne sont que des UUID jusqu’à ce qu’un client nous demande de les examiner de plus près.
Nous exécutons nos processus sous des comptes d’utilisateurs non privilégiés et leur fournissons les informations d’authentification dont ils ont besoin. Un processus compromis peut exposer les informations d’authentification qu’il reçoit sans disposer d’un accès root. L’accès aux données chiffrées dépend des autorisations associées aux informations d’authentification dérobées et de l’accès aux clés de déchiffrement correspondantes. Le chiffrement au repos ne protège pas les données contre un attaquant qui peut utiliser un chemin d’accès en lecture autorisé. Il reste important de limiter les informations d’authentification et de protéger les processus, et aucun système ne peut offrir une garantie de sécurité à 100 %.