No mundo de hoje, as organizações enfrentam cada vez mais um nível sem precedentes de ameaça de ataques cibernéticos contra seus ativos de informação.
Os ataques cibernéticos podem ocorrer de várias formas. Um desses ataques é chamado de injeção de SQL . Com a injeção de SQL, os jogadores desonestos têm como alvo o banco de dados de back-end de qualquer sistema. Normalmente, esses sistemas são voltados para o público. Os hackers tentam enviar consultas aparentemente inócuas e regulares a um banco de dados – exceto com parâmetros que podem expor informações que eles não deveriam ver, corromper o banco de dados com informações erradas ou travar o sistema.
Os especialistas em segurança cibernética estão sempre correndo contra o tempo para ficar à frente da sofisticação desses ataques e, como a maioria das grandes guerras, agora são travadas em todas as frentes. Isso significa que a segurança deve ser implementada em todas as camadas da pilha de um aplicativo – incluindo a camada de banco de dados.
DBAs experientes normalmente tentam proteger bancos de dados com medidas como controle de acesso baseado em função (RBAC), autenticação federada, auditoria ou SSL. No entanto, qualquer medida extra para proteger o banco de dados também deve ser considerada.
Uma dessas medidas de proteção é um firewall de banco de dados. Assim como os firewalls comuns, os firewalls de banco de dados filtram o tráfego com base em uma lista branca ou uma lista negra. Eles também podem “aprender” com os padrões de acesso ao sistema para entender quais declarações podem ser confiáveis e quais não podem. Usar uma ferramenta como essa adiciona uma forte camada de proteção contra injeção de SQL.
Neste artigo, falaremos sobre o Firewall SQL , um firewall de banco de dados para proteger bancos de dados PostgreSQL. O SQL Firewall é construído e suportado pela 2ndQuadrant, líder em tecnologias PostgreSQL.
Como funciona o firewall do SQL
O SQL Firewall vem como uma extensão do PostgreSQL 9.4 e superior. Embora atualmente seja suportado até a versão 10 do PostgreSQL, mais trabalho está em andamento para oferecer suporte a versões posteriores.
Por ser uma extensão, o SQL Firewall é muito simples de instalar e configurar. Uma vez configurado, ele pode ser usado para listar instruções SQL em bancos de dados para usuários individuais. A lista de permissões vem do “treinamento” da extensão com a carga de trabalho típica de um aplicativo – geralmente proveniente de execuções repetidas de um conjunto de testes cobrindo todos os cenários possíveis. Depois que a lista de permissões estiver ajustada e finalizada, ela poderá ser exportada e importada para outras instâncias do PostgreSQL que atendem a cargas de trabalho semelhantes.
Por exemplo, antes do lançamento de um aplicativo, cada usuário configurado pode executar cargas de trabalho de amostra com qualidade de produção no banco de dados em um ambiente controlado. Uma conta de usuário humano pode ter permissão para executar somente consultas somente leitura, enquanto uma conta de usuário de aplicativo pode ter permissão para executar leituras e gravações. O SQL Firewall, em seguida, lista as consultas de leitura para contas de usuário humano e de aplicativo e grava consultas apenas para a conta de usuário do aplicativo. Se um usuário humano tentar executar um INSERT, DELETE ou UPDATE, o SQL Firewall negará a operação. À medida que o aplicativo evolui, a lista de permissões também pode ser treinada novamente com a mudança de carga de trabalho.
Cada instrução bloqueada é registrada pelo SQL Firewall, o que significa que as equipes de operações podem enviar esses logs para suas soluções de gerenciamento de logs e ser alertadas sempre que houver uma exceção.
Configurando o ambiente
Neste artigo, instalaremos o SQL Firewall para uma instância PostgreSQL 10 de nó único em execução no Red Hat Enterprise Linux 7. No momento da redação, RHEL/CentOS 7 e PostgreSQL 10 são as versões mais suportadas. No entanto, como mencionado anteriormente, mais suporte está chegando.
Observação
[Observe que o SQL Firewall é um produto licenciado comercialmente disponível para clientes de suporte 24 horas por dia, 7 dias por semana. Não está disponível para download no site público do 2ndQuadrant.]
Etapa 1:Instalando o PostgreSQL 10
Nosso sistema de teste é uma instância do Amazon EC2 executando o Red Hat Enterprise Linux 7.2.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
Executamos o seguinte comando para baixar o repositório 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
Em seguida, instalamos o servidor e o pacote do cliente.
# yum install postgresql10-server postgresql10 -y
Uma vez que os pacotes são instalados com sucesso, executamos o comando initdb para inicializar o banco de dados.
# /usr/pgsql-10/bin/postgresql-10-setup initdb Initializing database ... OK
Em seguida, fazemos a seguinte alteração no arquivo postgresql.conf. Por padrão, está no diretório /var/lib/pgsql/10/data/.
listen_addresses = '*'
E então, adicione a seguinte linha ao arquivo pg_hba.conf (novamente, por padrão, está no diretório /var/lib/pgsql/10/data/).
host all all <our IP address range> md5
Em seguida, iniciamos o serviço PostgreSQL e o habilitamos para iniciar automaticamente.
# systemctl start postgresql-10.service # systemctl enable postgresql-10.service
Por fim, fazemos login na instância do banco de dados do psql como usuário postgres e alteramos a senha.
# su - postgres -bash-4.2$ psql psql (10.12) Type "help" for help. postgres=# \password Enter new password: Enter it again: postgres=#
Etapa 2:restaurar bancos de dados de amostra
Para emular um sistema de produção, restauramos dois bancos de dados de amostra em nosso servidor PostgreSQL. Esses bancos de dados estão disponíveis publicamente:
- Pagila : a versão PostgreSQL do popular banco de dados MySQL Sakila
- Chinook : um banco de dados sobre a loja de mídia digital
Etapa 3:criar funções e usuários
Com os bancos de dados criados, criamos duas funções de usuário. Um é chamado de “human_user”, o outro é chamado de “app_user”.
A função human_user representa qualquer pessoa acessando o banco de dados a partir do back-end ou com uma ferramenta cliente. A função app_user representa a conta que um aplicativo usará para se conectar ao banco de dados.
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>';"
As funções de usuário recebem permissão para acessar os bancos de dados chinook e pagila executando os seguintes comandos como usuário 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;"
Etapa 4:Instalando o Firewall do SQL
A instalação do SQL Firewall é um processo simples. Primeiro, instalamos o pacote.
# 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%]
Em seguida, atualizamos o arquivo postgresql.conf alterando o parâmetro shared_preload_libraries.
shared_preload_libraries = 'sqlfirewall'
Feito isso, reiniciamos o serviço PostgreSQL.
# systemctl restart postgresql-10.service
Depois que o serviço é reiniciado, efetuamos login na instância como o usuário postgres e adicionamos a extensão a ambos os bancos de dados de amostra.
$ 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
A imagem abaixo mostra as extensões instaladas em ambos os bancos de dados. Observe como existe um esquema especial chamado “sqlfirewall” também criado em ambos os bancos de dados. Este esquema contém todos os objetos de banco de dados relacionados à operação do SQL Firewall.
Também podemos ver que uma nova função chamada “sqlfirewall_manager” é criada automaticamente. Os usuários adicionados a essa função podem acessar funções e exibições no esquema sqlfirewall.
Etapa 5:configurando o firewall do SQL
Vários parâmetros são então adicionados ao postgresql.conf Arquivo. Para Red Hat Enterprise Linux e suas distribuições derivadas, o local do diretório padrão para este arquivo é /var/lib/pgsql/10/data/.
No trecho de código a seguir, estamos editando o arquivo e adicionando vários parâmetros.
# vim /var/lib/pgsql/10/data/postgresql.conf sqlfirewall.whitelist = 'verbose' sqlfirewall.track = 'all' sqlfirewall.track_utility = 'true' sqlfirewall.save = 'true'
Em seguida, recarregamos toda a configuração.
$ 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)
Em seguida, deixamos o processo dormir por um segundo.
postgres=# SELECT pg_sleep(1); pg_sleep ---------- (1 row)
e, em seguida, verifique o status da lista de permissões em ambos os bancos de dados. Se as etapas foram seguidas, ambos os bancos de dados devem ter a lista de permissões habilitada.
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)
Vamos passar pelos parâmetros que acabamos de adicionar.
A sqlfirewall.whitelist O parâmetro é usado para habilitar a funcionalidade de lista de permissões do firewall. Este parâmetro pode ter dois valores:“verbose” ou “protect”.
Com a opção detalhada, o SQL Firewall mostrará uma mensagem de aviso ao usuário quando ele tentar executar uma consulta não incluída na lista de permissões, informando que ele não tem permissão para fazê-lo. Quando o valor estiver definido como protegido, o SQL Firewall mostrará uma mensagem genérica de “permissão negada”. Como prática recomendada, recomendamos definir o valor como “proteger”, o que não dá ao hacker nenhuma ideia de por que o comando foi rejeitado. Definimos este parâmetro como “verbose” apenas para fins de demonstração.
Os valores atribuídos ao sqlfirewall.track e o sqlfirewall.track_utility parâmetros garantem que o SQL Firewall esteja rastreando todas as instruções para fins de lista de permissões.
Por fim, definindo o sqlfirewall.save parâmetro para “true” garante que as instruções da lista de permissões sejam mantidas mesmo se o servidor for reinicializado.
Executando o Firewall do SQL
A execução do SQL Firewall envolve a chamada de várias funções que acompanham a extensão.
Etapa 1:Noções básicas sobre as funções do firewall do SQL
A extensão SQL Firewall cria uma série de funções no esquema sqlfirewall do banco de dados onde está instalado. A maioria dessas funções pode ser executada apenas por superusuários ou membros da função sqlfirewall_manager.
Vamos passar rapidamente por algumas dessas funções.
sqlfirewall_whitelist_mode é a função principal com a qual trabalharemos. Esta função habilita a lista de permissões de instruções para um determinado usuário do PostgreSQL. São necessários dois parâmetros:um é o nome de usuário, o outro é o whitelist_mode.
O modo_lista de permissões parâmetro pode ter três valores:
- Quando estiver definido como “RECORD ”, o SQL Firewall registrará todas as instruções executadas pelo usuário na lista de permissões do usuário
- Quando definido como “ENFORCE ”, o SQL Firewall aplicará a lista de permissões. Qualquer declaração não incluída na lista branca causará um erro
- O valor de “OFF ” desativa a funcionalidade de lista de permissões para o usuário, e o usuário não poderá executar nenhuma consulta
Se você deseja remover as consultas da lista de permissões de um usuário, execute o sqlfirewall_whitelist_delete função em vez disso. Esta função recebe um único parâmetro:o nome de usuário. Uma vez executada, a função sqlfirewall_whitelist_delete remove todas as instruções da lista de permissões para o usuário.
A sqlfirewall_whitelist_delete_entry A função é usada para remover IDs de consulta individuais da lista de permissões de um usuário. Isso pode ser útil quando você tem muitas consultas permitidas para um usuário e deseja ajustá-las. A função recebe dois parâmetros:o nome de usuário e o ID da consulta. Você pode encontrar o ID da consulta que deseja excluir da lista de permissões examinando a exibição sqlfirewall.
Os sqlfirewall_whitelist_users função não recebe nenhum parâmetro. Ele retorna uma lista de usuários que têm a lista de permissões habilitada para sua conta.
Você pode exportar a lista de permissões para um usuário usando o sqlfirewall_whitelist_export função. Essa função recebe dois parâmetros:o nome de usuário e o nome do arquivo para o qual exporta as instruções do usuário na lista de permissões. O arquivo deve estar em um local onde o processo do servidor PostgreSQL tenha acesso de gravação.
Semelhante à função sqlfirewall_whitelist_export, a função sqlfirewall_whitelist_import é usado para importar um arquivo de lista branca exportado de um usuário para uma instância diferente do PostgreSQL para esse usuário. Essa função também recebe dois parâmetros, o nome de usuário e o arquivo a ser importado. O arquivo deve estar em um local onde o processo do servidor PostgreSQL possa lê-lo.
Além disso, o banco de dados de destino precisa ser uma cópia binária do banco de dados de origem – ou seja, o destino deve fazer parte de uma replicação de streaming ou de uma instância do PostgreSQL criada a partir de uma origem com o comando pg_basebackup. Bancos de dados criados a partir de um dump lógico do banco de dados de origem não podem importar o arquivo de lista branca – nesses casos, a lista branca deve ser configurada manualmente.
Etapa 2:habilitar a lista de permissões para usuários
Agora que temos algumas ideias sobre as funções do SQL Firewall, vamos iniciar o processo de lista de permissões para o human_user e o app_user nos bancos de dados pagila e chinook.
No trecho de código abaixo, estamos executando os comandos a seguir como o superusuário 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) Também podemos confirmar executando a função 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)
Etapa 3:executando uma carga de trabalho
Com a lista de permissões habilitada e gravada, mudamos para a conta app_user e executamos algumas consultas conforme mostrado abaixo. Observe como o app_user está selecionando vários “campos de ID” (customer_id, staff_id, EmployeeID, etc.) de diferentes tabelas.
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"; ...
Em seguida, mudamos para a conta human_user e executamos algumas consultas simples em algumas das tabelas que o app_user acessou.
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 consultarmos a visualização sqlfirewall de qualquer um dos bancos de dados como o usuário postgres, poderemos ver as consultas que foram permitidas para cada usuário.
Etapa 4:aplicando a lista de permissões
Com uma carga de trabalho de amostra agora capturada, aplicamos a lista de permissões para ambas as contas de usuário em ambos os bancos de dados executando os comandos a seguir. Os comandos devem ser executados por um superusuário; neste caso, estamos executando-os como o usuário 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) Etapa 5:Teste
Para testar a lista de permissões, efetuamos login no banco de dados pagila como human_user e tentamos executar os comandos que foram executados 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; ...
Os comandos são bem-sucedidos. Isso ocorre porque esses comandos foram executados pelo human_user antes e foram incluídos na lista de permissões.
Agora tentamos executar o seguinte comando. Observe como o human_user está tentando executar uma consulta com dois campos extras. Esta consulta foi executada pelo app_user antes.
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
A instrução falha com uma mensagem como esta:
ERROR: Execution of non-whitelisted statement prohibited
Isso está acontecendo porque o human_user executou anteriormente um comando para selecionar apenas dois campos desta tabela, não os campos extras (ID do pagamento e ID do cliente) que ele está tentando acessar agora. O SQL Firewall registrou sua consulta anterior como uma carga de trabalho conhecida e colocou essa consulta na lista de permissões. Enquanto ele tenta adicionar esses dois novos campos em sua consulta, o firewall o está bloqueando.
Se você pensar bem, é assim que um hacker pode querer roubar um valor de campo de ID para que possa ser usado na cláusula WHERE de outra consulta para obter mais informações. Usar um método de lista de permissões efetivamente bloqueia isso.
Então, o que acontece se o usuário precisar desses dois campos extras para fins legítimos? Nesse caso, o modo de lista de permissões do usuário precisa ser alterado novamente para "RECORD" novamente para que as novas consultas possam ser executadas e o SQL Firewall possa colocá-las na lista de permissões.
Vamos fazer outro teste antes de encerrarmos. Desta vez, vamos supor que um hacker tenha comprometido a conta app_user e queira executar uma declaração de exclusão na tabela "pagamento". Lembre-se de que concedemos ao usuário os privilégios DELETE e TRUNCATE na tabela.
Então, efetuamos login como app_user e executamos uma instrução 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
Conclusão
A declaração é negada porque não está na lista de permissões. Mesmo quando o usuário tem o direito de excluir dados da tabela, o SQL Firewall o bloqueou corretamente.
Como você pode ver, o SQL Firewall é uma poderosa ferramenta de segurança. Possui recursos de segurança que permitem que seja usado em modo de pseudoprodução. Nesse modo, um usuário de teste pode ser configurado para ter suas instruções na lista de permissões e, em seguida, a funcionalidade pode ser testada.
DBAs e administradores de sistema, no entanto, precisam estar atentos a alguns pontos:
Em primeiro lugar, quando o modo de lista de permissões de um usuário é definido como “RECORD”, o SQL Firewall não impede que o usuário execute nenhuma consulta. Em outras palavras, o SQL Firewall precisa ser treinado antes de bloquear um usuário. É por isso que é importante garantir que os privilégios normais de acesso ao banco de dados também sejam aplicados a qualquer conta de usuário. Isso é ainda mais importante porque os membros das funções superusuário e sqlfirewall_manager estão isentos das regras de firewall. O SQL Firewall não substitui a segurança de banco de dados existente – existe para complementá-la.
Em segundo lugar, ao incluir instruções SELECT, INSERT, UPDATE e DELETE individuais na lista de permissões, o SQL Firewall tratará os nomes de objetos usados nesses comandos escritos em maiúsculas e minúsculas (maiúsculas, mistas ou minúsculas) da mesma forma. Todos os outros comandos serão comparados com base nas strings de consulta textuais. Assim, por exemplo, o SQL Firewall tratará “BEGIN” e “begin” e “Begin” como parte de consultas separadas.
Terceiro, a lista de permissões do SQL Firewall não é replicada automaticamente para nós em espera em um ambiente de replicação. No entanto, você pode exportar listas brancas usando a função sqlfirewall_whitelist_export e importá-las para outro servidor usando a função sqlfirewall_whitelist_import. Infelizmente, fazer backup do banco de dados ou do esquema sqlfirewall e restaurar na instância de destino não funcionará. Além disso, o servidor de destino precisa ter a mesma conta de usuário presente para que a lista de permissões seja útil.
É preciso considerar cuidadosamente todos os tipos possíveis de consultas que um usuário pode realizar em um banco de dados e executar a lista de permissões no modo “RECORD” pelo tempo necessário para capturar todas as cargas de trabalho normais. Pouca captura pode impedir que uma conta de usuário execute consultas legítimas, enquanto a gravação por muito tempo pode adicionar comandos desnecessariamente à lista de permissões. Isso pode causar atrasos no SQL Firewall ao comparar instruções no modo de imposição.
