Comunicazione sicura mediante il supporto TLS e mTLS (dati in transito)

Oracle GoldenGate protegge i dati in transito o in movimento utilizzando le funzioni riportate di seguito.

• Sono supportati i protocolli di streaming con autorizzazione HTTP nativa. Include un'intestazione nella richiesta di stabilimento WebSocket iniziale, che è il protocollo WSS (Secure Web Socket). Il server Oracle GoldenGate controlla l'intestazione di autorizzazione per approvare o negare la richiesta in base al fatto che il ruolo associato all'utente richiedente sia uguale o maggiore del ruolo assegnato per le richieste di creazione dei socket Web. Oracle GoldenGate supporta l'autenticazione TLS 1.2 e TLS 1.3. È possibile scegliere tra diverse opzioni di cifratura TLS e applicare le suite di cifratura pertinenti.

• I percorsi avviati dalla destinazione supportano la transizione dei dati quando si lavora in zone demilitarizzate (DMZ).

Vedere anche Protocolli di streaming del percorso di distribuzione.

Comunicazione sicura mediante il supporto di TLS e mTLS

Il protocollo TLS (Transport Layer Security) garantisce la comunicazione sicura su una rete garantendo la trasmissione sicura dei dati. Lo scambio di dati tra il server (istanza GoldenGate) e i client, tra cui l'interfaccia Web GoldenGate, AdminClient e altre applicazioni, viene autenticato e cifrato. Utilizza algoritmi crittografici per crittografare i dati, impedendo a parti non autorizzate di accedere o modificare le informazioni trasmesse.

TLS verifica l'identità del server per garantire che la comunicazione sia con la parte prevista e non con un attore dannoso. HTTPS e WSS utilizzano il protocollo TLS. Le richieste HTTPS vengono effettuate tramite chiamate REST-API e WSS viene utilizzato per l'instradamento sicuro dei file trail dal percorso di distribuzione.

Mutual TLS (mTLS) è un'estensione del protocollo TLS che aggiunge un ulteriore livello di sicurezza eseguendo l'autenticazione sia del client che del server in una sessione di comunicazione. Si tratta di un miglioramento alla TLS tradizionale, fornendo una fiducia bidirezionale, ed è un'ulteriore difesa contro gli attacchi impersonati. Durante l'handshake client-server, il server presenta un certificato digitale per provare la sua identità al client in modo che il client verifichi l'identità del server. Il client presenta anche il certificato digitale per dimostrare la propria identità al server in modo che il server verifichi l'identità del client.

In una distribuzione sicura, mTLS viene utilizzato dal processo Percorso di distribuzione per inviare i file trail utilizzando il protocollo WSS in uno dei seguenti casi:

• Invio dei dati trail dal servizio di distribuzione al servizio ricevente

• Invio dei dati trail mediante il percorso di distribuzione avviato di destinazione, in cui il servizio ricevente richiede al servizio di distribuzione di inviare i file trail sulla rete.

L'utilizzo dell'autenticazione Distribution Client (DistClient) mediante la presentazione del certificato digitale DistClient consente una comunicazione di rete sicura con mTLS.

Per Oracle GoldenGate è consigliata una distribuzione sicura. Richiede il certificato del server, la chiave privata e il certificato di firma dell'autorità di certificazione (certificato CA). Il certificato DistClient, la chiave privata e il certificato di firma dell'autorità di certificazione (certificato CA) possono essere applicati in qualsiasi momento.

Tuttavia, NGINX potrebbe essere utilizzato con una distribuzione non sicura per fornire ancora il supporto TLS per il percorso di distribuzione. Il TLS verrà terminato in NGINX. Il certificato NGINX verrà verificato dal client. Tuttavia, il certificato client è facoltativo dalla configurazione NGINX predefinita di Oracle GoldenGate.

Per i dettagli, vedere Percorso avviato dalla destinazione e Supporto proxy inverso di Oracle GoldenGate. Nota: mTLS non è supportato quando si utilizza un proxy inverso.

Funzionamento di Transport Layer Security in un ambiente Oracle: l'handshake TLS

Quando viene avviata una connessione di rete su Transport Layer Security, il client e il server eseguono un handshake TLS prima dell'autenticazione.

