Regras de Segurança

Sobre VNICs e Recursos Pais

Uma VNIC é um componente do serviço Networking que permite que um recurso de rede, como uma instância de computação, estabeleça conexão 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 de computação, 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 de computação. Por esse motivo, as VNICs de uma instância são exibidas destacadamente como parte dos recursos relacionados de uma instância de computação 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 Balancer cria automaticamente VNICs para tráfego de balanceamento ao longo do conjunto de 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 visíveis na Console da mesma forma que as VNICs destinadas a instâncias de computação.

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, ao criar uma instância de computação, você 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 Balancer 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 de computação 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 especifiquem o próprio NSG da 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

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. Consulte Limites do Serviço para ver uma lista de limites e instruções aplicáveis para solicitar um aumento de limite.

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

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 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.

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, já que 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, 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.

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

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)

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

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.