Nel mondo di oggi, le organizzazioni affrontano sempre più un livello senza precedenti di minacce di attacchi informatici contro le loro risorse informative.
Gli attacchi informatici possono assumere molte forme. Uno di questi attacchi è chiamato SQL injection . Con SQL injection, i giocatori canaglia prendono di mira il database back-end di qualsiasi sistema. Di solito, questi sistemi sono rivolti al pubblico. Gli hacker tentano di inviare query apparentemente innocue e regolari a un database, tranne che con parametri che possono esporre informazioni che non dovrebbero vedere, o corrompere il database con informazioni errate o causare il crash del sistema.
Gli specialisti della sicurezza informatica corrono sempre contro il tempo per stare al passo con la sofisticatezza di questi attacchi e, come la maggior parte delle grandi guerre, ora sono combattuti su ogni fronte. Ciò significa che la sicurezza deve essere implementata a ogni livello dello stack di un'applicazione, incluso il livello del database.
I DBA stagionati in genere cercano di proteggere i database con misure come il controllo degli accessi basato sui ruoli (RBAC), l'autenticazione federata, il controllo o SSL. Tuttavia, dovrebbe essere presa in considerazione anche qualsiasi misura aggiuntiva per proteggere il database.
Una di queste misure di protezione è un firewall di database. Come i normali firewall, i firewall del database filtrano il traffico in base a una whitelist o una blacklist. Possono anche "imparare" dai modelli di accesso al sistema per capire quali affermazioni possono essere considerate attendibili e quali no. L'utilizzo di uno strumento come questo aggiunge un forte livello di protezione contro l'iniezione di SQL.
In questo articolo parleremo di SQL Firewall , un firewall per database per la protezione dei database PostgreSQL. SQL Firewall è costruito e supportato da 2ndQuadrant, leader nelle tecnologie PostgreSQL.
Come funziona SQL Firewall
SQL Firewall viene fornito come estensione di PostgreSQL 9.4 e versioni successive. Sebbene sia attualmente supportato fino alla versione 10 di PostgreSQL, sono in corso ulteriori lavori per supportare le versioni successive.
Poiché si tratta di un'estensione, SQL Firewall è molto semplice da installare e configurare. Una volta configurato, può essere utilizzato per inserire nella whitelist le istruzioni SQL rispetto ai database per i singoli utenti. La whitelist deriva dall'"addestramento" dell'estensione con il carico di lavoro tipico di un'applicazione, in genere proveniente da esecuzioni ripetute di una suite di test che coprono tutti i possibili scenari. Una volta che la whitelist è stata messa a punto e finalizzata, può essere esportata e quindi importata in altre istanze PostgreSQL che servono carichi di lavoro simili.
Ad esempio, prima dell'avvio di un'applicazione, ogni utente configurato può eseguire carichi di lavoro di esempio di qualità di produzione sul database in un ambiente controllato. Un account utente umano può essere autorizzato a eseguire query di sola lettura mentre un account utente dell'applicazione può essere autorizzato a eseguire letture e scritture. SQL Firewall quindi inserisce nella whitelist le query di lettura per gli account utente umano e dell'applicazione e scrive le query solo per l'account utente dell'applicazione. Se un utente umano tenta quindi di eseguire un INSERT, DELETE o UPDATE, SQL Firewall negherà l'operazione. Con l'evoluzione dell'applicazione, la whitelist può anche essere riqualificata con il carico di lavoro che cambia.
Ogni istruzione bloccata viene registrata da SQL Firewall, il che significa che i team operativi possono inviare questi log alle loro soluzioni di gestione dei log e ricevere avvisi ogni volta che si verifica un'eccezione.
Impostazione dell'ambiente
In questo articolo, installeremo SQL Firewall per un'istanza PostgreSQL 10 a nodo singolo in esecuzione su Red Hat Enterprise Linux 7. Al momento della stesura, RHEL/CentOS 7 e PostgreSQL 10 sono le versioni più supportate. Tuttavia, come accennato in precedenza, è in arrivo ulteriore supporto.
Nota
[Si noti che SQL Firewall è un prodotto con licenza commerciale disponibile per i clienti dell'assistenza 24 ore su 24, 7 giorni su 7. Non è disponibile per il download dal sito Web pubblico di 2ndQuadrant.]
Passaggio 1:installazione di PostgreSQL 10
Il nostro sistema di test è un'istanza Amazon EC2 che esegue Red Hat Enterprise Linux 7.2.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
Eseguiamo il comando seguente per scaricare il repository RPM per 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
Successivamente, installiamo il server e il pacchetto client.
# yum install postgresql10-server postgresql10 -y
Una volta installati correttamente i pacchetti, eseguiamo il comando initdb per inizializzare il database.
# /usr/pgsql-10/bin/postgresql-10-setup initdb Initializing database ... OK
Successivamente, apportiamo la seguente modifica al file postgresql.conf. Per impostazione predefinita, si trova nella directory /var/lib/pgsql/10/data/.
listen_addresses = '*'
E poi, aggiungi la seguente riga al file pg_hba.conf (di nuovo, per impostazione predefinita, si trova nella directory /var/lib/pgsql/10/data/).
host all all <our IP address range> md5
Quindi avviamo il servizio PostgreSQL e ne consentiamo l'avvio automatico.
# systemctl start postgresql-10.service # systemctl enable postgresql-10.service
Infine, accediamo all'istanza del database da psql come utente postgres e cambiamo la password.
# su - postgres -bash-4.2$ psql psql (10.12) Type "help" for help. postgres=# \password Enter new password: Enter it again: postgres=#
Fase 2:ripristino di database di esempio
Per emulare un sistema di produzione, abbiamo ripristinato due database di esempio nel nostro server PostgreSQL. Questi database sono disponibili pubblicamente:
- Pagila : la versione PostgreSQL del popolare database MySQL Sakila
- Chinook : un database sul digital media store
Fase 3:crea ruoli e utenti
Con i database creati, creiamo due ruoli utente. Uno si chiama “human_user”, l'altro si chiama “app_user”.
Il ruolo human_user rappresenta qualsiasi persona che accede al database dal back-end o con uno strumento client. Il ruolo app_user rappresenta l'account che un'applicazione utilizzerà per connettersi al 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>';"
Ai ruoli utente viene quindi concessa l'autorizzazione ad accedere ai database chinook e pagila eseguendo i seguenti comandi come utente 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;"
Passaggio 4:installazione di SQL Firewall
L'installazione di SQL Firewall è un processo semplice. Per prima cosa installiamo il pacchetto.
# 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%]
Quindi aggiorniamo il file postgresql.conf modificando il parametro shared_preload_libraries.
shared_preload_libraries = 'sqlfirewall'
Al termine, riavviamo il servizio PostgreSQL.
# systemctl restart postgresql-10.service
Una volta riavviato il servizio, accediamo all'istanza come utente postgres e aggiungiamo l'estensione a entrambi i database di esempio.
$ 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
L'immagine seguente mostra le estensioni installate su entrambi i database. Nota come esiste uno schema speciale chiamato "sqlfirewall" creato anche in entrambi i database. Questo schema contiene tutti gli oggetti di database relativi al funzionamento di SQL Firewall.
Possiamo anche vedere che un nuovo ruolo chiamato "sqlfirewall_manager" viene creato automaticamente. Gli utenti aggiunti a questo ruolo possono accedere a funzioni e viste nello schema sqlfirewall.
Passaggio 5:configurazione di SQL Firewall
Un certo numero di parametri vengono quindi aggiunti a postgresql.conf file. Per Red Hat Enterprise Linux e le sue distribuzioni derivate, la posizione della directory predefinita per questo file è /var/lib/pgsql/10/data/.
Nel seguente frammento di codice, stiamo modificando il file e aggiungendo una serie di parametri.
# vim /var/lib/pgsql/10/data/postgresql.conf sqlfirewall.whitelist = 'verbose' sqlfirewall.track = 'all' sqlfirewall.track_utility = 'true' sqlfirewall.save = 'true'
Quindi ricarichiamo tutta la configurazione.
$ 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)
Successivamente, lasciamo dormire il processo per un secondo.
postgres=# SELECT pg_sleep(1); pg_sleep ---------- (1 row)
e quindi controllare lo stato della whitelist in entrambi i database. Se sono stati seguiti i passaggi, entrambi i database dovrebbero avere la whitelist abilitata.
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)
Esaminiamo i parametri che abbiamo appena aggiunto.
La lista bianca di sqlfirewall. viene utilizzato per abilitare la funzionalità di whitelist del firewall. Questo parametro può avere uno dei due valori:"verbose" o "protect".
Con l'opzione dettagliata, SQL Firewall mostrerà un messaggio di avviso all'utente quando tenta di eseguire una query non inclusa nella whitelist che non è autorizzato a farlo. Quando il valore è impostato su protetto, SQL Firewall mostrerà un messaggio generico di "autorizzazione negata". Come best practice, consigliamo di impostare il valore su "protect", che non dà all'hacker alcuna idea del motivo per cui il comando è stato rifiutato. Abbiamo impostato questo parametro su "verbose" solo a scopo dimostrativo.
I valori assegnati a sqlfirewall.track e sqlfirewall.track_utility i parametri assicurano che SQL Firewall tenga traccia di tutte le istruzioni ai fini dell'inserimento nella whitelist.
Infine, impostando sqlfirewall.save parametro su "true" assicura che le istruzioni nella whitelist vengano mantenute anche se il server viene riavviato.
Esecuzione di SQL Firewall
L'esecuzione di SQL Firewall implica il richiamo di una serie di funzioni fornite con l'estensione.
Passaggio 1:comprensione delle funzioni di SQL Firewall
L'estensione SQL Firewall crea una serie di funzioni nello schema sqlfirewall del database in cui è installato. La maggior parte di queste funzioni può essere eseguita solo da superutenti o membri del ruolo sqlfirewall_manager.
Esaminiamo rapidamente alcune di queste funzioni.
sqlfirewall_whitelist_mode è la funzione principale con cui lavoreremo. Questa funzione abilita la whitelist delle istruzioni per un particolare utente PostgreSQL. Richiede due parametri:uno è il nome utente, l'altro è whitelist_mode.
La modalità whitelist parametro può avere tre valori:
- Quando è impostato su "REGISTRA ”, SQL Firewall registrerà tutte le istruzioni eseguite dall'utente nella whitelist dell'utente
- Quando impostato su "ENFORCE ”, SQL Firewall applicherà la whitelist. Qualsiasi istruzione non inclusa nella whitelist causerà un errore
- Il valore di "OFF ” disattiva la funzionalità di whitelist per l'utente e l'utente non sarà in grado di eseguire alcuna query
Se desideri rimuovere le query autorizzate per un utente, esegui sqlfirewall_whitelist_delete funzione invece. Questa funzione accetta un unico parametro:il nome utente. Una volta eseguita, la funzione sqlfirewall_whitelist_delete rimuove tutte le istruzioni autorizzate per l'utente.
La sqlfirewall_whitelist_delete_entry viene utilizzata per rimuovere singoli ID query dalla whitelist di un utente. Questo può essere utile quando hai troppe query consentite per un utente e vuoi perfezionarlo. La funzione accetta due parametri:il nome utente e l'ID della query. Puoi trovare l'ID della query che desideri escludere dalla whitelist guardando la vista sqlfirewall.
Gli sqlfirewall_whitelist_users la funzione non accetta alcun parametro. Restituisce un elenco di utenti che hanno abilitato la whitelist per il proprio account.
Puoi esportare la whitelist per un utente utilizzando sqlfirewall_whitelist_export funzione. Questa funzione accetta due parametri:il nome utente e il nome del file in cui esporta le istruzioni dell'utente nella whitelist. Il file deve trovarsi in una posizione a cui il processo del server PostgreSQL ha accesso in scrittura.
Simile alla funzione sqlfirewall_whitelist_export, la funzione sqlfirewall_whitelist_import viene utilizzato per importare un file di whitelist esportato per un utente in un'istanza PostgreSQL diversa per quell'utente. Questa funzione accetta anche due parametri, il nome utente e il file da importare. Il file deve trovarsi in una posizione da cui il processo del server PostgreSQL può leggerlo.
Inoltre, il database di destinazione deve essere una copia binaria del database di origine, ciò significa che la destinazione deve far parte di una replica in streaming o di un'istanza PostgreSQL creata da un'origine con il comando pg_basebackup. I database creati da un dump logico del database di origine non possono importare il file della whitelist:in questi casi, la whitelist deve essere configurata manualmente.
Fase 2:abilitazione della whitelist per gli utenti
Ora che abbiamo alcune idee sulle funzioni di SQL Firewall, iniziamo il processo di whitelist sia per human_user che per app_user nei database pagila e chinook.
Nello snippet di codice qui sotto, stiamo eseguendo i seguenti comandi come superutente 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) Possiamo anche confermare eseguendo la funzione 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)
Fase 3:esecuzione di un carico di lavoro
Con la whitelist abilitata e la registrazione, passiamo all'account app_user ed eseguiamo alcune query come mostrato di seguito. Nota come app_user seleziona vari "campi ID" (customer_id, staff_id, EmployeeID, ecc.) da tabelle diverse.
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"; ...
Successivamente, passiamo all'account human_user ed eseguiamo alcune semplici query su alcune delle tabelle a cui l'app_user ha avuto accesso.
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"; ...
Se interroghiamo la vista sqlfirewall da uno qualsiasi dei database come utente postgres, possiamo vedere le query che sono state inserite nella whitelist per ciascun utente.
Fase 4:applicazione della whitelist
Con un carico di lavoro di esempio ora acquisito, applichiamo la whitelist per entrambi gli account utente in entrambi i database eseguendo i seguenti comandi. I comandi devono essere eseguiti da un superutente; in questo caso, li stiamo eseguendo come utente 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) Fase 5:test
Per testare la whitelist, abbiamo effettuato l'accesso al database di pagila come human_user e abbiamo provato a eseguire i comandi che erano stati eseguiti prima
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; ...
I comandi riescono. Questo perché questi comandi sono stati eseguiti in precedenza da human_user e sono stati inseriti nella whitelist.
Ora proviamo a eseguire il seguente comando. Nota come human_user sta tentando di eseguire una query con due campi aggiuntivi. Questa query è stata eseguita in precedenza da app_user.
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
L'istruzione non riesce con un messaggio come questo:
ERROR: Execution of non-whitelisted statement prohibited
Ciò sta accadendo perché human_user aveva precedentemente eseguito un comando per selezionare solo due campi da questa tabella, non i campi extra (ID pagamento e ID cliente) a cui sta tentando di accedere ora. SQL Firewall ha registrato la query precedente come carico di lavoro noto e l'ha inserita nella whitelist. Mentre cerca di aggiungere questi due nuovi campi nella sua query, il firewall lo sta bloccando.
Se ci pensi, questo è il modo in cui un hacker potrebbe voler rubare un valore di campo ID in modo che possa essere utilizzato nella clausola WHERE di un'altra query per ottenere ulteriori informazioni. L'utilizzo di un metodo di inserimento nella whitelist lo blocca in modo efficace.
Quindi, cosa succede se l'utente ha bisogno di questi due campi aggiuntivi per scopi legittimi? In tal caso, la modalità whitelist per l'utente deve essere nuovamente impostata su "RECORD" in modo che le nuove query possano essere eseguite e SQL Firewall possa autorizzarle.
Eseguiamo un altro test prima di concludere. Questa volta, supponiamo che un hacker abbia compromesso l'account app_user e desideri eseguire un'istruzione di eliminazione rispetto alla tabella "pagamento". Ricorda che abbiamo concesso all'utente i privilegi DELETE e TRUNCATE sulla tabella.
Quindi accediamo come app_user ed eseguiamo un'istruzione 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
Conclusione
La dichiarazione viene negata perché non è nella whitelist. Anche quando l'utente ha il diritto di eliminare i dati dalla tabella, SQL Firewall lo ha giustamente bloccato.
Come puoi vedere, SQL Firewall è un potente strumento di sicurezza. Ha caratteristiche di sicurezza che ne consentono l'utilizzo in modalità pseudo-produzione. In questa modalità, un utente di test può essere configurato in modo che le sue istruzioni vengano inserite nella whitelist e quindi la funzionalità può essere testata.
I DBA e gli amministratori di sistema, tuttavia, devono essere consapevoli di alcuni punti:
Innanzitutto, quando la modalità whitelist di un utente è impostata su "RECORD", SQL Firewall non impedisce all'utente di eseguire alcuna query. In altre parole, SQL Firewall deve essere prima addestrato prima che possa bloccare un utente. Ecco perché è importante garantire che i normali privilegi di accesso al database vengano applicati anche a qualsiasi account utente. Questo è tanto più importante perché i membri dei ruoli superuser e sqlfirewall_manager sono esentati dalle regole del firewall. SQL Firewall non sostituisce la sicurezza del database esistente, ma è lì per integrarla.
In secondo luogo, quando si inseriscono nella whitelist singole istruzioni SELECT, INSERT, UPDATE e DELETE, SQL Firewall tratterà i nomi degli oggetti utilizzati in questi comandi scritti in caratteri diversi (maiuscolo, misto o minuscolo) come uguali. Tutti gli altri comandi verranno confrontati sulla base delle stringhe di query testuali. Quindi, ad esempio, SQL Firewall tratterà "BEGIN" e "begin" e "Begin" come parte di query separate.
In terzo luogo, la whitelist di SQL Firewall non si replica automaticamente sui nodi di standby in un ambiente di replica. Tuttavia, puoi esportare whitelist utilizzando la funzione sqlfirewall_whitelist_export e importarla in un altro server utilizzando la funzione sqlfirewall_whitelist_import. Sfortunatamente, il backup del database o dello schema sqlfirewall e il ripristino nell'istanza di destinazione non funzioneranno. Inoltre, il server di destinazione deve avere lo stesso account utente presente affinché la whitelist sia utile.
È necessario considerare attentamente tutti i possibili tipi di query che un utente può eseguire su un database ed eseguire la whitelist in modalità "RECORD" per tutto il tempo necessario per acquisire tutti i normali carichi di lavoro. Un'acquisizione insufficiente può impedire a un account utente di eseguire query legittime, mentre una registrazione troppo lunga può aggiungere inutilmente comandi alla whitelist. Ciò può causare ritardi per SQL Firewall quando confronta le istruzioni in modalità di imposizione.
