Projekt-Token und private Schlüssel
Bei der Integration deiner Anwendung mit dem Monitoring sind zwei Elemente am wichtigsten: das Projekt-Token und der private Schlüssel. Sie erfüllen unterschiedliche Funktionen und sollten nicht als austauschbar behandelt werden.
Projekt-Token
Das Token identifiziert das Projekt, an das gemeldete Ereignisse gehen sollen. Es wird vom Endpoint verwendet, der die Daten entgegennimmt, und ordnet jedes Ereignis der richtigen Anwendung zu.
Das Token allein sollte nicht als einziger Authentifizierungsmechanismus betrachtet werden. Wo eine Integration einen privaten Schlüssel verwendet, sollten beide Elemente gemäß den Sicherheitsrichtlinien aufbewahrt werden.
Privater Schlüssel
Der private Schlüssel dient der Authentifizierung der gesendeten Daten. Behandle ihn wie ein Geheimnis deiner Anwendung: Lege ihn nicht in einem Repository, im Frontend-Code oder an einer für Website-Besucher zugänglichen Stelle ab.
Eine gute Lösung ist, ihn in einer Umgebungsvariable oder in der Serverkonfiguration zu speichern. So erfordert eine Änderung des Schlüssels keine Anpassung des Anwendungscodes.
Ein Projekt kann mehrere Schlüssel haben
Wenn ein Projekt mehrere Umgebungen oder Server bedient, erleichtern separate Schlüssel die Zugriffsverwaltung. Du kannst zum Beispiel einen eigenen Schlüssel für die Produktion und einen weiteren für die Testumgebung verwenden.
Das begrenzt auch die Auswirkungen eines möglichen Lecks. Wenn ein von einem Server verwendeter Schlüssel widerrufen werden muss, musst du nicht die Konfiguration aller anderen Installationen ändern.
Wo findest du die Projektdaten?
Die für die Konfiguration von Integrationen benötigten Informationen findest du in den Projekteinstellungen und im Bereich der API-Schlüssel. Kopiere sie direkt aus dem Panel, statt sie von Hand abzutippen.
Wie übergibst du den Schlüssel an die API?
Integrationen können Anfragen entsprechend dem unterstützten API-Format authentifizieren. Bei direkter Nutzung der REST-API ist es am einfachsten, den Schlüssel als Bearer-Header zu übergeben:
Authorization: Bearer PROJECT_PRIVATE_KEYDas Projekt-Token steht in der Adresse des Endpoints, der private Schlüssel im Authentifizierungs-Header.
Platziere den Schlüssel nicht im Browser
Jeder Code, der im Browser ausgeführt wird, kann von der Nutzerin oder dem Nutzer gelesen werden. Der private Schlüssel sollte daher niemals in JavaScript, HTML oder einem öffentlichen Endpoint landen.
Wenn du Fehler aus dem Browser melden möchtest, sollte die Meldung über dein eigenes Backend laufen. Das Backend besitzt den privaten Schlüssel und leitet die Daten erst dann an das Monitoring-System weiter.
Was tun nach dem Verlust eines Schlüssels?
Wenn du vermutest, dass ein privater Schlüssel offengelegt wurde, behandle ihn wie jedes andere kompromittierte Zugangsdatum. Widerrufe ihn, erzeuge einen neuen und aktualisiere die Konfiguration deiner Anwendung.
Warte nicht auf die Bestätigung eines Missbrauchs. Allein die Tatsache, dass ein Geheimnis in einem öffentlichen Repository, in Logs oder im Frontend-Code gelandet ist, ist Grund genug, es auszutauschen.