Comunicação Segura Usando o Suporte a TLS e mTLS (Dados em Trânsito)

O Oracle GoldenGate protege os dados em trânsito ou em movimento usando os seguintes recursos:

• Protocolos de streaming com autorização HTTP nativa são suportados. Ele inclui um cabeçalho na solicitação inicial de estabelecimento WebSocket, que é o protocolo de soquete web seguro (WSS). O servidor do Oracle GoldenGate verifica o cabeçalho de autorização para aprovar ou negar a solicitação com base na atribuição associada ao usuário solicitante ser igual ou maior que a atribuição designada para solicitações de estabelecimento do Web Sockets. O Oracle GoldenGate suporta a autenticação TLS 1.2 e TLS 1.3. Você pode escolher entre diferentes opções de criptografia TLS e aplicar as suítes de cifragem relevantes.

• Caminhos iniciados por destino suportam a transição de dados ao trabalhar em Zonas Desmilitarizadas (DMZ).

Consulte também Protocolos de Streaming de Caminho de Distribuição.

Comunicação Segura Usando o Suporte de TLS e mTLS

O protocolo TLS (Transport Layer Security) fornece comunicação segura em uma rede, garantindo a transmissão segura de dados. A troca de dados entre o servidor (instância GoldenGate) e os clientes, incluindo a interface Web GoldenGate, AdminClient e outros aplicativos, é autenticada e criptografada. Ele usa algoritmos criptográficos para criptografar dados, impedindo que partes não autorizadas acessem ou modifiquem as informações que estão sendo transmitidas.

O TLS verifica a identidade do servidor para garantir que a comunicação seja com a parte pretendida e não com um ator mal-intencionado. HTTPS e WSS usam o protocolo TLS. As solicitações HTTPS são feitas por meio de chamadas de API REST e o WSS é usado para o roteamento seguro de arquivos de trilha pelo Caminho de Distribuição.

Mutual TLS (mTLS) é uma extensão do protocolo TLS que adiciona uma camada extra de segurança ao autenticar o cliente e o servidor em uma sessão de comunicação. É uma melhoria para o TLS tradicional, proporcionando uma confiança bidirecional, e é uma defesa adicional contra ataques personificados. Durante o handshake cliente-servidor, o servidor apresenta o certificado digital dele para provar sua identidade ao cliente de modo que o cliente verifique a identidade do servidor. O cliente também apresenta seu certificado digital para provar sua identidade ao servidor de modo que o servidor verifique a identidade do cliente.

Em uma implantação segura, o mTLS é usado pelo processo Caminho de Distribuição para enviar arquivos de trilha usando o protocolo WSS em um dos seguintes casos:

• Enviando dados de trilha do Serviço de Distribuição para o Serviço do Receptor

• Enviando dados de trilha usando o Caminho de Distribuição Iniciado pelo Destino, em que o Serviço do Receptor solicita ao Serviço de Distribuição o envio de arquivos de trilha pela rede.

Usando a autenticação do Cliente de Distribuição (DistClient) apresentando o certificado digital DistClient, permite uma comunicação de rede segura usando mTLS.

Uma implantação segura é recomendada para o Oracle GoldenGate. Ele requer o certificado do servidor, a chave privada e o Certificado de assinatura da Autoridade de Certificação (certificado de CA). O certificado DistClient, a chave privada e o certificado de assinatura da Autoridade de Certificação (certificado de CA) podem ser aplicados a qualquer momento.

No entanto, NGINX poderia ser usado com implantação insegura para ainda fornecer suporte TLS para o caminho de distribuição. O TLS será encerrado no NGINX. O certificado NGINX será verificado pelo cliente. No entanto, o certificado do cliente é opcional pela configuração NGINX padrão do Oracle GoldenGate.

Consulte Caminho Iniciado pelo Destino e Suporte ao Proxy Reverso do Oracle GoldenGate para obter detalhes. Observação: o mTLS não é suportado quando um Proxy Reverso é usado.

Como a Segurança da Camada de Transporte Funciona em um Ambiente Oracle: o Handshake do TLS

