Sicherheit von E-Mail-API-Schlüsseln: Berechtigungen, Rotation und Speicherung

Ein E-Mail-API-Schlüssel ist eine kurze Zeichenkette mit viel Macht. Wer ihn besitzt, kann E-Mails von Ihrer Domain an beliebige Empfänger in Ihrem Namen senden. Geleakte Schlüssel gehören zu den häufigsten Wegen, auf denen Phishing-Kampagnen über die Infrastruktur seriöser Unternehmen verschickt werden.

Die gute Nachricht: Ein paar Gewohnheiten machen ein Leak unwahrscheinlich und begrenzen den Schaden, falls es doch passiert. Dieser Leitfaden behandelt sie anhand der Einstellungen, die Inbixio jedem Schlüssel mitgibt.

Was ein Inbixio-Schlüssel kann

Jeder Schlüssel, den Sie unter API Keys → Create Api Key (API-Schlüssel → API-Schlüssel erstellen) anlegen, hat drei Einstellungen:

• Name, für Ihre eigene Übersicht, zum Beispiel prod-auth-service.
• Server Access (Serverzugriff): All Server (alle Server; sendet über den ersten SMTP-Server, den Sie verbunden haben) oder Selected Server (ausgewählter Server; genau der, den Sie auswählen).
• Permissions (Berechtigungen): Send (Senden), Read (Lesen) und Manage (Verwalten). Die API hat derzeit einen Endpunkt, den E-Mail-Versand – Send ist also die Berechtigung, die Ihre Dienste brauchen.

Schlüssel haben die Form ibx_ gefolgt von 32 Hexadezimalzeichen. Das Präfix macht sie leicht erkennbar – auch für Secret-Scanner.

Regel 1: ein Schlüssel pro Dienst und Umgebung

Verwenden Sie nicht einen Schlüssel für Ihr ganzes Unternehmen. Erstellen Sie für jeden Dienst und jede Umgebung einen eigenen Schlüssel:

Getrennte Schlüssel bedeuten:

• Ein Leak bleibt begrenzt. Wenn Sie prod-billing widerrufen, fallen die Anmelde-E-Mails nicht aus.
• Jeder Dienst sendet von der richtigen Adresse. Ein Schlüssel, der an den billing@-Server gebunden ist, sendet von billing@ – nicht von dem Server, den Sie zuerst verbunden haben. Löschen Sie einen gebundenen Server, fällt der Schlüssel auf Ihren ersten Server zurück. Binden Sie Schlüssel also neu, wenn Sie Server entfernen.
• Rotation ist schmerzlos. Sie können den Schlüssel eines Dienstes erneuern, ohne die anderen anzufassen.

Regel 2: die geringste Berechtigung vergeben, die funktioniert

Ein Backend, das E-Mails sendet, braucht Send und sonst nichts. Lassen Sie Read und Manage also deaktiviert. Je weniger ein Schlüssel darf, desto weniger kann ein Leak kosten.

Regel 3: Schlüssel gehören auf Server, nie in Clients

Alles, was an einen Browser oder eine mobile App ausgeliefert wird, lässt sich extrahieren – ob minifiziert oder nicht. Dazu gehören:

• JavaScript-Bundles (React, Vue, Next.js-Client-Komponenten),
• Umgebungsvariablen mit Browser-Präfix, etwa NEXT_PUBLIC_, VITE_ oder REACT_APP_,
• iOS- und Android-App-Binärdateien.

Soll eine Nutzeraktion in Ihrem Frontend eine E-Mail auslösen, rufen Sie Ihren eigenen Backend-Endpunkt auf. Ihr Backend prüft, ob der Nutzer das darf, wendet Rate-Limits an und ruft erst dann Inbixio mit dem Schlüssel auf, den es in seiner Umgebung vorhält.

// ✅ Browser → your API → Inbixio
await fetch('/api/invite', { method: 'POST', body: JSON.stringify({ email }) });

// ❌ Never do this in frontend code
fetch('https://backend.inbixio.com/api/send-email/', {
  headers: { 'X-API-Key': 'ibx_…' }, // visible to every visitor
});

