Erstellen und sichern Ihrer API-Schlüssel

Der Nachweis für die Authentifizierung Ihrer Anfragen

Ihr API-Schlüssel authentifiziert jede Anfrage, die an die Mistral-Modelle gesendet wird: Ohne ihn wird keine Anfrage akzeptiert. Betrachten Sie ihn als technisches Passwort, das jedoch durch Code, Konfigurationsdateien und Bereitstellungs-Pipelines reist und damit an weit mehr Orten landet als ein herkömmliches Passwort. Jeder, der über den Schlüssel verfügt, kann Ihre Kontingente verbrauchen und Kosten auf Ihrem Konto verursachen.

Erstellen Sie Ihren ersten Schlüssel

Öffnen Sie in der Mistral-Konsole Ihren Arbeitsbereich und navigieren Sie im Seitenbereich zum Abschnitt API-Schlüssel. Klicken Sie auf Neuen Schlüssel erstellen und vergeben Sie einen beschreibenden Namen, beispielsweise dev-chatbot-mars-2026. Dieser Name hat keine technische Funktion, wird Ihnen jedoch helfen, wenn sechs Schlüssel in der Liste koexistieren und Sie genau einen widerrufen müssen: „Schlüssel 3” verrät Ihnen nichts, während dev-chatbot-mars-2026 alles klar macht.

Der Schlüssel wird nur einmal zum Zeitpunkt der Erstellung angezeigt. Kopieren Sie ihn sofort und speichern Sie ihn an einem sicheren Ort. Schließen Sie das Fenster, bevor Sie ihn kopiert haben, und Sie können ihn nicht mehr wiederherstellen: Sie müssen einen neuen erstellen. Ein Mistral-Schlüssel besteht aus einem Präfix gefolgt von einer langen alphanumerischen Zeichenkette. Verwechseln Sie ihn nicht mit Ihrer Arbeitsbereichs-ID oder einem JWT-Token: Im Gegensatz zu letzterem verfällt er nicht von selbst und bleibt gültig, bis Sie ihn widerrufen.

Speichern Sie ihn, ohne ihn jemals im Quellcode zu hardcodieren

Die goldene Regel ist einfach: Hardcodieren Sie Ihren API-Schlüssel niemals im Quellcode. Sobald diese Datei in ein geteiltes Repository landet, landet der Schlüssel mit ihr. Verwenden Sie stattdessen immer eine Umgebungsvariable.

Unter Linux und macOS deklarieren Sie sie im Terminal:

export MISTRAL_API_KEY="your-api-key-here"

Diese Variable verschwindet, wenn Sie das Terminal schließen; um sie persistent zu machen, fügen Sie die Zeile in Ihre Datei ~/.bashrc, ~/.zshrc oder ~/.profile ein.

Unter Windows sieht das PowerShell-Äquivalent so aus:

$env:MISTRAL_API_KEY = "your-api-key-here"

Und um ein Neustarten der Sitzung zu überstehen:

[System.Environment]::SetEnvironmentVariable("MISTRAL_API_KEY", "your-api-key-here", "User")

In einem Anwendungsprojekt ist die gängigste Praxis, eine .env-Datei im Stammverzeichnis zu erstellen:

MISTRAL_API_KEY=your-api-key-here

Fügen Sie .env sofort zu Ihrem .gitignore hinzu – vor Ihrem ersten Commit, nicht danach. In Python liest die Bibliothek python-dotenv diese Datei ein und injiziert die Variablen beim Start, wodurch Sie den Komfort einer lokalen Datei ohne das Risiko der Versionierung von Geheimnissen erhalten.

Rotieren Sie Ihre Schlüssel

Ersetzen Sie einen Schlüssel aus drei Gründen. Sofort, wenn er auf irgendeine Weise offengelegt wurde: ein Commit, das in ein öffentliches Git-Repository hochgeladen wurde, eine hastige Slack-Nachricht oder Spuren in Server-Protokollen. Regelmäßig in der Produktion, wobei ein Intervall von neunzig Tagen ein vernünftiger Rhythmus ist. Und wenn ein Mitarbeiter verlässt, der Zugriff hatte, am selben Tag, an dem er seinen Ausweis zurückgibt.

Das Verfahren vermeidet Unterbrechungen des Dienstes, wenn Sie die Reihenfolge einhalten:

1. Erstellen Sie einen neuen Schlüssel in der Konsole
2. Aktualisieren Sie die Umgebungsvariable in allen Ihren Bereitstellungen
3. Verifizieren Sie, dass alles mit dem neuen Schlüssel funktioniert
4. Widerrufen Sie den alten Schlüssel erst nach dieser Verifizierung

Das Vertauschen der Schritte 3 und 4 ist der klassische Fehler: Sie widerrufen zuerst „zur Sicherheit”, um dann zu entdecken, dass ein vergessener Dienst immer noch den alten Schlüssel verwendet. Diese Rotation ohne Ausfallzeit stellt sicher, dass kein Komponentenausfall während des Übergangs auftritt.

Reduzieren Sie die Angriffsfläche

Wenn mehrere Anwendungen die API aufrufen, erstellen Sie einen Schlüssel pro Anwendung. Wenn einer kompromittiert wird, müssen Sie nur diesen spezifischen Schlüssel widerrufen, ohne die anderen zu stoppen. Nach demselben Prinzip sollten Sie einen Produktionsschlüssel niemals in der Entwicklung wiederverwenden: Das ist genau die Umgebung, in der sich Geheimnisse am freiesten bewegen.

Überwachen Sie im Anschluss die Nutzung über die Konsole, die Nutzungstagebücher für jeden Schlüssel bereitstellt. Ein plötzlicher Anstieg von Tokens oder Aufrufen von einer unbekannten IP-Adresse sollte eine sofortige Rotation auslösen, ohne auf eine Bestätigung des Vorfalls zu warten.

Drei finale Fehler verdienen Erwähnung, da wir sie jede Woche begegnen. Ein Schlüssel, der in ein öffentliches Git-Repository veröffentlicht wurde, bleibt auch nach dem Löschen der Datei in der Historie lesbar: Die einzige gültige Reaktion ist der Widerruf. Ein Schlüssel, der als Klartext per E-Mail oder Instant Messaging gesendet wurde, wird auf Servern, die Sie nicht kontrollieren, für immer archiviert. Und ein abgelaufener oder widerrufener Schlüssel, der in einer Bereitstellung verbleibt, erzeugt 401 Unauthorized-Fehler, die oft eine Stunde zur Diagnose benötigen, einfach weil niemand daran dachte, dies zu prüfen.

Kernaussagen

• Erstellen Sie Ihre Schlüssel im Abschnitt API-Schlüssel Ihres Arbeitsbereichs in der Mistral-Konsole
• Speichern Sie sie ausschließlich in Umgebungsvariablen oder einem Secrets Manager
• Führen Sie regelmäßige Rotationen und eine sofortige Rotation im Falle einer Offenlegung durch
• Erstellen Sie einen Schlüssel pro Anwendung, um die Auswirkungen eines Kompromisses zu begrenzen
• Fügen Sie .env immer zu Ihrem .gitignore hinzu