Regras de Segurança

Sobre VNICs e Recursos Pais

Uma VNIC é um componente de serviço de Rede necessário para um recurso em rede, como uma instância do serviço Compute, para se conectar a uma VCN (Virtual Cloud Network). A VNIC afeta 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 mais VNICs (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.

Outros tipos de recursos pais também resultam na criação automática de uma VNIC. Por exemplo: quando você cria um Balanceador de Carga, o serviço Load Balancer cria automaticamente VNICs para balancear o tráfego entre o conjunto de backend. Além disso, quando você cria um sistema de BD, o serviço Database cria automaticamente VNICs como nós do sistema de BD. Esses serviços criam e gerenciam essas VNICs para você. Por esse motivo, essas VNICs não são tão óbvias na Console da mesma forma como as VNICs são para instâncias de Computação.

Para usar um NSG, você coloca ativamente VNICs no grupo, uma VNIC nunca faz parte de um NSG porque está em uma determinada sub-rede. 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, ao criar uma instância do serviço Compute, você pode especificar um NSG para a instância. Embora você conceitualmente coloque a instância no grupo, você estará colocando a VNIC principal da instância 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 um NSG devem estar na mesma VCN à qual o NSG pertence.

Da mesma forma, quando você coloca um Balanceador de Carga em um grupo da segurança de rede, você coloca conceitualmente o Balanceador de Carga no grupo. Tecnicamente, você está colocando as VNICs gerenciadas pelo serviço Load Balancer no grupo de segurança da rede.

Você gerencia a associação de VNICs a um NSG no recurso pai, e não no próprio NSG. Por exemplo, para adicionar um recurso pai a um NSG, você executa a ação no recurso pai (especificando a quais NSGs o recurso pai é adicionado). Você não executa a ação no NSG (especificando quais VNICs ou recursos pais adicionar ao NSG). Da mesma forma, para remover uma VNIC de um NSG, você executa essa ação atualizando o recurso pai, não o NSG. Por exemplo, para adicionar uma VNIC existente da instância do serviço Compute 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, 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

Uma diferença importante em como você pode gravar regras de segurança para NSGs em comparação com listas de segurança: ao gravar regras para um NSG, você pode especificar um NSG como a origem do tráfego (no caso de regras de entrada) ou o destino do tráfego (no caso de regras de entrada). 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, para controlar o tráfego entre VNICs em um NSG específico, você pode gravar regras que especificam o NSG da própria regra como origem (para regras de entrada) ou destino (para 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

O modelo de API REST para NSGs tem algumas diferenças básicas em t em comparação com as listas de segurança. Para obter mais informações, consulte Usando a API.

Regras Padrão

Uma VCN vem automaticamente com uma lista padrão de segurança que contém várias regras de segurança default para ajudá-lo a começar a usar o serviço Networking. Quando você cria uma sub-rede, essa lista é associada à sub-rede, salvo se você especificar uma lista personalizada de segurança já criada na VCN.

Para comparação, a VCN não tem um grupo padrão de segurança da rede.

Limites

As duas funcionalidades têm limites distintos. Consulte Limites de Serviço para obter uma lista de limites e instruções aplicáveis a uma solicitação de aumento de limite.

Usar Grupos de Segurança de Rede

É recomendável usar NSGs para componentes que têm a mesma postura de segurança. Por exemplo, em uma arquitetura de várias camada, você teria um NSG separado para cada camada. Todas as VNICs de uma camada pertenceriam ao NSG da camada. Em uma camada específica, você pode ter um subconjunto específico de VNICs da camada que tenham requisitos especiais de segurança extras. Portanto, você criaria outro NSG para essas regras extras e colocaria esse subconjunto de VNICs no NSG da camada e no NSG extra.

A Oracle também recomenda o uso dos NSGs porque a Oracle prioriza os NSGs em relação às listas de segurança ao implementar aprimoramentos futuros.

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

Uma VCN vem automaticamente com uma lista padrão de segurança que contém várias regras de segurança default para ajudá-lo a começar a usar o serviço Networking. Essas regras existem porque permitem conectividade básica. Mesmo que você não use listas e segurança padrão, familiarize-se com as regras, para que você entenda melhor os tipos de tráfego exigidos pelos recursos de nuvem em rede. Talvez você queira usar essas regras em NSGs ou em quaisquer listas de segurança personalizadas que você configurar.

A lista de segurança padrão não inclui regras para ativar o 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

Uma VCN pode ter sub-redes que usam a lista de segurança padrão por padrão. Não exclua nenhuma das regras de segurança padrão da lista, a menos que você tenha confirmado pela primeira vez que os recursos na VCN não os exigem. Caso contrário, você poderá interromper a conectividade da VCN.

Confirmar se as Regras de Firewall do Sistema Operacional se Alinham com Regras de Segurança

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-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 de Rede oferece métricas para VNICs, que mostram os níveis de tráfego de 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 solucionar problemas relacionados a regras de segurança e se as VNICs estão recebendo o tráfego apropriado.

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.

Por exemplo, pode haver uma regra de segurança de entrada com monitoramento de estado para uma instância (A) que precisa receber e responder ao tráfego HTTP do Host B. O host B pode ser qualquer host, independentemente de ser ou não uma instância. A Instância A e o Host B estão se comunicando porque a regra de entrada com monitoramento de estado só permite o tráfego de qualquer endereço IP de origem (0.0.0.0/0) para a porta de destino 80 (protocolo TCP). Nenhuma regra de saída é necessária para permitir o tráfego de resposta porque as respostas são rastreadas e permitidas automaticamente.

Regras sem Monitoramento de Estado

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.

Se a Instância A precisar, em vez disso, iniciar o tráfego HTTP e obter a resposta, então será necessário um conjunto diferente de regras sem monitoramento de status. 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.

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.

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

A Oracle usa o rastreamento de conexão para permitir respostas para tráfego que corresponda a regras com monitoramento do estado (consulte Regras com Monitoramento de Estado Comparado a Sem Monitoramento de Estado). Cada instância tem um número máximo de conexões simultâneas que pode ser rastreado, com base na forma da instância.

Para decidir o tráfego de resposta para TCP, UDP e ICMP, a Oracle executa o rastreamento de conexão nestes itens para o pacote:

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

As conexões rastreadas são mantidas enquanto o tráfego é recebido para a conexão. Se uma conexão permanecer ociosa o suficiente, ela expirará e será removida. Depois que a conexão é removida, as respostas para uma regra de segurança com monitoramento de estado são eliminadas. A tabela a seguir mostra os timeouts padrão por inatividade:

Ativando Mensagens do 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. Esta regra permite que as instâncias de Computação recebam mensagens de fragmentação de Descoberta de MTU do Caminho. Esta regra é crítica para estabelecer uma conexão com instâncias. Sem ela, você pode ter problemas de conectividade. Para obter mais informações, consulte Conexão Pendente.