Operar um fabric de rede desenhado para latência de microssegundos em um ambiente de nuvem pública é um desafio que vai muito além da simples conectividade. Enquanto o RDMA (Remote Direct Memory Access) desbloqueia o desempenho necessário para cargas de trabalho de IA e computação de alta performance (HPC), ele também introduz riscos quando exposto a usuários com acesso root em instâncias bare metal. Ao integrar InfiniBand aos OCI SuperClusters, a Oracle não tratou a segurança como um overlay, mas como um requisito de design fundamental.
Oci GPU Clusters: a arquitetura das três redes
Para entender o modelo de segurança, é preciso segmentar a rede de um SuperCluster:
- Front-end (service) network: Acesso a storage, serviços OCI e tráfego externo.
- Back-end (cluster) network: O interconnect de alta performance otimizado para RDMA.
- Accelerator interconnect: Focado em latência ultra-baixa entre GPUs (NVLink, etc).
O foco aqui é a rede de back-end. Diferente do RoCE (RDMA over Converged Ethernet), que aproveita a maturidade do ecossistema Ethernet, o InfiniBand foi concebido para ambientes de confiança mútua. Em uma nuvem pública, onde o inquilino possui root no host, assumir essa premissa é um erro comercial e técnico. A necessidade de isolar o tráfego em um ambiente onde o controlador de rede (o Subnet Manager ou SM) vive dentro do próprio fabric exigiu inovações em controle de acesso e topologia.
Isolamento via Particionamento
No InfiniBand, o isolamento é feito via partitions. Cada pacote trafegado contém um Partition Key (PKey) de 16 bits. O OCI aplica uma camada dupla de proteção aqui: o firmware no HCA (Host Channel Adapter) e os switches de rede. O switch atua como um 'porteiro', descartando qualquer pacote que não corresponda ao PKey autorizado para aquela porta específica, reportando tentativas de violação através de traps para o SM.
Mitigando o Spoofing de GUIDs
Um dos pontos críticos discutidos pelo time de engenharia da OCI é a vulnerabilidade de GUIDs (Global Unique Identifiers). Ao contrário de endereços MAC, GUIDs são fundamentais na identificação de participantes no fabric. Como o usuário tem acesso root, ele poderia tentar fazer spoofing de um GUID. A OCI resolve isso através de um static topology specification (topospec). A rede é pré-mapeada via inventário detalhado; se o par GUID/Porta detectado pelo SM não coincidir exatamente com o gravado durante a integração do rack em fábrica, o link é desabilitado preventivamente.
Hardening do plano de controle
O plano de controle do InfiniBand (SM) é um alvo tentador. Para protegê-lo, a OCI utiliza chaves MAD (Management Datagram) únicas por dispositivo, com rotação diária. Além disso, a implementação do SMP firewall impede que o kernel do host do cliente envie pacotes de configuração para o SM. Uma vez que o host é provisionado, essa proteção é selada via chave privada, impossibilitando qualquer tentativa de manipulação por parte do inquilino.
Conclusão: a lição para o ecossistema
O caso dos OCI SuperClusters demonstra que, para empresas brasileiras que buscam escalar em alta performance, o foco deve ser a automação da segurança. Não basta importar soluções on-premise; é preciso reconstruir as políticas sob a ótica de um modelo de ameaça adversarial, garantindo que a infraestrutura de rede seja auditável, programável e, acima de tudo, mecanicamente isolada em cada nível de firmware e hardware.
Artigo originalmente publicado por Dr. Nikhil Shetty em cloud-infrastructure.
