Czy powinienem szyfrować dane w bazie danych?

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.

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ń.

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 .

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;

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.

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.

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.

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.