API-Sicherheit & Berechtigungen

Ein API-Zugang ist ein offener Weg in deine teamspace-Daten – mächtig und entsprechend sensibel. Dieser Artikel bündelt die Sicherheitsprinzipien, die in den einzelnen Anleitungen verstreut auftauchen, zu einer Übersicht. Wer API-Zugänge vergibt oder verwaltet, sollte sie kennen.

Grundregel: Die API hat dieselben Rechte wie die Weboberfläche

Ein API-Nutzer hat exakt die Berechtigungen, die er auch in der Web-App hat – nicht mehr und nicht weniger.

Wer in der Oberfläche Projekte löschen darf, kann das auch über die API. Das lässt sich nicht verhindern – und du kannst eine Person auch nicht davon abhalten, sich dafür eine eigene App zu schreiben.
Wer in der Oberfläche keine Zeiten buchen darf, kann das auch über die API nicht.

Die einzige Ausnahme ist der Zugriff über eine API-Zugangsberechtigung (Interface-Authentifizierung): Dort gelten keine Nutzerrechte, sondern ausschließlich die Rechte, die du der Zugangsberechtigung selbst gibst. Genau deshalb ist sie für Geräte und Dienste der sicherere Weg – siehe API-Zugangsberechtigung für Terminals & Dienste.

Konsequenz: Steuere den API-Zugriff einer Person über ihre normalen Berechtigungen in teamspace. Die API ist kein zusätzliches Schlupfloch, aber auch keine zusätzliche Schranke.

Den richtigen Zugangstyp wählen

teamspace kennt zwei Wege, sich an der API zu autorisieren – mit unterschiedlichem Sicherheitsprofil:

Gerätepasswort (persönlicher Zugang): an eine konkrete Person gebunden; die Anwendung handelt mit deren Rechten. Richtig für Skripte und Integrationen im Namen einer Person. Anleitung: Authentifizieren: Gerätepasswort & API-Token.
API-Zugangsberechtigung (neutraler Zugang): an keinen bestimmten Nutzer gebunden; die Rechte werden fein eingestellt. Richtig für Geräte und Dienste wie ein Zeiterfassungsterminal. Anleitung: API-Zugangsberechtigung für Terminals & Dienste.

Faustregel: Geräte und unbeaufsichtigte Dienste bekommen eine neutrale Zugangsberechtigung – nicht das persönliche Passwort eines Mitarbeiters.

Prinzip der minimalen Rechte

Vergib immer nur genau so viele Berechtigungen, wie der konkrete Anwendungsfall benötigt.

Bei der API-Zugangsberechtigung bedeutet das: nur die wirklich gebrauchten Optionen aktivieren. Ein Terminal, das nur ein- und auschecken soll, braucht kein „Detailliert” (Zugriff auf Abwesenheitsdetails wie Krankheit oder Urlaub).
Beschränke das Feld „Mitarbeiter” auf die Personen, die der Zugang tatsächlich betreffen darf.
Bei Gerätepasswörtern: ein eigenes Passwort pro Anwendung, damit sich einzelne Zugänge gezielt sperren lassen.

IP-Adressenschutz

Bei stationären Anwendungen – etwa einem Zeiterfassungsterminal an einem festen Standort – ist ein IP-Adressenschutz sinnvoll. Der Zugang funktioniert dann nur aus dem erlaubten Netz; selbst abgegriffene Zugangsdaten sind von außen wertlos.

Zugänge widerrufen und erneuern

Ein Gerätepasswort lässt sich jederzeit einzeln widerrufen, ohne dass du dein Hauptpasswort änderst – ein klarer Vorteil gegenüber dem Login mit dem persönlichen Passwort.
Das Passwort wird beim Anlegen nur einmal angezeigt. Über „Passwort ändern” erzeugst du es neu; das alte wird damit ungültig. Nutze das, sobald der Verdacht besteht, dass Zugangsdaten kompromittiert wurden.

Zwei-Faktor-Authentifizierung

Ist für ein Konto 2FA aktiviert, lässt sich kein Token mehr direkt über die API (POST api/device) erzeugen. Das Gerätepasswort wird dann über die Weboberfläche angelegt. 2FA erhöht die Sicherheit des Kontos und sollte für Konten mit API-Zugriff aktiv sein.

Voraussetzung „Synchronisation”

Das Anlegen von Gerätepasswörtern setzt die Berechtigung „Synchronisation” voraus. Vergib sie bewusst nur an Konten, die API-Zugriff wirklich brauchen – sie ist faktisch die Eintrittskarte zur API.