Il processo di handshake è il seguente:

1. Il client e l'istanza di Oracle GoldenGate definiscono le suite di cifratura e gli algoritmi di cifratura utilizzati per i trasferimenti di dati.

2. L'istanza di Oracle GoldenGate invia il certificato al client e il client verifica che il certificato dell'istanza di Oracle GoldenGate sia stato firmato da una CA sicura. Questo passo verifica l'identità dell'istanza di Oracle GoldenGate.

3. Analogamente, se è richiesta l'autenticazione del client, il client invia il proprio certificato all'istanza di Oracle GoldenGate. L'istanza di Oracle GoldenGate verifica che il certificato del client sia stato firmato da una CA sicura.

4. Le informazioni sulla chiave di scambio del client e dell'istanza Oracle GoldenGate utilizzano la crittografia a chiave pubblica. Sulla base di queste informazioni, ognuno genera una chiave di sessione. Una chiave viene condivisa da almeno due parti (in genere un client e un'istanza di Oracle GoldenGate) che viene utilizzata per la cifratura dei dati per la durata di una singola sessione di comunicazione. Le chiavi di sessione vengono in genere utilizzate per cifrare il traffico di rete. Un client e un'istanza di Oracle GoldenGate possono negoziare una chiave di sessione all'inizio di una sessione e tale chiave viene utilizzata per cifrare tutto il traffico di rete tra le parti per tale sessione. Se il client e l'istanza Oracle GoldenGate comunicano di nuovo in una nuova sessione, negoziano una nuova chiave di sessione. Tutte le comunicazioni successive tra il client e l'istanza di Oracle GoldenGate vengono cifrate e decifrate utilizzando questa chiave di sessione e la suite di cifratura negoziata.

Il processo di autenticazione è il seguente: 1. Su un client, l'utente avvia una connessione di rete a Oracle GoldenGate utilizzando TLS.

1. TLS esegue l'handshake tra il client e Oracle GoldenGate.

2. Se l'handshake riesce, l'istanza GoldenGate verifica che l'utente disponga dell'autorizzazione appropriata per accedere all'istanza di Oracle GoldenGate.

Modalità di utilizzo di Transport Layer Security per l'autenticazione da parte di Oracle GoldenGate

La funzionalità TLS di Oracle GoldenGate per proteggere le comunicazioni tra le istanze e i client Oracle GoldenGate consente di effettuare le operazioni riportate di seguito.

• Usare TLS per cifrare la connessione tra le istanze e i client Oracle GoldenGate

• Autenticare qualsiasi client o qualsiasi altra istanza di Oracle GoldenGate a qualsiasi altra istanza di Oracle GoldenGate configurata per comunicare tramite TLS.

Dopo aver stabilito TLS, l'istanza di Oracle GoldenGate dovrà autenticare il client per assicurarsi che disponga dei privilegi corretti per l'invio del trail. Vengono utilizzate le modalità di autenticazione indicate di seguito.

• L'istanza di Oracle GoldenGate eseguirà l'autenticazione del client utilizzando l'ID utente e la password con almeno il ruolo Operatore sul lato di destinazione. L'ID utente e la password vengono memorizzati come alias sul lato client. L'alias viene utilizzato durante la creazione del percorso di distribuzione.

  Fare riferimento alla sezione Connessione di due distribuzioni mediante un certificato RootCA esterno per informazioni sull'impostazione di un utente ruolo operatore, quindi utilizzare questo ID utente, alias password, quando si crea una connessione al percorso di distribuzione tra distribuzioni remote.

• L'istanza di Oracle GoldenGate utilizzerà il certificato client per autenticare la richiesta client, supponendo che esista un utente di certificato corrispondente creato sul lato di destinazione. Per i passi per la creazione di certificati per lato client e server, vedere Create Certificates for Secure Deployments.

• L'istanza di Oracle GoldenGate eseguirà l'autenticazione del client utilizzando OAuth quando utilizza un provider di identificazione esterno (IdP), ad esempio IAM. Vedere Delega la gestione utenti a un provider di identità esterno.

Suites di cifratura TLS

Una suite di cifratura specifica un algoritmo per ciascuna delle attività seguenti:

• Scambio di chiavi

• Cifratura di massa

