Сигурност

Автентикация

Акаунтите се управляват от Supabase Auth с имейл и парола, Google OAuth или GitHub OAuth. След вход браузърът ви пази токен на сесия (JWT), който се обновява автоматично от middleware на платформата, така че работеща сесия не изтича тихомълком по средата на работа.

API-то приема този токен на сесия в две форми: като бисквитката на сесията, която таблото и без друго изпраща, или като заглавие Authorization Bearer. Програмният достъп без вход в браузъра вместо това използва API ключове, описани по-долу. Endpoints отхвърлят заявки без валидни данни за достъп; без автентикация работят само изрично публичните маршрути, като проверката за здраве и контактната форма.

Роли и права

Всеки акаунт има точно една роля: CLIENT, OPERATOR или ADMIN. Клиентите притежават роботи и плащат за сесии, операторите управляват роботи и печелят от сесии, а администраторите ръководят платформата. Избирате между клиент и оператор по време на onboarding; ролята admin се присвоява от администратори на платформата и не може да бъде избрана сама.

Проверките на ролите се извършват от страна на сървъра при всяка заявка, не в потребителския интерфейс. Под API-то достъпът до базата данни е допълнително ограничен с политики за сигурност на ниво ред, така че дори грешка в endpoint не се превръща в свободен достъп до редовете на други акаунти.

API ключове

API ключовете дават на скриптове и сървъри достъп без вход в браузъра. Създавате и анулирате ги в /dashboard/settings; ключовете носят представка ayr_live_ и се изпращат като заглавие Authorization Bearer. Ключ действа с ролята и правата на акаунта, който го е създал, така че изтекъл ключ е точно толкова лош, колкото изтекла парола.

• Пазете ключовете от страна на сървъра. Те нямат място в клиентски JavaScript, мобилни приложения или публични хранилища.
• Използвайте по един ключ на интеграция. Когато нещо изтече, искате да анулирате един потребител на ключа, не всички.
• Ротирайте без прекъсване: първо създайте заместващия ключ, внедрете го, а после анулирайте стария ключ в /dashboard/settings.
• Анулирайте незабавно при всяко подозрение. Създаването на нов ключ отнема секунди; нападател с валиден ключ може да прави всичко, което може вашият акаунт.

Защитни механизми по време на управление на живо

Управлението на живо е обвързано с lease на сесия. Робот приема команди само докато е в точно една сесия ACTIVE, и само от оператора, който държи тази сесия; самият робот е маркиран IN_SESSION за всички останали. Оператор може да държи най-много една сесия ACTIVE или PAUSED едновременно, което изключва един човек номинално да управлява две ръце едновременно.

Кокпитът предоставя аварийно спиране, което спира ръката незабавно, а поставянето на пауза или прекратяването на сесията спира потока от команди като цяло. Освен това платформата наблюдава активността на оператора: след период без вход се изпраща предупреждение за неактивност, а ако операторът остане неактивен, сесията спира автоматично. Това защитава и двете страни, клиента от плащане за бездеен престой, а робота от престой в неконтролирано състояние с активен lease.

Одитен дневник

Всяка сесия поддържа дневник от събития: начало и край, паузи и възобновявания, проверки на активност, предупреждения за неактивност, смени на оператори, заявки за удължаване и грешки, всяко с времеви маркер. Когато спор се преглежда, този дневник от събития е основното доказателство, което е още една причина платформата да го записва автоматично, вместо да разчита на нечия памет.

Отвъд сесиите, значими действия на платформата се записват в одитен дневник с id на действащия потребител, действието, засегнатия ресурс и метаданни. Промени в профила, свързани с плащания транзакции и действия на администратори, всички оставят записи. Одитните записи се пишат от платформата и не могат да бъдат редактирани чрез какъвто и да е интерфейс, насочен към потребителите.

Криптиране и защита на данните

Целият трафик до и от платформата е криптиран при пренос с TLS, включително видео потоци и сигнали за управление. На нивото на данните политики за сигурност на ниво ред ограничават достъпа до базата данни по акаунт. Платежните данни са най-ясната граница от всички: карти и банкови данни се обработват изключително от Stripe и никога не достигат до сървъри на AY-Robots.

Съобщаване за уязвимост

Ако откриете проблем със сигурността, съобщете за него отговорно чрез страницата /security или формуляра /contact с категория Bug Report. Включете какво сте открили, къде и как да се възпроизведе; не осъществявайте достъп до данни на други потребители отвъд минимума, необходим за демонстрация на проблема, и не публикувайте подробности, преди да сме имали разумна възможност да го отстраним. Четем всяко съобщение.

Често задавани въпроси