Visão Geral do Serviço Networking

Quando você trabalha com o Oracle Cloud Infrastructure, uma das primeiras etapas é configurar uma Rede Virtual na Nuvem (VCN) para recursos de nuvem. Este tópico fornece uma visão geral dos componentes do Oracle Cloud Infrastructure Networking e cenários típicos para usar uma VCN.

Dica

Assista a uma introdução em vídeo do serviço.

Componentes do serviço Networking

O serviço Networking utiliza versões virtuais de componentes de rede tradicionais com os quais você pode já estar familiarizado:

Rede Virtual na Nuvem (VCN)
Uma rede virtual privada configurada nos data centers da Oracle. Ela se parece muito com uma rede tradicional, com regras de firewall e tipos específicos de gateways de comunicação que você pode decidir usar. Uma VCN reside em uma única região do Oracle Cloud Infrastructure e abrange um ou mais blocos CIDR (IPv4 e IPv6, se ativados). Consulte Tamanho da VCN e Intervalos de Endereços Permitidos. Os termos rede virtual na nuvem, VCN e rede na nuvem são usados de forma intercambiável nesta documentação. Para obter mais informações, consulte VCNs e Sub-redes.
SUB-REDES

Subdivisões que você define em uma VCN (por exemplo, 10.0.0.0/24, 10.0.1.0/24 ou 2001:DB8::/64). As sub-redes contêm VNICs (virtual network interface cards), que se conectam a instâncias do serviço Compute. Cada sub-rede consiste em uma faixa contígua de endereços IP (para IPv4 e IPv6, se ativada) que não são sobrepostas a outras sub-redes na VCN. É possível definir a existência de uma sub-rede em um único domínio de disponibilidade ou em toda uma região (sub-redes regionais são recomendadas). Sub-redes atuam como uma unidade de configuração dentro da VCN: Todas as VNICs em uma sub-rede específica usam a mesma tabela, listas de segurança e opções DHCP (consulte as definições a seguir). É possível definir uma sub-rede como pública ou privada ao criá-la. Privado significa que as VNICs da sub-rede não podem ter endereços IPv4 públicos e que a comunicação pela internet com pontos finais IPv6 é proibida. Público significa que VNICs na sub-rede podem ter endereços IPv4 públicos e que a comunicação com a internet é permitida por pontos finais IPv6. Consulte Acesso à Internet.

