2009/9/24 Claudio > > > Una cosa che usiamo qui è la "Transparent Data Encryption" di Oracle: > > http://www.oracle.com/technology/oramag/oracle/05-sep/o55security.html > > Sarà quel che sarà, ma io continuo a vedere questo genere di sistemi come più > un rischio (il "ricatto crittografico") che un reale vantaggio in termini di > sicurezza. Poi per carità, ci saranno anche situazioni dove serve...
Esatto, se ne discusse già tempo fa se non sbaglio. Si ricordi che vengono criptati pure tutti i backup e che se non lo vai a guardare esplicitamente, nessuno si accorge che il DB è stato criptato (devi fare una specifica query non penso che sia la prima cosa che un DBA faccia al mattino quando arriva ;-)) Nei fatti, un DBA può iniziare la criptazione, attendere sei mesi, fare shutdown del DB, scappare e ricattare l'azienda. Lui è l'unico che sa la password e può recuperare i backup - a meno che l'azienda non voglia perdere sei mesi di dati. Questo non vuol dire che non possa essere uno strumento utile (soprattutto a soddisfare certi specifici requirements di policy), ma va implementato con le necessarie "mitigations". Tornando alla domanda iniziale: qual è lo scopo per cui vuoi fare questo? a me per esempio sembra essere in genere molto più utile implementare una corretta security policy nella gestione del DB, imporre l'uso di certe view quando si fanno query via web (non risolve tutti i problemi ma aiuta), fare un pen-test dell'applicazione e se non basta, imporre un database-IDS che controllano le query mandate al DB e controllano il rispetto delle policy scelte (ce ne sono di specifici per esempio quello di Imperva). Cordiali saluti -- Marco Ermini r...@human # mount -t life -o ro /dev/dna /genetic/research http://www.linkedin.com/in/marcoermini "Jesus saves... but Buddha makes incremental back-ups!" ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
