Sécuriser la communication à l'aide de la prise en charge TLS et mTLS (données en transit)

Oracle GoldenGate protège les données en transit ou en mouvement à l'aide des fonctionnalités suivantes :

Les protocoles Streaming avec autorisation HTTP native sont pris en charge. Il inclut un en-tête dans la demande d'établissement initiale WebSocket, qui est le protocole de socket Web sécurisé (WSS). Le serveur Oracle GoldenGate vérifie l'en-tête d'autorisation pour approuver ou refuser la demande selon que le rôle associé à l'utilisateur demandeur est supérieur ou égal au rôle affecté aux demandes d'établissement de sockets Web. Oracle GoldenGate prend en charge l'authentification TLS 1.2 et TLS 1.3. Vous pouvez choisir entre différentes options de cryptage TLS et appliquer les mécanismes de cryptage appropriés.
Les chemins initiés par la cible prennent en charge la transition des données lorsque vous travaillez dans des zones démilitarisées (DMZ).

Reportez-vous également à Distribution Path Streaming Protocols.

Communication sécurisée à l'aide de la prise en charge de TLS et de mTLS

Le protocole TLS (Transport Layer Security) assure une communication sécurisée sur un réseau en assurant la transmission sécurisée des données. L'échange de données entre le serveur (instance GoldenGate) et les clients, y compris l'interface Web GoldenGate, AdminClient et d'autres applications, est authentifié et crypté. Il utilise des algorithmes cryptographiques pour chiffrer les données, empêchant les parties non autorisées d'accéder ou de modifier les informations transmises.

TLS vérifie l'identité du serveur pour s'assurer que la communication est avec la partie visée et non avec un acteur malveillant. HTTPS et WSS utilisent le protocole TLS. Les demandes HTTPS sont effectuées via des appels REST-API et WSS est utilisé pour le routage sécurisé des fichiers trace par le chemin de distribution.

Le protocole TLS mutuel (mTLS) est une extension du protocole TLS qui ajoute une couche de sécurité supplémentaire en authentifiant le client et le serveur dans une session de communication. Il s'agit d'une amélioration du TLS traditionnel, fournissant une confiance bidirectionnelle, et constitue une défense supplémentaire contre les attaques usurpées. Pendant l'établissement de liaison client-serveur, le serveur présente son certificat numérique pour prouver son identité au client afin que le client vérifie l'identité du serveur. Le client client présente également son certificat numérique pour prouver son identité au serveur server afin que le serveur vérifie l'identité du client.

Dans un déploiement sécurisé, mTLS est utilisé par le processus de chemin de distribution pour envoyer des fichiers trace à l'aide du protocole WSS dans l'un des cas suivants :

Envoi des données de trace du service de distribution au service récepteur
Envoi de données de trace à l'aide du chemin de distribution lancé par la cible, où le service de réception demande au service de distribution d'envoyer des fichiers trace sur le réseau.

L'utilisation de l'authentification du client de distribution (DistClient) en présentant le certificat numérique DistClient permet une communication réseau sécurisée à l'aide de mTLS.

Un déploiement sécurisé est recommandé pour Oracle GoldenGate. Il nécessite le certificat du serveur, la clé privée et le certificat de signature de l'autorité de certification (certificat CA). Le certificat DistClient, la clé privée et le certificat de signature de l'autorité de certification (certificat CA) peuvent être appliqués à tout moment.

Cependant, NGINX peut être utilisé avec un déploiement non sécurisé pour toujours fournir la prise en charge de TLS pour le chemin de distribution. Le protocole TLS sera interrompu sur NGINX. Le certificat NGINX sera vérifié par le client. Toutefois, le certificat client est facultatif par la configuration NGINX par défaut d'Oracle GoldenGate.

Pour plus d'informations, reportez-vous à Chemin initié par la cible et à Prise en charge du proxy inverse Oracle GoldenGate. Remarque : mTLS n'est pas pris en charge lorsqu'un proxy inverse est utilisé.

Fonctionnement de Transport Layer Security dans un environnement Oracle : établissement de liaison TLS

