EntrarFalar com especialistas

Visão Geral de Segurança

Descrição pública e honesta dos controles de segurança da plataforma NEXEFII: autenticação, isolamento por organização, segurança de sessão, cabeçalhos e transporte.

Versão
2026.3
Última atualização
2026-07-23

Escopo

Esta visão geral cobre a aplicação NEXEFII e seus módulos operados diretamente, incluindo NEXE Store, Master Control e o assistente Smartbot, na medida em que integram a mesma plataforma.

Ela não descreve a postura de segurança de sistemas de terceiros, de integrações contratadas por clientes, nem de ambientes fora do controle direto da NEXEFII. Processadores externos, como o processador de pagamentos, são regidos por seus próprios termos e controles.

Autenticação e controle de acesso

A plataforma oferece autenticação multifator (MFA) e adota controle de acesso baseado em papéis (RBAC). Os papéis de organização disponíveis são proprietário (owner), administrador (admin), gerente (manager), membro (member) e visualizador (viewer), com permissões diferenciadas por papel.

As decisões de acesso são avaliadas de forma restritiva (fail-closed): configurações inválidas ou insuficientes resultam em negação, não em concessão silenciosa.

Isolamento entre organizações (multi-tenant)

A plataforma é multi-tenant e os dados são escopados por organização (tenant). O objetivo do desenho é que dados de uma organização não sejam acessíveis por outra.

Esse isolamento é um controle central da arquitetura, aplicado de forma consistente às operações de leitura e escrita dos módulos.

Segurança de sessão

As sessões possuem expiração por inatividade (aproximadamente 45 minutos), com aviso prévio e contagem regressiva antes do encerramento, além de um tempo de vida absoluto da sessão (aproximadamente 24 horas).

Há sincronização entre abas do navegador e a capacidade de revogar sessões do lado do servidor, permitindo encerrar o acesso de forma centralizada quando necessário.

Cookies, transporte e cabeçalhos de segurança

Os cookies de autenticação são marcados como HttpOnly e Secure. Os tokens de sessão são assinados com um único algoritmo fixo, e configurações fracas são rejeitadas de forma restritiva (fail-closed).

O tráfego é protegido em trânsito por TLS/HTTPS. A criptografia de dados em repouso não é aqui afirmada; os dados são hospedados em infraestrutura de nuvem gerenciada e os detalhes de repouso são remetidos à revisão.

O compartilhamento de origem cruzada (CORS) é restrito a uma lista de origens permitidas explícita. Cabeçalhos de resposta de segurança são aplicados.

Controles preparados, ainda não impostos

A Política de Segurança de Conteúdo (Content-Security-Policy) está atualmente em modo somente-relatório (report-only): ela monitora e reporta, mas ainda NÃO é imposta como bloqueio. Descrevemos isso de forma honesta para não sugerir uma proteção que ainda não está em vigor.

Proteções contra CSRF estão preparadas, mas ainda não são impostas de forma abrangente. Nenhum desses controles preparados deve ser lido como já ativo em modo de bloqueio.

Auditoria e verificação contínua do pipeline

Ações administrativas sensíveis são registradas em trilhas de auditoria imutáveis, apoiando rastreabilidade e responsabilização.

O pipeline de desenvolvimento inclui varredura automatizada de segredos e varredura automatizada de vulnerabilidades em dependências, como parte da higiene contínua de segurança.

Limitações e o que não afirmamos

Nenhum sistema é perfeitamente seguro. Não afirmamos ausência de incidentes, segurança absoluta, invulnerabilidade, nem qualquer nível de proteção que não possamos sustentar honestamente.

No momento, não reivindicamos nenhuma certificação de conformidade (por exemplo, SOC 2, ISO 27001, PCI DSS). Qualquer certificação futura só será mencionada quando efetivamente obtida e verificável.

Alguns detalhes de segurança não são divulgados publicamente por razões de segurança.

Divulgação responsável

Se você identificar uma possível vulnerabilidade de segurança, pedimos que a relate de forma responsável, sem exploração além do necessário para demonstrá-la, através do contato de segurança: contact@nexefii.com.

Comprometemo-nos a analisar relatos recebidos de boa-fé; o tratamento formal e os prazos são regidos pela nossa política de divulgação responsável.

Última revisão

Última revisão editorial registrada em 2026-07-11. Esta visão geral é revisada periodicamente e pode ser atualizada à medida que os controles evoluem.

Postura de acesso de suporte

A NEXEFII não mantém acesso permanente ou contínuo ao ambiente de nenhum cliente. Não há login com credenciais compartilhadas do cliente e nenhum operador utiliza a senha do cliente. Quando o suporte remoto é necessário, o acesso ocorre somente mediante autorização explícita do cliente.

O acesso de suporte é projetado para ser nominativo (vinculado a um usuário de suporte identificado), temporário (com prazo de expiração), escopado ao tenant do cliente, de privilégio mínimo, somente leitura por padrão (com escrita apenas quando necessário e autorizado), protegido por MFA, vinculado a uma justificativa ou chamado, revogável pelo cliente e registrado em trilha de auditoria (início, fim e ações relevantes).

Um mecanismo de provisionamento just-in-time (JIT), com elevação temporária limitada por tempo, é descrito apenas como melhoria futura e ainda NÃO está implementado. Até lá, o acesso segue o procedimento nominativo e transitório conduzido pelo próprio cliente. Dúvidas sobre a postura de acesso de suporte podem ser encaminhadas para contact@nexefii.com.