Sikkerhet

Autentisering

Kontoer forvaltes av Supabase Auth med e-post og passord, Google OAuth eller GitHub OAuth. Etter innlogging holder nettleseren din et økt-token (en JWT) som fornyes automatisk av plattform-middlewaren, slik at en fungerende økt ikke stille utløper midt i arbeidet.

API-et godtar dette økt-tokenet i to former: som øktcookien dashbordet uansett sender, eller som en Authorization Bearer-header. Programmatisk tilgang uten nettleserinnlogging bruker i stedet API-nøkler, beskrevet under. Endepunkter avviser forespørsler uten gyldig legitimasjon; bare de eksplisitt offentlige rutene, som helsesjekken og kontaktskjemaet, fungerer uautentisert.

Roller og rettigheter

Hver konto har nøyaktig én rolle: CLIENT, OPERATOR eller ADMIN. Kunder eier roboter og betaler for økter, operatører styrer roboter og tjener på økter, og admins driver plattformen. Du velger mellom kunde og operatør under onboardingen; admin-rollen tildeles av plattformadministratorer og kan ikke velges selv.

Rollesjekker skjer serverside på hver forespørsel, ikke i brukergrensesnittet. Under API-et er databasetilgangen dessuten begrenset med sikkerhetspolicyer på radnivå, så selv en feil i et endepunkt gir ikke fri tilgang til andre kontoers rader.

API-nøkler

API-nøkler gir skript og servere tilgang uten nettleserinnlogging. Du oppretter og tilbakekaller dem i /dashboard/settings; nøkler har prefikset ayr_live_ og sendes som en Authorization Bearer-header. En nøkkel handler med rollen og rettighetene til kontoen som opprettet den, så en lekket nøkkel er nøyaktig like ille som et lekket passord.

• Hold nøkler serverside. De hører ikke hjemme i klientside-JavaScript, mobilapper eller offentlige repositorier.
• Bruk én nøkkel per integrasjon. Lekker noe, vil du tilbakekalle én forbruker, ikke alle.
• Roter uten nedetid: opprett erstatningsnøkkelen først, distribuer den, og tilbakekall så den gamle nøkkelen i /dashboard/settings.
• Tilbakekall umiddelbart ved enhver mistanke. Å opprette en ny nøkkel koster sekunder; en angriper med en gyldig nøkkel kan gjøre alt kontoen din kan.

Sikringstiltak under direkte styring

Direkte styring er bundet til en øktlease. En robot godtar kommandoer bare mens den er i nøyaktig én ACTIVE-økt, og bare fra operatøren som holder den økten; roboten selv merkes IN_SESSION for alle andre. En operatør kan holde høyst én ACTIVE- eller PAUSED-økt om gangen, noe som utelukker at én person nominelt styrer to armer samtidig.

Cockpit har en nødstopp som stanser armen umiddelbart, og å pause eller avslutte økten stopper kommandoflyten som helhet. På toppen av det overvåker plattformen operatøraktivitet: etter en periode uten input sendes en inaktivitetsadvarsel, og forblir operatøren inaktiv, stoppes økten automatisk. Det beskytter begge sider, kunden fra å betale for stillestående tid og roboten fra å sitte i en ukontrollert tilstand med en aktiv lease.

Revisjonslogg

Hver økt holder en hendelseslogg: start og slutt, pauser og gjenopptak, aktivitetskontroller, inaktivitetsadvarsler, operatørbytter, forlengelsesforespørsler og feil, hver med et tidsstempel. Når en tvist gjennomgås, er denne hendelsesloggen hovedbeviset, noe som er enda en grunn til at plattformen skriver den automatisk i stedet for å stole på noens hukommelse.

Utover økter registreres viktige plattformhandlinger i en revisjonslogg med den handlende brukerens id, handlingen, den berørte ressursen og metadata. Profilendringer, betalingsrelevante transaksjoner og admin-handlinger etterlater alle oppføringer. Revisjonsposter skrives av plattformen og kan ikke redigeres gjennom noe brukervendt grensesnitt.

Kryptering og databeskyttelse

All trafikk til og fra plattformen er kryptert under overføring med TLS, inkludert videostrømmer og styringssignaler. På datalaget begrenser sikkerhetspolicyer på radnivå databasetilgang per konto. Betalingsdata er det klareste skillet av alle: kort og bankopplysninger håndteres utelukkende av Stripe og berører aldri AY-Robots-servere.

Melde fra om en sårbarhet

Finner du et sikkerhetsproblem, meld fra om det på en ansvarlig måte gjennom /security-siden eller /contact-skjemaet med kategorien Bug Report. Inkluder hva du fant, hvor, og hvordan det kan gjenskapes; ikke få tilgang til andre brukeres data utover det minimum som trengs for å demonstrere problemet, og ikke publiser detaljer før vi har hatt en rimelig sjanse til å fikse det. Vi leser hver rapport.

Ofte stilte spørsmål