MongoDB
 sql >> Baza danych >  >> NoSQL >> MongoDB

Bezpieczeństwo bazy danych 101:Zrozumienie uprawnień dostępu do bazy danych

Dane to nowe złoto dla dużych firm i organizacji. Są uważane za siłę napędową większości nowoczesnych firm i dają mnóstwo możliwości sprzedaży lub wprowadzenia na rynek szerokiemu gronu odbiorców w internecie. W przypadku dużych firm zajmujących się handlem elektronicznym lub mediami społecznościowymi dane napędzają ich zdolność do generowania dużych przychodów i dochodów, dla których dane są ściśle zabezpieczone i mają zaawansowaną ochronę przed wszelkimi złośliwymi atakami i włamaniami online.

Więc dane takie jak złoto, ich wartościowy stan zaczyna się po przetworzeniu. Jego surowa wartość jest pełna bałaganu, jakby była gigantycznym, nieposortowanym kęsem. Gdy jego esencja jest ustrukturyzowana, wartość danych jest wielokrotność. Wyobraź sobie, że masz witrynę edukacyjną, która pozwala użytkownikom płacić. Gdy masz już mnóstwo wykładów i modułów, których docelowi odbiorcy mogą się uczyć, rozwijać i osiągać pewien stopień produktywności, rozumiesz smak możliwości i sukcesu, ponieważ masz drzwi do regulowania opłat, zanim będą mogli uzyskać pożądane ustrukturyzowane dane . Chociaż brzmi to jak marzenie każdego o sukcesie, jeśli chodzi o duże zbiory danych i ich podstawową istotę, przetwarzanie ich wiąże się z mnóstwem komplikacji, a ważnym problemem są zagrożenia dla Twojej bazy danych.

Zagrożenia baz danych ogólnie obejmują liczne i rozległe sektory, które należy przyjrzeć się i zbadać. Jednak najczęstszymi przyczynami są kradzież danych i naruszenia danych. Innym powszechnym zagrożeniem są rozległe uprawnienia lub dostęp do baz danych niepoprawnie przypisanych i/lub przekazanych użytkownikowi. Ochrona całego hosta serwera jest problemem dla każdego, kto zarządza bazą danych. Zwiększono bezpieczeństwo i radzenie sobie ze wszystkimi typami odpowiednich ataków, takich jak podsłuchiwanie, modyfikowanie, odtwarzanie i odmowa usługi (DDoS) nie tylko dla bazy danych, ale także dla całego stosu bazowego, który ma dostęp lub który łączy się z przechowywaniem danych.

W tym blogu omówimy zakres konieczności zrozumienia i posiadania uprawnień dostępu do bazy danych.

Niebezpieczeństwa związane z niewłaściwymi uprawnieniami dostępu

Nieuchronnie musimy udostępniać lub przynajmniej tworzyć użytkownika na poziomie fizycznym i technicznym. Natomiast zapewnienie dostępu komuś innemu oznacza, że ​​ufasz tej osobie. Oznacza to również, że upoważniona osoba musi zrozumieć niebezpieczeństwo i ryzyko współdzielenia dostępu i danych ze świata zewnętrznego.

Najważniejszym punktem zabezpieczenia swoich uprawnień dostępu jest poziom zrozumienia bezpieczeństwa między inżynierami, takimi jak administrator bazy danych, inżynier bezpieczeństwa lub administrator serwera. Jeśli zrozumienie jest słabe lub brakuje wiedzy i doświadczenia, zwłaszcza w przypadku najbardziej aktualnych podatności i ekspozycji, może to stanowić problem dla organizacji lub firmy.

Istnieją podstawowe rzeczy, które należy zrozumieć i wziąć pod uwagę, aby było to minimalne lub przynajmniej nie można było naruszyć lub ujawnić. W przeciwnym razie może to narazić Twoje dane na niebezpieczeństwo ze świata zewnętrznego lub przynajmniej dla niewłaściwej osoby lub osób. Ewentualnie, aby ukraść Twoje dane i wykorzystać je dla własnych korzyści finansowych lub mogą wykupić je od Ciebie i poprosić o pieniądze w zamian za słabą implementację zabezpieczeń.

