Sicherheitserklärung

Diese Sicherheitserklärung beschreibt die technischen und organisatorischen Maßnahmen, die Kapsule Group Limited ("KapsuleHost") implementiert, um die auf unserer Plattform gehosteten Daten zu schützen. Sie wird in der Datenverarbeitungsvereinbarung referenziert und wird von Zeit zu Zeit aktualisiert, um Verbesserungen unserer Sicherheitslage widerzuspiegeln.

Unser Grundprinzip ist Defense in Depth: Wir schichten mehrere unabhängige Kontrollen, sodass kein einzelner Fehler die Kundendaten gefährdet.

Wir führen dokumentierte Richtlinien zur Informationssicherheit und zum Datenschutz, die mindestens jährlich überprüft und aktualisiert werden, wenn wesentliche Änderungen der Plattform oder der Bedrohungslage dies erforderlich machen.

Ein benannter Datenschutzbeauftragter trägt die Verantwortung für die Einhaltung des Datenschutzes. Sicherheitsverantwortungen werden Namensträgern des Infrastruktur-Teams zugewiesen.

Alle Mitarbeiter erhalten bei der Einstellung und danach jährlich Schulungen zu Datenschutz und Sicherheit. Mitarbeiter mit Zugriff auf Produktionssysteme unterliegen Hintergrundüberprüfungen, soweit das Gesetz dies zulässt.

Sicherheitsvorfälle und Beinaheunfälle werden erfasst, überprüft und zur kontinuierlichen Verbesserung der Kontrollen herangezogen.

Der Zugriff auf Produktionssysteme und Kundendaten wird durch strikte rollenbasierte Zugriffskontrolle geregelt, die auf dem Prinzip der minimalen Berechtigung basiert: Mitarbeiter erhalten nur den Zugriff, den sie zur Ausführung ihrer spezifischen Rolle benötigen.

Die Verwendung von Zwei-Faktor-Authentifizierung (2FA) ist obligatorisch für alle Mitarbeiter mit Zugriff auf Produktionsinfrastruktur, das Hosting-Kontrollpanel, Quellcode und Cloud-Provider-Konsolen.

Zugriffsrechte werden regelmäßig überprüft und bei Rollenwechsel oder Ausscheiden umgehend widerrufen. Zugriffsereignisse und Rechteerweiterungen werden protokolliert.

Produktions- und Nicht-Produktionsumgebungen sind strikt voneinander getrennt. Kundenumgebungen sind logisch voneinander isoliert innerhalb der Hosting-Plattform.

Jeder administrative Zugriff auf Produktionsserver wird über SSH-Schlüsselpaare authentifiziert; passwortbasierte SSH-Authentifizierung ist deaktiviert.

Alle Daten im Transit zwischen Kunden und unserer Plattform werden mit TLS 1.2 oder höher verschlüsselt. TLS-Zertifikate werden automatisch ausgestellt und vor Ablauf erneuert.

Offsite-Backups werden mit restic und AES-256 verschlüsselt. Verschlüsselungsschlüssel werden separat von Sicherungsdaten gespeichert und offline gesichert. Der Verlust des Schlüssels macht Sicherungsdaten unwiederherstellbar, weshalb Schlüssel an mehreren sicheren Offline-Standorten verwahrt werden.

Verschlüsselte Backups werden bei einem unabhängigen Objektspeicher-Anbieter in der Region Ozeanien gespeichert und bieten dadurch geografische Trennung von unserer primären Hosting-Infrastruktur.

Anwendungsgeheimnisse, API-Schlüssel und Anmeldedaten werden in Dateien mit eingeschränkten Zugriffsrechten auf den Servern gespeichert, die sie verwenden, zugänglich nur für das Dienstkonto, das sie benötigt, und werden niemals in Quellcode eingebettet oder in die Versionskontrolle eingecheckt. Infrastruktur- und Backup-Geheimnisse werden zusätzlich mit SOPS und Age-Verschlüsselung geschützt.

Jede Produktionsoberfläche, einschließlich unserer Marketing-Website, des Kunden-Kontrollpanels, unserer API und der von uns gehosteten Kundenseiten, wird durch eine Web Application Firewall (ModSecurity mit dem OWASP Core Rule Set) geschützt, die auf unserer eigenen Infrastruktur läuft. Unsere Marketing-Website wird zusätzlich durch eine Web Application Firewall an unserem CDN-Edge geschützt, die im Blockierungsmodus läuft. Der Edge-Schutz umfasst die von uns gehosteten Kundenseiten, die über unser CDN ausgeliefert werden. Er erstreckt sich nicht auf das Kunden-Kontrollpanel oder unsere API.

