Sikkerhed

Autentificering

Konti administreres af Supabase Auth med e-mail og adgangskode, Google OAuth eller GitHub OAuth. Efter login holder din browser et sessionstoken (en JWT), som fornyes automatisk af platformens middleware, så en fungerende session ikke stille udløber midt i arbejdet.

API'et accepterer det sessionstoken i to former: som den sessionscookie, dashboardet alligevel sender, eller som en Authorization Bearer-header. Programmatisk adgang uden browserlogin bruger i stedet API-nøgler, beskrevet nedenfor. Endpoints afviser forespørgsler uden gyldig legitimation; kun de eksplicit offentlige ruter, såsom sundhedstjekket og kontaktformularen, virker uden autentificering.

Roller og tilladelser

Hver konto har præcis én rolle: CLIENT, OPERATOR eller ADMIN. Kunder ejer robotter og betaler for sessioner, operatører styrer robotter og tjener på sessioner, og administratorer driver platformen. Du vælger mellem kunde og operatør under onboardingen; adminrollen tildeles af platformens administratorer og kan ikke selv vælges.

Rollekontroller sker serverside ved hver forespørgsel, ikke i UI'et. Under API'et er databaseadgang derudover begrænset med row-level security-politikker, så selv en fejl i et endpoint ikke bliver til fri adgang til andre kontis rækker.

API-nøgler

API-nøgler giver scripts og servere adgang uden browserlogin. Du opretter og tilbagekalder dem i /dashboard/settings; nøgler bærer præfikset ayr_live_ og sendes som en Authorization Bearer-header. En nøgle handler med rollen og tilladelserne for den konto, der oprettede den, så en lækket nøgle er præcis lige så slem som en lækket adgangskode.

• Hold nøgler serverside. De hører ikke hjemme i klientside-JavaScript, mobilapps eller offentlige repositories.
• Brug én nøgle per integration. Lækker noget, vil du kunne tilbagekalde én forbruger, ikke dem alle.
• Roter uden nedetid: opret erstatningsnøglen først, udrul den, tilbagekald derefter den gamle nøgle i /dashboard/settings.
• Tilbagekald øjeblikkeligt ved enhver mistanke. At oprette en ny nøgle tager sekunder; en angriber med en gyldig nøgle kan gøre alt, din konto kan.

Sikring under live styring

Live styring er bundet til et sessionslease. En robot accepterer kun kommandoer, mens den er i præcis én ACTIVE session, og kun fra den operatør, der holder den session; robotten selv markeres IN_SESSION for alle andre. En operatør kan højst holde én ACTIVE eller PAUSED session ad gangen, hvilket udelukker, at én person nominelt styrer to arme samtidig.

Cockpittet har et nødstop, der øjeblikkeligt standser armen, og at sætte sessionen på pause eller afslutte den standser kommandoflowet som helhed. Ud over det overvåger platformen operatørens aktivitet: efter en periode uden input sendes en inaktivitetsadvarsel, og forbliver operatøren inaktiv, stoppes sessionen automatisk. Det beskytter begge sider, kunden mod at betale for ledig tid og robotten mod at sidde i en ukontrolleret tilstand med et aktivt lease.

Revisionsspor

Hver session fører en hændelseslog: start og slut, pauser og genoptagelser, aktivitetstjek, inaktivitetsadvarsler, operatørskift, forlængelsesanmodninger og fejl, hver med et tidsstempel. Når en tvist gennemgås, er denne hændelseslog hovedbeviset, hvilket er endnu en grund til, at platformen skriver den automatisk i stedet for at stole på nogens hukommelse.

Ud over sessioner registreres væsentlige platformshandlinger i en revisionslog med det handlende bruger-id, handlingen, den berørte ressource og metadata. Profilændringer, betalingsrelevante transaktioner og adminhandlinger efterlader alle poster. Revisionsposter skrives af platformen og kan ikke redigeres gennem nogen brugerflade.

Kryptering og databeskyttelse

Al trafik til og fra platformen er krypteret under transport med TLS, herunder videostreams og styringssignaler. På datalaget begrænser row-level security-politikker databaseadgang per konto. Betalingsdata er den klareste grænse af alle: kort- og bankoplysninger håndteres udelukkende af Stripe og rører aldrig AY-Robots-servere.

Rapportering af en sårbarhed

Finder du et sikkerhedsproblem, så rapporter det ansvarligt gennem siden /security eller formularen /contact med kategorien Bug Report. Inkluder, hvad du fandt, hvor, og hvordan det reproduceres; tilgå ikke andre brugeres data ud over det minimum, der er nødvendigt for at demonstrere problemet, og offentliggør ikke detaljer, før vi har haft en rimelig chance for at rette det. Vi læser hver rapport.

Ofte stillede spørgsmål