10.07.2015 Views

Pianificazione, installazione e configurazione di Host On-Demand

Pianificazione, installazione e configurazione di Host On-Demand

Pianificazione, installazione e configurazione di Host On-Demand

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

destinazione ed esegue un collegamento.La soluzione consigliata per un proxy Telnet consiste nell’utilizzare il LoadBalancer, una funzione degli Edge Components <strong>di</strong> WebSphere Application Serveroppure un prodotto simile che fornisce la conversione degli in<strong>di</strong>rizzi come partedella soluzione firewall globale invece <strong>di</strong> utilizzare il Re<strong>di</strong>rector <strong>di</strong> <strong>Host</strong><strong>On</strong>-<strong>Demand</strong>.Funzionamento del Re<strong>di</strong>rectorFigura 5 illustra come Re<strong>di</strong>rector invia i dati client al server Telnet ed invia al clienti dati <strong>di</strong> risposta dal server Telnet.Re<strong>di</strong>rector può essere configurato in uno dei seguenti quattro mo<strong>di</strong>:vPassthrough– Re<strong>di</strong>rector comunica con il server Telnet ed il client senza mo<strong>di</strong>ficare ilcontenuto dei dati.v Lato client– Il client e Re<strong>di</strong>rector comunicano in una sessione sicura utilizzando TLS o SSL(il contenuto è crittografato(decrittografato).– Re<strong>di</strong>rector ed il server Telnet comunicano in una sessione non sicura.v Lato hostv<strong>Host</strong><strong>On</strong>-<strong>Demand</strong>Client– Il client e Re<strong>di</strong>rector comunicano in una sessione non sicura.– Re<strong>di</strong>rector ed il server Telnet comunicano in una sessione sicura utilizzandoTLS o SSL (il contenuto è crittografato/decrittografato)EntrambiSSL/non-SSLPass-throughSSL/non-SSL9.24.105.229 9.24.104.93WTSCPOK1217323Figura 5. Come funziona il Re<strong>di</strong>rector<strong>Host</strong><strong>On</strong>-<strong>Demand</strong>ServerRe<strong>di</strong>rector– Il client e Re<strong>di</strong>rector comunicano in una sessione sicura utilizzando TLS o SSL(il contenuto è crittografato/decrittografato).– Re<strong>di</strong>rector ed il server Telnet comunicano in una sessione sicura utilizzandoTLS o SSL (il contenuto è crittografato/decrittografato).Prima <strong>di</strong> utilizzare i mo<strong>di</strong> Client, Server o Entrambi, occorre creare ilHODServerKeyDb.kdb per Re<strong>di</strong>rector.TelnetServerE’ possibile utilizzare il modo Pass-through quando la crittografia da parte <strong>di</strong>Re<strong>di</strong>rector non è necessaria, perché non occorre crittografare il flusso <strong>di</strong> dati operché il flusso <strong>di</strong> dati è già crittografato tra il client ed il server Telnet. E’necessario utilizzare il modo Pass-Through se il client <strong>Host</strong> <strong>On</strong>-<strong>Demand</strong> si connetteme<strong>di</strong>ante il Re<strong>di</strong>rector a un host che richiede l’autenticazione client o l’Accessorapido.Capitolo 5. <strong>Pianificazione</strong> per la sicurezza 47

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!