VNIC
Uma placa de interface de rede virtual (VNIC), que se conecta a um serviço Compute e reside em uma sub-rede para permitir uma conexão com a VCN da sub-rede. VNIC é o componente que a instância do serviço Compute usa para estabelecer conexão com pontos finais dentro e fora da VCN. Cada instância do serviço Compute tem uma VNIC principal que é criada durante a criação da instância do serviço Compute e não pode ser removida. Você pode adicionar VNICs secundárias a uma instância existente do serviço Compute (no mesmo domínio de disponibilidade da VNIC principal) e removê-las, conforme necessário. Cada VNIC secundária pode estar em uma sub-rede na mesma VCN da VNIC principal ou em outra sub-rede na mesma VCN ou em outra. Entretanto, todas as VNICs devem estar no mesmo domínio de disponibilidade da instância do serviço Compute. Para obter mais informações, consulte VNICs (Virtual Network Interface Cards). Uma VNIC anexada a uma instância do serviço Compute e que reside em uma Sub-rede ativada por IPv6 pode receber opcionalmente um endereço IPv6.
IP PRIVADO
Um endereço IPv4 privado e informações relacionadas para tratar uma instância do serviço Compute (por exemplo, um nome do host para DNS). Cada VNIC tem um IP privado principal, e você pode adicionar e remover IPs privados secundários. O endereço IP privado principal em uma instância do serviço Compute não é alterado durante o tempo de vida da instância do serviço Compute e não pode ser removido da instância do serviço Compute. Para obter mais informações, consulte Endereços IP Privados.
IP PÚBLICO
Um endereço IPv4 público e informações relacionadas. Opcionalmente, você pode designar um IP público a instâncias de Computação ou a outros recursos que tenham um IP privado. Os IPs públicos podem ser efêmeros ou reservados. Para obter mais informações, consulte Endereços IP Públicos.
IPV6
Um endereço IPv6 e informações relacionadas. Há suporte para o endereçamento IPv6 em todas as regiões comerciais e do setor governamental. Para obter mais informações, consulte Endereços IPv6.
Gateway de Roteamento Dinâmico (DRG)
Um roteador virtual opcional que você pode anexar a uma ou várias VCNs. Fornece um caminho para tráfego da rede privada entre uma VCN e uma rede on-premises. Você pode usá-lo com outros componentes de Rede e um roteador em uma rede local para estabelecer uma conexão por meio de VPN Site a Site ou do Oracle Cloud Infrastructure FastConnect. Também pode fornecer um caminho para o tráfego da rede privada entre uma VCN e outra VCN na mesma região ou em outra. Para obter mais informações, consulte Acesso à Sua Rede Local, Gateways de Roteamento Dinâmico, Pareamento Local de VCN por Meio de um DRG Submetido a Upgrade e Pareamento Remoto de VCN por meio de um DRG Submetido a Upgrade.
GATEWAY DE INTERNET
Um roteador virtual opcional que você pode adicionar a uma VCN para acesso direto pela internet. Para obter mais informações, consulte Gateway de Internet e também Cenário A: Sub-rede Pública.
GATEWAY NAT (CONVERSÃO DE ENDEREÇO DE REDE)
Outro roteador virtual opcional que você pode adicionar a uma VCN. Ele permite que recursos de nuvem sem endereços IP públicos acessem a internet sem expor esses recursos a conexões de entrada na internet. Para obter mais informações, consulte Sub-redes Públicas versus Privadas e também Gateway NAT.
GATEWAY DE SERVIÇO
Outro roteador virtual opcional que você pode adicionar a uma VCN. Ele fornece um caminho para o tráfego privado entre uma VCN e serviços suportados na Oracle Services Network (exemplos: Oracle Cloud Infrastructure Object Storage e Autonomous AI Database). Por exemplo, os Sistemas de BD em uma sub-rede privada em uma VCN podem fazer backup de dados no serviço Object Storage sem precisar de endereços IP públicos ou acesso à internet. Para obter mais informações, consulte Acesso a Serviços Oracle: Gateway de Serviço.
GATEWAY DE PAREAMENTO LOCAL (LPG)
Outro roteador virtual opcional que você pode adicionar a uma VCN. Ele permite parear uma VCN com outra VCN na mesma região. Pareamento significa que as VCNs se comunicam usando endereços IP privados, sem o tráfego que passa pela internet ou que é roteado por uma rede local. Uma VCN deve ter um LPG separado para cada pareamento estabelecido por ela. Para obter mais informações, consulte Pareamento de VCN Local usando Gateways de Pareamento Locais.
CONEXÃO DE PAREAMENTO REMOTO (RPC)
Um componente que você pode adicionar a um DRG. Ele permite parear uma VCN com outra VCN em outra região. Para obter mais informações, consulte Pareamento Remoto de VCN por meio de um DRG Atualizado.
TABELAS DE ROTEAMENTO
Tabelas de roteamento virtual para uma VCN. Eles têm regras para rotear o tráfego de sub-redes para destinos fora da VCN por meio de gateways ou instâncias do serviço Compute especialmente configuradas. Uma VCN vem com uma tabela da rota padrão vazia, e você pode adicionar tabelas da rota personalizadas. Para obter mais informações, consulte Tabelas de Roteamento de VCN.
REGRAS DE SEGURANÇA
Regras de firewall virtual para uma VCN. As regras de saída e entrada especificam os tipos de tráfego (protocolo e porta) permitidos dentro e fora das instâncias do serviço Compute. Você pode decidir se uma regra específica tem ou não monitoramento de estado. Por exemplo, você pode permitir o tráfego SSH recebido de qualquer lugar para um conjunto de instâncias do serviço Compute configurando uma regra da entrada com monitoramento do estado com o CIDR de origem 0.0.0.0/0 e porta TCP de destino 22. Para implementar regras de segurança, você pode usar grupos de segurança de rede ou listas de segurança. Um grupo de segurança de rede consiste em um conjunto de regras de segurança que se aplicam somente aos recursos desse grupo. Compare um grupo de segurança com uma lista de segurança, no qual as regras se aplicam a todos os recursos de qualquer sub-rede que use a lista. Uma VCN vem com uma Lista de Segurança Padrão com Regras de Segurança Padrão. Para obter mais informações, consulte Regras de Segurança.
OPÇÕES DE DHCP
Informações de configuração fornecidas automaticamente às instâncias do serviço Compute quando elas são inicializadas. Para obter mais informações, consulte as Opções de DHCP.
NOTAÇÃO CIDR
Um método compacto para especificar endereços IP ou intervalos de endereços e máscaras de rede. Por exemplo, o uso de IPv4 uma faixa de endereços IP privados de 10.0.0.0/24 representa todos os endereços entre 10.0.0.0 e 10.0.0.255. O /24 representa uma máscara de sub-rede de 255.255.255.0 porque os primeiros 24 bits estão mascarados. IPv6 usa notação semelhante a para blocos de endereço. Para obter mais informações, consulte RFC1817 e RFC1519.

