Desde 2004: Sem compromissos

Gestão out-of-band em todas as máquinas

Cada servidor que operamos é um verdadeiro servidor enterprise com um verdadeiro controlador lights-out: iDRAC Enterprise com licença Datacenter nos Dell, iLO Advanced nos HPE, ambos comandados por Redfish, e cada chassis de blades através do seu Onboard Administrator. Não uma placa-mãe white box cuja ideia de gestão remota é um botão de energia e nenhuma consola.

Nos chassis de blades, o Onboard Administrator chega a todos os controladores do enclosure através do backplane, e é ele próprio um par redundante com failover automático.

Na prática. Quando um rack de chassis de blades precisou de licenças iLO Advanced, e de uma conta de gestão criada em cada blade, não entrámos num único blade. Fizemo-lo através do Onboard Administrator de cada chassis e o rack ficou pronto em minutos, incluindo blades instalados nessa semana que ainda não tinham credenciais próprias. É um runbook.

A rede de gestão não é a rede de produção

O controlador tem a sua própria porta física e o seu próprio cabo até ao seu próprio switching. Não particionamos uma placa de rede de produção para o controlador pedir emprestada uma fatia dela, que é o atalho habitual e a razão habitual para a gestão acabar a um erro de distância da internet. A gestão vive nos seus próprios switches, ou nas suas próprias VLAN em fabrics que não transportam mais nada, em espaço de endereçamento privado que não é encaminhado de ou para nenhuma rede de cliente e nunca é anunciado à internet.

Chamamos-lhe air gap porque é assim que se comporta. Uma máquina virtual de cliente, mesmo totalmente comprometida, a fazer scan a line rate durante uma semana, não consegue ver de todo um iLO ou um iDRAC. Não recusado, não filtrado: ausente. Os pacotes não têm para onde ir. Também se verifica no sentido inverso, e isso importa tanto quanto: nenhum tráfego de gestão viaja numa VLAN de cliente, pelo que as nossas sessões de consola, a monitorização e os backups nunca entram no domínio de broadcast de um cliente nem competem pela sua largura de banda. O isolamento é suficientemente real para nos ser inconveniente, e essa é a prova de que é real: um controlador numa VLAN de gestão não consegue chegar casualmente a um servidor web interno para descarregar uma imagem de firmware, porque nada é permitido que não tenha sido pedido e escrito. O engenheiro dá o passo extra.

Os backups viajam pelo mesmo caminho. São feitos pela rede out-of-band, nunca por um segmento de produção.

Na prática. Uma única lista de acesso de gestão canónica está vinculada em todas as plataformas que operamos, nas linhas de login dos Cisco Nexus, por instância de routing nos routers, por interface para SSH e HTTPS nas firewalls, permitindo apenas sub-redes de gestão nomeadas, com control plane policing a limitar em hardware o que sobrar.

O próprio plano de gestão

O plano de gestão é uma rede por direito próprio e construímo-lo como tal. Corre no nosso próprio backbone encriptado multi-site: Cisco DMVPN, IPsec a AES-256, BGP transportado sobre os túneis, a ligar Atenas, Amesterdão e Toronto à nossa sede corporativa no Chipre, que deliberadamente não está em nenhum dos edifícios que gere. Os hubs são redundantes, com caminhos de custo igual entre eles e por circuitos diversos, e com deteção de falhas que nota um caminho morto em bem menos de um segundo.

O pessoal chega a ele de uma única forma: através de gateways VPN e firewalls que possuímos e operamos nós próprios, em OPNsense e Cisco Firepower, e depois através de jump hosts dentro do plano, e não diretamente do portátil de um engenheiro. Níveis de confiança diferentes nunca partilham um objeto de firewall, pelo que alargar o acesso de um grupo não consegue alargar silenciosamente o de outro.

Para os planos de backup e de disaster recovery, a política é negar por defeito e os dados fluem num só sentido. A produção nunca empurra para o backup. O lado do backup puxa. Isso é imposto com regras de negação explícitas nos equipamentos de firewall, não com uma firewall de host que um host comprometido poderia editar, e os segmentos de backup não têm qualquer rota para a internet. Só a gama de gestão lhes chega. Se uma máquina de produção for completamente tomada, o atacante não ganha nenhum conhecimento da infraestrutura de backup nem nenhum caminho até ela. De onde está, ela não existe.

