Beveiliging

Authenticatie

Accounts worden beheerd door Supabase Auth met e-mail en wachtwoord, Google OAuth of GitHub OAuth. Na het inloggen bewaart uw browser een sessietoken (een JWT) dat automatisch wordt vernieuwd door de platformmiddleware, zodat een lopende sessie niet stilletjes midden in het werk verloopt.

De API accepteert dit sessietoken in twee vormen: als de sessiecookie die het dashboard toch al verstuurt, of als een Authorization Bearer-header. Programmatische toegang zonder browserlogin gebruikt in plaats daarvan API-sleutels, hieronder beschreven. Endpoints wijzen verzoeken zonder geldige credential af; alleen de expliciet publieke routes, zoals de health check en het contactformulier, werken zonder authenticatie.

Rollen en rechten

Elk account heeft precies één rol: CLIENT, OPERATOR of ADMIN. Klanten bezitten robots en betalen voor sessies, operators besturen robots en verdienen aan sessies, en beheerders runnen het platform. U kiest tijdens de onboarding tussen klant en operator; de rol admin wordt toegewezen door platformbeheerders en kan niet zelf worden gekozen.

Rolcontroles gebeuren serverzijdig bij elk verzoek, niet in de interface. Onder de API wordt databasetoegang bovendien beperkt met row-level-securitybeleid, zodat zelfs een fout in een endpoint niet leidt tot vrije toegang tot de rijen van andere accounts.

API-sleutels

API-sleutels geven scripts en servers toegang zonder browserlogin. U maakt en trekt ze in onder /dashboard/settings; sleutels dragen het voorvoegsel ayr_live_ en worden verstuurd als een Authorization Bearer-header. Een sleutel handelt met de rol en de rechten van het account dat hem heeft aangemaakt, dus een gelekte sleutel is precies zo erg als een gelekt wachtwoord.

• Houd sleutels serverzijdig. Ze horen niet thuis in clientzijdige JavaScript, mobiele apps of publieke repositories.
• Gebruik één sleutel per integratie. Lekt er iets, dan wilt u één afnemer intrekken, niet allemaal.
• Roteer zonder downtime: maak eerst de vervangende sleutel aan, rol hem uit, trek daarna de oude sleutel in via /dashboard/settings.
• Trek bij elke verdenking direct in. Een nieuwe sleutel aanmaken kost seconden; een aanvaller met een geldige sleutel kan alles wat uw account kan.

Waarborgen tijdens live besturing

Live besturing is gebonden aan een sessielease. Een robot accepteert alleen commando's zolang hij zich in precies één ACTIVE-sessie bevindt, en alleen van de operator die deze sessie houdt; voor iedereen anders is de robot gemarkeerd als IN_SESSION. Een operator kan hoogstens één ACTIVE- of PAUSED-sessie tegelijk houden, wat uitsluit dat één persoon nominaal twee armen tegelijk bestuurt.

De cockpit biedt een noodstop die de arm onmiddellijk stillegt, en het pauzeren of beëindigen van de sessie stopt de commandostroom als geheel. Daarnaast bewaakt het platform de operatoractiviteit: na een periode zonder invoer wordt een inactiviteitswaarschuwing gestuurd, en blijft de operator inactief, dan wordt de sessie automatisch gestopt. Dat beschermt beide kanten, de klant tegen betalen voor stilstand en de robot tegen een ongecontroleerde toestand met een actieve lease.

Audittrail

Elke sessie houdt een gebeurtenislogboek bij: start en einde, pauzes en hervattingen, activiteitscontroles, inactiviteitswaarschuwingen, operatorwissels, verlengingsverzoeken en fouten, elk met een tijdstempel. Wordt een geschil beoordeeld, dan is dit logboek het belangrijkste bewijs, nog een reden waarom het platform het automatisch schrijft in plaats van te vertrouwen op iemands geheugen.

Naast sessies worden belangrijke platformacties vastgelegd in een auditlog, met het id van de handelende gebruiker, de actie, de betrokken resource en metadata. Profielwijzigingen, betalingsrelevante transacties en beheerdersacties laten allemaal vermeldingen na. Auditvermeldingen worden door het platform geschreven en zijn via geen enkele gebruikersinterface te bewerken.

Versleuteling en gegevensbescherming

Al het verkeer van en naar het platform is onderweg versleuteld met TLS, inclusief videostreams en besturingssignalen. Op dataniveau beperkt row-level-securitybeleid de databasetoegang per account. Betaalgegevens zijn de duidelijkste grens van allemaal: kaarten en bankgegevens worden uitsluitend door Stripe verwerkt en raken de servers van AY-Robots nooit.

Een kwetsbaarheid melden

Vindt u een beveiligingsprobleem, meld het dan verantwoord via de pagina /security of het formulier op /contact in de categorie Bug Report. Vermeld wat u hebt gevonden, waar en hoe het te reproduceren is; benader geen data van andere gebruikers verder dan het minimum dat nodig is om het probleem aan te tonen, en publiceer geen details voordat wij een redelijke kans hebben gehad het op te lossen. Wij lezen elke melding.

Veelgestelde vragen