In de wereld van vandaag worden organisaties steeds vaker geconfronteerd met een ongekend niveau van dreiging van cyberaanvallen op hun informatiemiddelen.
Cyberaanvallen kunnen in vele vormen voorkomen. Een dergelijke aanval heet SQL-injectie . Met SQL-injectie richten malafide spelers zich op de backend-database van elk systeem. Meestal zijn deze systemen publieksgericht. Hackers proberen schijnbaar onschuldige en regelmatige zoekopdrachten naar een database te sturen, behalve met parameters die informatie kunnen blootleggen die ze niet mogen zien, of de database beschadigen met verkeerde informatie, of het systeem laten crashen.
Cybersecurity-specialisten racen altijd tegen de klok om de verfijning van deze aanvallen voor te blijven, en zoals de meeste grote oorlogen wordt er nu op elk front gevochten. Dit betekent dat beveiliging moet worden geïmplementeerd op elke laag van de stack van een applicatie, inclusief de databaselaag.
Doorgewinterde DBA's proberen databases doorgaans te beveiligen met maatregelen zoals op rollen gebaseerde toegangscontrole (RBAC), federatieve authenticatie, auditing of SSL. Elke extra maatregel om de database te beveiligen moet echter ook worden overwogen.
Een dergelijke beveiligingsmaatregel is een database-firewall. Net als reguliere firewalls, filteren databasefirewalls verkeer uit op basis van een witte of zwarte lijst. Ze kunnen ook "leren" van systeemtoegangspatronen om te begrijpen welke verklaringen kunnen worden vertrouwd en welke niet. Het gebruik van een tool als deze voegt een sterke beschermingslaag toe tegen SQL-injectie.
In dit artikel zullen we het hebben over SQL Firewall , een database-firewall voor het beschermen van PostgreSQL-databases. SQL Firewall is gebouwd en ondersteund door 2ndQuadrant, een leider in PostgreSQL-technologieën.
Hoe SQL Firewall werkt
SQL Firewall wordt geleverd als een uitbreiding op PostgreSQL 9.4 en hoger. Hoewel het momenteel wordt ondersteund tot en met PostgreSQL-versie 10, wordt er verder gewerkt aan de ondersteuning van latere versies.
Omdat het een extensie is, is SQL Firewall heel eenvoudig te installeren en configureren. Eenmaal geconfigureerd, kan het worden gebruikt om SQL-instructies op de witte lijst te zetten voor databases voor individuele gebruikers. De whitelisting komt van het "trainen" van de extensie met de typische werklast van een applicatie - meestal afkomstig van herhaalde uitvoeringen van een reeks tests die alle mogelijke scenario's omvatten. Zodra de whitelisting is verfijnd en voltooid, kan deze worden geëxporteerd en vervolgens geïmporteerd in andere PostgreSQL-instanties die vergelijkbare workloads bedienen.
Voordat bijvoorbeeld een toepassing wordt gestart, kan elke geconfigureerde gebruiker in een gecontroleerde omgeving voorbeeldworkloads van productiekwaliteit uitvoeren op de database. Een menselijke gebruikersaccount mag mogelijk alleen-lezen-query's uitvoeren, terwijl een gebruikersaccount van een toepassing zowel lees- als schrijfbewerkingen mag uitvoeren. SQL Firewall zet vervolgens leesquery's voor zowel menselijke als applicatiegebruikersaccounts op de witte lijst en schrijfquery's alleen voor de applicatiegebruikersaccount. Als een menselijke gebruiker vervolgens een INSERT, DELETE of UPDATE probeert uit te voeren, weigert SQL Firewall de bewerking. Naarmate de applicatie evolueert, kan de witte lijst ook opnieuw worden getraind met de veranderende werklast.
Elke geblokkeerde instructie wordt vastgelegd door SQL Firewall, wat betekent dat operationele teams deze logboeken naar hun oplossingen voor logbeheer kunnen sturen en elke keer dat er een uitzondering is, worden gewaarschuwd.
De omgeving instellen
In dit artikel zullen we SQL Firewall installeren voor een single-node PostgreSQL 10-instantie die draait op Red Hat Enterprise Linux 7. Op het moment van schrijven zijn RHEL/CentOS 7 en PostgreSQL 10 de best ondersteunde versies. Zoals eerder vermeld, komt er echter meer ondersteuning.
Opmerking
[Houd er rekening mee dat SQL Firewall een commercieel gelicentieerd product is dat beschikbaar is voor 24/7 ondersteuningsklanten. Het kan niet worden gedownload van de openbare website van het 2ndQuadrant.]
Stap 1:PostgreSQL 10 installeren
Ons testsysteem is een Amazon EC2-instantie met Red Hat Enterprise Linux 7.2.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
We voeren de volgende opdracht uit om de RPM-repo voor PostgreSQL 10 (x86-64) te downloaden.
# yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm -y
Vervolgens installeren we de server en het clientpakket.
# yum install postgresql10-server postgresql10 -y
Zodra de pakketten met succes zijn geïnstalleerd, voeren we de opdracht initdb uit om de database te initialiseren.
# /usr/pgsql-10/bin/postgresql-10-setup initdb Initializing database ... OK
Vervolgens brengen we de volgende wijziging aan in het bestand postgresql.conf. Standaard staat het onder de /var/lib/pgsql/10/data/ directory.
listen_addresses = '*'
En voeg dan de volgende regel toe aan het bestand pg_hba.conf (alweer staat het standaard onder de /var/lib/pgsql/10/data/ directory).
host all all <our IP address range> md5
We starten dan de PostgreSQL-service en laten deze automatisch starten.
# systemctl start postgresql-10.service # systemctl enable postgresql-10.service
Ten slotte loggen we in op de database-instantie vanuit psql als de postgres-gebruiker en wijzigen we het wachtwoord.
# su - postgres -bash-4.2$ psql psql (10.12) Type "help" for help. postgres=# \password Enter new password: Enter it again: postgres=#
Stap 2:Herstel voorbeelddatabases
Om een productiesysteem te emuleren, hebben we twee voorbeelddatabases hersteld op onze PostgreSQL-server. Deze databases zijn openbaar beschikbaar:
- Pagila : de PostgreSQL-versie van de populaire MySQL Sakila-database
- Chinook : een database over digitale mediawinkel
Stap 3:maak rollen en gebruikers aan
Met de aangemaakte databases creëren we twee gebruikersrollen. De ene heet "human_user", de andere heet "app_user".
De rol human_user vertegenwoordigt elke persoon die toegang heeft tot de database vanaf de back-end of met een clienttool. De rol app_user vertegenwoordigt het account dat een toepassing zal gebruiken om verbinding te maken met de database.
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>';"
De gebruikersrollen krijgen vervolgens toestemming om toegang te krijgen tot de chinook- en de pagila-databases door de volgende opdrachten uit te voeren als de postgres-gebruiker:
$ 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;"
Stap 4:SQL Firewall installeren
Het installeren van SQL Firewall is een eenvoudig proces. Eerst installeren we het pakket.
# 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%]
Vervolgens werken we het bestand postgresql.conf bij door de parameter shared_preload_libraries te wijzigen.
shared_preload_libraries = 'sqlfirewall'
Als we klaar zijn, herstarten we de PostgreSQL-service.
# systemctl restart postgresql-10.service
Zodra de service opnieuw is gestart, loggen we in op de instantie als de postgres-gebruiker en voegen we de extensie toe aan beide voorbeelddatabases.
$ 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
De onderstaande afbeelding toont de extensies die op beide databases zijn geïnstalleerd. Merk op dat er in beide databases ook een speciaal schema met de naam "sqlfirewall" is gemaakt. Dit schema bevat alle database-objecten die verband houden met de werking van SQL Firewall.
We kunnen ook zien dat er automatisch een nieuwe rol met de naam "sqlfirewall_manager" wordt gemaakt. Gebruikers die aan deze rol zijn toegevoegd, hebben toegang tot functies en weergaven in het sqlfirewall-schema.
Stap 5:SQL Firewall configureren
Vervolgens worden een aantal parameters toegevoegd aan de postgresql.conf het dossier. Voor Red Hat Enterprise Linux en zijn afgeleide distributies is de standaardmaplocatie voor dit bestand /var/lib/pgsql/10/data/.
In het volgende codefragment bewerken we het bestand en voegen we een aantal parameters toe.
# vim /var/lib/pgsql/10/data/postgresql.conf sqlfirewall.whitelist = 'verbose' sqlfirewall.track = 'all' sqlfirewall.track_utility = 'true' sqlfirewall.save = 'true'
Daarna laden we alle configuratie opnieuw.
$ 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)
Vervolgens laten we het proces even slapen.
postgres=# SELECT pg_sleep(1); pg_sleep ---------- (1 row)
en controleer vervolgens de status op de witte lijst in beide databases. Als de stappen zijn gevolgd, zouden beide databases whitelisting moeten hebben ingeschakeld.
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)
Laten we de parameters doornemen die we zojuist hebben toegevoegd.
De sqlfirewall.whitelist parameter wordt gebruikt om de whitelisting-functionaliteit van de firewall in te schakelen. Deze parameter kan twee waarden hebben:"uitgebreid" of "beschermen".
Met de uitgebreide optie toont SQL Firewall een waarschuwingsbericht aan de gebruiker wanneer ze een niet op de witte lijst geplaatste query proberen uit te voeren dat ze dit niet mogen doen. Als de waarde is ingesteld op beveiligd, geeft SQL Firewall een algemeen bericht 'permission geweigerd' weer. Als best practice raden we aan om de waarde in te stellen op "protect", wat de hacker geen idee geeft waarom de opdracht wordt afgewezen. We hebben deze parameter alleen voor demonstratiedoeleinden op "uitgebreid" gezet.
De waarden die zijn toegewezen aan de sqlfirewall.track en de sqlfirewall.track_utility parameters zorgen ervoor dat SQL Firewall alle instructies bijhoudt voor doeleinden op de witte lijst.
Ten slotte, het instellen van de sqlfirewall.save parameter op "true" zorgt ervoor dat de verklaringen op de witte lijst behouden blijven, zelfs als de server opnieuw wordt opgestart.
SQL Firewall draaien
Het uitvoeren van SQL Firewall omvat het aanroepen van een aantal functies die bij de extensie horen.
Stap 1:SQL Firewall-functies begrijpen
De SQL Firewall-extensie creëert een aantal functies in het sqlfirewall-schema van de database waarin deze is geïnstalleerd. De meeste van deze functies kunnen alleen worden uitgevoerd door superusers of leden van de rol sqlfirewall_manager.
Laten we snel enkele van deze functies doornemen.
sqlfirewall_whitelist_mode is de belangrijkste functie waarmee we gaan werken. Deze functie activeert de whitelisting van de instructie voor een bepaalde PostgreSQL-gebruiker. Er zijn twee parameters nodig:de ene is de gebruikersnaam, de andere is de whitelist_mode.
De whitelist_mode parameter kan drie waarden hebben:
- Als het is ingesteld op "RECORD ”, zal SQL Firewall alle door de gebruiker uitgevoerde instructies opnemen in de witte lijst van de gebruiker
- Indien ingesteld op 'ENFORCE ', zal SQL Firewall de witte lijst afdwingen. Elke verklaring die niet op de witte lijst staat, veroorzaakt een fout
- De waarde van "OFF ” schakelt de whitelist-functionaliteit voor de gebruiker uit en de gebruiker kan helemaal geen zoekopdrachten uitvoeren
Als u de zoekopdrachten op de witte lijst voor een gebruiker wilt verwijderen, voert u de sqlfirewall_whitelist_delete uit in plaats daarvan functioneren. Deze functie heeft één parameter nodig:de gebruikersnaam. Eenmaal uitgevoerd, verwijdert de functie sqlfirewall_whitelist_delete alle instructies op de witte lijst voor de gebruiker.
De sqlfirewall_whitelist_delete_entry functie wordt gebruikt om individuele query-ID's van de witte lijst van een gebruiker te verwijderen. Dit kan handig zijn als u te veel toegestane query's voor een gebruiker hebt en deze wilt verfijnen. De functie heeft twee parameters:de gebruikersnaam en de query-ID. U kunt de ID vinden van de zoekopdracht die u wilt uitsluiten van de witte lijst door naar de sqlfirewall-weergave te kijken.
De sqlfirewall_whitelist_users functie heeft geen enkele parameter nodig. Het retourneert een lijst met gebruikers die whitelisting hebben ingeschakeld voor hun account.
U kunt de witte lijst voor een gebruiker exporteren met de sqlfirewall_whitelist_export functie. Deze functie heeft twee parameters:de gebruikersnaam en de bestandsnaam waar het de op de witte lijst geplaatste verklaringen van de gebruiker exporteert. Het bestand moet zich op een locatie bevinden waar het PostgreSQL-serverproces schrijftoegang heeft.
Net als de functie sqlfirewall_whitelist_export, is de functie sqlfirewall_whitelist_import wordt gebruikt om een geëxporteerd whitelist-bestand voor een gebruiker te importeren naar een andere PostgreSQL-instantie voor die gebruiker. Deze functie heeft ook twee parameters, de gebruikersnaam en het te importeren bestand. Het bestand moet zich op een locatie bevinden waar het PostgreSQL-serverproces het kan lezen.
De doeldatabase moet ook een binaire kopie zijn van de brondatabase - dat betekent dat het doel deel moet uitmaken van een streamingreplicatie of een PostgreSQL-instantie die is gemaakt op basis van een bron met de opdracht pg_basebackup. Databases die zijn gemaakt op basis van een logische dump van de brondatabase kunnen het witte lijstbestand niet importeren - in dergelijke gevallen moet de witte lijst handmatig worden geconfigureerd.
Stap 2:Whitelisting voor gebruikers inschakelen
Nu we wat ideeën hebben over de SQL Firewall-functies, laten we het proces op de witte lijst starten voor zowel de human_user als de app_user in de pagila- en de chinook-databases.
In het onderstaande codefragment voeren we de volgende opdrachten uit als de postgres-supergebruiker.
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) We kunnen dit ook bevestigen door de functie sqlfirewall_whitelist_users() uit te voeren.
$ 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)
Stap 3:Een werklast uitvoeren
Met de witte lijst ingeschakeld en opname, schakelen we over naar het app_user-account en voeren we enkele zoekopdrachten uit, zoals hieronder wordt weergegeven. Merk op hoe de app_user verschillende "ID-velden" (customer_id, staff_id, EmployeeID, etc.) uit verschillende tabellen selecteert.
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"; ...
Vervolgens schakelen we over naar het human_user-account en voeren we enkele eenvoudige query's uit op enkele van de tabellen waartoe de app_user toegang heeft.
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"; ...
Als we de sqlfirewall-weergave uit een van de databases opvragen als de postgres-gebruiker, kunnen we de zoekopdrachten zien die voor elke gebruiker op de witte lijst zijn geplaatst.
Stap 4:Witte lijst afdwingen
Nu een voorbeeldwerkbelasting is vastgelegd, dwingen we de witte lijst voor beide gebruikersaccounts in beide databases af door de volgende opdrachten uit te voeren. De commando's moeten worden uitgevoerd door een superuser; in dit geval voeren we deze uit als de gebruiker 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) Stap 5:Testen
Om de whitelisting te testen, logden we in op de pagila-database als de human_user en probeerden we de eerder uitgevoerde opdrachten uit te voeren
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; ...
De commando's slagen. Dit komt omdat deze commando's eerder zijn uitgevoerd door de human_user en op de witte lijst stonden.
Nu proberen we de volgende opdracht uit te voeren. Merk op hoe de human_user een query probeert uit te voeren met twee extra velden. Deze zoekopdracht is eerder uitgevoerd door de app_user.
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
De instructie mislukt met een bericht als dit:
ERROR: Execution of non-whitelisted statement prohibited
Dit gebeurt omdat de human_user eerder een opdracht had uitgevoerd om slechts twee velden uit deze tabel te selecteren, niet de extra velden (betalings-ID en klant-ID) die hij nu probeert te openen. SQL Firewall registreerde zijn vorige zoekopdracht als een bekende werkbelasting en zette die vraag op de witte lijst. Terwijl hij die twee nieuwe velden in zijn zoekopdracht probeert toe te voegen, blokkeert de firewall hem.
Als je erover nadenkt, is dit hoe een hacker een ID-veldwaarde kan stelen, zodat deze kan worden gebruikt in de WHERE-component van een andere zoekopdracht om meer informatie te krijgen. Het gebruik van een whitelisting-methode blokkeert dat effectief.
Dus, wat gebeurt er als de gebruiker deze twee extra velden nodig heeft voor legitieme doeleinden? In een dergelijk geval moet de witte lijstmodus voor de gebruiker weer worden teruggezet naar "RECORD", zodat de nieuwe zoekopdrachten kunnen worden uitgevoerd en SQL Firewall ze op de witte lijst kan zetten.
Laten we nog een test doen voordat we afronden. Deze keer gaan we ervan uit dat een hacker het app_user-account heeft gecompromitteerd en een verwijderverklaring wil uitvoeren tegen de "betalingstabel". Onthoud dat we de gebruiker DELETE en TRUNCATE privileges op de tafel hadden verleend.
Dus we loggen in als de app_user en voeren een DELETE-instructie uit.
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
Conclusie
De verklaring wordt geweigerd omdat deze niet op de witte lijst staat. Zelfs als de gebruiker het recht heeft om gegevens uit de tabel te verwijderen, heeft SQL Firewall deze terecht geblokkeerd.
Zoals u kunt zien, is SQL Firewall een krachtig beveiligingshulpmiddel. Het heeft veiligheidsvoorzieningen waardoor het in een pseudo-productiemodus kan worden gebruikt. In deze modus kan een testgebruiker worden geconfigureerd om zijn verklaringen op de witte lijst te krijgen en vervolgens kan de functionaliteit worden getest.
DBA's en systeembeheerders moeten zich echter bewust zijn van een paar punten:
Allereerst, wanneer de whitelist-modus van een gebruiker is ingesteld op "RECORD", weerhoudt SQL Firewall de gebruiker er niet van om een zoekopdracht uit te voeren. Met andere woorden, SQL Firewall moet eerst worden getraind voordat het een gebruiker kan blokkeren. Daarom is het belangrijk om ervoor te zorgen dat de normale toegangsrechten tot de database ook worden toegepast op elk gebruikersaccount. Dit is des te belangrijker omdat leden van de rollen superuser en sqlfirewall_manager zijn vrijgesteld van de firewallregels. SQL Firewall is niet de vervanging voor bestaande databasebeveiliging - het is er om het aan te vullen.
Ten tweede, wanneer individuele SELECT-, INSERT-, UPDATE- en DELETE-instructies op de witte lijst worden gezet, behandelt SQL Firewall objectnamen die in deze opdrachten in verschillende hoofdletters zijn geschreven (hoofdletters, hoofdletters of kleine letters) als hetzelfde. Alle andere commando's worden vergeleken op basis van de tekstuele querystrings. Zo behandelt SQL Firewall bijvoorbeeld "BEGIN" en "begin" en "Begin" als onderdeel van afzonderlijke query's.
Ten derde repliceert de witte lijst van SQL Firewall niet automatisch naar standby-knooppunten in een replicatieomgeving. U kunt witte lijsten echter exporteren met de functie sqlfirewall_whitelist_export en deze in een andere server importeren met de functie sqlfirewall_whitelist_import. Helaas werkt het niet om een back-up te maken van de database of het sqlfirewall-schema en te herstellen in de doelinstantie. De doelserver moet ook hetzelfde gebruikersaccount hebben om de witte lijst bruikbaar te maken.
Er moet zorgvuldig worden nagedacht over alle mogelijke soorten zoekopdrachten die een gebruiker kan uitvoeren op een database en de whitelisting in "RECORD"-modus uitvoeren zo lang als nodig is om alle normale werkbelastingen vast te leggen. Te weinig vastleggen kan ervoor zorgen dat een gebruikersaccount geen legitieme zoekopdrachten uitvoert, terwijl te lang opnemen opdrachten onnodig aan de witte lijst kan toevoegen. Dit kan vertragingen veroorzaken voor SQL Firewall bij het vergelijken van instructies in de afdwingingsmodus.