Datenschutzerklärung

Stand: 12. November 2026. Diese Bestandsaufnahme beschreibt die Anwendungsdaten und den eingerichteten Preview-Betrieb. Die Angaben für den öffentlichen Betrieb müssen vom Betreiber bestätigt und ergänzt werden.

Verantwortlicher

Yaroslav Gross
Selbständiger / Einzelunternehmer
Am Münzbergtor 9
85049 Ingolstadt
Deutschland
E-Mail: info@aufinai.de

Ein Datenschutzbeauftragter ist im Projekt nicht benannt. Ob eine Benennung im tatsächlichen Betrieb erforderlich ist, muss der Verantwortliche prüfen.

Technischer Betrieb und Serverprotokolle

Der geschlossene Vorabzugang läuft auf einem Server von Hetzner. Die Next.js-Anwendung speichert ihre Daten in einer eigenen PostgreSQL-Datenbank. Für den öffentlichen Zugang ist Caddy als Reverse Proxy vorgesehen. Serverstandort, Empfänger, Verträge und mögliche Drittlandübermittlungen sind vor dem Start zu bestätigen.

Im Anwendungscode ist kein allgemeines HTTP-Zugriffsprotokoll für IP-Adresse oder User-Agent eingerichtet. API-Fehler werden teilweise mit console.error in die Server-Standardausgabe geschrieben; dabei können technische Fehlerdetails ausgegeben werden. Die Docker-Protokolle für Anwendung und Datenbank werden nach Größe begrenzt und rotiert. Welche weiteren Protokolle im öffentlichen Betrieb anfallen und wie lange sie gespeichert werden, bleibt zu bestätigen.

Noch festzulegen: Hosting-Empfänger und Serverstandort, Protokollfelder, Speicherorte, Zugriffsberechtigungen und Löschfristen der tatsächlichen Betriebsprotokolle.

Kontaktanfragen über das Formular

Das öffentliche Formular verarbeitet Name, E-Mail-Adresse, optionales Unternehmen, ausgewähltes Thema und Nachricht, um die Anfrage entgegenzunehmen und dem Betreiber zur Bearbeitung bereitzustellen. Das Formular verlangt zusätzlich eine angekreuzte Datenschutzbestätigung; der Wert wird serverseitig geprüft, aber nicht als eigener Nachweis in PostgreSQL gespeichert. Ein verstecktes Honeypot-Feld dient der Spam-Erkennung. Die Anwendung versendet über diesen Vorgang keine E-Mail, sondern speichert erfolgreiche Anfragen in PostgreSQL.

Gespeichert werden Name, E-Mail-Adresse, optionales Unternehmen, Thema/Betreff, Nachricht, Bearbeitungsstatus sowie Erstellungs- und Änderungszeit. Eine automatische Löschroutine oder feste Aufbewahrungsfrist ist im Projekt nicht eingerichtet. Zweck und konkrete Rechtsgrundlage sind je nach Art der Anfrage vom Verantwortlichen festzulegen; eine pauschale Rechtsgrundlage wird hier nicht behauptet.

Noch festzulegen: Rechtsgrundlage, Kriterien und Frist für Löschung oder Archivierung, Umgang mit Anfragen nach Abschluss sowie die technische Zuständigkeit für deren Umsetzung.

IP-Adresse und Missbrauchsschutz

Für die Begrenzung öffentlicher Formularanfragen und von Admin-Anmeldeversuchen liest der Server den ersten Wert des Headers x-forwarded-for. Dieser Wert wird als Schlüssel in der PostgreSQL-Tabelle LoginAttempt zusammen mit Versuchszahl und Beginn des Zeitfensters gespeichert. Das Formular verwendet ein Stundenfenster mit höchstens fünf Anfragen; die Anmeldung prüft vor dem Passwortvergleich ein 15-Minuten-Fenster mit höchstens fünf Versuchen. Erfolgreiche Anmeldungen löschen den passenden Login-Zähler. Eine regelmäßige Bereinigung abgelaufener Einträge ist nicht eingerichtet; Einträge können deshalb über das jeweilige Zeitfenster hinaus gespeichert bleiben. Die korrekte Ermittlung der IP-Adresse hängt davon ab, dass ein vertrauenswürdiger Reverse Proxy eingehende Forwarding-Header überschreibt.

Noch festzulegen: Rechtsgrundlage und berechtigter Zweck, konkrete Löschfrist und Bereinigungsverfahren sowie die tatsächlich eingesetzte Proxy-Konfiguration.

Admin-Konten, Anmeldung und Cookie

Für Admin-Konten speichert PostgreSQL Name, E-Mail-Adresse, Rolle und ein mit bcrypt erzeugtes Passwort-Hash. Bei Anmeldeversuchen wird die E-Mail-Adresse zur Kontoprüfung verwendet; das eingegebene Passwort wird nicht im Klartext gespeichert. Die Admin-Sitzung wird durch ein signiertes Token im Cookie session gehalten. Das Cookie ist HttpOnly, SameSite=Strict, auf den Pfad „/“ beschränkt und läuft nach sieben Tagen ab; Secure wird im Production-Modus gesetzt. Es wird ausschließlich für die Admin-Anmeldung verwendet. Eine öffentliche Registrierung besteht im geprüften Code nicht.

Im geprüften Anwendungscode wurden keine Analyse-, Werbe- oder sonstigen optionalen Cookies und keine lokale Browser-Speicherung gefunden. Die rechtliche Einordnung des Admin-Cookies und die dafür erforderliche Information sind anhand der tatsächlichen Nutzung zu prüfen.

Admin-Inhalte in PostgreSQL

Administratoren können über die CMS-Funktionen Artikel, Tool-Einträge, Business-Leistungen und Anfragen speichern und bearbeiten. Dabei werden auch die Kontodaten des jeweiligen Admins und die von ihm in CMS-Felder eingetragenen Inhalte gespeichert. Zugriffsberechtigt sind die im System eingerichteten Admin-Konten. Berechtigungsverwaltung, tatsächliche Datenbank- und Backup-Berechtigungen sowie Lösch- und Aufbewahrungsfristen sind im jeweiligen Betrieb zu prüfen und festzulegen.

Externe Ressourcen und Verbindungen

Noch zu prüfen: tatsächlich verwendete Bildhosts, Empfänger, deren Datenschutzinformationen und mögliche Drittlandübermittlungen; außerdem Hosting- und Build-Dienstleister.

Rechte und Beschwerde

Betroffene können sich zur Ausübung ihrer Rechte, insbesondere Auskunft, Berichtigung, Löschung, Einschränkung, Widerspruch und Datenübertragbarkeit, an den Verantwortlichen unter info@aufinai.de wenden. Es besteht außerdem das Recht, Beschwerde bei einer zuständigen Datenschutzaufsichtsbehörde einzulegen.

Für private Unternehmen und selbständig Tätige in Bayern ist grundsätzlich das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) zuständig. Eine mögliche Sonderzuständigkeit für journalistisch-redaktionelle Tätigkeiten ist gesondert zu prüfen. Informationen zur Zuständigkeit des BayLDA.

Noch zu prüfen: ob im konkreten Fall ein Datenschutzbeauftragter zu benennen ist und ob für Teile des Angebots eine abweichende Aufsicht zuständig ist.

Rechtsquellen