Sicherheit

1. Hosting und Datenspeicherort

Kundendaten befinden sich vollständig in der Europäischen Union:

• Datenbank, Authentifizierung und Dateispeicherung bei Supabase, Region eu-central-1 (Frankfurt, Deutschland).
• Web-Hosting und Edge-Funktionen bei Vercel, fixiert auf fra1 (Frankfurt). Einige Plattformtelemetriedaten werden in den Vereinigten Staaten auf Grundlage von EU-Standardvertragsklauseln übermittelt.
• DNS-Auflösung über das globale Anycast-Netzwerk von Cloudflare - keine Anwendungsdaten gespeichert.
• E-Mail über Heinlein Hosting GmbH (Mailbox.org) - Berlin, Deutschland.

2. Verschlüsselung

Daten bei der Übertragung werden mit TLS 1.2+ verschlüsselt (HSTS erzwungen; HTTP-Anfragen werden auf HTTPS umgeleitet). Daten im Ruhezustand werden vom Anbieter verschlüsselt - Supabase verwendet AES-256 für die Datenbank und den Dateispeicher (Fotos und Dokumente), mit anbieterseitig verwalteten Schlüsseln.

3. Berechtigungsmodell

Jede Anfrage, die aus einer Browser-Sitzung stammt, wird über die Row-Level Security (RLS) von PostgreSQL ausgeführt. Berechtigungsprüfungen nutzen eine stufenbasierte Hilfsfunktion (has_farm_permission(farm_id, tier)) für owner_only / finance_access / write_access / any_member, die auf Datenbankebene angewendet wird. Die Anwendungsoberfläche ist nicht die Sicherheitsgrenze - auch eine gefälschte Client-Anfrage kann keine Daten lesen, die die RLS-Richtlinie verweigert. Einige wenige vertrauenswürdige serverseitige Pfade verwenden einen Service-Role-Schlüssel, der die RLS umgeht: die geplanten Retention-Jobs, der Stripe-Webhook, die Statusprüfung, der E-Mail-Versand für Käuferanfragen, der token-authentifizierte Kalender-Feed, die kurzlebigen signierten Links, über die von einem Verkäufer auf einer Verkaufsseite veröffentlichte Dokumente ausgeliefert werden, und ein ausschließlich dem Betreiber vorbehaltenes Admin-Dashboard. Dieser Schlüssel ist rein serverseitig, durch Umgebungsvariablen eingeschränkt und vom Browser aus nie erreichbar.

4. Aktivitätsprotokoll

Jede erfolgreiche Datenmutation schreibt genau eine Zeile in die Tabelle activity_log. Das Protokoll erfasst, wer was wann getan hat sowie die Änderung. Routineeinträge werden 24 Monate aufbewahrt; Einträge zu Sicherheit, Rechtsfragen, Finanzen und Mitgliedschaft werden unbegrenzt aufbewahrt. Soft-gelöschte Zeilen in Tabellen, die dies unterstützen (animals, events, tasks usw.), werden nach 24 Monaten endgültig gelöscht - ausgenommen die Finanzdatentabellen, die gemäß dem italienischen Steuerrecht zehn Jahre aufbewahrt werden.

5. Sicherung und Wiederherstellung

Das Supabase-Projekt läuft derzeit auf dem Free-Plan, der weder automatische Backups noch Point-in-Time-Recovery umfasst. Dem Betreiber steht ein manueller Datenbank-Dump-Befehl zur Verfügung, ein geplantes Backup und ein Offsite-Backup-Verfahren bestehen derzeit jedoch nicht. Vor dem Start der kostenpflichtigen Tarife wechselt das Projekt auf den Supabase-Pro-Plan mit 7 Tagen täglicher Backups; Point-in-Time-Recovery ist ein separat kostenpflichtiges Add-on, das wir zu diesem Zeitpunkt prüfen werden. Der Dateispeicher wird innerhalb der Region eu-central-1 repliziert. Wenn Backup-Garantien für Ihre Bewertung wesentlich sind, fragen Sie uns. Wir sagen Ihnen genau, was am Tag Ihrer Anfrage vorhanden ist.

6. DSGVO-Ansatz

Wir behandeln die DSGVO als grundlegende Produktanforderung, nicht als optionale Funktion. Jeder AlpacaKeep-Nutzer kann seine wichtigsten Datensätze als CSV exportieren (Tiere, Ereignisse, Shows, Finanzbuchungen, Faserergebnisse), eine Berichtigung beantragen und eine Löschung verlangen. Der Löschvorgang umfasst eine 30-tägige Bedenkzeit, gefolgt von einer endgültigen Löschung per Kaskade. Weitere Einzelheiten zur vollständigen Offenlegung nach DSGVO Art. 13/14 sowie zu unserem DSR-Verfahren finden Sie in unserer Datenschutzerklärung.

7. Responsible-Disclosure-Programm

Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, melden Sie diese bitte, bevor Sie sie öffentlich bekannt machen. Wir verpflichten uns, Ihre Meldung innerhalb von sieben Kalendertagen zu bestätigen und innerhalb von neunzig Kalendertagen eine inhaltliche Antwort (Behebung, Mitigationsplan oder ausführliche Begründung) zu geben. Forscher, die in gutem Glauben handeln - die im Scope bleiben, nicht auf Daten anderer Nutzer zugreifen und den Betrieb nicht beeinträchtigen - werden von uns nicht rechtlich verfolgt; wir werden gemeinsam mit Ihnen an der Behebung arbeiten und Sie auf Wunsch öffentlich nennen.

8. Scope

Im Scope:

• alpacakeep.com sowie jede Locale oder jeder Unterpfad, der darüber ausgeliefert wird (z. B. /it/...).
• Öffentlich anonym lesbare RPCs (insbesondere get_public_animal).
• Die Abläufe für Registrierung, Anmeldung, Passwort-Zurücksetzen und Einladungsannahme.
• Kundendatenverarbeitung - RLS, IDOR, Umgehung des finance-access usw.

Außerhalb des Scope:

• Infrastruktur der Auftragsverarbeiter (Supabase, Vercel, Cloudflare, Mailbox.org) - bitte direkt beim Anbieter melden.
• Befunde, die physischen Zugang zum Gerät eines Nutzers erfordern.
• Best-Practice-Hinweise ohne klaren Sicherheitseinfluss (z. B. fehlende Security-Header auf einer statischen Seite, theoretisches CSRF bei einem GET ohne Seiteneffekte).
• Denial-of-Service durch Volumen - bitte vermeiden.
• Social Engineering von Mitarbeitern, Kunden oder Auftragnehmern.

9. So melden Sie eine Sicherheitslücke

Senden Sie eine E-Mail an security@alpacakeep.com mit:

• Einer klaren Beschreibung der Sicherheitslücke und ihrer Auswirkungen.
• Reproduktionsschritten - idealerweise einem minimalen Proof-of-Concept.
• Ihrem Namen und einer Möglichkeit, Sie für Rückfragen zu kontaktieren. Anonyme Meldungen werden akzeptiert, lassen sich jedoch langsamer bearbeiten.

Wir bieten derzeit kein monetäres Bug-Bounty-Programm an. Wir nennen Sie auf Wunsch gerne öffentlich in einem Security Advisory oder in den Release Notes.