Datu aizsardzība

[krikulis]

Aleksejam ir kaut kādu procedūru slimība. Oraclists bļins.

var elementāri nograntot jūzerim select / insert / update / delete tiesības tabulai.

Vajag atļaut redzēt tikai datu subsetu - uztaisam skatu, grantojam select uz skatu.

Vienkāršāk un pārskatāmāk, kaut gan nav tik ENTERPRISE (Lieki abstrakcijas līmeņi tur, kur jamie nah vajadzīgi).

[Aleksejs]

krikuli, nelamājies!

Specifikācija nav dota, līdz ar to var būt gan "enterprise", gan "barn" klases sistēma.

[Delfins]

Kādi pasākumi būtu jāveic šo datu aizsardzībai (pret sql dampu piemēram)

sql-dump domāts bekupošanai.. gribi aizliegt bekupošanu? :)

 

Nosargājies pret savas lapas uzlaušanas un DB attiecīgi arī tiks pasargāta. Jo ja uzlauzīs webu, tiks pie pārēja.. bet vienalga - ja tiks pie servera resursiem (uzlauzīs pašu serveri), tad jau nekas nepalīdzēs.

 

Maksimāli drošs PHP kods un vari būt mierīgs un kā jau teica bubu - jāupdeito softs (Apache+PHP+*nix)

[bubu]

Aleksejam ir kaut kādu procedūru slimība. Oraclists bļins.

var elementāri nograntot jūzerim select / insert / update / delete tiesības tabulai.

Vajag atļaut redzēt tikai datu subsetu - uztaisam skatu, grantojam select uz skatu.

Vienkāršāk un pārskatāmāk, kaut gan nav tik ENTERPRISE (Lieki abstrakcijas līmeņi tur, kur jamie nah vajadzīgi).

 

Manā pierezē abstrakcijas ir tikai laba lieta (un ne tikai SQL kontekstā). Jo tev ar vienkāršākām lietām jāoperē (kuras noslēpj sarežģītākās lietas sevī dziļi iekšā), jo produktīvāk un efektīvāk tu spēsi programmēt.

Neredzu ne vaina SQL procedūrām - php kods mazāk tiek piemēslots ar SQL kverijiem, un kļūst tikai redzamāks, kas notiek (pēc procedūru nosaukumie), nevis jāpēta katru reizi liels SQL kverijs, lai saprastu, kas notiek.

[krikulis]

esmu aizgājis no ORM ceļu, kas manas kveriju palagu saīsināšanas prbl pilnīgi apmierina.

imo, vienkāršāk ir selectot no skata, updeitot to pašu skatu vai tabulu, tādejādi iegūstot gan vienkāršību, gan fleksibilitāti.

Lietas ir jātaisa vienkārši, bet ne pārāk vienkārši. Bieži vien visas abstrakcijas slāņi liedz fleksibilitāti un un pārkāpj DRY principu .

[marrtins]

Biju palaidis garām MySQL iebūvēto AES_ENCRYPT() :D Labs! Bet vispār, viens no drošākajiem variantiem ir:

*) definējam MySQL useri/paroli

*) softā (pieņemu, ka PHP) *nekur* to loginu paroli neglabāt

*) ielogošanās softā norealizēt ar MySQL useri/paroli (to var izdarīt)

*) INSERT/UPDATE kriptēt izmantojot šo pašu MySQL paroli un/vai izmantojot visādas manipulācijas ar paroli/useri/etc

 

Mīnusi:

*) nevar grupēt,meklēt,kārtot (varbūt vienīgi izmantotjot iebūvēto AES_ENCRYPT(), bet nu pats tikai tikko par tādu uzzināju, tāpēc nepateikšu kā ir)

*) aizmirstot paroli, nav iespējams atjaunot datus (labi, nerunāsim te par trīs simbolu parolēm)

*) iespējams viens lietotājs (šeit, varbūt, var izdomāt kaut-ko interesantu, kā to apiet)

Edited September 1, 2009 by marrtins

[krikulis]

jāāā, vēl katrai kolonnai piekabināt sha čeksummu, lai pārliecinātos, ka nekas nav mainīts ! </sarcasm>

piegājiens tik pat gudrs kā prezervatīva vietā izmantot ūdens spaini.

 

gribi securot datu pārraidi uz remote mysql serveri ? MySQL supportē SSL konekcijas - būs vienkāršāk, ātrāk.

pasākums ir lēns.

gribi fiziski datus aizsargāt - glabā mysql datu failus kriptētā partīcijā / securo backupus.

 

