Jak używać szyfrowania do ochrony danych MongoDB?

Bezpieczeństwo bazy danych jest kluczowym czynnikiem, który należy wziąć pod uwagę w przypadku każdej aplikacji, która obejmuje bardzo wrażliwe dane, takie jak raporty finansowe i zdrowotne. Ochronę danych można osiągnąć poprzez szyfrowanie na różnych poziomach, począwszy od samej aplikacji po pliki zawierające dane.

Ponieważ MongoDB jest nierelacyjną bazą danych, nie ma potrzeby definiowania kolumn przed wstawieniem danych; dlatego dokumenty w tej samej kolekcji mogą mieć różne pola.

Z drugiej strony, dla SZBD SQL należy zdefiniować kolumny dla danych, stąd wszystkie wiersze mają te same kolumny. Można zdecydować się na zaszyfrowanie pojedynczych kolumn, całego pliku bazy danych lub danych z aplikacji przed zaangażowaniem się w proces bazy danych.

Szyfrowanie poszczególnych kolumn jest najbardziej preferowane, ponieważ jest tańsze i mniej danych jest szyfrowanych, co poprawia opóźnienie. Ogólnie rzecz biorąc, ogólna wydajność wpływa na wynik szyfrowania.

Dla NoSQL DBMS to podejście nie będzie jednak najlepsze. Biorąc pod uwagę, że nie wszystkie dokumenty mogą zawierać wszystkie pola, których chcesz użyć do szyfrowania, nie można wykonać szyfrowania na poziomie kolumn.

Szyfrowanie danych na poziomie aplikacji jest dość kosztowne i trudne do wdrożenia. Dlatego pozostajemy z opcją szyfrowania danych na poziomie bazy danych.

MongoDB zapewnia natywne szyfrowanie, które nie wymaga ponoszenia dodatkowych kosztów za zabezpieczenie poufnych danych.

Szyfrowanie danych w MongoDB

Każda operacja bazy danych obejmuje jeden z tych dwóch formularzy danych, dane w spoczynku lub dane w ruchu.

Dane w ruchu to strumień danych przechodzący przez dowolną sieć, podczas gdy dane w spoczynku są statyczne, a zatem nigdzie się nie przemieszczają.

Oba te typy danych są podatne na zewnętrzne ingerencje ze strony anonimowych użytkowników, chyba że w grę wchodzi szyfrowanie. Proces szyfrowania obejmuje:

• Generowanie klucza głównego dla całej bazy danych
• Generowanie unikalnych kluczy dla każdej bazy danych
• Szyfrowanie danych za pomocą wygenerowanych kluczy bazy danych
• Szyfrowanie całej bazy danych kluczem głównym

Szyfrowanie danych w transporcie

Transakcja danych między MongoDB a aplikacją serwera odbywa się na dwa sposoby, tj. za pomocą Transport Layer Security (TLS) i Secure Socket Layer (SSL).

Te dwa są najczęściej używanymi protokołami szyfrowania do zabezpieczania wysyłanych i odbieranych danych między dwoma systemami. Zasadniczo chodzi o szyfrowanie połączeń z instancjami mongod i mongos w taki sposób, aby ruch sieciowy mógł być odczytywany tylko przez zamierzonego klienta.

TLS/SSL są używane w MongoDB z niektórymi certyfikatami jako pliki PEM, które są wydawane przez urząd certyfikacji lub mogą być certyfikatami z podpisem własnym. Ten ostatni ma ograniczenie polegające na tym, że kanał komunikacji jest szyfrowany, ale zawsze nie ma weryfikacji tożsamości serwera, a zatem jest podatny na ataki zewnętrzne w połowie. Zaleca się zatem korzystanie z certyfikatów zaufanego urzędu, które pozwalają sterownikom MongoDB na weryfikację tożsamości serwera.

Oprócz szyfrowania, TLS/SSL może być używany do uwierzytelniania klienta i wewnętrznych uwierzytelniania członków zestawów replik i klastrów podzielonych na fragmenty za pośrednictwem certyfikatów.

Konfiguracja TLS/SSL dla klientów

Istnieją różne ustawienia opcji TLS/SSL, których można użyć podczas konfiguracji tych protokołów.

