🚀 go-pugleaf

Niestety RODO wprowadzi dużo zmian ale nie jest nią proces szyfrowania bazy danych. 
Jedną z założeń dotyczących bazy danych jest przestrzeganie prawa do zapomnienia danych, czyli podanie bazy procesowi anonimizacji danych wrażliwych. Proces szyfrowania danych nie spełnia tych warunków. 

Proces szyfrowania spełnia wymagania RODO pod względem zabezpieczenia komputera (w rozumieniu stacji roboczym użytkownika) przed dostępem osób trzecich.

W dniu czwartek, 5 kwietnia 2018 08:38:40 UTC+2 użytkownik cichy napisał:
> Niestety RODO wprowadzi dużo zmian ale nie jest nią proces szyfrowania bazy danych. 
> Jedną z założeń dotyczących bazy danych jest przestrzeganie prawa do zapomnienia danych, czyli podanie bazy procesowi anonimizacji danych wrażliwych. Proces szyfrowania danych nie spełnia tych warunków. 
> 
> Proces szyfrowania spełnia wymagania RODO pod względem zabezpieczenia komputera (w rozumieniu stacji roboczym użytkownika) przed dostępem osób trzecich.

Nie masz racji. Wiele spotkań już w tym temacie odbyłem i raczej oczywistym jest, że to plik zawierający dane wrażliwe ma być tak zabezpieczony by dostęp do danych w nim zawartych był utrudniony ...

Roman 

On Thu, 5 Apr 2018 01:09:09 -0700 (PDT), kameleonsql@gmail.com wrote:

>> Niestety RODO wprowadzi dużo zmian ale nie jest nią proces szyfrowania bazy danych. 
>> Jedną z założeń dotyczących bazy danych jest przestrzeganie prawa do zapomnienia danych, czyli podanie bazy procesowi anonimizacji danych wrażliwych. Proces szyfrowania danych nie spełnia tych warunków. 
>> 
>> Proces szyfrowania spełnia wymagania RODO pod względem zabezpieczenia komputera (w rozumieniu stacji roboczym użytkownika) przed dostępem osób trzecich.
> 
> Nie masz racji. Wiele spotkań już w tym temacie odbyłem i raczej oczywistym jest, że to plik zawierający dane wrażliwe ma być tak zabezpieczony by dostęp do danych w nim zawartych był utrudniony ...

Czy wg Ciebie zaszyfrowanie bazy danych spełnia wymogi w zakresie usunięcia
danych osobowych na życzenie klienta?

-- 
pozdrawiam
Roman Tyczka

W dniu czwartek, 5 kwietnia 2018 11:48:38 UTC+2 użytkownik Roman Tyczka napisał:
> On Thu, 5 Apr 2018 01:09:09 -0700 (PDT), kameleonsql@gmail.com wrote:
> 
> >> Niestety RODO wprowadzi dużo zmian ale nie jest nią proces szyfrowania bazy danych. 
> >> Jedną z założeń dotyczących bazy danych jest przestrzeganie prawa do zapomnienia danych, czyli podanie bazy procesowi anonimizacji danych wrażliwych. Proces szyfrowania danych nie spełnia tych warunków. 
> >> 
> >> Proces szyfrowania spełnia wymagania RODO pod względem zabezpieczenia komputera (w rozumieniu stacji roboczym użytkownika) przed dostępem osób trzecich.
> > 
> > Nie masz racji. Wiele spotkań już w tym temacie odbyłem i raczej oczywistym jest, że to plik zawierający dane wrażliwe ma być tak zabezpieczony by dostęp do danych w nim zawartych był utrudniony ...
> 
> Czy wg Ciebie zaszyfrowanie bazy danych spełnia wymogi w zakresie usunięcia
> danych osobowych na życzenie klienta?
> 
> -- 
> pozdrawiam
> Roman Tyczka

Ale jaki to ma związek z szyfrowaniem pliku danych? Zarządzanie danymi w sensie logiki biznesowej ma się chyba nijak do wymagać RODO. Jeśli dane mają być dodane / modyfikowane / usunięte to sprawa interfejsu do tych danych. Mnie chodzi o to, że ustawa przewiduje odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)   
---
Roman

On Thu, 5 Apr 2018 03:03:53 -0700 (PDT), kameleonsql@gmail.com wrote:

>>>> Niestety RODO wprowadzi dużo zmian ale nie jest nią proces szyfrowania bazy danych. 
>>>> Jedną z założeń dotyczących bazy danych jest przestrzeganie prawa do zapomnienia danych, czyli podanie bazy procesowi anonimizacji danych wrażliwych. Proces szyfrowania danych nie spełnia tych warunków. 
>>>> 
>>>> Proces szyfrowania spełnia wymagania RODO pod względem zabezpieczenia komputera (w rozumieniu stacji roboczym użytkownika) przed dostępem osób trzecich.
>>> 
>>> Nie masz racji. Wiele spotkań już w tym temacie odbyłem i raczej oczywistym jest, że to plik zawierający dane wrażliwe ma być tak zabezpieczony by dostęp do danych w nim zawartych był utrudniony ...
>> 
>> Czy wg Ciebie zaszyfrowanie bazy danych spełnia wymogi w zakresie usunięcia
>> danych osobowych na życzenie klienta?
> 
> Ale jaki to ma związek z szyfrowaniem pliku danych? Zarządzanie danymi w sensie logiki biznesowej ma się chyba nijak do wymagać RODO. Jeśli dane mają być dodane / modyfikowane / usunięte to sprawa interfejsu do tych danych. Mnie chodzi o to, że ustawa przewiduje odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)   

