Zum Inhalt springen
warpbeam

Architektur

Architektur.

Warpbeam ist der Kettbaum, der Ihre Identitäten hält; um ihn herum hat es wie ein Webstuhl feste Teile und eine feste Ordnung. Hier sehen Sie beides: woraus Warpbeam besteht und wie es bei Ihnen laufen soll.

StandDie Bilder zeigen das Zielbild. Jeder Baustein nennt seinen Stand, gemessen am 23. September 2026.

Webstuhl

Jedes Teil ein Baustein.

Der Kettbaum ist Warpbeam selbst. Die übrigen Teile des Webstuhls nutzen wir als Karte: Jedes steht für einen Baustein, von der Streichwalze für den Lebenszyklus bis zum Warenbaum, auf dem der Nachweis entsteht. Wählen Sie ein Teil, um zu sehen, was es tut und wie weit es ist.

  • Heute nutzbar Der Kernablauf läuft in unserer Testumgebung.
  • Im Aufbau Teile laufen, der Kernablauf noch nicht vollständig.
  • Zielbild Entschieden und beschrieben, der Bau steht aus.

Wo wir messen, steht der Reifegrad dabei: 0 fehlt, 1 Grundlage, 2 nutzbar, 3 weitgehend, 4 vollständig. Abdeckung heißt: welcher Anteil der geplanten Funktionen gebaut ist, teilweise Gebautes zählt halb. Gemessen am 23. September 2026; heute liegt keine Fähigkeit über Reifegrad 2.

  1. Kettbaum: Warpbeam selbst

    Heute nutzbar

    Der Kettbaum ist Warpbeam selbst: Er hält alle Fäden an einem Ort, geordnet und gespannt. Sein Kern ist der Identitätskern: der Bestand aller Identitäten mit ihren Rechten und Beziehungen, etwa wer für ein Dienstkonto verantwortlich ist.

    Heute führt Warpbeam Identitäten aus Ihrem vorhandenen Verzeichnis, optional angebunden, und aus weiteren Quellen zusammen. Beziehungen als eigener Dienst sind im Aufbau. Ein eigenes Verzeichnis, mit dem Warpbeam ohne fremdes Verzeichnis auskommt, ist Zielbild.

    • Identitätsbestand Reifegrad 2 von 4 (nutzbar) · Abdeckung 17 %
    • Beziehungen Reifegrad 1 von 4 (Grundlage) · Abdeckung 16 %
  2. Kettfäden: Identitäten

    Im Aufbau

    Jeder Kettfaden ist eine Identität: Beschäftigte, Externe und Partner, Dienstkonten und Anwendungen, Geräte und KI-Agenten. Alle liegen auf demselben Kettbaum und folgen denselben Regeln.

    Warpbeam verwaltet heute die Menschen der eigenen Organisation und Dienstkonten. Externe und Identitäten von Anwendungen sind im Aufbau. KI-Agenten als eigene Identität mit einem verantwortlichen Menschen sind Zielbild, ebenso Geräte.

  3. Streichwalze: Lebenszyklus

    Im Aufbau

    Die Streichwalze hält die Spannung, während die Fäden nachlaufen. Diese Rolle übernehmen in Warpbeam die Quellen und der Lebenszyklus: Eintritt, Wechsel und Austritt kommen aus dem Personalsystem oder einer Liste und sollen überall wirken.

    Teile davon laufen in unserer Testumgebung, aber noch nicht durchgängig von der Quelle bis zum letzten System. Die Prüfung, ob eine neue Identität die ist, für die sie sich ausgibt, bauen wir.

    • Lebenszyklus Reifegrad 1 von 4 (Grundlage) · Abdeckung 15 %
    • Aufnahme und Identitätsprüfung Reifegrad 1 von 4 (Grundlage) · Abdeckung 3 %
  4. Teilstäbe: Ordnung

    Im Aufbau

    Teilstäbe trennen die Fäden, damit sich nichts verheddert. In Warpbeam trennen Stufen die Administratoren der kritischsten Systeme vom Rest, und Mandanten trennen Organisationen voneinander.

    Die Stufen für Administratoren und das zeitweise Anheben von Rechten laufen in Teilen. Wir bauen sie zu einem durchgängigen Ablauf aus. Sitzungen auf Servern (RDP, SSH) sollen über eine eigene Sitzungs-Engine laufen, mit Aufzeichnung.

    • Rechteerhöhung Reifegrad 1 von 4 (Grundlage) · Abdeckung 25 %
  5. Schäfte: Rechte

    Heute nutzbar

    Die Schäfte heben genau die Fäden, die jetzt oben liegen sollen. In Warpbeam entscheiden Rollen und Richtlinien, wer was darf. Privilegierte Rechte gibt es nur auf Zeit und mit Freigabe.

    Rollen, Richtlinien und Rechte auf Zeit sind heute nutzbar. Richtlinien, die im Moment der Anfrage neu entscheiden, bauen wir aus.

    • Rollen und Richtlinien Reifegrad 2 von 4 (nutzbar) · Abdeckung 15 %
    • Entscheidung im Moment Reifegrad 2 von 4 (nutzbar) · Abdeckung 19 %
    • Rechte auf Zeit Reifegrad 2 von 4 (nutzbar) · Abdeckung 18 %
  6. Riet: Anmeldung

    Heute nutzbar

    Das Riet schlägt jeden Schussfaden fest an. Dem entspricht in Warpbeam die Anmeldung: mehrere Faktoren, ein Anmeldeschutz, der verdächtige Versuche anhält, und die Kontrolle über laufende Sitzungen.

    Anmeldeschutz und Faktoren sind heute nutzbar. Ein eigener Anmeldedienst, der Anwendungen über OIDC, OAuth und SAML anmeldet, ist entschieden, mit eigenem Protokollkern; gebaut ist er noch nicht. Er ist die Voraussetzung für den Betrieb ohne fremden Anmeldedienst.

    • Risikobasierte Anmeldung Reifegrad 2 von 4 (nutzbar) · Abdeckung 29 %
    • Starke und passwortlose Anmeldung Reifegrad 2 von 4 (nutzbar) · Abdeckung 13 %
    • Sitzungen Reifegrad 1 von 4 (Grundlage) · Abdeckung 13 %
    • Anmeldung an Anwendungen Reifegrad 1 von 4 (Grundlage) · Abdeckung 5 %
  7. Schütze: KI-Schaltzentrale

    Zielbild

    Der Schütze trägt den Schussfaden quer durch die Kette. In Warpbeam ist das die KI-Schaltzentrale: Sie erklärt, empfiehlt und handelt, aber nur auf der Stufe, die Sie für jede Aufgabe freigeben, von 0 (aus) bis 5 (voll autonom). Voreinstellung ist Stufe 2, Empfehlen.

    Jede Handlung der KI passiert eine Prüfstelle; Protokoll und Notaus lassen sich nie abschalten. Das Sprachmodell soll in Warpbeam selbst laufen, als signiertes Datenpaket. Die Regeln sind entschieden, gebaut ist noch keine KI-Funktion. Heute arbeitet Warpbeam vollständig ohne Sprachmodell.

    KI mit Leitplanken

  8. Schussfaden: Anwendungen

    Im Aufbau

    Der Schussfaden läuft quer durch alle Kettfäden. Bei Warpbeam stehen dafür Ihre Anwendungen und Systeme: Konnektoren binden sie an, damit Konten, Rechte und Anmeldung überall denselben Regeln folgen.

    Konten legt Warpbeam heute in Ihrem vorhandenen Verzeichnis und über SCIM an. Ein Rahmen, der Anwendungen Schritt für Schritt über offene Standards wie SCIM, LDAP, REST, SQL, CSV, OIDC und SAML anbindet, ist im Aufbau.

    • Bereitstellung Reifegrad 2 von 4 (nutzbar) · Abdeckung 17 %
    • Identitäts-Schnittstelle Reifegrad 2 von 4 (nutzbar) · Abdeckung 16 %
  9. Brustbaum: Kontrolle

    Heute nutzbar

    Am Brustbaum sieht man das Gewebe zuerst und prüft es. In Warpbeam ist das die Kontrolle: Rechte regelmäßig bestätigen lassen, riskante Rechte finden und Angriffe auf Identitäten erkennen.

    Bestätigungen, Rechteanalyse und Angriffserkennung sind heute nutzbar. Das Eindämmen erkannter Angriffe und die Prüfung von Konflikten innerhalb einer Anwendung bauen wir aus. Dazu gehört eine eigene Sicherung Ihres vorhandenen Verzeichnisses, aus der sich einzelne Attribute bis zum ganzen Verzeichnis wiederherstellen lassen.

    • Rezertifizierung Reifegrad 2 von 4 (nutzbar) · Abdeckung 12 %
    • Rechteanalyse Reifegrad 2 von 4 (nutzbar) · Abdeckung 30 %
    • Angriffserkennung für Identitäten Reifegrad 2 von 4 (nutzbar) · Abdeckung 19 %
    • Verhaltensanalyse Reifegrad 2 von 4 (nutzbar) · Abdeckung 21 %
    • Anwendungsrisiko Reifegrad 1 von 4 (Grundlage) · Abdeckung 9 %
  10. Warenbaum: Nachweis

    Im Aufbau

    Auf dem Warenbaum wird das fertige Gewebe aufgewickelt. Hier entsteht in Warpbeam der Nachweis: Wer wann was erlaubt hat, Mensch oder KI, bleibt belegbar. Prüfer sollen fragen können, nicht suchen müssen.

    Heute protokolliert Warpbeam Änderungen mit Zeitpunkt und Urheber. Unveränderliche Nachweise und Prüfpakete für gängige Regelwerke sind im Aufbau.

