Se l'utente malintenzionato ha accesso completo sul server del database E ha accesso al server che decodifica i dati persi con uno di questi sistemi di database. Ho sentito parlare di mainframe e sistemi personalizzati in cui il database è integrato nel sistema operativo e non si ottiene alcun vero accesso amministrativo, ma anche per chi un aggressore con privilegi sufficientemente elevati può tipicamente impostare i limiti di lettura abbastanza alti da leggere l'intero database riga per riga e nulla fuori dallo scaffale sotto 100.000 USD all'anno.
Nel tuo caso con SQLite con SQLcipher dovrai memorizzare la decrittografia da qualche parte e poiché con SQLite è tipicamente il server delle applicazioni, l'hacker in genere ha solo bisogno di accedere con i diritti dell'applicazione / server web per ottenere tutti i dati. Altri sistemi di database forniscono funzionalità simili come menzionate sotto , ma potrebbero essere disponibili solo in alcune edizioni come per Microsoft SQL Server nelle edizioni Enterprise e Datacenter.
Modi per rendere più difficile l'attacco:
- Indurire il server (mantenere aggiornato il software, firewall, impostazioni sicure per le applicazioni, limitare l'accesso (di manutenzione) a determinati intervalli di indirizzi ip, pentesting, non eseguire servizi come admin, limitazione di velocità, ... )
- Non memorizzare i dati che non è necessario o in un modulo non necessario (nessuna password in chiaro, a volte non è necessario il nome di una persona per l'elaborazione ma solo identificatori univoci, ... )
- Crittografia del database: alcuni database forniscono diverse opzioni di crittografia del database come l'intero database, le tabelle, le colonne per esempio vedi qui . Attenzione, questo potrebbe significare una grande riduzione delle prestazioni. Ciò fa sì che l'hacker abbia anche bisogno della chiave di crittografia, ma se ha accesso completo sul server del database può anche annusare la chiave inviata al server di database tranne nel caso di Crittografia lato client, ma in tal caso avrebbe solo bisogno di un accesso sufficiente al server che accede al database.
- Limitazione della superficie di attacco: è possibile inserire dati più sensibili su server separati con verifiche di sicurezza migliori. Ad esempio per i nomi utente e le password è possibile utilizzare un server separato con un singolo webservice con le funzioni "Controlla password per id utente", "Aggiungi password per id utente", "Rimuovi password per ID utente" e un server di database aggiuntivo per quelli dati che accettano solo le connessioni da questo server. Poiché ha meno funzionalità / codice, è più facile da controllare e ha meno superficie di attacco.
Ovviamente avrai bisogno anche di altre misure di sicurezza non menzionate nel tuo vettore di attacco come l'accesso fisico al server, la crittografia dei dischi rigidi / backup, ...