Avere più JRE su un sistema non è di per sé un rischio, ma è presente il rischio che possano essere invocati da codice non attendibile.
Quindi è probabile che la chiave di questa configurazione sia garantire che i JRE obsoleti possano essere richiamati solo dall'applicazione a cui è necessario e non da un codice non affidabile.
Esattamente come si ottiene ciò dipende dall'applicazione che è necessario consentire l'uso di. Se si tratta di un'app client spessa, installare il JRE obsoleto nella home directory delle applicazioni e assicurarsi che eventuali variabili di ambiente (come JAVA_HOME) che indirizzano programmi a JRE specifici non puntino a questo sarebbe di aiuto.
L'elemento più critico in termini di rischio probabile è garantire che il plug-in del browser Java per la versione vulnerabile non sia esposto a Internet. C'è un gran numero di siti / exploit dannosi che possono attaccare quella debolezza, quindi è da evitare.
Se la tua app aziendale. ha bisogno del plugin del browser Java, quindi le cose diventano più difficili da fare con meno rischi. Qui direi che le tue scelte sono sia per garantire che il browser con il plugin Java obsoleto sia utilizzabile solo per accedere all'applicazione legacy (ad esempio, forzare un proxy e impostarlo su uno che non può accedere a siti basati su Internet), o per fornire un ambiente virtuale con il plugin per browser / Java reso disponibile e di nuovo assicurarsi che l'ambiente non possa accedere a Internet.
Con ognuna di queste soluzioni c'è ancora il rischio che un aggressore trovi un modo per invocare il JRE vulnerabile, ma limitando l'uso di esso, puoi ridurre il livello di rischio.