Lorsqu'une connexion réseau via Transport Layer Security est lancée, le client et le serveur exécutent une liaison TLS avant l'authentification.

Le processus d'établissement de liaison est le suivant :

Le client et l'instance Oracle GoldenGate établissent les mécanismes de cryptage et les algorithmes de cryptage utilisés pour les transferts de données.
L'instance Oracle GoldenGate envoie son certificat au client et ce dernier vérifie que le certificat de l'instance Oracle GoldenGate a été signé par une autorité de certification sécurisée. Cette étape vérifie l'identité de l'instance Oracle GoldenGate.
De même, si l'authentification client est requise, le client envoie son certificat à l'instance Oracle GoldenGate. L'instance Oracle GoldenGate vérifie que le certificat du client a été signé par une autorité de certification sécurisée.
Le client et l'instance Oracle GoldenGate échangent des informations de clé à l'aide de la cryptographie par clé publique. En fonction de ces informations, chacune génère une clé de session. Une clé est partagée par au moins deux parties (généralement un client et une instance Oracle GoldenGate) qui sont utilisées pour le cryptage des données pendant la durée d'une session de communication unique. Les clés de session sont généralement utilisées pour chiffrer le trafic réseau. Un client et une instance Oracle GoldenGate peuvent négocier une clé de session au début d'une session, et cette clé est utilisée pour crypter tout le trafic réseau entre les parties pour cette session. Si le client et l'instance Oracle GoldenGate communiquent à nouveau dans une nouvelle session, ils négocient une nouvelle clé de session. Toutes les communications ultérieures entre le client et l'instance Oracle GoldenGate sont cryptées et décryptées à l'aide de cette clé de session et du mécanisme de cryptage négocié.

Le processus d'authentification est le suivant : 1. Sur un client, l'utilisateur lance une connexion réseau à Oracle GoldenGate à l'aide de TLS.

TLS effectue l'établissement de liaison entre le client et Oracle GoldenGate.
Si l'établissement de liaison réussit, l'instance GoldenGate vérifie que l'utilisateur dispose de l'autorisation appropriée pour accéder à l'instance Oracle GoldenGate.

Comment Oracle GoldenGate utilise Transport Layer Security pour l'authentification

A l'aide de la fonctionnalité TLS d'Oracle GoldenGate pour sécuriser les communications entre les instances et les clients Oracle GoldenGate, vous pouvez effectuer les opérations suivantes :

utiliser TLS pour crypter la connexion entre les instances Oracle GoldenGate et les clients
Authentifiez tout client ou toute autre instance Oracle GoldenGate sur toute autre instance Oracle GoldenGate configurée pour communiquer via TLS.

Une fois TLS établi, l'instance Oracle GoldenGate devra authentifier le client pour s'assurer qu'il dispose des privilèges appropriés pour envoyer la trace. Les modes d'authentification suivants sont utilisés :

L'instance Oracle GoldenGate authentifie le client à l'aide de l'ID utilisateur et du mot de passe qui a au moins le rôle Opérateur côté cible. L'ID utilisateur et le mot de passe sont stockés en tant qu'alias côté client. L'alias est utilisé lors de la création du chemin de distribution.

Reportez-vous à Connexion de deux déploiements à l'aide d'un certificat RootCA externe pour en savoir plus sur la configuration d'un utilisateur de rôle d'opérateur, puis sur l'utilisation de cet ID utilisateur et de cet alias de mot de passe lors de la création d'une connexion de chemin de distribution entre des déploiements distants.
L'instance Oracle GoldenGate utilise le certificat client pour authentifier la demande client, en supposant qu'un utilisateur de certificat correspondant est créé côté cible. Pour connaître les étapes de création de certificats côté client et côté serveur, reportez-vous à Création de certificats pour des déploiements sécurisés.
L'instance Oracle GoldenGate authentifie le client à l'aide de OAuth, lorsqu'elle utilise un fournisseur d'identification externe (IdP), tel qu'IAM. Reportez-vous à Délégation de la gestion des utilisateurs à un fournisseur d'identités externe.

Mécanismes de cryptage TLS