Tamanho da VCN e Intervalos de Endereços Permitidos

Uma VCN abrange um ou mais blocos IPv4 CIDR ou prefixos IPv6. O intervalo de tamanho de VCN permitido é de /16 a /30. Exemplo: 10.0.0.0/16. O serviço Networking reserva os dois primeiros endereços IP e o último no CIDR de cada sub-rede. Você pode ativar IPv6 para VCNs ao criá-las ou pode ativar IPv6 em VCNs somente IPv4 existentes. Se você decidir usar um prefixo IPv6 alocado pela Oracle, sempre receberá um /56. Se preferir, você poderá importar seu próprio prefixo IPv6 BYOIP do qual poderá designar qualquer prefixo de /64 ou maior a uma VCN ou designar um prefixo ULA de /64 ou maior. As faixas de GUA podem ir até 2000::/3 e as faixas de ULA podem ir até fc00::/7. O tamanho das sub-redes IPv6 é sempre /64.

Para uma VCN, recomendamos o uso das faixas de endereços IP privados especificados na RFC 1918 (a RFC recomenda 10.0/8 ou 172.16/12, mas a Oracle não suporta esses tamanhos; portanto, use 16/10.0, 172.16/16 e 192.168/16). No entanto, você pode usar um intervalo roteável de forma pública. Independentemente, essa documentação usa o termo endereço IP privado ao fazer referência a endereços IP no CIDR de uma VCN. As faixas de endereços que não são permitidas são descritas em Endereços IP Reservados para Uso do Sistema Oracle. Nas VCNs ativadas para IPv6, a Oracle pode alocar um prefixo /56 de endereço unicast global ou criar uma VCN com um prefixo BYOIPv6.

Os blocos CIDR da VCN não devem se sobrepor aos CIDRs em uma rede on-premises conectada ou aos CIDRs de outra VCN com a qual há pareamento. As sub-redes de determinada VCN não devem se sobrepor. Para referência, verifique a calculadora de CIDR.

Há suporte para o endereçamento IPv6 em todas as regiões comerciais e do setor governamental. Para obter mais informações, consulte Endereços IPv6.

Domínios de Disponibilidade e VCNs

Uma VCN reside em uma única região do Oracle Cloud Infrastructure. Uma região pode ter vários domínios de disponibilidade para fornecer isolamento e redundância. Para obter mais informações, consulte Regiões e Domínios de Disponibilidade.

Originalmente, as sub-redes foram projetadas para cobrir somente um domínio de disponibilidade (AD) em uma região. Elas eram todas específicas do AD. Isso significa que os recursos da sub-rede precisavam residir em determinado domínio de disponibilidade. Agora as sub-redes podem ser específicas ou regionais do AD. Você seleciona o tipo ao criar a sub-rede. Ambos os tipos de sub-rede podem coexistir na mesma VCN. No diagrama a seguir, as sub-redes 1 a 3 são específicas do AD, e a sub-rede 4 é regional.

