Poziomy braku bezpieczeństwa MongoDB i jak ich uniknąć

Większość systemów zarządzania bazami danych ma kilka technik zabezpieczania swoich danych przed osobami z zewnątrz, nieuprawnioną osobą lub aplikacją. Techniki uniemożliwiają odczytanie lub skopiowanie danych bez zgody użytkownika.

MongoDB niczym się nie różni, ponieważ ma pewne poziomy niepewności. W tym poście na blogu omówimy poziomy braku bezpieczeństwa w MongoDB i sposoby ich uniknięcia, aby chronić swoją instalację MongoDB.

W celu zapewnienia bezpieczeństwa Twojej bazy danych MongoDB, poniżej wymieniono niektóre z głównych środków bezpieczeństwa, które należy ściśle wziąć pod uwagę:
 

1. Uwierzytelnianie połączeń użytkowników.

2. Autoryzacja/kontrola dostępu oparta na rolach.

3. Szyfrowanie sieci/szyfrowanie transportu.

4. Szyfrowanie pamięci/szyfrowanie w stanie spoczynku.

5. Audyt.

W tym artykule przyjrzymy się szczegółowo powyższym środkom bezpieczeństwa, ze szczególnym uwzględnieniem uwierzytelniania i autoryzacji.

Uwierzytelnianie i autoryzacja

Uwierzytelnianie i autoryzacja muszą być aktywowane jednocześnie. Można ich jednak używać niezależnie od siebie. Uwierzytelnianie uniemożliwia dostęp nieznanej osobie, która ma dostęp sieciowy do serwera bazy danych, przed skopiowaniem lub uszkodzeniem danych bazy danych. Uwierzytelnianie wymaga od wszystkich klientów i serwerów podania prawidłowych poświadczeń, zanim będą mogli połączyć się z systemem. Z drugiej strony autoryzacja uniemożliwia aplikacji lub użytkownikowi odczytywanie, zmienianie lub usuwanie danych innych niż te, które miały.

Aby skonfigurować kontrolę dostępu opartą na rolach;

1. Najpierw utwórz administratora użytkownika.

2. Utwórz dodatkowych użytkowników.

3. Następnie utwórz unikalnego użytkownika MongoDB dla każdej osoby/aplikacji, która ma dostęp do systemu.

4. Przestrzegając zasady najmniejszych uprawnień, należy utworzyć role, które dokładnie definiują prawa dostępu wymagane przez zestaw użytkowników.

5. Następnie przypisz użytkownikom tylko te role, które muszą wykonywać w swoich operacjach. Użytkownikiem może być aplikacja kliencka lub osoba.

Należy pamiętać, że użytkownik może mieć uprawnienia w różnych lub wielu bazach danych. W tym scenariuszu, zamiast wielokrotnie tworzyć użytkownika w różnych bazach danych, utwórz jednego użytkownika z rolami, które przyznają odpowiednie uprawnienia do bazy danych.

Częściej te dwa środki bezpieczeństwa mogą być mylone i oznaczać to samo. W niektórych scenariuszach są one do siebie podobne, ale są też różne.

Podobieństwa między uwierzytelnianiem a autoryzacją

• Oba są w pewnym sensie jedną jednostką, ponieważ po włączeniu uwierzytelniania Autoryzacja jest włączana automatycznie. Autoryzacja jest włączona zgodnie z uwierzytelnianiem, dlatego połączenia od nieznanych użytkowników nie będą miały uprawnień dostępu do danych bazy danych. Autoryzacja wymaga również zweryfikowania nazwy użytkownika przez uwierzytelnianie, aby wiedzieć, jakie uprawnienia mają zastosowanie do żądań połączenia. Dlatego też nie można go włączyć niezależnie od drugiego.

• Oba są również podobne pod względem niefortunnego, starszego nazewnictwa opcji konfiguracyjnych. Opcją pliku konfiguracyjnego dla uwierzytelniania jest security.authorization zamiast uwierzytelniania bezpieczeństwa, jak można by oczekiwać. Kiedy używasz tego polecenia, uwierzytelnianie jest włączane jako pierwsze, a autoryzacja jest włączana tylko jako efekt wtórny. „-auth” to argument wiersza poleceń umożliwiający włączenie uwierzytelniania, który automatycznie wymusza również włączenie autoryzacji.

