Utilizzo PKI in un cluster; per istanza dell'applicazione o per applicazione?

3

Ho un cluster con nodi (chiamiamoli A e B per l'esempio) che eseguono micro servizi identici (1, 2 e 3 - quindi l'applicazione 2 in esecuzione sul nodo A si chiama A2). Le applicazioni con gli stessi numeri sono completamente identiche.

Ogni istanza dell'applicazione (servizio micro) è accessibile tramite HTTPS.

Mi chiedo quale sia la procedura migliore per gestire il materiale PKI utilizzato per il connettore HTTPS delle applicazioni. Puoi dare alcune cose da considerare?

Sto considerando le seguenti configurazioni, ma non posso davvero decidere:

  • A1, A2, A3, B1, B2, B3 dovrebbero avere le proprie coppie di chiavi specifiche (per istanza dell'applicazione)
  • Le coppie A1 e B1, A2 e B2, A3 e B3 dovrebbero avere le loro coppie di chiavi condivise (per applicazione)

Ogni coppia di chiavi può essere firmata da una CA comune affidabile, quindi non è un problema qui.

    
posta nihilist84 11.06.2015 - 16:11
fonte

3 risposte

1

In generale, ogni chiave privata dovrebbe essere unica e le chiavi private non dovrebbero viaggiare.

Se si dispone di diverse "applicazioni" che prevedono connessioni HTTPS (sulla porta 443, handshake SSL / TLS ...) e che vengono eseguite sulla stessa macchina, l'applicazione non esegue effettivamente l'SSL. Il SSL è gestito dal frontend del server Web (ad esempio, un Apache o IIS): quel frontend esegue l'SSL, quindi (solo allora) riceve la richiesta HTTP, impara il percorso di destinazione e quindi sa a quale applicazione deve essere inviata la richiesta . In questo tipo di configurazione, la chiave privata e il certificato non sono di proprietà delle applicazioni, ma del frontend. In quel modello, si darebbe una chiave privata e un certificato per macchina .

Il paragrafo precedente presuppone che i "micro servizi" siano tutti registrati su un motore HTTP + SSL comune, come previsto se utilizzano tutti la porta HTTPS predefinita (443) e lo stesso indirizzo IP. potresti fare diversamente, ad es. eseguire i diversi servizi su porte distinte (l'URL di connessione dovrà quindi includere il nome della porta) o anche su indirizzi IP distinti (se ogni macchina possiede più indirizzi IP). In tal caso, ciascun micro servizio può eseguire il proprio motore HTTP + SSL e quindi avere il proprio certificato e la propria chiave privata.

Esistono due motivi principali per cui si desidera rendere più chiavi e certificati privati:

  • Si desidera fornire certificati a sistemi che non sono equivalenti tra loro in termini di sicurezza, ad es. appartengono a clienti distinti che non si fidano completamente (o non si conoscono) l'un l'altro. L'idea è che la conoscenza di una chiave privata utilizzata da un server consente (concettualmente) di impersonare quel server. Allo stesso modo, avere certificati distinti consente di revocarne uno senza revocare gli altri.

  • Le chiavi private che viaggiano sono "meno private". È meglio quando le chiavi private sono generate su una macchina e non lasciare mai la macchina. Quindi, se hai 10 server, vorrai avere (almeno) 10 chiavi private. Spostare le chiavi private in sicurezza è fattibile ma richiede attenzione (la copia delle connessioni SSH dovrebbe essere OK).

risposta data 11.06.2015 - 17:41
fonte
0

Per me ogni applicazione dovrebbe usare la propria coppia di chiavi. Poiché l'app su tutti i nodi del cluster è la stessa, deve esporla al client allo stesso modo.

Dall'altro lato non vedo alcun problema ad avere una coppia di chiavi per tutti i server e le applicazioni (se hanno qualcosa in comune, parte della grande applicazione, ecc.)

    
risposta data 11.06.2015 - 17:04
fonte
0

Un argomento che viene in mente è che spesso i progettisti vogliono che il cluster sia agnostico su quale nodo è connesso un utente; cioè l'utente ottiene lo stesso output indipendentemente da quale nodo ha eseguito l'elaborazione, le sessioni avviate su un nodo possono essere bilanciate su un altro nodo senza che l'utente lo sappia, ecc. Avere diversi certificati per ogni nodo lo impedirebbe.

    
risposta data 11.06.2015 - 17:07
fonte