Transloadit está listo para empresas
Todos los cuestionarios de seguridad preguntan lo mismo. ¿Quién puede iniciar sesión y cómo se le retira el acceso? ¿Qué puede hacer una clave filtrada? ¿Qué compromisos asumen por escrito? Transloadit ahora tiene una respuesta clara para cada pregunta, así que tu revisión puede pasar al siguiente proveedor.
Inicio de sesión único para tu Workspace
Los miembros de Workspaces Enterprise ahora pueden iniciar sesión en la Console mediante SAML 2.0. Tu proveedor de identidad autentica a los miembros del equipo; la pertenencia al Workspace de Transloadit, las invitaciones y los límites de puestos siguen determinando su acceso.
El SSO está en acceso anticipado, así que empieza por nosotros: envía un email a nuestro equipo de ventas, y lo habilitamos para tu Workspace y te ayudamos a configurarlo. Después, el propietario del Workspace abre Configuración y luego Inicio de sesión único (SAML) en la Console. Allí copia en el proveedor de identidad el ID de entidad de nuestro proveedor de servicios, la URL de ACS y la URL de metadatos, y pega de vuelta en Transloadit el ID de entidad, la URL de SSO, el certificado X.509 y el atributo de email del proveedor de identidad. Los propietarios que inician sesión con contraseña deben confirmarla cuando se necesita una nueva sesión con privilegios elevados. El proveedor de identidad debe firmar sus aserciones y enviar un NameID estable y no transitorio.
Luego, los miembros del equipo eligen Continuar con SSO en la página de inicio de sesión e introducen el slug de su Workspace. Algunos detalles sobre los que suelen preguntar los revisores de seguridad:
- Aprovisionamiento. En la Console, activa Permitir el aprovisionamiento de usuarios justo a tiempo para que las personas sin cuenta de Transloadit se unan con el rol Usuario en su primer inicio de sesión, dentro de los puestos de tu plan, incluidas las invitaciones pendientes. Quien ya tiene una cuenta pero no es miembro necesita una invitación, incluso con esta opción activada. Los nuevos miembros que se unen mediante una invitación de SSO también reciben el rol Usuario; los miembros existentes conservan sus roles. Con el aprovisionamiento desactivado, solo los miembros existentes y las personas invitadas pueden iniciar sesión.
- Baja de usuarios. Deshabilitar a alguien en tu proveedor de identidad bloquea los nuevos inicios de sesión con SSO, pero no una sesión existente ni otro método de inicio de sesión. Elimina por separado su pertenencia al Workspace; su acceso a ese Workspace termina en su siguiente solicitud. Rota o elimina también cada Auth Key cuyo secreto haya creado, visto o al que haya tenido acceso de cualquier otra forma.
- Alcance. El SSO convive con el inicio de sesión con contraseña en lugar de reemplazarlo, y los inicios de sesión comienzan en Transloadit (iniciados por el SP). Los miembros que ya tienen contraseña pueden seguir usándola.
Claves de acceso como tu segundo factor
Antes, la autenticación de dos factores en la Console significaba un código de seis dígitos enviado por email. Ahora puedes usar una clave de acceso en su lugar: Face ID, Touch ID o una llave de seguridad física. Una clave de acceso solo funciona en el sitio para el que se creó, así que una página de inicio de sesión falsa no puede robarla mediante phishing.
En la Console, abre Configuración de usuario, luego Seguridad de inicio de sesión, luego Autenticación de dos factores, elige Clave de acceso y sigue las indicaciones de tu navegador. En una sesión autenticada con contraseña, puedes volver a los códigos por email. Las claves de acceso se aplican a las cuentas que inician sesión con contraseña. Los inicios de sesión con Google, GitHub y SAML dependen, en cambio, de la autenticación y la MFA de su proveedor de identidad.
Actualmente, la Console registra una sola clave de acceso. Para reemplazarla, cambia a los códigos por email en una sesión autenticada con contraseña, luego elige Clave de acceso y registra la nueva. Usa los códigos por email si tu navegador no admite claves de acceso.
Firmar solicitudes con SHA-384
La Signature Authentication demuestra que una solicitud proviene de alguien que tiene tu secreto. Las nuevas Auth Keys para solicitudes de API ordinarias usan HMAC-SHA384 de forma predeterminada. Cada clave tiene su propia configuración de algoritmo. Usa SHA-384 en lugar de SHA-1 para las firmas de nuevas solicitudes de API. Las firmas de URL de Smart CDN usan SHA-256 en su lugar. Las claves con Smart CDN habilitado solo aceptan una restricción a SHA-256 o ninguna restricción por clave; no heredan el valor predeterminado SHA-384 de las claves ordinarias. Cuando una clave tiene una restricción de algoritmo, se rechazan las solicitudes de API firmadas con otro algoritmo. Las claves sin restricción aceptan SHA-1, SHA-256 y SHA-384 para las solicitudes de API. La documentación de autenticación describe el contrato de firma completo.
Usa una clave independiente para firmar con Smart CDN. Si habilitas Smart CDN en una clave existente restringida a SHA-384 sin elegir explícitamente una restricción compatible, esa restricción se elimina y se vuelven a permitir SHA-1, SHA-256 y SHA-384 para las solicitudes de API. Elige una restricción a SHA-256 si habilitas Smart CDN en una clave existente. Esta configuración de solicitudes de API no cambia las firmas de las Assembly Notifications.
Nuestro SDK para Node firma con SHA-384 de forma predeterminada; configura su opción
signatureAlgorithm: 'sha256' para una clave restringida a SHA-256. Si firmas las solicitudes por tu cuenta
con SHA-384, antepón sha384: al digest hexadecimal. Aquí tienes una pequeña función auxiliar
para una clave de API ordinaria con SHA-384 que solo usa crypto y fetch, integrados en Node:
// 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()
}
Este script la usa para crear una Assembly que importa una imagen y la redimensiona:
// 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)
Ejecútalo en tu servidor con una versión compatible de Node.js y una Auth Key con el ámbito
assemblies:write:
$ export TRANSLOADIT_KEY=MY_AUTH_KEY TRANSLOADIT_SECRET=MY_SECRET_KEY
$ node assembly.mjs
ASSEMBLY_EXECUTING 1aa00d5b547b…
La respuesta inicial significa que el procesamiento ha comenzado, no que la miniatura esté lista. Sigue el Assembly Status hasta que se complete o falle. Para esta imagen de ejemplo, una ejecución correcta produce una miniatura de 200×133.
Auth Keys con ámbitos
Una clave que puede hacerlo todo es un riesgo cuando se filtra. Ahora, cada nueva Auth Key necesita
al menos un ámbito. Prefiere ámbitos específicos por área para Assemblies, Templates,
credenciales de Template, Auth Keys, facturación, colas o firma de Smart CDN. Los ámbitos heredados
read y write siguen disponibles, pero otorgan un acceso amplio. Da a cada aplicación y
entorno su propia clave con solo los permisos que necesita, y revoca una sin afectar a las demás.
En la Console, ve a Credenciales y haz clic en Nueva Auth Key. El ajuste preestablecido Entrega privada de imágenes (firma de Smart CDN) crea una clave que puede firmar URL de Smart CDN, pero no puede crear Assemblies independientes ni gestionar Storage. Elige Personalizado para seleccionar los ámbitos por tu cuenta. La API ofrece lo mismo al crear una Auth Key y listar los ámbitos disponibles.
Comprobamos el ámbito en cada llamada. La clave de estos ejemplos puede crear Assemblies, pero no nuevas claves:
// 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)
La API devuelve INSUFFICIENT_AUTH_SCOPE porque esta operación requiere auth_keys:write;
la función auxiliar informa el estado HTTP sin imprimir el cuerpo de la respuesta. Una clave con
ese ámbito obtiene AUTH_KEY_CREATED en su lugar. Trata auth_keys:write como un privilegio administrativo: puede
crear claves con ámbitos más amplios, así que resérvalo para una clave dedicada y estrictamente
protegida. La respuesta de creación correcta también contiene el secreto de la nueva clave, que
este ejemplo deliberadamente no imprime. Guárdalo de forma segura cuando integres la creación de
claves. Configurar can_show_auth_secret durante la creación permite una única revelación posterior, no
una recuperación ilimitada. Si ejecutas el ejemplo con permiso para crear claves, elimina después
la clave de prueba en la Console.
El papeleo
La página de seguridad reúne lo que pide el área de compras:
- SOC 2 Type II. Nuestro informe de atestación está disponible bajo solicitud con un acuerdo de confidencialidad (NDA).
- ISO 27001. Transloadit cuenta con la certificación ISO/IEC 27001.
- SLA. Nuestro acuerdo de nivel de servicio (English) es público. Define compromisos de porcentaje de disponibilidad anual (Annual Uptime Percentage) y porcentaje anual de cola (Annual Queue Percentage), y otorga créditos de servicio cuando se cumplen los requisitos de elegibilidad y de reclamación del acuerdo.
Para los equipos de finanzas, el rol Administrador de facturación permite que alguien cambie el plan, consulte la facturación y el uso, y actualice el email de facturación y el método de pago sin tener todos los derechos de administración del Workspace.
Primeros pasos
Puedes configurar las claves de acceso y las Auth Keys en la Console. El inicio de sesión único SAML está en acceso anticipado para Workspaces Enterprise; consulta nuestra página de precios para ver los planes. Para habilitar el SSO, solicitar el informe SOC 2 Type II o revisar juntos un cuestionario de seguridad, envía un email a nuestro equipo de ventas.