Czy powinienem szyfrować dane w bazie danych?

16

Mam klienta, dla którego zamierzam stworzyć aplikację internetową dotyczącą opieki nad pacjentami, zarządzania pacjentami, konsultacji, historii, kalendarzy i wszystkiego w tym zakresie.

Problem polega na tym, że są to wrażliwe dane, historia pacjenta itp.

Klient nalega na szyfrowanie danych na poziomie bazy danych, ale myślę, że to pogorszy wydajność aplikacji internetowej. (Ale może nie powinienem się tym martwić)

Przeczytałem przepisy dotyczące ochrony danych w kwestiach zdrowotnych (Portugalia), ale nie jestem zbyt konkretny w tej kwestii (właśnie je przesłuchałem, czekam na ich odpowiedź).

Przeczytałem następujący link , ale moje pytanie jest inne, czy mam zaszyfrować dane w bazie danych, czy nie.

Jednym z problemów, które przewiduję przy szyfrowaniu danych, jest to, że będę potrzebować klucza, może to być hasło użytkownika, ale wszyscy wiemy, jakie są hasła użytkowników (12345 itp.) I generowanie klucza, który musiałbym przechowywać to gdzieś oznacza to, że programista, dba, cokolwiek może mieć do niego dostęp, jakieś przemyślenia na ten temat?

Nawet dodanie losowej soli do hasła użytkownika nie rozwiąże problemu, ponieważ zawsze mogę uzyskać do niego dostęp, a zatem odszyfrować dane.

Tio
źródło
1
Jestem raczej deweloperem po stronie klienta, ale podejrzewam, że zaszyfrowanie wszystkiego zmniejszyłoby dane, a nie bardziej bezpieczne, jeśli używasz tego samego klucza.
Erik Reppen
4
czy możesz umieścić całą bazę danych na zaszyfrowanym woluminie i nazwać go dniem. Pewnie odczyty / zapisy będą wolniejsze, ale zachowujesz wszystkie zalety RDMS (lub czegokolwiek używasz), podczas gdy dane na dysku są szyfrowane
DXM
2
Oznacza to również, że nie będzie można zobaczyć danych w środowisku mysql? Wszystkiego najlepszego do debugowania.
Manoj R
4
Przemysł medyczny jest ściśle regulowany. Pracujący tam profesjonaliści przyzwyczaili się, że ktoś powie im, jakie są zasady. Ten sposób myślenia przenosi się na projekty informatyczne. To nie jest tak naprawdę kwestia bezpieczeństwa. To kwestia kulturowa. Koszt prowadzenia działalności gospodarczej w dziedzinie medycyny.
Reactgular
1
Szpital w Wielkiej Brytanii został ukarany grzywną w wysokości ponad 300 000 funtów, ponieważ zepsute dyski zawierające niezaszyfrowane bazy danych. Informacje zdrowotne są bardzo wrażliwe.
MarkJ

Odpowiedzi:

9

Osobiście sprawdziłbym przepisy w tym zakresie. Jeśli dane wymagają zaszyfrowania, należy je zaszyfrować.

Jeśli jednak nie otrzymasz żadnych wskazówek, chciałbym chronić połączenie między pacjentem a jego danymi. Tj. Najprawdopodobniej masz plik PatientIDużywany w tabelach w całej bazie danych. PatientIDnie identyfikuje pacjenta, tylko historię medyczną pacjenta itp. Jednak, aby zidentyfikować PatientIDJoe Bloggsa mieszkającego w Rua de São Bernardo w Lizbonie, trzymałbym to w osobnej bazie danych, jeśli mogę. Użyj TDE dla danych osobowych pacjenta i rozważ zaszyfrowanie go za pomocą kluczy w swojej aplikacji internetowej.

Chociaż kradzież tych danych medycznych bez środków umożliwiających identyfikację pacjentów będzie niezwykle krępująca, nie jest prawdopodobne, aby było to coś więcej. Istnieją dosłownie internetowe konkursy, które wykorzystują te zanonimizowane dane medyczne.

