Identität & Delegation
Ein zentraler Pfeiler der etg24-Sicherheitsarchitektur ist die explizite Identität jedes Akteurs. Statt generische, unpersönliche Sammel-Tokens zu verwenden, gilt ein klares Prinzip: Jeder automatisierte Prozess, jedes Partnersystem und jeder KI-Agent operiert mit einem eigenen, benannten Schlüssel und einer eindeutigen Identität.
Self-Service-Verwaltung von API-Keys
API-Keys erstellst du eigenständig in der Administrationsoberfläche deiner etg24-App – ohne Support-Tickets oder Freigabeschleifen. Bei der Erstellung vergibst du einen aussagekräftigen Namen, wählst die Akteur-Bindung und definierst die Berechtigungs-Scopes.
Die zwei Dimensionen eines API-Keys
Jeder Schlüssel wird durch zwei voneinander unabhängige Eigenschaften definiert:
1. Akteur-Bindung (In wessen Namen handelt der Key?)
- User-gebunden: Der Agent agiert im Namen einer konkreten Person (z. B. ein KI-Assistent, der für eine Objektbetreuerin Antworten auf Mieteranfragen vorbereitet). Im Audit-Log werden Aktionen dem persönlichen Assistenten dieser Person zugeordnet. Für MCP-Verbindungen nutzen user-gebundene Keys den Endpunkt der Internal API (
https://api.etg24.de/api/internal/v1/mcp). - Tenant-gebunden: Der Agent agiert im Namen des Unternehmens als Organisation (z. B. für nächtliche ERP-Synchronisationen oder automatische Dokumentenverarbeitung). Aktionen werden der Organisationsebene zugerechnet. Bei MCP nutzen tenant-gebundene Keys den Endpunkt der Property Management API (
https://api.etg24.de/propertymanagement/v2/mcp).
2. Zugriffsebene (Was darf der Key ausführen?)
- Read-only: Kann alle berechtigten Lese-Endpunkte (
GET) aufrufen, hat jedoch technisch keinerlei Zugriff auf zustandsändernde Schreib-Befehle (POST). Ideal für Dashboards, Reporting und reine Such-Agenten. - Read/write: Kann berechtigte Queries und freigegebene Commands ausführen. Fachliche Domänen und destruktive Operationen (Löschvorgänge) werden über gesonderte Scopes gesteuert.
| Dimension | Ausprägung A | Ausprägung B |
|---|---|---|
| Akteur-Bindung | User-gebunden (konkrete Person) | Tenant-gebunden (gesamtes Unternehmen) |
| Zugriffsebene | Read-only (nur Lese-Queries) | Read/write (Queries + Commands) |
| MCP-Ziel | .../api/internal/v1/mcp | .../propertymanagement/v2/mcp |
Ein Key pro Agent
Integrationen dürfen keine gemeinsamen Keys teilen. Wenn jeder Bot, jeder Dienstleister und jede Automatisierung einen eigenen Schlüssel erhält, ergeben sich entscheidende Sicherheitsvorteile:
- Gezielte Sperrung im Notfall: Ein kompromittierter oder fehlerhafter Agent kann mit einem Klick deaktiviert werden, ohne andere Workflows zu unterbrechen.
- Transparente Verantwortlichkeit: Logs dokumentieren unmissverständlich, welcher Bot eine Änderung vorgenommen hat.
- Minimalrechte-Prinzip: Jeder Schlüssel erhält exakt nur die Berechtigungen, die er für seine spezifische Aufgabe benötigt.
Details zur Nachvollziehbarkeit findest du unter Audit-Trail & Änderungszuordnung und zur praktischen Verwaltung unter Key-Lebenszyklus.