jautājums - kā tu domā saglabāt konekcijas persistenci bez mysql user / pass glabāšanas sesijā vai cepumos ? PHP ir stateless verķis, aplikācijas uzlaušanas gadījumā būs elementāri nosniffot šo te pašu paroli un useri.

no sql injekcijām pasargās parametrizētu vaicājumu lietošana.

 

Datus normāli searchot nevar, nebūvējot papildus indeksu ar dekriptētiem datiem. (ar dekriptēšanu sanāks exact search, tas pats attiecas uz kārtošanu un grupēšanu). IMO, MySQL neļāva būvēt indeksus balstoties uz funkcijas rezultātu, jebkurā gadījumā šajā indeksā būtu atrodami dati.

 

Kverijos rādīsies šifrēšanas kejs. Jamo varēs nosniffot tīklā / atrast kveriju / lēno kveriju logā / binlogā

 

Vienkāršāks variants būtu taisīt logošanos aplikācijā ar MySQL jūzeri, uzbūvēt abstrakcijas slāni, kas ļauj jūzerim piekļūt tikai pie saviem datiem un ar piekļuves tiesībām nodrošināt, ka lietotājs šo abstrakcijas slāni nevar apiet.

 

Ja dikti vajag kaut ko kriptēt, es izvēlētos PGP + kādu XML datubāzi, kuru arī varētu šifrēt.

[marrtins]

gribi securot datu pārraidi uz remote mysql serveri ? MySQL supportē SSL konekcijas - būs vienkāršāk, ātrāk.

pasākums ir lēns.

Tas nepalīdzēs, ja tikšu pie dumpa.

 

gribi fiziski datus aizsargāt - glabā mysql datu failus kriptētā partīcijā / securo backupus.

Tas palīdzēs, ja to kasti fizisko nozags un izslēgs. Nepalīdzēs, ja es tikšu ejošā serverī.

 

jautājums - kā tu domā saglabāt konekcijas persistenci bez mysql user / pass glabāšanas sesijā vai cepumos ? PHP ir stateless verķis, aplikācijas uzlaušanas gadījumā būs elementāri nosniffot šo te pašu paroli un useri.

Sessijā nekādas paroles nav jāglabā. Idejā tāda: nokriptēt loginu un paroli ar brīvi izvēlētu key (kas gan būs jāglabā configā, lai gan arī šeit var ko labāku izdomāt), base64 un sūtam kukijā. Pa SSL, protams. Servera galā dekriptējam. Šāds piegājiens, protams, arī nav ne-uzlaužams, ja uzbrucējam ir pilna piekļuve kastei, taču tas prasa daudz vairāk prasmju kā 99% sīkperdeļiem.

 

Datus normāli searchot nevar, nebūvējot papildus indeksu ar dekriptētiem datiem. (ar dekriptēšanu sanāks exact search, tas pats attiecas uz kārtošanu un grupēšanu). IMO, MySQL neļāva būvēt indeksus balstoties uz funkcijas rezultātu, jebkurā gadījumā šajā indeksā būtu atrodami dati.

Nu neko darīt, jātaisa grupēšana/zortēšana un citas manipulācijas ar programmatiskiem līdzekļiem.

 

Kverijos rādīsies šifrēšanas kejs. Jamo varēs nosniffot tīklā / atrast kveriju / lēno kveriju logā / binlogā

Iespējams, ka MySQL varētu būt pietiekami gudrs un to key nelogot nekur (bet ej nu zini, protams). Var arī neizmantot iebūvēto funkciju, bet dragāt ar PHP kriptēšanas metodēm.

 

Vienkāršāks variants būtu taisīt logošanos aplikācijā ar MySQL jūzeri, uzbūvēt abstrakcijas slāni, kas ļauj jūzerim piekļūt tikai pie saviem datiem un ar piekļuves tiesībām nodrošināt, ka lietotājs šo abstrakcijas slāni nevar apiet.

Tas ir tikpat jauki, kā pieņemt, ka Tavu kasti neviens "nepaņems"

Edited September 2, 2009 by marrtins

[usver]

md5 + salt

Ja ar salt saprot tikai papildus stringa pielikšanu, tad es ieteiktu labāk izmantot tā vietā sha1. Vai domāji šādu tehniku?

md5($klientaparole.'saltastrings');

Priekš md5 ir tik daudz bruteforce tūļu + rainbow tables saģenerētas, ka vienkāršās paroles var sameklēt bez ilūzijām. Ar sha1(sha1( .. )) vismaz būs drošāk, ka klientu universālās paroles tik lēti neuzzinās.

 

