Sicherheitsüberblick

Überblick

CERTYX verwaltet die Zertifikate, die das Vertrauen in Ihre Dienste sichern. Deshalb ist Datensicherheit die erste Anforderung und keine Zusatzfunktion. Dieser Überblick beschreibt in allgemeiner Form, wie CERTYX Ihre Daten und Ihre Infrastruktur schützt. Er richtet sich an Sicherheitsverantwortliche, Architekten und Einkaufsteams. Einzelheiten der Konfiguration stehen im Benutzerhandbuch, in der Anleitung zur Agenteninstallation und im Leitfaden zur SIEM-Integration; die vertraglichen Bedingungen (Service-Level, Unterauftragsverarbeiter, Aufbewahrung, Zertifizierungen) regeln Ihr Kundenvertrag und Ihr Auftragsverarbeitungsvertrag.

Security by Design

Drei Grundsätze prägen jeden Teil des Produkts:

Das Sensibelste erreicht uns nie. Private Schlüssel verwalteter Zertifikate, Zugangsdaten von Zertifizierungsstellen (CA) und Cloud-Zugangsdaten bleiben in Ihrer Infrastruktur. CERTYX arbeitet mit öffentlichen Zertifikaten, Zertifikatsanforderungen und Metadaten.

Jede Organisation bleibt getrennt. Jede Kundenorganisation hat ihre eigene Datenbank und eigene Datenbankrollen, und jede Anfrage, jede Hintergrundaufgabe, jeder Agent und jede Integration ist genau einer Organisation zugeordnet.

Jede privilegierte Aktion hinterlässt Nachweise, die Sie sehen. Änderungen, Freigaben, Anmeldungen und die Aktionen unserer eigenen Plattformbetreiber werden in einem manipulationssicheren Journal erfasst, das Sie einsehen können. Ihr SIEM erhält ausschließlich die Ereignisse Ihrer Organisation.

Isolation Ihrer Organisation

Eigene Datenbank pro Organisation. Inventar, Richtlinien, Pläne, Aufträge und Journal liegen in einer eigenen Datenbank, die mit eigenen Datenbankrollen erreicht wird. Darin ist Row-Level-Security erzwungen, sodass selbst eine Abfrage ohne Filter keine Zeilen einer anderen Organisation liefern kann.

Isolation auch in der gemeinsamen Plattformschicht. Die wenigen zentral gehaltenen Datensätze (zum Beispiel Konten, Einstellungen der Firmenanmeldung, mobile Geräte, SIEM-Ziele und Cloud-Quellen) sind ebenfalls durch erzwungene Row-Level-Security pro Organisation geschützt. Die Isolation wird für jeden Datenspeicher mit automatisierten organisationsübergreifenden Tests geprüft.

Organisation nur aus der authentifizierten Sitzung. Die Organisation wird nie aus einem Parameter übernommen, den ein Benutzer ändern könnte. Hintergrundprozesse, Agenten, SCIM-Bereitstellung, Firmenanmeldung und die mobile App sind jeweils an ihre Organisation gebunden.

Ihre Schlüssel und Zugangsdaten bleiben bei Ihnen

Private Schlüssel entstehen dort, wo sie verwendet werden. Für eine Erneuerung erzeugt der CERTYX-Agent auf dem Zielhost (oder ein Agent, der für einen Host ohne Agent als Relay über SSH arbeitet) den Schlüssel und die Zertifikatsanforderung lokal. Der private Schlüssel wird nie an CERTYX gesendet; Berichte mit privatem Schlüsselmaterial werden abgewiesen.

Ihre Zertifizierungsstellen bleiben unter Ihrer Kontrolle. Die Ausstellung über ACME, DigiCert CertCentral oder Ihre eigene Vault PKI erfolgt mit Zugangsdaten, die auf Ihrer Seite bleiben. SSH-Zertifikate signiert eine Zertifizierungsstelle auf Ihrem eigenen Host.

Cloud-Tresore werden mit Ihrer eigenen Identität gelesen. Zertifikate in Azure Key Vault, AWS Certificate Manager und Google Certificate Manager werden nur lesend mit Ihrer eigenen Kommandozeilen-Sitzung importiert. In CERTYX werden keine Cloud-Zugangsdaten eingegeben.

