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.