I dagens verden står organisationer i stigende grad over for et hidtil uset niveau af trussel om cyberangreb mod deres informationsaktiver.
Cyberangreb kan komme i mange former. Et sådant angreb kaldes SQL-injektion . Med SQL-injektion målretter useriøse spillere mod backend-databasen i ethvert system. Normalt er disse systemer offentligt vendte. Hackere forsøger at sende tilsyneladende ufarlige og regelmæssige forespørgsler til en database – undtagen med parametre, som kan afsløre information, de ikke skal se, eller ødelægge databasen med forkerte oplysninger eller nedbryde systemet.
Cybersikkerhedsspecialister kæmper altid mod tiden for at være på forkant med det sofistikerede i disse angreb, og ligesom de fleste store krige udkæmpes det nu på alle fronter. Dette betyder, at sikkerhed skal implementeres på hvert lag af en applikations stak - inklusive databaselaget.
Erfarne DBA'er forsøger typisk at sikre databaser med foranstaltninger som rollebaseret adgangskontrol (RBAC), fødereret godkendelse, revision eller SSL. Dog bør enhver ekstra foranstaltning til at sikre databasen også overvejes.
En sådan beskyttelsesforanstaltning er en database firewall. Ligesom almindelige firewalls, filtrerer databasefirewalls trafik fra baseret på en hvidliste eller sortliste. De kan også "lære" af systemadgangsmønstre for at forstå, hvilke udsagn der kan stole på, og hvad der ikke kan. Brug af et værktøj som dette tilføjer et stærkt lag af beskyttelse mod SQL-injektion.
I denne artikel vil vi tale om SQL Firewall , en databasefirewall til beskyttelse af PostgreSQL-databaser. SQL Firewall er bygget og understøttet af 2ndQuadrant, førende inden for PostgreSQL-teknologier.
Sådan fungerer SQL Firewall
SQL Firewall kommer som en udvidelse til PostgreSQL 9.4 og nyere. Selvom det i øjeblikket understøttes op til PostgreSQL version 10, arbejdes der yderligere på at understøtte senere versioner.
Da det er en udvidelse, er SQL Firewall meget enkel at installere og konfigurere. Når den er konfigureret, kan den bruges til at hvidliste SQL-sætninger mod databaser for individuelle brugere. Whitelistingen kommer fra at "træne" udvidelsen med en applikations typiske arbejdsbyrde - som regel kommer fra gentagne kørsler af en suite af test, der dækker alle mulige scenarier. Når hvidlisten er finjusteret og afsluttet, kan den eksporteres og derefter importeres til andre PostgreSQL-instanser, der betjener lignende arbejdsbelastninger.
For eksempel, før lanceringen af en applikation, kan hver konfigureret bruger køre prøvearbejdsbelastninger i produktionskvalitet mod databasen i et kontrolleret miljø. En menneskelig brugerkonto kan få lov til kun at køre skrivebeskyttede forespørgsler, mens en applikationsbrugerkonto kan få lov til at køre både læsning og skrivning. SQL Firewall hvidlister derefter læseforespørgsler for både menneskelige og applikationsbrugerkonti og kun skriveforespørgsler for applikationsbrugerkontoen. Hvis en menneskelig bruger derefter forsøger at køre en INSERT, DELETE eller UPDATE, vil SQL Firewall derefter afvise handlingen. Efterhånden som applikationen udvikler sig, kan hvidlisten også genoptrænes med den skiftende arbejdsbyrde.
Hver blokeret erklæring logges af SQL Firewall, hvilket betyder, at driftsteams kan sende disse logfiler til deres logstyringsløsninger og blive advaret, hver gang der er en undtagelse.
Opsætning af miljøet
I denne artikel vil vi installere SQL Firewall for en enkelt-node PostgreSQL 10-instans, der kører på Red Hat Enterprise Linux 7. I skrivende stund er RHEL/CentOS 7 og PostgreSQL 10 de højest understøttede versioner. Men som før nævnt kommer der yderligere støtte.
Bemærk
[Bemærk venligst, at SQL Firewall er et kommercielt licenseret produkt, der er tilgængeligt for 24/7 supportkunder. Det er ikke tilgængeligt til download fra 2ndQuadrants offentlige websted.]
Trin 1:Installation af PostgreSQL 10
Vores testsystem er en Amazon EC2-instans, der kører Red Hat Enterprise Linux 7.2.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
Vi kører følgende kommando for at downloade RPM-repoen til 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
Dernæst installerer vi serveren og klientpakken.
# yum install postgresql10-server postgresql10 -y
Når pakkerne er installeret, kører vi kommandoen initdb for at initialisere databasen.
# /usr/pgsql-10/bin/postgresql-10-setup initdb Initializing database ... OK
Dernæst foretager vi følgende ændring af postgresql.conf-filen. Som standard er det under mappen /var/lib/pgsql/10/data/.
listen_addresses = '*'
Og tilføj derefter følgende linje til filen pg_hba.conf (igen, som standard er den under mappen /var/lib/pgsql/10/data/).
host all all <our IP address range> md5
Vi starter derefter PostgreSQL-tjenesten og aktiverer den til at starte automatisk.
# systemctl start postgresql-10.service # systemctl enable postgresql-10.service
Til sidst logger vi ind på databaseforekomsten fra psql som postgres-bruger og ændrer adgangskoden.
# su - postgres -bash-4.2$ psql psql (10.12) Type "help" for help. postgres=# \password Enter new password: Enter it again: postgres=#
Trin 2:Gendan prøvedatabaser
For at efterligne et produktionssystem har vi gendannet to eksempeldatabaser i vores PostgreSQL-server. Disse databaser er offentligt tilgængelige:
- Pagila : PostgreSQL-versionen af den populære MySQL Sakila-database
- Chinook : en database om digital mediebutik
Trin 3:Opret roller og brugere
Med de oprettede databaser opretter vi to brugerroller. Den ene hedder "human_user", den anden hedder "app_user".
Human_user-rollen repræsenterer enhver person, der får adgang til databasen fra back-end eller med et klientværktøj. App_user-rollen repræsenterer den konto, som en applikation vil bruge til at oprette forbindelse til databasen.
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>';"
Brugerrollerne får derefter tilladelse til at få adgang til chinook- og pagila-databaserne ved at køre følgende kommandoer som postgres-bruger:
$ 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;"
Trin 4:Installation af SQL Firewall
Installation af SQL Firewall er en ligetil proces. Først installerer vi pakken.
# 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%]
Derefter opdaterer vi postgresql.conf-filen ved at ændre parameteren shared_preload_libraries.
shared_preload_libraries = 'sqlfirewall'
Når det er gjort, genstarter vi PostgreSQL-tjenesten.
# systemctl restart postgresql-10.service
Når tjenesten er genstartet, logger vi på forekomsten som postgres-brugeren og tilføjer udvidelsen til begge eksempeldatabaserne.
$ 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
Billedet nedenfor viser udvidelserne installeret på begge databaser. Bemærk, hvordan der er et specielt skema kaldet "sqlfirewall" også oprettet i begge databaser. Dette skema indeholder alle databaseobjekter relateret til SQL Firewalls drift.
Vi kan også se en ny rolle ved navn "sqlfirewall_manager" oprettes automatisk. Brugere, der føjes til denne rolle, kan få adgang til funktioner og visninger i sqlfirewall-skemaet.
Trin 5:Konfiguration af SQL Firewall
En række parametre tilføjes derefter til postgresql.conf fil. For Red Hat Enterprise Linux og dets afledte distros er standard mappeplaceringen for denne fil /var/lib/pgsql/10/data/.
I det følgende kodestykke redigerer vi filen og tilføjer en række parametre.
# vim /var/lib/pgsql/10/data/postgresql.conf sqlfirewall.whitelist = 'verbose' sqlfirewall.track = 'all' sqlfirewall.track_utility = 'true' sqlfirewall.save = 'true'
Så genindlæser vi al konfiguration.
$ 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)
Dernæst lader vi processen sove i et sekund.
postgres=# SELECT pg_sleep(1); pg_sleep ---------- (1 row)
og kontroller derefter hvidlistestatus i begge databaser. Hvis trinene blev fulgt, skulle begge databaser have whitelisting aktiveret.
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)
Lad os gennemgå de parametre, vi lige har tilføjet.
sqlfirewall.whitelist parameter bruges til at aktivere firewallens hvidlistefunktionalitet. Denne parameter kan have en af to værdier:"verbose" eller "beskyt".
Med den verbose indstilling vil SQL Firewall vise en advarselsmeddelelse til brugeren, når de forsøger at køre en ikke-hvidlistet forespørgsel, som de ikke har tilladelse til at gøre det. Når værdien er indstillet til beskyttet, vil SQL Firewall vise en generisk "tilladelse nægtet"-meddelelse. Som en bedste praksis anbefaler vi at sætte værdien til "beskytte", hvilket ikke giver hackeren nogen idé om, hvorfor kommandoen afvises. Vi har sat denne parameter til "verbose" kun til demonstrationsformål.
Værdierne tildelt sqlfirewall.track og sqlfirewall.track_utility parametre sikrer, at SQL Firewall sporer alle sætninger til hvidlisteformål.
Til sidst skal du indstille sqlfirewall.save parameter til "true" sikrer, at de hvidlistede udsagn bevarer, selvom serveren genstartes.
Kører SQL Firewall
Kørsel af SQL Firewall involverer aktivering af en række funktioner, der følger med udvidelsen.
Trin 1:Forstå SQL Firewall-funktioner
SQL Firewall-udvidelsen opretter en række funktioner i sqlfirewall-skemaet for den database, hvor den er installeret. De fleste af disse funktioner kan kun udføres af superbrugere eller medlemmer af rollen sqlfirewall_manager.
Lad os hurtigt gennemgå nogle af disse funktioner.
sqlfirewall_whitelist_mode er hovedfunktionen vi skal arbejde med. Denne funktion aktiverer erklæringens hvidliste for en bestemt PostgreSQL-bruger. Det kræver to parametre:den ene er brugernavnet, den anden er whitelist_mode.
whitelist_mode parameter kan have tre værdier:
- Når den er indstillet til "OPTAG ”, vil SQL Firewall optage alle sætninger, der udføres af brugeren på brugerens hvidliste
- Når den er indstillet til "ENFORCE ”, vil SQL Firewall håndhæve hvidlisten. Enhver erklæring, der ikke er inkluderet på hvidlisten, vil forårsage en fejl
- Værdien af "OFF ” deaktiverer hvidlistefunktionalitet for brugeren, og brugeren vil slet ikke være i stand til at udføre nogen forespørgsler
Hvis du vil fjerne de hvidlistede forespørgsler for en bruger, skal du køre sqlfirewall_whitelist_delete funktion i stedet for. Denne funktion tager en enkelt parameter:brugernavnet. Når den er kørt, fjerner funktionen sqlfirewall_whitelist_delete alle hvidlistede udsagn for brugeren.
sqlfirewall_whitelist_delete_entry funktion bruges til at fjerne individuelle forespørgsels-id'er fra en brugers hvidliste. Dette kan være nyttigt, når du har for mange tilladte forespørgsler til en bruger og ønsker at finjustere den. Funktionen tager to parametre:brugernavnet og forespørgsels-id'et. Du kan finde ID'et for den forespørgsel, du vil udelukke fra hvidlisten, ved at se på sqlfirewall-visningen.
sqlfirewall_whitelist_users funktion tager ikke nogen parameter. Det returnerer en liste over brugere, der har aktiveret hvidliste for deres konto.
Du kan eksportere hvidlisten for en bruger ved hjælp af sqlfirewall_whitelist_export fungere. Denne funktion tager to parametre:brugernavnet og filnavnet, hvor den eksporterer brugerens hvidlistede udsagn. Filen skal være på et sted, hvor PostgreSQL-serverprocessen har skriveadgang til.
I lighed med funktionen sqlfirewall_whitelist_export, funktionen sqlfirewall_whitelist_import bruges til at importere en eksporteret hvidlistefil for en bruger til en anden PostgreSQL-instans for denne bruger. Denne funktion tager også to parametre, brugernavnet og filen, der skal importeres. Filen skal være på et sted, hvor PostgreSQL-serverprocessen kan læse den fra.
Måldatabasen skal også være en binær kopi af kildedatabasen - det betyder, at målet skal være en del af en streaming-replikering eller en PostgreSQL-instans oprettet fra en kilde med kommandoen pg_basebackup. Databaser oprettet fra et logisk dump af kildedatabasen kan ikke importere hvidlistefilen – i sådanne tilfælde skal hvidlisten konfigureres manuelt.
Trin 2:Aktivering af hvidlistning for brugere
Nu hvor vi har nogle ideer om SQL Firewall-funktionerne, lad os starte hvidlisteprocessen for både human_user og app_user i pagila- og chinook-databaserne.
I kodestykket nedenfor kører vi følgende kommandoer som postgres superbruger.
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) Vi kan også bekræfte ved at køre funktionen 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)
Trin 3:Kørsel af en arbejdsbyrde
Med hvidlisten aktiveret og optagelse skifter vi til app_user-kontoen og kører nogle forespørgsler som vist nedenfor. Bemærk, hvordan app_user vælger forskellige "ID-felter" (customer_id, staff_id, EmployeeID osv.) fra forskellige tabeller.
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"; ...
Dernæst skifter vi til human_user-kontoen og kører nogle simple forespørgsler på nogle af de tabeller, som app_user har adgang til.
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"; ...
Hvis vi forespørger på sqlfirewall-visningen fra en af databaserne som postgres-bruger, kan vi se de forespørgsler, der blev hvidlistet for hver bruger.
Trin 4:Håndhævelse af hvidliste
Med et eksempel på en arbejdsbelastning, der nu er fanget, håndhæver vi hvidlisten for begge brugerkonti i begge databaser ved at køre følgende kommandoer. Kommandoerne skal køres af en superbruger; i dette tilfælde kører vi disse som brugerens 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) Trin 5:Test
For at teste hvidlisten loggede vi på pagila-databasen som human_user og forsøgte at køre de kommandoer, der blev kørt før
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; ...
Kommandoerne lykkes. Dette er fordi disse kommandoer blev kørt af human_user før og blev hvidlistet.
Nu prøver vi at køre følgende kommando. Bemærk, hvordan human_user forsøger at køre en forespørgsel med to ekstra felter. Denne forespørgsel blev kørt af app_user før.
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
Udsagnet mislykkes med en meddelelse som denne:
ERROR: Execution of non-whitelisted statement prohibited
Dette sker, fordi human_user tidligere havde kørt en kommando om kun at vælge to felter fra denne tabel, ikke de ekstra felter (betalings-id og kunde-id), som han forsøger at få adgang til nu. SQL Firewall registrerede hans tidligere forespørgsel som en kendt arbejdsbelastning og hvidlistede denne forespørgsel. Da han forsøger at tilføje de to nye felter i sin forespørgsel, blokerer firewallen ham.
Hvis du tænker over det, er det sådan, en hacker måske vil stjæle en ID-feltværdi, så den kan bruges i WHERE-klausulen i en anden forespørgsel for at få yderligere information. Brug af en hvidlistemetode blokerer effektivt for det.
Så hvad sker der, hvis brugeren har brug for disse to ekstra felter til legitime formål? I et sådant tilfælde skal hvidlistetilstanden for brugeren ændres tilbage til "RECORD" igen, så de nye forespørgsler kan køre, og SQL Firewall kan hvidliste dem.
Lad os køre endnu en test, før vi afslutter. Denne gang vil vi antage, at en hacker har kompromitteret app_user-kontoen og ønsker at køre en sletteerklæring mod "betalings"-tabellen. Husk, at vi havde givet brugeren DELETE og TRUNCATE privilegier på bordet.
Så vi logger ind som app_user og kører en DELETE-sætning.
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
Konklusion
Udtalelsen afvises, fordi den ikke er hvidlistet. Selv når brugeren har ret til at slette data fra tabellen, har SQL Firewall med rette blokeret det.
Som du kan se, er SQL Firewall et kraftfuldt sikkerhedsværktøj. Den har sikkerhedsfunktioner, der gør det muligt at bruge den i en pseudo-produktionstilstand. I denne tilstand kan en testbruger konfigureres til at få sine udsagn hvidlistet, og derefter kan funktionaliteten testes.
DBA'er og systemadministratorer skal dog være opmærksomme på et par punkter:
Først og fremmest, når en brugers hvidlistetilstand er indstillet til "RECORD", forhindrer SQL Firewall ikke brugeren i at køre nogen forespørgsel. Med andre ord skal SQL Firewall først trænes, før den kan blokere en bruger. Derfor er det vigtigt at sikre, at normale databaseadgangsrettigheder også anvendes på enhver brugerkonto. Dette er så meget desto vigtigere, fordi medlemmer af superbruger- og sqlfirewall_manager-rollerne er undtaget fra firewall-reglerne. SQL Firewall er ikke en erstatning for eksisterende databasesikkerhed – den er der for at supplere den.
For det andet, når du hvidlister individuelle SELECT-, INSERT-, UPDATE- og DELETE-sætninger, vil SQL Firewall behandle objektnavne brugt i disse kommandoer skrevet i forskellige bogstaver (store bogstaver, blandede bogstaver eller små bogstaver) som ens. Alle andre kommandoer vil blive sammenlignet på basis af de tekstuelle forespørgselsstrenge. Så for eksempel vil SQL Firewall behandle "BEGIN" og "begynd" og "Begynd" som en del af separate forespørgsler.
For det tredje replikerer SQL Firewalls hvidliste ikke automatisk over til standby-noder i et replikeringsmiljø. Du kan dog eksportere hvidlister ved hjælp af funktionen sqlfirewall_whitelist_export og importere den til en anden server ved hjælp af funktionen sqlfirewall_whitelist_import. Desværre vil sikkerhedskopiering af databasen eller sqlfirewall-skemaet og gendannelse i målforekomsten ikke fungere. Målserveren skal også have den samme brugerkonto til stede, for at hvidlisten er nyttig.
Der skal være omhyggelig overvejelse af alle mulige typer forespørgsler, som en bruger kan udføre mod en database og køre hvidlisten i "RECORD"-tilstand så længe det er nødvendigt for at fange alle normale arbejdsbelastninger. For lidt optagelse kan begrænse en brugerkonto i at køre legitime forespørgsler, hvorimod optagelse i for lang tid kan unødigt tilføje kommandoer til hvidlisten. Dette kan forårsage forsinkelser for SQL Firewall, når den sammenligner sætninger i håndhævelsestilstand.