Fakts ir tāds, ka palūdza mums neglabāt personas kodu (interneta veikalam, līzinga noformēšanai), jo to vienkārši nedrīkstot darīt.

Drīkst. Fizisko personu datu aizsardzības likumā tā ir noteikts. Tikai vispirms personas piekrišanu vajag + reģistrēt šo DB valsts iestādēs. http://www.likumi.lv/doc.php?id=4042 AFAIK ar to nodarbojas Datu Valsts inspekcija.

Edited September 2, 2009 by usver

[Klez]

domāju ka md5($lietotaja_parole . 'sde@# 789^&^%& kksdfksdo )(_()(*&^%$#$@#$%^&*(/..,>?');

arī jau gatavām tabulām un brute force būs diezgan pasmagi.

parasti dabuu caurumu pashaa skriptaa (php)

tā kā vajag nodalīt php un db.

vislabāk ir tā ka ir viens DB lietotājs, kam ir tikai select tiesības (public daļa)

ir lietotājs kam ir update tiesības (komentāri, etc, pub daļā)

ir lietotājs kam ir write tiesības (admin sadaļa kas ir pavisam nost no public)

ir lietotājs kam ir insert tiesības (jaunu datu ievietošanai.. komentāri, sesijas ..)

 

lieki piebilst ka tiesības ir uz konkrētām tabulām.

sesijām var vispār atsevišķu jūzeri (gan select gan insert gan update)

 

---

tas priekš paranoiķiem :)

[bubu]

Vēl labāk ieliekam kādu ar klaviatūru neuzrakstāmo simbolu, un tad lai pamēģina to bruteforcēt - cik uz tādām lietām bruteforcē kāds pārbauda vispār?

md5($pasw . "aasdasdad \1 asdasd \xbe\xba\xb0 asdasd");

[Aleksejs]

Ikvienā jaunveidojamā sistēmā, ja vien nav kāda īpaši svarīga iemesla, būtu jāizmanto vismaz sha-2 nevis md5.

Sāli jāģenerē katram lietotājam savu kā vismaz hash funkcijas bloka garuma virkni (sāls ģenerēšana ar RNG jau ar lielu varbūtību garantē, ka būs ar_klaviatūru_tik_viegli_neievadāms_simbols).

[aika]

Viens no relatīvi vienkāršiem, bet pietiekami efektīviem variantiem. Pieņemsim, ka tā tabula saucas Personas. Šai tabulai web-aplikācijā izmantotajam DB lietotājam ļaujam darboties ar šo tabulu tikai izmantojot "Stored procedure" -

diemžēl nederēs - dati ir arī jānolasa, jānodod darījumā iesaistītajām personām!

[Aleksejs]

Jā, bet vai šai pašai aplikācijai?

[krikulis]

Tikt pie dumpa ? komoon, ja tiek pie dumpa tiek arī pie source backupiem un var īzī visu nojaukt :)

 

SQLs ir programmēšanas valodas, ja kas :) Virs > 1k ierakstiem tavs risinājums darbosies ātri cik Lembergs deklarē savus reālos īpāšumus. JOINus vēl kkā varētu realizēt (bet vai tas nav jāšifrē - kāda entīnija ar kādu attiecas ?).

Pamēģini php galā dekriptēt, nogrepopot un sasortēt 1k resultsetu .

 

Gadījumā ar SQL privilēģiju jūzeri ielauzties var tikai tad, ja atklāj mysql drošības bugu, kas ļauj iehavot roota privilēģijas ;). Pārējais ir bullshits.

Ar SQL injekcijām neko padarīt nevar, principā var jūzerim dot pieeju MySQL serverim pa tiešo un jams tur neko izownot nevarēs .

 

MySQL var izrubīt dajebkādu logošanu (kas gan būtu epic stupid and epic fail).

Principā man šķiet, ka pilsonis marrtins ir kaut ko salietojies un mēģina te episki tizlas sistēmas, kas nebūs drošākas par Mysql iebūvētas ACL jūzošanu.

 

Par hašošanu - visdrošāk ir saltu ģenerēt ar

http://www.php.net/manual/en/function.openssl-random-pseudo-bytes.php

MD5 der tikai novilktā porn integritātes nodrošināšanai, paroles hašo ar sha256 (PHP jamo supportē ar mhash extensiju).

Edited September 2, 2009 by krikulis