Betrieb

Drei Formen, ein Paket.

Der Warpbeam-Server soll auf Linux laufen, in Containern. Klein auf einer Maschine, hochverfügbar im Verbund oder als Dienst aus Deutschland: Es sollen in jeder Form dieselben signierten Container-Images sein. Windows braucht es dann nur noch als Agent auf Ihrer Seite. In unserer Testumgebung läuft Warpbeam bereits als Linux-Container, on-prem und als Mehrmandanten-Dienst. Erhältlich ist es noch nicht.

Alle drei Formen sind entschieden und beschrieben; gebaut wird zuerst die kleine.

  1. Klein: Ubuntu + Docker

    Im Aufbau

    Die Standardform: eine virtuelle Maschine mit Ubuntu LTS, darin Docker und Warpbeam als Container. Es gibt sie als fertige VM oder als Skript für Ihr eigenes Ubuntu. Ein Befehl installiert, einer aktualisiert, einer geht zurück.

    Härtung, verschlüsselte Datenplatte und Signaturprüfung der Images sind ab Werk eingestellt. In unserer Testumgebung läuft Warpbeam bereits als Linux-Container, on-prem und als Mehrmandanten-Dienst, und wird bei jeder Änderung automatisch geprüft. Die fertige VM und das Installationsskript bauen wir.

  2. Hochverfügbar: Kubernetes

    Zielbild

    Drei solche Maschinen bilden einen Verbund mit Kubernetes (k3s) und einer gespiegelten Datenbank (PostgreSQL mit CloudNativePG). Fällt eine Maschine aus, übernehmen die anderen.

    Es sind dieselben Images wie in der kleinen Form. Wer schon Kubernetes betreibt, nutzt dasselbe Paket dort. Für den Betrieb ohne fremdes Verzeichnis ist diese Form Pflicht, weil Warpbeam dann jede Anmeldung trägt.

  3. SaaS: gehostet in DE

    Zielbild

    Als Dienst ist Warpbeam dieselbe Software, nur betreiben wir sie: bei einem Hoster in Deutschland, Region DE. Die Kunden sind Mandanten auf gemeinsam betriebenen Instanzen.

    Jeder Mandant erreicht Warpbeam unter einer eigenen Adresse und sieht nie die Daten eines anderen. Die Datenbank selbst trennt die Mandanten (Row-Level-Security), jeder Mandant hat eigene Schlüssel, und ein automatischer Trenntest läuft bei jeder Änderung. Auf Ihre Daten greifen wir nur mit Ihrer Freigabe zu, befristet und aufgezeichnet.

    Nur als Dienst gibt es das Migrationswerkzeug: Es zieht Identitäten, Rechte, Postfächer und Dateien zwischen Verzeichnissen, Mailsystemen und Ablagen um, auch in eine souveräne Umgebung. Wer Warpbeam selbst betreibt, bekommt dafür einen befristeten Mandanten.

  4. Windows-Agent: auf Ihren Servern

    Heute nutzbar

    Windows gibt es nur noch auf Ihrer Seite: als kleinen Agenten auf den Servern Ihres vorhandenen Verzeichnisses und auf weiteren Windows-Servern. Er liest dort, was Warpbeam wissen muss, und führt freigegebene Änderungen aus.

    Der Agent baut die Verbindung selbst auf: mTLS, nur ausgehend, mit einem eigenen Zertifikat je Agent. Einen eingehenden Port öffnen Sie dafür nicht. Der Agent läuft heute in unserer Testumgebung.

  5. Linux-Agent: auf Linux-Servern

    Zielbild

    Für Linux-Server ist ein eigener Agent vorgesehen, mit derselben Verbindung: mTLS, nur ausgehend. Er soll Anmeldung, lokale Konten und Richtlinien übernehmen wie der Agent auf Windows.

    Das Wechseln von Kennwörtern privilegierter Konten auf Linux-Servern über SSH ist gebaut, gegen echte Linux-Server aber noch nicht nachgewiesen. Der Agent ist Zielbild.

  6. Anwendungen: offene Standards

    Zielbild

    Anwendungen melden ihre Benutzer über OIDC oder SAML bei Warpbeam an; ältere Anwendungen fragen über LDAPS oder RADIUS. Konten und Rechte kommen über Konnektoren, etwa SCIM.

    Der Anmeldedienst für OIDC und SAML ist entschieden, gebaut ist er noch nicht. LDAP und RADIUS aus dem eigenen Verzeichnis sind Zielbild.

    • Anmeldung an Anwendungen Reifegrad 1 von 4 (Grundlage) · Abdeckung 5 %
  7. Eigenes Modell: optional

    Zielbild

    Das Sprachmodell läuft in Warpbeam selbst (siehe Rollen). Wer schon ein eigenes Modell betreibt, in seinem Rechenzentrum oder bei einem Anbieter seiner Wahl, kann es stattdessen anbinden.

    Auch dorthin gehen nur geschwärzte Daten: Namen, Kennungen und Geheimnisse ersetzt Warpbeam vorher. Ohne Modell arbeitet Warpbeam vollständig weiter. Die Anbindung ist Zielbild.

  8. Schlüssel: HSM optional

    Im Aufbau

    Die wichtigsten Schlüssel gehören in ein Hardware-Sicherheitsmodul. Warpbeam spricht dafür den offenen Standard PKCS#11 und bindet sich an kein bestimmtes Gerät.

    Nicht jeder hat ein solches Modul: Ein eingebauter Software-Schlüsselspeicher ist immer dabei und wird als niedrigere Schutzstufe ausgewiesen. Heute verschlüsselt Warpbeam Geheimnisse mit eingebauten Mitteln; die Anbindung über PKCS#11 ist Zielbild.

    • Geheimnisse Reifegrad 2 von 4 (nutzbar) · Abdeckung 14 %

