O que fazemos · Operações: O hardening baseline em cada host
Cada máquina que construímos parte da mesma base de segurança, e a base não está em negociação. SELinux enforcing, uma firewall de host mais um par de firewalls de perímetro, política de rede e de país no edge, só chaves SSH, sem swap em máquinas virtuais. É o que faz de «seguro» uma propriedade da plataforma e não uma promessa num contrato.
O que é
- h2: O que é
Um conjunto fixo de controlos aplicado a cada host Linux e a cada serviço público que operamos, desde o momento em que a máquina é instalada. Está embutido nos nossos templates de instalação, para que um servidor novo esteja reforçado antes de alguém lhe fazer login, e é verificado de fora depois de cada alteração em vez de ser dado por garantido de dentro.
Como o construímos
- h2: Como o construímos
SELinux enforcing, sempre. Quando uma aplicação e a política discordam, escrevemos ou corrigimos a política. Não desligamos a proteção e não a tapamos com uma regra gerada automaticamente que enfraquece em silêncio todo o host. Quando alteramos o modo de enforcement numa máquina remota, arma-se primeiro uma rede de segurança temporizada, para que um erro nunca nos possa trancar fora da máquina.
Duas firewalls, não uma. Cada serviço público está atrás de um par de firewalls de alta disponibilidade no perímetro, construído em Cisco Firepower ou OPNsense, além da firewall de host. As alterações de perímetro passam apenas pela API da firewall, primeiro no nó standby, e os dois nós são verificados como idênticos a seguir.
Política de rede e de país no edge. Os serviços públicos têm uma lista de bloqueio de países mantida e uma lista de bloqueio de redes conhecidas por abuso. As plataformas privadas recebem o contrário: uma allowlist, em que só países ou redes nomeados conseguem sequer ligar-se. Depois de cada alteração, a política é testada a partir de vários países para provar que faz o que diz.
Acesso administrativo numa rede separada. Os administradores chegam a um host através dos nossos próprios gateways VPN e jump hosts, numa rede de gestão que o tráfego dos clientes não consegue ver.
Sem swap em máquinas virtuais. O disco de uma máquina virtual vive num array enterprise all-flash. O swap gastaria a resistência desse array como memória de transbordo e transformaria uma falta de memória num servidor lento e imprevisível. Uma máquina que precisa de mais memória recebe mais memória, e a aplicação é afinada para caber nela.
O filesystem certo e as afinações certas. XFS em todo o lado, e afinações de storage ajustadas aos discos reais por trás do controlador, para que o storage de estado sólido seja tratado como storage de estado sólido.
Patching a partir do nosso próprio mirror. O nosso mirror de pacotes vive dentro do nosso próprio datacenter, com as assinaturas upstream intactas, acessível só a partir das nossas próprias gamas de endereços. Um servidor deliberadamente incapaz de chegar à internet continua a ser um servidor que conseguimos corrigir por completo.
Stateless onde não é preciso estado. Os serviços UDP que não precisam de connection tracking, como o DNS, passam de forma stateless na firewall, e o processamento de pacotes é distribuído pelos núcleos do processador com o control plane mantido à parte, para que a firewall se mantenha rápida sob carga.
Do que o protege
-
h2: Do que o protege
-
Um comprometimento de uma aplicação que se torna um comprometimento de todo o servidor.
- Um serviço exposto ao mundo inteiro quando só precisava de responder a um país.
- Uma falta de memória que se transforma num problema de storage.
- Patching refém de um mirror externo.
Na prática
- h2: Na prática
Política de país, provada de fora. Quando apertámos as listas de bloqueio de países nos nossos pares de firewalls públicos, a alteração foi primeiro para o nó standby, os dois nós foram verificados como idênticos, e o resultado foi testado a partir de vários países antes de se dar por terminado.
Um sistema de testes que responde a um único país. Um cliente precisava de um sistema de staging acessível apenas a partir do seu próprio país. O conjunto de regras foi construído por cliente, com bloqueios explícitos a tudo o resto, posicionado deliberadamente em relação às regras gerais de ameaças, e provado de dentro e de fora desse país.
Porquê a EuroVPS
-
h2: Porquê a EuroVPS
-
O SELinux fica enforcing. Corrigimos a política, não desativamos a proteção.
- Uma firewall de host e um par de perímetro de alta disponibilidade em cada serviço público.
- Política de país e de rede testada de fora depois de cada alteração.
- Sem swap nas VM: os problemas de memória resolvem-se com memória.
- O nosso próprio mirror de pacotes, para que o patching nunca espere por mais ninguém.
Perguntas frequentes
- h2: Perguntas frequentes
- O fabricante da minha aplicação diz para desativar o SELinux. Fazem-no? Não. Escrevemos a política de que a sua aplicação precisa. Pela nossa experiência, é quase sempre uma alteração pequena e precisa.
- Conseguem restringir o meu serviço a certos países? Sim. Allowlist ou lista de bloqueio, no perímetro, testada de fora depois de aplicada.
- Porque é que não há swap na minha VM? Porque o swap em flash enterprise partilhado torna um servidor lento e imprevisível em vez de resolver o problema real. Se a sua carga de trabalho precisa de mais memória, dimensionamos a máquina para isso ou ajudamos a afinar a aplicação.
- Posso ter logins por palavra-passe para a minha equipa? O acesso administrativo é por chaves. Ajudamos a configurar chaves para todos os que precisam de acesso.
- closing line: Se quer uma plataforma reforçada por defeito, não a pedido, Fale com um engenheiro.
O seu próximo parceiro de infraestrutura
Vamos analisar a sua infraestrutura.
Diga-nos o que executa hoje e o que precisa de melhorar. Um engenheiro vai analisar o seu pedido e ajudar a planear o passo seguinte.
+357 222 32280
Comecemos pela sua infraestrutura.
Um pouco de contexto ajuda-nos a começar a conversa certa.