Hybridmoln kan vara ett utmärkt sätt att lägga till flexibilitet till dina befintliga installationer på plats. Som vi diskuterade i flera bloggar kan det offentliga molnet vara ett bra tillägg till ditt eget datacenter, vilket säkerställer att du enkelt kan skala ut för att hantera belastningen, minska din capex och användas för att implementera katastrofåterställningsprocedurer. Säkerhet är en annan aspekt du måste tänka igenom när du planerar att bygga sådana system. I det här blogginlägget kommer vi att prata om några av säkerhetsövervägandena för hybridmoln MariaDB-distributioner.
Anslutning
VPN
Största delen av varje hybridinfrastruktur är nätverket. När allt kommer omkring pratar vi om två miljöer, lokal, lokal och ett publikt moln, som måste kopplas ihop och bilda en enhet. Anslutningen måste vara krypterad. Hur man närmar sig det, det finns många sätt att göra det på.
En av dem skulle vara att använda en lösning som görs tillgänglig av molnleverantören - de flesta av dem har något slags anslutningsalternativ tillgängligt. Det kan vara AWS Direct Connect om du råkar integrera med Amazon Web Services. Om du planerar att använda Google Cloud diskuteras lösningar på följande webbplats:https://cloud.google.com/hybrid-connectivity. Kort sagt, det finns ett stort antal olika alternativ som varierar från hårdvaru-VPN-integration till att ställa in BGP-peering.
På andra sidan av spektrumet har vi mjukvarulösningar för VPN. OpenVPN eller liknande mjukvara kan användas för att skapa en säker, krypterad nätverksanslutning mellan ditt eget datacenter och det offentliga molnet. I ett sådant fall skulle du kräva en separat instans som körs i det offentliga molnet som kommer att användas för VPN-servern. Genom att använda VPN-programvara kan du välja den lösning som bäst passar dina krav och passar bäst i din miljö.
Brandvägg
Databaser bör aldrig vara tillgängliga från externa nätverk. Det är ytterst viktigt att bygga din miljö på ett sätt så att databasnivån endast kan nås från den begränsade uppsättningen värdar. Exakt vad som krävs och hur man gör det, det är upp till dig att bestämma. En typisk installation skulle bestå av en säker databasnivå som endast kan nås från proxynivå och, om det behövs, bör någon form av en hoppvärd implementeras om det krävs för automatiserings- och administrationsuppgifter.
Applikationsservrar bör inte ha direkt åtkomst till databasen – de behöver inte. Allt som applikationen behöver göra är att ansluta till lastbalanseraren. Lastbalanserare ska kunna ansluta till databasen. En lastbalanserare som ProxySQL är perfekt kapabel att utföra läs/skrivdelningen och skicka läsningar och skrivningar till rätt databasnoder. Applikationen bör kunna ansluta till ProxySQL och resten kommer att hanteras av proxyn - databasautentisering, trafikformning, distribution av trafiken över många repliker som du kan ha. All onödig åtkomst bör begränsas. Säkerhetsgrupper, brandväggar – det här är verktygen du vill använda för att säkra din miljö.
Kort sagt, åtkomst till databasvärdarna bör endast tillåtas på de portar som krävs. För MariaDB kommer det uppenbarligen att vara en port som används för databasen men även andra portar om det behövs - du kan ha någon sorts exportörer eller agenter installerade. För Galera skulle du behöva öppna portar för kommunikation inom kluster. Du kanske också vill ha en öppen port för SSH-anslutningar. Begränsa helst åtkomsten per värd; endast en begränsad uppsättning värdar kan komma åt en given port. Till exempel kan databasporten vara tillgänglig från de andra databasnoderna, localhost och proxy-lagret. Det finns inget behov av att hålla den öppen för andra noder. Dina databasnoder kan till och med finnas på ett separat undernät, vilket säkerställer att säkerheten är ännu strängare.
När det gäller portar skulle bästa praxis vara att ändra dem från standardinställningarna till något annat. Helst något slumpmässigt. Att ändra SSH-porten från 22 till 2222 eller MariaDB-porten från 3306 till 33306 kan hjälpa till att undvika några av de automatiska attackerna, men det kan fortfarande listas ut om någon aktivt letar efter att komma in i ditt nätverk. Om du vill ha bättre säkerhet kan du bara gå vidare med några slumpmässiga värden. Sätt SSH till 5762 och MariaDB till 24359. Det är ganska troligt att ingen kommer att kunna gissa dem. Ställ in dina TCP-timeout så att portskanningarna blir mycket långa och dyra och det kommer säkerligen att öka dina chanser.
SSL
Förutom VPN och brandvägg bör du se till att din databastrafik är krypterad med SSL.
Helst kommer du att skydda både frontend-anslutningar (från lastbalanserarna) och kommunikationen mellan dina databasnoder (vare sig det är replikering eller intra-klusteröverföring i Galera-kluster). ClusterControl kan hjälpa dig att aktivera dessa alternativ med bara några få klick.
Allt du behöver göra är att låta ClusterControl skapa nya certifikat eller använda ett av de befintliga - du kan importera ditt eget certifikat om du vill. Att ha SSL aktiverat säkerställer att databastrafiken inte är läsbar ens av någon som fått åtkomst till ditt nätverk.
Databassäkerhet
Naturligtvis är nätverket inte den enda viktiga aspekten av säkerhet. Ja, det är kritiskt, särskilt i hybridmolnmiljön, men det finns också andra mycket viktiga aspekter. En av dem är åtkomstkontrollen inbäddad i MariaDB.
Rollbaserad åtkomstkontroll för MariaDB
MariaDB levereras med en uppsättning instrument för att säkerställa att databasåtkomsten hanteras korrekt och begränsas varhelst det behövs. Den första raden av autentisering är användare. Alla och allt som får komma åt MariaDB bör använda en tilldelad användare för att ansluta till databasen. Sådana användare kommer att ha ett korrekt lösenord - du kan ha lösenordsvalideringen aktiverad i MariaDB för att säkerställa att lösenorden är tillräckligt starka. Helst skulle du begränsa användarens åtkomstvärd endast till värdnamn eller IP-adresser för belastningsutjämnare - detta bör alltid vara hur användare ansluter till databasen. För vissa administrativa användare kanske du vill behålla lokalvärdens åtkomst om det behövs. Utöver att upprätthålla rätt lösenordsstyrka kan du konfigurera lösenordet så att det upphör att gälla inom en viss tidsperiod eller framtvinga lösenordsrotation på användarna. Som du kan föreställa dig är en korrekt lösenordsrotationspolicy något du vill ha implementerat.
Varje användare i MariaDB kan ha flera privilegier tilldelade. Privilegier kan tilldelas på flera nivåer - global nivå, databasnivå, tabellnivå eller till och med kolumnnivå. Den bästa praxisen är att bevilja en begränsad uppsättning privilegier till användarna som möjligt. Om användaren bara behöver tillgång till en viss tabell, ge honom bara det. Det finns inget behov för den användaren att komma åt andra tabeller för att inte nämna andra scheman. Du kan definiera ganska detaljerade åtkomsträttigheter med hjälp av en stor uppsättning privilegier som du kan ge användare. Det sträcker sig från rättigheter att läsa, uppdatera eller ta bort data genom databashanteringsprivilegier upp till "super"-privilegiet som tillåter användaren att utföra åtgärder som att hantera replikeringstrådarna och kringgå skrivskyddsinställningen.
Utöver det kommer MariaDB med roller - för att göra användarhantering enklare är det möjligt att definiera roller med en given uppsättning beviljade privilegier och sedan tilldela dessa roller till användarna. Sådana användare kommer att ärva anslag relaterade till rollen som de har tilldelats, vilket gör det mycket lättare att hantera anslag i stor skala:istället för att ändra anslag för flera användare kan du tilldela dem en specifik roll och sedan hantera alla deras privilegier genom att ändra de privilegier som tilldelats rollen som de har tilldelats.
Du bör också se till att du inte har några redan existerande användare utan ett tilldelat lösenord eller med en för stor uppsättning privilegier. Sådan säkerhetsrevision bör utföras då och då, för att säkerställa att du är medveten om potentiella säkerhetsrisker och att du kan planera att agera på dem.
Revisionslogg
Om din databas kommer med granskningslogg, precis som MariaDB gör, bör du överväga att använda den för att spåra de åtgärder som händer i databasen. Granskningsloggen hjälper dig att uppnå det. Med den aktiverad kommer du att kunna spåra även detaljer som vilken användare som utförde vilken fråga. Om du råkar använda ClusterControl kan du aktivera granskningsloggen bara med ett par klick:
För att sammanfatta den här bloggen finns det ett par saker du bör tänka på när du designar en MariaDB-distribution i hybridmolnmiljön. Vissa av dem är strikt relaterade till hur miljön är designad, vissa är ganska mycket relaterade till den databastyp som du använder och det faktum att du använder hybridmoln förändrar egentligen inte mycket. Det som verkligen är viktigt är att se till att din databas är ordentligt skyddad - det är det slutliga målet, oavsett vilken miljö det är.