Sicherheit & Vertrauen
Du gibst PaaSbox ein Read/Write-Token für ein Hetzner-Projekt und lässt es Kubernetes Control Planes für dich betreiben. Das verdient eine Erklärung in klaren Worten, wie die Plattform gebaut ist, um dieses Vertrauen zu rechtfertigen – was wir halten, was wir sehen können und was strukturell unmöglich ist. Keine Badges auf dieser Seite, nur Mechanik.
Dein Hetzner-Token
Abschnitt betitelt „Dein Hetzner-Token“- Das Token gelangt einmal in die Plattform, wird durch Auflisten deines Projekts validiert und verschlüsselt gespeichert (encrypted at rest). Es wird nie wieder angezeigt – nicht in der Konsole, nicht in der API, nicht dem Support.
- Es ist auf ein Hetzner-Projekt beschränkt (wir empfehlen ein dediziertes) und wird ausschließlich genutzt, um dort Cluster-Ressourcen zu verwalten – Server, Netzwerke, Load Balancer, Volumes. Es gewährt keinen Zugriff auf deine anderen Projekte oder dein Hetzner-Konto selbst.
- Du kannst es jederzeit im Portal rotieren oder bei Hetzner widerrufen. Der Widerruf ist dein harter Aus-Schalter: Ohne das Token kann die Plattform dein Projekt nicht anfassen.
Ein einziger Schreibpfad
Abschnitt betitelt „Ein einziger Schreibpfad“Jede Änderung an deiner Infrastruktur läuft durch das Portal und seine API – ein einziger, kontrollierter Schreibpfad, auf dem Abrechnungsprüfungen und Sicherheitsinvarianten greifen, bevor irgendetwas passiert. Es gibt keinen Seitenkanal: keinen Agenten in deinem Projekt mit eigenen Privilegien, keinen SSH-Zugang, den wir behalten, überhaupt keine eingehende Verbindung in dein Projekt (Nodes verbinden sich ausschließlich ausgehend mit ihrer Control Plane).
Kunden erhalten keinen Zugriff auf die Steuerungs-Infrastruktur der Plattform – das Credential, das du bekommst, ist eine cluster-admin-kubeconfig für deinen Cluster, höchstens 8 Stunden gültig, auf Abruf ausgestellt, auf unserer Seite nie gespeichert und bei der Ausstellung auditiert im Aktivitätsprotokoll deines Teams. Sie erreicht den API-Server deines Clusters – und sonst nichts.
Die Niemals-Löschen-Invariante
Abschnitt betitelt „Die Niemals-Löschen-Invariante“Das zentrale Versprechen der Plattform – adoptierte Server werden niemals gelöscht – ist keine Richtlinie, an die wir uns halten, sondern eine Eigenschaft des Systems: Die Komponente, die adoptierte Server verwaltet, hat für sie keinen Löschpfad, und Hetzners Löschschutz ist auf jedem adoptierten Server als unabhängige zweite Absicherung auf Infrastrukturebene aktiviert. Jede Operation, die die Plattform an einem adoptierten Server ausführt, stammt aus der preissicheren Liste – Rebuild, niemals Löschen, niemals Rescale. Die Adoptions-Doku geht das im Detail durch.
Was wir sehen können – und was wir nicht anschauen
Abschnitt betitelt „Was wir sehen können – und was wir nicht anschauen“Ehrliche Grenzen:
- Wir betreiben und überwachen deine Control Plane – API-Server-Gesundheit, etcd, Provisionierungsstatus. Das ist Teil des Service.
- Wir lesen standardmäßig weder die Logs noch die Daten deiner Anwendungen. Deine Workloads laufen auf deinen Nodes in deinem Projekt; Workload-Observability installierst du selbst (du hast Admin-Zugriff) – sie ist kein Plattform-Feature, das nach Hause telefoniert. Falls ein Support-Fall je davon profitiert, sich etwas von dir anzusehen, passiert das gemeinsam mit dir, auf deine Initiative.
- Die Abrechnung sieht Messwerte, keine Inhalte: aktive Stunden pro Cluster, nicht, was der Cluster tut.
Wo Daten liegen
Abschnitt betitelt „Wo Daten liegen“Die Plattform und die Control Planes, die sie betreibt, laufen in Hetzner-Rechenzentren in der Europäischen Union, und deine Worker-Nodes leben in deinem eigenen Hetzner-Projekt. Kundendaten werden innerhalb der EU gespeichert – eine sachliche Aussage darüber, wo die Maschinen stehen, und zugleich das, wozu sich die Vertragsbedingungen verpflichten. Zahlungsdaten verarbeitet Stripe; Kartennummern berühren unsere Systeme nie.
Backups
Abschnitt betitelt „Backups“Kontinuierliche Backups des etcd-Zustands deines Clusters sind Teil des Service – die Details und die ehrliche Grenze zwischen dem, was wir sichern, und dem, was deins bleibt, stehen unter Backups & Verfügbarkeit.
Eine Sicherheitslücke melden
Abschnitt betitelt „Eine Sicherheitslücke melden“Wenn du glaubst, ein Sicherheitsproblem gefunden zu haben, schreib an
support@paasbox.com mit „security“ im Betreff – bitte eröffne
kein öffentliches Issue. Du bekommst eine Antwort von einem Menschen, und wir halten dich bis zum
Fix auf dem Laufenden. Die maschinenlesbare Version dieser Policy liegt unter
/.well-known/security.txt.
Wir sind ein kleines Unternehmen; ein Bug-Bounty-Programm gibt es nicht (Stand: 2026-07-09) – aber Meldungen werden ernst genommen, schnell bearbeitet und auf Wunsch mit Namensnennung gewürdigt.