Como mantemos os servidores da ArduMaker seguros, dia a dia

Publicado em 2026-09-12 por frfrand

La parte operativa, no la de diseño: qué se actualiza, qué se vigila, cómo se aíslan las cosas y qué pasa cuando algo se cae a las tres de la mañana.

Já contamos como a plataforma é projetada: portas fechadas por padrão, SSH com expiração, isolamento por Empresa. Isso define o que é possível.

Mas a segurança real não é definida pelo projeto, é definida pela rotina. Um servidor bem projetado e sem manutenção acaba sendo inseguro do mesmo jeito, só que mais lento.

Esta é a parte operativa.

Atualizações que não dependem de ninguém

Cada VPS tem atualizações de segurança automáticas ativadas desde o momento em que é criado.

Parece óbvio e é, estatisticamente, a medida que evita mais ataques. A enorme maioria das intrusões em servidores usa vulnerabilidades conhecidas, com patch publicado há meses. Não há nada sofisticado: há um servidor que ninguém atualizou.

Deixamos ativado por padrão justamente porque é uma tarefa que nunca é urgente. Se depender de alguém agendá-la, não é feita.

Vigilância contínua, com histórico

Há um sistema de status que revisa hosts, VPS, domínios e serviços em ciclo contínuo, e guarda 45 dias de histórico.

O histórico é a parte mais subestimada. Saber que algo está fora do ar agora é útil; poder responder "isso vem acontecendo há quanto tempo?" é o que permite encontrar a causa. Muitos problemas não são quedas: são degradações lentas que só se veem comparando com semanas anteriores.

E antes de escalar para uma pessoa, o sistema tenta reparar sozinho as falhas conhecidas. Um serviço que caiu e que se resolve reiniciando não precisa acordar ninguém às três da manhã.

Cópias em outro lugar, e verificadas

Cada VPS tem cópia completa periódica, feita a quente, armazenada em um host diferente daquele em que o VPS roda.

As duas partes importam e costumam falhar juntas:

• Um backup no mesmo disco que os dados não é um backup. Protege contra exclusão acidental e contra nada mais.
• Um backup que você não verificou pode estar corrompido e você não saberá até o pior momento. Por isso são armazenados com seu hash: é possível verificar a integridade antes de precisar dele.

E cada cópia vem com instruções de restauração. É o detalhe que separa um arquivo salvo de um plano de recuperação.

Isolamento que não depende de configurar bem

Cada VPS é uma máquina separada, e cada Empresa está separada das outras. Não há servidores compartilhados entre clientes nem permissões cruzadas que possam ficar mal configuradas.

É mais caro de operar do que um servidor compartilhado bem configurado. A diferença é que "bem configurado" precisa ser mantido todos os dias, e a separação estrutural se sustenta sozinha.

Tudo fica registrado

Cada comando executado em um VPS a partir da plataforma fica registrado com quem o lançou e quando. Cada abertura de acesso, também.

O valor não aparece em auditorias: aparece na terça-feira, quando algo parou de funcionar e a pergunta é "o que mudou aqui?". Com registro é uma consulta. Sem registro é uma reconstrução de memória entre várias pessoas.

O que isso não resolve

Vale a pena dizer isso, porque prometer mais do que se cumpre é sua própria forma de insegurança.

Nada disso protege sua aplicação de seus próprios erros. Se o seu código tem uma injeção SQL, se suas chaves estão no repositório, ou se alguém da sua equipe usa a mesma senha em todos os lugares, a plataforma não pode fazer muito.

O que podemos garantir é que a camada de baixo não seja o ponto fraco, e que os erros mais comuns de infraestrutura não dependam de alguém se lembrar.