Złośliwy użytkownik może znaleźć luki, które będą wykorzystywać bazę danych MySQL organizacji. Dlatego monitorowanie aktywności baz danych powinno być podstawową praktyką każdej firmy. Hakerzy przeprowadzają ataki mające na celu kradzież poufnych danych, a ich głównym celem są serwery baz danych MySQL organizacji. Bazy danych są jednym z najbardziej zagrożonych zasobów.
Dlaczego baza danych jest tak często celem ataków? Prostota - baza danych jest sercem każdej organizacji, która przechowuje rekordy klientów i inne poufne dane biznesowe. Organizacje dają najmniejszy priorytet, jeśli chodzi o ochronę tych kluczowych zasobów.
Gdy hakerzy i złośliwi specjaliści uzyskają dostęp do poufnych danych, ich następnym krokiem jest szybkie wydobycie wartości, narzucenie szkód lub wpłynięcie na operacje biznesowe. Oprócz strat finansowych lub uszczerbku na reputacji naruszenia te skutkują również naruszeniami przepisów, grzywnami, opłatami prawnymi itp.
Przyjrzyjmy się poniższemu studium przypadku, w którym klient stracił miliony dolarów z powodu złośliwej aktywności w swojej bazie danych:
Studium przypadku
Nazwa firmy: Capital One
Połączyć: https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html
Problem:
Bank Capital One ponosi jedną z największych strat w wysokości 150 milionów w wyniku ataku podatności.
Konsekwencja:
Inżynier oprogramowania i poprzedni pracownik banku Capital One włamał się na serwer firmy, przechowując dane klientów i przechwycił dane osobowe ponad 100 milionów osób. Amazon Web Services obsługuje bazę danych klientów, a nawiasem mówiąc, inżynier był również wcześniej zatrudniony w Amazon.
Według sądu i Capital One haker ukradł 140,000 80,000 numerów ubezpieczenia społecznego i 2005 2019 numerów kont bankowych. Oprócz dziesiątek milionów wniosków o karty kredytowe zostały również złamane. Kradzież naruszyła milion kanadyjskich numerów ubezpieczenia społecznego, które są równoważne numerom ubezpieczenia społecznego Amerykanów. Zakres skradzionych danych był już w XNUMX roku, a najpóźniej w XNUMX roku.
Bank złożył oświadczenie, że spodziewa się, że naruszenie będzie kosztować go do 150 mln USD, w tym zapłacenie za monitorowanie kredytów dla klientów, których dotyczy problem. Naruszenie było możliwe, ponieważ w ich zaporze ogniowej była otwarta luka, a haker mógł łatwo uzyskać dostęp do hostowanej bazy danych w AWS.
Będąc byłym pracownikiem AWS, luka została dobrze wykorzystana do włamania się do bazy danych i manipulowania danymi klientów. Potencjalna wiedza na temat sposobu wykorzystania luki.
Jak wiemy, do przechowywania wszystkich danych klientów i transakcji służą bazy danych. Haker manipulował bazą danych, dodając / usuwając lub nawet wyodrębniając dane z bazy danych banku.
Gdyby mieli odpowiednie zabezpieczenia do monitorowania tej bazy danych, co można zrobić za pomocą Żmanda ZRM, takie zagrożenie mogło zostać wykryte i proaktywnie powstrzymane. Bank naprawił lukę i obecnie stosuje bardziej rygorystyczne metody kontroli takich oszustw.
Wykrywanie złośliwego oprogramowania Aktywność bazy danych MySQL przy użyciu Zmanda
Organizacje powinny przyjąć wielowarstwową strategię ochrony bezpieczeństwa baz danych. Dzięki przyjęciu najlepszych praktyk można rozsądnie zmniejszyć ryzyko narażenia danych spowodowane przez różne ataki wektory. Na przykład Zmanda może wykrywać złośliwe działania z kopii zapasowych baz danych
ZRM dla MySQL przechowuje dzienniki binarne MySQL jako część kopii zapasowych bazy danych. Dzienniki binarne zapewniają odpowiednią ścieżkę audytu wszystkich działań w bazie danych. Plik binarny ZRM dla MySQL korzysta z funkcji analizowania dzienników dla odzyskiwania z określonego punktu w czasie, wykrywając złośliwą aktywność w bazie danych za pomocą inspekcji SQL.
Interfejs wtyczki ZRM dla MySQL umożliwia administratorom bazy danych (administrator bazy danych) pisanie skryptów wtyczki parsera dziennika w celu śledzenia i monitorowania określonej / całej aktywności bazy danych. Na przykład poniższy kod może wykryć usunięcie danych z tabeli PRODUCTS w bazie danych. Ten skrypt wyświetla wszystkie wystąpienia usuniętych pozycji z tabeli PRODUCTS.
@fields = split (/ \ | /, $ ARGV [0]);
my $ SQL_VERB = ”USUŃ”;
moja $ TABLE_NAME = ”PRODUKTY”;
if (($ fields [3] == „Zapytanie”) && \
($ fields [4] = ~ / $ SQL_VERB * FROM. * `$ TABLE_NAME` /)) {
print „$ pola [2] $ pola [4] \ n”;
}
Polecenie mysql-zrm uruchamia dostosowany skrypt wtyczki dla wszystkich kopii zapasowych lub określonego obrazu kopii zapasowej. Następujące polecenie szuka usunięcia z tabeli PRODUCTS na obrazie kopii zapasowej z 9 grudnia 2019 r.
# mysql-zrm-działanie parse-binlogs \
–Source-directory / var / lib / mysql-zrm / pricebook / 20061205142103 \
–Parse-binlogs-plugin /usr/share/mysql-zrm/plugins/detect_deletion.pl
Dane wyjściowe polecenia będą zawierać prawidłowe usunięcia, a także złośliwe usunięcia bazy danych.
Podobnie, klienci mogą skonfigurować własny skrypt i uruchomić go i zweryfikować przed i po utworzeniu kopii zapasowej zgodnie z potrzebą i jest to funkcja wyróżniająca ZRM dla MySQL.
Poniższy zrzut ekranu odnosi się do strony Backup | How w ZRM, gdzie możesz skonfigurować nazwę wtyczki, ścieżkę i wykonanie.
Parametr przed i po backup-plugin powinien zawierać nazwę i pełną ścieżkę do wtyczki. Zalecana lokalizacja dla wtyczek w katalogu „/ usr / share / mysql-is database / plugins”.
Zakończyć!
Pomimo wysokiego poziomu świadomości na temat różnych zagrożeń związanych z lukami w zabezpieczeniach, liczba incydentów wzrosła w ostatnich latach. W wyniku kosztów poniesionych przez ofiary tych incydentów wzrosły koszty operacyjne do bardzo znaczącego poziomu ze względu na wzrost naruszeń danych. Aby zmniejszyć wpływ tych zdarzeń, organizacja musi przyjąć odpowiednie procedury, aby zminimalizować całkowity koszt poniesiony z powodu naruszenia danych i braku skutecznego narzędzia do monitorowania i wykrywania.
Koniecznie sprawdź także Punkty, które należy uwzględnić w planie odzyskiwania po awarii
