Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web

Guias de Segurança

Inventário de segurança — 7 verificações que quem roda vários servidores ignora

Inventário de segurança para operadores solo: incidentes vêm menos de controles ausentes do que de estado não rastreado. 7 verificações — audite o PC que guarda as chaves, escalone o 2FA, mapeie as chaves SSH e remova senhas em texto puro.

Publicado 2026-06-11 Atualizado 2026-06-11 8 min de leitura

Para operadores solo ou de pequena escala que gerenciam vários servidores, sites e domínios. Quanto mais você adiou fazer o balanço porque "funciona", mais isto se aplica. Nenhum passo de ataque aqui — só riscos que você mesmo pode listar e apagar.

"Contar e cortar" antes de "adicionar"

Estado não rastreado é, em si, um risco. Faça o balanço e você geralmente encontra:

Chave→onde?
Não está claro qual chave em qual PC abre qual servidor
2FA nebuloso
Se as contas-chave têm 2FA é nebuloso
Texto puro
Você esquece onde restam senhas em texto puro
Órfãs
Chaves sem uso e cadastros obsoletos persistem

1. Defenda o "PC com as chaves", não o "servidor"

Por mais que você fortaleça o servidor, se o PC que guarda sua chave privada SSH for comprometido, tudo se abre. Uma vez que você muda para autenticação por chave, a fronteira real da sua frota passa para "o PC que guarda a chave". Então a prioridade não é "servidor → PC", mas "PC → servidor."

PC que guarda a chave (o ponto de entrada real)
↓ uma chave abre vários servidores
Servidor A
Servidor B
Servidor C
Com autenticação por chave, o ponto de entrada não é o servidor, mas o PC que guarda a chave. Se esse PC cai, tudo que aquela chave abre cai junto (raio da explosão).

A verificação de maior valor: se .ssh fica FORA de uma pasta de sincronização em nuvem (OneDrive/Drive/Dropbox). Se uma chave privada acidentalmente fica sob sincronização, sua chave vaza no momento em que a conta da nuvem cai — mesmo sem tocar no PC. A mentalidade de menor privilégio para chaves está em chaves SSH e menor privilégio.

2. Escalone o 2FA pela "raiz de confiança"

"Adicione 2FA a tudo" nunca termina se você começar de forma vaga. Escalone pela cadeia de controle (raiz de confiança) e a prioridade se decide sozinha.

NívelAlvoPor que é prioridade máxima
Nível 0Conta de e-mailQuase todo serviço se recupera via "link de redefinição para o e-mail" — tome o e-mail e os 2FAs inferiores são contornados
Nível 1Controle de domínio (registrador/DNS/hospedagem/plataforma de código)O próprio site pode ser sequestrado ou trocado
Nível 2APIs de cobrança (pagamentos / APIs de IA / envio de e-mail)Leva a prejuízo financeiro direto

As chaves práticas: guarde os códigos de backup em papel (colocá-los na nuvem corta pela metade o sentido do 2FA) e confirme que seu e-mail de recuperação está vivo e sob seu controle. Os passos estão no guia de autenticação multifator e no checklist de base de segurança.

3. Chaves SSH não estão "gerenciadas" até você fazer a matriz

"É autenticação por chave, então é seguro" não é gerenciamento. O que você de fato precisa é uma tabela de "qual chave em qual PC abre qual servidor." Cruze o authorized_keys de cada servidor por fingerprint e o invisível aparece — chaves duplicadas (a mesma chave sob dois nomes), chaves sem uso (não usadas em lugar nenhum) e cadastros órfãos (deixados para um propósito que já não existe). O authorized_keys é fácil de adicionar e fácil de esquecer de podar. Uma matriz permite perguntar, linha por linha, "para que serve isto?"

4. Dispositivos em fim de vida: o corte de menor esforço, ponderado por esforço vs. risco

Uma chave em um dispositivo cujo SO chegou ao fim de vida (EOL) é comum. Ir grande — "rotacione toda chave e reconfigure todo servidor" — é tão pesado que você nunca faz.

1

Verifique qualquer sinal de vazamento

Sem sinal? A chave está segura agora. EOL não obriga automaticamente a rotacionar toda chave.
2

O corte de menor esforço = apague a chave do dispositivo

Não toque na configuração do servidor; remova fisicamente a chave privada no lado da entrada. Quanto mais mudanças de configuração você faz, maior o risco de abrir um novo buraco.
3

