Jak oddzielić wrażliwe dane w bazie danych (MySql)

Muszę zaprojektować bazę danych, która będzie zawierać informacje o osobistej chorobie użytkowników.

Jakie może być podejście do wdrożenia kolumn tabel DB: szyfrowanie informacji, oddzielenie danych w dwóch różnych DB, jeden dla danych wrażliwych, a drugi dla danych wrażliwych, lub jedno lub drugie?

Możesz zaszyfrować dane kluczem przechowywanym w aplikacji internetowej, aby dane były zapisywane / odczytywane z bazy danych w postaci zaszyfrowanej. Jednak każdy, kto ma dostęp do kodu, miałby dostęp do klucza, a kluczem - do niezaszyfrowanych danych. To rozwiązuje wymaganie

dba nie powinna mieć możliwości przeglądania informacji o chorobie użytkownika bazy danych.

Jeśli chodzi o używanie do oddzielania baz danych, nie sądzę, że jest to potrzebne. Przechowujesz dane zaszyfrowane i korzystasz z uprawnień bazy danych przez użytkownika, tabela (jeśli to nawet potrzebne) będzie więcej niż wystarczająca. Myślę, że dodatkowe DB dodaje warstwę złożoności bez większego znaczenia. Jeśli nie jest w innej lokalizacji, może mieć MAŁĄ poprawę z jednego systemu bazy danych.

Odpowiedź Ominusa dotyczy twojego pierwszego pytania. Odpowiedź na drugie pytanie może wymagać więcej szczegółów na temat Twojej aplikacji.

Innym podejściem z jeszcze większym bezpieczeństwem, jeśli pacjenci muszą uzyskać dostęp do bazy danych, może być oddzielna baza danych dla każdego użytkownika. W tym podejściu można użyć struktury, która zapewnia funkcjonalność dla wielu dzierżawców i wielu baz danych. Problem jednak polega na tym, że jeśli masz oddzielnych użytkowników aplikacji i oddzielnych użytkowników bazy danych, synchronizacja tych użytkowników będzie niezwykle trudna. Sądzę jednak, że pacjenci nie muszą mieć dostępu do bazy danych. W razie potrzeby najbezpieczniejszym rozwiązaniem może być posiadanie klucza na użytkownika.

Oprócz wymogów prawnych lub umownych, istnieją inne powody, dla których mogę myśleć o osobnych bazach danych: postrzeganie przez klienta zwiększonego bezpieczeństwa ułatwiającego sprzedaż, obawy o złamanie szyfrowania i obawy o naruszenie (-ych) klucza (-ów).

Odnośnie części odpowiedzi Briddmusa, w której stwierdza on, że „musisz zaszyfrować więcej niż tylko informacje medyczne”: dotyczy to tylko sytuacji, w której wszyscy w bazie danych mają problemy zdrowotne. (Domyślam się, że tak jest).

Uwaga: części tej odpowiedzi lepiej nadają się jako komentarze, ale nie mam jeszcze wystarczającego przedstawiciela, aby opublikować tutaj komentarze.

W przypadku tego typu aplikacji należy zastanowić się, kto powinien mieć dostęp do danych. Mając informacje medyczne, myślę, że powinno to być ograniczone do użytkownika, który je wprowadził i każdego, kto wyraził zgodę na ich przeglądanie.

Aby uniemożliwić DBA przeglądanie danych, będziesz musiał je zaszyfrować przy użyciu kodu, do którego DBA nie ma dostępu.

Musisz także zaszyfrować informacje, aby programista aplikacji nie mógł uzyskać do nich dostępu. Nie ma sensu szyfrować informacji z bazy danych, jeśli programista może zalogować się jako dowolny użytkownik.

Nie chcesz również szyfrować wszystkich danych za pomocą tego samego kodu. Oprogramowanie może zawierać błąd, który pokazuje jednemu użytkownikowi informacje innego. Prawdopodobnie najlepiej byłoby zaszyfrować dane każdego użytkownika za pomocą kodu specyficznego dla tego użytkownika.

Ważne jest, aby pamiętać, że musisz zaszyfrować coś więcej niż tylko informacje medyczne; jako użytkownik końcowy nie chciałbym, aby twój DBA nawet wiedział, że mam chorobę, nie mówiąc już o tym, co to jest. Musisz więc również zaszyfrować wszelkie dane osobowe użytkownika. Obejmuje to takie rzeczy jak:

• imię
• Data urodzenia
• adres e-mail
• seks
• adres