Nie znam szczegółowo tych ustaw, ani starych, ani nowych, ale jeśli wrócimy
do początkowego pytania to i poprzednio obowiązkiem administratora danych
było ich zabezpieczenie przed dostępem osób niepowołanych co implikowało
dokładnie takie same skutki jak teraz. Gdyby kiedyś bazę ktoś ukradł to też
jej zaszyfrowanie utrudniłoby lub uniemożliwiło do niej dostęp. Zatem te
dywagacje wydają się nieistotne.

-- 
pozdrawiam
Roman Tyczka

W dniu czwartek, 5 kwietnia 2018 10:09:10 UTC+2 użytkownik kamel...@gmail.com napisał:
> W dniu czwartek, 5 kwietnia 2018 08:38:40 UTC+2 użytkownik cichy napisał:
> > Niestety RODO wprowadzi dużo zmian ale nie jest nią proces szyfrowania bazy danych. 
> > Jedną z założeń dotyczących bazy danych jest przestrzeganie prawa do zapomnienia danych, czyli podanie bazy procesowi anonimizacji danych wrażliwych. Proces szyfrowania danych nie spełnia tych warunków. 
> > 
> > Proces szyfrowania spełnia wymagania RODO pod względem zabezpieczenia komputera (w rozumieniu stacji roboczym użytkownika) przed dostępem osób trzecich.
> 
> Nie masz racji. Wiele spotkań już w tym temacie odbyłem i raczej oczywistym jest, że to plik zawierający dane wrażliwe ma być tak zabezpieczony by dostęp do danych w nim zawartych był utrudniony ...
> 
> Roman



Pani Romanie, 
Zgadam się z Tobą, dane w twojej firmie/korporacji powinny a nawet musza być zaszyfrowane w ramach RODO, bo takie są wymogi. I aktualne w mojej korporacji twa proces szyfrowania serwerów, komputerów, poczty a nawet telefonów komórkowych wszytko w jednym celu, jeśli dany sprzęt znajdzie w niepowołanych rękach to nie było dostęp u do danych. Swoja drogą do tej pory wszystko mieliśmy szyfrowane dane (nawet bez rozporządzenia RODO) a teraz jeszcze bardziej zwiększają w korporacji bezpieczeństwo danych i autoryzacji.  
Jednak cały ten proces szyfrowania nie spełnia jednego zasadniczego założenia RODO a mianowicie anonimizacji danych. Przykładowo jeśli masz dane w bazie typu imię/nazwisko i przyjdzie do firmy Jan Nowak z wnioskiem o zapomnieniem jego danych a my jego imię  nazwisko zaszyfrujemy to według prawnika nie jest to proces zapomnienia danych. Według prawników sformułowanie pojęcia anomizanji (zapomnienia) polega na trwałym zamazaniu/usunięciu danych w takiej postaci, aby ich ponowę odtworzenie nie było możliwe. 
Może Pan zaszyfrować dane w bazie, całą bazę, cały dysk, cały komputer ale jeśli dane wnioskującego nie zostaną podane procesowi anomizacji to Pana firma poniesie duże kary finansowe.
Ja w swoim procesie dostosowania systemów do RODO ponad 60% czasu pochłonęła analiza prawa przeprowadzona przez zespół prawników i dyskusje które dane i kiedy można anonimizować. 

