V dnešním světě čelí organizace stále více bezprecedentní úrovni hrozby kybernetických útoků proti jejich informačním aktivům.
Kybernetické útoky mohou mít mnoho podob. Jeden takový útok se nazývá SQL injection . Pomocí SQL injection se nepoctiví hráči zaměřují na backendovou databázi jakéhokoli systému. Obvykle jsou tyto systémy orientovány na veřejnost. Hackeři se pokoušejí posílat do databáze zdánlivě neškodné a pravidelné dotazy – kromě parametrů, které mohou odhalit informace, které nemají vidět, nebo poškodit databázi nesprávnými informacemi nebo zhroucení systému.
Specialisté na kybernetickou bezpečnost vždy závodí s časem, aby zůstali o krok před sofistikovaností těchto útoků, a jako většina velkých válek se nyní bojuje na všech frontách. To znamená, že zabezpečení musí být implementováno na každé vrstvě zásobníku aplikace – včetně databázové vrstvy.
Zkušení správci databází se obvykle snaží zabezpečit databáze pomocí opatření, jako je řízení přístupu na základě rolí (RBAC), federované ověřování, auditování nebo SSL. Je však třeba zvážit i jakékoli další opatření k zabezpečení databáze.
Jedním z takových ochranných opatření je databázový firewall. Stejně jako běžné firewally, databázové firewally filtrují provoz na základě whitelistu nebo blacklistu. Mohou se také „učit“ ze vzorců přístupu k systému, aby pochopili, kterým prohlášením lze důvěřovat a kterým ne. Použití nástroje, jako je tento, přidává silnou vrstvu ochrany proti SQL injection.
V tomto článku budeme hovořit o bráně SQL Firewall , databázový firewall pro ochranu PostgreSQL databází. SQL Firewall je postaven a podporován společností 2ndQuadrant, lídrem v technologiích PostgreSQL.
Jak SQL Firewall funguje
SQL Firewall přichází jako rozšíření PostgreSQL 9.4 a vyšší. Přestože je v současné době podporována až do verze PostgreSQL 10, pokračují další práce na podpoře novějších verzí.
Protože se jedná o rozšíření, SQL Firewall se velmi snadno instaluje a konfiguruje. Jakmile je nakonfigurován, lze jej použít k whitelistování příkazů SQL proti databázím pro jednotlivé uživatele. Whitelisting pochází z „trénování“ rozšíření s typickou zátěží aplikace – obvykle pocházející z opakovaných běhů sady testů pokrývajících všechny možné scénáře. Jakmile je whitelist doladěn a finalizován, lze jej exportovat a poté importovat do jiných instancí PostgreSQL, které obsluhují podobnou zátěž.
Například před spuštěním aplikace může každý nakonfigurovaný uživatel spouštět ukázkové úlohy produkční kvality proti databázi v kontrolovaném prostředí. Lidskému uživatelskému účtu může být povoleno spouštět dotazy pouze pro čtení, zatímco uživatelskému účtu aplikace může být povoleno spouštět čtení i zápis. SQL Firewall poté zařadí na seznam povolených dotazů na čtení pro lidské účty i uživatelské účty aplikace a dotazy na zápis pouze pro uživatelský účet aplikace. Pokud se pak lidský uživatel pokusí spustit INSERT, DELETE nebo UPDATE, SQL Firewall pak operaci odmítne. Jak se aplikace vyvíjí, whitelist lze také přeškolit s měnícím se pracovním zatížením.
Každý zablokovaný příkaz je protokolován bránou SQL Firewall, což znamená, že provozní týmy mohou tyto protokoly odesílat do svých řešení pro správu protokolů a dostávat upozornění pokaždé, když dojde k výjimce.
Nastavení prostředí
V tomto článku nainstalujeme SQL Firewall pro instanci PostgreSQL 10 s jedním uzlem běžící na Red Hat Enterprise Linux 7. V době psaní tohoto článku jsou nejvyšší podporované verze RHEL/CentOS 7 a PostgreSQL 10. Nicméně, jak již bylo zmíněno, další podpora se chystá.
Poznámka
[Upozorňujeme, že SQL Firewall je komerčně licencovaný produkt dostupný zákazníkům s nepřetržitou podporou. Není k dispozici ke stažení z veřejného webu 2ndQuadrant.]
Krok 1:Instalace PostgreSQL 10
Náš testovací systém je instance Amazon EC2 se systémem Red Hat Enterprise Linux 7.2.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
Spustíme následující příkaz ke stažení repozitáře RPM pro 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
Dále nainstalujeme server a balíček klienta.
# yum install postgresql10-server postgresql10 -y
Jakmile jsou balíčky úspěšně nainstalovány, spustíme příkaz initdb pro inicializaci databáze.
# /usr/pgsql-10/bin/postgresql-10-setup initdb Initializing database ... OK
Dále provedeme následující změnu v souboru postgresql.conf. Ve výchozím nastavení se nachází v adresáři /var/lib/pgsql/10/data/.
listen_addresses = '*'
A pak přidejte následující řádek do souboru pg_hba.conf (opět je ve výchozím nastavení v adresáři /var/lib/pgsql/10/data/).
host all all <our IP address range> md5
Poté spustíme službu PostgreSQL a povolíme její automatické spouštění.
# systemctl start postgresql-10.service # systemctl enable postgresql-10.service
Nakonec se přihlásíme do instance databáze z psql jako uživatel postgres a změníme heslo.
# su - postgres -bash-4.2$ psql psql (10.12) Type "help" for help. postgres=# \password Enter new password: Enter it again: postgres=#
Krok 2:Obnovení ukázkových databází
Pro emulaci produkčního systému jsme obnovili dvě vzorové databáze na našem PostgreSQL serveru. Tyto databáze jsou veřejně dostupné:
- Pagila : verze PostgreSQL populární databáze MySQL Sakila
- Chinook : databáze obchodu s digitálními médii
Krok 3:Vytvořte role a uživatele
S vytvořenými databázemi vytvoříme dvě uživatelské role. Jeden se nazývá „human_user“, druhý se nazývá „app_user“.
Role human_user představuje jakoukoli osobu přistupující k databázi z back-endu nebo pomocí klientského nástroje. Role app_user představuje účet, který aplikace použije k připojení k databázi.
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>';"
Uživatelským rolím je poté uděleno oprávnění k přístupu k chinooku a databázím pagila spuštěním následujících příkazů jako uživatel 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:Instalace brány SQL Firewall
Instalace SQL Firewallu je jednoduchý proces. Nejprve nainstalujeme balíček.
# 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%]
Poté aktualizujeme soubor postgresql.conf změnou parametru shared_preload_libraries.
shared_preload_libraries = 'sqlfirewall'
Po dokončení restartujeme službu PostgreSQL.
# systemctl restart postgresql-10.service
Jakmile je služba restartována, přihlásíme se do instance jako uživatel postgres a přidáme rozšíření do obou ukázkových databází.
$ 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
Obrázek níže ukazuje rozšíření nainstalovaná v obou databázích. Všimněte si, že v obou databázích je také vytvořeno speciální schéma zvané „sqlfirewall“. Toto schéma obsahuje všechny databázové objekty související s operací SQL Firewallu.
Můžeme také vidět, že se automaticky vytvoří nová role s názvem „sqlfirewall_manager“. Uživatelé, kteří jsou přidáni do této role, mají přístup k funkcím a pohledům ve schématu sqlfirewall.
Krok 5:Konfigurace brány SQL Firewall
Do postgresql.conf je poté přidána řada parametrů soubor. Pro Red Hat Enterprise Linux a jeho odvozené distribuce je výchozí umístění adresáře pro tento soubor /var/lib/pgsql/10/data/.
V následujícím fragmentu kódu upravujeme soubor a přidáváme řadu parametrů.
# vim /var/lib/pgsql/10/data/postgresql.conf sqlfirewall.whitelist = 'verbose' sqlfirewall.track = 'all' sqlfirewall.track_utility = 'true' sqlfirewall.save = 'true'
Poté znovu načteme veškerou konfiguraci.
$ 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)
Dále necháme proces na sekundu spát.
postgres=# SELECT pg_sleep(1); pg_sleep ---------- (1 row)
a poté zkontrolujte stav whitelistingu v obou databázích. Pokud byly dodrženy tyto kroky, měly by mít obě databáze povolenou bílou listinu.
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)
Pojďme si projít parametry, které jsme právě přidali.
sqlfirewall.whitelist Parametr se používá k povolení funkce whitelistingu firewallu. Tento parametr může mít jednu ze dvou hodnot:„verbose“ nebo „protect“.
S možností verbose, SQL Firewall zobrazí varovnou zprávu uživateli, když se pokusí spustit dotaz, který není na seznamu povolených, že to nemá povoleno. Když je hodnota nastavena na protected, SQL Firewall zobrazí obecnou zprávu „oprávnění odepřeno“. Jako osvědčený postup doporučujeme nastavit hodnotu na „protect“, což hackerovi nedává žádnou představu, proč je příkaz odmítnut. Tento parametr jsme nastavili na „verbose“ pouze pro účely demonstrace.
Hodnoty přiřazené k sqlfirewall.track a sqlfirewall.track_utility parametry zajišťují, že brána SQL Firewall sleduje všechny příkazy pro účely zařazení na seznam povolených.
Nakonec nastavte sqlfirewall.save parametr na „true“ zajišťuje, že příkazy na seznamu povolených zůstanou zachovány, i když je server restartován.
Spuštění brány SQL Firewall
Spuštění brány SQL Firewall zahrnuje vyvolání řady funkcí, které jsou součástí rozšíření.
Krok 1:Pochopení funkcí brány firewall SQL
Rozšíření SQL Firewall vytváří řadu funkcí ve schématu sqlfirewall databáze, kde je nainstalováno. Většinu těchto funkcí mohou provádět pouze superuživatelé nebo členové role sqlfirewall_manager.
Pojďme si rychle projít některé z těchto funkcí.
sqlfirewall_whitelist_mode je hlavní funkcí, se kterou budeme pracovat. Tato funkce umožňuje whitelisting příkazů pro konkrétního uživatele PostgreSQL. Vyžaduje dva parametry:jeden je uživatelské jméno, druhý je whitelist_mode.
režim whitelist_mode parametr může mít tři hodnoty:
- Když je nastaveno na „ZÁZNAM “, SQL Firewall zaznamená všechny příkazy provedené uživatelem do seznamu povolených uživatelů
- Při nastavení na „ENFORCE “, SQL Firewall vynutí whitelist. Jakýkoli příkaz, který není uveden na seznamu povolených, způsobí chybu
- Hodnota „OFF ” vypne funkci whitelisting pro uživatele a uživatel nebude moci provádět žádné dotazy.
Pokud chcete odstranit dotazy na seznamu povolených pro uživatele, spusťte sqlfirewall_whitelist_delete místo toho funkci. Tato funkce má jediný parametr:uživatelské jméno. Po spuštění funkce sqlfirewall_whitelist_delete odstraní pro uživatele všechny příkazy z bílé listiny.
sqlfirewall_whitelist_delete_entry Funkce se používá k odstranění jednotlivých ID dotazů z bílé listiny uživatele. To může být užitečné, když máte pro uživatele příliš mnoho povolených dotazů a chcete to doladit. Funkce přebírá dva parametry:uživatelské jméno a ID dotazu. ID dotazu, který chcete vyloučit ze seznamu povolených, najdete v zobrazení sqlfirewall.
sqlfirewall_whitelist_users funkce nepřebírá žádný parametr. Vrátí seznam uživatelů, kteří mají pro svůj účet povolenou bílou listinu.
Whitelist pro uživatele můžete exportovat pomocí sqlfirewall_whitelist_export funkce. Tato funkce má dva parametry:uživatelské jméno a název souboru, do kterého exportuje výpisy uživatele na seznamu povolených. Soubor musí být v umístění, kam má proces serveru PostgreSQL přístup pro zápis.
Podobně jako u funkce sqlfirewall_whitelist_export, funkce sqlfirewall_whitelist_import se používá k importu exportovaného souboru whitelistu pro uživatele do jiné instance PostgreSQL pro tohoto uživatele. Tato funkce také přebírá dva parametry, uživatelské jméno a soubor, který má být importován. Soubor musí být v umístění, odkud jej může proces serveru PostgreSQL číst.
Cílová databáze musí být také binární kopií zdrojové databáze – to znamená, že cíl musí být součástí streamované replikace nebo instance PostgreSQL vytvořené ze zdroje pomocí příkazu pg_basebackup. Databáze vytvořené z logického výpisu zdrojové databáze nemohou importovat soubor whitelistu – v takových případech je nutné whitelisting nakonfigurovat ručně.
Krok 2:Povolení přidávání na seznam povolených uživatelů
Nyní, když máme nějaké představy o funkcích SQL Firewallu, začněme proces přidávání na seznam povolených pro uživatele human_user i app_user v databázích pagila a chinook.
Ve fragmentu kódu níže spouštíme následující příkazy jako superuživatel 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) Můžeme to také potvrdit spuštěním funkce 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:Spuštění úlohy
S povoleným seznamem povolených a záznamem se přepneme na účet app_user a spustíme některé dotazy, jak je uvedeno níže. Všimněte si, jak uživatel app_user vybírá různá pole „ID“ (customer_id, staff_id, EmployeeID atd.) z různých tabulek.
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"; ...
Dále přepneme na účet human_user a spustíme několik jednoduchých dotazů na některé tabulky, ke kterým app_user přistupoval.
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"; ...
Pokud se dotazujeme na zobrazení sqlfirewall z jakékoli databáze jako uživatel postgres, můžeme vidět dotazy, které byly pro každého uživatele přidány na bílou listinu.
Krok 4:Vynucení bílé listiny
Po zachycené ukázkové zátěži vynucujeme whitelist pro oba uživatelské účty v obou databázích spuštěním následujících příkazů. Příkazy musí spouštět superuživatel; v tomto případě je spouštíme jako uživatel postgres.
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:Testování
Abychom otestovali whitelisting, přihlásili jsme se do databáze pagila jako human_user a pokusili jsme se spustit příkazy, které byly spuštěny dříve
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; ...
Příkazy jsou úspěšné. Je to proto, že tyto příkazy byly dříve spouštěny uživatelem human_user a byly zařazeny na bílou listinu.
Nyní se pokusíme spustit následující příkaz. Všimněte si, jak se human_user pokouší spustit dotaz se dvěma poli navíc. Tento dotaz již dříve spustil uživatel app_user.
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
Příkaz selže se zprávou jako je tato:
ERROR: Execution of non-whitelisted statement prohibited
K tomu dochází, protože human_user dříve spustil příkaz k výběru pouze dvou polí z této tabulky, nikoli dalších polí (ID platby a ID zákazníka), ke kterým se nyní pokouší získat přístup. SQL Firewall zaznamenal jeho předchozí dotaz jako známé pracovní zatížení a přidal tento dotaz na bílou listinu. Když se pokouší přidat tato dvě nová pole do svého dotazu, firewall ho blokuje.
Pokud o tom přemýšlíte, hacker může chtít ukrást hodnotu pole ID, aby ji bylo možné použít v klauzuli WHERE jiného dotazu k získání dalších informací. Použití metody whitelisting to účinně blokuje.
Co se tedy stane, pokud uživatel potřebuje tato dvě další pole pro legitimní účely? V takovém případě je třeba režim whitelistu pro uživatele znovu změnit zpět na „RECORD“, aby bylo možné spustit nové dotazy a SQL Firewall je mohl přidat na seznam povolených.
Udělejme další test, než skončíme. Tentokrát budeme předpokládat, že hacker prolomil účet app_user a chce spustit příkaz delete proti tabulce „platba“. Pamatujte, že jsme uživateli udělili oprávnění DELETE a TRUNCATE v tabulce.
Přihlásíme se tedy jako app_user a spustíme příkaz 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
Závěr
Prohlášení je zamítnuto, protože není na seznamu povolených. I když má uživatel právo smazat data z tabulky, SQL Firewall to správně zablokoval.
Jak můžete vidět, SQL Firewall je výkonný bezpečnostní nástroj. Má bezpečnostní prvky, které umožňují jeho použití v pseudoprodukčním režimu. V tomto režimu může být testovací uživatel nakonfigurován tak, aby měl své příkazy na seznamu povolených a poté lze otestovat funkčnost.
DBA a správci systému si však musí být vědomi několika bodů:
Za prvé, když je režim bílé listiny uživatele nastaven na „ZÁZNAM“, SQL Firewall nezabrání uživateli spouštět jakýkoli dotaz. Jinými slovy, SQL Firewall musí být nejprve vyškolen, než může zablokovat uživatele. Proto je důležité zajistit, aby se na jakýkoli uživatelský účet vztahovala i normální přístupová práva k databázi. To je o to důležitější, že členové rolí superuser a sqlfirewall_manager jsou vyňati z pravidel brány firewall. SQL Firewall nenahrazuje stávající zabezpečení databáze – je tu, aby jej doplnil.
Za druhé, při zařazování jednotlivých příkazů SELECT, INSERT, UPDATE a DELETE na seznam povolených bude SQL Firewall považovat názvy objektů použité v těchto příkazech zapsané v různých případech (velká písmena, smíšená písmena nebo malá písmena) za stejné. Všechny ostatní příkazy budou porovnány na základě textových dotazových řetězců. Takže například SQL Firewall bude považovat „BEGIN“ a „begin“ a „Begin“ za součást samostatných dotazů.
Za třetí, whitelist SQL Firewallu se automaticky nereplikuje napříč do pohotovostních uzlů v prostředí replikace. Whitelisty však můžete exportovat pomocí funkce sqlfirewall_whitelist_export a importovat je na jiný server pomocí funkce sqlfirewall_whitelist_import. Zálohování databáze nebo schématu sqlfirewall a obnovení v cílové instanci bohužel nebude fungovat. Aby byl seznam povolených užitečný, musí mít cílový server stejný uživatelský účet.
Je třeba pečlivě zvážit všechny možné typy dotazů, které může uživatel provést proti databázi, a spouštět whitelisting v režimu „ZÁZNAM“ tak dlouho, jak je nutné k zachycení všech běžných úloh. Příliš malé zachycení může omezit uživatelský účet ve spouštění legitimních dotazů, zatímco příliš dlouhé nahrávání může zbytečně přidávat příkazy do seznamu povolených. To může způsobit zpoždění brány SQL Firewall při porovnávání příkazů v režimu vynucení.