Dzięki oddzieleniu danych medycznych od danych osobowych pacjenta. Użyj solidnego zestawu ról, aby ograniczyć personel do tylko tego, czego potrzebują. Z wyjątkiem personelu medycznego, który wymaga bezpośredniego kontaktu z pacjentem (pielęgniarki pierwszej linii i lekarze), nikt nie powinien mieć dostępu do obu. Recepcjonistki potrzebują tylko danych osobowych Pacjenta, personel laboratorium potrzebuje tylko dokumentacji medycznej i Identyfikatora Pacjenta, pielęgniarki chirurgiczne tylko obecnie stan zdrowia i imię.

Po zidentyfikowaniu każdego zestawu ról staraj się nie tylko zaimplementować je w aplikacji internetowej, ale także w bazie danych, a także w dodatkowej warstwie zabezpieczeń.

M Afifi
źródło
1
IANAL, ale laicy IMO nie powinni „sprawdzać prawa”, kiedy możliwa odpowiedzialność jest duża. Powinni skonsultować się z prawnikiem.
kevin cline
idę z tym podejściem jako prawdziwą odpowiedzią ... dokumentacja medyczna, która nie jest powiązana z pacjentami ani lekarzem, jest bez znaczenia i nie nadaje się nawet do analizy statystycznej, ponieważ nie ma odniesienia ani nie dowodzi, że nie jest sporządzona.
Zalaboza
13

Tak, należy zaszyfrować bazę danych.

Podstawowe szyfrowanie przechowywanych danych („dane w spoczynku”) jest ogólnie przyjętą zasadą bezpieczeństwa i jest prawdopodobnie wymagane przez prawo, jeśli w twoim kraju obowiązują przepisy chroniące dane osobowe lub zdrowotne.

Używamy SQL Server 2008, więc używamy TDE Microsoftu; może istnieć jakieś rozwiązanie strony trzeciej dla MySQL lub może po prostu zadziałałoby ogólne szyfrowanie woluminów (takie jak TrueCrypt) (chociaż chciałbym mieć coś, co zostało certyfikowane do użytku z bazą danych).

Jeśli zostanie to wykonane poprawnie, wydajność powinna być niewielka.

Nawiasem mówiąc, wspomniany link (dotyczący rozdzielenia poufnych informacji) jest czymś, co należy rozważyć oprócz podstawowego szyfrowania bazy danych.

EDYCJA: Szyfrowanie wspomniane powyżej szyfruje wolumin. Gdyby ktoś ukradł dysk twardy, dane zostałyby zaszyfrowane. Gdyby jednak ktoś uruchomił zapytania w bazie danych, zobaczyłby niezaszyfrowane dane (dlatego wspomniałem o oddzieleniu informacji, nawet jeśli OP nie chciał o tym dyskutować).

Pamiętaj, że to zalecenie ma stanowić minimum, które powinieneś zrobić. Jeśli potrzebujesz porady prawnej, to oczywiście musisz szukać gdzie indziej. Jeśli chcesz dokładniejszej dyskusji na temat pisania bezpiecznego kodu, zacznę od książki Writing Secure Code .

jdigital
źródło
2
Nie jestem pewien, czy tak jest. Pytanie nie dotyczy szyfrowania bazy danych, ale szyfrowania danych w bazie danych. Oznacza to, że dane w zapytaniach SQL będą szyfrowane.
Manoj R
1
Hit wydajności powinien być mały? Wyszukiwanie danych będzie POWOLNE. Cała koncepcja indeksowania nie działa, gdy dane są szyfrowane. Będzie to wymagało skanowania pełnego stołu.
mike30
@mike Powyższe podejście zaszyfruje wolumin i nie wpłynie na indeksowanie itp.
jdigital
IMO potrzebujesz więcej wiedzy, niż możesz tutaj uzyskać. IANAL, ale myślę, że twój klient ma dość wysoką ekspozycję, jeśli te dane zostaną naruszone.
kevin cline
8

Przed podjęciem decyzji w takich kwestiach dotyczących bezpieczeństwa należy ocenić model zagrożenia. Bez pojęcia, przed czym się bronisz, wszelkie podejmowane przez ciebie środki prawdopodobnie będą miały niewielką wartość.

