Se a plataforma do seu fornecedor cair, o seu parque inteiro cai junto?
É a pergunta que todo MSP passou a fazer depois de 2021 — e a maioria dos fornecedores responde com selo de conformidade em vez de mecanismo. Esta página responde com mecanismo: o que existe no agente do GestorMSP, o que cada controle impede na prática, e o que ainda não podemos afirmar.
A resposta curta: comando privilegiado é assinado
No GestorMSP, os comandos capazes de causar dano — executar script, apagar perfil, mexer em credencial, desativar proteção, atualizar o próprio agente, reiniciar ou bloquear a máquina remotamente — exigem assinatura criptográfica Ed25519 com nonce anti-replay, validada pelo agente antes de executar.
A consequência prática: quem obtiver acesso ao canal de comunicação com os agentes, mas não à chave privada de assinatura, não consegue executar as ações do conjunto privilegiado. E o nonce impede o outro caminho clássico — capturar um comando legítimo hoje e reenviá-lo amanhã.
Comandos comuns de coleta e inventário não passam pelo gate, o que mantém a operação fluida e limita o raio de impacto ao conjunto que realmente importa.
Três cenários, e o que barra cada um
Segurança se explica melhor por aquilo que ela impede do que por lista de siglas. Estes são os três caminhos por onde um ataque a um MSP costuma passar.
O canal com os agentes é comprometido
Mesmo com acesso ao canal, um comando privilegiado sem assinatura Ed25519 válida é recusado pelo agente. Reenviar um comando legítimo capturado antes também não funciona: o nonce só vale uma vez. A verificação acontece no endpoint, não no servidor — ou seja, não depende de o servidor estar íntegro.
Uma credencial de operador vaza
O agente valida RBAC localmente e aplica a política de execução do tenant: listas de permissão e bloqueio, padrões por expressão regular, janelas de horário e fluxo de aprovação para comandos destrutivos. Um rate limiter corta rajada de comandos. A conta vazada fica limitada ao que aquele papel podia fazer, naquele horário.
O binário do agente é adulterado
O agente verifica a própria integridade com assinatura Ed25519 e hash SHA-256 embarcados no build, com comportamento fail-secure — na dúvida, não executa. Os pacotes de release são assinados. E o certificado de máquina é checado por OCSP, então um agente revogado para de ser aceito sem esperar o certificado expirar — desde que o respondedor OCSP esteja acessível.
Os controles, um a um
Tudo abaixo está implementado no agente hoje. O que ainda não está, você encontra mais adiante, na seção do que não afirmamos.
Identidade do agente
- mTLS por agente. Par de chaves RSA-2048 gerado na própria máquina, chave privada com permissão restrita ao proprietário e gravação atômica.
- Certificado X.509 de máquina, com cache e ciclo de vida gerenciados pelo agente.
- Revogação verificada por OCSP e revogação GPG para artefatos. Certificado revogado deixa de ser aceito sem esperar a expiração. A verificação é fail-open por decisão de projeto: se o respondedor OCSP estiver fora do ar, a conexão não é bloqueada — disponibilidade acima de revogação estrita.
- TLS 1.2 no mínimo, com TLS 1.3 e conjunto de cifras declarado explicitamente nos caminhos de autenticação. Validação do certificado do servidor ativa por padrão.
- Detecção de TPM 2.0 no dispositivo, exposta ao inventário.
Execução de comandos
- Assinatura Ed25519 obrigatória no conjunto privilegiado, com nonce anti-replay. Validação feita pelo agente, não pelo servidor.
- Política por tenant e por empresa: listas de permissão e bloqueio, padrões por expressão regular, janelas de horário e contexto de usuário.
- Bloqueio de comando destrutivo pendente de aprovação. O comando é negado e devolve um identificador de aprovação — o retorno automático após aprovar ainda não existe.
- Rate limiting de comandos, para conter rajada e negação de serviço a partir do canal.
- RBAC validado no próprio agente — a permissão não é conferida só do lado do servidor.
Segredos e chaves
- Cofre nativo do sistema operacional: Windows Credential Manager e Keychain no macOS, em vez de arquivo próprio. No Linux o agente usa o keyring via
secret-tooloupass— se nenhum dos dois estiver instalado no host, não há cofre nativo disponível. - AES-256-GCM para cifragem. A derivação de chave do arquivo de credenciais usa PBKDF2-SHA256; Argon2id é usado no hash de senha e na derivação de chave de token.
- Rotação automática de chaves com AES-256-GCM, backup dos conjuntos anteriores e métricas de rotação.
- Sanitização automática de log: segredo é removido antes de gravar, não depois.
Integridade e rastro
- Autoverificação do binário com Ed25519 e SHA-256 embarcados no build, com comportamento fail-secure.
- Pacotes de release assinados antes da distribuição.
- Trilha de auditoria das ações, com ator, operação e resultado.
- Postura do endpoint no inventário: status de antivírus (Defender, ESET, ThreatDown/Malwarebytes) e de criptografia de disco com BitLocker.
Controles em formato de resposta
Quando o cliente do seu cliente manda a planilha de segurança, é aqui que você encontra a resposta pronta — inclusive as linhas em que a resposta honesta é “parcial”.
| Controle | Situação | Como está implementado |
|---|---|---|
| Autenticação mútua agente–servidor | Sim | mTLS com par RSA-2048 por agente e certificado X.509 de máquina. |
| Criptografia em trânsito | Sim | TLS 1.2 no mínimo; TLS 1.3 com cifras explícitas nos caminhos de autenticação. |
| Verificação de revogação de certificado | Sim | OCSP para certificados X.509 e revogação GPG para artefatos. Fail-open quando o respondedor está offline. |
| Assinatura criptográfica de comandos privilegiados | Sim | Ed25519 com nonce anti-replay, validada no endpoint, para o conjunto privilegiado definido no agente. |
| Proteção contra reexecução (replay) | Sim | Nonce de uso único por comando privilegiado. |
| Controle de acesso baseado em papéis | Sim | RBAC granular, validado também no agente e não apenas no servidor. |
| Restrição de comandos por política | Sim | Listas de permissão e bloqueio por tenant e empresa, regex, janelas de horário. |
| Aprovação prévia para ação destrutiva | Parcial | O motor de políticas nega o comando destrutivo e devolve identificador de aprovação. Não há retomada automática da execução após aprovar. |
| Limitação de taxa de comandos | Sim | Rate limiter por comando, contra rajada e negação de serviço. |
| Armazenamento de segredos | Parcial | Cofre nativo no Windows e no macOS. No Linux exige secret-tool ou pass. Arquivo local cifrado com AES-256-GCM e derivação PBKDF2-SHA256. |
| Rotação de chaves | Sim | Automática, AES-256-GCM, com backup e métricas. |
| Integridade do agente | Sim | Autoverificação Ed25519 + SHA-256 embarcada no build, fail-secure. |
| Assinatura de pacotes distribuídos | Sim | Releases assinados antes da publicação. |
| Trilha de auditoria | Sim | Registro de ator, operação, resultado e contexto. |
| Sanitização de dados sensíveis em log | Sim | Remoção automática de segredo antes da gravação. |
| Isolamento entre clientes | Parcial | Separação lógica por tenant em toda a stack. Banco de dados dedicado por cliente não está implementado. |
| Certificação ISO 27001 | Não | Construído em alinhamento à norma; sem certificado emitido por auditor. |
| Atestado SOC 2 Tipo II | Não | Não realizado até esta data. |
| LGPD, GDPR e CCPA | Alinhado | Sanitização, trilha de auditoria e controles de acesso projetados para atender aos requisitos. Sem parecer jurídico de terceiro. |
Situação verificada no código do agente em 31/07/2026. Se o seu cliente exigir um controle que não está nesta lista, escreva para [email protected] — respondemos com o que existe, não com o que soa bem.
O que não afirmamos
Página de segurança que só tem “sim” não é página de segurança, é folheto. O que ainda não temos:
- Não somos certificados em ISO 27001 nem temos atestado SOC 2. A plataforma é construída em alinhamento a esses frameworks, e isso é diferente de ter o certificado. Quem exibe selo sem auditoria concluída cria um problema maior do que resolve.
- O isolamento entre clientes é lógico, não por banco de dados dedicado. É o modelo da maior parte do SaaS, e preferimos dizer o nível exato a usar “isolamento real” como figura de linguagem.
- Não temos teste de intrusão por terceiro publicado. Quando houver, o resumo executivo vem para esta página.
- A verificação de revogação por OCSP é fail-open. Se o respondedor estiver fora do ar, a conexão continua em vez de ser bloqueada. É uma escolha de disponibilidade, e preferimos declarar a escolha a deixar entender que a revogação é absoluta.
- O fluxo de aprovação de comando destrutivo é parcial. O comando é bloqueado e fica pendente de aprovação; o disparo automático depois que alguém aprova ainda não existe — hoje o reenvio é manual.
- No Linux, o cofre nativo depende do host. É preciso ter
secret-tooloupassinstalado. Sem um dos dois, o agente cai para o arquivo local cifrado; não há keyring nativo de fallback. - Durante o pré-lançamento não há SLA contratual. Atendimento prioritário, sim; prazo assinado, não.
O que perguntam com mais frequência
Se o GestorMSP for comprometido, um invasor consegue executar comandos no meu parque?
Comandos privilegiados exigem assinatura criptográfica Ed25519 com nonce anti-replay, validada pelo próprio agente antes da execução. Quem obtiver acesso ao canal de comunicação, mas não à chave privada de assinatura, não consegue executar script remoto, apagar perfil, mexer em credencial, desabilitar proteção, forçar atualização do agente nem disparar ações de acesso remoto como reinício ou bloqueio de tela. O nonce impede que um comando legítimo capturado antes seja reenviado depois.
Quais comandos exigem assinatura digital no GestorMSP?
A lista é curada e fica no código do agente: execução de script, remoção de perfil, operações sobre credenciais, desativação de mecanismos de segurança, atualização do próprio agente e as ações privilegiadas de acesso remoto — reinício do sistema, envio de Ctrl+Alt+Del, bloqueio de teclado e mouse e apagamento da tela. Comandos fora dessa lista não passam pelo gate de assinatura, o que limita o raio de impacto sem travar a operação do dia a dia.
Como o agente do GestorMSP se autentica no servidor?
Por mTLS. Cada agente gera o próprio par de chaves RSA de 2048 bits na instalação, com a chave privada gravada em arquivo de permissão restrita ao proprietário e escrita atômica, e recebe um certificado X.509 de máquina. A revogação é verificada por OCSP, então um certificado revogado deixa de ser aceito sem depender de expiração. A verificação é fail-open por decisão de projeto: se o respondedor OCSP estiver indisponível, a conexão não é bloqueada.
Qual versão de TLS o GestorMSP usa?
O mínimo padrão é TLS 1.2. Nos caminhos de autenticação e autorização o agente exige TLS 1.3 com conjunto de cifras declarado explicitamente. A validação de certificado do servidor está ativa por padrão em todos os caminhos de segurança.
Onde ficam guardadas as credenciais no endpoint?
No cofre nativo do sistema operacional: Windows Credential Manager e Keychain no macOS. No Linux, o agente usa o keyring através do secret-tool ou do pass — se nenhum dos dois estiver instalado no host, não há cofre nativo disponível. Quando o armazenamento é feito pelo próprio agente, a cifragem usa AES-256-GCM e a derivação de chave do arquivo de credenciais usa PBKDF2-SHA256; Argon2id é usado no hash de senha e na derivação de chave de token. As chaves têm rotação automática e os logs passam por sanitização que remove segredo antes de gravar.
O GestorMSP tem certificação ISO 27001 ou SOC 2?
Não. A plataforma é construída alinhada a esses frameworks e à LGPD, ao GDPR e à CCPA, mas não existe certificado emitido por auditor independente. Preferimos dizer isso de forma direta: quem apresenta selo de certificação sem auditoria concluída cria um problema maior do que resolve.
Os dados de cada cliente ficam isolados?
Sim, com separação lógica de dados por tenant em toda a stack, RBAC granular e mTLS validando cada agente conectado. Sendo específico sobre o nível: hoje o isolamento é lógico, não existe banco de dados dedicado por cliente. É o mesmo modelo adotado pela maior parte das plataformas SaaS.
Segurança que você consegue explicar para o seu cliente
É disso que o MSP precisa numa reunião de compliance: mecanismo, não selo. Veja a plataforma inteira funcionando com os seus próprios cenários.
Entrar no pré-lançamento →