Secure comunicazione API RESTful tra più server

Naviga le tue risposte
3

Attualmente ho il seguente design:

  • Server ospitato nel cloud centrale con un'API REST
  • Più server remoti ciascuno con un'API REST

I dati vengono registrati dai server remoti al server centrale a intervalli regolari.

I comandi vengono inviati dal server centrale a singoli server remoti sotto forma di POST alla API REST in esecuzione sul server remoto.

Sono preoccupato per la sicurezza. La cosa più importante è impedire l'emissione di comandi non autorizzati ai server remoti.

Attualmente sto usando l'autenticazione basata su token. Ogni server remoto ha un token senza scadenza emesso dal server centrale che è memorizzato in un file di configurazione sul filesystem del server remoto. Questo token viene passato nell'intestazione di autorizzazione delle richieste POST provenienti dal server remoto.

L'altra direzione della comunicazione funziona in modo simile. Ogni server remoto genera un token per il server centrale che è archiviato in un database relazionale nella stessa rete del server cloud centrale.

I miei problemi con questo design:

  • Se il database è compromesso, l'utente malintenzionato può impartire comandi ai dispositivi remoti: essenzialmente sto memorizzando le password in formato testo nel db
  • Se il file system di un dispositivo remoto viene compromesso, l'utente malintenzionato accede al token

Quali sono i modi per migliorare questo progetto? La comunicazione dal server cloud centrale al dispositivo remoto non ha bisogno di essere una API REST. Sembra che quello di cui ho bisogno sia una specie di stretta di mano bidirezionale tra i due server. Come è possibile con una API REST?

Alcune note:

  • Entrambe le restanti apis vengono pubblicate su HTTPS
  • I dispositivi remoti spesso perdono la connettività Internet per periodi di tempo
  • I dispositivi remoti sono a rischio di essere rubati fisicamente

Alcune cose che ho considerato:

  • Potrei connettere tutti i server al database centrale ospitato e usarlo per la comunicazione. Questo non sembra ideale, perché questo sembra un rischio per la sicurezza di avere questi dispositivi remoti collegati direttamente al database. Inoltre, i server remoti spesso perdono la connettività.
  • Limita l'accesso ai server remoti a una whitelist di indirizzi IP incluso il server remoto centrale
posta Water Malone 06.02.2018 - 23:18
fonte

1 risposta

2

Poiché ti preoccupi principalmente della sicurezza del tuo programma (impedendo a qualcuno di inviare comandi ai tuoi clienti), devi anche identificare il tuo modello di minaccia. Ad esempio, se invii comandi a un programma per sbloccare la porta principale, il tuo approccio nel progettare l'applicazione diventa molto diverso rispetto a quando invii solo dati privi di significato come "ciao mondo!".

Una volta che lo hai definito, puoi prendere decisioni in merito all'opzione di hash una password nel tuo database e bloccare la chiave in una password sicura o in testo normale potrebbe funzionare per dati insignificanti. Proverò a parlare alla tua applicazione senza conoscere ogni singolo dettaglio.

Stai già utilizzando SSL / TLS, quindi è un ottimo inizio. Hai implementato una forma di autenticazione, un modo per i clienti di dimostrare al server che sono legittimi. Hai il controllo fisico sugli host, quindi presumo che nessuno possa avere accesso fisico. Se si dispone di IP statici, assicurarsi di inserire una whitelist e un firewall possibile per limitare determinati metodi http (GET, POST). Potresti considerare un proxy front-end come Nginx per fare tutto questo sul server. Suggerisco caldamente di non consentire ai client una connessione pulita al database. Consenti solo al server di effettuare connessioni al database. Hai detto che stai memorizzando le password nel database, perché non hash / sale? Di nuovo, dipende dal tuo modello di minaccia.

Hai detto che le macchine client sono sotto il tuo accesso fisico ma potrebbero essere rubate. Se un attaccante ha accesso fisico a una scatola, tutte le scommesse sono disattivate. La tua migliore scommessa qui sarebbe identificare il più rapidamente possibile che un cliente è compromesso. Stai già utilizzando token, perché non hai un tempo di scadenza

Infine, tutti i dati inviati dai client al tuo server devono, devono, devono essere disinfettati e controllati. Se hai un'idea di come sono i dati, imposta un modello e tutti i dati ricevuti che non lo corrispondono, rifiutalo

    
risposta data 07.02.2018 - 03:08
fonte

Leggi altre domande sui tag

È pericoloso installare il certificato 802.1x del mio lavoro? [duplicare] Memorizzazione delle chiavi di crittografia [chiuso]