Castelos medievais, pontes levadiças… e o fantasma dos SO “zombie”

2026-02-14 893 words 5 minutes

Contents

VPN por unidade orgânica: As pontes levadiças do costume

Há frases que soam a progresso só porque vêm embrulhadas em intenção. “Cada unidade orgânica terá a sua própria VPN.” Dito assim, parece uma cidade bem planeada: ruas limpas, portas certas, cada bairro no seu compasso. Parece autonomia, parece agilidade, parece aquela palavra mágica que aparece em todos os slides: governança.

Mas eu sou artesão. E o artesão aprende cedo uma coisa: o que conta não é o desenho. é a junta. E é sempre na junta - no detalhe, no “depois logo se afina”, no “isto é só provisório” - que a segurança começa a ranger.

Vou falar disto sem nomes e sem dedos apontados. Isto não é denúncia. É crónica. Uma dessas crónicas que cheiram a rack quente e a madrugada.

Cada unidade um castelo, cada castelo uma ponte

O plano é simples como um poema de escola:

um castelo por unidade,
uma ponte levadiça por castelo,
e um guarda a decidir quem entra.

E a teoria fica bonita: “se houver problema, fica contido”. Mas quando multiplicas castelos, multiplicas também:

portas expostas,
regras distintas,
atualizações esquecidas,
e exceções que começam como “só hoje” e acabam como “sempre”.

A cidade cresce. E com ela cresce o ruído. E no ruído, o atacante não precisa de força — precisa de paciência. Vai ao castelo com a fechadura mais antiga. Vai ao castelo onde a ponte range e ninguém lubrifica.

O problema não é ter portas. é ter portas sem mestre-de-obras

Uma VPN é uma porta. Um ponto de entrada. Um convite condicionado. Multiplicar VPNs pode parecer redundância, mas muitas vezes é só estatística.

Porque em segurança existe uma lei não escrita: quanto mais superfícies tens, mais cedo alguém tropeça numa falha.

E a falha raramente é “uma grande vulnerabilidade épica”. A falha é humana, é operacional, é repetição sem disciplina.

“Depois tratamos do controlo de acessos”

Aqui o artesão suspira, acende a luz da oficina e vê o mesmo erro em madeira e em rede:

construir primeiro, pensar depois.

Quando um sistema começa com acesso amplo e termina com “mais tarde restringimos”, ele nasce com um vício. É como levantar um muro e deixar um buraco “para facilitar durante a obra”… e nunca o fechar.

O “mais tarde” chega sempre:

com urgência,
com pressa,
com tickets a pingar,
e um “abre só esta porta, é rápido”.

E o “rápido” é o cimento mais usado na construção de dívida técnica.

MFA: o cinto de segurança não salva um carro sem travões

MFA é bom. É necessário. É uma peça certa.

Mas há quem use MFA como se fosse um amuleto: “tem MFA, logo está seguro”.

O artesão-poeta traduz assim: um cinto no banco não conserta os travões.

MFA não resolve:

permissões excessivas,
lateral movement,
segmentação fraca,
rotação inexistente de credenciais,
logs dispersos,
patching irregular.

MFA é um controlo. Não é fundação.

E então chega o fantasma: o SO zombie

Há um tipo de erro que não dá logo alarme - mas fica a roer por dentro.

É quando a porta principal (o gateway VPN) vive em:

sistema operativo descontinuado,
sem updates consistentes,
ou “mantido” com a filosofia do: “isto está estável, não mexas.”

O artesão chama-lhe madeira húmida: por fora parece firme, por dentro já está oco.

Porque o endpoint VPN é sempre apetecível:

está exposto,
autentica,
termina túneis,
encaminha tráfego,
e geralmente encosta ao que é valioso.

Se a tua porta vive num SO que já não recebe manutenção, então não tens uma ponte levadiça. Tens uma porta antiga com fechadura bonita… e dobradiças gastas.

E não, “estar atrás de firewall” não é um feitiço. Firewall ajuda. Patching defende.

O que um artesão exigiria antes de entregar a obra

Se isto é para ser grande e sério, então precisa de ritual - não de improviso.

1) Base comum (baseline) - igual para todos

SO suportado e atualizado com janela definida
hardening mínimo (serviços, SSH, ciphers)
rotação de chaves/certificados
inventário do que existe e porquê

2) Identidade central - para a chave não andar em mil bolsos

autenticação centralizada
acesso por grupos/funções
revogação automática (offboarding não pode ser “lembrar-se”)

3) Acesso mínimo necessário — a porta abre, mas não para a cidade inteira

deny by default
só redes/serviços necessários
separar gestão/admin do acesso normal

4) Observabilidade — porque sem logs, a história é sempre “ninguém sabe”

logs centralizados, retenção, integridade
alertas mínimos para padrões estranhos
capacidade de responder a “quem entrou, quando, e onde foi”

5) Anti-drift — para cada castelo não virar religião própria

templates versionados
alterações auditáveis
revisões periódicas

Três caminhos de obra limpa

Para uma organização grande, há três estradas com menos buracos:

Poucos gateways centrais + segmentação forte
Por unidade orgânica, mas com baseline + IAM + logs central obrigatórios
ZTNA / acesso por aplicação, quando o que se quer não é “rede”, é “serviço”

Remate (produtivo, porque em 2026 isto ainda acontece)

Em 2026, ainda se vê muita obra feita “a correr”: portas novas em paredes antigas, pontes levadiças montadas sem mapa e sem mestres-de-obras, e sistemas operativos “zombie” a segurar a entrada principal porque “sempre foi assim e nunca caiu”.

A boa notícia é que isto não exige magia — exige método: baseline comum, identidade central, acesso mínimo, logs centralizados e disciplina de patching. Não é glamour. É carpintaria.

E quando a carpintaria é boa, a cidade dorme melhor.