Esta imagem mostra uma VCN com uma sub-rede regional e três sub-redes específicas do AD.

As sub-redes regionais se comportam da mesma forma que as sub-redes específicas do AD. A diferença é a remoção da restrição do AD. Recomendamos o uso de sub-redes regionais porque elas são mais flexíveis. Elas tornam mais fácil dividir com eficiência uma VCN em sub-redes, projetando falhas no domínio de disponibilidade.

Ao criar um recurso, como uma instância do Compute, você decide em qual domínio de disponibilidade o recurso está. De um ponto de vista de rede virtual, você também deve decidir em qual VCN e em qual sub-rede a instância está. Você pode selecionar uma sub-rede regional ou específica do AD que corresponda ao AD escolhido para a instância.

Componentes Padrão que Vêm com uma VCN

Uma VCN vem automaticamente com estes componentes padrão:

Não é possível excluir esses componentes padrão. Entretanto, é possível alterar o conteúdo desses componentes (por exemplo, as regras na lista de segurança padrão). Você também pode criar versões personalizadas de cada tipo de componente em uma VCN. Existem limites quanto a quantos você pode criar e ao número máximo de regras. Para obter mais informações, consulte Limites por Serviço.

Cada sub-rede sempre tem estes componentes associados a ela:

  • Uma tabela de roteamento
  • Uma ou mais listas de segurança (para o número máximo, consulte Limites por Serviço)
  • Um conjunto de opções de DHCP

Durante a criação da sub-rede, você pode decidir qual tabela de roteamento, lista de segurança e conjunto de opções de DHCP a sub-rede utilizará. Se você não especificar um componente específico, a sub-rede usará automaticamente o componente padrão da VCN. A qualquer momento, é possível alterar quais componentes a sub-rede utilizará.

Dica

As listas de Segurança são uma forma de controlar o tráfego dentro e fora dos recursos da VCN. Também é possível usar grupos de segurança de rede

Opções de Conectividade

Você pode controlar se as sub-redes serão públicas ou privadas e se as instâncias terão endereços IP públicos. Você pode configurar uma VCN para ter acesso à internet, se necessário. Você também pode conectar de forma privada uma VCN com os serviços públicos do Oracle Cloud Infrastructure, como o Object Storage, com uma rede local ou com outra VCN.

Sub-redes Públicas e Privadas

Quando você cria uma sub-rede, por padrão, ela é considerada pública. Isso significa que as instâncias dessa sub-rede podem ter endereços IPv4 públicos e que a comunicação pela internet é permitida com pontos finais IPv6. Quem iniciar a instância escolhe se ela terá um endereço IPv4 público ou especifica se um endereço IPv6 do prefixo alocado será designado. Você pode substituir esse comportamento ao criar a sub-rede e solicitar que ela seja privada, o que não permite o uso de endereços IPv4 públicos e a comunicação pela internet com pontos finais IPv6. Portanto, os administradores de rede podem assegurar que as instâncias da sub-rede não terão acesso à internet, mesmo que a VCN tenha um gateway de internet em funcionamento e que as regras de segurança e de firewall permitam o tráfego.

Como os Endereços IP São Designados

Cada instância tem uma VNIC principal que é criada durante a inicialização da instância e não pode ser removida. Você pode adicionar VNICs secundárias a uma instância existente (no mesmo domínio de disponibilidade que a VNIC principal) e removê-las como desejar.

Cada VNIC tem um endereço IP privado proveniente do CIDR da sub-rede associada. Você pode escolher o endereço IP específico (durante a inicialização da instância ou a criação da VNIC secundária) ou pode deixar que o sistema Oracle o escolha para você. O endereço IP privado não é alterado durante o tempo de vida da instância e não pode ser removido. Você também pode adicionar endereços IPv4 privados secundários ou endereços IPv6 secundários a uma VNIC.