Różnice między uwierzytelnianiem a autoryzacją

• Te dwa są różne, ponieważ są dwiema częściami oprogramowania, które mają różne funkcje.

Uwierzytelnianie ==Tożsamość użytkownika za pomocą sprawdzania poświadczeń.

Autoryzacja ==Przypisywanie i wymuszanie uprawnień do obiektów i poleceń DB.

• Podczas początkowej konfiguracji uwierzytelnianie jest wyłączone dla połączeń z hostem lokalnym. Jest to jednak krótkie, ponieważ masz jedną możliwość utworzenia pierwszego użytkownika, a następnie wyjątek (w regule Uwierzytelnianie i autoryzacja w połączeniu) zostaje odrzucony.

Jak sprawdzić, czy uwierzytelnianie i autoryzacja są włączone, czy nie

Pierwsze wersje MongoDB miały domyślnie włączone „-auth”, co jest powszechnie uważane za zły ruch. Nawet w wersji 4.0 nadal był domyślnie wyłączony. Pusta konfiguracja nadal oznacza wyłączenie autoryzacji, mimo ostrzeżeń o uruchomieniu i różnych redukcji narażenia, takich jak localhost staje się jedynym domyślnym urządzeniem sieciowym w MongoDB v3.6.

Nie używasz uwierzytelniania lub raczej nie masz włączonej uwierzytelniania, jeśli pliki konfiguracyjne mongod nie:

1. Ustaw security.authorization na „włączone”.

2. Dołącz plik security.key.

3. Dołącz ustawienie security.clusterAuthMode, które wymusza włączenie uwierzytelniania.

Aby dokładnie sprawdzić, czy masz włączone uwierzytelnianie i autoryzację, czy nie, możesz wypróbować ten szybki jednowierszowy tekst powłoki mongo (bez ustawionych argumentów poświadczeń użytkownika):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

Odpowiedź, którą powinieneś otrzymać, to „nieautoryzowany” błąd. Ale z drugiej strony, jeśli otrzymasz listę nazw baz danych, automatycznie oznacza to, że masz nagie wdrożenie MongoDB.

Uwierzytelnianie zewnętrzne

Jak sama nazwa wskazuje, uwierzytelnianie zewnętrzne polega na umożliwieniu uwierzytelnienia użytkowników w usłudze zewnętrznej. W drodze wyjątku nie można go używać dla wewnętrznego użytkownika systemu mongodb __, ale używanie go dla dowolnego prawdziwego użytkownika lub konta usługi aplikacji klienckiej jest doskonale odpowiednie.

Po prostu zewnętrzną usługą uwierzytelniania będzie Kerberos KDC lub serwer ActiveDirectory lub OpenLDAP. Należy pamiętać, że korzystanie z uwierzytelniania zewnętrznego nie uniemożliwia jednoczesnego posiadania zwykłych kont użytkowników MongoDB.

Uwierzytelnianie wewnętrzne

Wręcz przeciwnie, wewnętrzne uwierzytelnianie MongoDB nie oznacza przeciwieństwa uwierzytelniania zewnętrznego. Dzieje się tak, ponieważ węzeł mongod działający z włączonym uwierzytelnianiem nie będzie ufał, że każdy peer TCP jest innym węzłem mongod lub mongos tylko dlatego, że komunikuje się jak jeden. Wymaga to raczej uwierzytelnienia peera przez dowód wspólnego sekretu.

Istnieją dwa rodzaje wewnętrznych mechanizmów uwierzytelniania w MongoDB:

1. Wewnętrzne uwierzytelnianie pliku klucza.

2. Uwierzytelnianie wewnętrzne SCRAM lub x.509.

Wewnętrzne uwierzytelnianie pliku klucza

