Nodo SSL (Secure Sockets Layer), server delle applicazioni e isolamento cluster

Il protocollo Secure Sockets Layer ( SSL ) consente di garantire che qualsiasi client che tenti di connettersi a un server durante l'handshake esegua prima l'autenticazione del server. Utilizzando le configurazioni di SSL a livello di nodo, server delle applicazioni e cluster, è possibile isolare la comunicazione tra server che non devono comunicare tra loro tramite porte sicure.

Prima di tentare di isolare le comunicazioni controllate da WebSphere® Application Server, è necessario avere una buona conoscenza della topologia di distribuzione e dell'ambiente dell'applicazione. Per isolare un nodo, un server applicazioni o un cluster, è necessario essere in grado di controllare i firmatari contenuti negli archivi di fiducia associati alla configurazione dell' SSL. Quando il client non contiene il firmatario del server, non può stabilire una connessione al server. Per impostazione predefinita, WebSphere utilizza certificati concatenati e ogni nodo ha un firmatario di certificati root unico. Poiché il nodo condivide lo stesso firmatario root, tutti i server in tale nodo possono connettersi tra loro perché condividono lo stesso firmatario root. Tuttavia, se si utilizzano certificati autofirmati, il server che ha creato il certificato personale controlla il firmatario, anche se è necessario gestire i certificati autofirmati. Se si ottengono certificati da una CA (Certificate Authority), è necessario ottenere più firmatari CA poiché tutti i server possono connettersi tra loro se condividono lo stesso firmatario.

l'autenticazione solo del lato server di una connessione non è una protezione adeguata quando è necessario isolare un server. Qualsiasi client può ottenere un certificato del firmatario per il server e aggiungerlo al relativo truststore. SSL L'autenticazione client deve essere abilitata anche tra i server, in modo che il server possa controllare le proprie connessioni decidendo quali certificati client considerare affidabili. Per ulteriori informazioni, vedere Abilitazione dell'autenticazione client Secure Sockets Layer per un endpoint in entrata specifico, che si applica anche all'abilitazione dell'autenticazione client SSL a livello di cella.

L'isolamento richiede inoltre l'utilizzo di configurazioni di gestione centralizzata ( SSL ) per tutti o quasi tutti gli endpoint della cella. Le configurazioni gestite centralmente possono essere definite in base all'ambito, a differenza della selezione diretta o dell'endpoint, e consentono di creare configurazioni dell' SSL, archivi di chiavi e archivi di fiducia in un ambito specifico. A causa della gerarchia di ereditarietà delle celle di WebSphere Application Server, se si selezionano solo le proprietà necessarie per una configurazione di SSL, solo queste proprietà vengono definite nell'ambito selezionato o in quelli inferiori. Ad esempio, se si configura nell'ambito del nodo, la configurazione si applica agli ambiti del server delle applicazioni e del singolo endpoint che seguono l'ambito del nodo. Per ulteriori informazioni, vedere Associazione centralizzata delle configurazioni Secure Sockets Layer con ambiti in entrata e in uscita, Selezione di un alias di configurazione SSL direttamente da una configurazione endpoint e Associazione dinamica di una configurazione Secure Sockets Layer con un protocollo in uscita e un endpoint remoto sicuro

Quando si configurano gli archivi delle chiavi, che contengono le chiavi crittografiche, è necessario operare allo stesso livello in cui si definisce la configurazione dell' SSL, e non a un livello superiore. Ad esempio, se si crea un keystore che contiene un certificato il cui nome host fa parte del DN (distinguished name), memorizzare tale keystore nella directory del nodo del repository di configurazione. Se si decide di creare un certificato per il server delle applicazioni, memorizzare tale keystore sul server delle applicazioni nella directory del server delle applicazioni.

Quando si configurano i truststore, che controllano le decisioni di trust sul server, è necessario considerare quanto si desidera isolare i server delle applicazioni. Non è possibile isolare i server delle applicazioni dagli agent del nodo o dal gestore distribuzione. Tuttavia, è possibile configurare gli endpoint del connettore SOAP con lo stesso certificato personale o per condividere l'attendibilità. La persistenza della denominazione richiede connessioni IIOP quando passano attraverso il gestore distribuzione. Poich ' i server delle applicazioni si collegano sempre agli agenti nodo quando il server viene avviato, il protocollo IIOP richiede che WebSphere Application Server stabilisca l'affidabilit ... tra i server delle applicazioni e gli agenti nodo.