Se a VNIC estiver em uma sub-rede pública, cada IP privado dessa VNIC poderá ter um endereço IPv4 ou IPv6 público designado a ela à sua escolha. Para IPv4, a Oracle escolhe o endereço IP específico. Para IPv6, você pode especificar o endereço IP. Há dois tipos de IPs públicos: efêmeros e reservados. Um IP público efêmero só existe durante o tempo de vida do IP privado ao qual ele está designado. Por outro lado, um IP público reservado existirá durante o tempo que você quiser. Você mantém um pool de IPs públicos reservados e os aloca para as instâncias desejadas. Você pode movê-los de recurso para recurso em uma região como precisar.

Acesso à Internet

Há dois gateways (roteadores virtuais) opcionais que você pode adicionar à sua VCN, dependendo do tipo de acesso à internet necessário:

  • Gateway de internet: para recursos com endereços IP públicos que precisam ser acessados pela internet (exemplo: um servidor web) ou que precisam iniciar conexões com a internet.
  • Gateway NAT: para recursos sem endereços IP públicos que precisam iniciar conexões com a internet (exemplo: para atualizações de software), mas que precisam ser protegidos de conexões recebidas pela internet.

Ter apenas um gateway de internet não permite que você exponha as instâncias nas sub-redes da VCN diretamente à internet. Os seguintes requisitos também devem ser atendidos:

Dica

Para acessar serviços públicos como Object Storage por meio da sua VCN sem o tráfego que passa pela internet, use um gateway de serviço.

Além disso, observe que o tráfego por meio de um gateway de internet entre uma VCN e um endereço IP público que faz parte do Oracle Cloud Infrastructure (como o Object Storage) é roteado sem ser enviado pela internet.

Você também pode permitir que uma sub-rede tenha acesso indireto à internet configurando um proxy de internet na sua rede local e conectando essa rede com a sua VCN por meio de um DRG. Para obter mais informações, consulte Acesso à Sua Rede Local.

Acesso a Serviços Públicos do Oracle Cloud Infrastructure

Você pode usar um gateway de serviço com a sua VCN para permitir acesso privado a serviços públicos do Oracle Cloud Infrastructure, como o Object Storage. Por exemplo, Sistemas de Banco de Dados em uma sub-rede privada na sua VCN podem fazer backup de dados no Object Storage sem precisar de endereços IP públicos ou de acesso à internet. Não é necessário usar gateway de internet ou NAT. Para obter mais informações, consulte Acesso a Serviços Oracle: Gateway de Serviço.

Acesso à Sua Rede Local

Há duas maneiras de conectar a sua rede local ao Oracle Cloud Infrastructure:

  • VPN Site a Site: Oferece vários túneis IPSec entre a borda da rede existente e a VCN, por meio de um DRG que você cria e anexa à sua VCN.
  • Oracle Cloud Infrastructure FastConnect: oferece uma conexão privada entre a borda da sua rede existente e o Oracle Cloud Infrastructure. O tráfego não passa pela internet. Tanto o pareamento privado quanto o pareamento público são suportados. Isso significa que os hosts locais podem acessar endereços IPv4 ou IPv6 privados na sua VCN, bem como endereços IPv4 ou IPv6 públicos regionais no Oracle Cloud Infrastructure (por exemplo, Object Storage ou balanceadores de carga públicos na sua VCN).

É possível usar um ou ambos os tipos de conexões anteriores. Se ambos forem usados, você poderá usá-los simultaneamente ou em uma configuração redundante. Essas conexões chegam à sua VCN por meio de um único DRG que você cria e anexa à sua VCN. Sem a anexação desse DRG e sem uma regra de roteamento para o DRG, o tráfego não flui entre a sua VCN e a rede local. A qualquer momento, você pode desanexar o DRG da sua VCN, mas manter todos os outros componentes que formam o restante da conexão. Nesse caso, você poderá anexar o DRG novamente ou anexá-lo a outra VCN.

Acesso a Outra VCN