W dniu piątek, 6 kwietnia 2018 10:22:41 UTC+2 użytkownik cichy napisał:
> W dniu czwartek, 5 kwietnia 2018 10:09:10 UTC+2 użytkownik kamel...@gmail.com napisał:
> > W dniu czwartek, 5 kwietnia 2018 08:38:40 UTC+2 użytkownik cichy napisał:
> > > Niestety RODO wprowadzi dużo zmian ale nie jest nią proces szyfrowania bazy danych. 
> > > Jedną z założeń dotyczących bazy danych jest przestrzeganie prawa do zapomnienia danych, czyli podanie bazy procesowi anonimizacji danych wrażliwych. Proces szyfrowania danych nie spełnia tych warunków. 
> > > 
> > > Proces szyfrowania spełnia wymagania RODO pod względem zabezpieczenia komputera (w rozumieniu stacji roboczym użytkownika) przed dostępem osób trzecich.
> > 
> > Nie masz racji. Wiele spotkań już w tym temacie odbyłem i raczej oczywistym jest, że to plik zawierający dane wrażliwe ma być tak zabezpieczony by dostęp do danych w nim zawartych był utrudniony ...
> > 
> > Roman
> 
> 
> 
> Pani Romanie, 
> Zgadam się z Tobą, dane w twojej firmie/korporacji powinny a nawet musza być zaszyfrowane w ramach RODO, bo takie są wymogi. I aktualne w mojej korporacji twa proces szyfrowania serwerów, komputerów, poczty a nawet telefonów komórkowych wszytko w jednym celu, jeśli dany sprzęt znajdzie w niepowołanych rękach to nie było dostęp u do danych. Swoja drogą do tej pory wszystko mieliśmy szyfrowane dane (nawet bez rozporządzenia RODO) a teraz jeszcze bardziej zwiększają w korporacji bezpieczeństwo danych i autoryzacji.  
> Jednak cały ten proces szyfrowania nie spełnia jednego zasadniczego założenia RODO a mianowicie anonimizacji danych. Przykładowo jeśli masz dane w bazie typu imię/nazwisko i przyjdzie do firmy Jan Nowak z wnioskiem o zapomnieniem jego danych a my jego imię  nazwisko zaszyfrujemy to według prawnika nie jest to proces zapomnienia danych. Według prawników sformułowanie pojęcia anomizanji (zapomnienia) polega na trwałym zamazaniu/usunięciu danych w takiej postaci, aby ich ponowę odtworzenie nie było możliwe. 
> Może Pan zaszyfrować dane w bazie, całą bazę, cały dysk, cały komputer ale jeśli dane wnioskującego nie zostaną podane procesowi anomizacji to Pana firma poniesie duże kary finansowe.
> Ja w swoim procesie dostosowania systemów do RODO ponad 60% czasu pochłonęła analiza prawa przeprowadzona przez zespół prawników i dyskusje które dane i kiedy można anonimizować.

Super, 
dzięki za garść fachowych informacji, też spotykamy się z prawnikami i różnymi opiniami na temat RODO. Poza tym głownie interesuje mnie aspekt tego
(to już off-topic), czy producent / autor Aplikacji służącej do gromadzenia danych musi dostarczyć rozwiązanie z np. szyfrowaną bazą danych, czy może to mieć ofercie np. jako opcje ?

W dniu piątek, 6 kwietnia 2018 12:48:55 UTC+2 użytkownik kamel...@gmail.com napisał:

> Super, 
> dzięki za garść fachowych informacji, też spotykamy się z prawnikami i różnymi opiniami na temat RODO. Poza tym głownie interesuje mnie aspekt tego
> (to już off-topic), czy producent / autor Aplikacji służącej do gromadzenia danych musi dostarczyć rozwiązanie z np. szyfrowaną bazą danych, czy może to mieć ofercie np. jako opcje ?

Też się spotykamy, ale nikt nigdzie nie mówił o szyfrowaniu bazy danych. Bo i po co? Faktycznie producent oprogramowania może mieć w delikatnym poważaniu RODO w odniesieniu do swojego produktu, co najwyżej straci klienta. 
Niemniej - zakładając że to nie jest program z bazą na komputerze u pani Tereski (nie obrażając Teresek) - to szyfrowanie bazy nie ma sensu. Oczywiście administrator może szyfrować dyski serwera, ale znowu - po co? Ktoś wyniesie szafę serwerową? Ktoś wykręci dyski? No więc właśnie nie - zabezpieczony ma być dostęp do takich miejsc odpowiednimi uprawnieniami. Po stronie aplikacji co jedyne to można wprowadzić szyfrowane połączenia klientów z bazą, ale to też tylko w wypadku "zdalnych" dostępów. Chociaż znowu RODO wymaga połączeń szyfrowanych ale na poziomie tunelu czyli samego VPN.
Ogólnie - rozmawiając z praktykami (bo są firmy które mają nawet mocniejsze zabezpieczenia niż wymaga RODO) a nie prawnikami, dochodzę do wniosku, że jak zwykle nasi rządzący chcą być świętsi od papieża i wychodzą przed szereg wprowadzając idiotyczne obostrzenia.
Bo rozmawiając ostatnio z prawnikami niektórzy z nich doszli do wniosku że rozwiązania cloudowe nie mogą być użytkowane jeśli wprowadzi się wszystkie zalecenia RODO, a to ze względu na brak bezpośredniego nadzoru nad miejscem przechowywania danych. :)

PS. To szyfrowanie bazy danych przypomina mi sytuację, gdzie klient się upierał nad dokumentami podpisywanymi podpisem elektronicznym, z tym że on chciał takie "podpisane" dokumenty drukować :/

pozdrawiam,
Przemek O.