W tej sekcji zobaczmy kilka typowych przyczyn tych zagrożeń bezpieczeństwa.

Udostępnianie uprawnień dostępu root

W środowisku lokalnym, zwykły przypadek naruszenia bazy danych opiera się głównie na niebezpieczeństwie przyznania dostępu roota na poziomie systemu operacyjnego lub na poziomie oprogramowania bazy danych. Zdarzają się przypadki, w których hasło roota jest rozpowszechniane i udostępniane kilku osobom, które powinny być ograniczone tylko do administratorów pracujących wyłącznie w systemie. Może się to zdarzyć z powodu braku listy kontrolnej bezpieczeństwa lub środków w protokole przed wdrożeniem uprawnień dostępu. Posiadanie listy kontrolnej bezpieczeństwa pomaga śledzić dostęp i przywileje, które mogą narazić ryzyko i niebezpieczeństwo, zwłaszcza gdy określony użytkownik systemu operacyjnego jest narażony na intruza. Lista kontrolna pomaga również omówić lub uzyskać przegląd środków bezpieczeństwa wprowadzonych i zaimplementowanych jako protokół dla Twojej organizacji.

Na przykład użytkownik, który ma uprawnienia roota, może wyrządzić wiele szkód, takich jak usunięcie wszystkich danych z fizycznego dysku, zresetowanie hasła roota, utworzenie własnego użytkownika/hasła, które wygląda jak legalny użytkownik (może być używany przez bardzo długi czas do zbierania danych, chyba że zostanie złapany wcześnie), sudo do innego użytkownika systemu operacyjnego, takiego jak użytkownik postgres, i wiele bardziej przerażających rzeczy, którymi może się cieszyć intruz.

Jeżeli korzystasz z MongoDB, użytkownik z uprawnieniami roota może zalogować się do serwera bazy danych. Tak długo, jak intruz może zlokalizować twój /etc/mongod.conf lub plik konfiguracyjny mongodb i zlokalizować ścieżkę twojego klucza, logowanie jest łatwe. Na przykład użycie tego polecenia umożliwia zalogowanie się,

