Szyfrowanie MySQL i zarządzanie kluczami

Rozwijam lokalny system intranetowy w PHP / MySQL do zarządzania danymi naszych klientów. Wydaje się, że najlepszą praktyką byłoby szyfrowanie wrażliwych danych na serwerze MySQL podczas ich wprowadzania.

Nie jestem jednak pewien, jaki byłby najlepszy sposób, aby to zrobić, mając jednocześnie łatwy dostęp do danych.

Odpowiedź na pytanie wydaje się trudna: gdzie są przechowywane klucze? Jak najlepiej chronić klucz? Jeśli klucz jest przechowywany na komputerze każdego użytkownika, jak go zabezpieczyć, jeśli komputer jest wykorzystywany? Jeśli klucz zostanie wykorzystany, jak go zmienić?

Jeśli klucz ma być przechowywany w bazie danych, jak go tam zabezpieczyć? Jak użytkownicy mieliby do niego dostęp?

Tak naprawdę nie ma żadnych wbudowanych funkcji MySQL do obsługi wyrafinowanych ustawień szyfrowanych kluczy. Musisz zaimplementować większość logiki szyfrowania we własnym kodzie PHP i / lub w przeglądarce (javascript?).

Ale twoje obawy są nieco dziwne: wydaje się, że twoje jedyne prawdziwe obawy to zastrzyk SQL lub brutalna siła (zgaduję hasło, przypuszczam) atak ze zdalnego komputera stacjonarnego / laptopa. To sprawia, że ​​podejrzewam, że masz już zaplanowane inne, niewymienione środki bezpieczeństwa i przeanalizowałeś możliwe drogi kompromisu.

• Po pierwsze, zakładam, że masz reguły zapory chroniące host MySQL / PHP przed jakimkolwiek dostępem z niezatwierdzonych adresów IP zdalnych klientów. Jeśli mam rację, to ma sens, że martwisz się tylko atakami ze stacji roboczych z zaatakowanymi użytkownikami.

• Zakładam również, że rozumiesz, że jeśli osoba atakująca na zdalnym hoście klienta może eskalować do uprawnień administratora / administratora lub bezpośrednio narazić własne konto prawdziwego użytkownika, dane tego klienta nie mają żadnej ochrony, niezależnie od szyfrowania lub jakichkolwiek innych zabezpieczeń. (Osoba atakująca może odczytać klucze z dowolnego miejsca, w którym są zapisane na dysku, lub węszyć je, gdy prawdziwy użytkownik wprowadza je podczas logowania, a klucze prowadzą do danych.)

Wychodząc z tych dwóch założeń, rozsądne jest, aby wyciągnąć wniosek, że jedynymi dwoma istotnymi zagrożeniami są: A) zgadywanie hasła typu brute-force i B) próby wstrzyknięcia SQL:

• Jeśli atakujący nie dostanie klucza prawdziwego użytkownika lub jeśli chce uzyskać dostęp do czegoś więcej niż tylko rzeczywistych danych użytkownika, może spróbować brutalnie wymuszonych danych logowania dla prawdziwego użytkownika lub innego konta. (Teoretycznie możesz zablokować każde konto do konkretnego adresu IP klienta zdalnego, co pomogłoby również w podziale ryzyka).
• Jeśli atakujący otrzyma prawidłowy klucz dla prawdziwego użytkownika, może przejść obok ekranu logowania (który jest prawdopodobnie wystarczająco prosty, aby był bezpieczny), do miękkiego podbrzusza potencjalnie błędnego kodu aplikacji. Pomyślne wstrzyknięcie SQL z kontekstu rzeczywistego użytkownika może zapewnić mu również dostęp do danych innych klientów.

Porozmawiajmy teraz o tym, jak szyfrowanie po stronie serwera stosuje się w następujących sytuacjach:

• Szyfrowanie po stronie serwera zdecydowanie pomaga w walce z zagrożeniem iniekcją SQL. Jeśli wartości wierszy są zaszyfrowane w tabelach DB, atakujący może zobaczyć tylko bełkotliwy tekst zaszyfrowany danych, które należą do innych kont. Zagrożenie jest ograniczone, podzielone na przedziały.
• Brutalne wymuszanie zgadywania haseł wcale nie jest trudniejsze dla atakującego, który ma szyfrowanie po stronie serwera. Niezależnie od tego, czy klucze użytkowników są przechowywane na serwerze, czy generowane na podstawie hasła, jedyne, co się liczy, to czy masz właściwe hasło. Albo serwer zdecyduje się na użycie poprawnego przechowywanego klucza, ponieważ sprawdza, czy hasło jest poprawne, lub oblicza prawidłowy klucz, ponieważ hasło jest poprawnym wejściem do wygenerowania tego klucza.

Z drugiej strony szyfrowanie po stronie klienta sprawia, że ​​ataki hasłem „brute force” są nieistotne. Nie możesz użyć siły brutalnie poprawnie skonstruowanego klucza. Szyfrowanie po stronie klienta utrzymuje zasadniczo ten sam poziom ochrony przed wstrzyknięciem SQL, jak szyfrowanie po stronie serwera. Klient może przekazać klucz do serwera podczas logowania, zachowując kopię w pamięci do czasu zakończenia sesji, co obciąża serwer. Lub klient może samodzielnie obsługiwać szyfrowanie / deszyfrowanie w przeglądarce. Obie techniki mają swoje zalety i wady:

• Przekazanie klucza do serwera jest znacznie łatwiejsze do kodowania i zarządzania, i zwykle znacznie szybsze z powodu bardziej zoptymalizowanego kodu kryptograficznego (prawdopodobnie skompilowanego C).
• Podejście oparte wyłącznie na kliencie zapewnia dodatkowe bezpieczeństwo, ponieważ nawet jeśli atakujący zrootuje się na serwerze, nadal nie może odczytać zaszyfrowanych danych i nigdy nie będzie w stanie ich odczytać. Jedynym możliwym wektorem ataku jest złamanie bezpieczeństwa zdalnej stacji roboczej.

Na koniec zauważę, że istnieją pewne poważne wady operacyjne związane z szyfrowaniem danych w bazie danych. Ponieważ zaszyfrowane reprezentacje danych są w zasadzie przypadkowymi wzorami, podstawowe funkcje bazy danych, takie jak indeksowanie, łączenia itp. Nie będą działać. Klient przyjmuje ogromne obciążenie logiczne i może stracić wiele korzyści, które zwykle zapewniają funkcje bazy danych.

Warto przyjrzeć się ezNcrypt , który wykorzystuje ecryptfs, kontrolę dostępu i zarządzanie kluczami, aby zapewnić wysokie bezpieczeństwo i wydajność szyfrowania Linux baz danych MySQL i innych procesów. Nie, nie pracuję dla nich.

Możesz użyć Scytale. Jest to krypto proxy NoSQL dla nowoczesnych DBMS i aplikacji internetowych. Obsługuje szyfrowanie wielu adresatów i grup. Obciążony silnym kryptosystemem RSA / AES. Jest również w 100% darmowy i open source.

https://bitbucket.org/maximelabelle/scytale