Безпека

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

Акаунтами керує Supabase Auth за допомогою email і пароля, Google OAuth чи GitHub OAuth. Після входу ваш браузер зберігає токен сесії (JWT), який автоматично оновлюється проміжним шаром платформи, тож робоча сесія не спливає мовчки посеред роботи.

API приймає цей токен сесії у двох формах: як cookie сесії, який дашборд надсилає в будь-якому разі, або як заголовок Authorization Bearer. Програмний доступ без входу через браузер використовує натомість API-ключі, описані нижче. Ендпоінти відхиляють запити без дійсних облікових даних; без автентифікації працюють лише явно публічні маршрути, такі як перевірка здоров'я і контактна форма.

Ролі і дозволи

У кожного акаунта рівно одна роль: CLIENT, OPERATOR чи ADMIN. Клієнти володіють роботами і платять за сесії, оператори керують роботами і заробляють на сесіях, а адміністратори керують платформою. Між клієнтом і оператором ви обираєте під час онбордингу; роль адміністратора призначається адміністраторами платформи і не може бути обрана самостійно.

Перевірки ролей відбуваються на боці сервера під час кожного запиту, а не в інтерфейсі. Під API доступ до бази даних додатково обмежений політиками row-level security, тож навіть баг в ендпоінті не перетворюється на вільний доступ до рядків чужих акаунтів.

API-ключі

API-ключі дають скриптам і серверам доступ без входу через браузер. Ви створюєте і відкликаєте їх у /dashboard/settings; ключі мають префікс ayr_live_ і надсилаються як заголовок Authorization Bearer. Ключ діє з роллю і правами акаунта, який його створив, тож витік ключа настільки ж небезпечний, як витік пароля.

• Тримайте ключі на боці сервера. Їм не місце в клієнтському JavaScript, мобільних застосунках чи публічних репозиторіях.
• Використовуйте один ключ на інтеграцію. Коли щось витікає, ви хочете відкликати одного споживача, а не всіх одразу.
• Ротуйте без простою: спершу створіть ключ на заміну, розгорніть його, потім відкличте старий ключ у /dashboard/settings.
• Відкликайте негайно за будь-якої підозри. Створення нового ключа займає секунди; зловмисник із дійсним ключем може зробити все, що може ваш акаунт.

Захист під час живого керування

Живе керування прив'язане до оренди сесії. Робот приймає команди лише поки перебуває рівно в одній сесії ACTIVE, і лише від оператора, який тримає цю сесію; для всіх інших сам робот позначений як IN_SESSION. Оператор може тримати не більше однієї сесії ACTIVE чи PAUSED одночасно, що виключає номінальне керування двома руками однією людиною одночасно.

Кокпіт надає аварійну зупинку, яка негайно зупиняє руку, а пауза чи завершення сесії зупиняють потік команд цілком. Крім того, платформа стежить за активністю оператора: після періоду відсутності введення надсилається попередження про неактивність, а якщо оператор залишається неактивним, сесія зупиняється автоматично. Це захищає обидві сторони: клієнта від оплати за простій і робота від перебування в неконтрольованому стані під живою орендою.

Журнал аудиту

Кожна сесія веде журнал подій: початок і кінець, паузи і відновлення, перевірки активності, попередження про неактивність, зміни операторів, запити на продовження і помилки, кожна з часовою міткою. Коли спір розглядається, цей журнал подій слугує основним доказом, що ще одна причина, чому платформа записує його автоматично, а не покладається на чиюсь пам'ять.

Крім сесій, значущі дії на платформі записуються в журнал аудиту з id діючого користувача, дією, зачепленим ресурсом і метаданими. Зміни профілю, транзакції, значущі для платежів, і дії адміністраторів, усі залишають записи. Записи аудиту пише платформа, і їх не можна редагувати через жоден користувацький інтерфейс.

Шифрування і захист даних

Увесь трафік до платформи і від неї шифрується під час передавання за допомогою TLS, зокрема відеопотоки і керуючі сигнали. На рівні даних політики row-level security обмежують доступ до бази даних за акаунтом. Платіжні дані утворюють найчіткішу межу з усіх: картки і банківські реквізити обробляє виключно Stripe, вони ніколи не потрапляють на сервери AY-Robots.

Повідомити про вразливість

Якщо ви виявили проблему безпеки, повідомте про неї відповідально через сторінку /security чи форму /contact, використовуючи категорію Bug Report. Вкажіть, що ви виявили, де і як це відтворити; не звертайтеся до даних інших користувачів понад мінімум, потрібний для демонстрації проблеми, і не публікуйте деталі, поки в нас не було розумної можливості це виправити. Ми читаємо кожне повідомлення.

Часті запитання