Sicurezza

Autenticazione

Gli account sono gestiti da Supabase Auth con email e password, OAuth Google o OAuth GitHub. Dopo l'accesso, il browser conserva un token di sessione (un JWT) rinnovato automaticamente dal middleware della piattaforma, così una sessione funzionante non scade silenziosamente a metà lavoro.

L'API accetta questo token di sessione in due forme: come cookie di sessione che la dashboard invia comunque, oppure come header Authorization Bearer. L'accesso programmatico senza login via browser usa invece chiavi API, descritte più avanti. Gli endpoint rifiutano le richieste senza credenziali valide; solo le rotte esplicitamente pubbliche, come il controllo di salute e il modulo di contatto, funzionano senza autenticazione.

Ruoli e permessi

Ogni account ha esattamente un ruolo: CLIENT, OPERATOR o ADMIN. I clienti possiedono i robot e pagano per le sessioni, gli operatori controllano i robot e guadagnano dalle sessioni, gli admin gestiscono la piattaforma. Si sceglie tra cliente e operatore durante l'onboarding; il ruolo admin viene assegnato dagli amministratori della piattaforma e non può essere selezionato autonomamente.

I controlli sui ruoli avvengono lato server a ogni richiesta, non nell'interfaccia. Al di sotto dell'API, l'accesso al database è ulteriormente limitato con criteri di sicurezza a livello di riga (row-level security), così anche un bug in un endpoint non si trasforma in accesso libero alle righe di altri account.

Chiavi API

Le chiavi API danno accesso a script e server senza login via browser. Si creano e revocano in /dashboard/settings; le chiavi portano il prefisso ayr_live_ e vengono inviate come header Authorization Bearer. Una chiave agisce con il ruolo e i permessi dell'account che l'ha creata, quindi una chiave trapelata è esattamente grave quanto una password trapelata.

• Conservare le chiavi lato server. Non appartengono a JavaScript lato client, app mobile o repository pubblici.
• Usare una chiave per integrazione. Se qualcosa trapela, si vuole revocare un solo consumatore, non tutti.
• Ruotare senza interruzioni: creare prima la chiave sostitutiva, distribuirla, poi revocare la chiave vecchia in /dashboard/settings.
• Revocare immediatamente al minimo sospetto. Creare una chiave nuova costa pochi secondi; un attaccante con una chiave valida può fare tutto ciò che può fare il proprio account.

Protezioni durante il controllo live

Il controllo live è vincolato a un lease di sessione. Un robot accetta comandi solo mentre si trova in esattamente una sessione ACTIVE, e solo dall'operatore titolare di quella sessione; il robot stesso risulta IN_SESSION per chiunque altro. Un operatore può mantenere al massimo una sessione ACTIVE o PAUSED alla volta, il che esclude che una persona controlli nominalmente due bracci contemporaneamente.

Il cockpit fornisce un arresto di emergenza che ferma immediatamente il braccio, e mettere in pausa o terminare la sessione interrompe il flusso di comandi nel suo complesso. Inoltre, la piattaforma monitora l'attività dell'operatore: dopo un periodo senza input viene inviato un avviso di inattività, e se l'operatore resta inattivo la sessione viene interrotta automaticamente. Questo protegge entrambe le parti: il cliente dal pagare per tempo morto e il robot dal restare in uno stato non controllato con un lease attivo.

Audit trail

Ogni sessione mantiene un log di eventi: inizio e fine, pause e riprese, controlli di attività, avvisi di inattività, cambi di operatore, richieste di estensione ed errori, ciascuno con un timestamp. Quando una contestazione viene esaminata, questo log di eventi è la prova principale, il che è un motivo in più per cui la piattaforma lo scrive automaticamente invece di affidarsi alla memoria di qualcuno.

Oltre alle sessioni, le azioni significative sulla piattaforma vengono registrate in un log di audit con l'id dell'utente che ha agito, l'azione, la risorsa interessata e i metadati. Modifiche al profilo, transazioni rilevanti per i pagamenti e azioni degli admin lasciano tutte una traccia. I record di audit vengono scritti dalla piattaforma e non sono modificabili tramite alcuna interfaccia utente.

Crittografia e protezione dei dati

Tutto il traffico da e verso la piattaforma è crittografato in transito con TLS, inclusi flussi video e segnali di controllo. A livello dati, criteri di sicurezza a livello di riga limitano l'accesso al database per singolo account. I dati di pagamento rappresentano il confine più netto di tutti: carte e dati bancari sono gestiti esclusivamente da Stripe e non raggiungono mai i server di AY-Robots.

Segnalare una vulnerabilità

Chi trova un problema di sicurezza è invitato a segnalarlo in modo responsabile tramite la pagina /security o il modulo /contact usando la categoria Bug Report. Occorre includere cosa è stato trovato, dove e come riprodurlo; è importante non accedere a dati di altri utenti oltre il minimo necessario per dimostrare il problema, e non pubblicare dettagli prima che sia stata data una ragionevole possibilità di risolverlo. Ogni segnalazione viene letta.

Domande frequenti