Bezpieczeństwo

Uwierzytelnianie

Kontami zarządza Supabase Auth przy użyciu e-maila i hasła, Google OAuth albo GitHub OAuth. Po zalogowaniu Twoja przeglądarka przechowuje token sesji (JWT), który jest automatycznie odnawiany przez middleware platformy, dzięki czemu działająca sesja nie wygasa po cichu w trakcie pracy.

API akceptuje ten token sesji w dwóch formach: jako ciasteczko sesji, które panel i tak wysyła, albo jako nagłówek Authorization Bearer. Dostęp programistyczny bez logowania w przeglądarce wykorzystuje zamiast tego klucze API, opisane poniżej. Endpointy odrzucają żądania bez ważnych danych uwierzytelniających; tylko jawnie publiczne trasy, takie jak health check i formularz kontaktowy, działają bez uwierzytelnienia.

Role i uprawnienia

Każde konto ma dokładnie jedną rolę: CLIENT, OPERATOR albo ADMIN. Klienci posiadają roboty i płacą za sesje, operatorzy sterują robotami i zarabiają na sesjach, a administratorzy prowadzą platformę. Między klientem a operatorem wybierasz podczas onboardingu; rolę admina przydzielają administratorzy platformy i nie da się jej wybrać samodzielnie.

Kontrole ról odbywają się po stronie serwera przy każdym żądaniu, nie w interfejsie. Pod API dostęp do bazy danych jest dodatkowo ograniczony politykami row-level security, więc nawet błąd w endpoincie nie zamienia się w swobodny dostęp do wierszy innych kont.

Klucze API

Klucze API dają skryptom i serwerom dostęp bez logowania w przeglądarce. Tworzysz je i unieważniasz w /dashboard/settings; klucze noszą prefiks ayr_live_ i są wysyłane jako nagłówek Authorization Bearer. Klucz działa z rolą i uprawnieniami konta, które go utworzyło, więc wyciekły klucz jest dokładnie tak samo groźny jak wyciekłe hasło.

• Trzymaj klucze po stronie serwera. Nie należą do JavaScriptu po stronie klienta, aplikacji mobilnych ani publicznych repozytoriów.
• Używaj jednego klucza na integrację. Jeśli coś wycieknie, chcesz unieważnić jednego odbiorcę, nie wszystkich.
• Rotuj bez przestoju: najpierw utwórz klucz zastępczy, wdróż go, potem unieważnij stary klucz w /dashboard/settings.
• Unieważniaj natychmiast przy każdym podejrzeniu. Utworzenie nowego klucza kosztuje sekundy; atakujący z ważnym kluczem może zrobić wszystko, co może Twoje konto.

Zabezpieczenia podczas sterowania na żywo

Sterowanie na żywo jest związane z dzierżawą sesji. Robot przyjmuje polecenia tylko wtedy, gdy znajduje się w dokładnie jednej sesji ACTIVE, i tylko od operatora, który tę sesję dzierży; dla wszystkich innych robot jest oznaczony jako IN_SESSION. Operator może jednocześnie dzierżyć co najwyżej jedną sesję ACTIVE lub PAUSED, co wyklucza sytuację, w której jedna osoba nominalnie steruje dwoma ramionami naraz.

Kokpit udostępnia wyłącznik awaryjny, który natychmiast zatrzymuje ramię, a wstrzymanie lub zakończenie sesji zatrzymuje przepływ poleceń w całości. Dodatkowo platforma monitoruje aktywność operatora: po okresie braku wejścia wysyłane jest ostrzeżenie o nieaktywności, a jeśli operator pozostaje nieaktywny, sesja zatrzymuje się automatycznie. Chroni to obie strony, klienta przed płaceniem za bezczynność i robota przed pozostawaniem w niekontrolowanym stanie z aktywną dzierżawą.

Ślad audytowy

Każda sesja prowadzi log zdarzeń: początek i koniec, pauzy i wznowienia, kontrole aktywności, ostrzeżenia o nieaktywności, zmiany operatora, wnioski o przedłużenie i błędy, każde ze znacznikiem czasu. Gdy rozpatrywany jest spór, ten log zdarzeń jest głównym dowodem, co jest kolejnym powodem, dla którego platforma zapisuje go automatycznie, zamiast polegać na czyjejś pamięci.

Poza sesjami istotne działania na platformie są zapisywane w logu audytowym, z identyfikatorem działającego użytkownika, akcją, dotkniętym zasobem i metadanymi. Zmiany profilu, transakcje istotne dla płatności i działania administratorów pozostawiają wpisy. Wpisy audytowe zapisuje platforma i nie da się ich edytować przez żaden interfejs użytkownika.

Szyfrowanie i ochrona danych

Cały ruch do i z platformy jest szyfrowany w tranzycie za pomocą TLS, w tym strumienie wideo i sygnały sterujące. Na poziomie danych polityki row-level security ograniczają dostęp do bazy danych na poziomie konta. Dane płatnicze to najwyraźniejsza granica ze wszystkich: karty i dane bankowe obsługuje wyłącznie Stripe i nigdy nie trafiają na serwery AY-Robots.

Zgłaszanie luki bezpieczeństwa

Jeśli znajdziesz problem z bezpieczeństwem, zgłoś go odpowiedzialnie przez stronę /security albo formularz na /contact w kategorii Bug Report. Podaj, co znalazłeś, gdzie i jak to odtworzyć; nie sięgaj do danych innych użytkowników poza minimum potrzebnym do zademonstrowania problemu i nie publikuj szczegółów, zanim nie damy sobie rozsądnej szansy na naprawę. Czytamy każde zgłoszenie.

Najczęściej zadawane pytania