Jedes System eine Quelle. Jede Änderung eine Transaktion.

Syntra ist eine Synchronisations- und Automatisierungsplattform. Sie liest die Systeme, die eine Organisation bereits betreibt - Verzeichnisse, Datenbanken, Cloud-Plattformen, Ticketing, Security-Werkzeuge -, hält eine abfragbare, revisionssichere Kopie dessen, was sie vorfindet, transformiert sie und trägt Änderungen über Genehmigungsketten statt über Skripte zurück. Identity & Access ist ihre grösste Stärke. Dieselbe Pipeline führt Konfigurationselemente, Firewall-Regeln, Schwachstellenbefunde und DNS-Einträge mit derselben Disziplin.

Das herkömmliche Modell: eine Suite pro Domäne

Eine IAM-Suite hält die Identitäten. Eine CMDB hält die Assets. Eine Security-Konsole hält die Befunde. Jede definiert ihr eigenes Modell, liefert ihre eigenen Konnektoren, hält ihre Daten in einem Speicher, den nur die eigene Konsole lesen kann, und erwartet, dass sich die Organisation um das Produkt herum neu formt. Am Ende hat der Betrieb drei Kopien der Wahrheit, die nie ganz übereinstimmen, und jede domänenübergreifende Frage - welcher Administrator erreicht welchen Server über welche Firewall-Regel - wird von Hand beantwortet oder gar nicht.

Das Syntra-Modell: eine Pipeline über der eigenen Datenbank

Syntra ist eine Pipeline. Ein Provider liest ein System, ein Consumer schreibt eines, und der Kern dazwischen weiss von keinem der beiden etwas. Was in der Mitte landet, ist eine gewöhnliche SQL-Datenbank mit einer Tabelle pro Entität, Audit-Spalten auf jeder Zeile und dem gesamten Bestand - Identitäten, Assets, Regeln, Befunde - offen für T-SQL, Power BI oder jedes Werkzeug, das mit SQL Server spricht. Domänenübergreifende Fragen werden zu Joins, und was SQL lesen kann, liest Syntra: Power BI für das Reporting, Azure Logic Apps zum Auslösen von Incidents oder jeder andere Abnehmer der Datenbank.

Vier Aufgaben, eine Pipeline

• Datensynchronisation. Verzeichnisbenutzer und -gruppen, Cloud-Subscriptions und Rollenzuweisungen, Service Principals, CMDB-Einträge, Postfächer, Repositories - nach Zeitplan in Tabellen pro Entität gestreamt, vollständig oder als Delta.

• Datentransformation und Auditierung. Schattenkopien halten fest, was eine Quelle zu einem Zeitpunkt gesagt hat, sodass jede Transformation gegen ihre Eingabe geprüft werden kann. Nahezu aktuelle Daten speisen Power BI und Reporting, ohne die Quellsysteme zu belasten.

• Sicherheitsanalyse. Ein gerichteter Graph aus Knoten und typisierten Kanten mit Vertraulichkeits- und Verfügbarkeitsfaktoren, die sich entlang des Graphen vererben. Lateral-Movement-Pfade über Domänen hinweg, Firewall-Exposition und Reichweite von Schwachstellen werden zu Abfragen.

• Identity Governance. Transaktionsbasiertes Änderungsmanagement: eine Operation, eine Vorgängerkette, ein Genehmigungsantrag mit Zustandsautomat und ein protokolliertes Ergebnis. Nichts erreicht ein Zielsystem ohne eine Zeile, die sagt, wer gefragt hat, wer genehmigt hat und was geschehen ist.

Konnektor-agnostisch von Grund auf

Provider und Consumer sind gewöhnliche .NET-Assemblies, die zwei kleine Schnittstellen implementieren. Der Kern löst sie zur Laufzeit per Reflection anhand ihres Namens aus der Konfiguration auf und baut jeden mit dem, was er braucht: seiner Konfiguration, seinem Logger, einem Decryptor für seine Zugangsdaten und - bei einem Provider - den Metadaten des vorherigen Laufs. Ein System an Syntra anzubinden heisst, eine Assembly hinzuzufügen, nicht den Kern zu ändern.

• Ein Provider hat eine Methode: die Entitäten streamen, die er sieht, mit den angefragten Eigenschaften. Wohin sie gehen, weiss er nicht.

• Ein Consumer hat zwei: den Stream eines Providers synchronisieren, dann abschliessen. Woher der Stream kommt, weiss er nicht.

• Jeder Datensatz ist eine IEntity: ein Identifikator, ein Zustand (created, updated, deleted, unclassified) und ein Eigenschaftsbeutel. Das ist der gesamte Vertrag zwischen den beiden Seiten.

• Consumer, die parallel schreiben können, verarbeiten den Stream nebenläufig, begrenzt durch einen konfigurierten Parallelitätsgrad; Consumer, deren Ziel geordnete Schreibvorgänge braucht, verarbeiten ihn sequenziell. Der Provider ändert sich in keinem Fall.

