Pitanje je filozofske prirode. Access nije bog zna kako jak u sprecavanju neovlascenog pristupa podacima. Mogu se preduzeti razumne mere, koje obicnog korisnika sprecavaju da namerno ili slucajno brlaj sa podacima.

Medjutim, tim koji radi na razvoju softvera, po definiciji ima pristup svemu. I kad se sutem zavrsi, uvek postoji neko ko ima pruistup svemu. Ovo vazi za bilo koju bazu podataka, ne samo Access. AKo nemas poverenja u clanove tima, onda treba tim rasturiti ili obustaviti posao. Za ovakve stvari je potrebno poverenje i nema drugog leka.

:-)

Delimicno se slazem, zato sam i rekla da problem nije bas striktno vezan za bazu ali ima veze i moze nekome pomoci. Ako ja kao programer napisem program nekoj od banaka ja imam pristup svemu. Ali isto tako ne postoji verovatno ni teoretska sansa da ja nekome ili sebi uplatim odredjeni iznos ili nekome skinem odredjeni iznos sa racuna a da se to u narednom obracunskom periodu ne skonta. Sve je stvar knjizenja (citaj u pozadini matematike). Znaci pitanje bi bilo kao sto rekoh, nemoguce je spreciti nekoga ko zna sifru da udje u bazu i unesi neki broj ali kako bi se matematicki shvatilo da se to uradilo?

Ima rešenja: Uzmi Oracle Database Enterprise Edition i Database Vault opciju. Stavi na papir koliko će to da košta (45,700 USD po procesoru za bazu i 23,000 USD po procesoru za Vault opciju). Onda izračunaj da li ti se isplati da neko kraducka ili da ovo nabaviš.



Ovo je isto kao da pitaš: Sa firminog Yuga, zato što ga svi voze, skinuli smo sve brave, pa kako da rešim da se ne krade benzin?
Odgovor: nikako!

Nevena, koristi NTFS, zatim napravi korisnicke grupe i namesti pravo pristupa koja grupa moze da cita fajl a koja ne. Zatim odgovarajuce korisnike stavi u odgovarajuce grupe (mozes raditi i direktno sa korisnicima ali je sa grupama lakse).
User-a pod kojim se pokrece program stavi u grupu koja sme modifikovati fajl.

Ovo se postiže podelom uloga koje imaju korisnici sistema.

Da bi se omogućilo da se pristupa bazi, mora postojati "Security officer" koji "otključava" bazu. Da bi neko mogao direktno da pristupi podacima (čak i administrator) security officer mora da mu da eksplicitnu privilegiju.

Naravno, i dalje postoji mogućnost da se securiy officer i DBA lepo "dogovore", ali deo sistema je i logovanje svih takvih akcija...

Iju iznenadili ste me koliko odgovora tako brzo :)
Hajde ovako, posto je krenulo... Sve ono nisam upotpunosti razumela nego delimicno i za sada me zainteresovalo ono sa logovanjem. Da li je moguce logovati sve sto se rucno radi u bazi?
Da vam jos malo pojasnim o cemu se radi jer cini mi se da smo u nekip postovima malo odlutali sto znaci da nisam dovoljno dobro objasnila. Situacija je ovakva... Oformila se grupa ljudi koja se ne poznaje da izvrsi jedan projekat. Nasli smo se bas ovde na elite, projkat gotovo zavrsili i sada se desilo to da svi znaju sve, i svi imaju apsolutnu kontrolu nad svim a opet dovoljno se ne poznajemo da bismo mogli samo da zazmurimo :) I na kraju krajeva cist racun duga ljubav, odavno su rekli. Znaci potrebna je neka metodologija zapisivanja, logovanja ili cega sve, kojom bi se moglo utvrditi sta je ko radio (to je moguce kada se izmene vrse softverski) ali takodje bitna je i neka procedura ili matematika kojom bi se skontalo da nesto ipak nije uredu i da je neko radio nesto mimo softvera. U sustini nekog velikog problema nema, a ako se sistem dobro postavi nece ga ni biti. E sad ako je neko gore predlozio nesto sto bi i u ovom slucaj radilo, slobodno me vratite, samo nisam skontala.
I hvala za ovako brze odgovore.



Nije to tako, pitanje je bilo ok, svako moze da ukrade benzin ali kako ja da shvatim da je ukraden? Preko putnog lista naravno :)