Coloque o precipício num calendário

Se existirem atualizações de segurança estendidas (ESU), inscreva-se e agende uma data para decidir migrar-ou-cortar antes do prazo (→ riscos de SO em fim de suporte).

O truque: escolha o corte que você de fato consegue terminar hoje em vez de um procedimento perfeito que você deixa por fazer.

5. Remova senhas em texto puro da nuvem

Antes do debate sobre gerenciador de senhas, há um dano real maior: uma lista de senhas em texto puro parada em um documento na nuvem. Vaze-a e é perda total instantânea.

Lista em texto puro (um documento na nuvem)

  • Uma conta caindo vaza tudo
  • Você vai colar à mão em um site falso
  • Sem detecção de vazamento, sem preenchimento automático

Armazenamento criptografado no dispositivo

  • O conteúdo é criptografado no seu dispositivo (o provedor não consegue lê-lo)
  • Não preenche automaticamente em um domínio falso = resistente a phishing
  • Após migrar, apague o texto puro de vez

"Qual gerenciador é o melhor" importa muito menos que "você removeu o texto puro da nuvem" (→ como escolher um gerenciador de senhas / guardando senhas com segurança).

6. Remedie "de forma reversível, uma de cada vez"

Quando o inventário revela problemas, você vai querer corrigir todos de uma vez. Em produção, mudar várias coisas no impulso é a jogada mais perigosa. Operações difíceis de desfazer — rotação de chaves, mudanças de configuração, deploys de produção — devem ser feitas uma de cada vez, depois de preparar um backup completo e um procedimento de restauração (ou seja, torná-las reversíveis). Não abra um novo buraco com a própria correção (→ backup e recuperação).

7. Projete o registro para não conter segredos

O registro dos seus resultados vira um mapa de ataque se vazar. Então trace a linha desde o início.

OK anotar (não catastrófico se vazar)

  • Chaves públicas, fingerprints
  • A estrutura da sua configuração, se o 2FA está ligado
  • Resultados de aprovado/reprovado

Nunca anotar (uma linha o transforma em arma)

  • Conteúdo de chave privada
  • Senhas, chaves de API
  • Códigos de redefinição reais

Fingerprints e chaves públicas só identificam "qual chave" e não podem ser abusados sozinhos. Expresse seu estado usando só informação que não é catastrófica se vazar — então o registro fica seguro na nuvem ou compartilhado com um time.

A visão deste site: inventário antes da adição

Neste site nunca guardamos segredos (chaves, senhas, detalhes de conexão) em texto puro — nem em documentos compartilhados, nem no código — separamos as chaves por propósito (um vazamento não cascateia = raio de explosão mínimo) e remediamos de forma reversível, uma de cada vez. Antes de adicionar uma ferramenta nova, primeiro transforme "estado não rastreado" em "estado listado." É pouco glamoroso, mas apaga mais risco do que qualquer outra coisa.

Leia a seguir

FAQ

QO que é um inventário de segurança?
A

Antes de 'adicionar' novos controles, você lista as chaves, contas, dispositivos e cadastros que já tem, encontra os desnecessários ou perigosos e os reduz. Para operadores solo/pequenos, incidentes vêm menos de um firewall ou WAF ausente do que de estado não rastreado — 'qual chave em qual PC abre qual servidor?', 'o 2FA está ligado ou não?' Um inventário apaga isso.

QPor onde começo?
A

A ordem é PC → servidor. Uma vez que você usa SSH por chave, a fronteira real passa do servidor para o PC que guarda a chave. Primeiro audite a saúde do PC que guarda a chave (especialmente se .ssh fica FORA de uma pasta de sincronização em nuvem), depois o 2FA e os códigos de backup da sua conta de e-mail, depois o inventário de chaves SSH.

QÉ seguro manter um registro dos resultados?
A

É, se você traçar a linha no conteúdo. Chaves públicas, fingerprints, a estrutura da sua configuração, se o 2FA está ligado e resultados de aprovado/reprovado podem ser anotados (nenhum é segredo). Mas nunca anote o conteúdo de uma chave privada, uma senha, uma chave de API ou um código de redefinição real — nem uma linha. Expresse seu estado usando só informação que não é catastrófica se vazar, e o registro nunca vira um mapa de ataque.