[ franjo_tahi @ 27.12.2010. 11:04 ] @
Koja je mogućnost da se kriptiraju podaci unutar fb-a?
Problem je kako sakriti podatke, učiniti ih nepristupačnima ako se kopira baza. U situaciji sam da ne mogu spriječiti pristup serveru.
Da li možda UDF?
Funkcija bi trebala biti dovoljno brza da bitno ne uspori pristup podacima, ali bi morala isto tako podržavati ODRDER. Znači da bi kriptirani podaci morali zadržati isti odnos vrijednosti. Budući da je funkcija dostupna svima, kako spriječiti neovlaštenu upotrebu? Možda temp tablica (budući da se iz nje ne mogu učitati podaci iz druge transakcije) u koju program upisuje ključ, a funkcija čita podatak i njime kriptira/dekriptira podatke?

Bilo kakove ideje i mišljenje o ovom su dobrodošle, a iskustva pogotovo (a tek primjeri :) ).
[ rambo @ 27.12.2010. 12:09 ] @
Za enkripciju podataka na strani servera trenutno nemam nikakvu ideju, ali zato možeš da enkriptuješ podatke na klijentu. Za to koristiš TDataSetProvider i TClientDataSet. Koristeći evente koje imaš na provajderu možeš da enkrpituješ/dekriptuješ podatke pre nego što ih upišeš/pročitaš. Na taj način ćeš u bazi uvek imati enkriptovane podatke a na klijentu ih dekriptuješ i u TClientDataSet radiš sa njima šta hoćeš (to podrazumeva i promenu ORDERa).

Postoje na internetu primeri za ovo a postoji i knjiga koja se bavi dbExpress komponentama, uključujući i TDataSetProvider i TClientDataSet. Ako ne uspeš da nađeš sam, reci pa ću napisati nešto više.
[ franjo_tahi @ 28.12.2010. 08:35 ] @
Do sada nisam radio s TDataSetProvider i TClientDataSet. Može u kratkim crtama zašto njih i što time dobivam?
Zar ne mogu isto i s TIBDataset?
[ MarkoBalkan @ 29.12.2010. 19:27 ] @
Citat:
franjo_tahi: Koja je mogućnost da se kriptiraju podaci unutar fb-a?
Problem je kako sakriti podatke, učiniti ih nepristupačnima ako se kopira baza. U situaciji sam da ne mogu spriječiti pristup serveru.
Da li možda UDF?
Funkcija bi trebala biti dovoljno brza da bitno ne uspori pristup podacima, ali bi morala isto tako podržavati ODRDER. Znači da bi kriptirani podaci morali zadržati isti odnos vrijednosti. Budući da je funkcija dostupna svima, kako spriječiti neovlaštenu upotrebu? Možda temp tablica (budući da se iz nje ne mogu učitati podaci iz druge transakcije) u koju program upisuje ključ, a funkcija čita podatak i njime kriptira/dekriptira podatke?

Bilo kakove ideje i mišljenje o ovom su dobrodošle, a iskustva pogotovo (a tek primjeri :) ).


kako misliš da ne možeš spriječiti pristup bazi?
pa izmijeni password od SYSDBA usera.
jel možeš malo detaljnije objasniti problem?
[ darko_sudarov @ 29.12.2010. 21:30 ] @
Zao mi je sto moram da te razocaram ali kriptovanja u bazi nema.
I meni je to trebalo...tj jos mi treba ali to firebird nece da uradi.
Procitaj detaljinije ovde
http://www.firebirdfaq.org/faq160/
Pozdrav.
[ savkic @ 30.12.2010. 12:36 ] @
> Koja je mogućnost da se kriptiraju podaci unutar fb-a?
> Problem je kako sakriti podatke, učiniti ih nepristupačnima ako se kopira baza. U situaciji sam da ne mogu spriječiti pristup serveru.

Najbolje da uzmeš neki program za šifrovanje diska tj. voluma, bazu staviš na taj volume i potpuno si miran.
[ darko_sudarov @ 30.12.2010. 22:03 ] @
Savkicu objasni ako imas vremena zasto je kriptovanje diska resenje?
Zar ne bi bilo bolje da firebird da mogucnost da se polje unutar baze kriptuje kao recimo oracle sto dopusta?
Ja sam imao situaciju namernog napada na bazu pri cemu je obrisano xyz bajtova iz hedera,to je muka vratiti a zamisli da je jos kriprtovan volume,ko bi to znao
vratiti?
Mozda ja nesto ne vidim kako treba ali kriptovanje diska mislim da nije resenje.
[ savkic @ 31.12.2010. 01:02 ] @
> Savkicu objasni ako imas vremena zasto je kriptovanje diska resenje?
> Zar ne bi bilo bolje da firebird da mogucnost da se polje unutar baze kriptuje kao recimo oracle sto dopusta?

Kako FB nema tu mogućnost, izmena source koda (da podrži enkripciju), pisanje UDF funkcija ili enkripcija u lokalu kao i enkripcija voluma su neke od mogućnosti. Programi za enkripciju voluma su već dugo na tržištu, isprobani i pouzdani. Naravno oni koštaju ali se mogu odmah angažovati, dok bi pisanje nekog rešenja neumitno trajalo neko vreme, svako može da proceni šta je najbolje rešenje za njegovu situaciju.

