Trust-Zonen getrennt halten
Tiers, Forests, Domains, CAs und Netzsegmente behalten eigene Grenzen und Konnektorwege.
ENTERPRISE TRUST ARCHITEKTUR
Viele Trust-Domänen. Ein kontrollierter Identitäts-Lifecycle.
SYNRION x.ID verbindet lokale Active-Directory-Forests über LDAP Connector und Microsoft Entra ID nativ über Azure Connector mit Hardware, Policies, Zertifizierungsstellen und verteilten Outposts.
NUTZEN IN 30 SEKUNDEN
Kontrolle skalieren, ohne Trennung aufzuheben.
Ein Identitätsmodell verbinden
Primär- und Sekundäridentitäten bleiben über lokale AD-Forests, Microsoft Entra ID, administrative Rollen und getrennte Umgebungen verantwortlich zugeordnet.
Policy konsistent anwenden
Unabhängige Freigabe, Hardwarenachweis und Lifecycle-Regeln bleiben über Ausgabesysteme und Standorte hinweg verständlich.
KONTROLLE ÜBER TRUST-GRENZEN HINWEG
Wie bleibt eine große Identitätsarchitektur verständlich und durchsetzbar?
Enterprise-Größe ist kein vergrößertes Single-Server-Diagramm. Sie ist eine bewusste Verteilung von Trust, Konnektorverantwortung und Hardwareschutz um einen konsistenten Identitäts-Lifecycle.
-
01
Tiers, Forests und Domains abbilden
Administrative Grenzen bestimmen, die getrennt bleiben müssen, und die Primäridentitäten zuordnen, die für Rollen darin verantwortlich sind.
-
02
AD DS und Microsoft Entra ID getrennt anbinden
Jeden lokalen Forest über den passenden LDAP-Connector-Weg und Microsoft Entra ID direkt über den nativen Azure Connector in den Lifecycle aufnehmen.
-
03
Interne und öffentliche CAs abbilden
Jeden Zertifikats-Anwendungsfall mit seiner vorgesehenen Zertifizierungsstelle, seinem Profil und seiner Trust-Zielgruppe verbinden.
-
04
Outposts nach Verantwortung platzieren
CA-, LDAP- und Policy-Funktionen in den Zonen betreiben, in denen sie ihre Aufgabe mit minimalem Zugriff erfüllen; den Azure Connector als nativen Cloud-Pfad getrennt ausweisen.
-
05
Menschen, Hardware und Rollen binden
Jede administrative oder betriebliche Identität mit der verantwortlichen Person und freigegebener Sicherheitshardware verbunden halten.
-
06
Service- und CA-Schlüssel in Hardware schützen
Maschinen- und Service-Identitäten als vollwertige Trust-Objekte behandeln und privilegierte private Schlüssel im HSM schützen.
-
07
Jeden Zustandswechsel nachvollziehbar halten
Identitäten konsistent ausgeben, erneuern, sperren, ersetzen und entfernen, auch wenn Zielsysteme und CAs verschieden sind.
DIE ARCHITEKTUR AUF EINEN BLICK
Forests, Domains, Tiers und CAs getrennt halten – den Lifecycle gemeinsam steuern.
TECHNISCHE TIEFE
Enterprise-Größe bedeutet kontrollierte Verteilung.
Die folgenden Begriffe beschreiben unterschiedliche Architekturdimensionen. Werden sie gleichgesetzt, verschwinden genau die Entscheidungen, die eine Umgebung sicher machen.
- Multi-Tier
- Administrative Sicherheitstiers trennen Systeme und Credentials nach Auswirkung. x.ID kann den Tiers getrennte Sekundäridentitäten, Hardware und Policies zuordnen und die verantwortliche Primäridentität erhalten.
- Multi-Forest und Multi-Domain
- Verzeichnis-Forests und Domains definieren Identitäts- und Administrationsgrenzen. Je AD-Kontext kann ein minimal berechtigter LDAP Connector userCertificate und X509:<SKI> pflegen; Microsoft Entra ID wird davon getrennt nativ über den Azure Connector angebunden.
- Microsoft Entra ID und Entra CBA
- Der native Azure Connector greift über Microsoft Graph direkt auf Microsoft Entra ID zu, ohne eine AD-Synchronisation vorauszusetzen. Für Entra CBA pflegt er SKI-Zuordnungen in certificateUserIds. Die Entra-FIDO2-Vorprovisionierung verbindet die Registrierung im Tenant mit einer getrennten persönlichen PIN-Übergabe.
- Multi-CA
- Beispiel: Benutzeranmeldung über eine interne CA, administrative Identität über eine getrennte CA und S/MIME über einen passenden öffentlichen Anbieter. x.ID ordnet je Zertifikat Identität, CA, Vorlage oder Profil und PIV-Slot zu. Der YubiKey erhält Zertifikate, keine CA-Templates; öffentliche TLS-Zertifikate ersetzen kein PIV-Authentifizierungsprofil.
- Multi-Segment
- Netzsegmente begrenzen technische Reichweite. Outposts verbinden definierte lokale Funktionen sternförmig, hintereinander oder gemischt über mTLS. Die Topologie folgt den freigegebenen Netzwegen; nicht jeder Outpost benötigt eine direkte Core-Verbindung.
- Menschliche und technische Identitäten
- Personen, verwaltete Servicekonten, Anwendungen und Infrastrukturdienste besitzen unterschiedliche Lifecycle- und Schlüsselschutzanforderungen, gehören aber in ein gemeinsames Trust-Modell.
- Auswertbare Berichte und rollenberechtigte API
- Auditberichte lassen sich anzeigen und als CSV oder Excel exportieren. Betriebs- und Auswertungsdaten sind über die API für berechtigte Rollen zugänglich. Weitere Berichte und Formate werden nach Kundenanforderung bereitgestellt; die gemeinsame Basis liefert auch CBOM-fähige Daten.
- Bericht und exportierte Datei unterscheiden
- Berichte werden im Core nicht nachträglich bearbeitet. Die Erstellung erfolgt unter dem gMSA des Core; berechtigte Benutzer können sie abrufen. Für exportierte Dateien bietet der Core keinen zusätzlichen Integritätsschutz. Signierung durch den Auditor und geschützte Ablage sind getrennte Schritte.
- Aufbewahrung und Wiederherstellung planen
- Es gibt keine feste produktseitige Aufbewahrungsgrenze; Datenbankkapazität und Kundenbetrieb bestimmen die mögliche Historie. Ein Core mit gescriptetem Wiederaufbau ist der reguläre Ausgangspunkt. Datenbank- und erforderliche Server-/HSM-Schlüsselsicherungen verantwortet der Kunde; besondere Verfügbarkeit wird gesondert bewertet.
NACHWEIS & GRENZEN
Was im Enterprise-Betrieb nachweisbar bleiben muss.
Eine große Umgebung ist kontrolliert, wenn jede aktive Identität und jeder Schlüssel einen verantwortlichen Eigentümer, Verwendungszweck, eine Policy, einen technischen Ort und einen aktuellen Lifecycle-Zustand besitzt.
Verantwortliche Identität und Rolle
Sekundäridentitäten über Tiers, lokale AD-Domains und Microsoft Entra ID bleiben mit der verifizierten Primäridentität verbunden.
AD- und Entra-Zielzustand
Eine Sperraktion führt CA-Widerruf und CRL-Veröffentlichung mit der Bereinigung betroffener Zertifikatseinträge und Zuordnungen in AD/LDAP, Windows-Zertifikatsspeicher und Entra CBA zusammen.
Auswertungen im gemeinsamen Basismodul
Das gemeinsame SYNRION-Basismodul stellt Compliance-Auswertungen, CBOM-fähige Daten über API sowie vorbereitete PCI-DSS-, DORA- und BSI-orientierte Berichte bereit. Individuelle Auswertungen und der Export von Protokolldaten sind möglich. Das unterstützt Prüfungen, ist aber keine Konformitätszertifizierung.
Verteiltes Policy Enforcement
Outposts und unabhängige Policies erweitern Kontrolle in getrennte Zonen, ohne die Architektur einzuebnen.
Hardwaregeschützte privilegierte Schlüssel
Benutzer-, Service- und CA-Schlüsselwege lassen sich um Security Keys und unterstützte HSM-Anbieter planen.
PASSENDES PRODUKT
SYNRION x.ID
YubiKeys, Identitäten, PIV-Zertifikate und FIDO2 zentral im Browser verwalten. SYNRION x.ID verbindet native Entra-Anbindung mit Cloud-, On-Premises- oder Hybridbetrieb über Outpost-Connectoren. Das Portal ist auch mobil bedienbar; Freigabestatus und Voraussetzungen stehen in der Funktionsübersicht.
NÄCHSTER KONTROLLIERTER SCHRITT
Bringen Sie reale Trust-Grenzen in eine Architektursicht.
Wir verfolgen eine Benutzer- und eine Service-Identität durch Ihre CA-, Verzeichnis-, Outpost- und HSM-Wege – einschließlich Erneuerung, Rechteentzug und Recovery.