Kundenseiten sind sowohl voneinander als auch von gemeinsam genutzten Plattformdiensten auf Netzwerkebene isoliert, nicht nur durch getrennte Dateisystemkonten und Prozesse. Firewall-Regeln auf Kernel-Ebene (nftables), die an das eigene Systemkonto jedes Prozesses gebunden sind und nicht an die Anwendungslogik, blockieren jeden nicht-administrativen Prozess, einschließlich des eigenen Anwendungscodes jeder Kundenseite, am Zugriff auf den gemeinsam genutzten Datenbankport oder den eigenen Anwendungsserverport jeder anderen Seite. Dies wurde verifiziert, indem echte Verbindungsversuche aus dem echten Ausführungskontext einer Seite heraus in beide Richtungen durchgeführt wurden: blockiert für einen gewöhnlichen Seitenprozess, zugelassen für die Systemadministration. Derselbe Mechanismus blockiert außerdem den nicht-administrativen Zugriff auf interne Cloud-Infrastruktur-Diensteendpunkte, die ein Seitenprozess niemals erreichen können sollte. Er erstreckt sich noch nicht auf jeden gemeinsam genutzten Dienst: Der gemeinsam genutzte Caching-Dienst der Plattform ist durch seitenspezifische Zugangsdaten geschützt, die auf die eigenen Daten dieser Seite beschränkt sind, wird aber noch nicht zusätzlich auf Netzwerkebene blockiert, wie es bei den Datenbank- und Anwendungsserver-Ports der Fall ist; die Erweiterung desselben Firewall-Schutzes auf diesen Dienst ist eine geplante Verbesserung unseres Sicherheitsprogramms.

Betriebssysteme, Plattformsoftware und Anwendungsabhängigkeiten werden regelmäßig gepflegt. Sicherheitsupdates werden automatisch über unattended-upgrades angewendet, in der Regel innerhalb eines Tages nach Veröffentlichung. Für kritische Sicherheitspatches, einschließlich solcher, die manuelles Eingreifen erfordern, etwa einen Neustart, oder die noch nicht über automatische Updates verfügbar sind, beträgt unsere verbindliche Frist 7 Tage ab Veröffentlichung. Internetorientierte Infrastruktur wird regelmäßig auf bekannte Schwachstellen überprüft.

Firewall-Regeln beschränken den eingehenden Zugriff auf die notwendigsten Ports und Dienste. Unnötige Dienste sind standardmäßig deaktiviert.

Regelmäßige Penetrationstests werden durch unabhängige qualifizierte Tester durchgeführt. Wesentliche Erkenntnisse werden behoben und erneut getestet.

Authentifizierungsversuche, Konto- und Konfigurationsänderungen sowie Maßnahmen, die unser eigenes Personal an Kundenkonten vornimmt, werden in einem zentralisierten, unveränderlichen Datenbank-Auditprotokoll erfasst und mindestens 90 Tage lang aufbewahrt. Infrastruktur- und Systemprotokolle (Webserver-, Firewall- und Betriebssystemprotokolle) werden lokal auf jedem Produktionsserver gespeichert und sind ausschließlich autorisiertem Personal zugänglich und werden zusätzlich stündlich an einen unabhängigen, extern gehosteten Speicher mit Einmalschreib-Schutz und einer 90-tägigen Aufbewahrungssperre übertragen: Ist ein Protokollarchiv einmal geschrieben, kann es während dieses Zeitraums von niemandem, auch nicht von uns, gelöscht oder überschrieben werden, sodass ein kompromittierter Server keine Beweise für die auf ihm stattgefundenen Vorgänge beseitigen kann.

Die Plattformgesundheit und Sicherheitssignale werden rund um die Uhr überwacht. Warnmeldungen werden an das Bereitschaftspersonal weitergeleitet, um eine sofortige Untersuchung zu ermöglichen.

Wir unterhalten einen dokumentierten Incident-Response-Plan mit definierten Schweregrad-Stufen, Eskalationswegen und Kommunikationsverfahren. Der Plan wird mindestens jährlich überprüft und getestet.

Im Falle einer bestätigten meldepflichtigen Datenschutzverletzung, die sich auf Customer Personal Information auswirkt, werden wir betroffene Kunden innerhalb von 72 Stunden nach Kenntnisnahme benachrichtigen, wie von der Privacy Act 2020 und der Data Processing Agreement gefordert.

Sentry wird für Echtzeit-Fehlertracking und Application-Performance-Überwachung im gesamten Platform Stack verwendet.

Kundenseite-Dateien, Datenbanken und E-Mail-Daten werden täglich mit restic in externen Objektspeicher (Region Ozeanien) gesichert. Sicherungen werden im ruhenden Zustand mit AES-256 verschlüsselt.