W dniu piątek, 6 kwietnia 2018 15:36:11 UTC+2 użytkownik immo napisał:
> W dniu piątek, 6 kwietnia 2018 12:48:55 UTC+2 użytkownik kamel...@gmail.com napisał:
> 
> > Super, 
> > dzięki za garść fachowych informacji, też spotykamy się z prawnikami i różnymi opiniami na temat RODO. Poza tym głownie interesuje mnie aspekt tego
> > (to już off-topic), czy producent / autor Aplikacji służącej do gromadzenia danych musi dostarczyć rozwiązanie z np. szyfrowaną bazą danych, czy może to mieć ofercie np. jako opcje ?
> 
> Też się spotykamy, ale nikt nigdzie nie mówił o szyfrowaniu bazy danych. Bo i po co? Faktycznie producent oprogramowania może mieć w delikatnym poważaniu RODO w odniesieniu do swojego produktu, co najwyżej straci klienta. 
> Niemniej - zakładając że to nie jest program z bazą na komputerze u pani Tereski (nie obrażając Teresek) - to szyfrowanie bazy nie ma sensu. Oczywiście administrator może szyfrować dyski serwera, ale znowu - po co? Ktoś wyniesie szafę serwerową? Ktoś wykręci dyski? No więc właśnie nie - zabezpieczony ma być dostęp do takich miejsc odpowiednimi uprawnieniami. Po stronie aplikacji co jedyne to można wprowadzić szyfrowane połączenia klientów z bazą, ale to też tylko w wypadku "zdalnych" dostępów. Chociaż znowu RODO wymaga połączeń szyfrowanych ale na poziomie tunelu czyli samego VPN.
> Ogólnie - rozmawiając z praktykami (bo są firmy które mają nawet mocniejsze zabezpieczenia niż wymaga RODO) a nie prawnikami, dochodzę do wniosku, że jak zwykle nasi rządzący chcą być świętsi od papieża i wychodzą przed szereg wprowadzając idiotyczne obostrzenia.
> Bo rozmawiając ostatnio z prawnikami niektórzy z nich doszli do wniosku że rozwiązania cloudowe nie mogą być użytkowane jeśli wprowadzi się wszystkie zalecenia RODO, a to ze względu na brak bezpośredniego nadzoru nad miejscem przechowywania danych. :)
> 
> PS. To szyfrowanie bazy danych przypomina mi sytuację, gdzie klient się upierał nad dokumentami podpisywanymi podpisem elektronicznym, z tym że on chciał takie "podpisane" dokumenty drukować :/
> 
> pozdrawiam,
> Przemek O.

Przemek O, 

Nasza interpretacja "dostępu do pliku danych" z danymi wrażliwymi jest jednak inna (również prawników). Nie ma znaczenia, w jaki sposób utrudnisz dostęp do pliku w lokalizacji gdzie on się znajduje, na jakim sprzęcie "leży". RODO raczej jasno "nakazuje" by jeśli "plik z danymi wrażliwymi" dostanie się  w niepowołane ręce (np. zostanie skopiowany), to by był tak zabezpieczony by dostęp do danych w nim zawartych był utrudniony. Moja firma pracuje nad szyfrowaniem pliku bazy (FB 3.0) i już praktycznie mamy to opracowane  i jesteśmy w końcowej fazie testowania. Będziemy oferowali rozwiązanie z bazą szyfrowaną lub nie, decyzje podejmie końcowy użytkownik.

---
Pozdrawiam
Roman

W dniu środa, 11 kwietnia 2018 12:53:15 UTC+2 użytkownik kamel...@gmail.com napisał:

> Nasza interpretacja "dostępu do pliku danych" z danymi wrażliwymi jest jednak inna (również prawników). Nie ma znaczenia, w jaki sposób utrudnisz dostęp do pliku w lokalizacji gdzie on się znajduje, na jakim sprzęcie "leży". RODO raczej jasno "nakazuje" by jeśli "plik z danymi wrażliwymi" dostanie się  w niepowołane ręce (np. zostanie skopiowany), to by był tak zabezpieczony by dostęp do danych w nim zawartych był utrudniony. Moja firma 

No i jak zwykle problem rozbija się o to, jakich kto ma prawników i jak kto interpretuje zapisy które jak zwykle nie mówią nic wprost.
Rozumiem że klucz do szyfrowania bazy też będzie zaszyfrowany? Bo jak wpadnie w niepowołane ręce razem z bazą to dostęp będzie bezproblemowy :P

> pracuje nad szyfrowaniem pliku bazy (FB 3.0) i już praktycznie mamy to opracowane  i jesteśmy w końcowej fazie testowania. Będziemy oferowali rozwiązanie z bazą szyfrowaną lub nie, decyzje podejmie końcowy użytkownik.

FB nie ma szyfrowania samo w sobie? 
Poza tym już widzę przetargi z wymogiem szyfrowania pliku bazy danych które preferują tylko jedne rozwiązanie...
Druga sprawa - jak z wydajnością takiego rozwiązania gdzie szyfrowany jest plik bazy danych? 
Kolejna - co zrobić jeśli baza nie jest plikowa? Co szyfrować?

W ustawie nigdzie nie ma napisane że szyfrowany ma być plik bazy danych. Jedynie że mają być utrudnione możliwości odczytu danych z bazy. I uwaga - baza!=plik!

pozdrawiam,
Przemek O.

W dniu piątek, 6 kwietnia 2018 10:22:41 UTC+2 użytkownik cichy napisał:
> W dniu czwartek, 5 kwietnia 2018 10:09:10 UTC+2 użytkownik kamel...@gmail.com napisał:

> Jednak cały ten proces szyfrowania nie spełnia jednego zasadniczego założenia RODO a mianowicie anonimizacji danych. Przykładowo jeśli masz dane w bazie typu imię/nazwisko i przyjdzie do firmy Jan Nowak z wnioskiem o zapomnieniem jego danych a my jego imię  nazwisko zaszyfrujemy to według prawnika nie jest to proces zapomnienia danych. Według prawników sformułowanie pojęcia anomizanji (zapomnienia) polega na trwałym zamazaniu/usunięciu danych w takiej postaci, aby ich ponowę odtworzenie nie było możliwe. 

Szkoda tylko, że owo RODO nie jest zgodne z toną innych przepisów/ustaw które nie pozwalają na owo 'zapomnienie' danych :) A wręcz wymagają przechowywania takich danych przez określony czas (czasami nawet dożywotnio).

pozdrawiam,
Przemek O.

W dniu środa, 11 kwietnia 2018 13:32:07 UTC+2 użytkownik immo napisał:
> W dniu piątek, 6 kwietnia 2018 10:22:41 UTC+2 użytkownik cichy napisał:
> > W dniu czwartek, 5 kwietnia 2018 10:09:10 UTC+2 użytkownik kamel...@gmail.com napisał:
> 
> > Jednak cały ten proces szyfrowania nie spełnia jednego zasadniczego założenia RODO a mianowicie anonimizacji danych. Przykładowo jeśli masz dane w bazie typu imię/nazwisko i przyjdzie do firmy Jan Nowak z wnioskiem o zapomnieniem jego danych a my jego imię  nazwisko zaszyfrujemy to według prawnika nie jest to proces zapomnienia danych. Według prawników sformułowanie pojęcia anomizanji (zapomnienia) polega na trwałym zamazaniu/usunięciu danych w takiej postaci, aby ich ponowę odtworzenie nie było możliwe. 
> 
> Szkoda tylko, że owo RODO nie jest zgodne z toną innych przepisów/ustaw które nie pozwalają na owo 'zapomnienie' danych :) A wręcz wymagają przechowywania takich danych przez określony czas (czasami nawet dożywotnio).
> 
> pozdrawiam,
> Przemek O.

No i mamy to !!! :)

Szyfrowane bazy muszą być w wersji Firebird 3.0 tutaj coś więcej https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html

Wydajność bazy z dość dużą ilością blob'ow (baza zawiera obrazy wszystkich dokumentów w formacie PDF, plus zdjecią części B2B/B2C) spada o około 10% (dyski ssd). 

