Sicherheit

Gebaut für Leute, die Firewalls konfigurieren.

Projekt 47 ist so entworfen, dass ein Angriff auf unsere Cloud keine Schlüssel deiner Kunden preisgibt und keinen Code auf ihren Servern ausführen kann.

Architektur

Wer spricht mit wem

Architektur von Projekt 47 Der Agent im Kundennetz verbindet sich nur ausgehend per mTLS mit der Projekt-47-Cloud und holt Zertifikate per ACME von der Zertifizierungsstelle. Private Schlüssel bleiben im Kundennetz. Kundennetz p47-agent Erzeugt Schlüssel lokal Lokale Policy entscheidet Exchange · IIS RD-Gateway · RDP Firewall · Linux Firewall des Kunden Keine eingehenden Ports · nur ausgehend 443 Projekt-47-Cloud · Deutschland Koordination Soll-Zustand, Alarme Reports, CT-Watch sieht nur CSR + Zertifikat Challenge-DNS beantwortet nur _acme-challenge per CNAME-Delegation Zertifizierungsstelle (ACME) Let’s Encrypt oder eine ACME-CA deiner Wahl, prüft die Domain per DNS-01 und stellt aus mTLS, ausgehend ACME, HTTPS DNS-01
Steuerkanal (mTLS, ausgehend) Zertifikatsantrag und Validierung Privater Schlüssel liegt hier – und nur hier

Datensparsam

Was unsere Cloud weiß – und was nicht.

Das wissen wir

  • Domainnamen und öffentliche Zertifikate, die ohnehin in den CT-Logs stehen
  • Hostnamen, Betriebssystem und Version der Agents
  • Welche Dienste ein Zertifikat nutzen und ob die Installation geklappt hat
  • Wer im Dashboard was geändert hat (Audit-Log)

Das wissen wir nicht

  • Private Schlüssel – sie werden auf dem Server erzeugt und verlassen ihn nie
  • Passwörter oder Zugangsdaten zu Exchange, IIS oder Firewalls deiner Kunden
  • DNS-Zugangsdaten – die CNAME-Delegation braucht keine
  • Inhalte von Mails, Webseiten oder sonstigem Datenverkehr

Im Detail

Schutzmaßnahmen

Schlüssel bleiben lokal

Der Agent erzeugt das Schlüsselpaar auf dem Zielserver und schickt nur den Zertifikatsantrag (CSR). Unter Windows schützt DPAPI den Schlüssel, unter Linux restriktive Dateirechte.

Die lokale Policy hat das letzte Wort

Eine Richtlinie auf dem Server legt fest, welche Domains, Dienste und Skripte der Agent bedienen darf. Verlangt die Cloud etwas anderes, lehnt der Agent ab und meldet es.

Nur ausgehendes mTLS

Jeder Agent hat ein eigenes Client-Zertifikat und verbindet sich ausschließlich ausgehend über Port 443. Kein VPN, keine Portfreigabe, keine eingehenden Verbindungen.

Signierte, gestaffelte Updates

Updates sind mit Ed25519 signiert und werden vor der Installation geprüft. Sie werden stufenweise ausgerollt und lassen sich pro Kunde pausieren.

Open Source

Der Agent steht unter der Apache-2.0-Lizenz. Du kannst jede Zeile prüfen, die auf den Servern deiner Kunden läuft, und selbst bauen.

Hosting in Deutschland

Server und Backups liegen in deutschen Rechenzentren. Keine US-Cloud, kein Tracking, keine externen Schriften oder CDNs.

CAA und CT-Watch

Wir empfehlen CAA-Einträge mit accounturi, damit nur dein ACME-Konto ausstellen darf, und melden jedes unbekannte Zertifikat aus den CT-Logs.

Pflicht-MFA und Mandantentrennung

Anmeldung nur mit Passkey, TOTP oder Microsoft Entra ID. Mandanten sind bis in die Datenbank getrennt (Row-Level Security), jede Änderung landet im Audit-Log.

Schwachstelle gefunden?

Wir freuen uns über jeden Hinweis. Schreib uns an mailto:p47@ckitsolutions.de – gern verschlüsselt, den Schlüssel nennen wir auf Anfrage. Unsere Kontaktdaten stehen auch maschinenlesbar in der security.txt.

  • Wir bestätigen den Eingang innerhalb von zwei Werktagen.
  • Wir halten dich über den Stand der Behebung auf dem Laufenden.
  • Wer nach Treu und Glauben forscht, keine Daten Dritter abruft und uns Zeit zur Behebung gibt, hat von uns nichts zu befürchten.
  • Auf Wunsch nennen wir dich nach der Behebung namentlich.