CluPilotCloud/resources/views/legal/dpa/measures.blade.php

{{--
    Anlage 1: Technische und organisatorische Maßnahmen (Art. 32 DSGVO).

    Written from what this installation ACTUALLY does — the backup job as
    RegisterBackup creates it, the isolation Proxmox gives, the sign-in as
    Fortify enforces it, the deletion deadlines the two prune commands run. Every
    sentence here is meant to survive somebody checking it against the machine.

    Where a measure is planned but not in place, it is not written down. A TOM
    that claims more than the system does is worse than a short one: it is the
    document an auditor reads before looking.
--}}
@php
    $c = App\Support\CompanyProfile::all();
@endphp

<h1>Anlage 1 — Technische und organisatorische Maßnahmen</h1>
<p><i>gemäß Art. 32 DSGVO, Anlage zum Auftragsverarbeitungsvertrag</i></p>

<p><b>Fassung {{ $version }}</b> · Stand {{ $issuedOn }} · {{ $c['name'] ?? 'CluPilot Cloud e.U.' }}</p>

<p>Diese Anlage beschreibt die Maßnahmen, die CluPilot beim Betrieb der
Kundeninstanzen tatsächlich umsetzt. Sie wird mit jeder Fassung des
Auftragsverarbeitungsvertrags überprüft und, wo nötig, fortgeschrieben.</p>

<h2>1. Zutrittskontrolle (physisch)</h2>

<p>Die Instanzen laufen ausschließlich in Rechenzentren der in Ziffer 6 des
Hauptvertrags genannten Unterauftragsverarbeiter innerhalb der Europäischen Union.
Physischer Zutritt, Videoüberwachung, Zutrittsprotokollierung, Brand- und
Einbruchschutz sowie unterbrechungsfreie Stromversorgung liegen in deren
Verantwortung und richten sich nach deren jeweils veröffentlichten Nachweisen
(u. a. ISO/IEC 27001). CluPilot selbst betreibt keine eigenen Serverräume.</p>

<h2>2. Zugangskontrolle (Systemzugang)</h2>

<ul>
    <li>Jeder Zugang zum Kundenportal und zur Betreiberkonsole erfordert Benutzername
        und Passwort. Passwörter werden ausschließlich als Hash gespeichert (bcrypt);
        die Klartexte sind CluPilot zu keinem Zeitpunkt bekannt.</li>
    <li>Zwei-Faktor-Authentisierung (TOTP) steht sowohl Kundinnen und Kunden als auch
        Betreibern zur Verfügung; für Betreiberkonten wird sie eingesetzt.</li>
    <li>Sicherheitsrelevante Änderungen (Zwei-Faktor abschalten, Schlüssel speichern)
        verlangen zusätzlich eine erneute Passwortbestätigung innerhalb der laufenden
        Sitzung.</li>
    <li>Angemeldete Geräte werden je Konto geführt und können einzeln abgemeldet
        werden; eine Anmeldung von einem neuen Gerät löst eine Benachrichtigung per
        E-Mail aus.</li>
    <li>Die Betreiberkonsole ist über eine eigene Adresse erreichbar und für das
        öffentliche Internet gesperrt; der Zugang erfolgt über ein privates Netz
        (WireGuard).</li>
    <li>Der administrative Zugriff auf die Virtualisierungsplattform erfolgt über
        API-Token je Host, nicht über gemeinsam genutzte Kennwörter.</li>
</ul>

<h2>3. Zugriffskontrolle (Berechtigungen)</h2>

<ul>
    <li>Die Betreiberkonsole kennt abgestufte Rollen (Owner, Admin, Support, Billing,
        Read-only) mit einzeln vergebenen Berechtigungen; jede Aktion prüft die
        Berechtigung serverseitig, nicht durch Ausblenden von Bedienelementen.</li>
    <li>Betreiber- und Kundenkonten sind getrennte Identitäten in getrennten Tabellen
        mit getrennten Anmeldewegen. Ein Kundenkonto kann keine Betreiberrechte
        erhalten.</li>
    <li>CluPilot greift nicht auf Inhalte in Kundeninstanzen zu. Ein Zugriff erfolgt
        nur, wenn der Kunde im Rahmen einer Supportanfrage darum ersucht, oder wenn
        eine gesetzliche Verpflichtung besteht.</li>
    <li>Zugangsdaten und Schlüssel (Zahlungsdienst, DNS, Hosts, Mailkonten) werden
        verschlüsselt gespeichert; der dafür verwendete Schlüssel ist vom
        Anwendungsschlüssel getrennt.</li>
</ul>

<h2>4. Trennungskontrolle (Mandantentrennung)</h2>

