Projete a Proteção DDoS para o Oracle Cloud Infrastructure
Embora existam muitas opções de design das quais selecionar, os fatores comuns para a maioria dos projetos são:
- Alinhados aos padrões de segurança de negócios
- Seguro de ponta a ponta
- Siga um modelo de defesa em profundidade
- Fácil de gerenciar
- Escalável
O principal objetivo do serviço de proteção OCI DDoS é fornecer uma solução segura e escalável que atenda aos requisitos DDoS de uma organização, ao mesmo tempo em que dá suporte a várias camadas de ambiente, incluindo produção, preparação, desenvolvimento, garantia de qualidade e recuperação de desastres. Os serviços de proteção OCI DDoS também ajudam uma empresa a manter uma arquitetura altamente disponível e escalável com um modelo de segurança de defesa profunda, aproveitando componentes nativos da nuvem da OCI, como Firewalls de Aplicativos Web (WAF), Balanceadores de Carga de Rede (NLB), Balanceadores de Carga Flexíveis (FLB), Firewalls de Última Geração de terceiros (NGFWs) com certificados DDoS ativados e TLS/SSL, juntamente com os benefícios e considerações associados para cada design.
Avalie e Escolha uma Opção de Design de Arquitetura para Prevenção DDoS no OCI
Há várias opções de design de arquitetura que você pode escolher, dependendo de como deseja que sua prevenção DDoS seja dimensionada.
Opção de Design 1: Firewalls de Aplicativo Web e Balanceador de Carga de Rede Único
Neste design, os certificados TLS são usados no WAF, NGFW, os FLBs privados e os servidores de back-end para fluxos HTTP/S. O fluxo HTTP/S sempre entrará da borda OCI WAF e funcionará gradualmente em um NLB, seguido por NGFWs e, finalmente, pelo FLB privado. Essa abordagem requer várias políticas de WAF para cada camada de ambiente (por exemplo, produção, QA e DR) e encaminhamento de tráfego HTTP/S para um único NLB, um único FLB e seus conjuntos de back-end correspondentes.
Observação:
Para todos os fluxos não HTTP/S, o fluxo sempre entrará por meio do NLB, ignorando o OCI WAF, pelas NGFWs e, finalmente, pelo NLB privado. Isso permite implementar o firewall DDoS em um nível baseado em zona ou em um nível global para focar em ataques nas camadas 3 e 4.O diagrama a seguir mostra essa arquitetura.
rede única-lb-ngfw-architecture.zip
À medida que o tráfego entra pela borda do OCI, as políticas de borda do OCI WAF executam o encerramento de TLS/SSL. O pacote é decriptografado para que possa ser inspecionado em busca de payloads maliciosos na camada 7 do WAF antes de enviar o tráfego para a origem em uma porta específica. Por padrão, esse é o 443/TCP, que pode ser configurado para encaminhar em portas específicas.
A origem do OCI WAF é configurada para encaminhar tráfego para um único NLB, que então encaminha o tráfego para instâncias de computação NGFW de terceiros para uma determinada porta TCP. Por exemplo, no diagrama acima, os fluxos de tráfego verde e azul da borda OCI WAF são enviados para a origem (o endereço IP do listener NLB) em portas específicas, 4443/TCP e 4444/TCP, respectivamente. Por sua vez, o NLB é configurado para encaminhar o tráfego para os conjuntos de backend (as NGFWs) nas mesmas portas TCP.
O NLB opera nas camadas 3 e 4 e é colocado em uma sub-rede pública. O NLB normalmente será configurado para preservar o endereço IP de origem do cliente. O tráfego que entra no OCI WAF será submetido a proxy, usando CIDRs documentados do OCI WAF dedicados ao serviço OCI WAF. Como o tráfego está vinculado a uma lista de CIDRs documentados do OCI WAF, podemos adicionar uma camada de segurança adicional utilizando listas de segurança e/ou NSGs para limitar a conectividade a uma lista de CIDRs válidos e confiáveis do OCI WAF. Isso também implica nos logs de fluxo da sub-rede NLB e os logs de tráfego NGFW de terceiros só verão os endereços IP dos intervalos CIDR do OCI WAF como o IP de origem.
Como esse design aproveita firewalls ativos/ativos usando um NLB, o firewall de terceiros deve executar a NAT de origem antes de encaminhar o tráfego ao FLB privado para manter um caminho simétrico para o tráfego de retorno. A NGFW também terá de realizar o destino-NAT, uma vez que o destino é um FLB privado.
Partindo do pressuposto de que o NGFW suporta decriptografia e inspeção, podemos decriptografar o tráfego para executar IDS/IPS em payloads não criptografados no NGFW, antes de encaminhar o tráfego para um determinado FLB.
Considerando os requisitos fornecidos e a opção de design descrita acima, podemos concluir as seguintes melhores práticas para essa implantação:
- Políticas de WAF separadas para cada camada de ambiente (produção, desenvolvimento e QA).
- Use um único balanceador de carga de rede (NLB).
- Reutilize os mesmos NGFWs de backend para várias camadas de ambiente.
- Projete uma arquitetura de defesa em profundidade.
- Proteja o ambiente de ponta a ponta.
- Mitigue e controle ataques locais que chegam ao Oracle Cloud.
- Obtenha proteção da camada 3 e da camada 4 DDoS com controle organizacional.
- Configure DDoS na camada de firewall com controle do usuário para complementar as ofertas da Oracle.
Opção de Design 2: Firewalls de Aplicativo Web e Vários Balanceadores de Carga de Rede
Nesse design, a tecnologia, os componentes e o fluxo de dados permanecem os mesmos do nosso design anterior. Depois que o tráfego entra pela borda do OCI, ele é processado e inspecionado pelas políticas de borda do OCI WAF para qualquer payloads mal-intencionados da camada 7 do WAF antes de ser enviado para o NLB, NGFW e, por fim, um ALB privado. Da mesma forma, todos os fluxos não HTTP/S sempre entrarão por meio do NLB, ignorando o OCI WAF e as NGFWs e, finalmente, o NLB privado. Isso permite implementar o firewall DDoS em um nível baseado em zona ou em um nível global para focar em ataques nas camadas 3 e 4.
A principal diferença no design da Opção 2 é aproveitar vários NLBs em uma base por camada de ambiente (produção, desenvolvimento e QA) para segregar o tráfego do ambiente. Na Opção 2, cada NLB usa um endereço IP secundário exclusivo na NGFW como o backend definido para encaminhar o tráfego. O tráfego acaba percorrendo o FLB designado para o aplicativo ou serviço fornecido. Este design também introduz a capacidade de escalar além da limitação de 50 listeners usando um único NLB. Esse design também permitirá a reutilização de portas de listener NLB para padronizar os fluxos de tráfego para cada camada de ambiente (produção, desenvolvimento e QA).
O diagrama a seguir mostra essa arquitetura.
