Temat: Jak prawidłowo podejśćdo szyfrowania zawartości bazy danych

Witam,

macie może jakieś przemyślenia wynikające z doświadczenia? Muszę w bazie danych SQL (niezależnie od jej typu). szyfrować część kolumn z części tabel bazy.

Macie pomysły na jakieś "niekanoniczne" rozwiązanie, przy którym można by było się mniej napracować.

BTW: wiem że w MS SQL Server od chyba wersji 2008 można korzystać z "przezroczystego" szyfrowania całej bazy, ale akurat docelowa baza to nie MS SQL Server

PozdrawiamTen post został edytowany przez Autora dnia 18.08.17 o godzinie 15:12

Temat: Jak prawidłowo podejśćdo szyfrowania zawartości bazy danych

Po co?

A odpowiedź na pytanie: skoro niezależnie od typy bazy to nie da się w bazie.Ten post został edytowany przez Autora dnia 18.08.17 o godzinie 21:27

Temat: Jak prawidłowo podejśćdo szyfrowania zawartości bazy danych

A ja w sumie chciałbym zrozumieć dlaczego kolumna "A" ma być szyfrowana a kolumna "B" nie w mojej tabeli... jakie jest uzasadnienie biznesowe?

Jeżeli dane w bazie wymagają zaszyfrowania bo są wrażliwe to może lepiej dane przenieść na oddzielny wolumen i ten zaszyfrować. Dane wewnątrz bazy nie są szyfrowane ale bez podmontowania zaszyfrowanego wolumenu dane będą zabezpieczone poprawnie.

Dodatkowo nie znajdziesz gotowca na coś takiego. W PostgreSQL jest extension pgcrypto którym można szyfrować tabele a nawet kolumny. Można też użyć funkcji implementujących pgp.
Niestety dostęp do danych jest rozwiązywany na poziomie zapytań SQL czyli wymagana zmiana w aplikacjach/usługach korzystających z danych lub tworzenie funkcji wewnątrz bazy do decrypt'u. Ale nadal gdzieś trzeba przechowywać klucze deszyfrujące.. gdzie?

Myślę, że najprościej zaszyfrować wolumen z plikami bazy.

Temat: Jak prawidłowo podejśćdo szyfrowania zawartości bazy danych

Marcin M.:
A ja w sumie chciałbym zrozumieć dlaczego kolumna "A" ma być szyfrowana a kolumna "B" nie w mojej tabeli... jakie jest uzasadnienie biznesowe?

Kolumny niezaszyfrowane byłyby używane w zapytaniach do bazy (są tam dane nie-wrażliwe).
Martwi mnie, że zaszyfrowane wartości nie mogą być już "normalnie" używane w zapytaniach SQL.

Pozdrawiam

Temat: Jak prawidłowo podejśćdo szyfrowania zawartości bazy danych

Maciej G.:
macie może jakieś przemyślenia wynikające z doświadczenia?

Przede wszystkim odpowiedzieć sobie dlaczego baza ma być chroniona. Zbyt ogólne i banalne pytanie? Nie sądzę, bo odpowiedź na to pytanie powinna dać odpowiedź na całą listę pytań szczegółowych:
- jak udostępniać bazę na poziomie sieci?
- jakie mechanizmy bezpieczeństwa są niezbędne?
- jak z chronionej bazy mają korzystać użytkownicy?
- definicja uprawnień do plików bazodanowych (poziomi systemu opreacyjnego, dostęp do plików)?
- które funkcjonalności oferowane przez bazę danych mają być ograniczone?
- jaki logowanie dostępu do bazy danych (Active directory, SQL)?
- jakie szyfrowanie jest niezbędne?
- liczba poziomów bezpieczeństwa?
- jak zagwatantować bezpieczeństwo po stronie aplikacji korzystających z bazy danych?
- gdzie składować dane w systemie plików (dysk, foledr, chmura)?
- jakie kopie zapasowe (full, przyrostowo, ..)?
- ..?
To tak tytułem prawidłowego podejścia.

Martwi mnie, że zaszyfrowane wartości nie mogą być już "normalnie"
używane w zapytaniach SQL.

Tego się nie przeskoczy, więc odpowiedź na pytania o sposób użytkowania bazy danych bezcenna. ;-)

Marcin M.:
A ja w sumie chciałbym zrozumieć dlaczego kolumna "A" ma być szyfrowana
a kolumna "B" nie w mojej tabeli... jakie jest uzasadnienie biznesowe?

No cóż, szyfrowanie wszystkich informacji ze wszystkich kolumn poważnie ogranicza liczbę odbiorców, a w konsekwencji przydatność i niekoniecznie jest niezbędne. Np: szyfrujemy klucze dostępu do tabeli, np: username, password i tylko w ten sposób aplikacja użytkowa może mieć dostęp do danych, ale nie programista, który ma pełen przegląd danych w postaci jawnej.

Jeżeli programiści mają dane w postaci zaszyfrowanej to nie programiści testują swój kod, itd., itp. itd., co ma swoje berdzo konkretne uzasadnienie biznesowe. Czy tak zrobić dowiemy się jak odpowiemy sobie na moje pierwsze pytanie ogólne.