API-Keys lassen sich direkt in den Kontoeinstellungen erstellen. Die Antwort enthält den Rohschlüssel genau einmal; wir speichern ihn niemals im Klartext. Was wir persistieren, ist eine gehashte Version des Keys — ausreichend, um ihn bei künftigen Requests wiederzuerkennen, ohne das Geheimnis preiszugeben, selbst wenn unsere Systeme einmal kompromittiert würden.
Keys sind eine sicher generierte Zeichenfolge mit hoher Entropie und lassen sich daher weder erraten noch per Brute-Force ermitteln. Jeder Key erhält außerdem eine Rolle sowie ein optionales Ablaufdatum, die Sie beim Erstellen selbst festlegen. Das genaue Anfrageformat für die Integration in die API finden Sie in der Crowdee-API-Dokumentation.
Ein Key kann auf eine oder mehrere bestimmte Organisationen beschränkt werden. Ist ein Key org-gescoped, funktioniert er nur für Requests an diese Organisationen. Ein nicht gescopter Key kann für alle Organisationen verwendet werden, denen Sie angehören.
Die tatsächlichen Berechtigungen eines Keys werden immer durch zwei Dinge begrenzt: die Rolle, die Sie dem Key zugewiesen haben, und Ihre eigene tatsächliche Mitgliedsrolle in der Organisation, gegen die der Key verwendet wird. In der Praxis bedeutet das: Ein Key kann Ihnen nie mehr Zugriff verschaffen, als Sie selbst besitzen. Haben Sie in einer Organisation eine Standardrolle und stellen versehentlich einen Key mit einer höheren Rolle aus, bleiben Requests mit diesem Key in dieser Organisation trotzdem auf das beschränkt, was Ihre Standardrolle erlaubt. Das ist eine bewusste Designentscheidung: Keys sind als Zugangsdaten gedacht, nicht als Mittel, um die eigenen Rechte zu erweitern.
Jeder Request wird gegen die aufgelöste Rolle geprüft, bevor irgendetwas anderes passiert — Berechtigungen werden also unabhängig davon, welcher Key oder welche Sitzung verwendet wird, immer konsistent durchgesetzt.
Viele Crowdee-Nutzer — insbesondere Personen, die über mehrere Kundenkonten hinweg arbeiten — gehören mehr als einer Organisation an. Crowdee merkt sich, welche Organisation für einen bestimmten Request „aktiv" ist: Bei einem org-gescopten API-Key ist das schlicht die Organisation, auf die der Key beschränkt ist; bei einer regulären, angemeldeten Sitzung ist es die Organisation, die Sie gerade ausgewählt haben.
Ein Organisationswechsel erfordert kein erneutes Ab- und Anmelden. Sie wählen einfach eine andere Organisation aus, und Ihre Berechtigungen sowie die sichtbaren Daten werden sofort für diesen Kontext aktualisiert.
Diese aktive Organisation ist es, die Ihre Daten sauber trennt: Ein Projekt, das in einer Organisation liegt, ist für einen Request, der an eine andere Organisation gebunden ist, niemals sichtbar — unabhängig davon, welcher Key oder welche Sitzung verwendet wird. Ihre tatsächlichen Berechtigungen werden dabei immer frisch für die Organisation berechnet, in der Sie gerade arbeiten.
Aus Integrationsperspektive ist diese Trennung größtenteils unsichtbar — im positiven Sinn. Eine Client-Anwendung, die einen auf eine einzelne Organisation gescopten Key verwendet und diesen Kontext konsequent bei jedem Request nutzt, greift niemals versehentlich auf die Daten eines anderen Kunden zu. Das Scoping auf Key-Ebene ist eine zusätzliche Schutzschicht obendrauf auf die strikte Datentrennung, die Crowdee ohnehin auf Datenbankebene zwischen Organisationen durchsetzt.
Für anspruchsvollere Anwendungsfälle — etwa Automatisierungsskripte, die über mehrere Kundenorganisationen hinweg arbeiten müssen — empfiehlt sich das Muster, pro Organisation einen eigenen Key auszustellen und für jeden Request den passenden zu wählen. Das vermeidet jede Mehrdeutigkeit und hält Ihren Audit-Trail sauber, da die Aktivität jedes API-Keys eindeutig einer einzigen Organisation zugeordnet ist.
Keys werden niemals im Klartext gespeichert. Selbst im unwahrscheinlichen Fall eines Datenlecks gibt es also keine nutzbaren Zugangsdaten preiszugeben — nur Hashes, die sich nicht in funktionierende Keys zurückverwandeln lassen.
Ablaufdaten werden bei jedem Request durchgesetzt: Sobald ein Key abläuft, funktioniert er sofort nicht mehr, auch wenn wir zu Audit-Zwecken einen Eintrag darüber behalten, statt ihn vollständig zu löschen. Organisations-Scoping wird auf dieselbe Weise durchgesetzt — ein Key funktioniert schlicht nicht für eine Organisation, für die er nicht ausgestellt wurde, unabhängig von allen anderen Eigenschaften des Keys. In Summe — keine Klartextspeicherung, Rollengrenzen, Organisations-Scoping und Ablaufdaten — sorgt dafür, dass ein geleakter Key nur einen eng begrenzten Schaden anrichten kann, sowohl zeitlich als auch im Umfang.
Artikel teilen:
