Documentação do Oracle Cloud Infrastructure

Regras de Segurança

O serviço Networking oferece duas funcionalidades de firewall virtual que usam regras de segurança para controlar o tráfego no nível do pacote. As duas funcionalidades são:

  • Listas de segurança: a funcionalidade de firewall virtual original do serviço Networking.
  • Grupos de segurança de rede (NSGs): uma funcionalidade subsequente projetada para componentes de aplicativo que têm diferentes posturas de segurança. Os NSGs são suportados somente para serviços específicos.

Essas duas funcionalidades oferecem diferentes maneiras de aplicar regras de segurança a um conjunto de placas de interface de rede virtual (VNICs) na VCN (virtual cloud network).

Este tópico resume as diferenças básicas entre as duas funcionalidades. Ele também explica conceitos importantes de regras de segurança que você precisa entender. A forma como você cria, gerencia e aplica regras de segurança varia entre listas de segurança e grupos de segurança de rede. Para obter detalhes de implementação, consulte estes tópicos relacionados:

Comparação entre Listas de Segurança e Grupos de Segurança de Rede

As listas de segurança permitem definir um conjunto de regras de segurança que se aplicam a todas as VNICs em uma sub-rede inteira. Para usar determinada lista de segurança com uma sub-rede específica, você associa a lista de segurança à sub-rede durante a criação da sub-rede ou posteriormente. Uma sub-rede pode ser associada com um máximo de cinco listas de segurança. As VNICs criadas nessa sub-rede estão sujeitas às listas de segurança associadas à sub-rede.

Os Grupos de segurança de rede (NSGs) permitem definir um conjunto de regras de segurança que se aplicam a um grupo de VNICs da sua escolha (ou aos recursos pais de VNICs, como balanceadores de carga ou sistemas de banco de dados). Por exemplo: as VNICs pertencentes a um conjunto de instâncias do Compute que têm a mesma postura de segurança. Para usar um NSG específico, adicione as VNICs de interesse ao grupo. As VNICs adicionadas a esse grupo estão sujeitas às regras de segurança desse grupo. Uma VNIC pode ser adicionada a um máximo de cinco NSGs.

O diagrama a seguir ilustra o conceito.

Comparação entre um grupo de segurança de rede e uma lista de segurança.

A Oracle recomenda o uso de NSGs em vez de listas de segurança porque os NSGs permitem que você separe a arquitetura de sub-rede da VCN dos seus requisitos de segurança de aplicativo.

Entretanto, você pode usar listas de segurança e NSGs juntos, se quiser. Para obter mais informações, consulte Se Você Usar Listas de Segurança e Grupos de Segurança de Rede.

Sobre VNICs e Recursos Pais

Uma VNIC é um componente do serviço Networking que permite que um recurso de rede, como uma instância do Compute, se conecte com uma rede virtual na nuvem (VCN). A VNIC determina como a instância se conecta com pontos finais dentro e fora da VCN. Cada VNIC reside em uma sub-rede contida em uma VCN.

Quando você cria uma instância do serviço Compute, uma VNIC é criada automaticamente para a instância na sub-rede da instância. A instância é considerada o recurso pai da VNIC. Você pode adicionar VNICs adicionais (secundárias) a uma instância do serviço Compute. Por esse motivo, as VNICs de uma instância são exibidas proeminentemente como parte dos recursos relacionados de uma instância do serviço Compute na Console.

Você pode criar outros tipos de recursos pais que também resultam na criação automaticamente de uma VNIC. Por exemplo: quando você cria um balanceador de carga, o serviço Load Balancing cria automaticamente VNICs para tráfego de balanceamento ao longo do conjunto backend. Além disso, quando você cria um sistema de banco de dados, o serviço Database cria VNICs automaticamente como nós do sistema de Banco de Dados. Esses serviços criam e gerenciam essas VNICs para você. Por esse motivo, essas VNICs não se tornam prontamente aparentes na Console da mesma forma que as VNICs destinadas a instâncias do serviço Compute.

Para usar um NSG, coloque VNICs da sua escolha no grupo. Entretanto, você normalmente trabalha com o recurso pai quando adiciona uma VNIC ao grupo. Você não trabalha com a VNIC em si. Por exemplo, quando você cria uma instância do serviço Compute, tem a opção de especificar um NSG para a instância. Embora, conceitualmente, você esteja colocando a instância no grupo, na verdade, a VNIC principal da instância é que está sendo colocada no grupo de segurança de rede. As regras de segurança do grupo se aplicam a essa VNIC, e não à instância. Além disso, se adicionar uma VNIC secundária à instância, você poderá, opcionalmente, especificar um NSG para essa VNIC, e as regras serão aplicadas a essa VNIC, e não à instância. Observe que todas as VNICs em determinado NSG devem estar na VCN à qual o NSG pertence.

Da mesma forma, ao colocar um balanceador de carga em um grupo de segurança de rede, conceitualmente você coloca o balanceador de carga no grupo. No entanto, na verdade, você está colocando as VNICs gerenciadas pelo serviço Load Balancing no grupo de segurança de rede.

Você gerencia a associação de VNICs a um NSG no recurso pai, e não no próprio NSG. Em outras palavras, para adicionar um recurso pai a um NSG, execute a ação no recurso pai (especificando a quais NSGs o recurso pai deverá ser adicionado). Você não executa a ação no NSG (especificando quais VNICs ou recursos pais devem ser adicionados ao NSG). Da mesma forma, para remover uma VNIC de um NSG, execute essa ação atualizando o recurso pai, e não o NSG. Por exemplo, para adicionar a VNIC de uma instância do serviço Compute existente a um NSG, atualize as propriedades dessa VNIC e especifique o NSG. Por exemplo, com a API REST, você chama o recurso UpdateVnic. Na Console, você exibe a instância e a VNIC de interesse e, em seguida, edita as propriedades da VNIC.

Para obter uma lista de recursos pais que suportam o uso de NSGs, consulte Suporte para Grupos de Segurança de Rede.

Grupo de Segurança de Rede como Origem ou Destino de uma Regra

Há uma diferença importante em como você pode elaborar regras de segurança para NSGs em comparação com listas de segurança.

Ao elaborar regras para um NSG, você pode especificar um NSG como a origem do tráfego (para regras de entrada) ou o destino do tráfego (para regras de saída). Compare esse comportamento com as regras de lista de segurança, nas quais você especifica um CIDR como origem ou destino.

A capacidade de especificar um NSG significa que você pode criar facilmente regras para controlar o tráfego entre dois NSGs diferentes. Os NSGs devem estar na mesma VCN.

Além disso, se você quiser controlar o tráfego entre as VNICs em um NSG específico, poderá criar regras que especificam o próprio NSG da regra como origem (das regras de entrada) ou destino (das regras de saída).

Para obter mais informações, consulte Visão Geral de Grupos de Segurança de Rede.

Diferenças da API REST

Em comparação com as listas de segurança, há algumas diferenças básicas no modelo da API REST para NSGs. Para obter mais informações, consulte Usando a API.

Regras Padrão

Sua VCN vem automaticamente com uma lista de segurança padrão que contém várias regras de segurança padrão para ajudá-lo a começar a usar o serviço Networking. Quando você cria uma sub-rede, a lista de segurança padrão é associada à sub-rede, a menos que você especifique uma lista de segurança personalizada já criada na VCN. Para fins de comparação, a VCN NÃO tem um grupo de segurança de rede padrão.

Limites

As duas funcionalidades têm limites distintos.

Limites da Lista de Segurança
Limites do Grupo de Segurança de Rede

Melhores Práticas para Regras de Segurança

Usar Grupos de Segurança de Rede

A Oracle recomenda o uso de NSGs para os casos em que todos os componentes têm a mesma postura de segurança. Por exemplo, em uma arquitetura de várias camadas, você teria um NSG separado para cada camada. Todas as VNICs de uma camada pertenceriam ao NSG dessa camada. Em determinada camada, você poderia ter um subconjunto específico das VNICs dessa camada cujos requisitos de segurança seriam distintos e especiais. Portanto, você criaria outro NSG para essas regras adicionais e colocaria esse subconjunto de VNICs no NSG da camada e no NSG adicional.

A Oracle também recomenda o uso de NSGs porque o sistema Oracle priorizará NSGs em listas de segurança ao implementar aprimoramentos futuros.

Familiarize-se com as Regras de Lista de Segurança Padrão

Sua VCN vem automaticamente com uma lista de segurança padrão que contém várias regras de segurança padrão para ajudá-lo a começar a usar o serviço Networking. Essas regras existem porque permitem conectividade básica. Mesmo que você opte por não usar listas de segurança ou a lista de segurança padrão, familiarize-se com as regras para entender melhor os tipos de tráfego necessários para os seus recursos de rede na nuvem. Talvez você queira usar essas regras nos seus NSGs ou em todas as listas de segurança personalizadas que configurar.

A lista de segurança padrão não inclui regras para permitir solicitações de ping. Se você precisar usar solicitações de ping, consulte Regras para Permitir Solicitações de Ping.

Não Exclua Regras de Segurança Padrão Indiscriminadamente

Como procedimento, a sua VCN pode ter sub-redes que usam a lista de segurança padrão. Não exclua qualquer uma das regras de segurança padrão da lista, a menos que você tenha confirmado primeiro que os recursos da sua VCN não precisam delas. Caso contrário, você poderá interromper a conectividade da sua VCN.

Confirme se as Regras de Firewall do Sistema Operacional Estão Alinhadas com Suas Regras de Segurança

As suas instâncias do Oracle Cloud Infrastructure que executam imagens do Windows ou imagens do Linux fornecidas pela Oracle também têm regras de firewall de sistema operacional que controlam o acesso à instância. Ao diagnosticar e solucionar problemas de acesso a uma instância, certifique-se de que todos os seguintes itens estão definidos corretamente:

  • As regras nos grupos de segurança de rede nos quais a instância está
  • As regras nas listas de segurança associadas à sub-rede da instância
  • As regras de firewall do sistema operacional da instância

Para obter mais informações, consulte Imagens Fornecidas pela Oracle.

Se a sua instância estiver sendo executada no Oracle Autonomous Linux 7 ou Oracle Linux 7, você precisará usar o firewalld para interagir com as regras do iptables. Para a sua referência, estes são comandos para abrir uma porta (1521, nesse exemplo):

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

Para instâncias com um volume de inicialização iSCSI, o comando --reload anterior pode causar problemas. Para obter detalhes e uma solução alternativa, consulte O sistema das instâncias congela após a execução de -cmd --reload.

Usar Métricas de VNIC para Diagnosticar e Solucionar Problemas com Pacotes Eliminados por Causa de Regras de Segurança

O serviço Networking oferece métricas para VNICs, que mostram os níveis de tráfego da VNIC (pacotes e bytes). Duas das métricas se referem a pacotes de entrada e saída que violam as regras de segurança e que, portanto, são eliminados. Você pode usar essas métricas para ajudá-lo a diagnosticar e solucionar problemas relacionados a regras de segurança e para determinar se as suas VNICs receberão o tráfego desejado.

Se Você Usar Listas de Segurança e Grupos de Segurança de Rede

Você pode usar apenas listas de segurança, apenas grupos de segurança de rede ou ambos juntos. Isso dependerá das suas necessidades de segurança específicas.

Se você tiver regras de segurança que deseja aplicar a todas as VNICs em uma VCN: a solução mais fácil é colocar as regras em uma lista de segurança e associar essa lista de segurança a todas as sub-redes da VCN. Dessa forma, você pode assegurar que as regras sejam aplicadas, independentemente de quem na sua organização cria uma VNIC na VCN. Se preferir, você pode usar a lista de segurança padrão da VCN, que vem automaticamente com a VCN e que, por padrão, contém um conjunto de regras essenciais.

Se você optar por usar listas de segurança e grupos de segurança de rede, o conjunto de regras que se aplicam a uma VNIC específica será a união destes itens:

  • As regras de segurança nas listas de segurança associadas à sub-rede da VNIC
  • As regras de segurança em todos os NSGs em que a VNIC está

O diagrama a seguir é uma ilustração simples da ideia.

Uma VNIC está sujeita às regras de todos os grupos de segurança de rede em que ela está e a todas as listas de segurança associadas à sua sub-rede.

Um pacote será permitido se qualquer regra em qualquer uma das listas possibilitar o tráfego (ou se o tráfego fizer parte de uma conexão existente que está sendo rastreada). Haverá uma limitação se as listas contiverem regras com e sem monitoramento de estado que abranjam o mesmo tráfego. Para obter mais informações, consulte Regras com e sem Monitoramento de Estado.

Partes de uma Regra de Segurança

Uma regra de segurança permite um tipo específico de tráfego para dentro ou para fora de uma VNIC. Por exemplo, uma regra de segurança comumente usada permite tráfego TCP de entrada na porta 22 para estabelecer conexões SSH com a instância (mais especificamente com as VNICs da instância). Sem regras de segurança, não é permitido tráfego para dentro e para fora das VNICs e na VCN.

Observação

As regras de segurança não são aplicadas ao tráfego relativo ao bloco CIDR 169.254.0.0/16. Isso inclui serviços como iSCSI e metadados de instância.

Cada regra de segurança especifica os seguintes itens:

  • Direção (entrada ou saída): entrada é o tráfego de entrada na VNIC, e a saída é o tráfego de saída da VNIC. O modelo de API REST para listas de segurança é diferente do modelo para grupos de segurança de rede. Com listas de segurança, há um objeto IngressSecurityRule e um objeto EgressSecurityRule separados. Com grupos de segurança de rede, só há um objeto SecurityRule e o atributo direction do objeto determina se a regra se destina a tráfego de entrada ou saída.
  • Com ou sem monitoramento de estado: se a opção com monitoramento de estado for usada, o rastreamento de conexões será usado para o tráfego correspondente à regra. Se a opção sem monitoramento de estado for selecionada, o rastreamento de conexões não será usado. Consulte Regras com e sem Monitoramento de Estado
  • Tipo de origem e origem (somente regras de entrada): a origem que você fornece para uma regra de entrada depende do tipo de origem escolhido.

    Tipos de origem permitidos
  • Tipo de destino e destino (somente regras de saída): o destino que você fornece para uma regra de saída depende do tipo de destino escolhido.

    Tipos de destino permitidos
  • Protocolo IP: um único protocolo IPv4 ou "todos" para abranger todos os protocolos.
  • Porta de origem: a porta onde o tráfego tem origem. Para TCP ou UDP, você pode especificar todas as portas de origem ou, opcionalmente, pode especificar um único número de porta de origem ou um intervalo.
  • Porta de destino: a porta para a qual o tráfego é destinado. Para TCP ou UDP, você pode especificar todas as portas de destino ou, opcionalmente, pode especificar um único número de porta de destino ou um intervalo.
  • Tipo e código ICMP: para ICMP, você pode especificar todos os tipos e códigos ou, opcionalmente, especificar um único tipo com um código opcional. Se o tipo tiver vários códigos, crie uma regra separada para cada código que você deseja permitir.
  • Descrição (somente regras NSG): as regras de segurança NSG incluem um atributo opcional no qual você pode fornecer uma descrição amigável da regra. Atualmente, isso não é suportado para regras de lista de segurança.

Para obter exemplos de regras de segurança, consulte Cenários do Serviço Networking.

Para obter o limite do número de regras que você pode ter, consulte Limites.

Observação

Se você estiver usando NSGs e duas VNICs que estão na mesma VCN precisarem se comunicar usando seus respectivos endereços IP públicos, será necessário usar o endereço IP público da VNIC e não o NSG da VNIC como origem (para entrada) ou destino (para saída) nas regras de segurança relevantes. O pacote é roteado para o gateway de internet da VCN e, nesse ponto, as informações do NSG da VNIC não estão disponíveis. Portanto, uma regra de segurança que especifica o NSG como origem ou destino será ineficaz na permissão desse tipo específico de tráfego.

Regras com e sem Monitoramento de Estado

Ao criar uma regra de segurança, você escolhe se ela terá monitoramento de estado ou não terá monitoramento de estado. A diferença é descrita nas seções a seguir. O padrão é com monitoramento de estado. As regras sem monitoramento de estado são recomendadas quando você tem um site de alto volume voltado para internet (para tráfego HTTP/HTTPS).

Esta seção se refere especificamente às instâncias do Compute e ao tráfego dessas instâncias. No entanto, a discussão é aplicável a todos os tipos de recursos com VNICs. Consulte Sobre VNICs e Recursos Pais.

Regras com Monitoramento de Estado

Marcar uma regra de segurança para ter monitoramento de estado indica que você deseja usar o rastreamento de conexões para qualquer tráfego que corresponda a essa regra. Isso significa que quando uma instância recebe tráfego correspondente à regra de entrada com monitoramento de estado, a resposta é rastreada e automaticamente permitida para o host de origem, independentemente das regras de saída aplicáveis à instância. E quando uma instância envia um tráfego correspondente a uma regra de saída com monitoramento de estado, a resposta recebida é automaticamente permitida, independentemente das regras de entrada. Para obter mais detalhes, consulte Detalhes do Rastreamento de Conexões para Regras com Monitoramento de Estado.

A figura a seguir ilustra uma regra de entrada com monitoramento de estado para uma instância que precisa receber tráfego HTTP e responder a ele. A Instância A e o Host B estão se comunicando (o Host B pode ser qualquer host, independentemente de ser ou não uma instância). A regra de entrada com monitoramento de estado permite o tráfego entre qualquer endereço IP de origem (0.0.0.0/0) e a porta de destino 80 (protocolo TCP) somente. Nenhuma regra de saída é necessária para permitir o tráfego de resposta.

Regra de entrada com monitoramento de estado que permite um tráfego HTTP de entrada e uma resposta

Regras sem Monitoramento de Estado

Marcar uma regra de segurança para não ter monitoramento de estado indica que você NÃO deseja usar o rastreamento de conexões para qualquer tráfego que corresponda a essa regra. Isso significa que o tráfego de resposta não é permitido automaticamente. Para permitir o tráfego de resposta em relação a uma regra de entrada sem monitoramento de estado, é necessário criar uma regra de saída sem monitoramento de estado correspondente.

A próxima figura mostra a Instância A e o Host B como anteriormente, mas agora com regras de segurança sem monitoramento de estado. Assim como a regra com monitoramento de estado mostrada na seção anterior, a regra de entrada sem monitoramento de estado permite o tráfego proveniente de todos os endereços IP e de todas as portas somente na porta de destino 80 (usando o protocolo TCP). Para que seja possível permitir o tráfego de resposta, deverá haver uma regra de saída sem monitoramento de estado correspondente que permita o tráfego entre qualquer endereço IP de destino (0.0.0.0/0) e todas as portas. No entanto, somente o tráfego proveniente da porta de origem 80 (usando o protocolo TCP) será permitido.

Regras de entrada e saída sem monitoramento de estado que permitem resposta e tráfego HTTP de entrada

Se, em vez disso, a Instância A precisar iniciar o tráfego HTTP e obter a resposta, será necessário um conjunto específico de regras sem monitoramento de estado. Como mostra a próxima figura, a regra de saída teria a porta de origem = todas e a porta de destino = 80 (HTTP). A regra de entrada teria a porta de origem 80 e a porta de destino = todas.