Quellen heute - Identität: Active Directory, Entra ID, Exchange Online. Cloud und Daten: Azure Resources, Azure SQL und SQL Server, Oracle, Azure DevOps. Betrieb: ServiceNow, CMDB. Security: Tenable, Tufin, Infoblox, Ciphersuite.

Ziele heute: SQL Server und Azure SQL, Active Directory, Schema Designer.

Vollständig, wenn es sein muss - Delta, wenn es geht

Eine vollständige Synchronisation streamt alles, was eine Quelle hält, führt es im Ziel zusammen und gleicht dann ab: Zeilen, die die Quelle nicht mehr hat, werden als gelöscht markiert, nie entfernt. Ein Schwellenwert begrenzt, wie viele Zeilen ein Lauf löschen darf - eine Quelle, die wegen eines Ausfalls leer zurückkommt, leert damit nicht das Ziel.

Eine Delta-Synchronisation fragt die Quelle nur nach dem, was sich seit dem letzten Lauf geändert hat. Der Mechanismus ist der, den die Quelle selbst anbietet, und der Provider hält seinen Cursor als opake Metadaten, die der Kern ihm beim nächsten Lauf zurückgibt.

• Active Directory - Update Sequence Number. Ein uSNChanged-Filter gegen die zuletzt gesehene USN.

• Entra ID und Exchange Online - Delta-Token. Der Microsoft-Graph-Endpunkt /delta.

• SQL Server und Oracle - Zeitstempel. Ein Änderungsdatum-Prädikat gegen den letzten Lauf.

• ServiceNow und CMDB - Zeitstempel. Ein REST-Datumsfilter.

• Azure Resources - keiner. Vollständige Synchronisation bei jedem Lauf.

Eine Tabelle pro Entität. Jede Zeile nachvollziehbar.

Synchronisierte Daten landen in Tabellen pro Entität, deren Form der Schema Designer aus der Quelle selbst ableiten kann - auf ein neues System gerichtet, schlägt er die Tabelle vor. Die plattformeigenen Tabellen tragen das Präfix S1 und eine gemeinsame Disziplin: einen Schlüssel, eine Identität, wer jede Zeile wann eingefügt und geändert hat, einen Soft-Delete-Zeitstempel und eine Zeilenversion für die Nebenläufigkeit. Eine Synchronisation entfernt nie etwas physisch.

• Identität und Organisation. Identitäten nach SCIM, Organisationseinheiten, Rollen und typisierte Beziehungen zwischen beliebigen Datensätzen - eine Person zu einem Postfach, ein Server zu einer Firewall-Regel, ein Befund zu einem Verantwortlichen.

• Transaktionen und Genehmigungen. Das Rückgrat des Änderungsmanagements: Operationen, Vorgängerketten, Genehmigungsanträge mit Zustandsautomat, protokollierte Ergebnisse.

• Schatten. JSON-Kopien der Datensätze, wie sie waren, damit eine Transformation gegen das geprüft werden kann, was die Quelle damals gesagt hat.

• Sicherheitsgraph. Knoten und typisierte Kanten mit Vertraulichkeits- und Verfügbarkeitsfaktoren, die sich entlang des Graphen vererben.

• Frontend-Metadaten. Stored Procedures beschreiben ihre eigenen Felder, Typen, Validierungsregeln und Menüstruktur, sodass eine Benutzeroberfläche aus der Datenbank generiert statt gegen sie kompiliert wird.

Die Autorisierung liegt in der Datenbank, nicht in der API

Die REST-API ist bewusst dünn. Sie bildet OData-Abfragen und HTTP-Verben auf Stored Procedures ab und reicht die Identität des Aufrufers an SQL Server durch, statt selbst etwas zu entscheiden. Eine Anfrage wird mit Windows Negotiate oder einem im Namen des Aufrufers getauschten Bearer-Token authentifiziert; die Abfrage läuft dann unter dieser Identität, und Views und Funktionen in der Datenbank entscheiden, welche Zeilen diese Person sehen oder ändern darf. Die API kann nicht gewähren, was die Datenbank verweigern würde - und ein Power-BI-Bericht oder eine T-SQL-Sitzung bekommt genau dieselbe Antwort.

Derselbe Instinkt gilt für die beweglichen Teile rund um den Kern:

• Zugangsdaten sind nie Klartext. Geschützte Werte in der Konfiguration sind mit Keyra verschlüsselt und liegen nach dem Öffnen in gesicherten Speicherpuffern. Konfigurationsdateien können in der Versionsverwaltung liegen.

• Ein Konnektor wird nur geladen, wenn er sagt, was er ist. Der Loader liest das Manifest einer Datei, bevor er sie lädt, und lässt nur Assemblies mit derselben Strong-Name-Identität wie der Kern zu. Der Authenticode-Herausgeber eines Konnektors wird gegen den des Kerns geprüft und bei jedem Laden protokolliert.