Die Sicherungsaufbewahrung beträgt mindestens 30 Tage für alle kostenpflichtigen Pläne. Höherwertige Pläne bewahren Sicherungen länger auf: 90 Tage, 1 Jahr oder 7 Jahre, je nach gebuchter Stufe. Planspezifische Aufbewahrungsdetails finden Sie in der Service Level Agreement.

Wiederherstellungsverfahren sind in unseren internen Runbooks dokumentiert und werden regelmäßig getestet. Das Platform-Team führt Wiederherstellungsübungen durch, um die Sicherungsintegrität zu validieren.

Der KapsuleHost-Plattform-Codebase (einschließlich Konfiguration und Bereitstellungsskripte) wird täglich in private GitHub-Repositories der Organisation kapsulenz gesichert und bietet damit einen unabhängigen Wiederherstellungspfad für die Plattform selbst.

Disaster-Recovery-Verfahren für jede Infrastrukturkomponente sind mit einem für diese Komponente spezifischen angestrebten Wiederherstellungszeitziel dokumentiert: bis zu 8 Stunden für den Hosting-Server, abhängig vom Umfang der wiederherzustellenden Kundendaten; 2 bis 4 Stunden für die Mail-Plattform; und 4 Stunden für das Kundenportal.

Alle Mitarbeiter mit Zugriff auf Kundendaten sind entweder vertraglich oder gesetzlich an Vertraulichkeitsverpflichtungen gebunden.

Wir unterhalten schriftliche Datenverarbeitungsvereinbarungen mit allen Unterauftragsverarbeitern. Diese Vereinbarungen verpflichten Unterauftragsverarbeiter, Schutzmaßnahmen umzusetzen, die nicht weniger schützend sind als diejenigen in unserer Datenverarbeitungsvereinbarung, einschließlich Vertraulichkeit, Sicherheit und Verpflichtungen zur zweckgebundenen Verarbeitung.

Unsere Liste der Unterauftragsverarbeiter wird mindestens jährlich auf fortlaufende Eignung überprüft. Unterauftragsverarbeiter werden vor ihrer Beauftragung anhand unserer Mindestanforderungen an die Sicherheit bewertet.

Die aktuelle Liste der Unterauftragsverarbeiter wird unter kapsulehost.com/legal/sub-processors veröffentlicht.

Produktionsserver werden in Rechenzentren Dritter betrieben. Wir besitzen und betreiben kein eigenes Rechenzentrum; daher liegen die physische Sicherheit, die Umgebungssteuerung, die Stromredundanz und die Brandbekämpfung in der Verantwortung des Betreibers der Einrichtung, und unsere Vereinbarungen mit Infrastruktur-Unterauftragsverarbeitern verlangen Schutzmaßnahmen, die denen unserer Data Processing Agreement mindestens gleichwertig sind. Wir veröffentlichen das Land einzelner Produktionsserver nicht: unsere Kapazitäten verlagern sich, wenn wir Regionen hinzufügen, und eine einmal veröffentlichte Angabe zum Standort ist ab dem Tag der Änderung falsch, ohne dass sie jemand bearbeitet. Die von uns eingesetzten Unterauftragsverarbeiter sind unter kapsulehost.com/legal/sub-processors aufgeführt.

Der physische Zugriff auf Server-Hardware ist auf autorisiertes Rechenzentrumspersonal beschränkt. KapsuleHost-Personal hat keinen routinemäßigen physischen Zugriff auf Produktionshardware; alle administrativen Zugriffe werden remote über verschlüsselte Kanäle durchgeführt.

Außerbetriebgenommene Speichermedien werden gemäß den Verfahren des Rechenzentrumsbetreibers sicher gelöscht oder zerstört, bevor sie wiederverwendet oder entsorgt werden.

Anwendungsgeheimnisse, API-Schlüssel und sensible Konfigurationswerte werden in Dateien mit eingeschränkten Zugriffsrechten auf den Servern gespeichert, die sie verwenden, und werden niemals in Source-Code-Repositorys eingecheckt. Infrastruktur- und Backup-Geheimnisse werden separat mit SOPS und Age-Verschlüsselung verwaltet.

Tests vor der Veröffentlichung umfassen funktionale, Regressions- und sicherheitsorientierte Test-Läufe. Änderungen an Authentifizierungs-, Zahlungs- oder Datenverarbeitungsabläufen unterliegen zusätzlichen Überprüfungen.

Benutzereingaben werden an allen Anwendungsgrenzen validiert und bereinigt. Wir wenden Standardschutzmaßnahmen gegen OWASP-Top-10-Risiken an, einschließlich SQL-Injection, Cross-Site-Scripting und Cross-Site-Request-Forgery.