Mamy zamiar dystrybuować swój plugin (biblioteka dll 32/64) firmą trzecim (cena tego https://www.ibphoenix.com/products/software/encryptionplugin to 2500 $), nasza jest dużo korzystniejsza :). Zainteresowanych zapraszam do kontaktu na priv.

Pozdrawiam
---
Roman 

> Mamy zamiar dystrybuować swój plugin (biblioteka dll 32/64) firmą trzecim (cena tego https://www.ibphoenix.com/products/software/encryptionplugin to 2500 $), nasza jest dużo korzystniejsza :). Zainteresowanych zapraszam do kontaktu na priv.

Osobiście się tym nie interesowałem ale ciekawy jestem jaka jest różnica 
miedzy tym pluginem a np.TUniEncryptor z:
https://www.devart.com/unidac/editions.html
Może ktoś się orientuje czy TUniEncryptor może spełniać wymagania?

-- 
Pozdrawiam
Janek

W dniu wtorek, 24 kwietnia 2018 11:48:52 UTC+2 użytkownik kamel...@gmail.com napisał:
> Szyfrowane bazy muszą być w wersji Firebird 3.0 tutaj coś więcej https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html
> 

Moment moment. Cały czas była mowa o szyfrowaniu pliku bazy danych a nie o szyfrowaniu zawartości bazy danych. Dlatego też podnosiłem bezsensowność takiego rozwiązania.

Cytat z Twoich wypowiedzi: "plik zawierający dane wrażliwe ma być tak zabezpieczony", "odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)".

A tak z tego co prezentujesz to wymysliles cos co np. MSSQL ma w standardzie, cos co np. komponenty DevArta (ktorych uzywam) maja w standardzie... I co od poczatku pisalem ze jesli juz, to jest wystarczajacym zabezpieczeniem...

pozdrawiam,
Przemek O.
  

W dniu środa, 25 kwietnia 2018 08:23:28 UTC+2 użytkownik immo napisał:
> W dniu wtorek, 24 kwietnia 2018 11:48:52 UTC+2 użytkownik kamel...@gmail.com napisał:
> > Szyfrowane bazy muszą być w wersji Firebird 3.0 tutaj coś więcej https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html
> > 
> 
> Moment moment. Cały czas była mowa o szyfrowaniu pliku bazy danych a nie o szyfrowaniu zawartości bazy danych. Dlatego też podnosiłem bezsensowność takiego rozwiązania.
> 
> Cytat z Twoich wypowiedzi: "plik zawierający dane wrażliwe ma być tak zabezpieczony", "odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)".
> 
> A tak z tego co prezentujesz to wymysliles cos co np. MSSQL ma w standardzie, cos co np. komponenty DevArta (ktorych uzywam) maja w standardzie... I co od poczatku pisalem ze jesli juz, to jest wystarczajacym zabezpieczeniem...
> 
> pozdrawiam,
> Przemek O.

Witam,

Dla zainteresowanych szyfrowaniem bazy Firebird 3.0. Jest dość poważny błąd w kodzie FB, który się ujawnia dopiero przy większym rozmiarze bazy (tak bynajmniej wychodzi z naszych testów). Temat zgłosiliśmy zespołowi FB http://tracker.firebirdsql.org/browse/CORE-5830 
Jeśli ktoś chce tego szyfrowania używać to proszę się jednak zastanowić, bo po tym błędzie baz jest do wyrzucenia.

Ps.
Czekamy na poprawkę w FB 3.0

---
Pozdrawiam
Roman
 

W dniu 21-05-2018 o 08:37, kameleonsql@gmail.com pisze:
> W dniu środa, 25 kwietnia 2018 08:23:28 UTC+2 użytkownik immo napisał:
>> W dniu wtorek, 24 kwietnia 2018 11:48:52 UTC+2 użytkownik kamel...@gmail.com napisał:
>>> Szyfrowane bazy muszą być w wersji Firebird 3.0 tutaj coś więcej https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html
>>>
>>
>> Moment moment. Cały czas była mowa o szyfrowaniu pliku bazy danych a nie o szyfrowaniu zawartości bazy danych. Dlatego też podnosiłem bezsensowność takiego rozwiązania.
>>
>> Cytat z Twoich wypowiedzi: "plik zawierający dane wrażliwe ma być tak zabezpieczony", "odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)".
>>
>> A tak z tego co prezentujesz to wymysliles cos co np. MSSQL ma w standardzie, cos co np. komponenty DevArta (ktorych uzywam) maja w standardzie... I co od poczatku pisalem ze jesli juz, to jest wystarczajacym zabezpieczeniem...
>>
>> pozdrawiam,
>> Przemek O.
> 
> Witam,
> 
> Dla zainteresowanych szyfrowaniem bazy Firebird 3.0. Jest dość poważny błąd w kodzie FB, który się ujawnia dopiero przy większym rozmiarze bazy (tak bynajmniej wychodzi z naszych testów). Temat zgłosiliśmy zespołowi FB http://tracker.firebirdsql.org/browse/CORE-5830
> Jeśli ktoś chce tego szyfrowania używać to proszę się jednak zastanowić, bo po tym błędzie baz jest do wyrzucenia.
> 
> Ps.
> Czekamy na poprawkę w FB 3.0

I co pomogły poprawki, bo widzę że już ukazała  się wersja po 
3.0.4.32974 czyli 3.0.4.32977 ?

miab

W dniu środa, 23 maja 2018 09:11:59 UTC+2 użytkownik miab napisał:
> W dniu 21-05-2018 o 08:37, kameleonsql@gmail.com pisze:
> > W dniu środa, 25 kwietnia 2018 08:23:28 UTC+2 użytkownik immo napisał:
> >> W dniu wtorek, 24 kwietnia 2018 11:48:52 UTC+2 użytkownik kamel...@gmail.com napisał:
> >>> Szyfrowane bazy muszą być w wersji Firebird 3.0 tutaj coś więcej https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html
> >>>
> >>
> >> Moment moment. Cały czas była mowa o szyfrowaniu pliku bazy danych a nie o szyfrowaniu zawartości bazy danych. Dlatego też podnosiłem bezsensowność takiego rozwiązania.
> >>
> >> Cytat z Twoich wypowiedzi: "plik zawierający dane wrażliwe ma być tak zabezpieczony", "odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)".
> >>
> >> A tak z tego co prezentujesz to wymysliles cos co np. MSSQL ma w standardzie, cos co np. komponenty DevArta (ktorych uzywam) maja w standardzie... I co od poczatku pisalem ze jesli juz, to jest wystarczajacym zabezpieczeniem...
> >>
> >> pozdrawiam,
> >> Przemek O.
> > 
> > Witam,
> > 
> > Dla zainteresowanych szyfrowaniem bazy Firebird 3.0. Jest dość poważny błąd w kodzie FB, który się ujawnia dopiero przy większym rozmiarze bazy (tak bynajmniej wychodzi z naszych testów). Temat zgłosiliśmy zespołowi FB http://tracker.firebirdsql.org/browse/CORE-5830
> > Jeśli ktoś chce tego szyfrowania używać to proszę się jednak zastanowić, bo po tym błędzie baz jest do wyrzucenia.
> > 
> > Ps.
> > Czekamy na poprawkę w FB 3.0
> 
> I co pomogły poprawki, bo widzę że już ukazała  się wersja po 
> 3.0.4.32974 czyli 3.0.4.32977 ?
> 
> miab

Testujemy,
Napisze co i jak ...

---
Roman

W dniu środa, 23 maja 2018 09:11:59 UTC+2 użytkownik miab napisał:
> W dniu 21-05-2018 o 08:37, kameleonsql@gmail.com pisze:
> > W dniu środa, 25 kwietnia 2018 08:23:28 UTC+2 użytkownik immo napisał:
> >> W dniu wtorek, 24 kwietnia 2018 11:48:52 UTC+2 użytkownik kamel...@gmail.com napisał:
> >>> Szyfrowane bazy muszą być w wersji Firebird 3.0 tutaj coś więcej https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html
> >>>
> >>
> >> Moment moment. Cały czas była mowa o szyfrowaniu pliku bazy danych a nie o szyfrowaniu zawartości bazy danych. Dlatego też podnosiłem bezsensowność takiego rozwiązania.
> >>
> >> Cytat z Twoich wypowiedzi: "plik zawierający dane wrażliwe ma być tak zabezpieczony", "odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)".
> >>
> >> A tak z tego co prezentujesz to wymysliles cos co np. MSSQL ma w standardzie, cos co np. komponenty DevArta (ktorych uzywam) maja w standardzie... I co od poczatku pisalem ze jesli juz, to jest wystarczajacym zabezpieczeniem...
> >>
> >> pozdrawiam,
> >> Przemek O.
> > 
> > Witam,
> > 
> > Dla zainteresowanych szyfrowaniem bazy Firebird 3.0. Jest dość poważny błąd w kodzie FB, który się ujawnia dopiero przy większym rozmiarze bazy (tak bynajmniej wychodzi z naszych testów). Temat zgłosiliśmy zespołowi FB http://tracker.firebirdsql.org/browse/CORE-5830
> > Jeśli ktoś chce tego szyfrowania używać to proszę się jednak zastanowić, bo po tym błędzie baz jest do wyrzucenia.
> > 
> > Ps.
> > Czekamy na poprawkę w FB 3.0
> 
> I co pomogły poprawki, bo widzę że już ukazała  się wersja po 
> 3.0.4.32974 czyli 3.0.4.32977 ?
> 
> miab

Po bieżących testach nie wystąpiły błędy szyfrowania. Chyba można powiedzieć, że poprawka 3.0.4.32977 problem rozwiązała. Naszą wtyczkę
zaczynamy dystrybuować w naszych rozwiązaniach od 06/2018. Czyli czas 
prawdy nadejdzie niebawem :) 
---
Roman

W dniu niedziela, 27 maja 2018 09:53:58 UTC+2 użytkownik kamel...@gmail.com napisał:
> W dniu środa, 23 maja 2018 09:11:59 UTC+2 użytkownik miab napisał:
> > W dniu 21-05-2018 o 08:37, kameleonsql@gmail.com pisze:
> > > W dniu środa, 25 kwietnia 2018 08:23:28 UTC+2 użytkownik immo napisał:
> > >> W dniu wtorek, 24 kwietnia 2018 11:48:52 UTC+2 użytkownik kamel...@gmail.com napisał:
> > >>> Szyfrowane bazy muszą być w wersji Firebird 3.0 tutaj coś więcej https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html
> > >>>
> > >>
> > >> Moment moment. Cały czas była mowa o szyfrowaniu pliku bazy danych a nie o szyfrowaniu zawartości bazy danych. Dlatego też podnosiłem bezsensowność takiego rozwiązania.
> > >>
> > >> Cytat z Twoich wypowiedzi: "plik zawierający dane wrażliwe ma być tak zabezpieczony", "odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)".
> > >>
> > >> A tak z tego co prezentujesz to wymysliles cos co np. MSSQL ma w standardzie, cos co np. komponenty DevArta (ktorych uzywam) maja w standardzie... I co od poczatku pisalem ze jesli juz, to jest wystarczajacym zabezpieczeniem...
> > >>
> > >> pozdrawiam,
> > >> Przemek O.
> > > 
> > > Witam,
> > > 
> > > Dla zainteresowanych szyfrowaniem bazy Firebird 3.0. Jest dość poważny błąd w kodzie FB, który się ujawnia dopiero przy większym rozmiarze bazy (tak bynajmniej wychodzi z naszych testów). Temat zgłosiliśmy zespołowi FB http://tracker.firebirdsql.org/browse/CORE-5830
> > > Jeśli ktoś chce tego szyfrowania używać to proszę się jednak zastanowić, bo po tym błędzie baz jest do wyrzucenia.
> > > 
> > > Ps.
> > > Czekamy na poprawkę w FB 3.0
> > 
> > I co pomogły poprawki, bo widzę że już ukazała  się wersja po 
> > 3.0.4.32974 czyli 3.0.4.32977 ?
> > 
> > miab
> 
> Po bieżących testach nie wystąpiły błędy szyfrowania. Chyba można powiedzieć, że poprawka 3.0.4.32977 problem rozwiązała. Naszą wtyczkę
> zaczynamy dystrybuować w naszych rozwiązaniach od 06/2018. Czyli czas 
> prawdy nadejdzie niebawem :) 
> ---
> Roman