Une suite de chiffrement indique un algorithme pour chacune des tâches suivantes :

Échange de clés
Cryptage en masse
Code d'authentification de messages (MAC)

Les mécanismes de cryptage par défaut pour TLS 1.2 et 1.3 sont pris en charge, à l'exception des cryptages faibles.

Oracle vous recommande vivement d'utiliser TLS 1.3 pour répondre à vos exigences en matière de sécurité.

Les mécanismes de cryptage par défaut pour TLS 1.2 sont pris en charge, à l'exception des cryptages faibles.

Chemin initié par la cible

Les chemins initiés par la cible pour les microservices permettent au service de destinataire de lancer un chemin vers le service de distribution sur le déploiement de la cible et d'extraire les fichiers trace. Cette fonctionnalité permet au service de destinataire de créer un chemin lancé par la cible pour des environnements tels que les chemins de zone démilitarisés (DMZ) ou le cloud vers le site, où le service de distribution dans le déploiement Oracle GoldenGate source ne peut pas ouvrir de connexions réseau dans l'environnement cible au service de destinataire en raison de stratégies de sécurité réseau.

Si le service de distribution ne peut pas initier de connexions au service de destinataire, mais que le service de destinataire peut initier une connexion à l'hôte exécutant le service de distribution, le service de destinataire établit un chemin sécurisé ou non sécurisé initié par la cible vers le service de distribution via un pare-feu ou une zone démilitarisée (DMZ) à l'aide d'Oracle GoldenGate pour extraire les fichiers trace demandés. Les points de terminaison du service de destinataire indiquent que l'extraction des fichiers trace a été lancée par le service de destinataire.

Un chemin (en lecture seule) est créé à partir du service de destinataire du déploiement cible et possède la propriété TARGET_INITIATED. Ce chemin est également accessible à partir du service de distribution. Les informations de chemin sont stockées sur le système cible. Si la communication est perdue, le service de destinataire sur l'hôte cible a besoin de la définition de chemin pour redémarrer la connexion. Ces informations sont partagées avec le service de distribution lorsque le chemin est en cours d'exécution. Le chemin est éphémère sur le déploiement source. Les chemins éphémères contribuent à la consolidation de la configuration des chemins et au renforcement de l'initiation de la connexion cible-source.

Lorsque le chemin est arrêté ou déconnecté, le service de distribution supprime toutes les informations sur le chemin, y compris la définition du chemin. Toutefois, le fichier de point de reprise est conservé car il est utilisé pour déterminer si les anciennes traces peuvent être purgées ou non. Il est recommandé de ne pas purger les anciennes traces, sauf si le chemin est intentionnellement supprimé.

Rubriques connexes :

Prise en charge du proxy inverse Oracle GoldenGate

Le proxy inverse permet d'accéder aux microservices à l'aide d'un seul port (443) dans un déploiement. Cela permet l'encapsulation de l'URL pour les microservices sur un déploiement non sécurisé. Remarque : le proxy inverse est facultatif. Cependant, Oracle vous recommande de garantir un accès facile aux microservices et une sécurité renforcée.

Vous pouvez exécuter des microservices dans un déploiement non sécurisé sur une adresse loopback et l'afficher avec un proxy HTTP inverse à l'aide de l'installation de Nginx.

Oracle GoldenGate MA inclut un script appelé ReverseProxySettings qui génère un fichier de configuration pour le serveur proxy inverse Nginx uniquement.

Par exemple, le service d'administration est disponible sur http://goldengate.example.com:9001 et le service de distribution sur http://goldengate.example.com:9002. Avec le proxy inverse, chacun des microservices est simplement accessible à partir de l'adresse unique. Par exemple, http://goldengate.example.com/distsrvr pour le service de distribution. L'URL est différente pour chaque service et est par nom plutôt que par port.

Ces valeurs sont utilisées lors de la connexion au gestionnaire de services et sont requises lorsque l'authentification est activée.

Reportez-vous à Configuration du proxy inverse Oracle GoldenGate avec NGINX pour implémenter le proxy inverse NGINX avec Oracle GoldenGate.