W dzisiejszym świecie organizacje coraz częściej stają w obliczu bezprecedensowego poziomu zagrożenia cyberatakami na ich zasoby informacyjne.
Cyberataki mogą przybierać różne formy. Jeden z takich ataków nazywa się wstrzykiwanie SQL . Dzięki wstrzyknięciu SQL nieuczciwi gracze atakują bazę danych zaplecza dowolnego systemu. Zazwyczaj te systemy są dostępne publicznie. Hakerzy próbują wysyłać pozornie nieszkodliwe i regularne zapytania do bazy danych – z wyjątkiem parametrów, które mogą ujawnić informacje, których nie powinni widzieć, lub uszkodzić bazę danych błędnymi informacjami lub spowodować awarię systemu.
Specjaliści od cyberbezpieczeństwa zawsze ścigają się z czasem, aby wyprzedzić wyrafinowanie tych ataków, i jak większość wielkich wojen, teraz toczy się na każdym froncie. Oznacza to, że zabezpieczenia muszą być zaimplementowane w każdej warstwie stosu aplikacji – w tym w warstwie bazy danych.
Doświadczeni administratorzy baz danych zazwyczaj próbują zabezpieczyć bazy danych za pomocą środków, takich jak kontrola dostępu oparta na rolach (RBAC), uwierzytelnianie federacyjne, inspekcja lub SSL. Należy jednak rozważyć również wszelkie dodatkowe środki zabezpieczające bazę danych.
Jednym z takich środków ochrony jest zapora bazy danych. Podobnie jak zwykłe zapory, zapory baz danych odfiltrowują ruch na podstawie białej lub czarnej listy. Mogą również „uczyć się” na podstawie wzorców dostępu do systemu, aby zrozumieć, jakim stwierdzeniom można ufać, a którym nie. Korzystanie z takiego narzędzia dodaje silną warstwę ochrony przed wstrzyknięciem SQL.
W tym artykule omówimy Zaporę SQL , firewall bazy danych do ochrony baz danych PostgreSQL. SQL Firewall jest zbudowany i wspierany przez 2ndQuadrant, lidera w technologii PostgreSQL.
Jak działa zapora SQL
Zapora SQL jest rozszerzeniem PostgreSQL 9.4 i nowszych. Chociaż jest obecnie obsługiwany do wersji PostgreSQL 10, trwają dalsze prace nad obsługą późniejszych wersji.
Ponieważ jest to rozszerzenie, SQL Firewall jest bardzo prosty w instalacji i konfiguracji. Po skonfigurowaniu może być używany do umieszczania na białej liście instrukcji SQL w bazach danych dla poszczególnych użytkowników. Biała lista pochodzi z „wytrenowania” rozszerzenia pod kątem typowego obciążenia aplikacji — zwykle pochodzącego z wielokrotnych uruchomień zestawu testów obejmujących wszystkie możliwe scenariusze. Po dopracowaniu i sfinalizowaniu białej listy można ją wyeksportować, a następnie zaimportować do innych instancji PostgreSQL obsługujących podobne obciążenia.
Na przykład przed uruchomieniem aplikacji każdy skonfigurowany użytkownik może uruchomić przykładowe obciążenia o jakości produkcyjnej na bazie danych w kontrolowanym środowisku. Konto użytkownika może mieć uprawnienia do uruchamiania zapytań tylko do odczytu, podczas gdy konto użytkownika aplikacji może mieć uprawnienia do uruchamiania zarówno odczytów, jak i zapisów. Zapora SQL umieszcza następnie na białej liście zapytania odczytu zarówno dla kont użytkowników, jak i kont użytkowników aplikacji oraz zapisują zapytania tylko dla kont użytkowników aplikacji. Jeśli użytkownik-człowiek spróbuje następnie wykonać operację INSERT, DELETE lub UPDATE, zapora SQL odmówi wykonania operacji. W miarę rozwoju aplikacji białą listę można również przeszkolić w zależności od zmieniającego się obciążenia.
Każda zablokowana instrukcja jest rejestrowana przez zaporę SQL, co oznacza, że zespoły operacyjne mogą wysyłać te dzienniki do swoich rozwiązań do zarządzania dziennikami i otrzymywać alerty za każdym razem, gdy wystąpi wyjątek.
Konfigurowanie środowiska
W tym artykule zainstalujemy zaporę SQL Firewall dla jednowęzłowej instancji PostgreSQL 10 działającej w systemie Red Hat Enterprise Linux 7. W momencie pisania tego tekstu RHEL/CentOS 7 i PostgreSQL 10 są najbardziej obsługiwanymi wersjami. Jednak, jak wspomniano wcześniej, nadchodzi dalsze wsparcie.
Uwaga
[Należy pamiętać, że zapora SQL jest produktem licencjonowanym na zasadach komercyjnych, dostępnym dla klientów pomocy technicznej 24/7. Nie można go pobrać z publicznej strony internetowej 2nd Quadrant.]
Krok 1:Instalacja PostgreSQL 10
Nasz system testowy to instancja Amazon EC2 z systemem Red Hat Enterprise Linux 7.2.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
Uruchamiamy następujące polecenie, aby pobrać repozytorium RPM dla PostgreSQL 10 (x86-64).
# yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm -y
Następnie instalujemy serwer i pakiet klienta.
# yum install postgresql10-server postgresql10 -y
Po pomyślnym zainstalowaniu pakietów uruchamiamy polecenie initdb, aby zainicjować bazę danych.
# /usr/pgsql-10/bin/postgresql-10-setup initdb Initializing database ... OK
Następnie wprowadzamy następującą zmianę w pliku postgresql.conf. Domyślnie znajduje się w katalogu /var/lib/pgsql/10/data/.
listen_addresses = '*'
A następnie dodaj następujący wiersz do pliku pg_hba.conf (ponownie, domyślnie, znajduje się on w katalogu /var/lib/pgsql/10/data/).
host all all <our IP address range> md5
Następnie uruchamiamy usługę PostgreSQL i włączamy ją automatycznie.
# systemctl start postgresql-10.service # systemctl enable postgresql-10.service
Na koniec logujemy się do instancji bazy danych z psql jako użytkownik postgres i zmieniamy hasło.
# su - postgres -bash-4.2$ psql psql (10.12) Type "help" for help. postgres=# \password Enter new password: Enter it again: postgres=#
Krok 2:Przywróć przykładowe bazy danych
Aby emulować system produkcyjny, przywróciliśmy dwie przykładowe bazy danych na naszym serwerze PostgreSQL. Te bazy danych są publicznie dostępne:
- Pagila : wersja PostgreSQL popularnej bazy danych MySQL Sakila
- Chinook :baza danych o sklepie z mediami cyfrowymi
Krok 3:Utwórz role i użytkowników
Z utworzonych baz danych tworzymy dwie role użytkowników. Jeden nazywa się „human_user”, drugi to „app_user”.
Rola human_user reprezentuje dowolną osobę uzyskującą dostęp do bazy danych z zaplecza lub za pomocą narzędzia klienckiego. Rola app_user reprezentuje konto, którego aplikacja będzie używać do łączenia się z bazą danych.
psql -d postgres -c "CREATE ROLE human_user WITH NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT LOGIN NOREPLICATION PASSWORD '<a tough password>';" psql -d postgres -c "CREATE ROLE app_user WITH NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT LOGIN NOREPLICATION PASSWORD '<a tough password>';"
Role użytkowników otrzymują następnie uprawnienia dostępu do baz danych chinook i pagila, uruchamiając następujące polecenia jako użytkownik postgres:
$ psql -d postgres -c "GRANT CONNECT ON DATABASE pagila, chinook TO app_user;" $ psql -d chinook -c "GRANT USAGE ON SCHEMA public TO app_user;" $ psql -d chinook -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_user;" $ psql -d chinook -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO app_user;" $ psql -d chinook -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO app_user;" $ psql -d pagila -c "GRANT USAGE ON SCHEMA public TO app_user;" $ psql -d pagila -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_user;" $ psql -d pagila -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO app_user;" $ psql -d pagila -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO app_user;" $ psql -d postgres -c "GRANT CONNECT ON DATABASE pagila, chinook TO human_user;" $ psql -d chinook -c "GRANT USAGE ON SCHEMA public TO human_user;" $ psql -d chinook -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO human_user;" $ psql -d chinook -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO human_user;" $ psql -d chinook -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO human_user;" $ psql -d pagila -c "GRANT USAGE ON SCHEMA public TO human_user;" $ psql -d pagila -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO human_user;" $ psql -d pagila -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO human_user;" $ psql -d pagila -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO human_user;"
Krok 4:Instalowanie zapory SQL
Instalowanie zapory SQL jest prostym procesem. Najpierw instalujemy pakiet.
# rpm -ivh postgresql10-sqlfirewall-3.0-1.el7.x86_64.rpm warning: postgresql10-sqlfirewall-3.0-1.el7.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID ******: NOKEY Preparing... ################################# [100%] Updating / installing... 1:postgresql10-sqlfirewall-3.0-1.el################################# [100%]
Następnie aktualizujemy plik postgresql.conf, zmieniając parametr shared_preload_libraries.
shared_preload_libraries = 'sqlfirewall'
Po zakończeniu ponownie uruchamiamy usługę PostgreSQL.
# systemctl restart postgresql-10.service
Po ponownym uruchomieniu usługi logujemy się do instancji jako użytkownik postgres i dodajemy rozszerzenie do obu przykładowych baz danych.
$ psql -U postgres -d chinook -c "CREATE EXTENSION sqlfirewall;" Password for user postgres: CREATE EXTENSION -bash-4.2$ psql -U postgres -d pagila -c "CREATE EXTENSION sqlfirewall;" Password for user postgres: CREATE EXTENSION
Poniższy obrazek pokazuje rozszerzenia zainstalowane w obu bazach danych. Zwróć uwagę, że istnieje specjalny schemat o nazwie „sqlfirewall” również utworzony w obu bazach danych. Ten schemat zawiera wszystkie obiekty bazy danych związane z działaniem Zapory SQL.
Możemy również zobaczyć, że nowa rola o nazwie „sqlfirewall_manager” jest tworzona automatycznie. Użytkownicy dodani do tej roli mają dostęp do funkcji i widoków w schemacie sqlfirewall.
Krok 5:Konfiguracja zapory SQL
Szereg parametrów jest następnie dodawanych do pliku postgresql.conf plik. W przypadku Red Hat Enterprise Linux i jego pochodnych dystrybucji domyślną lokalizacją katalogu dla tego pliku jest /var/lib/pgsql/10/data/.
W poniższym fragmencie kodu edytujemy plik i dodajemy szereg parametrów.
# vim /var/lib/pgsql/10/data/postgresql.conf sqlfirewall.whitelist = 'verbose' sqlfirewall.track = 'all' sqlfirewall.track_utility = 'true' sqlfirewall.save = 'true'
Następnie ponownie ładujemy całą konfigurację.
$ psql -U postgres -d postgres Password for user postgres: psql (10.12) Type "help" for help. postgres=# SELECT pg_reload_conf(); pg_reload_conf ---------------- t (1 row)
Następnie pozwalamy procesowi na chwilę uśpić.
postgres=# SELECT pg_sleep(1); pg_sleep ---------- (1 row)
a następnie sprawdź stan białej listy w obu bazach danych. Jeśli kroki zostały wykonane, obie bazy danych powinny mieć włączoną białą listę.
postgres=# \connect pagila You are now connected to database "pagila" as user "postgres". pagila=# show sqlfirewall.whitelist; sqlfirewall.whitelist ----------------------- verbose (1 row) pagila=# \connect chinook; You are now connected to database "chinook" as user "postgres". chinook=# show sqlfirewall.whitelist; sqlfirewall.whitelist ----------------------- verbose (1 row)
Przejdźmy przez parametry, które właśnie dodaliśmy.
sqlfirewall.whitelist parametr służy do włączenia funkcji białej listy zapory. Ten parametr może mieć jedną z dwóch wartości:„verbose” lub „protect”.
W przypadku opcji pełnej, Zapora SQL wyświetli komunikat ostrzegawczy dla użytkownika, gdy spróbuje uruchomić zapytanie spoza białej listy, że nie jest do tego uprawniony. Gdy wartość jest ustawiona na chroniony, Zapora SQL wyświetli ogólny komunikat „odmowa uprawnień”. Jako najlepszą praktykę zalecamy ustawienie wartości na „chroń”, co nie daje hakerowi pojęcia, dlaczego polecenie zostało odrzucone. Ustawiliśmy ten parametr na „pełny” wyłącznie w celach demonstracyjnych.
Wartości przypisane do sqlfirewall.track i sqlfirewall.track_utility parametry zapewniają, że zapora SQL śledzi wszystkie instrukcje w celu umieszczania na białej liście.
Na koniec ustaw sqlfirewall.save parametr na „true” zapewnia, że oświadczenia z białej listy są utrwalane nawet po ponownym uruchomieniu serwera.
Uruchamianie zapory SQL
Uruchomienie Zapory SQL wymaga wywołania szeregu funkcji, które są dostarczane z rozszerzeniem.
Krok 1:Zrozumienie funkcji zapory SQL
Rozszerzenie SQL Firewall tworzy szereg funkcji w schemacie sqlfirewall bazy danych, w której jest zainstalowane. Większość z tych funkcji może być wykonywana tylko przez superużytkowników lub członków roli sqlfirewall_manager.
Przejdźmy szybko przez niektóre z tych funkcji.
sqlfirewall_whitelist_mode to główna funkcja, z którą będziemy pracować. Ta funkcja włącza białą listę instrukcji dla konkretnego użytkownika PostgreSQL. Przyjmuje dwa parametry:jeden to nazwa użytkownika, a drugi to tryb białej listy.
tryb_białej listy parametr może mieć trzy wartości:
- Gdy jest ustawiony na „RECORD ”, Zapora SQL zarejestruje wszystkie instrukcje wykonane przez użytkownika na jego białej liście
- Po ustawieniu na „WYKONAJ ”, Zapora SQL wymusi białą listę. Każde stwierdzenie nieuwzględnione na białej liście spowoduje błąd
- Wartość „OFF ” wyłącza funkcję białej listy dla użytkownika, a użytkownik w ogóle nie będzie mógł wykonywać żadnych zapytań
Jeśli chcesz usunąć zapytania z białej listy dla użytkownika, uruchom sqlfirewall_whitelist_delete funkcja zamiast. Ta funkcja przyjmuje jeden parametr:nazwę użytkownika. Po uruchomieniu funkcja sqlfirewall_whitelist_delete usuwa wszystkie instrukcje z białej listy dla użytkownika.
sqlfirewall_whitelist_delete_entry Funkcja służy do usuwania poszczególnych identyfikatorów zapytań z białej listy użytkownika. Może to być przydatne, gdy masz zbyt wiele dozwolonych zapytań dla użytkownika i chcesz je dostroić. Funkcja przyjmuje dwa parametry:nazwę użytkownika i identyfikator zapytania. Identyfikator zapytania, które chcesz wykluczyć z białej listy, możesz znaleźć w widoku sqlfirewall.
sqlfirewall_whitelist_users funkcja nie przyjmuje żadnego parametru. Zwraca listę użytkowników, którzy mają włączoną białą listę na swoim koncie.
Możesz wyeksportować białą listę dla użytkownika za pomocą sqlfirewall_whitelist_export funkcjonować. Ta funkcja przyjmuje dwa parametry:nazwę użytkownika i nazwę pliku, do którego eksportuje wyciągi użytkownika z białej listy. Plik musi znajdować się w lokalizacji, w której proces serwera PostgreSQL ma dostęp do zapisu.
Podobnie jak w przypadku funkcji sqlfirewall_whitelist_export, funkcja sqlfirewall_whitelist_import służy do importowania wyeksportowanego pliku białej listy dla użytkownika do innej instancji PostgreSQL dla tego użytkownika. Ta funkcja wymaga również dwóch parametrów, nazwy użytkownika i pliku do zaimportowania. Plik musi znajdować się w lokalizacji, z której proces serwera PostgreSQL może go odczytać.
Ponadto docelowa baza danych musi być binarną kopią źródłowej bazy danych – co oznacza, że docelowa musi być częścią replikacji strumieniowej lub instancji PostgreSQL utworzonej ze źródła za pomocą polecenia pg_basebackup. Bazy danych utworzone z logicznego zrzutu źródłowej bazy danych nie mogą importować pliku białej listy – w takich przypadkach biała lista musi być skonfigurowana ręcznie.
Krok 2:włączanie białej listy dla użytkowników
Teraz, gdy mamy kilka pomysłów na funkcje zapory SQL, zacznijmy proces umieszczania na białej liście zarówno human_user, jak i app_user w bazach danych pagila i chinook.
W poniższym fragmencie kodu uruchamiamy następujące polecenia jako superużytkownik postgres.
postgres=# \connect pagila
You are now connected to database "pagila" as user "postgres".
pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'RECORD');
sqlfirewall_whitelist_mode
----------------------------
t
(1 row)
pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'RECORD');\
sqlfirewall_whitelist_mode
----------------------------
t
(1 row)
pagila=# \connect chinook
You are now connected to database "chinook" as user "postgres".
chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'RECORD');
sqlfirewall_whitelist_mode
----------------------------
t
(1 row)
chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'RECORD');
sqlfirewall_whitelist_mode
----------------------------
t
(1 row) Możemy również potwierdzić, uruchamiając funkcję sqlfirewall_whitelist_users().
$ psql -U postgres -d pagila -c "SELECT sqlfirewall.sqlfirewall_whitelist_users();" Password for user postgres: sqlfirewall_whitelist_users ----------------------------- (17479,human_user,RECORD) (17480,app_user,RECORD) (2 rows) $ psql -U postgres -d chinook -c "SELECT sqlfirewall.sqlfirewall_whitelist_users();" Password for user postgres: sqlfirewall_whitelist_users ----------------------------- (17479,human_user,RECORD) (17480,app_user,RECORD) (2 rows)
Krok 3:Uruchamianie zadania
Po włączeniu białej listy i nagrywaniu przełączamy się na konto app_user i uruchamiamy kilka zapytań, jak pokazano poniżej. Zwróć uwagę, jak app_user wybiera różne „pola identyfikatora” (customer_id, staff_id, EmployeeID itp.) z różnych tabel.
postgres=# \c - app_user Password for user app_user: You are now connected to database "postgres" as user "app_user". postgres=> \connect pagila You are now connected to database "pagila" as user "app_user". pagila=> SELECT customer_id, first_name, last_name, email FROM public.customer; ... pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment; ... pagila=> SELECT staff_id, first_name, last_name, email FROM public.staff; ... pagila=> \connect chinook; You are now connected to database "chinook" as user "app_user". chinook=> SELECT "CustomerId", "FirstName", "LastName", "Phone" FROM public."Customer"; ... chinook=> SELECT "EmployeeId", "FirstName", "LastName", "Phone", "Email" FROM public."Employee"; ...
Następnie przełączamy się na konto human_user i uruchamiamy kilka prostych zapytań w niektórych tabelach, do których miał dostęp app_user.
postgres=# \c - human_user Password for user human_user: You are now connected to database "postgres" as user "human_user". postgres=> \connect pagila; You are now connected to database "pagila" as user "human_user". pagila=> SELECT payment_date, amount FROM public.payment; ... pagila=> SELECT first_name, last_name, email FROM public.customer; ... pagila=> \connect chinook; You are now connected to database "chinook" as user "human_user". chinook=> SELECT "FirstName", "LastName", "Phone", "Email" FROM public."Employee"; ...
Jeśli wysyłamy zapytanie do widoku sqlfirewall z dowolnej bazy danych jako użytkownik postgres, możemy zobaczyć zapytania, które zostały umieszczone na białej liście dla każdego użytkownika.
Krok 4:Egzekwowanie białej listy
Po przechwyceniu przykładowego obciążenia wymuszamy białą listę dla obu kont użytkowników w obu bazach danych, uruchamiając następujące polecenia. Polecenia muszą być uruchamiane przez administratora; w tym przypadku uruchamiamy je jako postgres użytkownika.
postgres=# \connect pagila;
You are now connected to database "pagila" as user "postgres".
pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'ENFORCE');
sqlfirewall_whitelist_mode
----------------------------
t
(1 row)
pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'ENFORCE');
sqlfirewall_whitelist_mode
----------------------------
t
(1 row)
pagila=# \connect chinook;
You are now connected to database "chinook" as user "postgres".
chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'ENFORCE');
sqlfirewall_whitelist_mode
----------------------------
t
(1 row)
chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'ENFORCE');
sqlfirewall_whitelist_mode
----------------------------
t
(1 row) Krok 5:Testowanie
Aby przetestować białą listę, zalogowaliśmy się do bazy danych pagila jako human_user i próbowaliśmy uruchomić polecenia, które były uruchamiane wcześniej
chinook=# \c - human_user; Password for user human_user: You are now connected to database "chinook" as user "human_user". chinook=> \connect pagila; You are now connected to database "pagila" as user "human_user". pagila=> SELECT payment_date, amount FROM public.payment; ... pagila=> SELECT first_name, last_name, email FROM public.customer; ...
Polecenia powiodły się. Dzieje się tak, ponieważ te polecenia były wcześniej uruchamiane przez human_user i znajdowały się na białej liście.
Teraz próbujemy uruchomić następujące polecenie. Zwróć uwagę, jak human_user próbuje uruchomić zapytanie z dwoma dodatkowymi polami. To zapytanie zostało już wcześniej uruchomione przez użytkownika app_user.
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
Oświadczenie kończy się niepowodzeniem z komunikatem takim jak:
ERROR: Execution of non-whitelisted statement prohibited
Dzieje się tak, ponieważ human_user wcześniej uruchomił polecenie, aby wybrać tylko dwa pola z tej tabeli, a nie dodatkowe pola (identyfikator płatności i identyfikator klienta), do których próbuje teraz uzyskać dostęp. Zapora SQL zarejestrowała jego poprzednie zapytanie jako znane obciążenie i umieściła je na białej liście. Gdy próbuje dodać te dwa nowe pola do swojego zapytania, zapora go blokuje.
Jeśli się nad tym zastanowisz, w ten sposób haker może chcieć ukraść wartość pola ID, aby można ją było wykorzystać w klauzuli WHERE innego zapytania, aby uzyskać dalsze informacje. Korzystanie z białej listy skutecznie to blokuje.
Co się stanie, jeśli użytkownik potrzebuje tych dwóch dodatkowych pól do uzasadnionego celu? W takim przypadku tryb białej listy dla użytkownika należy ponownie zmienić z powrotem na „RECORD”, aby nowe zapytania mogły być uruchamiane, a Zapora SQL mogła umieścić je na białej liście.
Przeprowadźmy kolejny test, zanim zakończymy. Tym razem założymy, że haker włamał się na konto app_user i chce uruchomić instrukcję usunięcia dla tabeli „płatność”. Pamiętaj, że przyznaliśmy użytkownikowi uprawnienia DELETE i TRUNCATE do tabeli.
Więc logujemy się jako app_user i uruchamiamy instrukcję DELETE.
pagila=> \c - app_user Password for user app_user: You are now connected to database "pagila" as user "app_user". pagila=> DELETE FROM public.payment; ERROR: Execution of non-whitelisted statement prohibited
Wniosek
Oświadczenie zostało odrzucone, ponieważ nie znajduje się na białej liście. Nawet jeśli użytkownik ma prawo do usunięcia danych z tabeli, SQL Firewall słusznie je zablokował.
Jak widać, SQL Firewall to potężne narzędzie zabezpieczające. Posiada funkcje bezpieczeństwa, które pozwalają na użycie go w trybie pseudoprodukcyjnym. W tym trybie użytkownik testowy może zostać skonfigurowany tak, aby jego oświadczenia były umieszczane na białej liście, a następnie można testować jego funkcjonalność.
Administratorzy baz danych i administratorzy systemów muszą jednak pamiętać o kilku kwestiach:
Po pierwsze, gdy tryb białej listy użytkownika jest ustawiony na „RECORD”, zapora SQL nie uniemożliwia użytkownikowi uruchomienia żadnego zapytania. Innymi słowy, Zapora SQL musi zostać najpierw przeszkolona, zanim będzie mogła zablokować użytkownika. Dlatego ważne jest, aby zapewnić normalne uprawnienia dostępu do bazy danych również do każdego konta użytkownika. Jest to tym ważniejsze, że członkowie ról superuser i sqlfirewall_manager są zwolnieni z reguł zapory. Zapora SQL nie zastępuje istniejących zabezpieczeń bazy danych – ma je uzupełniać.
Po drugie, podczas umieszczania na białej liście poszczególnych instrukcji SELECT, INSERT, UPDATE i DELETE, Zapora SQL będzie traktować nazwy obiektów używane w tych poleceniach napisane w różnych przypadkach (wielkie, mieszane lub małe litery) jako takie same. Wszystkie inne polecenia zostaną porównane na podstawie tekstowych ciągów zapytań. Na przykład Zapora SQL będzie traktować „POCZĄTEK”, „Rozpocznij” i „Rozpocznij” jako część oddzielnych zapytań.
Po trzecie, biała lista programu SQL Firewall nie jest automatycznie replikowana do węzłów rezerwowych w środowisku replikacji. Możesz jednak wyeksportować białe listy za pomocą funkcji sqlfirewall_whitelist_export i zaimportować je na inny serwer za pomocą funkcji sqlfirewall_whitelist_import. Niestety tworzenie kopii zapasowej bazy danych lub schematu sqlfirewall i przywracanie w instancji docelowej nie zadziała. Ponadto serwer docelowy musi mieć to samo konto użytkownika, aby biała lista była przydatna.
Należy dokładnie rozważyć wszystkie możliwe typy zapytań, które użytkownik może wykonać względem bazy danych, i uruchomić białą listę w trybie „RECORD” tak długo, jak to konieczne, aby przechwycić wszystkie normalne obciążenia. Zbyt mała ilość przechwytywania może uniemożliwić kontu użytkownika uruchamianie uzasadnionych zapytań, podczas gdy zbyt długie nagrywanie może niepotrzebnie dodawać polecenia do białej listy. Może to powodować opóźnienia dla Zapory SQL podczas porównywania instrukcji w trybie wymuszania.
