Transloadit ist bereit für den Enterprise-Einsatz
Jeder Sicherheitsfragebogen stellt dieselben Fragen. Wer kann sich anmelden, und wie entziehen Sie den Zugang wieder? Was kann ein geleakter Schlüssel anrichten? Wozu verpflichten Sie sich schriftlich? Transloadit hat jetzt auf jede dieser Fragen eine klare Antwort, damit Ihre Prüfung beim nächsten Anbieter weitergehen kann.
Single Sign-on für Ihren Workspace
Mitglieder von Enterprise-Workspaces können sich jetzt per SAML 2.0 in der Console anmelden. Ihr Identity Provider authentifiziert Ihre Teammitglieder; über deren Zugriff entscheiden weiterhin die Mitgliedschaft im Transloadit Workspace, Einladungen und Seat-Limits.
SSO befindet sich im Early Access, daher beginnt es bei uns: Schreiben Sie unserem Vertriebsteam, dann aktivieren wir SSO für Ihren Workspace und helfen Ihnen bei der Einrichtung. Anschließend öffnet der Workspace-Inhaber in der Console Einstellungen und dann Single Sign-on (SAML). Dort werden unsere Service-Provider-Entity-ID, ACS-URL und Metadaten-URL in den Identity Provider kopiert und die Entity-ID, die SSO-URL, das X.509-Zertifikat und das E-Mail-Attribut des Identity Providers zurück in Transloadit eingefügt. Inhaber, die sich mit einem Passwort anmelden, müssen es bestätigen, wenn eine neue Sitzung mit erweiterten Rechten nötig ist. Der Identity Provider muss seine Assertions signieren und eine stabile, nicht transiente NameID senden.
Ihre Teammitglieder wählen dann auf der Anmeldeseite Mit SSO fortfahren und geben ihren Workspace-Slug ein. Einige Details, nach denen Sicherheitsprüfer häufig fragen:
- Provisionierung. Aktivieren Sie in der Console Just-in-Time-Benutzerbereitstellung zulassen, damit Personen ohne Transloadit-Konto bei ihrer ersten Anmeldung mit der Rolle „User“ beitreten können, solange Ihr Tarif dafür noch Seats frei hat; ausstehende Einladungen zählen mit. Wer bereits ein Konto hat, aber kein Mitglied ist, braucht auch bei aktivierter Option eine Einladung. Neue Mitglieder, die über eine SSO-Einladung beitreten, erhalten ebenfalls die Rolle „User“; bestehende Mitglieder behalten ihre Rollen. Ist die Provisionierung deaktiviert, können sich nur bestehende Mitglieder und eingeladene Personen anmelden.
- Offboarding. Wenn Sie eine Person in Ihrem Identity Provider deaktivieren, blockiert das neue SSO-Anmeldungen, aber weder eine bestehende Sitzung noch eine andere Anmeldemethode. Entfernen Sie ihre Workspace-Mitgliedschaft separat; ihr Zugriff auf diesen Workspace endet mit ihrer nächsten Anfrage. Rotieren oder löschen Sie außerdem jeden Auth Key, dessen Secret die Person erstellt oder eingesehen hat oder auf das sie anderweitig Zugriff hatte.
- Umfang. SSO ergänzt die Anmeldung per Passwort, statt sie zu ersetzen, und Anmeldungen beginnen bei Transloadit (SP-initiiert). Mitglieder, die bereits ein Passwort haben, können es weiterhin verwenden.
Passkeys als zweiter Faktor
Zwei-Faktor-Authentifizierung in der Console bedeutete bisher einen sechsstelligen Code per E-Mail. Jetzt können Sie stattdessen einen Passkey verwenden: Face ID, Touch ID oder einen Hardware-Sicherheitsschlüssel. Ein Passkey funktioniert nur auf der Website, für die er erstellt wurde, sodass eine täuschend ähnliche Anmeldeseite ihn nicht abphishen kann.
Öffnen Sie in der Console Benutzereinstellungen, dann Anmeldesicherheit und dann Zwei-Faktor-Authentifizierung, wählen Sie Zugangsschlüssel und folgen Sie der Aufforderung Ihres Browsers. In einer per Passwort authentifizierten Sitzung können Sie wieder zu E-Mail-Codes wechseln. Passkeys gelten für Konten, die sich mit einem Passwort anmelden. Bei Anmeldungen über Google, GitHub und SAML greifen stattdessen die Authentifizierung und MFA des jeweiligen Identity Providers.
Die Console registriert derzeit einen einzigen Passkey. Um ihn zu ersetzen, wechseln Sie in einer per Passwort authentifizierten Sitzung zu E-Mail-Codes, wählen dann Zugangsschlüssel und registrieren den neuen Passkey. Verwenden Sie E-Mail-Codes, wenn Ihr Browser keine Passkeys unterstützt.
Anfragen mit SHA-384 signieren
Signature Authentication belegt, dass eine Anfrage von jemandem stammt, der Ihr Secret besitzt. Neue Auth Keys für gewöhnliche API-Anfragen verwenden standardmäßig HMAC-SHA384. Jeder Schlüssel hat eine eigene Algorithmus-Einstellung. Verwenden Sie für neue Signaturen von API-Anfragen SHA-384 statt SHA-1. Signaturen für Smart-CDN-URLs verwenden dagegen SHA-256. Schlüssel mit aktiviertem Smart CDN akzeptieren nur eine SHA-256-Beschränkung oder keine schlüsselspezifische Beschränkung; sie übernehmen nicht den SHA-384-Standard gewöhnlicher Schlüssel. Sobald ein Schlüssel eine Algorithmus-Beschränkung hat, werden API-Anfragen abgelehnt, die mit einem anderen Algorithmus signiert sind. Schlüssel ohne Beschränkung akzeptieren für API-Anfragen SHA-1, SHA-256 und SHA-384. Die Dokumentation zur Authentifizierung beschreibt die vollständigen Regeln für das Signieren.
Verwenden Sie für das Signieren mit Smart CDN einen separaten Schlüssel. Wenn Sie Smart CDN für einen bestehenden, auf SHA-384 beschränkten Schlüssel aktivieren, ohne ausdrücklich eine kompatible Beschränkung zu wählen, wird diese Beschränkung aufgehoben, und für API-Anfragen sind wieder SHA-1, SHA-256 und SHA-384 zulässig. Wählen Sie eine SHA-256-Beschränkung, wenn Sie Smart CDN für einen bestehenden Schlüssel aktivieren. Diese Einstellungen für API-Anfragen ändern nichts an den Signaturen von Assembly Notifications.
Unser Node SDK signiert standardmäßig mit SHA-384; setzen Sie für einen auf SHA-256
beschränkten Schlüssel seine Option signatureAlgorithm: 'sha256'. Wenn Sie Anfragen selbst
mit SHA-384 signieren, stellen Sie dem Hex-Digest sha384: voran. Hier ist eine kleine
Hilfsfunktion für einen gewöhnlichen SHA-384-API-Schlüssel, die ausschließlich crypto und fetch aus dem Lieferumfang von Node verwendet:
// 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()
}
Dieses Skript erstellt damit eine Assembly, die ein Bild importiert und seine Größe ändert:
// 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)
Führen Sie es auf Ihrem Server mit einem unterstützten Node.js-Release und einem Auth Key mit dem
Scope assemblies:write aus:
$ export TRANSLOADIT_KEY=MY_AUTH_KEY TRANSLOADIT_SECRET=MY_SECRET_KEY
$ node assembly.mjs
ASSEMBLY_EXECUTING 1aa00d5b547b…
Die erste Antwort bedeutet, dass die Verarbeitung begonnen hat, nicht dass das Thumbnail fertig ist. Verfolgen Sie den Assembly Status, bis die Assembly abgeschlossen oder fehlgeschlagen ist. Bei diesem Beispielbild entsteht bei erfolgreichem Abschluss ein Thumbnail im Format 200×133.
Auth Keys mit Scopes
Ein Schlüssel, der alles darf, wird zum Risiko, wenn er geleakt wird. Jeder neue Auth Key benötigt
jetzt mindestens einen Scope. Bevorzugen Sie bereichsspezifische Scopes für Assemblies, Templates,
Template-Zugangsdaten, Auth Keys, Abrechnung, Queues oder das Signieren mit Smart CDN. Die
Legacy-Scopes read und write sind weiterhin verfügbar, gewähren aber weitreichenden Zugriff.
Geben Sie jeder App und jeder Umgebung einen eigenen Schlüssel mit nur den Berechtigungen, die sie
braucht, und widerrufen Sie einzelne Schlüssel, ohne die anderen anzutasten.
Gehen Sie in der Console zu Zugangsdaten und klicken Sie auf Neuer Auth Key. Die Voreinstellung Private Bildauslieferung (Smart-CDN-Signierung) erstellt einen Schlüssel, der Smart-CDN-URLs signieren, aber weder eigenständige Assemblies erstellen noch Storage verwalten kann. Wählen Sie Individuell, um die Scopes selbst auszuwählen. Über die API erreichen Sie dasselbe, indem Sie einen Auth Key erstellen und die verfügbaren Scopes auflisten.
Wir prüfen den Scope bei jedem Aufruf. Der Schlüssel hinter diesen Beispielen kann Assemblies erstellen, aber keine neuen Schlüssel:
// 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)
Die API gibt INSUFFICIENT_AUTH_SCOPE zurück, weil dieser Vorgang auth_keys:write erfordert;
die Hilfsfunktion meldet den HTTP-Status, ohne den Antwortkörper auszugeben. Ein Schlüssel mit
diesem Scope erhält stattdessen AUTH_KEY_CREATED. Behandeln Sie auth_keys:write als administratives Privileg: Damit
lassen sich Schlüssel mit weitreichenderen Scopes erstellen, reservieren Sie diesen Scope also für
einen dedizierten, streng geschützten Schlüssel.
Die Antwort auf eine erfolgreiche Erstellung enthält außerdem das Secret des neuen Schlüssels, das
dieses Beispiel bewusst nicht ausgibt. Speichern Sie es sicher, wenn Sie die Schlüsselerstellung
integrieren. Wenn Sie bei der Erstellung can_show_auth_secret setzen, ist eine einzige spätere Anzeige möglich,
kein unbegrenzter Abruf. Wenn Sie das Beispiel mit der Berechtigung zum Erstellen von Schlüsseln
ausführen, löschen Sie den Testschlüssel anschließend in der Console.
Der Papierkram
Die Sicherheitsseite bündelt, was der Einkauf verlangt:
- SOC 2 Type II. Unser Prüfbericht ist auf Anfrage unter NDA erhältlich.
- ISO 27001. Transloadit ist nach ISO/IEC 27001 zertifiziert.
- SLA. Unser Service Level Agreement (English) ist öffentlich. Es legt Zusagen zu Annual Uptime Percentage und Annual Queue Percentage fest und gewährt Service-Gutschriften, wenn die im SLA festgelegten Anspruchs- und Antragsvoraussetzungen erfüllt sind.
Für Finanzteams gibt es die Rolle „Billing Admin“: Damit kann eine Person den Tarif ändern, Abrechnung und Nutzung einsehen sowie die Rechnungs-E-Mail-Adresse und die Zahlungsmethode aktualisieren, ohne volle Admin-Rechte für den Workspace zu haben.
Erste Schritte
Passkeys und Auth Keys können Sie in der Console konfigurieren. SAML-Single-Sign-on befindet sich für Enterprise-Workspaces im Early Access; die Tarife finden Sie auf unserer Preisseite. Wenn Sie SSO aktivieren, den SOC-2-Type-II-Bericht anfordern oder gemeinsam einen Sicherheitsfragebogen durchgehen möchten, schreiben Sie unserem Vertriebsteam.