Mysql
 sql >> база данни >  >> RDS >> Mysql

Разбиране на дневника за одит на ProxySQL

ProxySQL се превърна в много важна част от инфраструктурата в среди на база данни. Той работи като балансьор на натоварването, помага за оформянето на потока на трафика и намалява времето на престой. С голяма сила идва и голяма отговорност. Как можете да сте в течение за това кой има достъп до конфигурацията на ProxySQL? Кой се свързва с базата данни чрез ProxySQL? На тези въпроси може да се отговори с помощта на ProxySQL Audit Log, който е наличен от ProxySQL 2.0.5. В тази публикация в блога ще разгледаме как да активираме тази функция и как изглежда съдържанието на журнала.

Първоначалните стъпки ще бъдат внедряване на ProxySQL. Можем лесно да направим това с помощта на ClusterControl – както MySQL Replication, така и типовете Galera Cluster поддържат внедряване на ProxySQL.

Ако приемем, че имаме работещ клъстер, можем да внедрим ProxySQL от Manage -> LoadBalancers:

Трябва да решим кой възел да бъде инсталиран ProxySQL, неговата версия ( ще запазим 2.x по подразбиране и ще дефинираме идентификационни данни за потребители с администриране и наблюдение на ProxySQL.

По-долу можем да импортираме съществуващи потребители на приложението от базата данни или да създадем ново един чрез присвояване на име, парола, схема и MySQL привилегии. След това можем да конфигурираме кои възли трябва да бъдат включени в ProxySQL и да решим дали да използваме неявни транзакции или не. След като всичко е направено, можем да разположим ProxySQL. За висока наличност вероятно искате да добавите втори ProxySQL и след това да поддържате активност върху тях. Keepalived може лесно да се разгърне от ClusterControl:

Тук трябва да изберем възли, на които е разположен ProxySQL, да предадем виртуалния IP и мрежовия интерфейс трябва да бъдат присвоени на VIP. След като това стане, ClusterControl може да внедри Keepalived вместо вас.

Сега нека да разгледаме регистрационния файл за одит. Всички конфигурации трябва да се извършват и на двата ProxySQL възела. Като алтернатива можете да използвате опция за синхронизиране на възлите:

Има две настройки, които управляват как трябва да работи регистрационният файл за одит:

Първият дефинира файла, където трябва да се съхраняват данните, вторият казва колко голям трябва да бъде регистрационният файл, преди да се завърти. Нека конфигурираме вход в директорията с данни на ProxySQL:

Сега можем да разгледаме данните, които виждаме при одита лог файл. На първо място, форматът, в който се съхраняват данните, е JSON. Има два типа събития, едното е свързано с MySQL свързаността, а второто е свързано със свързването на ProxySQL администраторския интерфейс.

Ето пример за записи, задействани от 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"

}

Както можете да видите, повечето данни се повтарят:адрес на клиента, адрес на ProxySQL, име на схема, ако SSL е бил използван във връзките, номер на свързаната нишка в MySQL, потребител, създал връзката. Събитието “MySQL_Client_Close” също съдържа информация за времето, когато е създадена връзката и продължителността на връзката. Можете също да видите коя част от ProxySQL кода е отговорна за затварянето на връзката.

Администраторските връзки са доста сходни:

{

  "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"

}

Събраните данни са много сходни, основната разлика е, че са свързани с връзки към административния интерфейс на ProxySQL.

Заключение

Както можете да видите, по много лесен начин можете да активирате одит на достъпа до ProxySQL. Това, особено административният достъп, е нещо, което трябва да се наблюдава от гледна точка на сигурността. Плъгинът за одит го прави доста лесен за изпълнение.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да инсталирате phpMyAdmin на управлявани хостинг акаунти

  2. Как да попълним дупките в полетата за автоматично увеличение?

  3. Изпълнението на MySQL израза отнема повече от минута

  4. Архивиране на логически бази данни с помощта на MySQL Shell

  5. Функция SUM() в MySQL