<ul>
    <li>Jede Kundin und jeder Kunde erhält eine <b>eigene virtuelle Maschine</b> mit
        eigenem Betriebssystem, eigener Datenbank und eigenem Dateisystem. Es gibt
        keine geteilte Nextcloud-Installation und keine gemeinsame Datenbank für
        Kundeninhalte.</li>
    <li>Jede Instanz hat eine eigene Adresse und ein eigenes Zertifikat.</li>
    <li>Die Verwaltungsdaten von CluPilot (Verträge, Rechnungen, Betriebsdaten) sind
        von den Kundeninhalten getrennt und liegen nicht in den Kundeninstanzen.</li>
</ul>

<h2>5. Weitergabekontrolle (Transport und Ablage)</h2>

<ul>
    <li>Sämtlicher Verkehr zu Kundeninstanzen, Portal und Konsole läuft über HTTPS mit
        Zertifikaten von Let's Encrypt; unverschlüsselte Verbindungen werden nicht
        angeboten.</li>
    <li>E-Mail wird über TLS an den Mailserver übergeben.</li>
    <li>Administrativer Zugriff auf Hosts erfolgt über SSH beziehungsweise über die
        API der Virtualisierungsplattform, jeweils verschlüsselt.</li>
    <li>Zahlungsdaten werden nicht von CluPilot verarbeitet: Karteneingabe und
        Zahlungsabwicklung finden beim Zahlungsdienstleister statt. CluPilot erfährt
        nur, dass und in welcher Höhe gezahlt wurde.</li>
</ul>

<h2>6. Eingabekontrolle (Nachvollziehbarkeit)</h2>

<ul>
    <li>Jede automatisierte Einrichtung, Änderung und Beendigung einer Instanz wird
        Schritt für Schritt protokolliert und bleibt in der Konsole einsehbar.</li>
    <li>Ausgehende E-Mails an Kundinnen und Kunden werden mit Zeitpunkt, Empfänger und
        Betreff in einem eigenen Register geführt.</li>
    <li>Wesentliche Vertragsvorgänge (Bestellung, Kündigung samt Grund, Widerruf,
        Abschluss dieses Vertrags) werden mit Zeitpunkt festgehalten; der Abschluss
        dieser Vereinbarung zusätzlich mit Fassung und IP-Adresse.</li>
    <li>Anwendungs- und Systemprotokolle werden auf den Servern geführt.</li>
</ul>

<h2>7. Verfügbarkeit und Belastbarkeit</h2>

<ul>
    <li><b>Sicherung:</b> Für jede Instanz wird bei der Einrichtung ein täglicher
        Sicherungslauf um 02:00 Uhr auf der Virtualisierungsplattform eingerichtet
        (Snapshot der gesamten Maschine).</li>
    <li><b>Überwachung:</b> Erreichbarkeit und Zustand der Instanzen und Hosts werden
        laufend überwacht; Störungen erzeugen Meldungen an den Betrieb.</li>
    <li><b>Kapazität:</b> Vor jeder Einrichtung wird geprüft, ob auf dem Zielhost
        ausreichend Speicher und Rechenleistung frei sind; reicht sie nicht, wird die
        Bestellung vorgemerkt statt einen Host zu überbuchen.</li>
    <li><b>Aktualisierung:</b> Sicherheits- und Versionsaktualisierungen werden
        eingespielt; geplante Wartungen werden angekündigt.</li>
</ul>

<h2>8. Löschung und Aufbewahrung</h2>

<ul>
    <li>Nach Vertragsende werden die Daten zum Abruf bereitgestellt und nach Ablauf der
        im Hauptvertrag genannten Frist samt Sicherungen gelöscht.</li>
    <li>Registrierungen, deren E-Mail-Adresse nie bestätigt wurde, werden nach
        {{ $unverifiedDays }} Tagen automatisch gelöscht.</li>
    <li>Bestätigte Konten ohne jemals gebuchtes Paket werden nach einem Jahr gelöscht;
        die Löschung wird {{ $warnDays }} Tage vorher per E-Mail angekündigt.</li>
    <li>Rechnungen und Buchhaltungsunterlagen werden sieben Jahre aufbewahrt
        (§ 132 BAO). Sie enthalten Vertrags-, nicht Inhaltsdaten.</li>
</ul>

<h2>9. Auftragskontrolle und Überprüfung</h2>

<ul>
    <li>Unterauftragsverarbeiter werden vertraglich auf ein entsprechendes
        Schutzniveau verpflichtet; die Liste ist Teil des Hauptvertrags.</li>
    <li>Diese Maßnahmen werden bei jeder neuen Fassung des
        Auftragsverarbeitungsvertrags überprüft, mindestens jedoch jährlich.</li>
    <li>Ansprechstelle für Datenschutzfragen: {{ $c['email'] ?? '' }}</li>
</ul>