> Ja sam imao situaciju namernog napada na bazu pri cemu je obrisano xyz bajtova iz hedera,to je muka vratiti a zamisli da je jos kriprtovan volume,ko bi to znao vratiti?

Ne vidim kako bi enkripcija kod Oracla u slučaju ručne izmene baze to sprečila ili onemogućila. Ako je baza na nesigurnom Serveru i svakome na izvolte, sigurnosti nema. BTW, postoje programi koji oporavljaju oštećene FB baze, kao i profesionalci gde su programi nemoćni. Ako govoriš o ručnom oštećenju fajla gde je enkriptovan volume, ista je stvar sa brisanjem baze, ako dozvoliš tako nešto, nemaš odgovarajući bekap ni podatke nije moguće vratiti, onda tu pomoći prosto nema.




[ schild @ 06.01.2011. 10:36 ] @
Citat:
franjo_tahi: Možda temp tablica (budući da se iz nje ne mogu učitati podaci iz druge transakcije) u koju program upisuje ključ, a funkcija čita podatak i njime kriptira/dekriptira podatke?

Mozda je ovo tvoje dobar pristup. Mozda bi mogao neki kljuc da postavis iz programa u context variable sa RDB$SET_CONTEXT('USER_SESSION', 'MojKljuc', 'vrednost kljuca bla bla...') i onda da imas UDFe recimo Encode/Decode(AVrednostPolja, AKljuc).

U praksi, iz programa postavis kljuc kroz query sa sledecim kodom:
Code:
execute block as
begin
    RDB$SET_CONTEXT('USER_SESSION', 'MojKljuc', 'vrednost kljuca bla bla...');
end

I onda upite mozes raditi sa
Code:
select x.* from
(   select obicno_polje1, decode(enc_polje1, RDB$GET_CONTEXT('USER_SESSION', 'MojKljuc')) enc_polje1
    from tabela1
) x
order by x.enc_polje1 -- ovako bi imao i sortiranje, bez da pozivas udf 2x
-- a upis
insert into tabela1(obicno_polje1, enc_polje1)
values ('vrednost1', encode('vrednost2', RDB$GET_CONTEXT('USER_SESSION', 'MojKljuc')))


Cak bi modao napraviti updatable view koji bi ti u hodu radio enc/dec....
Code:
create view ve_tabela1
(obicno_polje1, enc_polje1)
as
select obicno_polje1, decode(enc_polje1, RDB$GET_CONTEXT('USER_SESSION', 'MojKljuc')) enc_polje1
from tabela1;

-- i onda trigger
CREATE OR ALTER trigger ve_tabela1_bi0 for ve_tabela1
active before insert or update position 0
as begin
  update or insert into tabela1 (obicno_polje1, enc_polje1)
  values (new.obicno_polje1, encode(new.enc_polje1, RDB$GET_CONTEXT('USER_SESSION', 'MojKljuc')));
end

I onda normalno radis sa ve_tabela1, a podaci su u tabeli uvek zasticeni.

Enkripcija diska je dobro resenje za zastitu od kradje racunara/diska. ALI ako neko ima pristup racunaru sa bazom u toku rada racunara i baze, onda ga nista ne sprecava da kopira bazu - koliko sam ja shvatio, programi za enkripciju diska rade tako sto se disk montira kao novi drajv na recimo slovo X:, i onda imas full pristup tim podacima dok god je disk montiran. Znaci copy/paste bez problema. Ovo sve mislim na tipicnu windows xp klient instalaciju. Uz malo podesavanja privilegija pristupa, jos bolje linux server, moze biti dobro resenje.
[ franjo_tahi @ 14.01.2011. 13:42 ] @
Nisam gladao postove neko vrijeme...

Ali, kako sam i mislio - nema zaštite.

Prilika je specifična: treba onemogučiti korisniku koji ima pravo pristupa na disk gdje je baza pregled ili izmjenu baze. Ne treba zaštitu od binarne izmjene file-a već od pregleda podataka. Kopiranje file-a na drugu mašinu s poznatim pass-om za fb i ode zaštita. Kriptanje volumena ne znači ništa - tko ima pravo pristupa na njega može kopirati fdb file.
Rješenje je očito pisanje UDF-a, a kom se iz programa šalje ključ za dekripciju. Samo tada to znači prepravljanje svih SQL-ova, a ostaje i problem order-a.

Da ne bih bio prost, p.s m...r i ostalo....

[ tkaranovic @ 14.01.2011. 17:45 ] @
Teorije radi... i ako se koristi embeded firebird...

Može da se zamene API funkcije koje se pozivanju a sa kojim dll pristupa bazi, to bi radilo ovako:

HookProc('kernel32.dll', 'CreateFileW',@New_CreateFile,@_CreateFile);


Tako bi se napravio virtualni fajl (*.fb) koji bi se čitao i pisao virtualno... a zapisivao bi se negde na drugom mestu gde bi mogao da se čuva i (samo) arhiviran pod šifrom.

Ako baš neko bude hteo da potraži, za Delphi može da se nađe unit advApiHook koji je pisao neki rus...