Zabezpečení

Autentizace

Účty spravuje Supabase Auth, s e-mailem a heslem, Google OAuth nebo GitHub OAuth. Po přihlášení váš prohlížeč drží session token (JWT), který middleware platformy automaticky obnovuje, takže běžící session uprostřed práce potichu nevyprší.

API přijímá tento session token ve dvou formách: jako session cookie, kterou dashboard stejně posílá, nebo jako hlavičku Authorization Bearer. Programový přístup bez přihlášení v prohlížeči místo toho používá API klíče, popsané níže. Endpointy odmítají požadavky bez platného přihlašovacího údaje; bez autentizace fungují jen výslovně veřejné routy, jako je health check a kontaktní formulář.

Role a oprávnění

Každý účet má přesně jednu roli: CLIENT, OPERATOR nebo ADMIN. Klienti vlastní roboty a platí za session, operátoři ovládají roboty a vydělávají na session a admini provozují platformu. Mezi klientem a operátorem si vyberete během onboardingu; roli admina přiděluje správce platformy a sám si ji vybrat nelze.

Kontroly role probíhají na straně serveru u každého požadavku, ne v rozhraní. Pod API je přístup k databázi navíc omezený politikami row-level security, takže ani chyba v endpointu se nepromění ve volný přístup k řádkům jiných účtů.

API klíče

API klíče dávají skriptům a serverům přístup bez přihlášení v prohlížeči. Vytváříte a odvoláváte je v /dashboard/settings; klíče nesou prefix ayr_live_ a posílají se jako hlavička Authorization Bearer. Klíč jedná s rolí a oprávněními účtu, který ho vytvořil, takže uniklý klíč je přesně tak zlý jako uniklé heslo.

• Uchovávejte klíče na straně serveru. Nepatří do klientského JavaScriptu, mobilních aplikací ani veřejných repozitářů.
• Používejte jeden klíč na integraci. Když něco unikne, chcete odvolat jednoho konzumenta, ne všechny.
• Rotujte bez výpadku: nejdřív vytvořte náhradní klíč, nasaďte ho, pak odvolejte starý klíč v /dashboard/settings.
• Při jakémkoli podezření okamžitě odvolejte. Nový klíč stojí pár vteřin; útočník s platným klíčem umí vše, co umí váš účet.

Ochrana během živého ovládání

Živé ovládání je vázané na session lease. Robot přijímá příkazy jen tehdy, když je v přesně jedné session ACTIVE, a jen od operátora, který tuto session drží; pro všechny ostatní je robot označený jako IN_SESSION. Operátor může naráz držet nejvýš jednu session ve stavu ACTIVE nebo PAUSED, což vylučuje, aby jedna osoba nominálně ovládala dvě ramena zároveň.

Kokpit poskytuje nouzové zastavení, které rameno okamžitě zastaví, a pozastavení nebo ukončení session zastaví tok příkazů jako celek. Navíc platforma sleduje aktivitu operátora: po období bez vstupu se pošle varování o neaktivitě, a pokud operátor zůstane neaktivní, session se automaticky zastaví. Chrání to obě strany, klienta před placením za nečinný čas a robota před tím, aby zůstal s aktivní lease v nekontrolovaném stavu.

Audit trail

Každá session vede protokol událostí: start a konec, pauzy a obnovení, kontroly aktivity, varování o neaktivitě, výměny operátora, žádosti o prodloužení a chyby, každá s časovou značkou. Když se posuzuje spor, tento protokol je hlavním důkazem, což je jeden důvod navíc, proč ho platforma zapisuje automaticky, místo aby se spoléhala na něčí paměť.

Kromě session se významné akce platformy zaznamenávají do audit logu, s id jednajícího uživatele, akcí, dotčeným zdrojem a metadaty. Změny profilu, transakce relevantní pro platby a admin akce zanechávají všechny záznamy. Audit záznamy zapisuje platforma a přes žádné uživatelské rozhraní je nelze upravit.

Šifrování a ochrana dat

Veškerý provoz od platformy a k ní je při přenosu šifrovaný pomocí TLS, včetně video streamů a řídicích signálů. Na úrovni dat omezují politiky row-level security přístup k databázi podle účtu. Platební data jsou nejjasnější hranicí ze všech: karty a bankovní údaje zpracovává výhradně Stripe a serverů AY-Robots se nikdy nedotknou.

Nahlášení zranitelnosti

Pokud najdete bezpečnostní problém, nahlaste ho zodpovědně přes stránku /security nebo formulář na /contact v kategorii Bug Report. Uveďte, co jste našli, kde a jak to reprodukovat; nepřistupujte k datům jiných uživatelů nad minimum potřebné k demonstraci problému a nezveřejňujte detaily dřív, než budeme mít přiměřenou šanci to opravit. Každé hlášení si přečteme.

Časté dotazy