Schutz der Geheimnisse, die CERTYX halten muss

Manche Einstellungen benötigen ein Geheimnis auf der Plattform, etwa das Passwort Ihres SMTP-Relays, ein SIEM-Token, ein Client-Geheimnis der Firmenanmeldung oder den Schlüssel einer Authenticator-App.

Diese Geheimnisse sind verschlüsselt gespeichert und an Ihre Organisation gebunden: Ein in die Datensätze einer anderen Organisation kopierter Wert lässt sich dort nicht entschlüsseln.

Sie sind nur schreibbar: Nach dem Speichern werden sie nie wieder angezeigt, nie von der API zurückgegeben und nie in Protokolle oder das Journal geschrieben.

Im gehosteten Dienst sind die Schlüssel, mit denen sie verschlüsselt werden, durch einen eigenen Schlüssel in AWS KMS geschützt: Jede Entschlüsselung ist ein protokollierter Aufruf von KMS, eine Kopie der Datenbank samt der Dateien des Servers reicht also nicht aus, um sie zu lesen.

Agenten und Software-Lieferkette

Gegenseitiges TLS mit registrierten Identitäten. Jeder Agent weist sich mit seinem eigenen Client-Zertifikat aus. Ein Agent wird mit einem Einmalcode registriert, der nach zehn Minuten abläuft; ein neu registrierter Netzwerkagent darf nur suchen, Bereitstellungsrechte werden gesondert erteilt.

Nur ausgehende Verbindungen. Agenten verbinden sich mit CERTYX; auf Ihren Hosts muss kein eingehender Port geöffnet werden.

Lokale Begrenzung. Agenten lehnen Aufträge außerhalb der bei ihnen konfigurierten Ziele ab, was auch immer der Server verlangt.

Signierte Pakete und Updates. Agentenpakete tragen die Signatur des Herausgebers, die das Installationsprogramm gegen einen unabhängig bezogenen Fingerabdruck prüft; bei Abweichung wird nicht installiert. Automatische Updates sind mit einem offline gehaltenen Release-Schlüssel signiert und werden vor der Anwendung auf Integrität und gegen ein Downgrade geprüft.

Reproduzierbare Builds. Der Release-Prozess des Agenten baut die Programme reproduzierbar und legt jedem Paket eine Software-Stückliste (SBOM) und einen Build-Nachweis bei.

Anmeldung und Zugriff

Mehr-Faktor-Authentifizierung. Administrative Aktionen erfordern MFA. Authenticator-Codes können nicht wiederverwendet werden, und einmalige Wiederherstellungscodes werden nur als Hash gespeichert.

Passkeys. Phishing-resistente Passkeys (WebAuthn) können als zweiter Faktor bei der Anmeldung und für Bestätigungen verwendet werden.

Firmenanmeldung und Bereitstellung. Microsoft Entra ID, Okta, jeder OpenID-Connect-Anbieter oder SAML 2.0, wobei Benutzernamen gegen die für Ihre Organisation verifizierten E-Mail-Domänen geprüft werden, sowie SCIM-Bereitstellung. Änderungen, die über Ihren Identitätsanbieter eine Rolle anheben, werden protokolliert.

Netzwerk-Freigabelisten. Ihre Administratoren können die Anmeldung bei Ihrer Organisation auf freigegebene IP-Adressen und -Bereiche (IPv4 und IPv6) beschränken.

Sitzungen unter Ihrer Kontrolle. Sitzungen sind kurz und enden bei Inaktivität. Benutzer und Administratoren sehen die aktiven Browser- und Mobilsitzungen und können eine einzelne Sitzung oder alle anderen sofort beenden. Eine Änderung von Passwort, MFA oder Konto beendet bestehende Sitzungen.

Schutz vor Brute-Force. Wiederholte Fehlanmeldungen sperren das Konto für eine wachsende Dauer, und wiederholte Fehlversuche lösen eine Warnung aus.

Rollen und vier Augen. Die Rollen Auditor, Operator und Admin trennen Lesen, Betreiben und Verwalten. Erneuerungen und SSH-Signierprofile können die Freigabe durch einen zweiten Administrator erfordern.