Você pode conectar a sua VCN a outra VCN por meio de uma conexão privada que não requer que o tráfego passe pela internet. Em geral, esse tipo de conexão é chamado de pareamento de VCNs. Cada VCN deve ter componentes específicos para permitir o pareamento. As VCNs também devem ter políticas do IAM específicas, regras de roteamento e regras de segurança que permitam que a conexão seja estabelecida e o tráfego de rede desejado flua pela conexão. Para obter mais informações, consulte Acesso a Outras VCNs: Pareamento.

Conexão com o Microsoft Azure

A Oracle e o Microsoft criaram uma conexão de nuvem cruzada entre o Microsoft Azure e o Oracle Cloud Infrastructure em determinadas regiões. Essa conexão permite configurar cargas de trabalho de nuvem cruzada sem o tráfego entre as nuvens da internet. Para obter mais informações, consulte Interconexão para Azure.

Conexão com Outras Nuvens Usando Libreswan

Você pode conectar sua VCN a outro provedor de nuvem usando a VPN Site a Site com uma VM do Libreswan como o CPE (customer-premises equipment). Para obter mais informações, consulte Acesso a Outras Nuvens com o Libreswan.

Cenários de Rede

Esta documentação inclui alguns cenários de rede básicos para ajudá-lo a entender o serviço Networking e a como os componentes trabalham juntos em geral. Consulte estes tópicos:

Roteamento do Trânsito

Os Cenários de A a C mostram uma rede on-premises conectada a uma ou mais VCNs por meio de um DRG e FastConnect ou VPN Site a Site e acessando apenas os recursos dessas VCNs.

Os cenários de roteamento avançados a seguir concedem acesso a uma rede on-premises além dos recursos da VCN conectada. O tráfego vai de uma rede on-premises para o DRG e depois transita pelo DRG até seu destino. Consulte estes tópicos:

  • Roteamento de Trânsito dentro de uma VCN hub: Uma rede on-premises tem acesso a várias VCNs na mesma região por meio de um único circuito virtual privado FastConnect ou da VPN Site-to-Site. O DRG e as VCNs anexadas estão em uma topologia hub e spoke, com a rede on-premises conectada ao DRG, que age como hub. As VCNs spoke são pareadas.
  • Acesso Privado aos Serviços Oracle: Uma rede local tem acesso privado aos serviços Oracle no Oracle Services Network por meio de uma VCN conectada e do gateway do VCN. O tráfego não passa pela internet.

Regiões e Domínios de Disponibilidade

Uma VCN reside em uma única região do Oracle Cloud Infrastructure. Cada sub-rede reside em um único domínio de disponibilidade (AD). Os domínios de disponibilidade são projetados para fornecer isolamento e redundância na VCN, conforme ilustrado nos Cenários B e Cenários C mencionados anteriormente. Por exemplo, você pode configurar um principal conjunto de sub-redes em um único AD e configurar um conjunto duplicado de sub-redes em um AD secundário. Os dois ADs são isolados um do outro nos data centers da Oracle. Dessa forma, se houver uma falha, você poderá alternar facilmente para o outro AD. Para obter mais informações, consulte Regiões e Domínios de Disponibilidade.

Intervalos de Endereços IP Públicos

Para obter uma lista de intervalos de IPs públicos do Oracle Cloud Infrastructure, consulte Intervalos de Endereços IP.

Endereços IP Reservados para Uso do Sistema Oracle

Determinados endereços IP são reservados para uso do Oracle Cloud Infrastructure e não podem ser usados em um esquema de numeração de endereços.

169.254.0.0/16

Esses endereços são usados para conexões iSCSI com os volumes de inicialização e de armazenamento em blocos, os metadados da instância e outros serviços.

Classes D e E

Todos os endereços de 224.0.0.0 a 239.255.255.255 (Classe D) são proibidos para uso em uma VCN, eles são reservados para atribuições de endereço multicast nos padrões IP. Consulte a RFC 3171 para obter detalhes.

