Bezbednost

Autentifikacija

Nalozima upravlja Supabase Auth putem i-mejla i lozinke, Google OAuth-a ili GitHub OAuth-a. Nakon prijave, vaš pregledač drži token sesije (JWT) koji middleware platforme automatski obnavlja, pa aktivna sesija nečujno ne ističe usred rada.

API prihvata taj token sesije u dva oblika: kao kolačić sesije koji kontrolna tabla i inače šalje, ili kao Authorization Bearer zaglavlje. Programski pristup bez prijave preko pregledača umesto toga koristi API ključeve, opisane ispod. Krajnje tačke odbijaju zahteve bez validnog kredencijala; rade samo izričito javne rute, poput provere zdravlja i kontakt forme, bez autentifikacije.

Uloge i dozvole

Svaki nalog ima tačno jednu ulogu: CLIENT, OPERATOR ili ADMIN. Klijenti poseduju robote i plaćaju za sesije, operateri upravljaju robotima i zarađuju od sesija, a administratori vode platformu. Između klijenta i operatera birate tokom onboardinga; ulogu admina dodeljuju administratori platforme i ne može se samostalno izabrati.

Provere uloga se odvijaju na strani servera za svaki zahtev, a ne u interfejsu. Ispod API-ja, pristup bazi podataka je dodatno ograničen politikama bezbednosti na nivou reda, pa čak ni greška u krajnjoj tački ne pretvara se u slobodan pristup redovima drugih naloga.

API ključevi

API ključevi omogućavaju skriptama i serverima pristup bez prijave preko pregledača. Kreirate ih i opozivate u /dashboard/settings; ključevi nose prefiks ayr_live_ i šalju se kao Authorization Bearer zaglavlje. Ključ deluje sa ulogom i dozvolama naloga koji ga je kreirao, pa je procureli ključ podjednako loš kao procurela lozinka.

• Držite ključeve na strani servera. Ne pripadaju klijentskom JavaScript-u, mobilnim aplikacijama niti javnim repozitorijumima.
• Koristite jedan ključ po integraciji. Kada nešto procuri, želite da opozovete jednog potrošača, a ne sve njih.
• Rotirajte bez zastoja: prvo kreirajte zamenski ključ, primenite ga, zatim opozovite stari ključ u /dashboard/settings.
• Opozovite odmah kod bilo kakve sumnje. Kreiranje novog ključa traje sekunde; napadač sa validnim ključem može da uradi sve što i vaš nalog.

Zaštitni mehanizmi tokom upravljanja uživo

Upravljanje uživo je vezano za zakup sesije. Robot prihvata komande samo dok je u tačno jednoj ACTIVE sesiji, i samo od operatera koji drži tu sesiju; sam robot je za sve ostale označen kao IN_SESSION. Operater može da drži najviše jednu ACTIVE ili PAUSED sesiju odjednom, čime se isključuje da jedna osoba nominalno upravlja sa dve ruke istovremeno.

Kokpit pruža hitno zaustavljanje koje odmah zaustavlja ruku, a pauziranje ili završavanje sesije u celini zaustavlja tok komandi. Uz to, platforma nadzire aktivnost operatera: nakon perioda bez unosa šalje se upozorenje o neaktivnosti, a ako operater ostane neaktivan, sesija se automatski zaustavlja. To štiti obe strane, klijenta od plaćanja besposlenog vremena i robota od stajanja u nekontrolisanom stanju sa aktivnim zakupom.

Revizioni dnevnik

Svaka sesija čuva dnevnik događaja: početak i kraj, pauze i nastavke, provere aktivnosti, upozorenja o neaktivnosti, promene operatera, zahteve za produženje i greške, svaki sa vremenskom oznakom. Kada se spor pregleda, ovaj dnevnik događaja je glavni dokaz, što je još jedan razlog zašto ga platforma piše automatski umesto oslanjanja na nečije pamćenje.

Osim sesija, značajne radnje na platformi beleže se u revizioni dnevnik sa id-om korisnika koji je delovao, radnjom, pogođenim resursom i metapodacima. Promene profila, transakcije relevantne za plaćanje i administratorske radnje sve ostavljaju zapise. Revizione zapise piše platforma i nisu izmenjivi kroz bilo koji korisnički interfejs.

Enkripcija i zaštita podataka

Sav saobraćaj ka i od platforme je enkriptovan tokom prenosa TLS-om, uključujući video stream-ove i upravljačke signale. Na nivou podataka, politike bezbednosti na nivou reda ograničavaju pristup bazi podataka po nalogu. Podaci o plaćanju su najjasnija granica od svih: kartice i bankovni podaci se obrađuju isključivo kod Stripe-a i nikada ne dodiruju servere AY-Robots.

Prijava ranjivosti

Ako pronađete bezbednosni problem, prijavite ga odgovorno kroz stranicu /security ili formu /contact koristeći kategoriju Bug Report. Uključite šta ste pronašli, gde i kako to reprodukovati; ne pristupajte podacima drugih korisnika izvan minimuma potrebnog za demonstraciju problema, i ne objavljujte detalje pre nego što smo imali razumnu priliku da to popravimo. Čitamo svaku prijavu.

Često postavljana pitanja