• Die Konfiguration entscheidet, was läuft. Ein Deployment aktiviert nur die Konnektoren, die seine Konfiguration nennt - unabhängig davon, was sonst auf der Platte liegt.

• Releases werden offline signiert. Windows-Releases sind mit einem hardwaregebundenen Zertifikat Authenticode-signiert; jedes Archiv ist durch eine veröffentlichte Prüfsumme abgedeckt.

Ein Kern, vier Betriebsarten

Die Synchronisations-Engine hat keine Meinung zu ihrem Host. Derselbe Kern läuft im Terminal, unter einem Dienstmanager, in einem Container oder auf einem Plattformdienst; nur die äussere Hülle ändert sich. Jedes Release ist self-contained, ein Zielsystem braucht also keine installierte .NET-Laufzeit, und nichts wird getrimmt, weil Konnektoren anhand ihres Namens aufgelöst werden.

Windows-Dienst

svcsyntra registriert sich beim Service Control Manager, lädt jede Konfiguration in seinem Ordner Configuration/ und führt jede nach ihrem eigenen Cron-Zeitplan aus. Eine Lease-Datei verhindert, dass derselbe Job zweimal läuft.

Linux-Daemon

Dieselbe ausführbare Datei, für Linux gebaut, bindet sich als Type=notify-Unit in systemd ein: Bereitschaft und Herunterfahren werden dem Dienstmanager gemeldet, Logs gehen ins Journal.

Docker

Der self-contained Linux-Build läuft als Entry Point des Containers, Configuration/ wird als Volume eingebunden. Die systemd-Integration bleibt ausserhalb von systemd inaktiv, der Prozess verhält sich also unter jedem Orchestrator wie ein gewöhnlicher, lang laufender Host.

Azure App Service / Function App

Die REST-API ist eine ASP.NET-Core-Anwendung und wird als solche auf App Service bereitgestellt, mit Identität aus Entra ID und dem On-Behalf-Of-Austausch. Der Diensthost läuft daneben als kontinuierlicher WebJob, wenn die Zeitplanung auf derselben Plattform liegen soll.

Für einen einmaligen Lauf oder einen bereits vorhandenen Scheduler führt CMDSYNTRA eine einzelne Konfiguration von der Kommandozeile aus und beendet sich. Mit --schema läuft stattdessen der Schema Designer: Er liest die Quelle, leitet die Tabelle ab und schreibt nichts.

Suiten, Skripte und Syntra

Eine Suite pro Domäne: geschlossenes Modell, geschlossene Daten

Jedes Produkt besitzt sein Modell und seine Konnektoren. Daten sind über die Konsole und das Reporting dieses Produkts lesbar. Domänenübergreifende Fragen werden von Hand beantwortet, und jede Erweiterung bedeutet das SDK des Herstellers, dessen Release-Zyklus und dessen Lizenz.

• Die Organisation passt sich jedem Produkt an

• Drei Kopien der Wahrheit, die nie ganz übereinstimmen

• Workflow und Audit in jeder Suite eingeschlossen

Geplante Skripte: flexibel, nicht nachvollziehbar

PowerShell- und SQL-Jobs sind schnell geschrieben und schwer zu steuern. Zugangsdaten stehen im Skript, gelöscht ist, was das Skript letzte Nacht getan hat, und der einzige Audit-Trail ist das Log des Schedulers.

• Kein gemeinsames Entitätsmodell über Skripte hinweg

• Jedes Mal ein vollständiger Refresh oder eigene Delta-Logik

• Keine Genehmigung, kein Schwellenwert, keine Schattenkopie

Syntra: offene Pipeline, offene Daten

Konnektoren sind Assemblies; das Modell ist Ihre SQL-Datenbank; Änderungen sind Transaktionen mit Genehmigungen. Identitäten, Assets, Regeln und Befunde liegen an einem Ort, unter einer Audit-Disziplin. Der Kern ist Apache-2.0, und die Daten gehören den Werkzeugen, die Sie bereits nutzen.

• Vollständige und Delta-Synchronisation aus jedem Konnektor

• Soft Delete, Schwellenwerte, Schatten und Audit auf Zeilenebene

• Sicherheitsgraph und datensatzgenaue Autorisierung, durchgesetzt von der Datenbank

• Läuft als Windows-Dienst, Linux-Daemon, Docker-Container oder auf Azure App Service

Kein weiteres Silo. Kein Haufen Skripte. Eine Synchronisationsplattform, die man abfragen kann.

Syntra hält die Daten des Bestands dort, wo die Organisation sie erreicht, und macht jede Änderung an diesem Bestand einer Zeile gegenüber rechenschaftspflichtig, die jemand lesen kann.

Quellcode auf GitHub: https://github.com/PenguinConverters/Syntra

Syntra steht unter der Apache-2.0-Lizenz. Das Keyra SDK ist proprietär und wird separat lizenziert.