Todos os endereços de 240.0.0.0 a 255.255.255.255 (Classe E) são proibidos para uso em uma VCN; eles são reservados para uso futuro nos padrões IP. Consulte a RFC 1112, Seção 4 para obter detalhes.

Três Endereços IP em Cada Sub-rede

Esses endereços consistem:

  • No primeiro endereço IP no CIDR (o endereço de rede)
  • O último endereço IP no CIDR (o endereço de difusão)
  • O endereço do primeiro host no CIDR (o endereço de gateway padrão da sub-rede)

Por exemplo, em uma sub-rede com o CIDR 192.168.0.0/24, estes são os endereços reservados:

  • 192.168.0.0 (o endereço de rede)
  • 192.168.0.255 (o endereço de difusão)
  • 192.168.0.1 (o endereço do gateway padrão da sub-rede)

Os endereços restantes no CIDR (192.168.0.2 a 192.168.0.254) estão disponíveis para uso.

Criando Automação com Eventos

Você pode criar automação com base nas alterações de estado dos recursos do Oracle Cloud Infrastructure usando tipos de evento, regras e ações. Para obter mais informações, consulte Visão Geral de Eventos.

Identificadores de Recursos

A maioria dos tipos de recursos do Oracle Cloud Infrastructure tem um identificador exclusivo designado pelo Oracle chamado OCID (Oracle Cloud ID). Para obter informações sobre o formato OCID e outras maneiras de identificar os seus recursos, consulte Identificadores de Recursos.

Formas de Acessar o Oracle Cloud Infrastructure

Você pode acessar o OCI (Oracle Cloud Infrastructure) usando a Console (uma interface baseada em browser), a API REST ou a CLI do OCI. Instruções para usar a Console, API e CLI nos tópicos ao longo desta documentação. Para ver uma lista de SDKs disponíveis, consulte Software Development Kits e Interface de Linha de Comando.

Para acessar a Console, você deve usar um browser suportado. Para ir até a página de acesso da Console, abra o menu de navegação na parte superior desta página e selecione Console de Infraestrutura. Você é solicitado a digitar seu tenant na nuvem, seu nome de usuário e sua senha.

Para obter informações gerais sobre o uso da API, consulte APIs REST.

Autenticação e Autorização

Cada serviço do Oracle Cloud Infrastructure se integra ao IAM para autenticação e autorização, para todas as interfaces (Console, SDK ou CLI e API REST).

Um administrador de uma organização precisa configurar grupos, compartimentos e políticas que controlam quais usuários podem acessar quais serviços, quais recursos e o tipo de acesso. Por exemplo, as políticas controlam quem pode criar novos usuários, criar e gerenciar a rede na nuvem, criar instâncias, criar buckets, fazer download dos objetos, entre outros. Para obter mais informações, consulte Gerenciando Domínios de Identidade. Para ver detalhes específicos sobre a elaboração de políticas para cada um dos diferentes serviços, consulte a Referência para Políticas.

Se você for um usuário comum (não um administrador) que precisa usar os recursos do Oracle Cloud Infrastructure que a empresa possui, entre em contato com um administrador para configurar um ID de usuário para você. O administrador pode confirmar o(s) compartimento(s) que você pode usar.

Políticas do IAM para Redes

A abordagem mais direta para conceder acesso à Rede é a política listada em Permitir que os administradores da rede gerenciem uma rede na nuvem. Ela abrange a rede na nuvem e todos os outros componentes da Rede (sub-redes, listas de segurança, tabelas de roteamento, gateways etc.). Para também oferecer aos administradores de rede a capacidade de criar instâncias (para testar a conectividade da rede), consulte Permitir que os usuários iniciem instâncias de computação.

Se você for novo em políticas, consulte Gerenciando Domínios de Identidades e Políticas Comuns.

Para obter material de referência ao escrever políticas mais detalhadas para Redes, consulte Detalhes dos Serviços Principais.

Tipos de Recursos Individuais

