Sicherheit und Datenschutz
Wie BatteryPass den API-Zugang und die Passdaten schützt und was Ihre Integration tun und vermeiden sollte.
Diese Seite beschreibt die technischen Maßnahmen, die für Integrationen gelten, und wofür Sie auf Ihrer Seite verantwortlich sind. Sie ist eine Beschreibung, keine Zertifizierung und keine Prüfbestätigung.
Transport
Produktive BatteryPass-Installationen laufen über HTTPS; die Referenz-Bereitstellung beendet TLS an ihrem Reverse
Proxy und sendet Strict-Transport-Security. Senden Sie API-Schlüssel nur per HTTPS an Ihre BatteryPass-Adresse,
und schalten Sie die Zertifikatsprüfung in Ihrem HTTP-Client nicht ab.
API-Schlüssel
| Maßnahme | Detail |
|---|---|
| Geheimnis | bp_live_ gefolgt von 43 base64url-Zeichen (32 Zufallsbytes) |
| Speicherung | BatteryPass speichert nur den SHA-256 des Schlüssels. Der Schlüssel wird einmal angezeigt, wenn ein Inhaber ihn im Portal anlegt; danach lässt er sich nicht mehr anzeigen. |
| Wiedererkennung | Die ersten 12 Zeichen (bp_live_ und vier weitere) bleiben als Präfix erhalten, damit Inhaber Schlüssel im Portal unterscheiden können. |
| Nur im Header | Schlüssel werden nur in Authorization: Bearer angenommen, nie in einer URL. Eine Anfrage mit Sitzungs-Cookie und Schlüssel zugleich wird mit 401 abgelehnt. |
| Laufzeit | Schlüssel laufen nicht ab. Nur ein Widerruf stoppt einen Schlüssel; ein widerrufener Schlüssel funktioniert nie wieder. Zum Wechseln legen Sie einen neuen Schlüssel an und widerrufen den alten. |
| Anzahl | Höchstens 25 aktive Schlüssel je Organisation. |
Inhaber legen Schlüssel im Portal an, widerrufen sie dort und sehen, wann jeder Schlüssel zuletzt benutzt wurde. Siehe Authentifizierung und Schlüssel sicher verwalten.
Was ein Schlüssel darf
- Scopes. Ein Schlüssel hat einen oder mehrere der Scopes
read,conditionundimport. Jede Operation nennt ihren Scope inx-api-key-scope; ein Schlüssel ohne diesen Scope erhält403 forbidden. Geben Sie jedem System nur den Scope, den es braucht. - Rechte eines Betrachters. Ein Schlüssel handelt in seiner Organisation mit den Rechten eines Betrachters. Er ändert nie deklarierte Daten, gibt keine Werte frei, veröffentlicht oder zieht keine Pässe zurück und verwaltet weder Mitglieder noch Schlüssel noch Einstellungen.
- Trennung der Organisationen. Jede Anfrage ist auf die Organisation des Schlüssels beschränkt. Ids von
Ressourcen einer anderen Organisation verhalten sich, als gäbe es sie nicht (
404 not_found).
Ratenlimits
| Limit | Gilt für |
|---|---|
| 600 Anfragen pro Minute | Alle Schlüssel einer Organisation zusammen |
| 30 Versuche pro 15 Minuten | Unbekannte oder widerrufene Schlüssel, je Client-Adresse |
| 300 Anfragen pro Minute | Öffentliche Passabfragen, öffentliche Dokumente und den Resolver, je Client-Adresse |
Eine begrenzte Anfrage erhält 429 rate_limited mit dem Header Retry-After in Sekunden
(Ratenlimits).
Audit
Jeder Schreibvorgang mit einem Schlüssel (eine Zustandsmeldung oder ein Lebenszyklus-Ereignis) wird im Audit-Log
der Organisation mit dem Akteur api_key und der Id des Schlüssels festgehalten, in derselben Transaktion wie die
Änderung. Die entstehenden Werte und Ereignisse tragen source api; das Lebenszyklus-Ereignis jeder Meldung nennt den
Schlüssel (api_key). Anlegen und
Widerrufen von Schlüsseln wird mit dem handelnden Mitglied protokolliert. Lesezugriffe mit einem Schlüssel werden
nicht protokolliert.
Passdaten
- Öffentliche Operationen und der Resolver liefern nur die gespeicherte Projektion
publiceiner Version (Zugriffsstufen). Eingeschränkte Stufen erscheinen nie in einer öffentlichen Antwort, und eingeschränkte Dokumente werden dort nie verlinkt. - Das Lesen eingeschränkter Stufen durch Dritte ist eine eigene Portal-Funktion hinter einem standardmäßig ausgeschalteten Schalter; jeder solche Zugriff wird protokolliert.
- Jede veröffentlichte Version ist signiert, nachträgliche Änderungen sind also erkennbar (Signaturen).
- Fehler sind Problem Details mit stabilem
codeund einerrequest_id; sie enthalten kein SQL, keine Stacktraces und keine Fehlertexte von Drittsystemen (Fehler).
Datenschutz für Integrationen
In BatteryPass geht es um Batterien, nicht um Menschen, und Ihre Integration sollte das beibehalten.
Senden Sie keine personenbezogenen Daten in Freitextfeldern, also in note einer Zustandsmeldung und in
description eines Lebenszyklus-Ereignisses. Schreiben Sie „Modul 3 getauscht“ statt Name, Adresse, Telefonnummer oder Kennzeichen
des Technikers oder Endkunden. Ereignisse und Messwerte lassen sich über die API weder bearbeiten noch löschen,
jedes Mitglied Ihrer Organisation kann sie lesen, und sie sind Teil des vollständigen Exports der Organisation.
Auch was Sie lesen, kann personenbezogene Daten enthalten: Die Herkunft nennt Mitglieder (recorded_by,
reviewed_by, responsible, published_by_name), und ein Ereignis, das ein Servicepartner gemeldet hat, kann
dessen E-Mail-Adresse tragen. Übernimmt Ihre Integration solche Daten in ein anderes System, braucht dieses System
dafür eine Rechtsgrundlage und eine Löschregel. Übernehmen Sie nur, was Sie brauchen.
Diese Dokumentation
Die Seiten dieser Dokumentation laden keine Analyse-, Werbe- oder Tracking-Skripte Dritter. Die Menüeinträge, die eine Seite in einem KI-Assistenten öffnen, senden die Adresse der Seite erst an diesen Dienst, wenn Sie sie anklicken.
Ein Sicherheitsproblem melden
Vermuten Sie, dass ein Schlüssel offengelegt wurde, bitten Sie einen Inhaber Ihrer Organisation, ihn sofort zu widerrufen und einen neuen anzulegen. Eine vermutete Schwachstelle melden Sie direkt dem Betreiber Ihrer BatteryPass-Installation, nicht in einem gemeinsamen Kanal (Support).