Scelta tra SSH e HTTPS per l'esecuzione di script utilizzando McAfee ESM Nitro

Question

Scelta tra SSH e HTTPS per l'esecuzione di script utilizzando McAfee ESM Nitro

#1 da (1 voti)
#2 da (1 voti)

2

Intendiamo utilizzare McAfee ESM Nitro (SIEM) per il monitoraggio della sicurezza dei nostri server di infrastruttura. Per portare l'automazione nell'amministrazione di sistema dei nostri server, abbiamo sviluppato alcune applicazioni in-house.

Ad esempio, stiamo utilizzando uno strumento di terze parti per l'automazione automatica dei sistemi, che è Ansible e disponiamo di un'applicazione interna che controlla quale server rimane in produzione o chi spedire fuori produzione.

Ora intendiamo integrare McAfee ESM Nitro con queste due applicazioni. In questo modo, ogni volta che viene generato un avviso di minaccia tramite Nitro, è necessario utilizzare Ansible o la nostra applicazione interna per eseguire i passaggi di risoluzione o bloccare il sistema dal nostro ambiente di produzione.

Nitro offre due opzioni per l'attivazione di tali azioni rispetto a qualsiasi avviso. Per collegarsi in remoto a un server tramite SSH ed eseguire qualsiasi script che risiede su quel server o eseguire lo script tramite qualsiasi URL su HTTPS. Si prega di trovare l'istantanea allegata per entrambe le opzioni.

Ho letto il thread su questo sito web in cui viene discusso il confronto tra SSH e HTTP ( Qual è la differenza tra SSL vs SSH? Quale è più sicuro? )

Vorrei chiedere il tuo parere professionale su quale opzione si adatta e che è più sicuro.

Grazie, Fahad. Opzione URL di sfondo SIEM

cryptography ssh tls siem

posta user29752 10.12.2015 - 09:36

fonte

2 risposte

Leggi altre domande sui tag cryptography ssh tls siem

Infrastruttura per l'analisi degli incidenti Spostamento dei file infetti nel cestino rispetto alla messa in quarantena

score 1 · Answer 1

Dipende molto dall'aspetto della tua infrastruttura e da quanto tempo e denaro vuoi investire (o hai già investito) nella tua infrastruttura di sicurezza.

Da un lato, SSH è facile da implementare, richiede l'autenticazione di default (quindi meno spazio per errori) e può essere reso abbastanza sicuro molto facilmente. Lo svantaggio è che l'aspetto della sicurezza non si adatta troppo bene: la gestione delle chiavi in un ambiente più grande è complicata e il fallback di default (accetta qualsiasi chiave dal server) non è sicuro. Anche la gestione delle chiavi del client è un problema.

D'altro canto, è necessario uno sforzo maggiore per implementare HTTPS in modo sicuro e avere lo stesso livello di sicurezza di quello che si otterrebbe da SSH (supponendo che si stia utilizzando l'autenticazione basata su chiave). Il vantaggio è che è più semplice scalare: puoi usare un PKI privato per gestire facilmente le chiavi e, una volta che hai una configurazione funzionante, è molto, molto facile da replicare in modo sicuro su tutti i sistemi che vuoi.

score 1 · Answer 2

Personalmente vorrei andare con HTTPS (TLS) per i seguenti motivi:

Un sistema basato su avvisi / messaggi è molto più adatto per un protocollo come HTTP.
È possibile impostare un'autorità di certificazione (PKI) per gestire l'autenticazione come funzionalità richiesta di TLS.
È possibile utilizzare certificati autofirmati per la sicurezza equivalenti a SSH, che possono essere successivamente aggiornati a un sistema PKI legittimo.
È possibile utilizzare una tecnologia basata sul web preesistente ed estremamente potente, Node.js, per gestire direttamente le comunicazioni in entrata ed eseguire tutte le operazioni interne necessarie. Può agire sia come server sia come client tramite HTTPS.
Le connessioni SSH di solito finiscono per dare più accesso al computer di destinazione di quanto sia necessario per portare a termine un compito, perché le applicazioni che implementano SSH sono generalmente in grado di eseguire un ampio insieme di attività. La creazione di un server SSH personalizzato non è così semplice come lo è creare un server HTTP personalizzato con lo stesso livello limitato di autorizzazioni disponibili per l'applicazione di connessione.