MFA e hash de senhas
TOTP com apps autenticadoras e códigos de recuperação. Senhas com Argon2id; contas antigas migradas no primeiro login. Política de MFA configurável como obrigatória por tenant.
Segurança da plataforma
O Lunixar foi construído para que o acesso seja verificado, o isolamento entre tenants seja total e a execução remota tenha controles explícitos. MFA, Argon2id, política de conteúdo, níveis de confiança e auditoria completa — sem exceções nas camadas críticas.
Aplica-se a backend, WebSocket, agente e viewer. Sem exceções para isolamento de tenant ou RBAC.
Modelo de 3 camadas
Controles implementados
Cada controle nesta lista foi verificado no código. Sem itens de roadmap ou funcionalidades prometidas.
TOTP com apps autenticadoras e códigos de recuperação. Senhas com Argon2id; contas antigas migradas no primeiro login. Política de MFA configurável como obrigatória por tenant.
Isolamento completo em backend, WebSocket, agente e viewer. RBAC em cada endpoint — sem acesso cruzado possível.
Tenants sem confiança verificada não podem combinar download e execução. Confiança estendida com TTL de 30 dias. Regras de destinos bloqueados aplicam no cadastro e terminal.
Reforços transversais
Proteção contra força bruta com Redis, detecção de reutilização de refresh tokens e MFA step-up. CSRF double-submit, security headers e sessões revogáveis.
Binários ofuscados sem .pdb, atualizações com SHA-256 e allowlist de URL. Tokens de enroll com expiração e limite de usos; instaladores de agente não podem ser renomeados pela plataforma.
Execuções bloqueadas ficam em script_logs com o motivo exato. Mudanças de confiança têm timestamp, usuário e motivo.
Modelo de segurança em 3 camadas
As três camadas de segurança aplicam em ordem. Sem identidade verificada não há acesso; sem acesso com permissão não há operação; sem confiança verificada não há execução remota sensível.
1
Login protegido com Argon2id, proteção contra força bruta com Redis e TOTP MFA configurável como obrigatório por tenant. Ações sensíveis exigem MFA step-up recente mesmo com sessão ativa.
2
O RBAC verifica permissões em cada camada. O isolamento de tenant impede qualquer acesso cruzado entre contas. Toda requisição ao backend, WebSocket e viewer passa por validação de tenant e papel.
3
A política de conteúdo bloqueia combinações de download e execução para tenants não verificados. As regras de destinos bloqueados aplicam em terminal, scripts, agendamentos e cadastro de contas. Tudo bloqueado vai para o log de auditoria.
Perguntas frequentes
TOTP com apps autenticadoras como Google Authenticator, Authy ou qualquer app compatível. Ao ativar o MFA, códigos de recuperação de uso único são gerados. Os tenants podem configurar o MFA como obrigatório para todos os seus usuários.
O isolamento de tenant está implementado em todas as camadas: backend, WebSocket, agente e viewer. Cada requisição valida o tenant do usuário antes de acessar qualquer dado. Não há caminhos de acesso cruzado — nem por configuração incorreta.
Para tenants sem confiança verificada, o script é bloqueado antes de chegar ao agente. É salvo com IsMalicious=true na plataforma e a execução fica registrada em script_logs com WasBlockedBySecurityPolicy e o motivo exato.
Sim. A plataforma exibe as sessões ativas nas configurações de conta. Você pode ver cada sessão ativa e revogá-la individualmente sem precisar mudar a senha.
Prevenção de abuso RMM
A página de segurança explica o modelo da plataforma; a página de prevenção de abuso foca em política de execução remota, instaladores sem renomeação, restrição de tenant, auditoría e reporte.