La sécurité chez Transloadit
Nous devrions nous méfier des plateformes qui prétendent être sûres à 100 %, et vous ne surprendrez pas Transloadit à faire ce genre d’affirmations. Notre engagement, c’est plutôt que la confidentialité et la sécurité soient notre priorité numéro un. Nous partageons ouvertement ce que nous faisons pour vous protéger.
Conformité et résidence des données
Ciblez les États-Unis, l’Europe ou l’Asie-Pacifique pour la résidence des données, ou utilisez notre point de terminaison global pour acheminer géographiquement chaque Assembly vers la plus proche des trois régions.
Trois régions. À vous de choisir le routage.
Fixez le traitement dans une seule région pour la résidence des données, ou faites acheminer automatiquement les téléversements et les requêtes vers la région la plus proche.
États-UnisVirginieus-east-1
EuropeIrlandeeu-west-1
Asie-PacifiqueSingapourap-southeast-1
Une disponibilité sur laquelle vous pouvez compter.
La disponibilité à laquelle nous nous engageons dans notre SLA. Notre page de statut publique en présente l’historique.
Normes et contrôles de sécurité.
Notre programme de sécurité comprend la certification ISO 27001, une attestation SOC 2 Type II et des contrôles pour le traitement de vos fichiers.
RGPD
HIPAA
AES-256
SOC 2 Type II
ISO 27001
Les charges de travail soumises à la HIPAA nécessitent un Business Associate Agreement.
Ce que nous faisons pour assurer votre sécurité.
Voici la liste des mesures que nous prenons pour assurer votre sécurité et celle de vos données.
Politique
- Nous opérons conformément aux exigences du RGPD et du CCPA, prenons en charge les charges de travail soumises à HIPAA dans le cadre d’un Business Associate Agreement, et sommes certifiés ISO/IEC 27001.
- Notre rapport d’attestation SOC 2 Type II est disponible sur demande.
- Nous disposons d’un canal interne
#securityoù nous sensibilisons l’équipe, partageons et discutons toutes les dernières menaces pertinentes. Nous y révisons et mettons à jour nos politiques en continu. - Tous les membres de l’équipe et consultants qui manipulent des données sensibles doivent signer un contrat couvrant l’accord de confidentialité (NDA), la 2FA, les disques durs chiffrés, la gestion des mises à jour, etc.
- Nous menons un programme de sécurité et faisons l’objet de tests d’intrusion en continu, aussi bien par des scanners automatisés que par des humains.
- Les prestataires ayant accès aux informations sont tous répertoriés sur notre page Confidentialité (English).
- Tous les membres de l’équipe font l’objet d’une vérification, et les accès sont accordés selon le principe du besoin d’en connaître, puis révoqués dès que ce besoin disparaît. Nous nous en assurons lors du départ de chaque collaborateur.
- Nous publions les rapports d’incidents de sécurité sur notre blog (English). Les obligations de notification des clients sont régies par l’Avenant relatif au traitement des données (English) applicable.
- En tant qu’entreprise entièrement à distance, nous n’avons pas de bureau ni de réseau interne avec des zones démilitarisées, et nous avons adopté les principes de sécurité BeyondCorp (une mise en œuvre du Zero Trust). Consultez les articles de Google sur BeyondCorp. Nous segmentons en revanche différentes parties de notre infrastructure, utilisons des pare-feu pour restreindre le trafic entrant et sortant de notre réseau à des points stratégiques, et déployons des VPC (English) pour isoler le trafic et créer des zones réseau.
- Transloadit est une entreprise très technique, et tout y est code. Cela inclut les politiques, la configuration et l’infrastructure (via Terraform (English)). Cela nous permet de soumettre tout changement dans l’entreprise à une gestion des changements via le contrôle de version, les revues par les pairs, les tests, la CI/CD et les retours arrière. La documentation de tous les changements dans l’entreprise se trouve dans les pull requests et les documents Markdown qui les accompagnent. Les directives de durcissement sont documentées sous forme de code.
- Vous pouvez diriger les requêtes API vers une région spécifique en utilisant un point de terminaison régional tel que
https://api2-eu-west-1.transloadit.com.
Autorisation et chiffrement
- Notre API et notre site web prennent en charge HTTPS pour chiffrer les données en transit.
- Les données sensibles au repos sont chiffrées en AES-256.
- Les paiements par carte bancaire des abonnements Transloadit sont traités par Stripe, un prestataire de paiement certifié PCI DSS niveau 1.
- Transloadit doit d’abord activer l’authentification unique SAML pour votre Workspace Enterprise. Son propriétaire peut ensuite configurer un fournisseur d’identité pour les utilisateurs de la console développeur.
- Il existe des propriétaires de compte et des collaborateurs ; les propriétaires disposent de plus de privilèges (inviter, résilier, etc.).
- Pour les opérations dangereuses ou sensibles, notre site web demande de se réauthentifier afin d’ouvrir une session « sudo » d’une durée de 15 minutes.
- Pour les comptes avec mot de passe, nous imposons des exigences de sécurité minimales.
- Les mots de passe sont hachés de manière cryptographique et irréversible avec bcrypt, avec salage et poivrage.
Durcissement et processus
- Nous utilisons l’infrastructure d’AWS et de Hetzner, avec un stockage temporaire des fichiers sur Amazon S3 et Cloudflare R2. Nos serveurs tournent sous Ubuntu. Les administrateurs utilisent sudo pour élever leurs privilèges si nécessaire.
- Nos bonnes pratiques vous permettent facilement de donner à Transloadit le moins d’accès possible à vos fichiers (English).
- Notre encodage (la partie la plus risquée, puisque nous exécutons des commandes pour le compte de tiers) s’exécute sur des machines épurées. Nous y ajoutons en outre une isolation par bac à sable (sandboxing).
- Nous appliquons une limitation de débit au niveau du compte, de l’adresse IP et des événements d’audit.
- Toutes les entrées pertinentes des journaux de production sont stockées à distance, avec détection de motifs et alertes en cas d’intention malveillante, ainsi que de plantages inattendus, d’exceptions et d’autres conditions d’erreur.
- Nous durcissons les images système et en déployons automatiquement de nouvelles à chaque modification via Packer et CI/CD. Cela s’applique à tous les clusters. Les correctifs de sécurité sont déployés automatiquement. Les autres versions sont épinglées et ne sont mises à jour que sur activation explicite. Nous disposons d’un processus pour déployer des correctifs d’urgence.
- Nous disposons de milliers de tests unitaires, de tests système, de tests d’intégration et de tests e2e qui confirment que les modifications sont sécurisées, correctes et performantes.
- Nous utilisons des requêtes préparées et nous appuyons sur des frameworks pour échapper et assainir les entrées utilisateur.
- Vous pouvez activer la Signature Authentication pour vérifier l’intégrité des paramètres de requête signés. Consultez la section Sécurité de l’API pour découvrir d’autres moyens de protéger votre intégration.
- Vous pouvez analyser les fichiers entrants à la recherche de virus en ajoutant 🤖/file/virusscan (English) à vos Assembly Instructions.
Disponibilité et continuité
- Notre coffre-fort, qui contient les informations d’identification et les Templates, est chiffré et synchronisé vers un site distant. Des copies hors ligne de notre code et de ce coffre-fort sont conservées hors de l’internet public.
- Nous déployons une surveillance et des alertes (par milliers) portant sur la santé du système, la santé du produit et les abus (signatures d’attaques, événements d’audit).
- Notre page de statut est entièrement séparée de notre plateforme de production, jusqu’au bureau d’enregistrement du nom de domaine, et vous informe de tout incident affectant la production, tout comme le compte Twitter @TLStatus.
Divulgation responsable d’une vulnérabilité de sécurité.
Chez Transloadit, la sécurité nous tient particulièrement à cœur. Nous savons que des erreurs peuvent arriver, mais nous cherchons toujours à les corriger et à les prévenir. C’est pourquoi nous vous sommes très reconnaissants de nous prévenir si vous découvrez un problème de sécurité.
Récompenses
Si le problème est valide (c’est-à-dire que nous estimons qu’il doit être corrigé) et que vous êtes la première personne à le signaler, vous obtiendrez une place dans notre Tableau d’honneur. Pour les cas graves, nous offrons des goodies de votre choix sur shop.transloadit.com. Nous ne proposons pas de primes en argent.
Tableau d’honneur
Veuillez indiquer dans votre rapport comment vous souhaitez être crédité dans le Tableau d’honneur. Vous pouvez fournir un site et un nom ou un pseudonyme, mais nous fixons une limite dès que cela devient trop tapageur, publicitaire ou offensant.
Règles
Les outils automatisés peuvent générer beaucoup de bruit dans nos outils d’audit ; nous vous demandons donc de ne pas les utiliser.
Veuillez garder à l’esprit que nous appliquons une limitation de débit aux échecs de connexion et à de nombreux autres événements, mais qu’elle se déclenche assez tard.
Tableau d’honneur
Les chercheurs en sécurité suivants ont identifié des vulnérabilités et nous les ont signalées de manière responsable. Les 3 premiers sont présentés ici. Consultez la liste complète pour découvrir toutes les personnes qui ont contribué à rendre Transloadit plus sûr.
- 1Sachhit45 signalements
- 2Prasanth ElangovanLien externe25 signalements
- 3Faizan Ahmad WaniLien externe17 signalements
Vos questions, nos réponses.
Si vous avez des questions sur la sécurité de Transloadit en général, voici quelques questions liées à la sécurité et leurs réponses :
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 %.
Puis-je autoriser les IP de Transloadit dans mon pare-feu ?
Nos adresses IP sortantes changent à mesure que des serveurs sont ajoutés et retirés. Tenir à jour une liste d’autorisation de pare-feu avec les IP de chaque serveur peut entraîner des coupures de connexion.
Cela s’applique aux connexions sortantes telles que 🤖/sftp/store (English), les Assembly Notifications et 🤖/http/import (English).
Comment mes informations d’identification Amazon S3 sont-elles protégées ?
Pour les exportations vers S3, enregistrez vos informations d’identification en tant qu’informations d’identification de Template et référencez-les depuis vos Templates. Les informations d’identification de stockage cloud enregistrées sont chiffrées au repos.
Limitez l’accès de Transloadit au bucket S3 et aux autorisations dont votre flux de travail a besoin. Consultez la documentation de S3 Store (English) pour connaître les autorisations IAM requises.
L’autorisation s3:PutObject permet d’écraser les objets existants ayant la même clé ; elle ne limite pas l’accès à l’ajout de nouveaux fichiers.
MD5 n’est pas un algorithme de hachage sécurisé, pourquoi l’utilisez-vous ?
Tout d’abord, nous n’utilisons pas MD5 pour l’authentification par signature ni pour quoi que ce soit d’autre qui doit être sécurisé. Nous fournissons des empreintes MD5 des fichiers pour détecter les doublons provenant de sources fiables, ainsi qu’à d’autres fins pour lesquelles le vecteur d’attaque consistant à calculer des empreintes en collision ne présente aucun intérêt.
Comme MD5 est à la fois plus rapide à calculer et encore plus largement disponible que SHA1, par exemple, un compromis délibéré a été fait en fournissant des empreintes MD5 pour les résultats d’encodage. Il va sans dire que, MD5 n’étant pas sûr, vous ne devez pas utiliser ces empreintes comme éléments de base pour quoi que ce soit de sensible en matière de sécurité dans votre application.
Une sécurité sur laquelle vous pouvez bâtir
Les charges de travail soumises à la HIPAA nécessitent un Business Associate Agreement.