P.S. Takodje mogao bi se server sa bazom podeliti vecem brojem nepoznatih ljudi koji bi zeleli da hostuju (npr. ti) i tada se mora spreciti da svako moze da radi nekontrolisano sta mu je volja, znaci u svakom trenutku mora biti jasno koliko ko ima kredita, kolika je ukupna uplata i sl.

_{[Ovu poruku je menjao Nevena79 dana 08.06.2009. u 15:54 GMT+1]}

Recimo da se uplate vrše u gotovini.
Tada se na kraju dana blagajna zatvori i odštampa se blagajnički dnevnik. U njemu se nalaze sve promene na blagajni i one se upare sa papirnom dokumentacijom (priznanicama, računaima). Ukoliko se blagajna složi arhivira se blagajnički dnevnik sa svim pripadajućim papirima.

Kasnije, mogu se za svaki dan proveriti uplate i sravniti sa blagajničkim dnevnikom.

Kod bezgotovinskih uplata, rasknjižava se izvod iz banke na račune korisnika, knjiženja se odštampaju i prilože uz izvod i kasnije se proverava na osnovu izvoda.

Kod svakog umanjenja stanja na računu, odštampa se specifikacija (ako je potrebna).

Tabela koju si ti navela je tabela STANJA računa. Osim nje mora postojati tabela PROMENA (blagajna, račun itd.)

Ovo pitanja hostovanja je potpuno bezveze, zar misliš da nekome prodaš pristup na Access bazu i to istu onu na kojoj držiš sopstvene finansijske podatke???

Nije ovo nesto tako ozbiljno kako zamisljas. Upitanju je jedna igra. U planu njenog prosirenja postoji i opcija da se prazna baza i server daju nekome ko zeli da bude hoster i takvih ljudi moze da bude neograniceno mnogo. Oni dobijaju sva prava hostera, mogu da odredjuju cenu i slicno ali administratorima moraju uplacivati jedan procenat od zarade. Svako od hosera mora imati mogucnost da vidi sve sto se nalazi u bazi i da to i menja jer u probnom periodu primecena je potreba za tim jer korisnici imaju razlicite zahteve i takodje razlicite stvari se mogu desiti. Bilo kako bilo sve je to nebitno, bitno je samo da se citav taj proces moze na neki nacin kontrolisati, sto medju nama, sto kontrola samoh hostera.

Sve ostalo je vise manje moguce uspesno zastititi osim varijante da se zaobidju standardne procedure i ja kazem tebi evo uplaticu ti toliko i toliko po puno jeftinijoj ceni, das mi na ruke i nigde se nista ne evidentira. Tada je jedini dokaz povecani iznos u bazi kod tog korisnika ali posto je samo u test periodu bilo oko 900 registrovanih korisnika nemoguce je sve rucno proveravati. Postoje samo 2 stvari koje se mogu uraditi. Fakticki ako sam dobro promislila postoji samo jedna mogucnost koja se moze uraditi. Ako bi se rucno povecala uplata u bazi to se naravno vidi i toliko mora biti i na racunu u banci. Znaci jedino sto se moze uraditi je povecati nekome sadasnje stanje. Ono je npr bilo jos 20din i ti nekome povecas na novih 200 a to treba detektovati.

Ummm.. ne moz' detektovati promenu u access-u, ali sad mi pade napamet da mozes napraviti jednu kolonu koja je hash svih ostalih pa kada citas podatke da vidis da li se hash slaze. Neko ko ne zna algoritam hash-a nece moci da promeni i podatke i njega tako da i dalje odgovaraju. E sad, ako je to neko od tvojih saradnika koji zna algoritam, jbg :)

VIdis dao si mi odlicnu ideju.... To nije velika baza i ne ocekuje se bas na milione korisnika tako da se u nju mogu dodavati i gluposti. Moze biti jedan kriptovani deo za svakoga od nas (u krajnjem slucaju) i svako zna samo svoj kljuc za kriptovanje i uporedjuje se da li cifra odgovara. Zanimljivo si se setio, svaka cast.

Nešto slično sam i ja hteo da predložim.
Na redovima koji ne smeju da se menjaju, dodati kolone user i md5checksum. Neko, ko hoće da zaštiti red, na primer PERA ili LAZA, naprave kopiju tog reda u arhivsku tabelu, i nad vrednostima svih polja i konkateniranog passworda koji PERA ili LAZA unesu interaktivno, uradi se MD5 transformacija. Tada odgovorajući korisnik može da proveri da li je bilo promena nad slogom (uz unos passworda koji je korišćen u prethodnom koraku).