Quando uma conexão de rede pelo Transport Layer Security é iniciada, o cliente e o servidor executam um handshake TLS antes da autenticação.

O processo de handshake é o seguinte:

1. O cliente e a instância do Oracle GoldenGate estabelecem os conjuntos de cifras e os algoritmos de criptografia usados para transferências de dados.

2. A instância do Oracle GoldenGate envia seu certificado ao cliente e o cliente verifica se o certificado da instância do Oracle GoldenGate foi assinado por uma CA confiável. Esta etapa verifica a identidade da instância do Oracle GoldenGate.

3. Da mesma forma, se a autenticação do cliente for necessária, o cliente enviará seu certificado para a instância do Oracle GoldenGate. A instância do Oracle GoldenGate verifica se o certificado do cliente foi assinado por uma CA confiável.

4. As instâncias do cliente e do Oracle GoldenGate trocam informações de chave usando criptografia de chave pública. Com base nessas informações, cada uma gera uma chave de sessão. Uma chave é compartilhada por pelo menos duas partes (geralmente um cliente e uma instância do Oracle GoldenGate) que é usada para criptografia de dados durante uma única sessão de comunicação. Geralmente, as chaves de sessão são usadas para criptografar o tráfego de rede. Um cliente e uma instância do Oracle GoldenGate podem negociar uma chave de sessão no início de uma sessão, e essa chave é usada para criptografar todo o tráfego de rede entre as partes dessa sessão. Se o cliente e a instância do Oracle GoldenGate se comunicarem novamente em uma nova sessão, eles negociarão uma nova chave de sessão. Toda a comunicação subsequente entre o cliente e a instância do Oracle GoldenGate é criptografada e decriptografada usando esta chave de sessão e o conjunto de cifras negociado.

O processo de autenticação é o seguinte: 1. Em um cliente, o usuário inicia uma conexão de rede com o Oracle GoldenGate usando TLS.

1. TLS executa o handshake entre o cliente e o Oracle GoldenGate.

2. Se o handshake for bem-sucedido, a instância GoldenGate verificará se o usuário tem a autorização apropriada para acessar a instância do Oracle GoldenGate.

Como o Oracle GoldenGate Usa a Segurança da Camada de Transporte para Autenticação

Usando a funcionalidade TLS do Oracle GoldenGate para proteger a comunicação entre instâncias e clientes do Oracle GoldenGate, você pode fazer o seguinte:

• Usar o TLS para criptografar a conexão entre instâncias e clientes do Oracle GoldenGate

• Autentique qualquer cliente ou qualquer outra instância do Oracle GoldenGate, em qualquer outra instância do Oracle GoldenGate configurada para comunicação por TLS.

Depois que o TLS for estabelecido, a instância do Oracle GoldenGate precisará autenticar o cliente para garantir que ele tenha privilégios corretos para enviar a trilha. Os seguintes modos de autenticação são usados:

• A Instância do Oracle GoldenGate autenticará o cliente usando o ID do usuário e a senha que tem pelo menos a atribuição Operador no lado de destino. O ID do usuário e a senha são armazenados como alias no cliente. O alias é usado ao criar o caminho de distribuição.

  Consulte Conectando Duas Implantações Usando o Certificado RootCA Externo para saber mais sobre como configurar um usuário de atribuição Operador e, em seguida, usar esse ID de usuário, alias de senha ao criar uma conexão de caminho de distribuição entre implantações remotas.

• A instância do Oracle GoldenGate usará o certificado do cliente para autenticar a solicitação do cliente, supondo que haja um usuário de certificado correspondente criado no lado de destino. Para ver as etapas de criação de certificados para os clientes e os servidores, consulte Criar Certificados para Implantações Seguras.

• A instância do Oracle GoldenGate autenticará o cliente usando OAuth quando usar o provedor de identificação externa (IdP), como o serviço IAM. Consulte Delegar o Gerenciamento de Usuários a um Provedor de Identidades Externo.

Suítes de Cifragem TLS

Um conjunto de cifras especifica um algoritmo para cada uma das seguintes tarefas:

• Troca de chaves

• Criptografia em massa

• Código de autenticação de mensagem (MAC)

