Att läsa rubriken på det här blogginlägget kan väcka några frågor. SQL-brandvägg - vad är det? Vad gör den? Varför skulle jag behöva något sådant från början? Tja, möjligheten att blockera vissa frågor kan vara praktiskt i vissa situationer. När du använder ProxySQL framför dina databasservrar kan proxyn inspektera alla SQL-satser som skickas. ProxySQL har en sofistikerad regelmotor och kan matcha frågor som ska tillåtas, blockeras, skrivas om i farten eller dirigeras till en specifik databasserver. Låt oss gå igenom några exempel.
Du har en dedikerad slav som används av utvecklare för att testa sina frågor mot produktionsdata. Du vill försäkra dig om att utvecklarna bara kan ansluta till den specifika värden och endast köra SELECT-frågor.
Ett annat fall, låt oss säga att du råkade ut för en olycka för många med personer som körde schemaändringar och du skulle vilja begränsa vilka användare som kan köra ALTER-satsen.
Låt oss slutligen tänka på ett paranoid tillvägagångssätt där användare tillåts utföra bara en fördefinierad vitlistad uppsättning frågor.
I vår miljö har vi en replikeringsinställning med mastern och två slavar.
Framför våra databaser har vi tre ProxySQL-noder med Keepalived som hanterar virtuell IP. Vi har också ProxySQL-kluster konfigurerat (som förklarats i denna tidigare blogg) så vi behöver inte oroa oss för att göra konfigurations- eller frågeregeländringar tre gånger på alla tre ProxySQL-noderna. För frågereglerna ställs en enkel läs-skriv-delning upp:
Låt oss ta en titt på hur ProxySQL, med dess omfattande frågereglermekanism, kan hjälpa oss att uppnå våra mål i alla dessa tre fall.
Låser användaråtkomst till en enda värdgrupp
En dedikerad slav tillgänglig för utvecklare - detta är inte ovanligt. Så länge som dina utvecklare kan komma åt produktionsdata (och om de inte tillåts, t.ex. på grund av efterlevnadsskäl, kan datamaskering som förklaras i vår ProxySQL-handledning hjälpa dem), kan detta hjälpa dem att testa och optimera frågor om den verkliga världens data uppsättning. Det kan också hjälpa att verifiera data innan du utför några av schemaändringarna. Till exempel, är min kolumn verkligen unik innan jag lägger till ett unikt index?
Med ProxySQL är det ganska enkelt att begränsa åtkomsten. Till att börja med, låt oss anta att värdgruppen 30 innehåller den slav som vi vill att utvecklare ska få tillgång till.
Vi behöver en användare som kommer att användas av utvecklarna för att komma åt den slaven. Om du redan har det i ProxySQL är det bra. Om inte kan du antingen behöva importera den till ProxySQL (om den är skapad i MySQL men inte i ProxySQL) eller skapa den på båda platserna (om du ska skapa en ny användare). Låt oss gå med det sista alternativet, skapa en ny användare.
Låt oss skapa en ny användare med begränsade privilegier på både MySQL och ProxySQL. Vi kommer att använda det i frågeregler för att identifiera trafik som kommer från utvecklarna.
I den här frågeregeln kommer vi att omdirigera alla frågor som exekveras av dev_test-användaren till värdgruppen 30. Vi vill att denna regel ska vara aktiv och den ska vara den sista att analysera, därför aktiverade vi 'Apply'. Vi konfigurerade också RuleID att vara mindre än ID:t för den första existerande regeln eftersom vi vill att den här frågan ska köras utanför den vanliga läs/skrivdelningskonfigurationen.
Som du kan se använde vi ett användarnamn men det finns också andra alternativ.
Om du kan förutsäga vilka utvecklingsvärdar som kommer att skicka trafiken till databasen (du kan till exempel låta utvecklare använda en specifik proxy innan de kan nå databasen), kan du också använda alternativet "Client Address" för att matcha frågor som körs av den enda värd och omdirigera dem till en korrekt värdgrupp.
Tillåt användaren att utföra vissa frågor
Låt oss nu överväga fallet där vi vill begränsa exekvering av vissa speciella kommandon till en given användare. Detta kan vara praktiskt för att säkerställa att rätt personer kan köra en del av de prestandapåverkande frågor som schemaändringar. ALTER kommer att vara frågan som vi kommer att använda i det här exemplet. Till att börja med, låt oss lägga till en ny användare som kommer att tillåtas köra schemaändringar. Vi kommer att kalla det "admin_user". Därefter måste vi skapa de nödvändiga frågereglerna.
Vi kommer att skapa en frågeregel som använder det reguljära uttrycket '.*ALTER TABLE.*' för att matcha frågorna. Denna frågeregel bör köras före andra läs/skrivdelade regler. Vi tilldelade ett regel-ID på 20 till den. Vi definierar ett felmeddelande som kommer att returneras till klienten om denna frågeregel kommer att utlösas. När vi är klara fortsätter vi till en annan frågeregel.
Här använder vi samma reguljära uttryck för att fånga frågan men vi definierar ingen feltext (vilket betyder att frågan inte returnerar ett fel). Vi definierar också vilken användare som får köra det (admin_user i vårt fall). Vi ser till att den här frågan kontrolleras före den föregående, så vi tilldelade den ett lägre regel-ID på 19.
När dessa två frågeregler är på plats kan vi testa hur de fungerar. Låt oss försöka logga in som en applikationsanvändare och köra en ALTER TABLE-fråga:
[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> ^DByeSom förväntat kunde vi inte köra den här frågan och vi fick ett felmeddelande. Låt oss nu försöka ansluta med vår "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: 0Vi lyckades utföra ALTER när vi loggade in med "admin_user". Detta är ett mycket enkelt sätt att säkerställa att endast utsedda personer kan köra schemaändringar på dina databaser.
Skapa en vitlista med tillåtna frågor
Slutligen, låt oss överväga en hårt låst miljö där endast fördefinierade frågor kan köras. ProxySQL kan enkelt användas för att implementera en sådan installation.
Först och främst måste vi ta bort alla befintliga frågeregler innan vi kan implementera det vi behöver. Sedan måste vi skapa en catch-all-frågeregel, som blockerar alla frågor:
Resten vi måste göra är att skapa frågeregler för alla frågor som är tillåtna. Du kan göra en regel per fråga. Eller så kan du använda reguljära uttryck om till exempel SELECT alltid är ok att köra. Det enda du behöver komma ihåg är att regel-ID:t måste vara mindre än regel-ID för denna catch-all-regel, och se till att frågan så småningom kommer att träffa regeln med "Apply" aktiverat.
Vi hoppas att det här blogginlägget gav dig lite insikt i hur du kan använda ClusterControl och ProxySQL för att förbättra säkerheten och säkerställa efterlevnad av dina databaser.