ProxySQL tornou-se uma infraestrutura muito importante nos ambientes de banco de dados. Funciona como um balanceador de carga, ajuda a moldar o fluxo do tráfego e reduzir o tempo de inatividade. Com grandes poderes vem grandes responsabilidades. Como você pode se manter atualizado sobre quem está acessando a configuração do ProxySQL? Quem está se conectando ao banco de dados por meio do ProxySQL? Essas perguntas podem ser respondidas usando o ProxySQL Audit Log, que está disponível a partir do ProxySQL 2.0.5. Nesta postagem do blog, veremos como habilitar esse recurso e como é o conteúdo do log.
As etapas iniciais serão implantar o ProxySQL. Podemos fazer isso facilmente usando o ClusterControl - os tipos MySQL Replication e Galera Cluster suportam a implantação do ProxySQL.
Supondo que tenhamos um cluster em execução, podemos implantar o ProxySQL em Manage -> LoadBalancers:
Temos que decidir em qual nó o ProxySQL deve ser instalado, sua versão ( manteremos o padrão 2.x) e definiremos credenciais para usuários administrativos e de monitoramento do ProxySQL.
Abaixo podemos importar usuários de aplicativos existentes do banco de dados ou criar um novo um atribuindo nome, senha, esquema e privilégios MySQL. Podemos então configurar quais nós devem ser incluídos no ProxySQL e decidir se usamos transações implícitas ou não. Depois que tudo estiver pronto, podemos implantar o ProxySQL. Para alta disponibilidade, você provavelmente deseja adicionar um segundo ProxySQL e, em seguida, manter a atividade em cima deles. Keepalived também pode ser facilmente implantado a partir do ClusterControl:
Aqui temos que escolher os nós nos quais o ProxySQL é implantado, passe o Virtual IP e interface de rede VIP devem ser atribuídos. Feito isso, o ClusterControl pode implantar o Keepalived para você.
Agora, vamos dar uma olhada no log de auditoria. Todas as configurações devem ser executadas em ambos os nós ProxySQL. Como alternativa, você pode usar uma opção para sincronizar os nós:
Há duas configurações que determinam como o log de auditoria deve funcionar:
O primeiro define o arquivo onde os dados devem ser armazenados, o segundo informa quão grande o arquivo de log deve ser antes de ser girado. Vamos configurar o log no diretório de dados do ProxySQL:
Agora, podemos dar uma olhada nos dados que vemos na auditoria arquivo de log. Em primeiro lugar, o formato em que os dados são armazenados é JSON. Existem dois tipos de eventos, um relacionado à conectividade do MySQL e o segundo relacionado à conectividade da interface de administração do ProxySQL.
Aqui está um exemplo de entradas acionadas pelo tráfego do MySQL:
"client_addr": "10.0.0.100:40578",
"event": "MySQL_Client_Connect_OK",
"proxy_addr": "0.0.0.0:6033",
"schemaname": "sbtest",
"ssl": false,
"thread_id": 810,
"time": "2020-01-23 14:24:17.595",
"timestamp": 1579789457595,
"username": "sbtest"
}
{
"client_addr": "10.0.0.100:40572",
"event": "MySQL_Client_Quit",
"proxy_addr": "0.0.0.0:6033",
"schemaname": "sbtest",
"ssl": false,
"thread_id": 807,
"time": "2020-01-23 14:24:17.657",
"timestamp": 1579789457657,
"username": "sbtest"
}
{
"client_addr": "10.0.0.100:40572",
"creation_time": "2020-01-23 14:24:17.357",
"duration": "299.653ms",
"event": "MySQL_Client_Close",
"extra_info": "MySQL_Thread.cpp:4307:process_all_sessions()",
"proxy_addr": "0.0.0.0:6033",
"schemaname": "sbtest",
"ssl": false,
"thread_id": 807,
"time": "2020-01-23 14:24:17.657",
"timestamp": 1579789457657,
"username": "sbtest"
}
Como você pode ver, a maioria dos dados se repete:endereço do cliente, endereço ProxySQL, nome do esquema, se SSL foi usado nas conexões, número da thread relacionada no MySQL, usuário que criou a conexão. O evento “MySQL_Client_Close” também contém informações sobre a hora em que a conexão foi criada e a duração da conexão. Você também pode ver qual parte do código ProxySQL foi responsável por fechar a conexão.
As conexões de administrador são bastante semelhantes:
{
"client_addr": "10.0.0.100:52056",
"event": "Admin_Connect_OK",
"schemaname": "information_schema",
"ssl": false,
"thread_id": 815,
"time": "2020-01-23 14:24:19.490",
"timestamp": 1579789459490,
"username": "proxysql-admin"
}
{
"client_addr": "10.0.0.100:52056",
"event": "Admin_Quit",
"schemaname": "information_schema",
"ssl": false,
"thread_id": 815,
"time": "2020-01-23 14:24:19.494",
"timestamp": 1579789459494,
"username": "proxysql-admin"
}
{
"client_addr": "10.0.0.100:52056",
"creation_time": "2020-01-23 14:24:19.482",
"duration": "11.795ms",
"event": "Admin_Close",
"extra_info": "MySQL_Thread.cpp:3123:~MySQL_Thread()",
"schemaname": "information_schema",
"ssl": false,
"thread_id": 815,
"time": "2020-01-23 14:24:19.494",
"timestamp": 1579789459494,
"username": "proxysql-admin"
}
Os dados coletados são muito semelhantes, a principal diferença é que estão relacionados a conexões com a interface administrativa do ProxySQL.
Conclusão
Como você pode ver, de uma maneira muito fácil você pode habilitar a auditoria do acesso ao ProxySQL. Isso, principalmente o acesso administrativo, é algo que deve ser monitorado do ponto de vista da segurança. O plug-in de auditoria facilita bastante a realização.