Четенето на заглавието на тази публикация в блога може да породи някои въпроси. SQL защитна стена - какво е това? Какво прави? Защо ми трябва нещо подобно на първо място? Е, възможността за блокиране на определени заявки може да бъде полезна в определени ситуации. Когато използвате ProxySQL пред вашите сървъри на база данни, проксито може да инспектира всички изпратени SQL изрази. ProxySQL има усъвършенстван механизъм за правила и може да съответства на заявки, които трябва да бъдат разрешени, блокирани, пренаписани в движение или пренасочени към конкретен сървър на база данни. Нека да преминем през някои примери.
Имате специално подчинено устройство, което се използва от разработчиците за тестване на техните заявки спрямо производствени данни. Искате да сте сигурни, че разработчиците могат да се свързват само с този конкретен хост и да изпълняват само SELECT заявки.
Друг случай, да кажем, че сте срещнали твърде много инциденти с хора, изпълняващи промени в схемата, и бихте искали да ограничите кои потребители могат да изпълняват оператор ALTER.
И накрая, нека помислим за параноичен подход, при който на потребителите е позволено да изпълняват само предварително дефиниран набор от заявки от белия списък.
В нашата среда имаме настройка за репликация с главен и два подчинени.
Пред нашите бази данни имаме три ProxySQL възела с Keepalived, управляващ виртуален IP. Също така имаме конфигуриран ProxySQL клъстер (както е обяснено в този предишен блог), така че не е нужно да се притесняваме да правим промени в конфигурацията или правилата за заявка три пъти на всичките три възела на ProxySQL. За правилата на заявката е настроено просто разделяне на четене-запис:
Нека да разгледаме как ProxySQL, със своя разширен механизъм за правила за заявки, може да ни помогне да постигнем целите си и в тези три случая.
Заключване на потребителския достъп до една хост група
Специален роб, достъпен за разработчиците - това не е необичайна практика. Докато вашите разработчици имат достъп до производствени данни (и ако не им е позволено, например поради причини за съответствие, маскирането на данни, както е обяснено в нашия урок за ProxySQL, може да им помогне), това може да им помогне да тестват и оптимизират заявки за реалните данни комплект. Може също да помогне за проверка на данните, преди да изпълните някои от промените в схемата. Например моята колона наистина ли е уникална, преди да добавя уникален индекс?
С ProxySQL е сравнително лесно да ограничите достъпа. Като начало, нека приемем, че хостгрупата 30 съдържа подчинения, до който искаме разработчиците да имат достъп.
Нуждаем се от потребител, който ще бъде използван от разработчиците за достъп до този подчинен. Ако вече го имате в ProxySQL, това е добре. Ако не, може да се наложи или да го импортирате в ProxySQL (ако е създаден в MySQL, но не и в ProxySQL) или да го създадете на двете места (ако ще създавате нов потребител). Нека преминем към последната опция, създаване на нов потребител.
Нека създадем нов потребител с ограничени привилегии както в MySQL, така и в ProxySQL. Ще го използваме в правилата за заявки, за да идентифицираме трафика, идващ от разработчиците.
В това правило за заявка ще пренасочим всички заявки, които се изпълняват от потребителя на dev_test към хостгрупа 30. Искаме това правило да е активно и трябва да бъде последното за анализиране, затова активирахме „Прилагане“. Също така конфигурирахме RuleID да бъде по-малък от идентификатора на първото съществуващо правило, тъй като искаме тази заявка да се изпълнява извън обикновената настройка за разделяне на четене/запис.
Както можете да видите, използвахме потребителско име, но има и други опции.
Ако можете да предвидите кои хостове за разработка ще изпращат трафика към базата данни (например, можете да накарате разработчиците да използват конкретен прокси, преди да могат да достигнат до базата данни), можете също да използвате опцията „Адрес на клиента“, за да съпоставите заявки, изпълнени от това един хост и ги пренасочва към правилна хост група.
Забрана на потребителя да изпълнява определени заявки
Сега, нека разгледаме случая, когато искаме да ограничим изпълнението на някои конкретни команди до даден потребител. Това може да е удобно, за да се гарантира, че правилните хора могат да изпълняват някои от заявките, които влияят на производителността, като промени в схемата. ALTER ще бъде заявката, която ще използваме в този пример. Като начало, нека добавим нов потребител, на който ще бъде разрешено да изпълнява промени в схемата. Ще го наречем „admin_user“. След това трябва да създадем необходимите правила за заявка.
Ще създадем правило за заявка, което използва регулярен израз „.*ALTER TABLE.*“, за да съответства на заявките. Това правило за заявка трябва да се изпълни преди други правила за разделяне на четене/запис. Присвоихме му идентификатор на правило 20. Дефинираме съобщение за грешка, което ще бъде върнато на клиента, в случай че това правило за заявка бъде задействано. След като приключим, преминаваме към друго правило за заявка.
Тук използваме същия регулярен израз за улавяне на заявката, но не дефинираме никакъв текст за грешка (което означава, че заявката няма да върне грешка). Ние също така дефинираме кой потребител има право да го изпълни (admin_user в нашия случай). Уверяваме се, че тази заявка е проверена преди предишната, затова й присвоихме по-нисък идентификатор на правило от 19.
След като тези две правила за заявка са в сила, можем да тестваме как работят. Нека се опитаме да влезем като потребител на приложение и да изпълним заявка 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> ^DByeКакто се очакваше, не можахме да изпълним тази заявка и получихме съобщение за грешка. Нека сега се опитаме да се свържем с помощта на нашия „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: 0Успяхме да изпълним ALTER, докато влязохме с помощта на „admin_user“. Това е много прост начин да се гарантира, че само назначени хора могат да извършват промени в схемите във вашите бази данни.
Създаване на бял списък с разрешени заявки
И накрая, нека разгледаме плътно заключена среда, в която могат да се изпълняват само предварително дефинирани заявки. ProxySQL може лесно да се използва за прилагане на такава настройка.
На първо място, трябва да премахнем всички съществуващи правила за заявка, преди да можем да приложим това, от което се нуждаем. След това трябва да създадем правило за всички заявки, което ще блокира всички заявки:
Останалото, което трябва да направим, е да създадем правила за заявки за всички разрешени заявки. Можете да направите едно правило на заявка. Или можете да използвате регулярни изрази, ако например SELECT винаги може да се изпълнява. Единственото нещо, което трябва да запомните, е, че идентификационният номер на правилото трябва да бъде по-малък от идентификатора на правилото на това всеобхватно правило и да се уверите, че в крайна сметка заявката ще удари правилото с активирано „Прилагане“.
Надяваме се, че тази публикация в блога ви даде известна представа за това как можете да използвате ClusterControl и ProxySQL, за да подобрите сигурността и да осигурите съответствие на вашите бази данни.