Mobile Geräte. Die mobile CERTYX-App funktioniert nur auf Geräten, die Ihr Administrator mit einem Einmalcode aktiviert hat. Jede Anfrage wird mit einem nicht exportierbaren Schlüssel aus der sicheren Hardware des Geräts signiert, und ein widerrufenes Gerät wird bei seiner nächsten Anfrage abgewiesen.

Zugriff der Plattformbetreiber: unter Ihrer Kontrolle

Die Mitarbeitenden von CERTYX, die den gehosteten Dienst betreiben, unterliegen denselben Grundsätzen wie Ihre Benutzer, und weiteren:

Minimale Rechte. Betreiber haben getrennte Rollen (Support, Vertrieb, Sicherheitsadministration, Administration); jede Rolle sieht nur die Bereiche, die sie benötigt. Die Anhebung der Rolle eines Betreibers erfordert die Freigabe eines zweiten Betreibers.

Step-up-Bestätigung. Änderungen im Kontrollraum, die Zugriff oder Datenflüsse betreffen, erfordern eine frische MFA-Bestätigung.

Zuerst Ihre Freigabe. Ein Konto in Ihrer Organisation anlegen, eine Rolle anheben, ein Konto wieder aktivieren oder MFA zurücksetzen erfordert die Freigabe durch einen Ihrer Administratoren. Die einzige Alternative ist ein zeitlich begrenztes Break-Glass mit Begründung und einem zweiten Betreiber, und jedes Break-Glass wird allen Ihren Administratoren per E-Mail gemeldet.

Für Sie sichtbar. Jede Aktion eines Betreibers, die Ihre Organisation betrifft, wird in Ihrem eigenen Sicherheitsjournal erfasst und in Ihrer Konsole angezeigt. Plattformprotokolle gehen nie an Ihr SIEM und Ihre Protokolle nie an eine andere Organisation: Der Plattformbetreiber legt für Plattformprotokolle eigene Ziele fest.

Was Betreiber nie erhalten. Private Schlüssel und CA- oder Cloud-Zugangsdaten liegen nicht auf der Plattform, Betreiber können sie also nicht sehen; gespeicherte SMTP-, SIEM- und SSO-Geheimnisse sind über keine Schnittstelle lesbar.

Nachweise, Audit und SIEM

Manipulationssicheres Sicherheitsjournal. Jedes sicherheitsrelevante Ereignis ist mit einem kryptografischen Hash an das vorherige gekettet; die Konsole prüft die Integrität der Kette und exportiert jede gefilterte Auswahl als CSV oder JSON. Im gehosteten Dienst wird das Journal stündlich verankert: Eine signierte Verankerung wird in einem nur einmal beschreibbaren Speicher abgelegt, sodass eine spätere Änderung verankerter Ereignisse unabhängig von der Datenbank erkannt werden kann.

SIEM-Export in offenen Standards. CEF, LEEF 1.0 und 2.0, RFC-5424-Syslog, NDJSON, Generic KV und CSV, mit den Schemaprofilen OCSF, Elastic Common Schema und Splunk CIM, an Splunk, Cribl, IBM QRadar, ArcSight, Elastic, Microsoft Sentinel, OpenTelemetry-Backends oder Ihren eigenen Collector.

Immer verschlüsselter Transport. Der Export nutzt TLS mit Zertifikats- und Sperrprüfung; Client-Zertifikate (gegenseitiges TLS) werden unterstützt. Unverschlüsseltes Syslog wird nicht angeboten.

Nichts geht still verloren. Das Journal selbst ist die Zustellwarteschlange. Ist ein Empfänger nicht erreichbar, warten die Ereignisse, und bei anhaltenden Fehlern werden Warnungen ausgelöst; abgelehnte Ereignisse werden protokolliert und können nach der Korrektur des Empfängers erneut gesendet werden.

Jede Änderung verifiziert. Nach einer Bereitstellung wird das Ergebnis unabhängig am laufenden Endpunkt geprüft, und eine fehlgeschlagene Bereitstellung wird zurückgerollt.

AI Trust Analyst

Der AI Trust Analyst beantwortet Fragen zu Ihrem Zertifikatsbestand in verständlicher Sprache.

Er ist ausgeschaltet, bis ein Administrator Ihrer Organisation ihn einschaltet, nachdem er den Datenhinweis gelesen hat.