W tym kontekście możesz martwić się o kilka rzeczy:

  • Atakujący uzyskujący fizyczny dostęp do twoich danych (np. Włamują się do centrum danych, kradną kopie zapasowe taśm itp.)
  • Atakujący uzyskujący dostęp do odczytu do surowej bazy danych
  • Atakujący naruszający twoją aplikację, np. Poprzez wstrzyknięcie SQL, przepełnienie bufora itp.

W pierwszym scenariuszu przechowywanie bazy danych i wszystkich kopii zapasowych na zaszyfrowanych woluminach powinno działać, pod warunkiem, że serwer jest bezgłowy - kradzież serwera lub taśm wymagałaby wtedy przerwania szyfrowania na poziomie dysku.

W drugim scenariuszu szyfrowanie danych bazy danych pomaga, ale tylko wtedy, gdy nie przechowujesz wymaganych kluczy lub haseł w dowolnym miejscu.

W trzecim scenariuszu wszystko zależy od kontekstu, w którym następuje atak: jeśli jest to na przykład atak XSS lub CSRF, osoba atakująca może zrobić wszystko, co może zrobić legalny użytkownik, a szyfrowanie danych w ogóle nie pomaga .

W ten sposób model zagrożenia jest atakującym, który uzyskuje dostęp do odczytu surowej bazy danych, albo poprzez znalezienie danych logowania i zarządzanie logowaniem się do serwera bazy danych z zewnątrz, albo poprzez uzyskanie dostępu do katalogu głównego. Typową ścieżką jest najpierw uzyskanie dostępu do powłoki na serwerze WWW; stamtąd osoba atakująca może następnie odczytać poświadczenia dostępu z pliku konfiguracyjnego i połączyć się z bazą danych.

Dodatkową kwestią jest przechowywanie kluczy i haseł, szczególnie jeśli używasz platformy z bezstanowym modelem wykonania, takim jak PHP. Najlepiej, jeśli klient wpisze hasło w razie potrzeby i zachowa je tylko w pamięci, a nawet lepiej, odszyfruje po stronie klienta (ale nie jest to często możliwe). Na platformie bezstanowej stan jest zwykle przenoszony przy użyciu sesji, pamięci podręcznej, baz danych lub plików płaskich; ale wszystkie te są znacznie bardziej wrażliwe niż utrzymywanie stanu we własnej pamięci stanowej aplikacji internetowej. Unikanie tego jest problemem z kurczakiem i jajkiem, ponieważ jeśli zaszyfrujesz stan przed utrwaleniem go, właśnie stworzyłeś kolejny sekret, o którym musisz pamiętać. Zapamiętywanie hasła klienta i wysyłanie go wraz z każdym żądaniem, które go potrzebuje, może być wtedy najmniej okropnym rozwiązaniem;

tdammers
źródło
2
+1: bez modelu zagrożenia najprawdopodobniej blokujesz przednie drzwi, ale pozostawiasz szeroko otwarte tylne drzwi.
kevin cline
8

Ignorując przez chwilę to, o co prosi klient, i jakie są prawa ...

Nie, prawdopodobnie nie powinieneś szyfrować danych. Jeśli to zrobisz, nie będziesz w stanie łatwo go wyszukać. Jak na przykład szukałbyś nazwiska, like 'Smith%'jeśli każdy wpis jest zaszyfrowany? Jak byś wykreślił ciśnienie krwi pacjenta w czasie, jeśli nie możesz select .... from.... where patient_id = N ?

Należy oczywiście upewnić się, że serwer jest odpowiednio zabezpieczony, połączenie sieciowe jest zabezpieczone, a interfejs użytkownika jest odpowiednio zabezpieczony (w tym przekroczenia limitu czasu sesji, aby użytkownicy nie mogli odejść, pozostawiając dostęp każdemu, kto korzysta z ich komputera). Możesz także chcieć szyfrować kopie zapasowe bazy danych. I fizycznie zabezpiecz pokój, w którym znajduje się serwer. Ale nie szyfrowałbym danych na żywo.

Wyjaśnienie: Zakłada się, że o to, o co pytał PO, faktycznie szyfruje dane w bazie danych. Nie system plików, w którym znajduje się baza danych.