As alterações ao backbone são verificadas ao vivo contra o sistema em execução, uma metade de um par redundante de cada vez, e é por isso que conseguimos trabalhar no backbone a meio de um dia de trabalho.

Na prática. Movemos toda a instalação de VPN site-to-site de um cliente de um país para outro numa única sessão, antes de um prazo fixo. O hub foi clonado, transportado e levantado em paralelo com o original, para que ambos estivessem ao vivo ao mesmo tempo e houvesse sempre um sítio onde os túneis pudessem estar. Os routers das sucursais foram movidos um a um, cada um verificado em funcionamento antes de o seguinte ser tocado, cada um a fazer failover de forma limpa pelo caminho. Ninguém se deslocou a uma sucursal.

A baseline de hardening em todos os hosts

Cada máquina que construímos parte da mesma baseline, e a baseline não está em negociação. O SELinux está em enforcing, e não o desligamos para uma aplicação cooperar, escrevemos a política. Os sistemas de ficheiros são XFS.

O patching não depende de mais ninguém. Mantemos o nosso próprio mirror de pacotes no nosso próprio datacenter, com os repositórios a partir dos quais a nossa frota instala, com as assinaturas upstream intactas, acessível apenas a partir das nossas próprias gamas de endereços. Um mirror público a ter um mau dia não é um acontecimento aqui, e um servidor deliberadamente incapaz de falar com a internet continua a ser um servidor que conseguimos atualizar por completo.

Na prática. Quando foi publicada uma vulnerabilidade crítica num runtime amplamente utilizado, os pacotes corrigidos estavam em produção em todos os servidores afetados no mesmo dia, antes do fim dessa mesma noite. Não à mão e não à pressa: o rollout faz um backup, atualiza um host de cada vez, amostra sites reais nesse host para uma resposta saudável antes e depois, e para automaticamente toda a passagem se um não voltar corretamente. Rápido e cuidadoso não são opostos quando se constrói a coisa que o faz por nós.

Os logs das máquinas entram, e nada pode ficar em silêncio

As severidades sérias vão diretamente para o chat de operações onde o engenheiro de serviço já está, chegando a um humano em segundos, e sabemos que são segundos porque o cronometrámos com um alarme real. No edge, sensores dedicados leem tráfego espelhado dos border routers e vigiam continuamente padrões volumétricos e de negação de serviço.

Um dispositivo pode parecer perfeitamente saudável a partir da sua própria linha de comandos enquanto silenciosamente não envia nada para o coletor, por isso «o logging está configurado» não é prova aqui. Confirmamos que o log chega, do outro lado, no fluxo a que pertence, depois de cada alteração que o pudesse ter perturbado. Os sistemas de monitorização têm os seus próprios watchdogs em máquinas separadas, para que «aquilo que estava a vigiar deixou de vigiar» seja, por si só, um alarme. O silêncio nunca é boa notícia.

Na prática. A nossa verificação de saúde de rotina confirma também duas coisas que a maioria das verificações salta: se cada dispositivo continua realmente a enviar os seus logs, e se a sua configuração continua realmente a ser copiada em backup. Essas duas são as falhas que escondem as outras.

Análise em tempo real nas nossas próprias NVIDIA A100

A maioria dos fornecedores recolhe logs para um balde e pesquisa-o depois de algo já ter avariado. Nós pomos o fluxo a trabalhar. Regras básicas retiram primeiro o ruído conhecido, e depois tudo o que resta, de routers, switches, firewalls, arrays de storage e servidores, é analisado à medida que chega por modelos de IA a correr num conjunto de GPU NVIDIA A100 nossas, dentro do nosso próprio datacenter.

Os modelos leem transversalmente aos dispositivos, não uma linha de log de cada vez: um erro de caminho de storage, uma interface a oscilar e uma temperatura a subir no mesmo rack tornam-se uma única história em vez de três mensagens sem relação. Apanham os padrões que uma regra estática nunca apanhará, o desvio lento e a combinação invulgar que antecede uma falha, e cada alarme chega ao engenheiro já com uma segunda opinião anexada. Os dados das máquinas deixam de ser um monte de texto para fazer grep e tornam-se um aviso antecipado.

Nada disto sai da nossa rede. Os modelos, as GPU e os dados são todos nossos, e nenhuma linha de log é alguma vez enviada para um serviço de IA externo.

Um CTO que nos esteja a avaliar é bem-vindo a pedir a lista de acesso, o runbook e o encaminhamento dos alarmes. Mostramos os três.