Creazione dell'isolamento dell' SSL e dei nodi

Per impostazione predefinita, l'installazione di WebSphere Application Server utilizza un singolo certificato concatenato per ciascun nodo, in modo da poter isolare facilmente i nodi. Un truststore comune, che si trova nella directory della cella del repository di configurazione, contiene tutti i firmatari per ogni nodo federato nella cella. Dopo la federazione, ogni processo cellulare si fida di tutti gli altri processi cellulari perché ogni configurazione dell' SSL e fa riferimento all'archivio di fiducia comune.

È possibile modificare la configurazione predefinita in modo tale che ciascun nodo abbia il proprio truststore e ogni server delle applicazioni sul nodo considera attendibile solo l'agente nodo che utilizza lo stesso certificato personale. È inoltre necessario aggiungere il firmatario al truststore del nodo in modo che WebSphere Application Server possa stabilire il trust con il gestore distribuzione. Per isolare il nodo, verificare che siano soddisfatte le condizioni riportate di seguito:

• Il gestore distribuzione deve avviare le connessioni a qualsiasi processo
• L'agent del nodo deve avviare le connessioni al gestore distribuzione e ai propri server delle applicazioni
• I server delle applicazioni devono avviare le connessioni ai server delle applicazioni sullo stesso nodo, al proprio agente nodo e al gestore distribuzione

La Figura 1 mostra l'agent del nodo A contiene un keystore key.p12 e un truststore trust.p12 a livello di nodo del repository di configurazione per il nodo A.

Quando si associa una configurazione SSL a questo archivio chiavi e archivio certificati, si interrompe il collegamento con l'archivio certificati a livello di cella. Per isolare completamente il nodo, ripetere questo processo per ciascun nodo nella cella. WebSphere Application Server SSL Le configurazioni sostituiscono l'ambito della cella e utilizzano invece l'ambito del nodo, in modo che ogni processo in questo ambito utilizzi la configurazione dell' SSL e l'alias del certificato selezionati in questo ambito. È possibile stabilire un trust amministrativo corretto assicurandosi che il firmatario nodeA sia presente nell'archivio trust comune e che il firmatario della cella sia presente nell'archivio trust nodeA. La stessa logica si applica anche al nodo B. Per ulteriori informazioni, consultare Associazione centralizzata delle configurazioni SSL (Secure Sockets Layer) con gli ambiti in entrata e in uscita.

Creazione dell'isolamento dell' SSL e del server delle applicazioni

Isolare i processi del server delle applicazioni l'uno dall'altro è più impegnativo che isolare i nodi. È necessario considerare le seguenti condizioni di progettazione e topologia dell'applicazione:

• È possibile che un processo del server delle applicazioni debba comunicare con l'agent del nodo e il gestore distribuzione
• L'isolamento dei processi del server delle applicazioni potrebbe disabilitare le funzioni SSO (single sign - on) per la propagazione orizzontale

Se si configurano dinamicamente le impostazioni di uscita dell' SSL, è possibile soddisfare queste condizioni. Quando si definisce un protocollo in uscita specifico, un host di destinazione e una porta per ciascuna configurazione dell' SSL, è possibile sovrascrivere la configurazione con ambito.

La Figura 2 mostra come isolare completamente un server delle applicazioni, sebbene in pratica questo approccio sia più complicato.

La configurazione dinamica abilita server1 sul Nodo A a comunicare con il server 1 sul Nodo B solo su IIOP. La regola dinamica in uscita è IIOP,nodeBhostname,*. Per ulteriori informazioni, consultare Associazione dinamica di una configurazione SSL (Secure Sockets Layer) con un protocollo in uscita e un endpoint sicuro remoto

Creazione dell'isolamento dell' SSL e del cluster

