Ler o título deste post do blog pode levantar algumas questões. Firewall SQL - o que é isso? O que isso faz? Por que eu precisaria de algo assim em primeiro lugar? Bem, a capacidade de bloquear certas consultas pode ser útil em determinadas situações. Ao usar ProxySQL na frente de seus servidores de banco de dados, o proxy pode inspecionar todas as instruções SQL que estão sendo enviadas. O ProxySQL tem um mecanismo de regras sofisticado e pode corresponder a consultas que devem ser permitidas, bloqueadas, reescritas em tempo real ou roteadas para um servidor de banco de dados específico. Vamos a alguns exemplos.
Você tem um escravo dedicado que é usado pelos desenvolvedores para testar suas consultas em relação aos dados de produção. Você deseja garantir que os desenvolvedores possam se conectar apenas a esse host específico e executar apenas consultas SELECT.
Outro caso, digamos que você encontrou muitos acidentes com pessoas executando alterações de esquema e gostaria de limitar quais usuários podem executar a instrução ALTER.
Por fim, vamos pensar em uma abordagem paranóica na qual os usuários têm permissão para executar apenas um conjunto de consultas pré-definido na lista de permissões.
Em nosso ambiente temos uma configuração de replicação com o master e dois slaves.
Na frente de nossos bancos de dados, temos três nós ProxySQL com Keepalived gerenciando o IP Virtual. Também temos o cluster ProxySQL configurado (conforme explicado neste blog anterior) para que não precisemos nos preocupar em fazer alterações de configuração ou regra de consulta três vezes em todos os três nós ProxySQL. Para as regras de consulta, uma divisão simples de leitura e gravação é configurada:
Vamos dar uma olhada em como o ProxySQL, com seu extenso mecanismo de regras de consulta, pode nos ajudar a atingir nossos objetivos em todos esses três casos.
Bloqueando o acesso do usuário a um único grupo de hosts
Um escravo dedicado disponível para desenvolvedores - esta não é uma prática incomum. Contanto que seus desenvolvedores possam acessar dados de produção (e se eles não forem permitidos, por exemplo, por motivos de conformidade, o mascaramento de dados, conforme explicado em nosso tutorial ProxySQL, pode ajudar), isso pode ajudá-los a testar e otimizar consultas nos dados do mundo real definir. Também pode ajudar a verificar os dados antes de executar algumas das alterações de esquema. Por exemplo, minha coluna é realmente exclusiva antes de adicionar um índice exclusivo?
Com ProxySQL é bastante fácil restringir o acesso. Para começar, vamos supor que o hostgroup 30 contém o escravo que queremos que os desenvolvedores acessem.
Precisamos de um usuário que será usado pelos desenvolvedores para acessar esse escravo. Se você já o possui no ProxySQL, tudo bem. Caso contrário, você pode precisar importá-lo para o ProxySQL (se for criado no MySQL, mas não no ProxySQL) ou criá-lo em ambos os locais (se for criar um novo usuário). Vamos com a última opção, criando um novo usuário.
Vamos criar um novo usuário com privilégios limitados no MySQL e no ProxySQL. Vamos usá-lo nas regras de consulta para identificar o tráfego proveniente dos desenvolvedores.
Nesta regra de consulta vamos redirecionar todas as consultas que são executadas pelo usuário dev_test para o hostgroup 30. Queremos que esta regra esteja ativa e deve ser a última a ser analisada, portanto habilitamos 'Aplicar'. Também configuramos RuleID para ser menor que o ID da primeira regra existente, pois queremos que essa consulta seja executada fora da configuração de divisão de leitura/gravação regular.
Como você pode ver, usamos um nome de usuário, mas também existem outras opções.
Se você puder prever quais hosts de desenvolvimento enviarão o tráfego para o banco de dados (por exemplo, você pode fazer com que os desenvolvedores usem um proxy específico antes que eles possam acessar o banco de dados), você também pode usar a opção "Endereço do cliente" para corresponder às consultas executadas por esse único host e redirecioná-los para um hostgroup correto.
Proibindo que o usuário execute determinadas consultas
Agora, vamos considerar o caso em que queremos limitar a execução de alguns comandos específicos a um determinado usuário. Isso pode ser útil para garantir que as pessoas certas possam executar algumas das consultas que afetam o desempenho, como alterações de esquema. ALTER será a consulta que usaremos neste exemplo. Para começar, vamos adicionar um novo usuário que terá permissão para executar alterações de esquema. Vamos chamá-lo de ‘admin_user’. Em seguida, precisamos criar as regras de consulta necessárias.
Criaremos uma regra de consulta que usa a expressão regular '.*ALTER TABLE.*' para corresponder às consultas. Esta regra de consulta deve ser executada antes de outras regras de divisão de leitura/gravação. Atribuímos um ID de regra de 20 a ele. Definimos uma mensagem de erro que será retornada ao cliente caso esta regra de consulta seja acionada. Uma vez feito, passamos para outra regra de consulta.
Aqui usamos a mesma expressão regular para capturar a consulta, mas não definimos nenhum texto de erro (o que significa que a consulta não retornará um erro). Também definimos qual usuário tem permissão para executá-lo (admin_user no nosso caso). Garantimos que essa consulta seja verificada antes da anterior, por isso atribuímos um ID de regra menor de 19 a ela.
Depois que essas duas regras de consulta estiverem em vigor, podemos testar como elas funcionam. Vamos tentar fazer login como usuário do aplicativo e executar uma consulta ALTER TABLE:
[email protected]:~# mysql -P6033 -usbtest -ppass -h10.0.0.111
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43160
Server version: 5.5.30 (ProxySQL)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use sbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> alter table sbtest1 add index (pad);
ERROR 1148 (42000): You are not allowed to execute ALTER
mysql> ^DByeComo esperado, não conseguimos executar esta consulta e recebemos uma mensagem de erro. Vamos agora tentar conectar usando nosso ‘admin_user’:
[email protected]:~# mysql -P6033 -uadmin_user -ppass -h10.0.0.111
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43180
Server version: 5.5.30 (ProxySQL)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use sbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> alter table sbtest1 add index (pad);
Query OK, 0 rows affected (0.99 sec)
Records: 0 Duplicates: 0 Warnings: 0Conseguimos executar o ALTER quando entramos usando ‘admin_user’. Essa é uma maneira muito simples de garantir que apenas pessoas designadas possam executar alterações de esquema em seus bancos de dados.
Criando uma lista de permissões de consultas permitidas
Por fim, vamos considerar um ambiente fortemente bloqueado onde apenas consultas predefinidas podem ser executadas. O ProxySQL pode ser facilmente utilizado para implementar tal configuração.
Em primeiro lugar, precisamos remover todas as regras de consulta existentes antes de podermos implementar o que precisamos. Em seguida, precisamos criar uma regra de consulta catch-all, que bloqueará todas as consultas:
O resto que temos que fazer é criar regras de consulta para todas as consultas permitidas. Você pode fazer uma regra por consulta. Ou você pode usar expressões regulares se, por exemplo, SELECTs estiverem sempre ok para serem executados. A única coisa que você precisa lembrar é que o ID da regra deve ser menor que o ID da regra desta regra abrangente e garantir que a consulta acabe atingindo a regra com 'Aplicar' ativado.
Esperamos que esta postagem de blog tenha lhe dado algumas dicas sobre como você pode utilizar o ClusterControl e o ProxySQL para melhorar a segurança e garantir a conformidade de seus bancos de dados.