Regras de entrada e saída sem monitoramento de estado que permitem a instância iniciar tráfego HTTP e obter resposta

Se fosse usar o binding de portas na Instância A para especificar exatamente de qual porta o tráfego HTTP deveria vir, você poderia especificar essa porta como porta de origem na regra de saída e como porta de destino na regra de entrada.

Observação

Se, por algum motivo, você usar regras com e sem monitoramento de estado, e houver tráfego que corresponda a uma regra com e sem monitoramento de estado em uma direção específica (por exemplo, entrada), a regra sem monitoramento de estado terá precedência, e a conexão não será rastreada. Você precisaria de uma regra correspondente na outra direção (por exemplo, saída, com ou sem monitoramento de estado) para que o tráfego de resposta fosse permitido.

Detalhes do Rastreamento de Conexões para Regras com Monitoramento de Estado

O sistema Oracle usa o rastreamento de conexões para permitir respostas a um tráfego que corresponda às regras com monitoramento de estado (consulte Regras com e sem Monitoramento de Estado). Cada instância tem um número máximo de conexões simultâneas que podem ser rastreadas com base na forma da instância.

Para determinar o tráfego de resposta para TCP, UDP e ICMP, o sistema Oracle realiza o rastreamento de conexões nesses itens do pacote:

  • Protocolo
  • Endereços IP de origem e de destino
  • Portas de origem e de destino (somente para TCP e UDP)
Observação

Para outros protocolos, o sistema Oracle rastreia somente o protocolo e os endereços IP, e não as portas. Isso significa que quando uma instância inicia o tráfego para outro host e esse tráfego é permitido pelas regras de segurança de saída, qualquer tráfego que a instância receba posteriormente desse host durante um período é considerado tráfego de resposta e é permitido.

Ativando Mensagens de PMTUD (Path MTU Discovery) para Regras sem Monitoramento de Estado

Se você decidir usar regras de segurança sem monitoramento de estado para permitir o tráfego de/para pontos finais fora da VCN, será importante adicionar uma regra de segurança que permita tráfego de entrada do tipo 3 código 4 proveniente da origem 0.0.0.0/0 e de qualquer porta de origem. Essa regra permite que as suas instâncias recebam mensagens de fragmentação PMTU (Path MTU Discovery). Esta regra é crítica para estabelecer uma conexão com as suas instâncias. Sem ela, você pode ter problemas de conectividade. Para obter mais informações, consulte Conexão Pendente.

Regras para Permitir Solicitações de Ping

A lista de segurança padrão da VCN contém diversas regras padrão, mas não tem uma regra para permitir solicitações de ping. Se quiser usar solicitações de ping em uma instância, certifique-se de que os NSGs e as listas de segurança aplicáveis da instância incluam uma regra de entrada com monitoramento de estado adicional para permitir especificamente o tráfego ICMP tipo 8 proveniente da rede de origem de onde você pretende fazer solicitações de ping. Para permitir acesso por ping proveniente da internet, use 0.0.0.0/0 como origem. Observe que essa regra para ping é separada das regras relacionadas a ICMP padrão na lista de segurança padrão. Não remova essas regras.

Regras para Tratar Pacotes UDP Fragmentados

As instâncias podem enviar ou receber tráfego UDP. Se um pacote UDP for grande demais para a conexão, ele será fragmentado. No entanto, somente o primeiro fragmento do pacote contém as informações sobre protocolo e porta. Se as regras de segurança que permitem esse tráfego de entrada ou saída determinarem um número de porta específico (origem ou destino), os fragmentos após o primeiro serão eliminados. Se você espera que as suas instâncias enviem ou recebam pacotes UDP grandes, defina as portas de origem e de destino para as regras de segurança aplicáveis como ALL (em vez de um número de porta específico).