En el mundo actual, las organizaciones se enfrentan cada vez más a un nivel sin precedentes de amenazas de ciberataques contra sus activos de información.
Los ciberataques pueden presentarse de muchas formas. Uno de estos ataques se llama inyección SQL . Con la inyección de SQL, los jugadores deshonestos apuntan a la base de datos de back-end de cualquier sistema. Por lo general, estos sistemas están orientados al público. Los piratas informáticos intentan enviar consultas aparentemente inocuas y regulares a una base de datos, excepto con parámetros que pueden exponer información que se supone que no deben ver, corromper la base de datos con información incorrecta o bloquear el sistema.
Los especialistas en ciberseguridad siempre están compitiendo contra el tiempo para mantenerse a la vanguardia de la sofisticación de estos ataques y, como la mayoría de las grandes guerras, ahora se libra en todos los frentes. Esto significa que la seguridad debe implementarse en cada capa de la pila de una aplicación, incluida la capa de la base de datos.
Los DBA experimentados suelen intentar proteger las bases de datos con medidas como el control de acceso basado en roles (RBAC), la autenticación federada, la auditoría o SSL. Sin embargo, también se debe considerar cualquier medida adicional para proteger la base de datos.
Una de esas medidas de protección es un firewall de base de datos. Al igual que los firewalls regulares, los firewalls de bases de datos filtran el tráfico según una lista blanca o una lista negra. También pueden "aprender" de los patrones de acceso al sistema para comprender en qué declaraciones se puede confiar y cuáles no. El uso de una herramienta como esta agrega una fuerte capa de protección contra la inyección de SQL.
En este artículo, hablaremos sobre SQL Firewall , un firewall de base de datos para proteger bases de datos PostgreSQL. SQL Firewall está construido y respaldado por 2ndQuadrant, un líder en tecnologías PostgreSQL.
Cómo funciona el cortafuegos SQL
SQL Firewall viene como una extensión de PostgreSQL 9.4 y superior. Aunque actualmente es compatible con la versión 10 de PostgreSQL, se está trabajando más para admitir versiones posteriores.
Dado que es una extensión, SQL Firewall es muy sencillo de instalar y configurar. Una vez configurado, se puede usar para incluir en la lista blanca las declaraciones de SQL contra las bases de datos para usuarios individuales. La inclusión en la lista blanca proviene del "entrenamiento" de la extensión con la carga de trabajo típica de una aplicación, que generalmente proviene de ejecuciones repetidas de un conjunto de pruebas que cubren todos los escenarios posibles. Una vez que la lista blanca está ajustada y finalizada, se puede exportar y luego importar a otras instancias de PostgreSQL que atiendan cargas de trabajo similares.
Por ejemplo, antes del lanzamiento de una aplicación, cada usuario configurado puede ejecutar cargas de trabajo de muestra con calidad de producción en la base de datos en un entorno controlado. Se puede permitir que una cuenta de usuario humano ejecute solo consultas de solo lectura, mientras que una cuenta de usuario de aplicación puede ejecutar lecturas y escrituras. Luego, SQL Firewall incluye en la lista blanca las consultas de lectura para las cuentas de usuario humano y de la aplicación y las consultas de escritura solo para la cuenta de usuario de la aplicación. Si un usuario humano intenta ejecutar INSERTAR, ELIMINAR o ACTUALIZAR, SQL Firewall denegará la operación. A medida que la aplicación evoluciona, la lista blanca también se puede volver a entrenar con la carga de trabajo cambiante.
SQL Firewall registra cada declaración bloqueada, lo que significa que los equipos de operaciones pueden enviar estos registros a sus soluciones de administración de registros y recibir alertas cada vez que hay una excepción.
Configuración del entorno
En este artículo, instalaremos SQL Firewall para una instancia de PostgreSQL 10 de un solo nodo que se ejecuta en Red Hat Enterprise Linux 7. Al momento de escribir este artículo, RHEL/CentOS 7 y PostgreSQL 10 son las versiones más compatibles. Sin embargo, como se mencionó anteriormente, está llegando más soporte.
Nota
[Tenga en cuenta que SQL Firewall es un producto con licencia comercial disponible para los clientes de soporte 24/7. No está disponible para su descarga desde el sitio web público de 2ndQuadrant.]
Paso 1:Instalación de PostgreSQL 10
Nuestro sistema de prueba es una instancia de Amazon EC2 que ejecuta Red Hat Enterprise Linux 7.2.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
Ejecutamos el siguiente comando para descargar el repositorio RPM para 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
A continuación, instalamos el servidor y el paquete del cliente.
# yum install postgresql10-server postgresql10 -y
Una vez que los paquetes se hayan instalado correctamente, ejecutamos el comando initdb para inicializar la base de datos.
# /usr/pgsql-10/bin/postgresql-10-setup initdb Initializing database ... OK
A continuación, hacemos el siguiente cambio en el archivo postgresql.conf. De forma predeterminada, se encuentra en el directorio /var/lib/pgsql/10/data/.
listen_addresses = '*'
Y luego, agregue la siguiente línea al archivo pg_hba.conf (nuevamente, de manera predeterminada, se encuentra en el directorio /var/lib/pgsql/10/data/).
host all all <our IP address range> md5
Luego iniciamos el servicio PostgreSQL y lo habilitamos para que se inicie automáticamente.
# systemctl start postgresql-10.service # systemctl enable postgresql-10.service
Finalmente, iniciamos sesión en la instancia de la base de datos desde psql como usuario de postgres y cambiamos la contraseña.
# su - postgres -bash-4.2$ psql psql (10.12) Type "help" for help. postgres=# \password Enter new password: Enter it again: postgres=#
Paso 2:restaurar bases de datos de muestra
Para emular un sistema de producción, hemos restaurado dos bases de datos de muestra en nuestro servidor PostgreSQL. Estas bases de datos están disponibles públicamente:
- Paguila : la versión PostgreSQL de la popular base de datos MySQL Sakila
- Chinook : una base de datos sobre la tienda de medios digitales
Paso 3:Crear roles y usuarios
Con las bases de datos creadas, creamos dos roles de usuario. Uno se llama "usuario_humano", el otro se llama "usuario_aplicación".
El rol human_user representa a cualquier persona que acceda a la base de datos desde el back-end o con una herramienta de cliente. El rol app_user representa la cuenta que usará una aplicación para conectarse a la base de datos.
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>';"
A los roles de usuario se les otorga permiso para acceder a las bases de datos chinook y pagila ejecutando los siguientes comandos como usuario de 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;"
Paso 4:Instalación del cortafuegos SQL
La instalación de SQL Firewall es un proceso sencillo. Primero, instalamos el paquete.
# 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%]
Luego actualizamos el archivo postgresql.conf cambiando el parámetro shared_preload_libraries.
shared_preload_libraries = 'sqlfirewall'
Una vez hecho esto, reiniciamos el servicio de PostgreSQL.
# systemctl restart postgresql-10.service
Una vez que se reinicia el servicio, iniciamos sesión en la instancia como usuario de postgres y agregamos la extensión a ambas bases de datos de muestra.
$ 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
La siguiente imagen muestra las extensiones instaladas en ambas bases de datos. Tenga en cuenta que también se creó un esquema especial llamado "sqlfirewall" en ambas bases de datos. Este esquema contiene todos los objetos de la base de datos relacionados con el funcionamiento de SQL Firewall.
También podemos ver que se crea automáticamente un nuevo rol llamado "sqlfirewall_manager". Los usuarios que se agregan a este rol pueden acceder a funciones y vistas en el esquema de sqlfirewall.
Paso 5:Configuración del cortafuegos SQL
Luego se agregan una serie de parámetros al postgresql.conf expediente. Para Red Hat Enterprise Linux y sus distribuciones derivadas, la ubicación del directorio predeterminado para este archivo es /var/lib/pgsql/10/data/.
En el siguiente fragmento de código, estamos editando el archivo y agregando una serie de parámetros.
# vim /var/lib/pgsql/10/data/postgresql.conf sqlfirewall.whitelist = 'verbose' sqlfirewall.track = 'all' sqlfirewall.track_utility = 'true' sqlfirewall.save = 'true'
Luego recargamos toda la configuración.
$ 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)
Luego, dejamos que el proceso duerma por un segundo.
postgres=# SELECT pg_sleep(1); pg_sleep ---------- (1 row)
y luego verifique el estado de la lista blanca en ambas bases de datos. Si se siguieron los pasos, ambas bases de datos deberían tener habilitada la lista blanca.
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)
Repasemos los parámetros que acabamos de agregar.
La sqlfirewall.lista blanca El parámetro se utiliza para habilitar la funcionalidad de lista blanca del cortafuegos. Este parámetro puede tener dos valores:"verbose" o "protect".
Con la opción detallada, SQL Firewall mostrará un mensaje de advertencia al usuario cuando intente ejecutar una consulta no incluida en la lista blanca de que no tiene permiso para hacerlo. Cuando el valor se establece en protegido, SQL Firewall mostrará un mensaje genérico de "permiso denegado". Como práctica recomendada, recomendamos establecer el valor en "proteger", lo que no le da al pirata informático ninguna idea de por qué se rechaza el comando. Hemos establecido este parámetro en "detallado" solo con fines de demostración.
Los valores asignados a sqlfirewall.track y la sqlfirewall.track_utility Los parámetros aseguran que SQL Firewall esté rastreando todas las declaraciones con fines de inclusión en la lista blanca.
Finalmente, configurar sqlfirewall.save parámetro en "verdadero" garantiza que las declaraciones incluidas en la lista blanca se mantengan incluso si se reinicia el servidor.
Ejecución del cortafuegos SQL
Ejecutar SQL Firewall implica invocar una serie de funciones que vienen con la extensión.
Paso 1:comprensión de las funciones de SQL Firewall
La extensión SQL Firewall crea una serie de funciones en el esquema sqlfirewall de la base de datos donde está instalada. La mayoría de estas funciones solo pueden ser ejecutadas por superusuarios o miembros del rol sqlfirewall_manager.
Repasemos rápidamente algunas de estas funciones.
sqlfirewall_whitelist_mode es la función principal con la que trabajaremos. Esta función habilita la declaración en la lista blanca para un usuario de PostgreSQL en particular. Toma dos parámetros:uno es el nombre de usuario, el otro es whitelist_mode.
El modo_lista_blanca El parámetro puede tener tres valores:
- Cuando está configurado en "GRABAR ”, SQL Firewall registrará todas las declaraciones ejecutadas por el usuario en la lista blanca del usuario
- Cuando se establece en “ENFORCE ”, SQL Firewall aplicará la lista blanca. Cualquier declaración no incluida en la lista blanca causará un error
- El valor de “DESACTIVADO ” desactiva la funcionalidad de lista blanca para el usuario, y el usuario no podrá ejecutar ninguna consulta
Si desea eliminar las consultas incluidas en la lista blanca para un usuario, ejecute sqlfirewall_whitelist_delete función en su lugar. Esta función toma un único parámetro:el nombre de usuario. Una vez ejecutada, la función sqlfirewall_whitelist_delete elimina todas las declaraciones incluidas en la lista blanca para el usuario.
El sqlfirewall_whitelist_delete_entry La función se utiliza para eliminar ID de consultas individuales de la lista blanca de un usuario. Esto puede ser útil cuando tiene demasiadas consultas permitidas para un usuario y desea ajustarlas. La función toma dos parámetros:el nombre de usuario y el ID de la consulta. Puede encontrar el ID de la consulta que desea excluir de la lista blanca en la vista de sqlfirewall.
Los sqlfirewall_whitelist_users La función no toma ningún parámetro. Devuelve una lista de usuarios que tienen la lista blanca habilitada para su cuenta.
Puede exportar la lista blanca de un usuario mediante sqlfirewall_whitelist_export función. Esta función toma dos parámetros:el nombre de usuario y el nombre del archivo donde exporta las declaraciones del usuario en la lista blanca. El archivo debe estar en una ubicación donde el proceso del servidor PostgreSQL tenga acceso de escritura.
Similar a la función sqlfirewall_whitelist_export, la función sqlfirewall_whitelist_import se utiliza para importar un archivo de lista blanca exportado para un usuario a una instancia de PostgreSQL diferente para ese usuario. Esta función también toma dos parámetros, el nombre de usuario y el archivo a importar. El archivo debe estar en una ubicación desde donde el proceso del servidor PostgreSQL pueda leerlo.
Además, la base de datos de destino debe ser una copia binaria de la base de datos de origen, lo que significa que el destino debe ser parte de una replicación de transmisión o una instancia de PostgreSQL creada a partir de una fuente con el comando pg_basebackup. Las bases de datos creadas a partir de un volcado lógico de la base de datos de origen no pueden importar el archivo de lista blanca; en tales casos, la lista blanca debe configurarse manualmente.
Paso 2:Habilitación de la lista blanca para usuarios
Ahora que tenemos algunas ideas sobre las funciones de SQL Firewall, comencemos el proceso de inclusión en la lista blanca para human_user y app_user en las bases de datos pagila y chinook.
En el fragmento de código a continuación, estamos ejecutando los siguientes comandos como superusuario de 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) También podemos confirmar ejecutando la función 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)
Paso 3:ejecutar una carga de trabajo
Con la lista blanca habilitada y la grabación, cambiamos a la cuenta app_user y ejecutamos algunas consultas como se muestra a continuación. Observe cómo app_user selecciona varios "campos de ID" (customer_id, staff_id, EmployeeID, etc.) de diferentes tablas.
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"; ...
A continuación, cambiamos a la cuenta human_user y ejecutamos algunas consultas simples en algunas de las tablas a las que accedió app_user.
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"; ...
Si consultamos la vista de sqlfirewall desde cualquiera de las bases de datos como usuario de Postgres, podemos ver las consultas que se incluyeron en la lista blanca para cada usuario.
Paso 4:aplicación de la lista blanca
Con una carga de trabajo de muestra ahora capturada, aplicamos la lista blanca para ambas cuentas de usuario en ambas bases de datos mediante la ejecución de los siguientes comandos. Los comandos deben ser ejecutados por un superusuario; en este caso, los estamos ejecutando como el usuario 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) Paso 5:Prueba
Para probar la lista blanca, iniciamos sesión en la base de datos de pagila como human_user e intentamos ejecutar los comandos que se ejecutaron antes
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; ...
Los comandos tienen éxito. Esto se debe a que human_user ejecutó estos comandos antes y se incluyeron en la lista blanca.
Ahora tratamos de ejecutar el siguiente comando. Observe cómo human_user intenta ejecutar una consulta con dos campos adicionales. Esta consulta la ejecutó app_user antes.
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
La declaración falla con un mensaje como este:
ERROR: Execution of non-whitelisted statement prohibited
Esto sucede porque human_user había ejecutado previamente un comando para seleccionar solo dos campos de esta tabla, no los campos adicionales (ID de pago e ID de cliente) a los que intenta acceder ahora. SQL Firewall registró su consulta anterior como una carga de trabajo conocida y la incluyó en la lista blanca. Mientras intenta agregar esos dos nuevos campos en su consulta, el firewall lo bloquea.
Si lo piensa, así es como un pirata informático podría querer robar un valor de campo de ID para que pueda usarse en la cláusula WHERE de otra consulta para obtener más información. El uso de un método de lista blanca bloquea efectivamente eso.
Entonces, ¿qué sucede si el usuario necesita estos dos campos adicionales para fines legítimos? En tal caso, el modo de lista blanca para el usuario debe volver a cambiarse a "REGISTRAR" para que las nuevas consultas puedan ejecutarse y SQL Firewall pueda incluirlas en la lista blanca.
Hagamos otra prueba antes de terminar. Esta vez, asumiremos que un pirata informático ha comprometido la cuenta de usuario_aplicación y desea ejecutar una declaración de eliminación en la tabla de "pago". Recuerde que le habíamos otorgado al usuario los privilegios DELETE y TRUNCATE sobre la tabla.
Así que iniciamos sesión como app_user y ejecutamos una instrucción 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
Conclusión
La declaración se deniega porque no está incluida en la lista blanca. Incluso cuando el usuario tiene derecho a eliminar datos de la tabla, SQL Firewall lo ha bloqueado correctamente.
Como puede ver, SQL Firewall es una poderosa herramienta de seguridad. Tiene características de seguridad que permiten su uso en un modo de pseudoproducción. En este modo, se puede configurar un usuario de prueba para que sus declaraciones se incluyan en la lista blanca y luego se puede probar la funcionalidad.
Sin embargo, los DBA y los administradores de sistemas deben tener en cuenta algunos puntos:
En primer lugar, cuando el modo de lista blanca de un usuario se establece en "GRABAR", SQL Firewall no impide que el usuario ejecute ninguna consulta. En otras palabras, SQL Firewall debe entrenarse primero antes de que pueda bloquear a un usuario. Por eso es importante asegurarse de que los privilegios normales de acceso a la base de datos también se apliquen a cualquier cuenta de usuario. Esto es aún más importante porque los miembros de los roles de superusuario y sqlfirewall_manager están exentos de las reglas del firewall. SQL Firewall no es el reemplazo de la seguridad de la base de datos existente, está ahí para complementarla.
En segundo lugar, al incluir en la lista blanca las declaraciones SELECT, INSERT, UPDATE y DELETE individuales, SQL Firewall tratará los nombres de los objetos utilizados en estos comandos escritos en diferentes casos (mayúsculas, mayúsculas, minúsculas o mayúsculas) como iguales. Todos los demás comandos se compararán sobre la base de las cadenas de consulta textuales. Entonces, por ejemplo, SQL Firewall tratará "BEGIN" y "begin" y "Begin" como parte de consultas separadas.
En tercer lugar, la lista blanca de SQL Firewall no se replica automáticamente en nodos en espera en un entorno de replicación. Sin embargo, puede exportar listas blancas usando la función sqlfirewall_whitelist_export e importarlas a otro servidor usando la función sqlfirewall_whitelist_import. Desafortunadamente, la copia de seguridad de la base de datos o el esquema de sqlfirewall y la restauración en la instancia de destino no funcionarán. Además, el servidor de destino debe tener la misma cuenta de usuario presente para que la lista blanca sea útil.
Debe haber una consideración cuidadosa de todos los tipos posibles de consultas que un usuario puede realizar en una base de datos y ejecutar la lista blanca en modo "REGISTRO" durante el tiempo que sea necesario para capturar todas las cargas de trabajo normales. Una captura demasiado pequeña puede impedir que una cuenta de usuario ejecute consultas legítimas, mientras que la grabación durante demasiado tiempo puede agregar comandos innecesariamente a la lista blanca. Esto puede causar demoras para SQL Firewall cuando compara sentencias en modo de aplicación.