Er arbeitet nur über lesende Werkzeuge, die auf Ihre Organisation beschränkt sind; er kann nichts anlegen, ändern, freigeben oder löschen.

Jede Antwort nennt die Datensätze, die sie verwendet hat.

Private Schlüssel, Passwörter, Tokens, Geheimnisse und Zertifikatsdateien werden nie an den KI-Anbieter gesendet. Ihr Administrator legt fest, wie lange Gespräche aufbewahrt werden, auch gar nicht.

Infrastruktur und Betrieb des gehosteten Dienstes

Betrieb in der EU. Der gehostete Dienst läuft in der AWS-Region Frankfurt (eu-central-1).

Durchgehende Transportverschlüsselung. Browser-, Mobil-, Agenten- und Integrationsverkehr nutzt TLS, im Web mit Strict Transport Security. Auch die Verbindungen zu den Datenbanken innerhalb der Plattform sind verschlüsselt, mit vollständiger Zertifikatsprüfung.

Gehärtete Webanwendung. Eine strikte Content Security Policy, Schutz vor Clickjacking und Cross-Site Request Forgery, Ratenbegrenzungen und allgemeine Fehlerantworten ohne interne Details.

Verschlüsselte Sicherungen. Sicherungen werden mit authentifizierter Verschlüsselung verschlüsselt, bevor sie den Server verlassen, und täglich in versionierten, nur einmal beschreibbaren Speicher mit 30-tägiger Aufbewahrungssperre hochgeladen. Eine Wiederherstellung prüft jeden Teil, bevor Daten geändert werden.

Eigene Verschlüsselungsschlüssel und Audit-Trail. Die Datenbank, die Server-Datenträger, Sicherungs- und Release-Speicher sowie der Schlüsselring, der Ihre Geheimnisse schützt, sind mit eigenen Schlüsseln in AWS KMS verschlüsselt, die jährlich rotiert werden. Verwaltungsaktionen im Cloud-Konto, einschließlich jeder Verwendung dieser Schlüssel, werden in einem Cloud-Audit-Trail mit Validierung der Protokolldateien erfasst, der in einem separaten, verschlüsselten, nur einmal beschreibbaren Speicher liegt.

Kontrollierte Administration. Der gehostete Server ist nicht über SSH erreichbar; administrativer Zugriff erfolgt über einen protokollierten Verwaltungskanal. Releases werden aus getaggten Builds über eine automatisierte Pipeline bereitgestellt, mit per Digest festgelegten Container-Images und per Prüfsumme verifizierten Release-Archiven.

Geprüfte Ausfallsicherheit. Datenbankausfälle, Instanzabstürze, Wiederherstellungen und ein Failover zwischen zwei Instanzen wurden in protokollierten Übungen auf einer Testinstallation durchgespielt; in der Failover-Übung schlug keine Client-Anfrage fehl.

Datenschutz und DSGVO

Benannter Verantwortlicher. Die Datenschutzerklärung nennt den Verantwortlichen für personenbezogene Daten und wie er erreichbar ist.

Auftragsverarbeitung. Die Bedingungen der Verarbeitung in Ihrem Auftrag (Art. 28 DSGVO) sind auf der Seite zur Auftragsverarbeitung veröffentlicht und in Ihrem Auftragsverarbeitungsvertrag geregelt.

Kein Tracking ohne Einwilligung. Die öffentliche Website nutzt standardmäßig nur notwendige Speicherung. Optionale Webanalyse läuft nur nach Einwilligung und nie auf den Anmeldeseiten oder in der Konsole. Keine Werbung.

Bereitstellungsoptionen

CERTYX ist als von CERTYX betriebener gehosteter Dienst oder in Ihrem eigenen Rechenzentrum oder Cloud-Konto erhältlich. Eine Bereitstellung in Ihrem eigenen AWS-Konto kann dieselben Cloud-Schutzmaßnahmen wie der gehostete Dienst nutzen, mit den Verschlüsselungsschlüsseln und dem Cloud-Audit-Trail in Ihrem Konto. Der Vertrieb bestätigt, welche Optionen zu Ihrem Plan passen.

Kontakt

Website: https://certyx.space

Vertrieb: sales@certyx.space

Technischer Support und Sicherheitsfragen: support@certyx.space

Bitte melden Sie eine vermutete Schwachstelle an support@certyx.space.