Jak mogę chronić dane w tabelach SQL?
Jakie są najlepsze praktyki ochrony tych aktywów, zainspirowane wieloma wyciekami danych, w wyniku których wyciekły całe bazy danych / tabele z danymi osobowymi użytkowników? Jestem szczególnie zaniepokojony, jeśli ktoś był w stanie uzyskać dostęp do kodu zaplecza (co zdecydowanie nie powinno mieć miejsca) i tym samym uzyskać poświadczenia SQL.
Przechowuję dane konta osobistego, do których dostęp musi mieć tylko odpowiedni użytkownik.
Mój pomysł polega na tym, aby zaszyfrować dane w tabeli symetrycznie z nazwą użytkownika i hasłem użytkownika. To sprawia, że jest to bardzo trudne podczas obsługi resetowania hasła ...
Czy istnieją inne pomysły lub typowe implementacje dla tego scenariusza?
Odpowiedzi
Jestem szczególnie zaniepokojony, jeśli ktoś był w stanie uzyskać dostęp do kodu zaplecza i tym samym uzyskać poświadczenia SQL.
System bazy danych powinien być dostępny z ograniczonej liczby systemów. W szczególności nie powinien być dostępny w Internecie. Jeśli ktoś ma poświadczenia SQL, nadal nie będzie miał dostępu do serwera.
Typowe źródła wycieków to:
- Wstrzyknięcie SQL
- Ujawniony serwer nieuwierzytelniony, taki jak MongoDB, ElasticSearch
- Eksportuj plik CSV lub ujawniony dokument, np. Przez Dysk Google
- Otwórz zasobnik Amazon S3
- Eksfiltracja danych po włamaniu
Mój pomysł polega na tym, aby zaszyfrować dane w tabeli symetrycznie z nazwą użytkownika i hasłem użytkownika.
Większość aplikacji internetowych ma swój tekst w postaci zwykłego tekstu w bazie danych i po prostu sprawdza logikę biznesową aplikacji, czy użytkownik może uzyskać dostęp do określonego obiektu. To, co proponujesz, zapewniłoby większe bezpieczeństwo, ale jednocześnie wprowadziłoby większą złożoność. Zastanów się, czy warto.
To sprawia, że jest to bardzo trudne podczas obsługi resetowania hasła ...
Podczas szyfrowania danych hasłem użytkownika dane te znikają, gdy użytkownik zapomni hasła. W niektórych przypadkach jest to dopuszczalne, a użytkownik powinien po prostu utworzyć nowe konto. W przeciwnym razie czasami można to rozwiązać, dając użytkownikowi klucz deszyfrujący podczas zakładania konta, który ma on wydrukować i zapisać. Jest to klucz „backdoora”, który umożliwia odszyfrowanie konta w przypadku zapomnienia hasła.
Chcesz chronić dane. Ale od czego? Od kogo?
Musisz zdefiniować możliwy scenariusz, a następnie możesz spróbować znaleźć sposób na ochronę przed określonym niebezpieczeństwem, przed konkretnym sposobem, w jaki osoba atakująca może próbować ukraść Twoje dane.
A co z fizycznym hakowaniem ? Czy ktoś może wejść i ukraść twój serwer? Czy ktoś może wykonać kopię aktualnych danych? Czy ktoś może uzyskać dostęp do kopii zapasowych? ( ponieważ masz kopię zapasową w siedzibie firmy, poza nią, a wszystkie te kopie zapasowe są chronione hasłem , prawda?)
Jeśli chcesz zaszyfrować dane, musisz określić, na jakim poziomie chcesz szyfrować dane .
Na niektórych RDBMS możesz zaszyfrować całą bazę danych na dysku i przechowywać klucz na serwerze bazy danych. Może to Cię ochronić, jeśli ktoś ukradnie kopię plików Twojej bazy danych. Ale nie ochroni cię, jeśli ktoś ukradnie dane uwierzytelniające DB.
Lub możesz przekazać klucz szyfrowania z parametrami połączenia, ale tego rodzaju rzeczy mogą się znacznie różnić w różnych systemach RDBMS.
Możesz zmodyfikować swoją aplikację / witrynę, aby szyfrować wszystkie dane w każdym wierszu / kolumnie bazy danych .
Teraz masz dużo bezpieczeństwa i dużo problemów :
- Jak sortować tabelę zaszyfrowanych danych? ty nie.
- Indeksy kolumn ? bezużyteczny.
- Czy możesz wykonać SELECT ... WHERE Encrypted_Name_Column, na przykład „% Fox%” ? nie, nie możesz.
- Jak zaszyfrować kolumnę Data / Godzina ? Czy konwertujesz datę na ciąg, a następnie szyfrujesz ciąg? Powodzenia w odszyfrowywaniu, gdy zaczyna się czas letni ...
- Jak zarządzasz IV ( wektorem inicjalizacyjnym ) algorytmu szyfrowania? Jeśli zaszyfrujesz te same dane, przy użyciu tych samych kluczy i tego samego IV, otrzymasz te same zaszyfrowane dane wyjściowe. Dlatego osoba atakująca może nie być w stanie odszyfrować danych, ale może być w stanie wykryć, że niektóre wartości są takie same , ponieważ wartości zaszyfrowane są takie same.
Możesz to wszystko zrobić, ale czy naprawdę warto?
Jak zarządzasz kluczami szyfrowania?
Zwykle nie używasz bezpośrednio hasła do szyfrowania danych . Zwykle generujesz losowy bezpieczny klucz do szyfrowania danych, a następnie używasz hasła w celu uzyskania klucza do zaszyfrowania klucza użytego do danych.
W ten sposób możesz zmienić hasło bez konieczności ponownego szyfrowania wszystkich danych.
Teraz, jeśli zgubisz hasło, potrzebujesz planu awaryjnego ... takiego jak kopia klucza szyfrowania danych, zaszyfrowana hasłem głównym, używana tylko do resetowania hasła. (ale teraz masz hasło główne, które może odszyfrować wszystkie dane wszystkich użytkowników ... gdzie je przechowujesz? na serwerze z izolacją powietrzną?)
Czy lepiej byłoby podzielić usługi i spróbować zmniejszyć powierzchnię ataku?
Dlaczego Twoja aplikacja / witryna potrzebuje danych logowania DB? Możesz stworzyć aplikację / stronę internetową, która nigdy nie będzie miała bezpośredniego dostępu do bazy danych, ale będzie miała dostęp do danych tylko za pośrednictwem usługi internetowej. Usługa sieciowa umożliwiająca dostęp do danych może znajdować się na drugim serwerze niedostępnym z Internetu. Poświadczenia bazy danych, używane przez drugi serwer, mogą być przechowywane na trzecim serwerze i dostępne dla sieci za pomocą określonego konta ...
Możesz budować warstwę bezpieczeństwa po warstwie.
Prawdopodobnie tylko zarysowuję powierzchnię, bezpieczeństwo strony / aplikacji / db to dość szeroki argument.