Jest to domyślny wewnętrzny mechanizm uwierzytelniania w MongoDB. Termin „klucz” oznacza asymetryczny klucz szyfrowania, ale w rzeczywistości jest to tylko hasło, bez względu na to, jak je wygenerowałeś. Plik klucza jest zapisywany w identycznym pliku dystrybuowanym do każdego węzła mongod i mongos w klastrze. W scenariuszu, w którym hasło zostanie użyte pomyślnie, węzeł mongod pozwoli na uruchamianie poleceń pochodzących od uwierzytelnionego partnera jako superużytkownik „_ _ systemu”.

Jeśli ktoś ma kopię pliku klucza, może po prostu usunąć znaki kontrolne i niedrukowalne z pliku klucza, aby utworzyć ciąg hasła, który pozwoli mu połączyć się jako użytkownik „_ _ system”.

Jednak jeśli tak się stanie i uruchomisz poniższe polecenie jako użytkownik mongod (lub root) na jednym z twoich serwerów MongoDB i odniesiesz sukces, nie powinieneś się martwić, ponieważ nie dojdzie do przypadkowego wycieku uprawnień do odczytu . Dzieje się tak, ponieważ mongod przerwie działanie podczas uruchamiania, jeśli plik klucza jest w trybie uprawnień do plików innym niż 400 (lub 600).

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Jednak przypadkowe zapisanie pliku klucza w czytelnej dla całego świata kontroli źródła może pozwolić użytkownikom, którzy nie są administratorami baz danych (lub administratorami serwera z rootem) na odczytanie kopii pliku klucza. Jest to uważane za awarię bezpieczeństwa.

Ekstremalne ryzyko wzrasta, gdy plik klucza jest dystrybuowany z węzłami mongos będącymi własnością i uruchamianymi jako jeden z użytkowników unixowych zespołu aplikacji, zamiast jako „mongod” lub inny użytkownik unixowy należący do zespołu DBA.

SCRAM lub uwierzytelnianie wewnętrzne x.509

Wewnętrzny mechanizm uwierzytelniania x.509 w rzeczywistości używa asymetrycznych kluczy prywatnych lub publicznych i musi być używany w połączeniu z TLS/SSL. Ten mechanizm może być używany do połączeń klientów, a także uwierzytelniania wewnętrznego.

Mechanizm x.509 lub SCRAM ma przewagę nad mechanizmem Keyfile, ponieważ w mechanizmie x.509 jest mniej prawdopodobne, że jeden z kluczy wdrożonych z węzłami mongod i mongos może zostać nadużyty przez intruz, który otrzyma jego kopię. Jednak zależy to od tego, jak ściśle skonfigurowane są certyfikaty x.509. Aby cieszyć się maksymalnym bezpieczeństwem tego mechanizmu, powinieneś mieć dedykowany zespół ds. bezpieczeństwa, który rozumie koncepcje i najlepsze praktyki x.509. Te najlepsze praktyki obejmują zawężenie hostów, na których będzie działać, oraz możliwość odwołania i przywrócenia certyfikatów.

Szyfrowanie sieci/szyfrowanie transportu

Szyfrowanie sieciowe uniemożliwia komuś kopiowanie danych przesyłanych łączem sieciowym gdzieś między dwoma serwerami. Szyfrowanie sieci wymaga niewiele lub żadnego przemyślenia, jeśli chodzi o podjęcie decyzji, czy go użyć, ponieważ jest to kluczowe. Ale jeśli na przykład Twój klaster MongoDB i wszyscy jego klienci znajdują się w wirtualnej sieci prywatnej, która Twoim zdaniem nie ma dziur w zaporze i nie ma ryzyka eskalacji uprawnień ze strony innych aplikacji, nie potrzebujesz szyfrowania sieci.

W przypadku szyfrowania sieci należy skonfigurować MongoDB tak, aby używało TLS/SSL dla wszystkich połączeń wychodzących i przychodzących. Szyfruj komunikację między komponentami mongod i mongos we wdrożeniu MOngoDB, a także między wszystkimi aplikacjami i MongoDB za pomocą TLS/SSL.