Grandmaster B.
źródło
całkowicie się zgadzam, ale
LAWS
1
Cóż, możesz być AES_DESCRYPT('') LIKE 'Smith%'niesamowicie wolny. Możesz też zrobić coś intensywnego i zrobić odwrócony indeks z solonymi
haszami
1

Jeśli starannie opracujesz aplikację internetową przy użyciu efektywnego frameworka MVC, takiego jak CakePHP. Zend lub Rails, wtedy powinieneś być w stanie włączyć / wyłączyć szyfrowanie na poziomie danych modalnych.

Na przykład CakePHP ma kilka przykładów zachowań dla Modala, które szyfrują dane. Uczynienie procesu przejrzystym dla kontrolerów i widoków.

Ignorując przy tym problemy dotyczące indeksowania i inne techniczne problemy z bazami danych. Powinna istnieć możliwość skonfigurowania tej opcji.

Dodatkowo chciałbym włączyć szyfrowanie w późniejszym czasie lub tylko na serwerze produkcyjnym. Zaszyfrowane dane są trudne do debugowania i pracy z nimi podczas opracowywania i można to zrobić tylko w niektórych kolumnach.

Reactgular
źródło
1

Tak, należy zaszyfrować bazę danych.

Ponieważ są to dane osobowe i wrażliwe, zdecydowanie uważam, że powinny.

Z hasła możesz uzyskać klucz szyfrujący, który przechowujesz tylko na czas sesji. W ten sposób nigdzie nie jest przechowywany i nikt (w tym DBA) nie może go znać, ponieważ nikt też nie zna hasła. Każdy, kto spróbuje wyświetlić DB bezpośrednio, będzie patrzył na bełkot. Jedynym sposobem na to jest przechwycenie sesji, ale zakładam, że sesje również są bezpieczne.

Dagnele
źródło
Ludzie bardzo często zapominają hasła ... co wtedy?
ciekawy
-1

Zadaję sobie pytanie, dlaczego klient prosi o szyfrowanie bazy danych? Gdyby poprosił cię o ochronę danych, zgodziłbym się, ale już ma na myśli domniemane wdrożenie. Więc dopóki nie wie dokładnie, o czym mówi, po prostu rzuca modne słowa z mojego punktu widzenia.

Uważam też za bardzo bezużyteczne szyfrowanie DB, ponieważ jestem przekonany, że dosłownie każdy większy DBMS bierze pod uwagę bezpieczeństwo odpowiednio i prawdopodobnie lepiej niż ty. Aby uzyskać dostęp do bazy danych przez DBMS, potrzebne byłyby dane uwierzytelniające. W przypadku zaszyfrowanej bazy danych potrzebne byłyby również te poświadczenia, a do odszyfrowania danych potrzebne byłyby te poświadczenia, które już masz.

Zgodnie z tym sposobem myślenia proponuję, aby DBMS obsługiwał bezpieczeństwo i wkładał wysiłki w ochronę poświadczeń od wejścia użytkownika do dostępu do bazy danych, może również wymuszać silne hasła i okresowe zmiany.

sschrass
źródło
... każdy większy DBMS bierze zabezpieczenia na konto ... chyba że nie .
Jay Elston,
Pierwsze pytanie, które musiałbym zadać, to jak to zrobili i jak można zapobiec szkodzie poprzez szyfrowanie bazy danych. Właśnie przejrzałem szybko ten artykuł, ale miałem wrażenie, że są w posiadaniu referencji.
sschrass
Dokładnie - poświadczenia DB mogą zostać naruszone. Wyzwanie polega na zaprojektowaniu systemu tak, aby nawet gdy nieautoryzowani użytkownicy uzyskali dostęp do danych uwierzytelniających, nadal potrzebowali dodatkowych kluczy szyfrujących, aby uzyskać dostęp do poufnych danych. W przypadku informacji zdrowotnych jest to jeszcze bardziej skomplikowane. Nie każdy mający dostęp do poświadczeń DB powinien mieć dostęp do poufnych danych. Na przykład DBA nie powinien być w stanie odczytać danych pacjenta w postaci zwykłego tekstu. Jedynymi osobami, które powinny móc odczytać te dane, są pacjenci i ich usługodawcy.
Jay Elston,