Os conjuntos de cifras padrão para TLS 1.2 e 1.3 são suportados, exceto para as cifras fracas.

A Oracle recomenda que você use o TLS 1.3 para atender aos seus requisitos de segurança.

Os conjuntos de cifras padrão para TLS 1.2 são suportados, exceto pelas cifras fracas.

Caminho Iniciado pelo Destino

Os caminhos iniciados pelo destino para microsserviços permitem que o Serviço do Receptor inicie um caminho para o Serviço de Distribuição na implantação de destino e extraia arquivos de trilha. Esse recurso permite que o Serviço do Receptor crie um caminho iniciado por destino para ambientes como Caminhos de Zona Desmilitarizados (DMZ) ou Nuvem para on-premise, em que o Serviço de Distribuição na implantação do Oracle GoldenGate de origem não pode abrir conexões de rede no ambiente de destino para o Serviço do Receptor devido a políticas de segurança de rede.

Se o Serviço de Distribuição não puder iniciar conexões com o Serviço do Receptor, mas o Serviço do Receptor puder iniciar uma conexão com o host que executa o Serviço de Distribuição, o Serviço do Receptor estabelecerá um caminho seguro ou não seguro iniciado pelo destino para o Serviço de Distribuição por meio de um firewall ou zona Desmilitarizada (DMZ) usando o Oracle GoldenGate para extrair os arquivos de trilha solicitados. Os pontos finais do Serviço do Receptor exibem que a recuperação dos arquivos de trilha foi iniciada pelo Serviço do Receptor.

Um caminho (somente leitura) é criado com base no Serviço Receptor da implantação de destino e tem a propriedade TARGET_INITIATED. Este caminho também pode ser acessado no Serviço de Distribuição. As informações de caminho são armazenadas no sistema de destino. Se a comunicação for perdida, o Serviço Receptor no host de destino precisará da definição de caminho para reiniciar a conexão. Essas informações são compartilhadas com o Serviço de Distribuição quando o caminho está em execução. O caminho é efêmero na implantação de origem. Caminhos efêmeros ajudam na consolidação da configuração do caminho e com o reforço da iniciação da conexão de destino para origem.

Quando o caminho é interrompido ou desconectado, o Serviço de Distribuição remove todas as informações do caminho, incluindo a definição do caminho. No entanto, o arquivo de checkpoint é mantido porque o checkpoint é usado para decidir se as trilhas antigas podem ser expurgadas ou não. É recomendável que as trilhas antigas não sejam limpas, a menos que o caminho seja excluído intencionalmente.

Tópicos Relacionados:

• Autenticação com Certificados

• Conectando Duas Implantações Usando o Certificado RootCA Externo

• Adicionar um Caminho de Distribuição

Suporte ao Proxy Reverso do Oracle GoldenGate

O proxy reverso permite acessar microsserviços usando uma única porta (443) em uma implantação. Isso permite o encapsulamento do URL para microsserviços em uma implantação não segura. Observação: O proxy reverso é opcional; no entanto, a Oracle recomenda que você garanta acesso fácil a microsserviços e forneça segurança aprimorada.

Você pode executar microsserviços em uma implantação não segura no endereço de loopback e enfrentá-lo com um proxy reverso HTTP usando a instalação do Nginx.

O Oracle GoldenGate MA inclui um script chamado ReverseProxySettings que gera um arquivo de configuração somente para o servidor proxy reverso Nginx.

Por exemplo, o Serviço de Administração está disponível no http://goldengate.example.com:9001 e o Serviço de Distribuição no http://goldengate.example.com:9002. Com o proxy reverso, cada um dos microsserviços pode ser acessado a partir de um único endereço. Por exemplo, http://goldengate.example.com/distsrvr para o Serviço de Distribuição. O URL é diferente para cada serviço e é por nome em vez de por porta.

Esses valores são usados ao estabelecer conexão com o Service Manager e são necessários quando a autenticação está ativada.

Consulte Configurar o Proxy Reverso do Oracle GoldenGate com NGINX para implementar o proxy reverso NGINX com o Oracle GoldenGate.