atrium — technischer Anhang
Sicherheit und Architektur
Für Ihr IT- und Security-Team. Dokumentiert atriums Sicherheits- und Architekturentscheidungen so, wie sie tatsächlich umgesetzt sind. Wo eine Entscheidung aus einem konkreten Sicherheitsgrund fiel, wird dieser Grund ausdrücklich genannt.
Architektur im Überblick
Zwei Sichten: der Request- / Trust-Flow zeigt, wie ein Aufruf verläuft und wo die Sicherheitsgrenzen liegen; die Deployment-Sicht zeigt, welche Software wo läuft und was öffentlich gegenüber privat ist. Eine bebilderte Fassung beider Diagramme finden Sie unter atrium — Funktionsweise.
Ein KI-Client meldet sich über Standard-OAuth an. atriums OAuth-Broker erzeugt eigene, opake und widerrufbare Tokens und delegiert die eigentliche Anmeldung per Certificate Auth an den Identity Provider der Organisation (Entra ID). Anschließend löst atrium die aufrufende Person auf. Die Ausführung erfolgt in einer isolierten Sandbox, die niemals ein rohes Credential enthält: Der Endpoint- bzw. Connector-Code ruft über den Credential-Broker nach außen — dieser ist an genau eine Integration gebunden, entschlüsselt das Credential aus dem verschlüsselten Speicher, hängt die korrekte Authentifizierung selbst an, protokolliert den Zugriff und leitet den Aufruf an das Downstream-System weiter. Das Credential gelangt nie in die Sandbox.
Jeder veröffentlichte Port ist an eine private Adresse gebunden — Datenbank, Vektor-Store und Metriken sind nie aus dem Internet erreichbar. Ein Reverse Proxy mit TLS-Terminierung ist die einzige öffentliche Fläche.
Deployment und Datenresidenz
atrium läuft als kleiner, in sich geschlossener Stack:
- Ein einzelner Application Container (ein Bun + Hono Backend, das ein Angular-Frontend ausliefert), dem ein Reverse Proxy mit TLS-Terminierung vorgelagert ist.
- Eine relationale Datenbank für den Gateway-Zustand (Workspaces, Endpoints, Credentials, Audit-Logs, Tokens).
- Optionale Zusatzdienste — eine Vektor-Datenbank und ein Embeddings-Provider — nur für Wissens-Retrieval-Endpoints. Für das Kern-Gateway sind sie nicht zwingend. Authentifizierung, Credential-Brokering, MCP-Serving und Endpoint-Ausführung funktionieren auch ohne sie.
Die gesamte Infrastruktur wird in EU-Rechenzentren betrieben. Der Verkehr zwischen den Diensten läuft über ein privates Netz; kein Backing-Service (Datenbank, Vektor-Store, Metriken) ist aus dem öffentlichen Internet erreichbar — bestätigt durch ein Public-Exposure-Audit über sämtliche Knoten (siehe „Netzwerk-Exposure“ unten).
Identität: KI-Assistenten authentifizieren sich als echte Personen
Die zentrale Sicherheitseigenschaft: Ein KI-Assistent, der sich mit atrium verbindet, authentifiziert sich als individuelle Nutzer:in über den eigenen Identity Provider der Organisation — per Standard-OAuth. atrium fungiert dabei als OAuth-Broker: Nach außen bietet es die Authorization-Server-Schnittstelle, die der KI-Client erwartet, leitet intern aber zur Anmeldung an den echten Unternehmens-Identity-Provider weiter (im Referenz-Deployment Microsoft Entra ID), inklusive MFA. Jeder Tool-Aufruf über diesen Pfad trägt eine aufgelöste Nutzeridentität.
Erst das macht die übrige Governance echt statt kosmetisch. Zugriffsprotokolle nennen eine Person. Die Verknüpfung von Credentials pro Nutzer:in wird sinnvoll. Ein sofortiger Widerruf trifft genau eine Sitzung.
Aus Gründen der Abwärtskompatibilität existiert weiterhin ein Legacy-Modell mit geteiltem Token, unverändert daneben; Aufrufe darüber tragen nur eine Workspace-Identität, keine individuelle. Neue Deployments sollten den OAuth-Pfad bevorzugen.
Zum aktuellen Umfang, nicht schöngeredet: Die Identity-Provider-Anbindung zielt derzeit auf Microsoft Entra ID — bei der Anmeldung ist atrium heute also an einen Anbieter gebunden. Die Anbindung ist so angelegt, dass weitere Identity Provider ohne Neuschreiben ergänzt werden können, aber das ist eine Architektureigenschaft, kein bereits ausgelieferter zweiter IdP-Connector. (Für die KI-Modell-Seite gilt das Gegenteil: dort ist atrium über MCP Authorization — OAuth 2.1 + PKCE + Dynamic Client Registration — heute schon echt anbieterunabhängig.)
Tokens: opak und sofort widerrufbar
atrium erzeugt eigene Access- und Refresh-Tokens, die die KI-Clients halten. Sie sind bewusst opak, in der Datenbank gespeichert und im Ruhezustand SHA-256-gehasht — keine in sich geschlossenen JWTs.
Die Begründung, in einfachen Worten: Zugriff auf Enterprise- und Behördenniveau heißt, eine Sitzung sofort beenden zu können. Ein signiertes, in sich geschlossenes JWT lässt sich vor seinem Ablauf nur mit einer separaten Sperrliste widerrufen — was den Zweck untergräbt. Opake, nachgeschlagene und gehashte Tokens ermöglichen echten, sofortigen Widerruf. Der Preis ist eine Datenbankabfrage pro Aufruf — bei dieser Größenordnung kein Thema.
Refresh-Token-Rotation ist Pflicht: Jeder Refresh verbraucht das alte Token und stellt ein neues Paar aus; die Wiederverwendung eines bereits verbrauchten Refresh-Tokens gilt als Kompromittierungssignal. Token-Laufzeiten und die erneute Validierung gegen den vorgelagerten Identity Provider sind administrativ konfigurierbar.
Anmeldung am Identity Provider: Zertifikate statt geteilter Secrets
atrium meldet sich am Identity Provider per Certificate Auth an (private_key_jwt, RFC 7523) statt mit einem Client-Secret.
Die Begründung, in einfachen Worten: atrium verlangt von Kund:innen nie, im eigenen Tenant eine Ausnahme für Client-Secrets freizugeben — es meldet sich so an, wie Microsofts eigene Sicherheitsempfehlungen es nahelegen. Client-Secrets werden zunehmend per tenant-weiter Richtlinie blockiert; Zertifikate sind der sicherere Standard, unabhängig vom Identity Provider.
Der private Schlüssel verlässt nie den Server.
Credentials: vermittelter Zugriff, nie direkte Injektion
Wenn ein Endpoint ein Credential braucht, um ein Downstream-System zu erreichen, wird dieses Credential nie an den ausführenden Code übergeben. Stattdessen ruft der Endpoint-Code über einen vermittelnden Broker: einen kurzlebigen lokalen Server, pro Ausführung gestartet, an genau eine vorab aufgelöste Integration gebunden, der die korrekte Authentifizierung selbst anhängt und jeden Versuch abweist, eine andere Integration zu erreichen.
Die Begründung, in einfachen Worten: Die bequeme Abkürzung wäre, das entschlüsselte Credential direkt in die Ausführungsumgebung des Endpoints zu geben. Das wurde bewusst verworfen. Der Code in der Sandbox hält nie einen rohen Credential-Wert — selbst wer Schreibzugriff auf einen geteilten Endpoint hat, kann keinen Code schreiben, um das verknüpfte Credential einer anderen Person abzugreifen. Auf demselben Broker-Muster — derselben Trust-Grenze — baut das Connector-Framework auf.
Der Broker stellt zudem sicher, dass die Authentifizierungs-Header stets Vorrang vor jedem vom Endpoint-Code gesetzten Header haben — so kann der Code das Credential auch nicht versehentlich überschreiben oder fälschen.
Verschlüsselung im Ruhezustand, mit austauschbarer Schlüsselquelle
Credentials sind per Envelope-Verschlüsselung geschützt (AES-256-GCM). Die Quelle des Key-Encryption-Keys ist hinter einer sauberen Schnittstelle austauschbar.
Die Begründung, in einfachen Worten: Standardmäßig kommt ein über die Umgebung bereitgestellter Schlüssel zum Einsatz; dank der Abstraktion lässt sich die Schlüsselquelle aber ohne Schema-Änderung austauschen — etwa gegen ein dediziertes Secrets-Management wie HashiCorp Vault, das eine Behördenausschreibung verlangen kann. Die Souveränität lässt sich so ohne Umbau weiter stärken.
Jede Entschlüsselung eines Credentials — nicht nur jede Änderung — wird mit wer, was und wann in ein Audit-Log geschrieben.
Auditierbarkeit: jeder Zugriff einer Person zuordenbar
Token-Ausstellung, -Refresh und -Widerruf, Einstellungsänderungen, Anmeldungen am Identity Provider und Credential-Zugriffe schreiben alle in ein Audit-Log. Weil Tool-Aufrufe über den OAuth-Pfad eine echte Nutzeridentität tragen, lässt sich die Audit-Spur einzelnen Personen zuordnen — die Grundlage für geplante Aktivitätsansichten pro Nutzer:in. Das ist ein zentrales Governance- und Compliance-Argument: Sie sehen genau, wer wann was aufgerufen hat.
Connector-Framework: Anbindung ohne Code pro Anbieter
Externe Systeme werden über ein typisiertes Connector-Framework eingebunden. Ein Connector ist ein kleines, abhängigkeitsarmes Paket, das eine Reihe von Aktionen beschreibt; entscheidend: Connector-Code spricht nie direkt mit dem Netzwerk und sieht nie ein rohes Credential — jeder Aufruf läuft über denselben vermittelnden Broker. Die Auth-Anbindung einfacher token-basierter Provider ist vollständig datengetrieben (eine Konfigurationszeile statt Code pro Provider). Der Referenz-Connector nutzt pro Nutzer:in delegiertes OAuth.
Netzwerk-Exposure: eine öffentliche Fläche, sonst nichts
Über alle Infrastruktur-Knoten wurde ein Public-Exposure-Audit durchgeführt. Wichtigster Befund: Ein Container, der einen Port veröffentlicht, kann die Firewall des Hosts komplett umgehen, weil die Firewall-Regeln der Container-Runtime vor denen der Host-Firewall greifen. Die überall angewandte Lösung: jeden veröffentlichten Port an eine bestimmte private Adresse binden, statt sich darauf zu verlassen, dass die Host-Firewall einen öffentlich veröffentlichten Port filtert. Ergebnis, aus öffentlicher wie privater Sicht bestätigt: Datenbank, Vektor-Store und Metriken sind nur über das private Netz erreichbar, nie über das öffentliche Internet; die öffentliche Fläche der Anwendung beschränkt sich auf den TLS-terminierenden Reverse Proxy.
Governance-Kontrollen: Freigaben, Grenzen, Obergrenzen
atriums Governance-Modell schichtet mehrere Kontrollen:
- Human-in-the-Loop-Freigabe für Schreib-/Aktions-Endpoints — eine KI-ausgelöste Aktion, die Daten in einem externen System anlegt oder ändert, kann vor der Ausführung eine ausdrückliche Bestätigung verlangen; die Aktion wird protokolliert.
- Eingegrenzter Zugriff — über die Workspace-Grenze hinaus lässt sich Zugriff pro Endpoint und pro Tool steuern, statt über eine einzige pauschale Rolle.
- Rate-Limiting pro Endpoint — eine Obergrenze, wie oft ein Endpoint aufgerufen werden darf, um Fehlerschleifen wie Missbrauch einzudämmen.
- Verwaltung der Workspace-Mitgliedschaft — Administrator:innen steuern manuell, wer zu welchem Workspace gehört und damit, welche Endpoints und Connectors erreichbar sind.
Die Identity-Provider-Anbindung zielt derzeit auf Microsoft Entra ID und ist so angelegt, dass weitere Identity Provider ohne Neuschreiben ergänzt werden können.