[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"

Rozważ normalną konfigurację instalacji MySQL, dostęp roota można pozostawić bez hasła dostępu do hosta lokalnego. Łatwo jest uzyskać dostęp, gdy jesteś rootem. Dostęp do plików, takich jak $HOME/.my.cnf lub przeglądanie zawartości /etc/my.cnf, zapewni łatwy dostęp.

Usilnie zaleca się, aby ograniczyć dostęp do konta roota tylko lub tylko do jak najmniejszej liczby osób, które pracują bezpośrednio z serwerem w celu aktualizacji pakietów, aktualizacji zabezpieczeń i stosowania poprawek wymaganych przez zespół programistów.

Właściwe używanie sudoers

Główne oprogramowanie baz danych typu open source, takie jak PostgreSQL, MySQL/MariaDB, MongoDB, wymaga utworzenia określonego użytkownika systemu operacyjnego. Użytkownik systemu operacyjnego wymaga określonej roli ograniczonej, aby umożliwić zarządzanie jego możliwościami w ramach funkcjonalności bazy danych. Należy ustawić odpowiednie uprawnienia do odczytu i zapisu dla podstawowej ścieżki urządzenia pamięci masowej. Zdarzają się jednak przypadki, w których niektórzy, którzy używają tych konkretnych użytkowników do oprogramowania bazodanowego, mają uprawnienia sudo, które są również w stanie uzyskać dostęp do użytkownika przeznaczonego wyłącznie do dostępu do bazy danych. Uprawnienia użytkownika w systemie operacyjnym muszą być ograniczone i najlepiej ograniczyć jego dostęp na podstawie roli. Na przykład w przypadku Percona Server CVE-2016-6664, chociaż zostało to naprawione, ten typ luki jest przykładem możliwego ataku ze strony konkretnego użytkownika, który ma dostęp do konta MySQL i uzyskuje uprawnienia roota. Użytkownicy Sudo muszą zostać przejrzani i zrozumieli, że rola jest ograniczona tylko do wykonywania określonej pracy.

Włączenie systemu audytu Linux, takiego jak auditd, może pomóc w poprawie bezpieczeństwa, ponieważ podnosi przeoczone uprawnienia dostępu na poziomie systemu operacyjnego, co może prowadzić do luk w zabezpieczeniach bazy danych. SELinux i AppArmor są dobrymi przykładami modułów bezpieczeństwa dla środowiska Linux, które obsługują system baz danych, aby poprawić bezpieczeństwo przed intruzami lub naruszeniami, które mogłyby doprowadzić do narażenia danych.

Przyznawanie uprawnień dostępu do bazy danych

Główne bazy danych typu open source oferują szczegółową listę uprawnień, które można dostosować w celu przypisania tylko do określonej akcji dla określonego użytkownika. Jest to obszerny sposób, aby pomóc administratorom baz danych w bezpiecznym separacji danych i ukierunkowaniu działań na podstawie określonych uprawnień.

Wspólne uprawnienia dostępu

Najczęściej używane uprawnienia będą oparte na tych trzech kategoriach:

  • Możliwość odczytu/znalezienia, np. WYBIERZ, POKAŻ WIDOK, ZNAJDŹ

  • Możliwość wstawiania/aktualizowania/usuwania, takich jak WSTAW, AKTUALIZUJ, USUŃ, USUŃ

  • Możliwość wykonywania czynności administracyjnych, takich jak CREATE USER, CREATE ROLE, ALTER, REPLICATION, DROP USER/TABLES/ SCHEMATY, operacje kill itp.

Te kategorie można rozszerzyć na bardziej wyrafinowane uprawnienia w oparciu o listę kontrolną zabezpieczeń. Dobrze jest zdefiniować konkretnego użytkownika, który zostanie utworzony z określonymi uprawnieniami do konkretnego zadania. Na przykład aplikacja może mieć wielu użytkowników z przypisanymi własnymi uprawnieniami. Chociaż aplikacja może być równie skomplikowana przy tego typu implementacji. Istnieją przypadki, w których łączność na użytkownika może wymagać dużych zasobów, na przykład przy użyciu ORM, takiego jak Hibernate. Z drugiej strony zależy to od projektu architektonicznego Twojej aplikacji. Cel bazy danych na użytkownika w aplikacji może pomóc w utrzymaniu bardziej wyrafinowanych uprawnień dostępu do bazy danych i uniknąć uszkodzenia danych w wyniku niechcianego usunięcia, aktualizacji lub wstrzyknięcia SQL atakującego bazę danych.

W większości przypadków aplikacja używa jednego użytkownika do łączenia się z bazą danych, która ogranicza się tylko do działań wykonywanych specjalnie w celu uruchomienia aplikacji. Najlepiej zaprojektować uprawnienia użytkownika aplikacji tylko do odczytu i zapisu. Zważywszy, że jeśli wymagane są działania administracyjne, określony skrypt, demon lub moduł w dostępie do aplikacji musi być oddzielony od zwykłych użytkowników.-.

Dostęp do bazy danych, którego należy unikać

PostgreSQL i MySQL/MariaDB mają tę opcję, aby nadać użytkownikowi WSZYSTKIE uprawnienia. W przypadku PostgreSQL najlepiej jest mieć użytkownika z NOSUPERUSER. Jeśli to możliwe, należy tego unikać za wszelką cenę. To uprawnienie może wykonać większość wszystkich czynności, które mogą potencjalnie zniszczyć lub uszkodzić cenne dane. Możesz używać WSZYSTKICH uprawnień administratora lub administratora, ale są one ograniczone tylko do użytkowników, którzy wymagają superuprawnień do wykonywania zadań administracyjnych i zarządzania danymi.

Dostęp na podstawie tabeli lub schematu

Dobrą praktyką jest zapewnienie użytkownikowi dostępu tylko do wymaganych tabel. . Tak więc, nawet jeśli użytkownik ma pewne uprawnienia administracyjne, wszelkie szkody dotyczą tylko ograniczonego zestawu tabel. Albo możesz ustawić na całym schemacie; zapewnienie dostępu do ograniczonej tabeli zapewnia szczegółowe uprawnienia i pomaga chronić dane przed uszkodzeniem.

Dostęp ograniczony tylko do hosta

Łączenie za pośrednictwem adresu IP zasobów pomaga ograniczyć dostęp do Twoich danych. Unikaj używania '%' tak, że na przykład w MySQL

GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';

Zakres szkód jest narażony na każdy host, z którym można się połączyć, a nie to, co chciałeś, aby się stało. Nakłada to na podatność, a wyzwanie włamania się do bazy danych jest bardzo niskie.

W przypadku PostgreSQL upewnij się, że ustawiłeś swój pg_hba.conf i użytkownika tylko na określony limit hosta. Dotyczy to również MongoDB, dla którego można to ustawić w pliku konfiguracyjnym MongoDB lub /etc/mongodb.conf. W MongoDB możesz pobawić się ograniczeniami uwierzytelniania i ustawić odpowiednio clientSource lub serverAddress, ale tylko w przypadku, gdy wymagasz, aby klient lub użytkownik nawiązał połączenie lub został zweryfikowany.

Kontrola dostępu oparta na rolach

Kontrola dostępu oparta na rolach (RBAC) w bazach danych zapewnia wygodny sposób zarządzania użytkownikiem lub łatwy sposób grupowania użytkownika z wyznaczonymi uprawnieniami powiązanymi z listą użytkowników lub grupą użytkowników.

Chociaż trzeba pamiętać, że role są obsługiwane inaczej w dowolnych bazach danych o otwartym kodzie źródłowym. Na przykład MySQL zdefiniował role w następujący sposób:

Rola MySQL to nazwana kolekcja uprawnień. Podobnie jak konta użytkowników, role mogą mieć nadane i odebrane uprawnienia.

Konto użytkownika może mieć przypisane role, które nadają temu kontu uprawnienia związane z każdą rolą. Umożliwia to przypisywanie zestawów uprawnień do kont i stanowi wygodną alternatywę dla nadawania indywidualnych uprawnień, zarówno w celu konceptualizacji przypisania pożądanych uprawnień, jak i ich implementacji.

MongoDB definiuje rolę z RBAC jako,

MongoDB wykorzystuje kontrolę dostępu opartą na rolach (RBAC) do zarządzania dostępem do systemu MongoDB. Użytkownik otrzymuje jedną lub więcej ról, które określają dostęp użytkownika do zasobów i operacji bazy danych. Poza przypisaniem ról użytkownik nie ma dostępu do systemu.

W PostgreSQL

PostgreSQL zarządza uprawnieniami dostępu do bazy danych przy użyciu koncepcji ról. Rolę można traktować jako użytkownika bazy danych lub grupę użytkowników bazy danych, w zależności od konfiguracji roli. Role mogą być właścicielami obiektów bazy danych (na przykład tabel i funkcji) i mogą przypisywać uprawnienia do tych obiektów innym rolom, aby kontrolować, kto ma dostęp do jakich obiektów. Co więcej, możliwe jest przyznanie członkostwa w roli innej roli, dzięki czemu rola członka może korzystać z uprawnień przypisanych do innej roli.

Pojęcie ról obejmuje pojęcia „użytkowników” i „grup”. W wersjach PostgreSQL przed 8.1 użytkownicy i grupy były odrębnymi rodzajami bytów, ale teraz są tylko role. Każda rola może działać jako użytkownik, grupa lub jedno i drugie.

Chociaż te bazy danych implementują role specyficzne dla ich użycia, podzielają koncepcję przypisywania ról użytkownikowi w celu wygodnego przypisywania uprawnień. Korzystanie z ról umożliwia administratorom baz danych zarządzanie wymaganymi użytkownikami w celu zalogowania się lub uzyskania dostępu do bazy danych.

Wyobraź sobie, że masz listę użytkowników, którymi musisz zarządzać, lub listę użytkowników, które można usunąć lub odwołać, gdy nie są już potrzebne. W niektórych szczególnych przypadkach, jeśli określone zadanie wymaga wykonania, administratorzy baz danych mogą tworzyć użytkowników z już istniejącymi rolami. Tych utworzonych użytkowników można przypisać do określonej roli na krótki okres, a następnie odwołać, gdy nie jest to potrzebne.

Audyty pomagają również w segregacji użytkowników, którzy mają podejrzenie o luki w zabezpieczeniach lub ujawnienie danych, więc w takim przypadku pomaga bardzo łatwo zarządzać użytkownikami z rolami.

System zarządzania użytkownikami

Jeżeli bezpieczeństwo Twoich danych jest odpowiednio obsługiwane i wdrożone, toruje Ci to drogę do sukcesu. Chociaż nie ma idealnego rozwiązania, ponieważ luki i włamania zawsze ewoluują. Jest jak robak, który cały czas próbuje się czaić, aż będzie w stanie osiągnąć swój cel, naruszyć Twoje bezpieczeństwo i uzyskać dostęp do Twoich danych. Bez odpowiednich narzędzi, takich jak systemy ostrzegania lub powiadomienia o wszelkich zagrożeniach i lukach, trudno byłoby zabezpieczyć Twoje dane.

ClusterControl pomaga zarządzać użytkownikami i weryfikować lub sprawdzać uprawnienia użytkownika od systemów równoważenia obciążenia do głównych użytkowników bazy danych. Oferuje również doradców i alerty, dzięki którym powiadomi Cię o możliwych lukach w zabezpieczeniach lub włamaniach.

Na przykład używanie bazy danych MySQL/MariaDB z wbudowanymi funkcjami importowania i dodawania użytkowników ProxySQL. W celu importowania użytkowników zbiera listę użytkowników, którzy są obecni w bieżącym klastrze MySQL/MariaDB i oferuje przegląd aktualnych uprawnień. Zobacz poniżej,

Również w tym przypadku użytkownik ProxySQL może zostać szybko dezaktywowany, jeśli taka luka jest znany dla konkretnego użytkownika.

ClusterControl oferuje również bezpośrednie zarządzanie użytkownikami z Twojej bazy danych, takiej jak MySQL/MariaDB lub PostgreSQL. W przypadku MySQL/MariaDB możesz przejść do → Zarządzaj → Schematy i użytkownicy.

Dla PostgreSQL, → Zarządzaj → Zarządzanie użytkownikami.

Dzięki ClusterControl możesz dostosować swoje alerty za pomocą doradców. Doradcy to jednostki oparte na skryptach, które można modyfikować. Na przykład jest to klaster MySQL/MariaDB, jak pokazano poniżej, do którego można uzyskać dostęp poprzez → Wydajność → Doradcy:

Klikając przycisk Edytuj, możesz dostosować sposób, w jaki ClusterControl będzie reagował w przypadku znalezienia użytkowników z dowolnym hostem lub „%” lub użytkownika bez hasła. Zobacz, jak skrypt jest wyświetlany po naciśnięciu przycisku przycisk Edytuj.

Gdy ClusterControl dowie się, że którykolwiek z tych doradców został uruchomiony, zostanie wyświetlony alert, który zostanie również wysłany na skonfigurowany adres e-mail lub jeśli jakiekolwiek powiadomienia stron trzecich są zintegrowane, zostanie powiadomiony tam też.

Wnioski

Uprawnienia dostępu do bazy danych to jeden z głównych celów związanych z naruszeniami i włamaniami do danych. Jeśli użytkownik Twojej bazy danych zostanie ujawniony lub wystąpiło poważne zagrożenie dla bieżącej wersji bazy danych, która nie została załatana, prawdopodobieństwo zhakowania lub ataku ransomware i kradzieży jest bardzo wysokie. Zrozumienie uprawnień dostępu i ustawienie prawidłowych limitów pomoże złagodzić niebezpieczeństwa związane z ujawnieniem cennych danych.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Jak zaktualizować pola dokumentów MongoDB tylko wtedy, gdy nie istnieją?

  2. Zrozumienie limitu rozmiaru dokumentu MongoDB BSON

  3. Określ wiele kryteriów dla elementów tablicy

  4. Wyjaśnienie SQL COALESCE()

  5. Tworzenie bazy danych w Mongo:nie można się połączyć, połączenie nie powiodło się