Il 23 aprile 2010 16.58, Giuseppe "Gippa" Paterno' <[email protected]> ha scritto: > Ciao! > > Premesso che non sono un programmatore (leggo e scrivo accozzaglia di > codice :) e che non sono un DBA, mi permetto di dire la mia.
Io sviluppicchio abbastanza ma non sono un DBA... > > Anche se in teoria usare API sul DB per permettere la crittografia > potrebbe risultare simpatico, questo IMHO porta due problemi. Da un lato > la possibilita' di non avere un vendor lock-in sui dati del DB, ovvero > se si usano le API del DB sara' piu' difficile poter astrarre codice e > dati da quel determinato vendor di RDBMS. L'altro che l'uso di un Vero, ma se ti affidi ad un DBMS blasonato, nessuno ti obietterà sulla soluzione di cifratura. Altrimenti dovrai spiegare riga per riga il tuo codice e allora sì che son dolori....e ti devi augurare che tutto funzioni! Intendiamoci: mica devi per forza affidarti a Oracle. Magari Postgres, ma reinventare la ruota no. > eventuale ORM, ad esempio hibernate (Java) o ActiveRecord (Ruby), ci > permette di astrarre il codice dalla implementazione del DB, ma penso > che ci introduca non poche difficolta' se vogliamo usare query SQL > sepcifiche. Da quello che sto vedendo ultimamente, basandomi solo sulla Non sono query specifiche, sono colonne di tabelle o tabelle cifrate dallo stesso DBMS e in modo trasparente. Certo che se l'ORM non mappa però alcune API la vedo difficile. Ma se non ricordo male anche con Hibernate avevi la possibilità di eseguire "classiche" SQL! > esperienza personale, c'e' un certo proliferarsi di webapp che usino > hibernate (o altri ORM) e personalmente lo trovo alquanto utile. > > Appoggio in pieno quello che dice Alor, cioe' l'uso di un sistema > "pgp-like" per criptare la chiave simmetrica (K). La chiave K pero' deve > essere ricodificata in caso l'utente cambi password, ma introduce nuove > problematiche con eventuali sistemi di Web-SSO (es: Sitemider, Yale CAS). > > La cosa ideale IMHO e' quello che dice Fausto, cioe' l'uso del device > crittografico che ha un utente (smartcard). Al momento pero' non mi > risultano che esista nessun modo per "decodificare" in remoto, ovvero il > fatto che via web posso demandare l'utente finale a decriptarmi un dato > temporaneo via X.509. In realta' sto lavorando anche in questo senso, ma > non penso ci siano implementazioni commerciali o OSS (ben felice di > essere smentito pero'! :). La cifratura la puoi fare sia con una chiave pubblica PGP che con una chiave pubblica RSA su Smartcard o USB o dove vuoi....non cambia molto. Certamente la chiave privata è più al sicuro in una smartcard che in un file. Puoi disaccoppiare le credenziali di autenticazione da quelle per la cifratura, etc.. L'importante è che il dato cifrato dalla chiave pubblica (PGP o RSA) non sia il dato nel DB ma la chiave simmetrica di cifratura. Questo permette a diversi utenti di decifrare lo stesso dato. Poi se vogliamo dirla tutta puoi anche utilizzare dispositivi PKCS#11 per lo store di chiavi di cfratura, come HSM e robe simili. > > Ritornando con i piedi per terra penso che dovresti criptare i risultati > dei dati sensibili con una chiave simmetrica random, che sia essa > "unlockata" per ogni utente (cosa migliore, see Alor), oppure run-time > in qualche maniera sicura dall'applicativo in maniera simile a quanto > avviene per la crittografia dei dischi (es: truecrypt o luks). Per le > implementazioni Java IMHO e' molto interessante Bouncy Castle [1], che > implementa anche OpenPGP in Java senza bisogno di appoggiarsi a GPG/PGP > command line (come fanno in python/ruby tramite GPGME). Yes molto interessanti. Comunque rimango della mia. Per la cifratura, evita di farla tu applicativamente: i motivi per cui può fallire sono tanti ed il software che realizzi deve essere a prova di bomba. Affidati alle API del DBMS. Tanto poi il vero lavoro è costruire il layer sopra! Non ti scordare che ci sono pur sempre le macchine fotografiche per "rubare" un dato sensibile dal video, o le solite stampe che all'inizio l'utente non vuole, poi non si sa perché cambia idea e magari anche con il dato sensibile stampato sopra. E quindi cominci a stampare il nome dell'utente con il time-stamp, e via dicendo. Ovviamente IMHO :) > > Ciao ciao, > Gippa > > [1] http://www.bouncycastle.org/ > > ________________________________________________________ > http://www.sikurezza.org - Italian Security Mailing List > ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