KPanel-Authentifizierung: Passwörter werden mit Argon2id gehasht (speicherintensiv, resistent gegen GPU-Cracking). Neue Passwörter werden vor Akzeptanz über k-Anonymitäts-Präfix-Lookup gegen die Have I Been Pwned-Datenbank überprüft. Die Anmeldung unterstützt TOTP-basierte Zwei-Faktor-Authentifizierung, SMS-Einmalcodes und Hardware-Passkeys (WebAuthn/FIDO2). OAuth-Anmeldung wird via Google, GitHub, Apple Sign In und Discord unterstützt. Google und Apple Sign In werden gegen den eigenen JWKS-Endpunkt des Anbieters verifiziert; GitHub und Discord veröffentlichen keinen JWKS-Endpunkt für OAuth-Anmeldung, daher werden diese beiden stattdessen durch direkten Aufruf der Account-API des Anbieters mit dem von ihm ausgestellten Zugriffstoken verifiziert. Anmeldeversuche werden pro IP-Adresse begrenzt, und wiederholte fehlgeschlagene Versuche gegen ein einzelnes Konto werden für einen Zeitraum gesperrt. Session-Token sind kryptographisch zufällig und kryptographisch signiert und verfallen nach 30 Tagen Inaktivität.

Kundendaten werden auf logischer Ebene in den Bereichen Hosting, Datenbank und Anwendung getrennt. Die Dateien und Datenbanken jedes Kunden sind unter separaten Systemkonten isoliert, ohne dass ein kundenübergreifender Zugriff möglich ist.

E-Mail wird eigenständig isoliert und geschützt. Jedes Postfach ist ein eigenes Konto, das durch die Zugriffskontrollen unseres Mailservers isoliert ist und sich mit eigenen Zugangsdaten anmeldet. Unsere Mailserver akzeptieren ausschließlich TLS 1.2 und TLS 1.3: TLS 1.0 und 1.1 werden auf jedem Mail-Port abgewiesen, sowohl über IPv4 als auch über IPv6. Wir bieten überhaupt kein unverschlüsseltes IMAP oder POP3 an, und bevor eine Verbindung verschlüsselt ist, wird keinerlei Anmeldeverfahren angeboten. Der Mail-Port für die Übertragung zwischen Servern bietet überhaupt keine Anmeldung an. Fünf fehlgeschlagene Anmeldungen innerhalb von fünf Minuten sperren die verbindende IP-Adresse für eine Stunde, und der Mailserver sperrt unabhängig davon IP-Adressen, von denen wiederholt missbräuchliche Verbindungen ausgehen. Postfachdaten werden auf verschlüsselten Datenträgern (AES-256-XTS) gespeichert, und E-Mail-Sicherungen sind verschlüsselt. Jede Domain, für die wir E-Mail hosten, erhält eigene DKIM-Signaturschlüssel, sowohl in RSA als auch in Ed25519, zusammen mit einem SPF-Eintrag. Unsere eigene Domain kapsulehost.com veröffentlicht eine DMARC-Richtlinie mit reject und eine SPF-Richtlinie, die auf -all endet, sodass empfangende Server, die DMARC prüfen, E-Mails abweisen, die diese Domain fälschen. Außerdem veröffentlicht sie eine durchgesetzte MTA-STS-Richtlinie mit TLS-Berichten, die sendende Server anweist, E-Mails an uns ausschließlich über eine verschlüsselte Verbindung zu einem verifizierten Zertifikat zuzustellen.

Wenn ein Kunde seinen Service beendet, werden Kundenpersonendaten 30 Tage lang zum Export verfügbar gemacht und dann dauerhaft aus Live-Systemen gelöscht. Verschlüsselte Sicherungskopien werden beim nächsten geplanten Rotationszyklus gelöscht, spätestens 30 Tage nach der Löschung aus Live-Systemen.

Dokumentierte Datenlöschungsverfahren stellen sicher, dass Daten aus allen relevanten Systemen entfernt werden, einschließlich Live-Datenbanken, Caches und Anwendungsspeicher, nicht nur aus dem primären Datenspeicher.

Verfahren zur Bearbeitung von Anfragen von Betroffenen (Zugriff, Berichtigung, Löschung) sind dokumentiert und getestet. KPanel-Exporttools ermöglichen es Kunden, ihre Daten jederzeit während der Servicelaufzeit abzurufen.

Falls Sie Fragen zu unseren Sicherheitspraktiken haben oder eine vermutete Sicherheitslücke melden möchten, kontaktieren Sie uns bitte unter privacy@kapsulehost.com.

Kapsule Group Limited, New Zealand.