È possibile configurare i server delle applicazioni in cluster invece di definirne l'ambito centralmente a livello di nodo o dinamicamente a livello di server per stabilire l'isolamento dell' SSL e del cluster. Mentre i server con cluster possono comunicare tra loro, i server delle applicazioni esterni al cluster non possono comunicare con il cluster, isolando quindi i server con cluster. Ad esempio, potrebbe essere necessario separare le applicazioni da dipartimenti differenti, mantenendo un livello di attendibilità di base tra i server con cluster. Utilizzando il metodo di configurazione dinamica in uscita SSL descritto in precedenza per i server, è possibile estendere facilmente il cluster isolato in base alle esigenze.

La figura 3 mostra una configurazione cluster di esempio in cui il cluster 1 contiene un key.p12 con il proprio certificato autofirmato e un trust.p12 che si trova nella directory config/cells/ < cellname> /clusters/ < clustername>.

Nell'esempio, cluster1 potrebbe contenere applicazioni Web e cluster2 potrebbe contenere applicazioni EJB. Considerando i diversi protocolli, si decide di abilitare il traffico IIOP tra i due cluster. Il tuo compito è definire una configurazione dinamica dell' SSL e in uscita nell'ambito dell' cluster1 con le seguenti proprietà:

IIOP,nodeAhostname,9403|IIOP,nodeAhostname,9404|IIOP,nodeBhostname,9403|IIOP,nodeBhostname,9404

È necessario creare un'altra configurazione SSL nell'ambito cluster1 che contenga un nuovo file trust.p12 con il firmatario cluster2. Di conseguenza, le richieste IIOP in uscita vengono indirizzate alle porte 9403 e 9404 di nodeAhostname oppure alle porte 9403 e 9404 di nodeBhostname. I numeri di porta IIOP SSL su questi due processi del server delle applicazioni in cluster2 identificano le porte.

Quando si esamina la Figura 3, notare le seguenti funzioni della configurazione di isolamento cluster:

• trust.p12 per cluster1 contiene i firmatari che consentono le comunicazioni con se stesso (firmatariocluster1 ), tra gli agenti nodo (nodeAsigner e nodeBsigner) e con il gestore distribuzione (firmatario cella).
• trust.p12 per cluster2 contiene i firmatari che consentono le comunicazioni con se stesso (firmatariocluster2 ), tra entrambi gli agent del nodo (nodeAsigner e nodeBsigner) e con il gestore distribuzione (firmatario cella).
• L'agente nodo A e l'agente nodo B possono comunicare con se stessi, con il gestore distribuzione ed entrambi i cluster.

Per ulteriori informazioni, consultare Associazione dinamica di una configurazione SSL (Secure Sockets Layer) con un protocollo in uscita e un endpoint sicuro remoto .

Sebbene venga presentata una panoramica dei metodi di isolamento dal punto di vista dell' SSL, è necessario assicurarsi che le porte non SSL siano chiuse o che le applicazioni richiedano il vincolo di riservatezza nel descrittore di distribuzione. Ad esempio, è possibile impostare il pannello di trasporto in entrata dell' CSIv2 e in modo da richiedere SSL e disabilitare le porte del canale che non sono sicure dalla configurazione delle porte del server.

Inoltre, è necessario abilitare l'autenticazione client SSL per SSL al fine di applicare i requisiti di isolamento su entrambi i lati di una connessione. Senza l'autenticazione reciproca del client tramite SSL, un client può facilmente ottenere un firmatario per il server a livello di programmazione, aggirando così l'obiettivo dell'isolamento. Con l'autenticazione client " SSL ", il server richiederebbe il firmatario del client affinché la connessione abbia esito positivo. Per il protocollo HTTP /S, il client è in genere un browser, un servizio web o una connessione URL. Per il protocollo IIOP/S, il client è generalmente un altro server delle applicazioni o un client Java™ . WebSphere Application Server è necessario conoscere i client per determinare se è possibile abilitare l'autenticazione client SSL. Le applicazioni disponibili tramite un protocollo pubblico non devono abilitare l'autenticazione client SSL, poiché il client potrebbe non riuscire a ottenere un certificato per l'autenticazione al server.

Nota: è oltre l'ambito di questo argomento per descrivere tutti i fattori che è necessario considerare per ottenere un isolamento completo.