Comunicazione sicura e veloce tra 2 VM

Se due macchine (virtuali o meno) devono essere fatte per comunicare tra loro, allora stabilendo una VPN tra di loro non può nuocere; per definizione, la VPN mira a emulare un insieme isolato di cavi tra i due host (quindi presumibilmente liberi da intercettazioni e interferenze ostili) in modo che il traffico arbitrario tra le due macchine diventi "sicuro". OpenVPN ha una buona reputazione ed è gratuito, quindi utilizzarlo non è una cattiva idea. In alternativa, se le applicazioni che devono comunicare tra loro in grado di gestire la propria sicurezza (ad esempio, SSL), allora questo è anche applicabile; la VPN, tuttavia, è probabilmente più semplice da configurare e più completa.

Come altri hanno detto, se le tue macchine sono VM, allora il cloud provider è Dio: se lo desidera, può tecnicamente vedere tutti i tuoi segreti e modificarli a piacimento. Il provider è quindi fidato . Quindi il provider non può essere un attaccante e deve essere assunto per non cadere sotto il controllo ostile. In queste condizioni, se il provider può impostare un "collegamento privato" tra le due macchine (una VLAN , in effetti), allora va bene. La sicurezza della VLAN è strong fintanto che i fili e i router effettivi della rete del provider sono puliti e onesti, che è, come ho appena scritto, un'ipotesi centrale del modello Cloud.

Ora, naturalmente, può esserci una sottile differenza tra "il fornitore di servizi è onesto" e "il fornitore di servizi è onesto e competente". Un piccolo errore di configurazione (il temuto errore umano ) può mettere sistemi di terze parti sulla VLAN. Anche in questo caso, l'esecuzione della propria VPN può aggiungere protezione contro i capricci del provider (non starebbe contro la malice del provider , ma l'incompetenza è molto più comune della malvagità).

Modifica: ho dimenticato l'argomento classico sulle prestazioni. Va così:

1. I problemi di rendimento non esistono.
2. I problemi di prestazioni non esistono fino a quando sono stati misurati .

Quindi, se temi i problemi di rendimento, allora l'unico modo corretto è provare e vedere se le paure erano giustificate o meno. Si possono fare stime a priori ma ciò richiede una conoscenza approfondita del comportamento degli algoritmi coinvolti e dei protocolli e delle latenze di rete; non si può realisticamente sperare di ottenere stime accurate e decenti a meno che non si sia altamente competenti in crittografia, programmazione interna e TCP / IP di basso livello. Provare e quantificare i problemi è un modo molto migliore; il più delle volte, i presunti problemi di prestazioni sono inesistenti (ma potrebbero apparire inaspettatamente altri problemi di prestazioni imprevedibili). Se vuoi fare benchmark su OpenVPN, dovresti prima leggere ciò che è già stato fatto sull'argomento, ovvero questa pagina .

Qual è il tuo modello di minaccia? Con cosa stai proteggendo? Dove si trovano le macchine virtuali?

Supponendo che le macchine virtuali in questione siano quelle che si ospitano sui computer che si possiedono al posto delle istanze cloud come EC2, la crittografia tra il server Web e il server di database è quasi sicuramente eccessiva. È possibile semplicemente collocare i server nella rete interna e consentire solo al server Web di interrogare il database. Certo, un attaccante che riesce a violare le difese e accedere alla rete interna può annusare il traffico, quindi dovrai pesare quella minaccia contro il costo della crittografia dei dati e decidere se ne vale la pena .