Quanto è sicuro questo scenario di sicurezza saggio

2

In un progetto su cui sto lavorando, avevo bisogno di scrivere alcuni script di cron job, il cui scopo è di accedere ad alcune API esterne, che hanno informazioni che non dovrebbero essere accessibili al pubblico. Tutte le API esterne richiedono un nome utente e una password per renderle accessibili.

Il cliente era preoccupato che se qualcuno, in qualche modo, riuscisse a hackerare il server e memorizzassimo le password nei file di script per queste API, l'hacker avrebbe avuto accesso alle informazioni sicure o avrebbe potuto trasferire denaro da queste API per il proprio account.

Per risolvere questo problema, fondamentalmente, per creare un secondo livello di sicurezza sull'intera applicazione, pensavo che avrei potuto eliminare i lavori cron, scrivendo una semplice applicazione daemon, che una volta avviata, richiede una password all'amministratore. Con questa password, decifra le chiavi di accesso API e inizia a replicare le cose che i processi cron hanno fatto prima.

Il più grande svantaggio è che ogni volta che il demone si ferma per qualsiasi motivo, un amministratore DEVE riavviarlo manualmente, ma il mio cliente ha detto che questo non è un problema per lui.

Fondamentalmente, quello che vorrei sapere, è, quanto è sicuro questo approccio? Può un hacker, che riesce a penetrare nel server, recuperare la password di amministratore che è stata fornita al demone all'avvio, dalla memoria?

L'ambiente che utilizzo è PHP (so che questa non è la soluzione migliore per gli script daemon, ma il tempo è motivo di preoccupazione, e questo è stato il più veloce da implementare).

Quali altri svantaggi ha questo metodo, che non ho mai pensato?

    
posta Adam Baranyai 19.11.2017 - 12:51
fonte

2 risposte

3

Spostare la password in memoria aumenta il costo per l'attaccante, ma non di molto - e in cambio, il processo del server diventa effettivamente più fragile (richiede la presenza umana per il riavvio), che (come hai sottolineato) può influire negativamente sugli SLA.

La regola generale è che se un processo legittimo ha accesso alle informazioni, così fa l'attore delle minacce (se accedono all'ambiente del processo legittimo). Qualsiasi API implementata in questo modo richiede la password in chiaro.

Potrebbe essere necessario del lavoro per educare il tuo cliente a capirlo.

(Questa è la risposta di base alla tua domanda esplicita. Ecco alcune informazioni aggiuntive sul problema più grande che stai cercando di risolvere:)

Un'altra soluzione potrebbe essere quella di memorizzare parte del materiale in un HSM . Se implementato correttamente, ciò renderebbe ancora più difficile l'accesso. Ma anche in questo caso, se il server viene compromesso, un utente malintenzionato potrebbe scrivere codice aggiuntivo per intercettare la password mentre viene inviata all'API.

Un'altra opzione è quella di spostare la password su un server proxy più sicuro . Se non si ha la possibilità di bloccare il server corrente, ma è possibile creare un altro server che si potrebbe rendere notevolmente più sicuro, è possibile utilizzare quel server come proxy e memorizzare la password lì. Ciò aumenta la complessità, ma potrebbe valerne la pena se il server proxy può essere più rigido. Quel server proxy potrebbe anche essere utilizzato per monitorare le transazioni per attività insolite e bloccare quelle che non soddisfano determinati criteri.

Potresti anche lavorare con il provider API per limitare dove l'attività proviene a specifici indirizzi IP (in modo che l'attore delle minacce non possa semplicemente rubare la password e quindi usarla da qualsiasi luogo).

Se il lato server lo supportava, puoi anche utilizzare la crittografia a chiave pubblica per proteggere la password o un certificato SSL client per controllare chi può connettersi tramite TLS.

E in generale, dovresti utilizzare HTTPS per la connessione e utilizzare POST anziché GET per impedire che la password venga visualizzata negli URL nei log, ecc. Ciò contribuirà a proteggere la password in volo all'esterno del server.

Ma in tutti questi scenari, la password deve essere utilizzata in testo normale e sempre sarà vulnerabile all'intercettazione in qualche fase del flusso di lavoro.

    
risposta data 19.11.2017 - 18:02
fonte
1

Un concetto che provo spesso ad articolare con i clienti è principio sorgente pulito . Può essere molto efficace se si presuppone una violazione di un sistema e si lavora da lì, ma richiede anche che si comprenda la relazione di fiducia tra i sistemi e i loro elementi. Questo può essere più complesso di quanto molti immaginino.

    
risposta data 21.11.2017 - 05:24
fonte

Leggi altre domande sui tag