Die Verbindungen im Bild

Agent → Warpbeam
mTLS, nur ausgehend vom Agenten. Jeder Agent hat ein eigenes Zertifikat.
Anwendungen → Warpbeam
OIDC, OAuth und SAML; LDAPS und RADIUS für ältere Anwendungen.
Warpbeam → Ihr eigenes Modell
optional, nur geschwärzte Daten und nur, wenn Sie es einschalten.
Warpbeam → Schlüssel
PKCS#11 zum Hardware-Sicherheitsmodul oder der eingebaute Software-Speicher.
Ihr Team → Warpbeam
HTTPS im Browser.

Rollen

Ein Paket, eigene Engines.

Jede Fähigkeit soll Warpbeam mit einer eigenen Engine erbringen: Anmeldedienst, Sitzungen auf Servern, Web Application Firewall, Web-Gateway, Protokolldienst und KI. Fremde Produkte sollen nie Voraussetzung sein; heute laufen Sitzungen auf Servern zum Teil noch über eine fremde Komponente. Von außen kommen nur Grundbausteine wie Betriebssystem, Datenbank, Bibliotheken und offene Standards.

Alle Engines sollen im selben Container-Image stecken. Der Kern mit der Datenbank läuft immer, die übrigen Rollen schalten Sie zu, wenn Sie sie brauchen. Im eigenen Betrieb soll Warpbeam dabei kein Modul technisch sperren.

  1. Kern: Rollen web und worker

    Heute nutzbar

    Der Kern ist die Oberfläche im Browser, die Schnittstelle und die Abläufe im Hintergrund, dazu die mitgelieferte Datenbank. Hier laufen auch Engines ohne eigene Rolle: Sicherheitsereignisse sammeln, bewerten und beantworten (SIEM und SOAR), Messwerte als Zeitreihen und Berichte als PDF.

    Oberfläche, Schnittstelle und Abläufe laufen heute in unserer Testumgebung, ebenso eine erste Auswertung von Sicherheitsereignissen. Zeitreihen und PDF-Berichte bauen wir.

    • Abläufe Reifegrad 2 von 4 (nutzbar) · Abdeckung 9 %
    • Sicherheitsereignisse Reifegrad 2 von 4 (nutzbar) · Abdeckung 14 %
  2. Anmeldedienst: Rolle idp

    Zielbild

    Der Anmeldedienst meldet Benutzer an Anwendungen an, über OIDC, OAuth und SAML, mit einem eigenen Protokollkern. Die Signaturschlüssel liegen im Sicherheitsmodul oder im eingebauten Schlüsselspeicher.

    Er ist entschieden und beschrieben, gebaut ist er noch nicht; er ist die Voraussetzung für den Betrieb ohne fremden Anmeldedienst. Kein Sprachmodell entscheidet dort mit.

    • Anmeldung an Anwendungen Reifegrad 1 von 4 (Grundlage) · Abdeckung 5 %
  3. Sitzungs-Gateway: Rolle gateway

    Zielbild

    Administrative Sitzungen auf Servern laufen über eine eigene Sitzungs-Engine für RDP und SSH, im Browser und mit Aufzeichnung. Das Gateway selbst greift nicht auf die Datenbank zu; in getrennten Netzen vermittelt je Zone ein eigenes Gateway.

    Heute vermittelt Warpbeam Sitzungen in Teilen, SSH noch über eine fremde Komponente, die diese Engine ablöst. Aufzeichnungen lassen sich ansehen und aufbewahren, erzeugt werden sie noch nicht. Die eigene Engine für RDP und SSH ist entschieden, gebaut ist sie noch nicht.

    • Sitzungen Reifegrad 1 von 4 (Grundlage) · Abdeckung 13 %
  4. Web-Proxy mit WAF: Rolle wam

    Zielbild

    Der Web-Proxy steht vor Webanwendungen ohne eigene Anmeldung. Er meldet Benutzer an und prüft jede Anfrage mit einer eigenen Web Application Firewall: Regelwerke, Ratengrenzen und Schutz vor automatisierten Angriffen.

    Dieselbe Firewall schützt auch die Endpunkte von Warpbeam selbst. Sie ist Zielbild.

    • Webzugriff Reifegrad 1 von 4 (Grundlage) · Abdeckung 1 %
  5. Web-Gateway: Rolle swg

    Zielbild

    Zugriffe unterwegs und ins Internet laufen über eigene Gateways, in zwei Etappen. Zuerst der Zugang zu Anwendungen nach Identität und Gerät, ohne VPN. Danach ein Web-Gateway, das Adressen nach Kategorien filtert und verschlüsselten Verkehr nur prüft, wenn Sie es einschalten.

    Für die erste Etappe gibt es eine Grundlage, das Web-Gateway ist Zielbild.

    • Zugriff im Netzpfad Reifegrad 1 von 4 (Grundlage) · Abdeckung 6 %
  6. Protokolldienst: Rolle protokoll

    Zielbild

    Ältere Anwendungen und Netzgeräte fragen Warpbeam über LDAP und RADIUS; Sicherheitsereignisse kommen per Syslog herein. Der Dienst hält nur eine lesende Kopie, Kennwörter prüft der Kern.

    Im souveränen Betrieb ist er Pflicht, mindestens zweimal je Standort. Er ist Zielbild.

  7. KI-Laufzeit: Rolle ki

    Zielbild

    Das Sprachmodell läuft in Warpbeam selbst: ein offenes Modell, geliefert als signiertes Datenpaket mit geprüfter Herkunft und Lizenz. Die Rolle hat keinen Zugang zur Datenbank und keine Verbindung ins Internet. Eine Grafikkarte macht sie schneller, nötig ist keine.

    Je Mandant wählen Sie die eingebaute Laufzeit, ein eigenes Modell oder keine KI. In jedem Fall gehen nur geschwärzte Daten an das Modell, und mit Ihren Daten wird kein Modell trainiert. Die KI-Laufzeit ist Zielbild.

    KI mit Leitplanken