• Codice di autorizzazione dei messaggi (MAC)

Sono supportate le suite di cifratura predefinite per TLS 1.2 e 1.3, ad eccezione delle cifrature deboli.

Oracle consiglia vivamente di utilizzare TLS 1.3 per soddisfare i requisiti di sicurezza.

Le suite di cifratura predefinite per TLS 1.2 sono supportate ad eccezione delle cifrature deboli.

Percorso avviato da destinazione

I percorsi avviati dalla destinazione per i microservizi consentono al servizio ricevente di avviare un percorso al servizio di distribuzione nei file di distribuzione e pull trail di destinazione. Questa funzione consente al servizio ricevente di creare un percorso avviato dalla destinazione per ambienti quali DMZ (Demilitarized Zone Paths) o DMZ (Cloud to on-premise), in cui il servizio di distribuzione nella distribuzione Oracle GoldenGate di origine non può aprire le connessioni di rete nell'ambiente di destinazione al servizio ricevente a causa dei criteri di sicurezza di rete.

Se il servizio di distribuzione non è in grado di avviare le connessioni al servizio ricevente, ma il servizio ricevente può avviare una connessione all'host su cui è in esecuzione il servizio di distribuzione, il servizio ricevente stabilisce un percorso sicuro o non sicuro avviato dalla destinazione al servizio di distribuzione tramite un firewall o una zona DMZ (demilitarized) utilizzando Oracle GoldenGate per estrarre i file trail richiesti. Gli endpoint del servizio ricevente indicano che il recupero dei file trail è stato avviato dal servizio ricevente.

Un percorso (di sola lettura) viene creato dal servizio ricevente della distribuzione di destinazione e ha la proprietà TARGET_INITIATED. Questo percorso è accessibile anche dal servizio di distribuzione. Le informazioni sul percorso vengono memorizzate nel sistema di destinazione. Se la comunicazione viene persa, il servizio ricevente sull'host di destinazione richiede la definizione del percorso per riavviare la connessione. Queste informazioni vengono condivise con il servizio di distribuzione quando il percorso è in esecuzione. Il percorso è effimero nella distribuzione di origine. I percorsi effimeri aiutano a consolidare la configurazione del percorso e a rafforzare l'avvio della connessione target-to-source.

Quando il percorso viene arrestato o disconnesso, il servizio di distribuzione rimuove tutte le informazioni sul percorso, inclusa la definizione del percorso. Tuttavia, il file di checkpoint viene conservato perché il checkpoint viene utilizzato per decidere se i vecchi trail possono essere rimossi o meno. Si consiglia di rimuovere i vecchi trail solo se il percorso viene eliminato intenzionalmente.

Argomenti correlati:

• L'autenticazione con i certificati

• Connessione di due distribuzioni mediante un certificato RootCA esterno

• Aggiungi percorso di distribuzione

Supporto proxy inverso di Oracle GoldenGate

Il proxy inverso consente di accedere ai microservizi utilizzando una singola porta (443) in una distribuzione. Ciò consente l'incapsulamento dell'URL per i microservizi su una distribuzione non sicura. Nota: il proxy inverso è facoltativo, tuttavia Oracle consiglia di garantire un accesso semplice ai microservizi e una maggiore sicurezza.

Puoi eseguire i microservizi in una distribuzione non sicura su un indirizzo di loopback e affrontarlo con un proxy inverso HTTP utilizzando l'installazione di Nginx.

Oracle GoldenGate MA include uno script denominato ReverseProxySettings che genera il file di configurazione solo per il server proxy inverso Nginx.

Ad esempio, il servizio di amministrazione è disponibile su http://goldengate.example.com:9001 e il servizio di distribuzione si trova su http://goldengate.example.com:9002. Con il proxy inverso, ognuno dei microservizi può essere semplicemente accessibile dal singolo indirizzo. Ad esempio, http://goldengate.example.com/distsrvr per il servizio di distribuzione. L'URL è diverso per ogni servizio ed è per nome anziché per porta.

Questi valori vengono utilizzati durante la connessione a Service Manager e sono necessari quando l'autenticazione è abilitata.

Vedere Configura proxy inverso Oracle GoldenGate con NGINX per l'implementazione del proxy inverso NGINX con Oracle GoldenGate.