bubu Posted September 3, 2009 Report Share Posted September 3, 2009 Pakļau, ļaudis - lūdzams atturamies no personiskiem uzbraucieniem (krikuli!). Savu viedokli pamatojam konstruktīvi, nevis pasakam "tu nekā nesaproti, es gudrāks par tevi!". Nevienam no tā nekļūs labāk. Quote Link to comment Share on other sites More sharing options...
marrtins Posted September 3, 2009 Report Share Posted September 3, 2009 Tikt pie dumpa ? komoon, ja tiek pie dumpa tiek arī pie source backupiem un var īzī visu nojaukt :) Ko tev dod kritpēts bakups vai source bez parolēm? 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 . Par to cik daudz SQL ir programmēšanas valoda var palasīt šeit: http://php.lv/f/topic/13085-vai-html-un-sql-ir-programmesanas-valodas/page__fromsearch__1 Kāpēc būtu jāJOINo pēc sensitīviem datiem? JOINojam pēc atslēgas. Galu galā, ja sets ir nežēlīgi liels, to var deliģēt kādai citai valodai, kas pratīs multithreadingu un atlasīs un sazortēs izmantojot n-tās cores tā ka prieks. 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 . Aizmirsti tak tās injekcijas. Tas nav vienīgais veids, kā tikt pie datiem. Pietam, lai tiktu pie dumpa, nav vajadzīgas root tiesības. MySQL var izrubīt dajebkādu logošanu (kas gan būtu epic stupid and epic fail). Par to, ka tā var šaubu nav, un vispār te neviens tādu variantu neieteica. 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. Interesants tas tav princips... Quote Link to comment Share on other sites More sharing options...
krikulis Posted September 3, 2009 Report Share Posted September 3, 2009 (edited) Arī zend opcode var lasīt . Source nav iespējams padot tā, lai jamo nevarētu atkodēt. Ar normālu privilēģiju nodalīšanu jūzeriem / fw un hardeningu var panākt to pašu bez bezjēdzīga čakara. Tavs variants ir slima suņa murgi, kas pat teorijā ir idiotisks :) Dati un datu loģika -> datubāze Aplikācijas loģika -> aplikācija Tu datus padara atkarīgus no aplikācijas, kas nozīmē vien to, ka pēc 10 gadiem tavi sensitīvie dati būs nejūzojami. Neizrubot logošanu, kverijus varēs lasīt no binloga / slowloga. Bez binloga nevar taisīt inkrementālus backupus un replikāciju. Edited September 3, 2009 by krikulis Quote Link to comment Share on other sites More sharing options...
marrtins Posted September 3, 2009 Report Share Posted September 3, 2009 (edited) Labi. Ja es tev iedošu root access, vai tu man apsolies dabūt noteikta ieraksta datus? Ar normālu privilēģiju nodalīšanu jūzeriem / fw un hardeningu var panākt to pašu bez bezjēdzīga čakara. Tavs variants ir slima suņa murgi, kas pat teorijā ir idiotisks :) Un kas notiek, ja viens no tiem posmiem nobrūk? Dabūjam plain datubāzi. Dati un datu loģika -> datubāze Aplikācijas loģika -> aplikācija Un kur drošība? Tu datus padara atkarīgus no aplikācijas, kas nozīmē vien to, ka pēc 10 gadiem tavi sensitīvie dati būs nejūzojami. Un? Tikpat labi var teikt, ka dati ir atkarīgi no datubāzes. Neizrubot logošanu, kverijus varēs lasīt no binloga / slowloga. Bez binloga nevar taisīt inkrementālus backupus un replikāciju. Bet tak lai lasa tos kritpētos datus :D Edited September 3, 2009 by marrtins Quote Link to comment Share on other sites More sharing options...
marrtins Posted September 4, 2009 Report Share Posted September 4, 2009 Kur tu pazudi? :O Quote Link to comment Share on other sites More sharing options...
blackhalt Posted September 5, 2009 Report Share Posted September 5, 2009 Tas ir komplekss pasākums, kas atkarīgs no Security policy. Jā, vajag šifrēt! Quote Link to comment Share on other sites More sharing options...
krikulis Posted September 6, 2009 Report Share Posted September 6, 2009 Dažiem šeit nav laika sēdēt forumā 24/7 Ar rootkit var datus. Kaut vai ar man - in - the - middle uzbrukumu starp MySQL klientu / serveri (Ja ir serveris ownots, tad privāto atslēgu SSLam dabūsim, ja klients - var uzģenerēt jaunu sertifikātu un klientam pateikt, ka jams ir trusted). Pārfrāzējot par datu un aplikācijas loģiku: Datu drošība - DB, aplikācijas drošība - aplikācijā. Ja kriptēsi ar MySQL funkcijām, viss kverijs būs pieejams logos, ar visu AES atslēgu. Daudzslāņu drošības risinājums nav no viena slāņa atkarīgs. Ja nofeilo viens slānis, uzbrucējs atduras strupceļā, savukārt tavs risinājs ir atkarīgs no vienas jūzerneima / paroles kombinācijas . Par datu atkarību no datubāzes - arī 10 gadus vecai DBVS var šodien php / .NET pieslēgties un jamo jūzot. Savukārt pamēģini šodien FoxPro verķi padarbināt uz 2008 servera / Vistas putna un vēl palabot. Datu atkarība no aplikācijas ir slikta ideja, it sevišķi, ja dati ir vērtīgi. Dati savu vērtību zaudē lēnāk kā programmēšanas valodas aktualitāti un lielākajai daļai DBVS ir iespējams migrēt uz jaunāku versiju ar mazāku ķesku kā pārrakstīt kodu citā valodā, pie tam neaizmirstot visus datu integritātes un unikalitātes ierobežojumus. Starp citu, simetriskā kriptogrāfija nav tik fleksibla datu drošības jautājumos kā asimetriskā. AES ir super hardcore drošs >=192bit atslēgām . 64bit atslēgas ir ownotas ;). Pieņemšu, ka serveris ir trusted party, tad prātīgi serverim dot privāto atslēgu, klientiem - publisko. Tādejādi viena puse varētu tikai atšifrēt datus (trusted), otra - aizšifrēt. Datu integritāte būtu pasargāta no nesankcionētiem uzbrukumiem / man - in - the middle, veicot verifikācijas procesu, kurā klients aizšifrē serverim iepriekš zināmus datus, bet serveris - atšifrē, pārbauda. Ja man būtu jātaisa kaut kas drošs "uz sitiena", bez vadlīnijām un laika, lai izstudētu piemēram Visa vai Mastercard drošības prasības online sistēmām, es darītu tā: 1)aplikācijas nodei pieeja f/w atļauts trafiks tikai uz klientiem un uz db. 2)DB var runāt tikai ar aplikācijas nodi, pietam ar SSL trafiku . 3)DB jūzeri, kuram katram minimālā iesp. piekļuve datiem atkarībā no specifikācijas uz tabulām / skatiem / procedūrām, ar kuriem var manipulēt ar datiem . 4)DB dati un aplikācijas kods atrodas uz kriptētām partīcijām, tāpat arī tmp / swaps. 5)Jūzeri slēdzas klāt pie aplikācijas, izmantojot ij klienta puses SSL sertifikātus, ij userneimu/pass . Enforcojam accessu arī klienta pusē, līdz ar to uzbrucējam jāapiet divi slāņi db piekļuvei app/fw un db iebūvētie drošības kontroļi. 6)Visām SSL vajadzībām uztaisam savu CA, sertifikātus ģenerējam kaut vai ar LiveCD palīdzību, pēc sertifikātu uzģenerēšanas root certifikātu izprintējam, iebāžam seifā . 7)Aplikācijas nodes uzmočītu uz read-only sistēmām, kur nekas atskaitot swapu un ramu nav rakstāms. 8)Visus logus ar write only kanālu uz citu serveri, kur logus arī kāds regulāri pētītu . Rezultāts - nevienā posmā dati nav nekriptēti. Klients ar savu paroli var jūzot jebkuru aplikāciju, kas darbojas ar DB, aplikācijas var kodēt izmantojot standarta api un drošības lietas ir padarītas vienkāršas, nevis sarežģītas. Var darboties daudz konkurenti jūzeri, Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted September 7, 2009 Report Share Posted September 7, 2009 AES ir super hardcore drošs >=192bit atslēgām . 64bit atslēgas ir ownotas ;). AES nemaz neeksistē ar 64b atslēgu, pēc standarta mazākā ir 128b. Ko tieši nozīmē, ka simetriskā kriptogrāfija nav tik fleksibla kā asimetriskā? Asimetriskā kriptogrāfija tak bez simetriskās praksē netiek izmantota (jo ir nepieļaujami lēna). Quote Link to comment Share on other sites More sharing options...
krikulis Posted September 7, 2009 Report Share Posted September 7, 2009 (edited) Pardon, nakts vidū domu nepareizi izteicu . Simetriskā kriptogrāfija viena pati nav pietiekami fleksibla, jamai klāt liekama ir asimetriskā. Biedram, kas grib aplikācijas levelā filtrēt un datus sortēt, ātrdarbība jau nu nav vērā ņemams faktors. Par 64bit keyu vainīgs. Man tas amatieru RC5 laušanas distributed comp. pasāciens bija iespiedies atmiņā ar AES saistībā, kaut gan saistība tik tāda, ka AES uz RC6 bāzēja. Ar asimetriskās kriptogrāfijas palīdzību no droši pārraidīt datus untrusted vidē, kur tikai viens endpoints (serveris) ir pieņemts kā drošs. Edited September 7, 2009 by krikulis Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted September 7, 2009 Report Share Posted September 7, 2009 Emmm... Nu nebūs gan tā, ka AES ir balstīts uz RC6. :) RC6 kopā ar Rijndael (kas tad arī tika izvēlēts par uzvarētāju) bija kandidāti sacensībā par to, kurš būs jaunais šifrēšanas standarts - AES. Rijndael atšķirībā no RC6 un arī vecā DES nav vis Feistela struktūra, bet gan substitūciju-permutāciju struktūra, kas ļoti daudziem pētniekiem likās aizdomīgi... :) Attiecībā uz asimetrisko šifrēšanu, protams, tā atrisina dažas lietas (kā, piemēram apmaiņu ar simetriskās šifrēšanas atslēgām nesatiekoties) un ļauj lietas, kuras simetriskā neļauj (vienvirziena šifrēšana/elektroniskā paraksta iespējamība), bet tā arī rada jaunas problēmas, kuras nebija aktuālas simetriskajai šifrēšanai (piemēram MiTM - simetriskajā šifrēšanā, lielākoties, atslēgu apmaiņas veids kā tāds neparedz attālinātu apmaiņu ar atslēgām, līdz ar to šī problēma nemaz nerodas). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.