"Uti non Abuti"

1. A racja. Wlasnie mi czegos brakowalo :) , ptoki 6/08/13 23:17
   No i LIKE/SUBSTRING/TRIM i podobne nie działają...
   Dlatego pytałem czy dla tych dwu jest rozwiązanie bardziej wewnętrzne...

I fix shit
http://raszpl.blogspot.com/

1. Klient sobie zyczy aby dane w bazie nie byly czytelne. , ptoki 7/08/13 00:02
   Szyfrowanie filesystemu mu nie wystarcza.
   Jednoczesnie na orakla nie chce sie zgodzic bo za drogie.
   Baza i aplikacja są na tym samym hoscie (bo ma byc tanio :) ).
   Plus jest taki ze uzytkownicy będą tylko wewnetrzni więc jest mniejsza szansa na włamanie.
   
   Narazie to nie jest warunek must-have ale klient chce wiedzieć czy sie da i jakie problemy to zrodzi.
   
   W przyszlosci plan jest taki ze sie baze wydzieli i wtedy rzeczywiscie połączenie będzie szyfrowane i po dedykowanej podsieci. Ale to za jakiś czas.
   
   Teraz istotne jest czy tanie bazy mają obsługę szyfrowania wewnętrznie. I nie wyczytałem ale może źle szukam...
   1. jest kilka aspektów , bwana 7/08/13 00:50
      1. Jeśli "dane w bazie" mają być nieczytelne, to przerzucanie szyfrowania na warstwę aplikacji nie spełnia założeń.
      
      2. Przy szyfrowaniu w bazie należy określić które dane nie muszą być szyfrowane (z dokładnością do tabeli-kolumny).
      
      3. Szyfrowanie wyklucza poprawne zapytania o wartość cząstkową pola (dzień, miesiąc, rok z daty, wszelkie LIKE-i na stringach
      
      Jeśli chcesz użyć frameworku (ogólnie - modelu) MVC to nie musi to być problem. Ale będzie. Przynajmniej wydajnościowy bo każde jak wyżej zapytanie będzie musiało trafić do warstwy widoku i dopiero tam będą mogły być odrzucane dane, które (po odszyfrowaniu) nie spełniają warunków LIKE, extract (day from date) etc.
      
      4. Jeśli właściciel obawia się że do jego danych dopcha się administrator bazy danych, to może wystarczy mu logowanie kwerend i eksportów - zniechęci administratora bazy do zaglądania do danych bez autoryzacji.
      
      5. Nie idź tą drogą
      
      6. Wybij to klientowi z głowy
      
      7. Unikaj tego jak ognia o ile nie dostaniesz za to taczki pieniędzy.
      
      8. http://www.postgresql.org/...cryption-options.html
      
      9. http://www.oracle.com/...ecurity/index-099011.html
      
      10. http://www.oracle-base.com/.../data-encryption.php
      
      11. https://dev.mysql.com/...encryption-functions.html
      
      12. NIE RÓB TEGO, MAN!

      "you don't need your smile when I cut
      your throat"

      1. ad 1. - a to czemu? , ptoki 7/08/13 07:39
         skoro klucz będzie w samej aplikacji? I docelowo hosty będą rozdzielone.
         
         Co do reszty punktów: Dzieki za sugestie/informacje. W wiekszości mamy świadomość tego o czym piszesz.
         
         Mamy liste tego co ma być zaszyfrowane i są to głównie dane osobowe. Przy nich jedyny problem to sortowanie listy nazwisk albo wyszukiwanie LIKE.
         Reszta raczej niebolesna. Ale obaczymy co powie klient.
         W aplikacji warto zrobić tak aby można było to szyfrowanie porzucić bez rozgrzebania całości.
         
         Ale to sie obaczy...
         Dobrze że to nie ja to pisze :)
         1. ad 1 - pomyliłem się, rzecz jasna masz rację , bwana 7/08/13 07:50
            jeśli tylko wybrane dane mają być szyfrowane to należy się zastanowić które i czemu faktycznie mają być szyfrowane. Dajmy na to dane typu Jan Kowalski to żadna informacja poza tą, że jakiś Jan Kowalski jest w bazie. Zaszyfrować można informacje o tym ile np. Jan Kowalski zarabia (ale wtedy nie zrobisz łatwo rankingu wynagrodzeń:-D).
            
            Jeśli "zaszyfrowanie" ma na celu uniknięcie uznania bazy za zbiór danych osobowych i męczenia się z GIODO to sorry, ale nie tędy droga. To nadal będzie zbiór danych osobowych który obejmuje ustawa.

            "you don't need your smile when I cut
            your throat"

            1. ok. ten aspekt z giodo to wiem ze nie da sie tak uniknąć ale jednak , ptoki 7/08/13 08:38
               zaszyfrowane dane czymkolwiek są lepsze niż czystotekstowe.
               
               No i nie wiem dokładnie czemu klient tak chce. To świeży temat więc szczegóły i powody dopiero wyjdą :)
               
               Obaczymy ile z tego co sobie zyczą sie ostanie...
               
               Jeszcze raz dziekuje.
               1. to może nie baza zaszyfrowana , bwana 7/08/13 16:50
                  Tylko system plików?

                  "you don't need your smile when I cut
                  your throat"

                  1. To juz dostal :) , ptoki 7/08/13 17:48
                     Ale obaczymy jak sie sytuacja rozwinie...

   2. Baza i aplikacja są na tym samym hoscie (bo ma byc tanio :) ). , RusH 7/08/13 01:54
      rece opadaja
      po co cokolwiek ma byc szyfrowane skoro i tak nie bedzie bezpieczne?
      
      PO CO te dane w bazie maja byc nieczytelne? jesli boi sie administratora aplikacji/bazy to trzeba zmienic administratora, bo aplikacja albo ma dostep do danych i dziala badz nie ma dostepu i nie dziala :)
      Twoj klient chyba chce aby aplikacja nie miala dostepu do danych i dzialala :)
      
      tak jak bwana pisal mozesz przerzucic cala prace na aplikacje i tam szyfrowac, wtedy faktycznie baza nie bedzie miec danych tylko zaszyfrowany smietnik, ale w takim przypadku odpadaja wszystkie zalety sql i mozna rownie dobrze isc w mongodb bo jest webscale (:P)
      
      mozna co najwyzej logowac queries i w razie wycieku masz paper trail kto grzebal

      I fix shit
      http://raszpl.blogspot.com/

      1. Bo narazie ma być tanio a jak projekt sie przyjmie to sie zrobi lepiej. , ptoki 7/08/13 07:31
         Jednak co to można zrobić juz warto zrobić już.
         A jednak szyfrowanie danych na warstwie aplikacji potencjalnemu włamywaczowi troche jednak utrudni dostanie sie do danych.
         
         Czemu maja byc nieczytelne? Pewnie przeciwko włamywaczom. Raczej nie przeciwko adminom. Ale na moje oko tam po drugiej stronie jest jakiś arkusz z warunkami i scoringiem. I komus wychodzi że jakby jeszcze taki punkt dodać to wynik bęzie lepszy :)
         
         Dzieki za sugestie.
         1. off-topic - na razie , Grocal 7/08/13 11:49
            Widzę ptoki, że robisz ten błąd notorycznie, więc pewnie błędnie zakładasz, że pisze się tak, jak Ty to piszesz.
            
            Co do meritum, to RusH chyba przedstawił problem idealnie. Z doświadczenia wiem, że klienci potrafią mieć poronione pomysły i czasami trzeba po prostu pokazać im, że coś jest idiotyczne, niewykonalne, bez sensu. Można szyfrować, ale co z tego, jeżeli włamywacz będzie miał też dostęp do klucza, bo np. będzie miał też dostęp do kodu aplikacji.
            
            Po prostu nie zawsze warto inwestować energię w szukanie rozwiązania problemu ale pozbyć się problemu całkowicie, czyli wybić z głowy klientowi :)

            Na pewno, na razie, w ogóle...
            Naprawdę, naprzeciwko, stąd...
            Ortografia nie gryzie!

            1. A mozliwe ze tak mi sie ułozyło to słowo. , ptoki 7/08/13 12:03
               Cóż jednak błąd :).
               
               A klient dostanie informację że to jest do zrobienia ale mocno skomplikuje rozwój.
               
               Dodatkowy feler jest taki że późniejsze zmiany w bazie (bo aplikacja miała błąd i dane biznesowe trzeba poprawić tez będą bardziej skomplikowane i klucz szyfrujący będzie musiał byc znany osobie łatającej bazę...
               
               Dzieki za sugestię.

         2. Bo narazie ma być tanio a jak projekt sie przyjmie to sie zrobi lepiej , RusH 7/08/13 22:22
            ojezusicku, jeszcze lepszy tekst niz ten pierwszy :)
            ile razy slyszales ta bajke i ile razy faktycznie sie sprawdzilo?
            
            car analogy: 'panie wyklep mi ten blotkin za pol ceny to pol mojej rodziny bedzie sie tu naprawiac'
            
            doic, doic i jeszcze raz doic, szczegulnie za glupie niestandardowe pomysly jakiegos cymbala bez pojecia, jak chca szyfrowanie ktorego nawet banki nie stosuja to niech placa przez lzy

            I fix shit
            http://raszpl.blogspot.com/

            1. golnie , RusH 7/08/13 22:23
               123

               I fix shit
               http://raszpl.blogspot.com/

            2. Nie ma źle. U mnie zazwyczaj tak jest ze najpierw jest POC potem jakiś mały systemik a pot , ptoki 7/08/13 22:51
               em produkcja pełną gębą jest uczciwie zrobiona.
               Dlatego nie mam uprzedzeń.
               
               Ale wiem że jak klient pierdoła to oszczędza.

"Uti non Abuti"

1. uuu tego to bym nie sugerował nawet wrogowi :) , ptoki 7/08/13 11:32
   Narazie to nie jest tak że musi być szyfrowanie - nawet po trupach.
   
   Ale dzieki za sugestie.

2. Jezusie , bwana 7/08/13 16:49
   Chrysty! Taki model to chyba jedynie dla warstwy persistency dla baz inmemory (typu Oracle times ten). Horror, zgroza i FSO polonez:-D

   "you don't need your smile when I cut
   your throat"

Strength is irrelevant.
Resistance is futile.
We wish to improve ourselves.

1. Tez taka moge zrobic. Na tym dysku co , ptoki 7/08/13 20:38
   wlasnie mi padł :)