Niestety, problemów ciąg dalszy :(
http://tracker.firebirdsql.org/browse/CORE-5836
---
Roman

W dniu wtorek, 29 maja 2018 11:58:33 UTC+2 użytkownik kamel...@gmail.com napisał:
> W dniu niedziela, 27 maja 2018 09:53:58 UTC+2 użytkownik kamel...@gmail.com napisał:
> > W dniu środa, 23 maja 2018 09:11:59 UTC+2 użytkownik miab napisał:
> > > W dniu 21-05-2018 o 08:37, kameleonsql@gmail.com pisze:
> > > > W dniu środa, 25 kwietnia 2018 08:23:28 UTC+2 użytkownik immo napisał:
> > > >> W dniu wtorek, 24 kwietnia 2018 11:48:52 UTC+2 użytkownik kamel...@gmail.com napisał:
> > > >>> Szyfrowane bazy muszą być w wersji Firebird 3.0 tutaj coś więcej https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html
> > > >>>
> > > >>
> > > >> Moment moment. Cały czas była mowa o szyfrowaniu pliku bazy danych a nie o szyfrowaniu zawartości bazy danych. Dlatego też podnosiłem bezsensowność takiego rozwiązania.
> > > >>
> > > >> Cytat z Twoich wypowiedzi: "plik zawierający dane wrażliwe ma być tak zabezpieczony", "odpowiedzialność właściciela pliku danych jeśli on zostanie np. skradziony i dostęp do pliku nie będzie utrudniony (np. szyfrowany)".
> > > >>
> > > >> A tak z tego co prezentujesz to wymysliles cos co np. MSSQL ma w standardzie, cos co np. komponenty DevArta (ktorych uzywam) maja w standardzie... I co od poczatku pisalem ze jesli juz, to jest wystarczajacym zabezpieczeniem...
> > > >>
> > > >> pozdrawiam,
> > > >> Przemek O.
> > > > 
> > > > Witam,
> > > > 
> > > > Dla zainteresowanych szyfrowaniem bazy Firebird 3.0. Jest dość poważny błąd w kodzie FB, który się ujawnia dopiero przy większym rozmiarze bazy (tak bynajmniej wychodzi z naszych testów). Temat zgłosiliśmy zespołowi FB http://tracker.firebirdsql.org/browse/CORE-5830
> > > > Jeśli ktoś chce tego szyfrowania używać to proszę się jednak zastanowić, bo po tym błędzie baz jest do wyrzucenia.
> > > > 
> > > > Ps.
> > > > Czekamy na poprawkę w FB 3.0
> > > 
> > > I co pomogły poprawki, bo widzę że już ukazała  się wersja po 
> > > 3.0.4.32974 czyli 3.0.4.32977 ?
> > > 
> > > miab
> > 
> > Po bieżących testach nie wystąpiły błędy szyfrowania. Chyba można powiedzieć, że poprawka 3.0.4.32977 problem rozwiązała. Naszą wtyczkę
> > zaczynamy dystrybuować w naszych rozwiązaniach od 06/2018. Czyli czas 
> > prawdy nadejdzie niebawem :) 
> > ---
> > Roman
> 
> Niestety, problemów ciąg dalszy :(
> http://tracker.firebirdsql.org/browse/CORE-5836
> ---
> Roman

OK, temat opanowany. Działa produkcyjnie na bazie 7 GB.
Powiem tak, proste to, to nie jest, koryta krwi i morze potu ...
Ale cóż, no programowanie dla każdego nie jest :)

