Autenticação e controle de acesso

Porque o login costuma estar certo e o problema aparece depois dele. Nos testes que fazemos, a falha mais frequente é uma rota que recebe o identificador da empresa como parâmetro e confia nele, em vez de usar a empresa do usuário autenticado. Controle de acesso quebrado é a primeira categoria do OWASP Top 10:2025.

O RBAC define na aplicação o que cada papel pode fazer: quem aprova, quem exclui, quem só consulta. O RLS age no banco de dados e define quais linhas cada usuário ou empresa consegue ler e alterar. Em sistemas multi-tenant, os dois se completam: se uma rota da aplicação errar o filtro, o banco ainda assim bloqueia o dado de outro cliente.

Sozinho, não. No PostgreSQL, superusuários, papéis com o atributo BYPASSRLS e, em regra, o dono da tabela ignoram as políticas por linha. Uma aplicação que se conecta com um desses usuários passa por cima de todo o RLS. Por isso revisamos com qual papel cada parte do sistema acessa o banco e testamos as políticas com usuários reais de empresas diferentes.

Depende de como é implantado. É comum exigir MFA só para perfis administrativos e oferecer como opção para os demais, lembrar o dispositivo por um período e usar passkey, que é mais rápida que digitar um código. Códigos de recuperação e um processo claro para troca de celular evitam boa parte dos chamados de suporte.

Serve, mas é a opção mais fraca. As diretrizes de autenticação do NIST (SP 800-63B, revisão 4, de 2025) classificam o SMS como autenticador restrito, por riscos como a clonagem de chip, e pedem avaliação de risco antes de adotá-lo. Aplicativo autenticador ou passkey são alternativas melhores, e a passkey também resiste a páginas falsas de login.

A recomendação atual vai no sentido oposto. O NIST SP 800-63B proíbe exigir troca periódica e regras de composição, como misturar maiúsculas, números e símbolos, e manda forçar a troca só quando houver indício de comprometimento. Em compensação, pede senha de pelo menos 15 caracteres quando ela é o único fator (8 quando há MFA) e comparação com listas de senhas vazadas ou muito comuns.

Na maioria dos casos, sim. Provedores que seguem OpenID Connect ou SAML, como Microsoft Entra ID e Google Workspace, podem ser integrados sem trocar o login atual dos usuários. A revisão confere os pontos onde essas integrações costumam falhar: validação do parâmetro state, lista de endereços de retorno e verificação da assinatura do token.

A migração pode ser gradual. É possível manter a senha atual válida enquanto o usuário cadastra o segundo fator no próximo acesso, ou liberar o SSO primeiro para uma empresa piloto. Mudanças de permissão entram com testes automatizados por papel, para que ninguém perca um acesso de que precisa nem ganhe um que não deveria ter.