Szyfrowanie w spoczynku i/lub AES_ENCRYPT

Szyfrowanie w spoczynku

Szyfrowanie w spoczynku to dane w bazie danych, gdy nie są używane/dostępne ani aktualizowane. Szyfrowanie w ruchu to takie rzeczy jak TLS gdzie dane (z bazy danych ) jest transportowany z serwera na serwer do przeglądarki, do serwera, do przeglądarki itd. TLS jest w większości sytuacji bardzo dobry, jeśli obchodzi się z nim ostrożnie i podchodzi się do niego z nastawieniem, że trzeba zrobić więcej niż minimum aby faktycznie było realistycznie bezpieczne.

Typowym przykładem są ludzie, którzy umieszczają na swojej domenie certyfikat TLS firmy LetsEncrypt i myślą, że nagle wszystkie ich rzeczy są bezpieczne; ale nie szyfrują swoich sesji ani plików cookie więc pozostawiając ogromną potencjalną dziurę w ich obronie.

Nie używaj wbudowanego systemu szyfrowania MySQL.

Nie mogę tego wystarczająco podkreślić; wbudowany system szyfrowania w MySQL nie jest odpowiedni do rzeczywistej bezpiecznej ochrony danych.

Przeczytaj moją odpowiedź na bardzo podobne pytanie tutaj co do szczegółów (nie chcę po prostu kopiować/wklejać ).

Ok, bo nalegasz... tutaj:

Z tego, co przeczytałem w moich własnych badaniach na ten temat, link dostarczony przez Magnusa do defuse/php -szyfrowanie jest jednym z najlepszych sposobów na to, aby MySQL nigdy nie spowodował naruszenia bezpieczeństwa Twoich danych, ponieważ nigdy nie pozwala programowi/serwerowi MySQL na zobaczenie wartości danych w postaci zwykłego tekstu.

-- Odpowiedź opublikowana 7 maja 2017 r.

Również odpowiedź Billa Karwina na to samo pytanie daje kilka cennych dodatkowych informacji:

-- Odpowiedź opublikowana 7 maja 2017 r.

Punkt zamknięcia:

Bezpieczeństwo jest złożone. Jeśli chcesz zrobić to właściwie i mieć zaufanie do swoich ochronnych skórek cebuli, musisz zrobić wiele rzeczy (patrz punktory poniżej); ale pierwszą rzeczą, którą musisz zrobić, to:

• Określ, przed kim chronisz

Poważnie. Potrzebujesz różnych strategii przeciwko komuś, kto chce ukraść twoje nazwy i adresy w postaci zwykłego tekstu, a komuś, kto chce przejąć twój serwer, a komuś, kto po prostu chce zniszczyć dane tylko dlatego. To mit, że możesz chronić się przed wszystkimi przez cały czas, z założenia jest to niemożliwe*; więc musisz zdefiniować najbardziej prawdopodobnych napastników, a następnie ustalić, jak najlepiej złagodzić ich postępy.

Oddzielnie do MySQL, kilka jasnych zaleceń:

• Zachowaj SQL i PHP na tym samym serwerze. Nie używaj zdalnego dostępu do danych MySQL.

• Wyklucz zewnętrzny dostęp do SQL (więc jest to localhost tylko)

• Ukryj nazwy tabel i nazwy kolumn; jeśli ktoś włamie się do Twoich danych i masz HDTBJ^BTUETHNUYT pod kolumną username wtedy wiedzą, że ten błąd jest prawdopodobnie nazwą użytkownika, więc mają bardzo dobry początek w próbie złamania szyfrowania.

• WAŻNE :Naprawdę zablokuj dostęp do stołu; skonfigurować wielu użytkowników MySQL, z których każdy ma tylko minimalne uprawnienia do robienia tego, czego potrzebują; chcesz, aby użytkownik czytał tabelę (tylko ) i czytać tylko niektóre tabele; użytkownicy mogą pisać do niektórych tabel, ale nie mają dostępu do innych tabel. Jest to kwestia separacji, więc jeśli jakikolwiek użytkownik MySQL zostanie skompromitowany; nie straciłeś automatycznie wszystkich zawartych tam danych.

• Użyj usług szyfrowania PHP. Przechowuj klucze szyfrujące w całkowicie oddzielnym miejscu; na przykład masz inny serwer, którego używasz wyłącznie do tworzenia kopii zapasowych, do którego możesz uzyskać dostęp wyłącznie w celu uzyskania kluczy szyfrowania, dlatego jeśli Twój serwer PHP/MySQL zostanie naruszony, masz trochę miejsca na odcięcie i zablokowanie serwera kluczy, abyś mógł ograniczyć szkody. Jeśli serwer kluczy ma również kopie zapasowe, to naprawdę nie jesteś zbytnio zagrożony (zależny od sytuacji ).

• Skonfiguruj wielu obserwatorów i informatorów e-mailowych, aby dokładnie informowali Cię, kiedy działają określone procesy i którzy użytkownicy serwera (nie ludzie, ale programy) co robią. Możesz więc zobaczyć, dlaczego nieoczekiwany proces zaczyna działać o 5 rano, aby spróbować zmierzyć rozmiar tabel MySQL. WTF?

• Istnieje duże prawdopodobieństwo, że Twoje dane MySQL AES_ENCRYPT zostaną „podsłuchane”, nawet jeśli nie są w stanie spoczynku w bazie danych, ale jeśli witryna zostanie naruszona (lub, co gorsza, kod PHP jest niepewny), ataki czasowe mogą zadziałać zawartość danych poprzez wyszukiwanie zapytań czasowych i zwroty pakietów danych.

• Bezpieczeństwo to czarna dziura; w pewnym momencie pomyślisz „Pieprz to, zrobiłem już wystarczająco”. Nikt nigdy nie ma pełnego bezpieczeństwa, niektóre bardzo zaangażowane organizacje mają wystarczające bezpieczeństwo. Musisz ustalić, jak daleko jesteś w stanie przejść, zanim pokonasz dystans.

* Dlaczego niemożliwe? Ponieważ aby chronić Twoje dane przed wszystkimi zagrożeniami, przez cały czas musiałyby być nieczytelne, bezużyteczne, jak hash. Hash jest chroniony przed wszystkimi przez cały czas. Ale hasz nigdy nie może zostać odszyfrowany.