Segurança

Autenticação

As contas são geridas pelo Supabase Auth com email e palavra-passe, Google OAuth ou GitHub OAuth. Depois do login, o seu browser guarda um token de sessão (um JWT) que é renovado automaticamente pelo middleware da plataforma, para que uma sessão em curso não expire silenciosamente a meio do trabalho.

A API aceita este token de sessão em duas formas: como o cookie de sessão que o painel envia de qualquer forma, ou como um cabeçalho Authorization Bearer. O acesso programático sem login no browser usa antes chaves de API, descritas abaixo. Os endpoints rejeitam pedidos sem credenciais válidas; só as rotas explicitamente públicas, como a verificação de saúde e o formulário de contacto, funcionam sem autenticação.

Funções e permissões

Cada conta tem exatamente uma função: CLIENT, OPERATOR ou ADMIN. Os clientes possuem robôs e pagam por sessões, os operadores controlam robôs e ganham com sessões, e os administradores gerem a plataforma. Escolhe entre cliente e operador durante o onboarding; a função de administrador é atribuída pelos administradores da plataforma e não pode ser autosselecionada.

As verificações de função acontecem do lado do servidor em cada pedido, não na interface. Abaixo da API, o acesso à base de dados está ainda mais restringido com políticas de row-level security, pelo que mesmo um erro num endpoint não se transforma em acesso livre às linhas de outras contas.

Chaves de API

As chaves de API dão acesso a scripts e servidores sem login no browser. Cria e revoga-as em /dashboard/settings; as chaves têm o prefixo ayr_live_ e são enviadas como um cabeçalho Authorization Bearer. Uma chave atua com a função e as permissões da conta que a criou, por isso uma chave exposta é exatamente tão grave como uma palavra-passe exposta.

• Mantenha as chaves do lado do servidor. Não pertencem a JavaScript do lado do cliente, aplicações móveis ou repositórios públicos.
• Use uma chave por integração. Se algo for exposto, quer revogar um único consumidor, não todos.
• Rode sem tempo de inatividade: crie primeiro a chave de substituição, implemente-a, depois revogue a chave antiga em /dashboard/settings.
• Revogue imediatamente perante qualquer suspeita. Criar uma chave nova custa segundos; um atacante com uma chave válida pode fazer tudo o que a sua conta pode.

Salvaguardas durante o controlo em tempo real

O controlo em tempo real está vinculado a uma concessão de sessão. Um robô só aceita comandos enquanto estiver em exatamente uma sessão ACTIVE, e apenas do operador que detém essa sessão; para todos os outros o robô fica marcado como IN_SESSION. Um operador pode deter, no máximo, uma sessão ACTIVE ou PAUSED de cada vez, o que exclui a possibilidade de uma pessoa controlar nominalmente dois braços em simultâneo.

O cockpit disponibiliza uma paragem de emergência que interrompe o braço de imediato, e pausar ou terminar a sessão interrompe o fluxo de comandos como um todo. Além disso, a plataforma monitoriza a atividade do operador: após um período sem entradas é enviado um aviso de inatividade, e se o operador permanecer inativo a sessão é terminada automaticamente. Isso protege ambos os lados, o cliente de pagar por tempo parado e o robô de ficar num estado descontrolado com uma concessão ativa.

Registo de auditoria

Cada sessão mantém um registo de eventos: início e fim, pausas e retomas, verificações de atividade, avisos de inatividade, mudanças de operador, pedidos de extensão e erros, cada um com data e hora. Quando uma disputa é analisada, este registo de eventos é a prova principal, mais uma razão pela qual a plataforma o escreve automaticamente, em vez de depender da memória de alguém.

Além das sessões, as ações significativas da plataforma são registadas num registo de auditoria, com o id do utilizador que agiu, a ação, o recurso afetado e metadados. Alterações de perfil, transações relevantes para pagamentos e ações administrativas deixam todas registos. Os registos de auditoria são escritos pela plataforma e não são editáveis através de qualquer interface voltada para o utilizador.

Encriptação e proteção de dados

Todo o tráfego de e para a plataforma é encriptado em trânsito com TLS, incluindo streams de vídeo e sinais de controlo. Ao nível dos dados, políticas de row-level security restringem o acesso à base de dados por conta. Os dados de pagamento são a fronteira mais clara de todas: cartões e dados bancários são tratados exclusivamente pelo Stripe e nunca tocam nos servidores da AY-Robots.

Reportar uma vulnerabilidade

Se encontrar um problema de segurança, reporte-o de forma responsável através da página /security ou do formulário em /contact na categoria Bug Report. Inclua o que encontrou, onde e como reproduzi-lo; não aceda a dados de outros utilizadores além do mínimo necessário para demonstrar o problema, e não publique detalhes antes de termos tido uma oportunidade razoável de o corrigir. Lemos todos os relatos.

Perguntas frequentes