Uruchamianie w wersji 4.0; MongoDB wyłącza obsługę szyfrowania TLS 1.0 w systemach, w których dostępny jest TLS 1.1+, a także korzysta z następujących natywnych bibliotek TLS/SSL:

1. Windows — bezpieczny kanał (Schannel).

2. Linux/BSD - OpenSSL.

3. macOS — bezpieczny transport.

Ogranicz ekspozycję sieci

Należy upewnić się, że MongoDB działa w zaufanym środowisku sieciowym, a także skonfigurować zaporę sieciową lub grupy zabezpieczeń, aby kontrolować ruch przychodzący i wychodzący dla instancji MongoDB. Co więcej, skonfiguruj tak, aby zezwalać tylko zaufanym klientom na dostęp do interfejsów sieciowych i portów, na których dostępne są instancje MongoDB. Na przykład użyj białej listy adresów IP, aby zezwolić na dostęp z zaufanych adresów IP.

Uruchom MongoDB z opcjami bezpiecznej konfiguracji

MongoDB obsługuje wykonanie kodu JavaScript dla następujących operacji po stronie serwera:

1. mapReduce.

2. $gdzie.

3. $akumulator.

4. $funkcja.

Użyj opcji --noscripting w wierszu poleceń, aby wyłączyć skrypty po stronie serwera, jeśli nie używasz powyższych operacji. Pozostaw włączoną walidację danych wejściowych, chociaż MongoDB domyślnie włącza walidację danych wejściowych za pomocą ustawienia net.wireObjectCheck. Gwarantuje to, że wszystkie dokumenty przechowywane przez instancję mongod są ważne w formacie BSON.

Szyfrowanie pamięci masowej MongoDB/szyfrowanie w spoczynku

Szyfrowanie pamięci uniemożliwia uzyskanie kopii plików baz danych. Może się to zdarzyć, gdy ktoś włamie się do Twojego centrum danych i ukradnie dysk twardy Twojego serwera. Dane MongoDB obejmują pliki danych, pliki konfiguracyjne, dzienniki audytu i pliki kluczy.

Począwszy od MongoDB Enterprise 3.2, możesz szyfrować dane w warstwie pamięci masowej za pomocą natywnego szyfrowania w spoczynku silnika WiredTiger. Dane MongoDB powinny być szyfrowane na każdym hoście przy użyciu systemu plików, urządzenia lub szyfrowania fizycznego, gdy nie używasz szyfrowania w spoczynku WiredTiger. Ponadto należy zbierać dzienniki do centralnego magazynu dzienników, ponieważ te dzienniki zawierają próby uwierzytelnienia bazy danych, w tym źródłowy adres IP. Jednak szyfrowanie pamięci ma niewielki koszt wydajności.

Kontrola

Audyt pomaga w śledzeniu użytkownika bazy danych, który wie, jak ukryć swoje ślady po zmianie lub modyfikacji danych w bazie danych. Zasadniczo audyt śledzi dostęp i zmiany w konfiguracjach i danych bazy danych. MongoDB Enterprise ma funkcję systemu audytu, która może rejestrować zdarzenia systemowe, takie jak operacje użytkowników i zdarzenia połączeń w instancji MongoDB.

Te zapisy audytu pomagają w analizie kryminalistycznej i umożliwiają administratorom weryfikację odpowiednich kontroli. Audyt ma dużą wartość dla niektórych użytkowników, ale może być taki tylko wtedy, gdy pewne inne zagrożenia zostaną wyeliminowane. Na przykład, atakujący nie może uzyskać dostępu do roota Unixa na serwerach podczas uruchamiania aktywnych węzłów mongod.

Naprzód

Możesz skonfigurować filtry, aby rejestrować określone zdarzenia, takie jak zdarzenia uwierzytelniania. Ale bądź ostrożny, ponieważ gdy filtry audytu są zbyt szerokie, ich wydajność szybko się dławi, co prowadzi do wysokich kosztów wydajności. Chociaż, jeśli audyt jest stosowany w odpowiedni sposób, nie będzie dużych kosztów wydajności.