Sicherheit & Architektur

Vertrauen entsteht nicht durch ein Siegel. Sondern durch überprüfbare Grenzen.

Stayara trennt Identität, Fachberechtigung, Betriebsdaten und externe Zahlungen bewusst. Hier zeigen wir, welche Kontrolle wo greift – und was wir ausdrücklich nicht behaupten.

Implementierte Kontrollen

Keine diffuse „Enterprise Security“. Acht konkrete Prüfstellen.

Jede Aussage nennt den technischen Ort, an dem die Kontrolle greift. Das macht Sicherheitsfragen im Pilot- und Freigabeprozess konkret besprechbar.

Kontrolle 01

Tenant-Isolation auf dem Server

Jede fachliche Anfrage wird gegen Tenant-Kontext und Mitgliedschaft geprüft. Isolation ist kein ausgeblendeter Menüpunkt, sondern Teil der serverseitigen Datenabfrage.

Tenant-ID in Repository- und Berechtigungsprüfung
Kontrolle 02

Authentifizierung und Sitzungen

E-Mail-/Passwort-Identitäten verarbeitet Firebase Authentication. Kurzlebige ID-Tokens werden gegen eine HMAC-signierte httpOnly-Session getauscht.

Serverseitige Session statt Token im UI-Zustand
Kontrolle 03

PostgreSQL als Autorität

Tenant, Mitgliedschaften, Rollen und fachliche Einstellungen liegen autoritativ in PostgreSQL. Firebase Custom Claims entscheiden nicht über Fachberechtigungen.

Rolle und Tenant bleiben fachliche Betriebsdaten
Kontrolle 04

Verschlüsselte Provider-Zugänge

Channel-Zugangsdaten werden mit AES-256-GCM und tenant-/providergebundenen Authenticated Data verschlüsselt. Der Schlüssel liegt im Google Secret Manager.

Weder Klartext noch Chiffrat in API- und Audit-Antworten
Kontrolle 05

Nachvollziehbare Änderungen

Administrative Statusänderungen an Rollen, Domains, Zahlungen oder Integrationen erzeugen zuordenbare Audit-Einträge.

Akteur, Zeitpunkt, Aktion und fachlicher Kontext
Kontrolle 06

Stripe-hosted Zahlungen

Jede Agentur kann ein eigenes Stripe-Connect-Konto anbinden. Karteninformationen werden von Stripe verarbeitet und nicht in Stayara gespeichert.

Hosted Onboarding und signierte Zahlungsereignisse
Kontrolle 07

Idempotente Webhooks

Externe Ereignisse werden signaturgeprüft und idempotent verarbeitet. Wiederholte Zustellungen sollen keine doppelte Zustandsänderung erzeugen.

Ereignis-ID vor fachlicher Verarbeitung prüfen
Kontrolle 08

Europäische Cloud-Region

Cloud SQL for PostgreSQL, Firestore und Cloud Storage liegen für die produktive Plattform in europe-west4. Der Datenbankzugriff erfolgt über IAM und Cloud SQL Connector.

Region Niederlande · Zugriff ohne öffentliche DB-IP

Bewusst nicht behauptet

Transparenz gehört zur Sicherheitsarchitektur.

Ein nicht belegtes Versprechen schafft keine Sicherheit. Deshalb bleiben Zertifikate, Providerstatus und Verantwortungsgrenzen sichtbar.

01
PCI

Stayara ist nicht selbst PCI-zertifiziert. Karteninformationen werden ausschließlich durch Stripe verarbeitet.

02
Zertifikate

Stayara beruft sich auf keine ISO-27001- oder SOC-2-Zertifizierung, die nicht nachweisbar vorliegt.

03
Channel-Zugänge

Ein Provider wird erst aktiviert, wenn Zugang, Mapping, technische Prüfung und Freigabe tatsächlich vorliegen.

Sicherheitsrelevanten Hinweis gefunden?Wir behandeln konkrete Meldungen vertraulich und priorisiert.
kontakt@stayara.de

Stayara kennenlernen

Sicherheit nicht als Folie zeigen – am tatsächlichen Betriebsablauf prüfen.

Persönliche Demo