Sekuriteit

Verifikasie

Rekeninge word bestuur deur Supabase Auth met e-pos en wagwoord, Google OAuth, of GitHub OAuth. Ná aanmelding hou jou blaaier 'n sessietoken ('n JWT) wat outomaties deur die platform-middleware verfris word, sodat 'n werkende sessie nie stilweg midde-werk verval nie.

Die API aanvaar daardie sessietoken in twee vorme: as die sessiekoekie wat die dashboard in elk geval stuur, of as 'n Authorization Bearer-header. Programmatiese toegang sonder 'n blaaieraanmelding gebruik eerder API-sleutels, hieronder beskryf. Eindpunte verwerp versoeke sonder 'n geldige geloofsbrief; slegs die uitdruklik openbare roetes, soos die gesondheidstoets en die kontakvorm, werk ongeverifieerd.

Rolle en toestemmings

Elke rekening het presies een rol: CLIENT, OPERATOR, of ADMIN. Kliënte besit robotte en betaal vir sessies, operateurs bestuur robotte en verdien van sessies, en administrateurs bestuur die platform. Jy kies tussen kliënt en operateur tydens onboarding; die administrateurrol word deur platformadministrateurs toegeken en kan nie self gekies word nie.

Rolkontroles gebeur aan die serverkant by elke versoek, nie in die UI nie. Onder die API word databasistoegang bykomend beperk met row-level-security-beleide, sodat selfs 'n fout in 'n eindpunt nie in vrye toegang tot ander rekeninge se rye verander nie.

API-sleutels

API-sleutels gee skripte en bedieners toegang sonder 'n blaaieraanmelding. Jy skep en herroep hulle in /dashboard/settings; sleutels dra die voorvoegsel ayr_live_ en word as 'n Authorization Bearer-header gestuur. 'n Sleutel tree op met die rol en toestemmings van die rekening wat dit geskep het, sodat 'n gelekte sleutel presies so erg is soos 'n gelekte wagwoord.

• Hou sleutels aan die serverkant. Hulle hoort nie in kliëntkant-JavaScript, mobiele apps, of openbare repositories nie.
• Gebruik een sleutel per integrasie. As iets lek, wil jy een verbruiker herroep, nie almal nie.
• Roteer sonder uitvaltyd: skep eers die vervangende sleutel, ontplooi dit, en herroep dan die ou sleutel in /dashboard/settings.
• Herroep onmiddellik by enige vermoede. Om 'n nuwe sleutel te skep, kos sekondes; 'n aanvaller met 'n geldige sleutel kan enigiets doen wat jou rekening kan doen.

Waarborge tydens lewende beheer

Lewende beheer is aan 'n sessiehuur gebind. 'n Robot aanvaar opdragte slegs terwyl dit in presies een ACTIVE-sessie is, en slegs van die operateur wat daardie sessie hou; die robot self word as IN_SESSION vir almal anders gemerk. 'n Operateur kan hoogstens een ACTIVE- of PAUSED-sessie op 'n slag hou, wat uitsluit dat een persoon nominaal twee arms terselfdertyd beheer.

Die cockpit bied 'n noodstop wat die arm onmiddellik staak, en om die sessie te pouseer of te beëindig, staak die opdragvloei in geheel. Daarbenewens monitor die platform operateuraktiwiteit: na 'n periode sonder toevoer word 'n onaktiwiteitswaarskuwing gestuur, en as die operateur onaktief bly, word die sessie outomaties gestop. Dit beskerm albei kante, die kliënt teen betaling vir ledige tyd en die robot teen 'n onbeheerde toestand met 'n lewende sessiehuur.

Oudit-spoor

Elke sessie hou 'n gebeurtenislog by: begin en einde, pouses en hervattings, aktiwiteitstoetse, onaktiwiteitswaarskuwings, operateurwisselings, verlengingsaanvrae, en foute, elkeen met 'n tydstempel. Wanneer 'n geskil hersien word, is hierdie gebeurtenislog die primêre bewys, wat een rede te meer is waarom die platform dit outomaties skryf in plaas daarvan om op iemand se geheue staat te maak.

Buiten sessies word beduidende platformaksies in 'n oudit-logboek aangeteken met die id van die handelende gebruiker, die aksie, die geraakte hulpbron, en metadata. Profielveranderinge, betalingsrelevante transaksies, en administrateuraksies laat almal inskrywings agter. Oudit-rekords word deur die platform geskryf en kan nie via enige gebruikerskoppelvlak gewysig word nie.

Enkripsie en databeskerming

Alle verkeer na en van die platform word tydens vervoer met TLS geënkripteer, insluitend videostrome en beheerseine. Op datavlak beperk row-level-security-beleide databasistoegang per rekening. Betaaldata is die duidelikste grens van almal: kaarte en bankbesonderhede word uitsluitlik deur Stripe hanteer en raak nooit AY-Robots-bedieners nie.

'n Kwesbaarheid rapporteer

As jy 'n sekuriteitskwessie vind, rapporteer dit verantwoordelik via die /security-bladsy of die /contact-vorm met die Bug Report-kategorie. Sluit in wat jy gevind het, waar, en hoe om dit te herhaal; kry nie toegang tot ander gebruikers se data verder as die minimum wat nodig is om die kwessie te demonstreer nie, en publiseer nie besonderhede voordat ons 'n redelike kans gehad het om dit reg te stel nie. Ons lees elke verslag.

Gereelde vrae