Há uma conversa que se repete em quase todas as diligências técnicas a que assisti nos últimos três anos. O CTO apresenta a arquitetura: um cluster de virtualização no seu centro de dados, ligado por VPN ou circuito dedicado a um ambiente de nuvem pública onde funciona a parte nova do produto, uma suíte de produtividade em SaaS e um par de aplicações verticais ligadas ao diretório corporativo. “Híbrido”, diz ele, e a palavra é pronunciada como se fosse uma decisão arquitetónica ponderada. Não é. É o resultado sedimentado de quinze anos de decisões individualmente razoáveis que nunca se sentaram para dialogar entre si.
E esse é exatamente o problema. A nuvem pública, por si só, tem um modelo de segurança imperfeito, mas coerente: identidade federada, tudo é API, tudo é auditado, tudo pode ser expresso como código. A nuvem privada tradicional tem outro modelo, também coerente à sua maneira: perímetro de rede, segmentação por VLAN, diretório on-premise, firewalls físicos, janelas de manutenção. O híbrido é onde ambos os modelos se tocam sem se integrarem, e a zona de contacto é o ponto mais vulnerável de toda a sua infraestrutura. É a costura, e é nas costuras que a roupa se rasga.
Onde se rasga: três costuras mal feitas
A identidade divide a organização em dois países
A maioria das médias empresas continua a utilizar um diretório local como fonte de dados de referência, sincronizado com o diretório na nuvem do fornecedor de soluções de produtividade. No papel, parece bom: uma identidade, dois planos. Na prática, a sincronização é unidirecional e parcial, as palavras-passe são geridas em locais diferentes, dependendo do caso, e os grupos que controlam permissões críticas na nuvem pública estão aninhados em grupos do diretório local que um administrador júnior pode modificar sem que seja emitido um alerta. O problema grave, no entanto, não são as identidades humanas: são as identidades não humanas, as credenciais que um servidor do CPD usa para comunicar com uma base de dados gerida na nuvem pública. Na maioria dos ambientes, essas credenciais são chaves estáticas guardadas em ficheiros de configuração, cuja última rotação ocorreu quando o sistema foi montado. Se esse servidor local for afetado por um ransomware, o atacante não precisa de violar a nuvem pública, já dispõe de credenciais legítimas para entrar pela porta da frente.
A rede híbrida é um perímetro que ninguém traçou
Quando configura o túnel ou o circuito dedicado entre o seu centro de dados e a nuvem pública, está a criar uma extensão de rede. Essa ligação, por predefinição, funciona com roteamento plano: qualquer tráfego na nuvem pública pode comunicar com qualquer servidor do centro de dados que esteja no intervalo de endereços anunciado, e vice-versa. Já vi ambientes em que a equipa de cloud tinha segmentado meticulosamente o seu lado — sub-redes privadas, regras de microsegmentação, controlo granular — e o lado on-prem era um terreno baldio, porque “esse tráfego é interno”. O conceito de “interno” sobrevive do mundo dos anos 90 e, num ambiente híbrido, é ativamente perigoso. A sua rede interna já não é sua, metade funciona num hipervisor que não é seu. A isto junta-se o problema do DNS dividido: quem resolve o quê, o que acontece com os nomes internos que coincidem, como se comporta a resolução quando um serviço passa do local para a nuvem. Cada um destes detalhes é uma oportunidade para que algo falhe silenciosamente até que um cliente ligue irritado.
A responsabilidade partilhada não se aplica da mesma forma a ambas as partes, e ninguém o refere
Na nuvem pública, o modelo está documentado até à exaustão. No seu centro de dados, é responsável por tudo, e a equipa de sistemas assume isso com naturalidade. O problema surge nos serviços que atravessam a fronteira. O ERP funciona no local, mas as cópias de segurança são replicadas para armazenamento de objetos na nuvem pública por uma questão de custo: quem garante que esse armazenamento tem a proteção contra apagamento e a imutabilidade ativadas? Quem testa a restauração entre sites, e não apenas o backup? Uma aplicação no local expõe uma API à Internet através de um balanceador na nuvem pública porque é mais fácil instalar o WAF lá: quem é responsável por atualizar as regras quando o OWASP Top 10 muda? A responsabilidade partilhada no ambiente híbrido não é entre si e o fornecedor, é entre a sua equipa local e a sua equipa na nuvem, e em organizações com mais de 100 funcionários essas equipas são, por vezes, compostas por duas pessoas que não estão alinhadas ou sincronizadas.
O que custa quando isso acontece
O incidente híbrido apresenta um padrão económico diferente do que ocorre exclusivamente na nuvem. Na nuvem, os danos são razoavelmente limitados: uma conta comprometida, alguns recursos, um raio de impacto mensurável. No híbrido, o ransomware que entra no local encripta o CPD e, se as credenciais da nuvem estavam nos servidores comprometidos, também destrói as cópias de segurança na nuvem pública. Pagou pela redundância e comprou correlação: ambas as cópias caem porque a cadeia de confiança era única. A isto acrescenta-se o custo regulatório: explicar à AEPD que os dados pessoais circulavam entre o seu CPD e uma região na nuvem sem uma análise de transferência documentada, ou a um auditor da ISO 27001 que os grupos do diretório local podiam ser acedidos por qualquer administrador de domínio, são conversas que se ganham ou se perdem antes mesmo de começar.
Como costurar: um guia prático que funciona
A boa notícia é que nenhum destes problemas exige reinventar a arquitetura. Exigem que o sistema híbrido seja tratado como um único sistema, em vez de como dois sistemas interligados. Quatro medidas, nesta ordem, resolvem a maior parte dos riscos num horizonte de seis a nove meses.
Unifica o plano de identidade e elimina as chaves estáticas
Defina uma única fonte de verdade — normalmente o diretório na nuvem, com o ambiente local subordinado, ou o contrário, se a sua situação assim o exigir — e federe tudo o resto através de padrões abertos (SAML, OIDC). Mas a mudança que realmente transforma a sua abordagem é eliminar as credenciais estáticas para as cargas de trabalho. Os três grandes fornecedores de nuvem oferecem federação de identidades de carga de trabalho (workload identity federation, IAM Roles Anywhere e equivalentes) que permitem que um servidor local se autentique na nuvem pública usando certificados ou tokens de curta duração, sem que exista uma chave passível de roubo no disco. É o investimento com o melhor retorno em segurança do ano: a credencial que não existe não é divulgada, não é renovada e não aparece num dump de ransomware.
Inserir uma inspeção na costura
A ligação entre o seu CPD e a sua nuvem pública não deve ser um cabo virtual transparente, deve passar por um ponto onde se inspecione, segmente e registe. Isto pode concretizar-se de várias formas, dependendo da sua realidade: um firewall de nova geração virtualizado no lado da nuvem, um serviço de firewall gerido pelo fornecedor ou — quando fizer sentido do ponto de vista operacional — um serviço gerido por um parceiro especializado que o liberte do peso de manter essa componente. A regra arquitetónica é a mesma independentemente do produto: o tráfego proveniente do CPD é tratado como tão não confiável quanto o proveniente da Internet. Zero Trust não é um slogan, é decidir que o túnel não lhe concede permissões. Aproveite o mesmo projeto para sanear o DNS: uma hierarquia de resolução clara, sem sobreposições entre zonas internas e na nuvem, com registo centralizado.
Elabore a matriz de responsabilidades antes do próximo incidente
Uma folha, um serviço por linha, colunas para “responsável pela configuração”, “responsável pela aplicação de patches”, “responsável pela monitorização”, “responsável pela resposta“. Se alguma célula ficar em branco, esse serviço é a sua primeira prioridade. Se duas células indicarem o mesmo quando não deveriam, esse é o segundo problema. Este exercício parece administrativo e é profundamente técnico: obriga alguém a decidir, com nome e apelido, quem aplica a próxima atualização ao WAF que protege a API on-prem, quem valida a imutabilidade do bucket de backup, quem verifica os alertas do diretório sincronizado num sábado à noite. Em organizações de média dimensão, onde a equipa é limitada, esta matriz é também a ferramenta que justifica a externalização de tarefas específicas — monitorização 24×7, gestão do firewall híbrido — em vez de fingir que tudo é coberto internamente.
Experimente a verdadeira recuperação
Desligue deliberadamente um serviço crítico e restaure-o a partir do backup na nuvem pública — ou a partir do ambiente local, se o principal estiver na nuvem. Meça quanto tempo demora. Verifique se as credenciais necessárias para a restauração não dependem do sistema que acabou de “perder”. A primeira vez será humilhante, e é por isso que é preciso fazê-lo antes que ocorra um incidente. Este teste, repetido trimestralmente, é o que distingue um plano de continuidade documental de um que funciona.
Fechar
A segurança híbrida não falha no centro de dados nem na nuvem pública. Falha no espaço mental onde ainda ninguém decidiu se o que tem diante de si é uma coisa ou são duas. A diferença entre as organizações que sofrem incidentes graves e as que não sofrem, na minha experiência, não é o orçamento nem as ferramentas: é que as segundas trataram o híbrido como um sistema único desde o primeiro dia, com um plano de identidade coerente, uma rede com pontos de ligação inspecionados e uma matriz de responsabilidades por escrito.
Fazer isso não é barato, mas é perfeitamente viável para uma organização de 100 a 500 funcionários que decida dar prioridade a isso. O que não é viável é o plano alternativo: ter o pior dos dois mundos, a rigidez do on-prem e a opacidade da nuvem, unidas por um túnel que ninguém vigia, e esperar que o incidente aconteça a outro.
Daniel Corbi
