Głównym celem tego zadania jest nauczenie studenta przeprowadzania procesu "utwardzania" (ang. hardening) serwera MySQL/MariaDB, czyli eliminacji najczęstszych i najbardziej krytycznych luk w zabezpieczeniach, które często występują w domyślnej konfiguracji. Zadanie to wykracza poza samo ustawienie hasła dla konta `root` i skupia się na systematycznym podejściu do audytu i poprawy bezpieczeństwa. Student nauczy się identyfikować i usuwać niepotrzebne, anonimowe konta, blokować zdalny dostęp do kont administracyjnych oraz pozbywać się domyślnych, testowych baz danych, które mogą stanowić wektor ataku. Co najważniejsze, zadanie to w praktyczny sposób wdraża fundamentalną zasadę bezpieczeństwa IT – zasadę najmniejszych uprawnień (Principle of Least Privilege). Student nauczy się tworzyć dedykowane konta użytkowników z precyzyjnie ograniczonym dostępem, co jest kluczowe w minimalizowaniu ryzyka i potencjalnych szkód w przypadku kompromitacji.
Student, pełniący rolę młodszego administratora bazy danych w projekcie hotelowym, otrzymuje swoje pierwsze odpowiedzialne zadanie: przeprowadzić audyt bezpieczeństwa świeżo zainstalowanego serwera i wdrożyć podstawowe zalecenia. Wie, że samo ustawienie hasła dla `root` to za mało. Rozpoczyna pracę, logując się na serwer z uprawnieniami administracyjnymi. Jego pierwszym krokiem jest dokładna inwentaryzacja istniejących kont. Wykonuje zapytanie `SELECT User, Host FROM mysql.user;` i z niepokojem odkrywa kilka potencjalnych problemów. Na liście znajduje się użytkownik z pustą nazwą (`''`), co oznacza, że każdy może się połączyć bez podawania nazwy użytkownika. Widzi również, że konto `root` jest skonfigurowane nie tylko dla `localhost`, ale także dla innych hostów, takich jak `::1` (odpowiednik localhost dla IPv6) czy `127.0.0.1`, a w niektórych domyślnych konfiguracjach mogłoby nawet istnieć niebezpieczne konto `root@'%'`. Działając metodycznie, student przystępuje do eliminacji tych zagrożeń. Za pomocą polecenia `DELETE` precyzyjnie usuwa z tabeli `mysql.user` wszystkie anonimowe konta. Następnie, z jeszcze większą ostrożnością, usuwa wszystkie wpisy dla użytkownika `root`, które nie są związane z `localhost`, skutecznie blokując wszelkie próby zdalnego logowania na konto superużytkownika. Kolejnym punktem na jego liście jest sprawdzenie istnienia domyślnej bazy danych o nazwie `test`. Wykonując `SHOW DATABASES;`, potwierdza jej obecność i bez wahania usuwa ją za pomocą `DROP DATABASE`, wiedząc, że jest ona często wykorzystywana przez automatyczne skanery do testowania znanych luk. Teraz, gdy serwer jest już wstępnie "oczyszczony", student przechodzi do wdrożenia zasady najmniejszych uprawnień. Zamiast pozwalać aplikacji na łączenie się z konta `root`, tworzy dwa dedykowane konta. Pierwsze, `app_user@localhost`, z bardzo ograniczonymi prawami, pozwalającymi tylko na operacje `SELECT`, `INSERT`, `UPDATE` na tabelach w bazie hotelowej. Drugie konto, `admin_user@localhost`, z szerszymi uprawnieniami, które pozwolą na przyszłe modyfikacje struktury bazy (np. `ALTER`, `CREATE`). Na koniec, aby zweryfikować swoją pracę, wylogowuje się z konta `root` i loguje się kolejno na oba nowe konta, testując, czy ich uprawnienia faktycznie są ograniczone zgodnie z założeniami. Próba stworzenia nowej tabeli z konta `app_user` kończy się błędem "Access denied", co jest dla niego potwierdzeniem dobrze wykonanej pracy.
Zaloguj się do konsoli MySQL na konto `root`. Pierwszym krokiem jest zawsze zorientowanie się w aktualnej konfiguracji. Wykonaj poniższe zapytanie, aby zobaczyć, jakie konta są obecnie zdefiniowane w Twoim serwerze.
-- To zapytanie jest kluczowe dla audytu bezpieczeństwa. -- Wyświetla wszystkie kombinacje użytkowników i hostów, z których mogą się oni łączyć. SELECT User, Host FROM mysql.user;
Jeśli audyt wykazał istnienie użytkowników z pustą nazwą, należy ich natychmiast usunąć. Są oni reliktem starszych wersji MySQL i nie powinni istnieć w żadnym środowisku.
-- Usuwamy wszystkie wiersze z tabeli `user`, gdzie nazwa użytkownika jest pustym ciągiem znaków. DELETE FROM mysql.user WHERE User = ''; -- Zawsze po operacjach na tabelach systemowych, przeładowujemy uprawnienia. FLUSH PRIVILEGES;
Konto `root` powinno mieć możliwość logowania się tylko i wyłącznie z lokalnej maszyny (`localhost`). Jeśli istnieją inne wpisy, należy je usunąć.
-- To polecenie usuwa wszystkie konta 'root', które NIE są przypisane do 'localhost'. -- Operator `!=` oznacza "różny od". DELETE FROM mysql.user WHERE User = 'root' AND Host != 'localhost'; FLUSH PRIVILEGES;
Domyślna baza `test` jest publicznie znana i może być wykorzystana do testowania różnych technik ataku. Należy ją usunąć.
-- `IF EXISTS` zapobiega wyświetleniu błędu, jeśli baza o tej nazwie nie istnieje. DROP DATABASE IF EXISTS test; FLUSH PRIVILEGES;
Tworzymy dedykowane konto dla naszej aplikacji hotelowej. Będzie ono miało tylko te uprawnienia, które są niezbędne do jej funkcjonowania.
-- Tworzymy użytkownika 'hotel_app' z hasłem, dostępnego tylko z localhost. CREATE USER 'hotel_app'@'localhost' IDENTIFIED BY 'TrudneHasloAplikacji456!'; -- Nadajemy mu prawa do odczytu, zapisu i modyfikacji danych we WSZYSTKICH tabelach bazy 'test_hotel'. GRANT SELECT, INSERT, UPDATE, DELETE ON test_hotel.* TO 'hotel_app'@'localhost'; -- Sprawdźmy, jakie dokładnie uprawnienia nadaliśmy. SHOW GRANTS FOR 'hotel_app'@'localhost'; FLUSH PRIVILEGES;
Bezpieczeństwo systemu informatycznego jest tak silne, jak jego najsłabsze ogniwo. To zadanie udowodniło, że domyślna konfiguracja serwera bazy danych często zawiera takie słabe ogniwa, które należy świadomie zidentyfikować i wyeliminować. Proces "utwardzania" serwera, obejmujący usunięcie niepotrzebnych kont i baz oraz ograniczenie dostępu do konta `root`, jest absolutnie niezbędnym krokiem w każdym profesjonalnym wdrożeniu. Jednak najważniejszym wnioskiem płynącym z tego ćwiczenia jest głębokie zrozumienie i praktyczne zastosowanie zasady najmniejszych uprawnień. Tworzenie dedykowanych ról i kont dla poszczególnych aplikacji i użytkowników, z precyzyjnie skrojonym zestawem uprawnień, jest fundamentem nowoczesnego podejścia do bezpieczeństwa baz danych. Takie działanie drastycznie ogranicza potencjalne szkody – nawet jeśli atakujący przejmie kontrolę nad kontem aplikacji, jego możliwości działania będą ograniczone tylko do tych operacji, które były absolutnie niezbędne do jej funkcjonowania. Wdrożenie tych praktyk od samego początku projektu jest inwestycją, która procentuje w postaci stabilnego, bezpiecznego i niezawodnego systemu.