Sigurnost

Autentikacija

Računima upravlja Supabase Auth sa email adresom i lozinkom, Google OAuth-om ili GitHub OAuth-om. Nakon prijave, vaš browser drži sesijski token (JWT) koji se automatski obnavlja od strane middleware-a platforme, tako da aktivna sesija tiho ne istekne usred rada.

API prihvata taj sesijski token u dva oblika: kao sesijski cookie koji kontrolna tabla i onako šalje, ili kao Authorization Bearer header. Programski pristup bez prijave putem browsera koristi API ključeve umjesto toga, opisane ispod. Endpoint-i odbijaju zahtjeve bez validnog kredencijala; samo eksplicitno javne rute, poput provjere zdravlja i kontakt obrasca, funkcionišu bez autentikacije.

Uloge i dozvole

Svaki račun ima tačno jednu ulogu: CLIENT, OPERATOR ili ADMIN. Klijenti posjeduju robote i plaćaju za sesije, operateri upravljaju robotima i zarađuju od sesija, a administratori vode platformu. Birate između klijenta i operatera tokom onboardinga; uloga admin dodjeljuje se od strane administratora platforme i ne može se samostalno izabrati.

Provjere uloga se dešavaju na serveru pri svakom zahtjevu, a ne u korisničkom interfejsu. Ispod API-ja, pristup bazi podataka je dodatno ograničen politikama row-level security, tako da ni greška u nekom endpoint-u ne pretvara se u slobodan pristup redovima drugih računa.

API ključevi

API ključevi daju skriptama i serverima pristup bez prijave putem browsera. Kreirate ih i opozivate u /dashboard/settings; ključevi nose prefiks ayr_live_ i šalju se kao Authorization Bearer header. Ključ djeluje sa ulogom i dozvolama računa koji ga je kreirao, pa je procurio ključ tačno onoliko opasan koliko i procurila lozinka.

• Čuvajte ključeve samo na serveru. Ne pripadaju JavaScript-u na klijentu, mobilnim aplikacijama, niti javnim repozitorijima.
• Koristite jedan ključ po integraciji. Kada nešto procuri, želite opozvati jednog potrošača, ne sve.
• Rotirajte bez prekida rada: prvo kreirajte zamjenski ključ, postavite ga u produkciju, zatim opozovite stari ključ u /dashboard/settings.
• Opozovite odmah kod bilo kakve sumnje. Kreiranje novog ključa košta sekunde; napadač sa validnim ključem može uraditi sve što može i vaš račun.

Mjere zaštite 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 držati najviše jednu ACTIVE ili PAUSED sesiju u isto vrijeme, što isključuje mogućnost da jedna osoba nominalno upravlja sa dvije ruke istovremeno.

Kokpit pruža hitno zaustavljanje koje odmah zaustavlja ruku, a pauziranje ili završetak sesije zaustavlja protok komandi u cjelini. Pored toga, platforma prati aktivnost operatera: nakon perioda bez unosa šalje se upozorenje o neaktivnosti, a ako operater ostane neaktivan, sesija se automatski zaustavlja. To štiti obje strane, klijenta od plaćanja praznog vremena i robota od zadržavanja u nekontrolisanom stanju sa aktivnim zakupom.

Revizijski trag

Svaka sesija čuva zapisnik aktivnosti: početak i kraj, pauze i nastavke, provjere aktivnosti, upozorenja o neaktivnosti, promjene operatera, zahtjeve za produženje i greške, svaku sa vremenskom oznakom. Kada se spor pregleda, ovaj zapisnik aktivnosti je primarni dokaz, što je još jedan razlog zašto ga platforma automatski piše umjesto da se oslanja na nečije sjećanje.

Van sesija, značajne akcije platforme bilježe se u revizijskom zapisniku sa id-om korisnika koji je djelovao, akcijom, pogođenim resursom i metapodacima. Promjene profila, transakcije relevantne za plaćanja i akcije administratora ostavljaju svi zapise. Revizijske zapise piše platforma i nisu izmjenjivi kroz nijedan interfejs za korisnike.

Enkripcija i zaštita podataka

Sav saobraćaj ka i od platforme je enkriptovan tokom prenosa pomoću TLS-a, uključujući video prenose i kontrolne signale. Na sloju podataka, politike row-level security ograničavaju pristup bazi podataka po računu. Podaci o plaćanju su najjasnija granica od svih: kartice i bankovni podaci obrađuju se isključivo od strane Stripe-a i nikada ne dodiruju servere AY-Robots.

Prijavljivanje ranjivosti

Ako pronađete sigurnosni problem, prijavite ga odgovorno preko stranice /security ili obrasca /contact koristeći kategoriju Bug Report. Uključite šta ste pronašli, gdje i kako se reprodukuje; ne pristupajte podacima drugih korisnika van minimuma potrebnog da demonstrirate problem, i ne objavljujte detalje prije nego što smo imali razumnu priliku da ga popravimo. Čitamo svaku prijavu.

Često postavljana pitanja