Regel 4: Schlüssel wie Passwörter aufbewahren

• Legen Sie Schlüssel in einem Secrets-Manager ab (AWS Secrets Manager, Google Secret Manager, Doppler, 1Password, Vault) oder in den verschlüsselten Umgebungsvariablen Ihrer Plattform.
• Committen Sie sie nie. Nehmen Sie .env in .gitignore auf und aktivieren Sie Secret Scanning für Ihre Repositories; der Push-Schutz von GitHub blockiert viele Leaks, bevor sie passieren.
• Halten Sie Schlüssel aus Logs heraus. Wenn Sie ausgehende Anfragen protokollieren, entfernen Sie vorher den X-API-Key-Header.
• Fügen Sie Schlüssel nicht in Tickets, Chats oder Screenshots ein. Teilen Sie den Zugriff auf das Secret, nicht seinen Wert.

Regel 5: regelmäßig rotieren – und sofort im Zweifelsfall

Inbixio kann einen Schlüssel erneuern: Klicken Sie auf der Seite API Keys auf das Aktualisieren-Symbol daneben. Beim Erneuern wird ein neuer Wert mit demselben Namen, demselben Serverzugriff und denselben Berechtigungen ausgestellt, und der alte Wert funktioniert sofort nicht mehr. So rotieren Sie einen Produktionsschlüssel ohne fehlgeschlagene Sendevorgänge:

1. Erstellen Sie einen zweiten Schlüssel mit denselben Einstellungen (zum Beispiel prod-auth-2).
2. Deployen Sie den neuen Schlüssel für den Dienst und prüfen Sie, dass seine Anfragen 200 zurückgeben, zum Beispiel in Ihren eigenen Anwendungslogs.
3. Löschen Sie den alten Schlüssel.

Nutzen Sie das Aktualisieren-Symbol, wenn Geschwindigkeit wichtiger ist als eine nahtlose Übergabe, etwa direkt nach einem Leak. Rotieren Sie Routineschlüssel alle paar Monate und immer dann, wenn jemand mit Zugriff das Team verlässt.

Wenn ein Schlüssel geleakt wurde

Behandeln Sie es als Sicherheitsvorfall – aber als einen beherrschbaren:

1. Erneuern (Aktualisieren-Symbol) oder löschen Sie den Schlüssel sofort. Damit ist jede Nutzung des alten Werts gestoppt.
2. Prüfen Sie die Logs im Dashboard auf ungewöhnliche Aktivität: Aufrufe zu ungewöhnlichen Zeiten oder ein Anstieg des Volumens. Das Log zeigt, wann Aufrufe erfolgt sind, nicht welcher Schlüssel sie ausgelöst hat – gleichen Sie es daher mit den Logs Ihrer eigenen Dienste ab.
3. Sehen Sie bei Ihrem Mail-Anbieter nach, ob es Bounces oder Spam-Beschwerden zu Nachrichten gibt, die Sie nicht gesendet haben.
4. Finden Sie heraus, wie das Leak entstanden ist – ob über einen Commit, eine Logzeile oder ein Frontend-Bundle – und schließen Sie diesen Weg.
5. Informieren Sie betroffene Nutzer, falls Nachrichten in Ihrem Namen versendet wurden, damit sie diese ignorieren.

Kurze Checkliste

• Ein Schlüssel pro Dienst und Umgebung, mit eindeutigen Namen
• Schlüssel an den Server (die Absenderadresse) gebunden, die der jeweilige Dienst verwenden soll
• Nur die Berechtigung Send für sendende Dienste
• Keine Schlüssel in Frontend-Code, mobilen Apps oder Repositories
• Schlüssel in einem Secrets-Manager gespeichert und aus Logs entfernt
• Ein Rotationstermin im Kalender und ein Plan für Leaks

Sicherheit hält Sie auch aus dem Spam-Ordner heraus: Nachrichten, die über einen kompromittierten Schlüssel gesendet werden, schaden dem Ruf Ihrer Domain. Kombinieren Sie diese Checkliste mit SPF, DKIM und DMARC, um das vollständige Bild zu erhalten.