Transloadit est prêt pour les entreprises
Chaque questionnaire de sécurité pose les mêmes questions. Qui peut se connecter, et comment lui retirez-vous l’accès ? Que peut faire une clé divulguée ? À quoi vous engagez-vous par écrit ? Transloadit apporte désormais une réponse claire à chacune, pour que votre évaluation puisse passer au fournisseur suivant.
Authentification unique pour votre Workspace
Les membres des Workspaces Enterprise peuvent désormais se connecter à la Console via SAML 2.0. Votre fournisseur d’identité authentifie vos coéquipiers ; l’appartenance au Workspace Transloadit, les invitations et les limites de sièges déterminent toujours leur accès.
Le SSO est en accès anticipé, tout commence donc par nous : écrivez à notre équipe commerciale, puis nous l’activons pour votre Workspace et vous aidons à le configurer. Le propriétaire du Workspace ouvre ensuite Paramètres, puis Authentification unique (SAML) dans la Console. Il y copie l’ID d’entité de notre fournisseur de services, l’URL ACS et l’URL des métadonnées dans le fournisseur d’identité, puis colle en retour dans Transloadit l’ID d’entité, l’URL SSO, le certificat X.509 et l’attribut e-mail du fournisseur d’identité. Les propriétaires qui se connectent avec un mot de passe doivent le confirmer lorsqu’une nouvelle session à privilèges élevés est nécessaire. Le fournisseur d’identité doit signer ses assertions et envoyer un NameID stable et non transitoire.
Vos coéquipiers choisissent ensuite Continuer avec SSO sur la page de connexion et saisissent le slug de leur Workspace. Quelques détails sur lesquels les auditeurs de sécurité posent souvent des questions :
- Provisionnement. Dans la Console, activez Autoriser le provisionnement des utilisateurs juste-à-temps pour permettre aux personnes sans compte Transloadit de rejoindre le Workspace avec le rôle Utilisateur lors de leur première connexion, dans la limite des sièges de votre forfait, invitations en attente comprises. Une personne qui possède déjà un compte mais n’est pas membre a besoin d’une invitation, même lorsque cette option est activée. Les nouveaux membres qui rejoignent le Workspace via une invitation SSO reçoivent également le rôle Utilisateur ; les membres existants conservent leurs rôles. Lorsque le provisionnement est désactivé, seuls les membres existants et les personnes invitées peuvent se connecter.
- Retrait des accès. Désactiver une personne dans votre fournisseur d’identité bloque les nouvelles connexions SSO, mais pas une session existante ni une autre méthode de connexion. Retirez séparément son appartenance au Workspace ; son accès à ce Workspace prend fin à sa prochaine requête. Renouvelez ou supprimez également chaque Auth Key dont cette personne a créé ou consulté le secret, ou dont elle a pu connaître le secret d’une autre manière.
- Portée. Le SSO s’ajoute à la connexion par mot de passe au lieu de la remplacer, et les connexions démarrent chez Transloadit (initiées par le SP). Les membres qui ont déjà un mot de passe peuvent toujours l’utiliser.
Des clés d’accès comme second facteur
Dans la Console, l’authentification à deux facteurs reposait jusqu’ici sur un code à six chiffres envoyé par e-mail. Vous pouvez désormais utiliser une clé d’accès à la place : Face ID, Touch ID ou une clé de sécurité matérielle. Une clé d’accès ne fonctionne que sur le site pour lequel elle a été créée, si bien qu’une page de connexion imitant la nôtre ne peut pas la dérober par hameçonnage.
Dans la Console, ouvrez Paramètres utilisateur, puis Sécurité de connexion, puis Authentification à deux facteurs, choisissez Clé d’accès et suivez les instructions de votre navigateur. Dans une session authentifiée par mot de passe, vous pouvez revenir aux codes par e-mail. Les clés d’accès s’appliquent aux comptes qui se connectent avec un mot de passe. Les connexions Google, GitHub et SAML reposent plutôt sur l’authentification et la MFA de leur fournisseur d’identité.
La Console enregistre actuellement une seule clé d’accès. Pour la remplacer, passez aux codes par e-mail dans une session authentifiée par mot de passe, puis choisissez Clé d’accès et enregistrez la nouvelle clé. Utilisez les codes par e-mail si votre navigateur ne prend pas en charge les clés d’accès.
Signer les requêtes avec SHA-384
La Signature Authentication prouve qu’une requête provient d’une personne qui détient votre secret. Les nouvelles Auth Keys destinées aux requêtes d’API ordinaires utilisent HMAC-SHA384 par défaut. Chaque clé possède son propre paramètre d’algorithme. Utilisez SHA-384 plutôt que SHA-1 pour les signatures des nouvelles requêtes d’API. Les signatures d’URL Smart CDN utilisent SHA-256 à la place. Les clés pour lesquelles Smart CDN est activé n’acceptent qu’une restriction SHA-256 ou aucune restriction par clé ; elles n’héritent pas de la valeur par défaut SHA-384 des clés ordinaires. Dès qu’une clé possède une restriction d’algorithme, les requêtes d’API signées avec un autre algorithme sont rejetées. Les clés sans restriction acceptent SHA-1, SHA-256 et SHA-384 pour les requêtes d’API. La documentation sur l’authentification décrit le contrat de signature complet.
Utilisez une clé distincte pour la signature Smart CDN. Activer Smart CDN sur une clé existante restreinte à SHA-384 sans choisir explicitement une restriction compatible supprime cette restriction, ce qui autorise de nouveau SHA-1, SHA-256 et SHA-384 pour les requêtes d’API. Choisissez une restriction SHA-256 si vous activez Smart CDN sur une clé existante. Ces paramètres de requêtes d’API ne modifient pas les signatures des Assembly Notifications.
Notre SDK Node signe avec SHA-384 par défaut ; définissez son option
signatureAlgorithm: 'sha256' pour une clé restreinte à SHA-256. Si vous signez vous-même les requêtes
avec SHA-384, préfixez le condensé hexadécimal avec sha384:. Voici un petit utilitaire pour une clé
d’API SHA-384 ordinaire qui n’utilise que les modules intégrés de Node crypto et fetch :
// sign.mjs
import { createHmac } from 'node:crypto'
export async function postApi2(path, fields, key, secret) {
if (!key || !secret) throw new Error('Set your server-side Transloadit credentials')
const expires = new Date(Date.now() + 10 * 60 * 1000).toISOString()
const params = JSON.stringify({ ...fields, auth: { key, expires } })
const hmac = createHmac('sha384', secret).update(params).digest('hex')
const body = new URLSearchParams({ params, signature: `sha384:${hmac}` })
const res = await fetch(`https://api2.transloadit.com${path}`, { method: 'POST', body })
if (!res.ok) throw new Error(`Transloadit request failed (HTTP ${res.status})`)
return res.json()
}
Ce script l’utilise pour créer une Assembly qui importe une image et la redimensionne :
// assembly.mjs
import { postApi2 } from './sign.mjs'
const { TRANSLOADIT_KEY, TRANSLOADIT_SECRET } = process.env
const steps = {
imported: { robot: '/http/import', url: 'https://demos.transloadit.com/inputs/chameleon.jpg' },
thumb: { use: 'imported', robot: '/image/resize', width: 200, height: 200 },
}
const assembly = await postApi2('/assemblies', { steps }, TRANSLOADIT_KEY, TRANSLOADIT_SECRET)
console.log(assembly.ok ?? assembly.error, assembly.assembly_id ?? assembly.message)
Exécutez-le sur votre serveur avec une version prise en charge de Node.js et une Auth Key disposant
de la portée assemblies:write :
$ export TRANSLOADIT_KEY=MY_AUTH_KEY TRANSLOADIT_SECRET=MY_SECRET_KEY
$ node assembly.mjs
ASSEMBLY_EXECUTING 1aa00d5b547b…
La réponse initiale signifie que le traitement a commencé, pas que la miniature est prête. Suivez l’Assembly Status jusqu’à ce que l’Assembly se termine ou échoue. Pour cet exemple d’image, une exécution réussie produit une miniature de 200×133.
Auth Keys à portée limitée
Une clé qui peut tout faire devient un risque lorsqu’elle fuite. Chaque nouvelle Auth Key nécessite
désormais au moins une portée. Privilégiez les portées propres à un domaine pour les Assemblies, les
Templates, les informations d’identification de Template, les Auth Keys, la facturation, les files
d’attente ou la signature Smart CDN. Les anciennes portées read et write restent disponibles,
mais accordent un accès étendu. Attribuez à chaque application et à chaque environnement sa propre
clé, avec uniquement les autorisations nécessaires, et révoquez-en une sans toucher aux autres.
Dans la Console, accédez à Informations d’identification et cliquez sur Nouvelle Auth Key. Le préréglage Diffusion d’images privées (signature Smart CDN) crée une clé capable de signer des URL Smart CDN, mais pas de créer des Assemblies autonomes ni de gérer Storage. Choisissez Sur mesure pour cocher vous-même les portées. L’API offre les mêmes possibilités via la création d’une Auth Key et la liste des portées disponibles.
Nous vérifions la portée à chaque appel. La clé utilisée dans ces exemples peut créer des Assemblies, mais pas de nouvelles clés :
// create-key.mjs
import { postApi2 } from './sign.mjs'
const { TRANSLOADIT_KEY, TRANSLOADIT_SECRET } = process.env
const fields = { scope: 'assemblies:write', description: 'my-app staging' }
postApi2('/auth_keys', fields, TRANSLOADIT_KEY, TRANSLOADIT_SECRET)
.then((res) => console.log(res.ok))
.catch((error) => {
console.error(error.message)
process.exitCode = 1
})
$ node create-key.mjs
Transloadit request failed (HTTP 403)
L’API renvoie INSUFFICIENT_AUTH_SCOPE, car cette opération nécessite auth_keys:write ;
l’utilitaire indique le statut HTTP sans afficher le corps de la réponse. Une clé disposant de
cette portée obtient AUTH_KEY_CREATED à la place. Considérez auth_keys:write comme un privilège d’administration :
cette portée permet de créer des clés aux portées plus étendues, réservez-la donc à une clé dédiée
et rigoureusement protégée.
La réponse de création réussie contient également le secret de la nouvelle clé,
que cet exemple n’affiche délibérément pas. Stockez-le de façon sécurisée lorsque vous intégrez la
création de clés. Définir can_show_auth_secret lors de la création autorise un seul affichage ultérieur, et non une
récupération illimitée. Si vous exécutez l’exemple avec l’autorisation de créer des clés, supprimez
ensuite la clé de test dans la Console.
Les documents
La page consacrée à la sécurité rassemble ce que demandent les services achats :
- SOC 2 Type II. Notre rapport d’attestation est disponible sur demande, dans le cadre d’un NDA.
- ISO 27001. Transloadit est certifié ISO/IEC 27001.
- SLA. Notre accord de niveau de service (English) est public. Il définit des engagements de pourcentage de disponibilité annuelle (Annual Uptime Percentage) et de pourcentage de file d’attente annuel (Annual Queue Percentage), et accorde des crédits de service lorsque les conditions d’éligibilité et de réclamation prévues par l’accord sont remplies.
Pour les équipes financières, le rôle Administrateur de facturation permet à une personne de changer de forfait, de consulter la facturation et l’utilisation, et de mettre à jour l’e-mail de facturation et le moyen de paiement sans disposer de tous les droits d’administration du Workspace.
Premiers pas
Vous pouvez configurer les clés d’accès et les Auth Keys dans la Console. L’authentification unique SAML est en accès anticipé pour les Workspaces Enterprise ; consultez notre page de tarifs pour découvrir les forfaits. Pour activer le SSO, demander le rapport SOC 2 Type II ou parcourir ensemble un questionnaire de sécurité, écrivez à notre équipe commerciale.