---
Pozdrawia

Ps. Ktoś ma ochotę zerknąć co i jak, to proszę https://wilksoft.pl/media-user/wilk/faq/kameleon_crt.pdf  

Roman

On Mon, 4 Jun 2018 04:36:40 -0700 (PDT), kameleonsql@gmail.com wrote:


>> Niestety, problemów ciąg dalszy :(
>> http://tracker.firebirdsql.org/browse/CORE-5836
>> ---
>> Roman
> 
> OK, temat opanowany. Działa produkcyjnie na bazie 7 GB.

I co było tym razem? Bo widzę, że na trackerze FB błędu nie potwierdzili.

-- 
pozdrawiam
Roman Tyczka

W dniu wtorek, 5 czerwca 2018 13:24:14 UTC+2 użytkownik Roman Tyczka napisał:
> On Mon, 4 Jun 2018 04:36:40 -0700 (PDT), kameleonsql@gmail.com wrote:
> 
> 
> >> Niestety, problemów ciąg dalszy :(
> >> http://tracker.firebirdsql.org/browse/CORE-5836
> >> ---
> >> Roman
> > 
> > OK, temat opanowany. Działa produkcyjnie na bazie 7 GB.
> 
> I co było tym razem? Bo widzę, że na trackerze FB błędu nie potwierdzili.
> 
> -- 
> pozdrawiam
> Roman Tyczka

No jak zwykle :)
Oni wszystkiego nie napiszą, my o wszystkim nie powiemy ...
Trzeba było napisać wtyczkę na podstawie swoich doświadczeń i żmudnych testów. Plus taki, że teraz działa nawet w oficjalną dystrybucją.
---
Pozdrawiam