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;