Você pode escrever políticas que se concentrem em tipos de recursos individuais (por exemplo, apenas listas de segurança) em vez de se concentrarem em virtual-network-family, que é mais amplo. O tipo de recurso instance-family também inclui várias permissões para VNICs, que residem em uma sub-rede, mas são anexadas a uma instância. Para obter mais informações, consulte Detalhes das Combinações de Verbo + Tipo de Recurso e VNICs (Virtual Network Interface Cards).

Um tipo de recurso chamado local-peering-gateways está incluído em virtual-network-family e inclui dois outros tipos de recursos relacionados ao pareamento local de VCN (dentro da região):

  • local-peering-from
  • local-peering-to

O tipo de recurso local-peering-gateways abrange todas as permissões relacionadas aos LPGs (local peering gateways). Os tipos de recurso local-peering-from e local-peering-to têm o objetivo de conceder permissão para conectar dois LPGs e definir um relacionamento de pareamento em uma única região. Para obter mais informações, consulte Pareamento Local usando um LPG (VCNs na Mesma Tenancy) ou Pareamento Local usando um LPG (VCNs em Tenancies Diferentes).

Da mesma forma, um tipo de recurso chamado remote-peering-connections está incluído em virtual-network-family e inclui dois outros tipos de recursos relacionados ao pareamento remoto de VCN (entre regiões):

  • remote-peering-from
  • remote-peering-to

O tipo de recurso remote-peering-connections abrange todas as permissões relacionadas às RPCs (Remote Peering Connections). Os tipos de recurso remote-peering-from e remote-peering-to têm o objetivo de conceder permissão para conectar dois RPCs e definir um relacionamento de pareamento entre regiões. Para obter mais informações, consulte Pareamento Remoto com um DRG Legado e Pareamento Remoto com um DRG Atualizado.

Nuances dos Diferentes Verbos

Você pode escrever políticas que limitam o nível de acesso usando outro verbo de política (manage em vez de use e assim por diante). Se fizer isso, aqui estão algumas nuances a serem compreendidas sobre os verbos de política para Rede.

Lembre-se de que o verbo inspect não só retorna informações gerais sobre os componentes da rede na nuvem (por exemplo, o nome e o OCID de uma lista de segurança ou de uma tabela de roteamento). O verbo também inclui o conteúdo do componente (por exemplo, as regras propriamente ditas contidas na lista de segurança, as rotas na tabela de roteamento etc.).

Além disso, os seguintes tipos de habilidades estão disponíveis apenas com o verbo manage e não com o verbo use:

  • Atualizar (ativar/desativar) internet-gateways
  • Atualizar security-lists
  • Atualizar route-tables
  • Atualizar dhcp-options
  • Anexar um Gateway de Roteamento Dinâmico (DRG) a uma VCN (Rede Virtual na Nuvem)
  • Criar uma conexão IPSec entre um DRG e o CPE (Customer-Premises Equipment)
  • Parear VCNs
Importante

Cada VCN tem vários componentes que afetam diretamente o comportamento da rede (tabelas de roteamento, listas de segurança, opções de DHCP, Gateway de Internet etc.). Ao criar um desses componentes, você estabelece um relacionamento entre esse componente e a VCN. Isso significa que você deve ter permissão em uma política para criar o componente e gerenciar a VCN propriamente dita. No entanto, a capacidade de atualizar esse componente (para alterar as regras de roteamento, as regras de lista de segurança etc.) não requer permissão para gerenciar a própria VCN, mesmo que a alteração desse componente possa afetar diretamente o comportamento da rede. Essa discrepância tem a intenção de dar flexibilidade para conceder menos privilégio aos usuários, e não requer que você conceda acesso excessivo à VCN para que o usuário possa gerenciar outros componentes da rede. Lembre-se de que ao conceder a alguém a capacidade de atualizar determinado tipo de componente, você está implicitamente confiando o controle do comportamento da rede a essa pessoa.

Para obter mais informações sobre verbos de políticas, consulte Informações Básicas sobre Política.

Políticas de Pareamento

Para políticas usadas na conexão de um DRG com VCNs e DRGs em outras regiões e tenancies, consulte Políticas do Serviço IAM para Roteamento entre VCNs.