Protezione delle credenziali del database in un campo distribuito Raspberry Pi

1

Un raspberry pi è schierato in un'area pubblica. Non sono così preoccupato per il furto fisico del Raspberry Pi: sono preoccupato che il dispositivo venga rubato, la scheda SD verrà letta e le credenziali del database AWS (nome utente / password in script python) saranno "in the wild".

Esistono pratiche di sicurezza efficaci in grado di mitigare questo rischio?

AGGIORNAMENTO: Ogni tentativo ragionevole sarà fatto per proteggere fisicamente il dispositivo (chiuso in una scatola), tuttavia, le probabilità di furto non sono zero.

    
posta gatorback 06.07.2018 - 23:30
fonte

2 risposte

4

Per prima cosa ... l'accesso fisico è l'accesso root . Se qualcuno può toccare fisicamente il tuo dispositivo, non è più il tuo dispositivo.

A parte ciò, cosa puoi fare per limitare la minaccia?

  • Blocca l'accesso all'AWS all'IP specifico (possibilmente anche sicurezza del porto se possibile) ... in questo modo anche se qualcuno ruba i crediti dallo script python non può fare nulla senza usare la stessa connessione in cui era originariamente.
  • Blocca l'utente DB al minimo accesso in lettura / scrittura richiesto dallo script, in modo che se qualcuno ottiene l'accesso non può scaricare l'intero database e / o eliminare le tabelle. (vedi anche Trigger del database )
  • Scrivi un wrapper API remoto attorno all'accesso Database (vedi anche redis pub / sub ) in modo che l'RPi possa solo eseguire comandi consentita dall'API e registra in remoto tutte le richieste API valide & male.
  • Distribuisci in remoto il codice solo sulla memoria. Se si imposta un bootstrap per estrarre il codice su un'unità ram (consultare anche loop0 ), eseguirlo ed eliminare la copia locale ... dovrebbe essere accessibile solo se il ladro può rubarlo mantenendo il potere.

Ancora una volta, non puoi proteggere completamente la tua AWS, ma puoi rafforzarla e guadagnare tempo per invalidare la chiave utente o API associata all'Ri. Assicurati di controllare regolarmente i log per attività nefaste.

    
risposta data 07.07.2018 - 01:30
fonte
1

Ho convenuto che l'accesso fisico è sbagliato, ma ci sono alcune cose che puoi fare, che almeno ritarderanno l'aggressore abbastanza a lungo da farti notare che il PI manca e cambiare le credenziali sul DB.

Prima di tutto, è ovvio che è necessario proteggere fisicamente il Pi e accertarsi di disporre di sistemi che notino la mancanza al più presto possibile. Ispezione fisica quotidiana - e forse forse uno script remoto per verificare se il Pi è ancora connesso alla rete che viene eseguito ogni 20-30 minuti. Se il Pi è disconnesso dalla rete, lo script ti avvisa e ora puoi agire su di esso.

Prova a verificare che ci sia la crittografia completa del disco sul Pi. Non sono un esperto di Raspbian o qualsiasi sistema operativo in uso, ma una crittografia del disco implementata correttamente, almeno rallenta l'aggressore, o al limite li ferma nelle loro tracce.

A seconda del DB, prova ad utilizzare il gestore segreti di AWS. In questa configurazione, tutto ciò che hai sul Pi è un'impostazione della chiave API AWS per IAM USER non root con autorizzazioni molto limitate. La chiamata API restituisce le credenziali del database che puoi utilizzare. La magia è che, non solo puoi disabilitare la chiave API con un clic / comando, puoi anche ruotare i segreti del database senza toccare la tua applicazione. Ciò ti offre una flessibilità molto più semplice per impedire l'accesso una volta che il Pi viene scoperto mancante.

Riguarda la difesa in profondità. L'attaccante deve rimuovere fisicamente la scheda SD sul tuo Pi (o rubare il Pi completamente), ignorare l'FDE, e quindi ignorare la password del sistema operativo, e poi tutti hanno la chiave del database-- che si spera che tu abbia già disabilitato da allora.

Il gestore dei segreti costa $ 0,50 / segreto al mese e non dovrebbe essere troppo difficile da implementare tramite Boto3 (defauly Python SDK per AWS). Se stai eseguendo qualcosa come DynamoDB, probabilmente puoi vivere senza, semplicemente disabilitando l'utente IAM (o la sua chiave API) che ha accesso al DB.

    
risposta data 10.07.2018 - 06:46
fonte

Leggi altre domande sui tag