Na przykład, jeśli chcesz połączyć się z instancją Mongod za pomocą szyfrowania, możesz uruchomić instancję w następujący sposób:

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl włącza połączenie TLS/SSL.

--sslCAFile określa plik pem urzędu certyfikacji (CA) do weryfikacji certyfikatu prezentowanego przez mongod lub mongos. Dlatego powłoka Mongo zweryfikuje certyfikat wystawiony przez instancję mongod z określonym plikiem CA i nazwą hosta.

Możesz także chcieć połączyć instancję MongoDB, która wymaga certyfikatu klienta. Korzystamy z przykładowego kodu poniżej

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

Opcja --sslPEMKeyFile określa plik .pem, który zawiera certyfikat powłoki mongo i klucz do przedstawienia instancji mongod lub mongos. Podczas procesu łączenia:

Powłoka mongo zweryfikuje, czy certyfikat pochodzi z określonego urzędu certyfikacji, którym jest (--sslCAFile), a jeśli nie, powłoka nie nawiąże połączenia.

Po drugie, powłoka sprawdzi również, czy nazwa hosta określona w opcji --host pasuje do SAN/CN w certyfikacie przedstawionym przez mongod lub mongos. Jeśli ta nazwa hosta nie pasuje do żadnej z tych dwóch, połączenie nie powiedzie się.

Jeśli nie chcesz używać certyfikatów z podpisem własnym, musisz upewnić się, że sieć połączenia jest zaufana.

Poza tym musisz zmniejszyć ekspozycję klucza prywatnego, szczególnie w przypadku zestawów replik/klastra podzielonego na fragmenty. Można to osiągnąć, używając różnych certyfikatów na różnych serwerach.

Dodatkowe opcje, których można użyć w połączeniach to:

requireSSL:ograniczy to każdy serwer do używania tylko połączeń szyfrowanych TLS/SSL.

--sslAllowConnectionsWithoutCertificates:umożliwia weryfikację, jeśli tylko klient przedstawi certyfikat, w przeciwnym razie w przypadku braku certyfikatu klient nadal będzie połączony w trybie szyfrowanym. Na przykład:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols:ta opcja uniemożliwia serwerom akceptowanie połączeń przychodzących, które używają określonych protokołów. Można to zrobić za pomocą:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Szyfrowanie danych w spoczynku

Od wersji 3.2 MongoDB wprowadził natywną opcję szyfrowania dla silnika pamięci masowej WiredTiger. Dostęp do danych w tym magazynie przez stronę trzecią można uzyskać tylko za pomocą klucza deszyfrującego do odszyfrowania danych do czytelnego formatu.

Powszechnie używanym algorytmem szyfrowania w MongoDB jest AES256-GCM. Używa tego samego tajnego klucza do szyfrowania i odszyfrowywania danych. Szyfrowanie można włączyć w trybie FIPS, dzięki czemu szyfrowanie spełnia najwyższe standardy i zgodność.

Całe pliki bazy danych są szyfrowane przy użyciu przezroczystego szyfrowania danych (TDE) na poziomie przechowywania.

Za każdym razem, gdy plik jest szyfrowany, generowany jest unikalny prywatny klucz szyfrowania i dobrze jest zrozumieć, w jaki sposób te klucze są zarządzane i przechowywane. Wszystkie wygenerowane klucze bazy danych są następnie szyfrowane kluczem głównym.

Różnica między kluczami bazy danych a kluczem głównym polega na tym, że klucze bazy danych mogą być przechowywane razem z samymi zaszyfrowanymi danymi, ale w przypadku klucza głównego MongoDB zaleca przechowywanie go na innym serwerze niż zaszyfrowane dane, takie jak klucz przedsiębiorstwa innej firmy rozwiązania do zarządzania.

W przypadku danych replikowanych kryteria szyfrowania nie są udostępniane innym węzłom, ponieważ dane nie są natywnie szyfrowane przez sieć przewodową. Można ponownie użyć tego samego klucza dla węzłów, ale najlepszą praktyką jest użycie unikalnych indywidualnych kluczy dla każdego węzła.

Obracanie kluczy szyfrowania

Klucz zarządzany używany do odszyfrowywania wrażliwych danych powinien być zmieniany lub wymieniany przynajmniej raz w roku. W MongoDB istnieją dwie opcje osiągnięcia rotacji.

