Sicherheit

Authentifizierung

Konten verwaltet Supabase Auth, mit E-Mail und Passwort, Google OAuth oder GitHub OAuth. Nach dem Login hält Ihr Browser ein Session-Token (ein JWT), das die Plattform-Middleware automatisch erneuert; eine laufende Session läuft also nicht mitten in der Arbeit still ab.

Die API akzeptiert dieses Session-Token in zwei Formen: als das Session-Cookie, das das Dashboard ohnehin sendet, oder als Authorization-Bearer-Header. Programmatischer Zugriff ohne Browser-Login nutzt stattdessen API-Keys, siehe unten. Endpunkte weisen Anfragen ohne gültige Berechtigung ab; nur die ausdrücklich öffentlichen Routen, etwa der Health-Check und das Kontaktformular, funktionieren ohne Authentifizierung.

Rollen und Berechtigungen

Jedes Konto hat genau eine Rolle: CLIENT, OPERATOR oder ADMIN. Kunden besitzen Roboter und zahlen für Sessions, Operatoren steuern Roboter und verdienen an Sessions, und Admins betreiben die Plattform. Zwischen Kunde und Operator wählen Sie beim Onboarding; die Admin-Rolle vergeben Plattform-Administratoren, selbst wählen lässt sie sich nicht.

Rollenprüfungen passieren serverseitig bei jeder Anfrage, nicht in der Oberfläche. Unterhalb der API ist der Datenbankzugriff zusätzlich mit Row-Level-Security-Policies eingeschränkt, sodass selbst ein Fehler in einem Endpunkt nicht zum freien Zugriff auf die Zeilen anderer Konten wird.

API-Keys

API-Keys geben Skripten und Servern Zugriff ohne Browser-Login. Sie legen sie in /dashboard/settings an und widerrufen sie dort; Keys tragen das Präfix ayr_live_ und werden als Authorization-Bearer-Header gesendet. Ein Key handelt mit der Rolle und den Berechtigungen des Kontos, das ihn erstellt hat; ein geleakter Key ist also exakt so schlimm wie ein geleaktes Passwort.

• Halten Sie Keys serverseitig. In clientseitiges JavaScript, Mobile-Apps oder öffentliche Repositories gehören sie nicht.
• Nutzen Sie einen Key pro Integration. Leakt etwas, wollen Sie einen Konsumenten widerrufen, nicht alle.
• Rotieren ohne Ausfall: erst den Ersatz-Key anlegen, ausrollen, dann den alten Key in /dashboard/settings widerrufen.
• Widerrufen Sie bei jedem Verdacht sofort. Ein frischer Key kostet Sekunden; ein Angreifer mit gültigem Key kann alles, was Ihr Konto kann.

Schutzmechanismen bei der Live-Steuerung

Live-Steuerung ist an eine Session-Lease gebunden. Ein Roboter nimmt Befehle nur an, solange er sich in genau einer ACTIVE-Session befindet, und nur vom Operator, der diese Session hält; für alle anderen ist der Roboter als IN_SESSION markiert. Ein Operator kann höchstens eine ACTIVE- oder PAUSED-Session gleichzeitig halten, was ausschließt, dass eine Person nominell zwei Arme zugleich steuert.

Das Cockpit bietet einen Not-Stopp, der den Arm sofort anhält, und das Pausieren oder Beenden der Session stoppt den Befehlsfluss insgesamt. Zusätzlich überwacht die Plattform die Operator-Aktivität: Nach einer Phase ohne Eingaben wird eine Inaktivitätswarnung gesendet, und bleibt der Operator inaktiv, wird die Session automatisch gestoppt. Das schützt beide Seiten, den Kunden vor der Bezahlung von Leerlauf und den Roboter davor, mit aktiver Lease in einem unkontrollierten Zustand zu stehen.

Audit-Trail

Jede Session führt ein Ereignisprotokoll: Start und Ende, Pausen und Fortsetzungen, Aktivitätsprüfungen, Inaktivitätswarnungen, Operator-Wechsel, Verlängerungsanfragen und Fehler, jeweils mit Zeitstempel. Wird ein Streitfall geprüft, ist dieses Protokoll das zentrale Beweismittel, ein Grund mehr, warum die Plattform es automatisch schreibt, statt sich auf irgendjemandes Gedächtnis zu verlassen.

Über Sessions hinaus werden wesentliche Plattform-Aktionen in einem Audit-Log festgehalten, mit der Id des handelnden Nutzers, der Aktion, der betroffenen Ressource und Metadaten. Profiländerungen, zahlungsrelevante Transaktionen und Admin-Aktionen hinterlassen alle Einträge. Audit-Einträge schreibt die Plattform; über keine Nutzeroberfläche lassen sie sich bearbeiten.

Verschlüsselung und Datenschutz

Der gesamte Verkehr von und zur Plattform ist mit TLS transportverschlüsselt, einschließlich Videostreams und Steuersignalen. Auf der Datenebene beschränken Row-Level-Security-Policies den Datenbankzugriff pro Konto. Zahlungsdaten sind die klarste Grenze von allen: Karten und Bankdaten verarbeitet ausschließlich Stripe, sie berühren die Server von AY-Robots nie.

Eine Schwachstelle melden

Wenn Sie ein Sicherheitsproblem finden, melden Sie es verantwortungsvoll über die Seite /security oder das Formular unter /contact in der Kategorie Bug Report. Beschreiben Sie, was Sie gefunden haben, wo und wie es sich reproduzieren lässt; greifen Sie nicht über das zur Demonstration nötige Minimum hinaus auf Daten anderer Nutzer zu und veröffentlichen Sie keine Details, bevor wir eine faire Chance zur Behebung hatten. Wir lesen jede Meldung.

Häufige Fragen