I dagens värld möter organisationer alltmer en oöverträffad nivå av hot om cyberattacker mot deras informationstillgångar.
Cyberattacker kan komma i många former. En sådan attack kallas SQL-injektion . Med SQL-injektion riktar sig oseriösa spelare mot backend-databasen i vilket system som helst. Vanligtvis är dessa system riktade till allmänheten. Hackare försöker skicka till synes ofarliga och regelbundna frågor till en databas – förutom med parametrar som kan avslöja information som de inte ska se, eller korrumpera databasen med felaktig information eller krascha systemet.
Cybersäkerhetsspecialister tävlar alltid mot tiden för att ligga steget före det sofistikerade i dessa attacker, och som de flesta stora krig utkämpas det nu på alla fronter. Detta innebär att säkerhet måste implementeras på varje lager i en applikations stack – inklusive databaslagret.
Erfarna DBA:er försöker vanligtvis säkra databaser med åtgärder som rollbaserad åtkomstkontroll (RBAC), federerad autentisering, revision eller SSL. Men eventuella extra åtgärder för att säkra databasen bör också övervägas.
En sådan skyddsåtgärd är en databasbrandvägg. Precis som vanliga brandväggar filtrerar databasbrandväggar bort trafik baserat på en vitlista eller svartlista. De kan också "lära sig" av systemåtkomstmönster för att förstå vilka uttalanden som kan litas på och vad som inte kan. Att använda ett verktyg som detta lägger till ett starkt lager av skydd mot SQL-injektion.
I den här artikeln kommer vi att prata om SQL-brandvägg , en databasbrandvägg för att skydda PostgreSQL-databaser. SQL-brandväggen är byggd och stöds av 2ndQuadrant, en ledare inom PostgreSQL-teknik.
Så fungerar SQL-brandväggen
SQL Firewall kommer som en tillägg till PostgreSQL 9.4 och senare. Även om det för närvarande stöds upp till PostgreSQL version 10, pågår ytterligare arbete för att stödja senare versioner.
Eftersom det är ett tillägg är SQL Firewall mycket enkel att installera och konfigurera. När den väl har konfigurerats kan den användas för att vitlista SQL-satser mot databaser för enskilda användare. Vitlistan kommer från att "träna" tillägget med en applikations typiska arbetsbelastning - vanligtvis från upprepade körningar av en uppsättning tester som täcker alla möjliga scenarier. När vitlistan har finjusterats och slutförts kan den exporteras och sedan importeras till andra PostgreSQL-instanser med liknande arbetsbelastningar.
Till exempel, före lanseringen av en applikation, kan varje konfigurerad användare köra provarbetsbelastningar av produktionskvalitet mot databasen i en kontrollerad miljö. Ett mänskligt användarkonto kan tillåtas att köra endast skrivskyddade frågor medan ett applikationsanvändarkonto kan tillåtas att köra både läsning och skrivning. SQL Firewall vitlistar sedan läsfrågor för både mänskliga och applikationsanvändarkonton och skrivfrågor endast för applikationens användarkonto. Om en mänsklig användare sedan försöker köra en INSERT, DELETE eller UPDATE, kommer SQL-brandväggen att neka åtgärden. Allt eftersom applikationen utvecklas kan vitlistan också omskolas med den förändrade arbetsbelastningen.
Varje blockerad uttalande loggas av SQL-brandväggen, vilket innebär att driftteam kan skicka dessa loggar till sina logghanteringslösningar och få en varning varje gång det finns ett undantag.
Konfigurera miljön
I den här artikeln kommer vi att installera SQL Firewall för en PostgreSQL 10-instans med en nod som körs på Red Hat Enterprise Linux 7. I skrivande stund är RHEL/CentOS 7 och PostgreSQL 10 de versioner som stöds högst. Men som tidigare nämnts kommer ytterligare stöd.
Obs
[Observera att SQL Firewall är en kommersiellt licensierad produkt tillgänglig för 24/7 supportkunder. Den är inte tillgänglig för nedladdning från 2ndQuadrants offentliga webbplats.]
Steg 1:Installera PostgreSQL 10
Vårt testsystem är en Amazon EC2-instans som kör Red Hat Enterprise Linux 7.2.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
Vi kör följande kommando för att ladda ner RPM-repo för 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ärefter installerar vi servern och klientpaketet.
# yum install postgresql10-server postgresql10 -y
När paketen väl har installerats kör vi kommandot initdb för att initiera databasen.
# /usr/pgsql-10/bin/postgresql-10-setup initdb Initializing database ... OK
Därefter gör vi följande ändring i postgresql.conf-filen. Som standard finns den under katalogen /var/lib/pgsql/10/data/.
listen_addresses = '*'
Och lägg sedan till följande rad i filen pg_hba.conf (återigen, som standard, är den under katalogen /var/lib/pgsql/10/data/).
host all all <our IP address range> md5
Vi startar sedan PostgreSQL-tjänsten och aktiverar den att starta automatiskt.
# systemctl start postgresql-10.service # systemctl enable postgresql-10.service
Slutligen loggar vi in i databasinstansen från psql som postgres-användare och ändrar lösenordet.
# su - postgres -bash-4.2$ psql psql (10.12) Type "help" for help. postgres=# \password Enter new password: Enter it again: postgres=#
Steg 2:Återställ exempeldatabaser
För att efterlikna ett produktionssystem har vi återställt två exempeldatabaser i vår PostgreSQL-server. Dessa databaser är allmänt tillgängliga:
- Pagila : PostgreSQL-versionen av den populära MySQL Sakila-databasen
- Chinook : en databas om digital mediabutik
Steg 3:Skapa roller och användare
Med de skapade databaserna skapar vi två användarroller. Den ena heter "human_user", den andra heter "app_user".
Rollen human_user representerar varje person som kommer åt databasen från back-end eller med ett klientverktyg. Rollen app_user representerar kontot som ett program kommer att använda för att ansluta till 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>';"
Användarrollerna ges sedan behörighet att komma åt databaserna chinook och pagila genom att köra följande kommandon som postgres-användare:
$ 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;"
Steg 4:Installera SQL-brandväggen
Att installera SQL Firewall är en enkel process. Först installerar vi paketet.
# 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%]
Sedan uppdaterar vi postgresql.conf-filen genom att ändra parametern shared_preload_libraries.
shared_preload_libraries = 'sqlfirewall'
När vi är klara startar vi om PostgreSQL-tjänsten.
# systemctl restart postgresql-10.service
När tjänsten har startat om loggar vi in på instansen som postgres-användare och lägger till tillägget till båda exempeldatabaserna.
$ 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
Bilden nedan visar tilläggen installerade på båda databaserna. Notera hur det finns ett speciellt schema som kallas "sqlfirewall" som också skapas i båda databaserna. Det här schemat innehåller alla databasobjekt relaterade till SQL-brandväggens drift.
Vi kan också se att en ny roll som heter "sqlfirewall_manager" skapas automatiskt. Användare som läggs till i den här rollen kan komma åt funktioner och vyer i sqlfirewall-schemat.
Steg 5:Konfigurera SQL-brandväggen
Ett antal parametrar läggs sedan till i postgresql.conf fil. För Red Hat Enterprise Linux och dess derivatdistros är standardkatalogplatsen för denna fil /var/lib/pgsql/10/data/.
I följande kodavsnitt redigerar vi filen och lägger till ett antal parametrar.
# vim /var/lib/pgsql/10/data/postgresql.conf sqlfirewall.whitelist = 'verbose' sqlfirewall.track = 'all' sqlfirewall.track_utility = 'true' sqlfirewall.save = 'true'
Sedan laddar vi om all 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)
Därefter låter vi processen vila en sekund.
postgres=# SELECT pg_sleep(1); pg_sleep ---------- (1 row)
och kontrollera sedan vitlistans status i båda databaserna. Om stegen följs, bör vitlistning aktiveras i båda databaserna.
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)
Låt oss gå igenom parametrarna vi just lade till.
sqlfirewall.whitelist parametern används för att aktivera brandväggens vitlistningsfunktion. Denna parameter kan ha något av två värden:"verbose" eller "protect".
Med det utförliga alternativet kommer SQL Firewall att visa ett varningsmeddelande till användaren när de försöker köra en icke-vitlistad fråga som de inte har tillåtelse att göra. När värdet är inställt på skyddat kommer SQL-brandväggen att visa ett allmänt "behörighet nekad"-meddelande. Som en bästa praxis rekommenderar vi att sätta värdet på "skydda", vilket inte ger hackaren någon aning om varför kommandot avvisas. Vi har ställt in den här parametern på "verbose" endast för demonstrationsändamål.
Värdena som tilldelats sqlfirewall.track och sqlfirewall.track_utility parametrar säkerställer att SQL-brandväggen spårar alla satser för vitlistningsändamål.
Slutligen, ställ in sqlfirewall.save parametern till "true" säkerställer att de vitlistade uttalandena kvarstår även om servern startas om.
Kör SQL-brandväggen
Att köra SQL Firewall innebär att man anropar ett antal funktioner som följer med tillägget.
Steg 1:Förstå SQL-brandväggsfunktioner
SQL Firewall-tillägget skapar ett antal funktioner i sqlfirewall-schemat för databasen där den är installerad. De flesta av dessa funktioner kan endast köras av superanvändare eller medlemmar av rollen sqlfirewall_manager.
Låt oss snabbt gå igenom några av dessa funktioner.
sqlfirewall_whitelist_mode är huvudfunktionen vi kommer att arbeta med. Den här funktionen aktiverar satsvitlistan för en viss PostgreSQL-användare. Det krävs två parametrar:en är användarnamnet, den andra är whitelist_mode.
whitelist_mode parameter kan ha tre värden:
- När den är inställd på RECORD ”, kommer SQL Firewall att registrera alla satser som körs av användaren i användarens vitlista
- När inställd på "ÖVERFÖRA ”, kommer SQL Firewall att tillämpa vitlistan. Alla uttalanden som inte ingår i vitlistan kommer att orsaka ett fel
- Värdet på AV ” stänger av vitlistningsfunktionen för användaren, och användaren kommer inte att kunna utföra några frågor alls
Om du vill ta bort de vitlistade frågorna för en användare, kör sqlfirewall_whitelist_delete funktion istället. Denna funktion tar en enda parameter:användarnamnet. När den har körts tar funktionen sqlfirewall_whitelist_delete bort alla vitlistade uttalanden för användaren.
sqlfirewall_whitelist_delete_entry funktionen används för att ta bort individuella fråge-ID:n från en användares vitlista. Detta kan vara användbart när du har för många tillåtna frågor för en användare och vill finjustera den. Funktionen tar två parametrar:användarnamnet och fråge-ID. Du kan hitta ID:t för den fråga du vill utesluta från vitlistan genom att titta på sqlfirewall-vyn.
sqlfirewall_whitelist_users funktionen tar inte någon parameter. Det returnerar en lista över användare som har aktiverat vitlistning för sitt konto.
Du kan exportera vitlistan för en användare med hjälp av sqlfirewall_whitelist_export fungera. Den här funktionen tar två parametrar:användarnamnet och filnamnet där den exporterar användarens vitlistade uttalanden. Filen måste finnas på en plats där PostgreSQL-serverprocessen har skrivåtkomst till.
I likhet med funktionen sqlfirewall_whitelist_export, funktionen sqlfirewall_whitelist_import används för att importera en exporterad vitlistasfil för en användare till en annan PostgreSQL-instans för den användaren. Denna funktion kräver också två parametrar, användarnamnet och filen som ska importeras. Filen måste finnas på en plats där PostgreSQL-serverprocessen kan läsa den från.
Måldatabasen måste också vara en binär kopia av källdatabasen – det betyder att målet måste vara en del av en strömmande replikering eller en PostgreSQL-instans skapad från en källa med kommandot pg_basebackup. Databaser skapade från en logisk dump av källdatabasen kan inte importera vitlistasfilen – i sådana fall måste vitlistan konfigureras manuellt.
Steg 2:Aktivera vitlistning för användare
Nu när vi har några idéer om SQL-brandväggsfunktionerna, låt oss börja vitlistningsprocessen för både human_user och app_user i pagila- och chinook-databaserna.
I kodavsnittet nedan kör vi följande kommandon som postgres superanvändare.
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 också bekräfta genom att köra 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)
Steg 3:Köra en arbetsbelastning
Med vitlistan aktiverad och inspelning byter vi till app_user-kontot och kör några frågor enligt nedan. Lägg märke till hur app_user väljer olika "ID-fält" (customer_id, staff_id, EmployeeID, etc.) från olika 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"; ...
Därefter byter vi till human_user-kontot och kör några enkla frågor på några av tabellerna som app_user gick åt.
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"; ...
Om vi frågar sqlfirewall-vyn från någon av databaserna som postgres-användare kan vi se frågorna som vitlistades för varje användare.
Steg 4:Genomför vitlista
Med ett exempel på arbetsbelastningen som nu fångats, tillämpar vi vitlistan för båda användarkontona i båda databaserna genom att köra följande kommandon. Kommandona måste köras av en superanvändare; i det här fallet kör vi dessa som användaren 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) Steg 5:Testning
För att testa vitlistan loggade vi in på pagila-databasen som human_user och försökte köra kommandona som kördes innan
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; ...
Kommandona lyckas. Detta beror på att dessa kommandon kördes av human_user tidigare och var vitlistade.
Nu försöker vi köra följande kommando. Notera hur human_user försöker köra en fråga med två extra fält. Den här frågan kördes av app_user tidigare.
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
Uttrycket misslyckas med ett meddelande som detta:
ERROR: Execution of non-whitelisted statement prohibited
Detta händer eftersom human_user tidigare hade kört ett kommando för att bara välja två fält från den här tabellen, inte de extra fälten (betalnings-ID och kund-ID) han försöker komma åt nu. SQL Firewall registrerade hans tidigare fråga som en känd arbetsbelastning och vitlistade den frågan. När han försöker lägga till de två nya fälten i sin fråga blockerar brandväggen honom.
Om du tänker på det är det så här en hackare kan vilja stjäla ett ID-fältvärde så att det kan användas i WHERE-satsen i en annan fråga för att få ytterligare information. Att använda en vitlistningsmetod blockerar effektivt det.
Så, vad händer om användaren behöver dessa två extra fält för legitimt syfte? I ett sådant fall måste vitlistasläget för användaren ändras tillbaka till "RECORD" igen så att de nya frågorna kan köras och SQL-brandväggen kan vitlista dem.
Låt oss köra ett nytt test innan vi avslutar. Den här gången kommer vi att anta att en hackare har äventyrat app_user-kontot och vill köra ett raderingsutdrag mot "betalnings"-tabellen. Kom ihåg att vi hade beviljat användaren DELETE och TRUNCATE privilegier på bordet.
Så vi loggar in som app_user och kör en DELETE-sats.
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
Slutsats
Uttalandet nekas eftersom det inte är vitlistat. Även när användaren har rätt att ta bort data från tabellen har SQL Firewall med rätta blockerat den.
Som du kan se är SQL Firewall ett kraftfullt säkerhetsverktyg. Den har säkerhetsfunktioner som gör att den kan användas i ett pseudoproduktionsläge. I det här läget kan en testanvändare konfigureras att få sina uttalanden vitlistade och sedan kan funktionalitet testas.
DBA:er och systemadministratörer måste dock vara medvetna om några punkter:
Först och främst, när en användares vitlista läge är inställt på "RECORD", hindrar inte SQL Firewall användaren från att köra någon fråga. Med andra ord måste SQL-brandväggen först tränas innan den kan blockera en användare. Det är därför det är viktigt att se till att normala databasåtkomstprivilegier också tillämpas på alla användarkonton. Detta är desto viktigare eftersom medlemmar i rollerna superuser och sqlfirewall_manager är undantagna från brandväggsreglerna. SQL-brandväggen ersätter inte befintlig databassäkerhet – den är till för att komplettera den.
För det andra, när du vitlistar individuella SELECT-, INSERT-, UPDATE- och DELETE-satser, kommer SQL Firewall att behandla objektnamn som används i dessa kommandon skrivna i olika bokstäver (versaler, blandade bokstäver eller gemener) som samma. Alla andra kommandon kommer att jämföras på basis av de textuella frågesträngarna. Så till exempel kommer SQL Firewall att behandla "BEGIN" och "begin" och "Begin" som en del av separata frågor.
För det tredje replikerar inte SQL Firewalls vitlista automatiskt till standbynoder i en replikeringsmiljö. Du kan dock exportera vitlistor med funktionen sqlfirewall_whitelist_export och importera den till en annan server med funktionen sqlfirewall_whitelist_import. Tyvärr fungerar det inte att säkerhetskopiera databasen eller sqlfirewall-schemat och återställa i målinstansen. Målservern måste också ha samma användarkonto för att vitlistan ska vara användbar.
Det måste vara noggrant övervägande av alla möjliga typer av frågor som en användare kan utföra mot en databas och köra vitlistan i "RECORD"-läge så länge som nödvändigt för att fånga alla normala arbetsbelastningar. För lite fångst kan begränsa ett användarkonto från att köra legitima frågor, medan inspelning under för lång tid kan lägga till kommandon till vitlistan i onödan. Detta kan orsaka förseningar för SQL-brandväggen när den jämför uttalanden i tillämpningsläge.