Obrót mistrza KMIP

W takim przypadku zmieniany jest tylko klucz główny, ponieważ jest zarządzany zewnętrznie. Proces obracania klucza jest opisany poniżej.

1. Klucz główny elementów pomocniczych w zestawie replik jest obracany pojedynczo. To znaczy

   mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

   Po zakończeniu procesu mongod wyjdzie i będziesz musiał ponownie uruchomić serwer pomocniczy bez parametru kmipRotateMasterKey

   mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

2. Podstawowy zestaw replik jest obniżony:
   Używając metody rs.stepDown(), podstawowy jest dezaktywowany, co wymusza wybór nowego podstawowego.

3. Sprawdź stan węzłów za pomocą metody rs.status() i jeśli klucz podstawowy wskazuje, że został obniżony, obróć jego klucz główny. Uruchom ponownie wycofanego członka, w tym opcję kmipRotateMasterKey.

   mongod --enableEncryption --kmipRotateMasterKey \
     --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Logowanie

MongoDB zawsze pracuje z plikiem dziennika w celu rejestrowania niektórych stanów lub określonych informacji w różnych odstępach czasu.

Jednak plik dziennika nie jest szyfrowany jako część aparatu magazynu. Stwarza to ryzyko, ponieważ instancja mongod działająca z rejestrowaniem może wysyłać potencjalnie wrażliwe dane do plików dziennika jako część normalnego rejestrowania.

Od wersji MongoDB 3.4 istnieje ustawienie security.redactClientLogData, które zapobiega rejestrowaniu potencjalnie poufnych danych w dzienniku procesu mongod. Jednak ta opcja może skomplikować diagnostykę dziennika.

Wydajność szyfrowania w MongoDB

Szyfrowanie w pewnym momencie powoduje zwiększenie opóźnień, a tym samym obniżenie wydajności bazy danych. Zwykle dzieje się tak, gdy w grę wchodzi duża ilość dokumentów.

Szyfrowanie i odszyfrowywanie wymaga więcej zasobów, dlatego ważne jest zrozumienie tej relacji w celu odpowiedniego dostosowania planowania pojemności.

Jeśli chodzi o testy MongoDB, zaszyfrowany silnik pamięci ma opóźnienie od 10% do 20% przy największym obciążeniu. Dzieje się tak często, gdy użytkownik zapisuje dużą ilość danych do bazy danych, co powoduje zmniejszenie wydajności. W przypadku operacji odczytu spadek wydajności jest znikomy, około 5–10%.

Aby zapewnić lepszą praktykę szyfrowania w MongoDB, najbardziej preferowany jest silnik pamięci masowej WiredTiger ze względu na jego wysoką wydajność, bezpieczeństwo i skalowalność. Ponadto optymalizuje szyfrowanie plików bazy danych do poziomu strony, co ma wielką zaletę, ponieważ jeśli użytkownik odczytuje lub zapisuje dane w zaszyfrowanej bazie danych, operacja przepustowości zostanie zastosowana tylko do strony, na której dane są przechowywane, a nie do całej baza danych.

Zmniejszy to ilość danych, które będą musiały zostać zaszyfrowane i odszyfrowane w celu przetworzenia pojedynczego fragmentu danych.

Podsumowanie

Bezpieczeństwo danych wrażliwych informacji jest koniecznością i istnieje potrzeba ich ochrony bez obniżania wydajności systemu bazy danych.

MongoDB zapewnia solidne natywne procedury szyfrowania, które mogą pomóc nam zabezpieczyć nasze dane zarówno w spoczynku, jak i w ruchu. Poza tym procedury szyfrowania powinny być zgodne z normami określonymi przez różne organizacje.

Zaawansowany silnik pamięci masowej WiredTiger zapewnia lepszą opcję ze względu na związane z nim zalety, takie jak wysoka wydajność, skalowalność i bezpieczeństwo. Podczas szyfrowania danych w zestawach replik dobrą praktyką jest używanie różnych kluczy głównych dla każdego z nich, poza zmienianiem ich co najmniej raz w roku.

Jednak dostępność opcji szyfrowania innych firm nie ma gwarancji, że Twoje wdrożenie będzie pasować do nich pod względem skalowalności. Dlatego też dość rozważne jest stosowanie szyfrowania na poziomie bazy danych.