Hybrid cloud kan være en fantastisk måde at tilføje fleksibilitet til dine eksisterende on-prem-implementeringer. Som vi diskuterede i flere blogs, kan public cloud være en fantastisk tilføjelse til dit eget datacenter, hvilket sikrer, at du nemt kan skalere ud for at håndtere belastningen, reducere din capex og blive brugt til at implementere katastrofegendannelsesprocedurer. Sikkerhed er et andet aspekt, du skal tænke igennem, når du planlægger at bygge sådanne systemer. I dette blogindlæg vil vi tale om nogle af sikkerhedsovervejelserne for hybrid cloud MariaDB-implementeringer.
Forbindelse
VPN
Størstedelen af enhver hybrid infrastruktur er netværket. Når alt kommer til alt, taler vi om to miljøer, lokale, lokale og en offentlig sky, der skal forbindes og danne en samlet enhed. Forbindelsen skal være krypteret. Hvordan man griber det an, er der mange måder at gøre det på.
En af dem ville være at bruge en løsning, der stilles til rådighed af cloud-udbyderen - de fleste af dem har en form for tilslutningsmulighed tilgængelig. Det kan være AWS Direct Connect, hvis du tilfældigvis integrerer med Amazon Web Services. Hvis du planlægger at bruge Google Cloud, diskuteres løsninger på følgende websted:https://cloud.google.com/hybrid-connectivity. Kort sagt er der et betydeligt antal forskellige muligheder, der varierer fra hardware-VPN-integration til opsætning af BGP-peering.
På den anden side af spektret har vi software-VPN-løsninger. OpenVPN eller lignende form for software kan bruges til at oprette en sikker, krypteret netværksforbindelse mellem dit eget datacenter og den offentlige sky. I et sådant tilfælde vil du kræve en separat instans, der kører i den offentlige sky, som vil blive brugt til VPN-serveren. Ved at bruge software-VPN'er kan du vælge den løsning, der passer bedst til dine krav og passer bedst til dit miljø.
Firewall
Databaser bør aldrig være tilgængelige fra eksterne netværk. Det er altafgørende at bygge dit miljø på en måde, så databaseniveauet kun er tilgængeligt fra det begrænsede sæt af værter. Præcis hvad der kræves, og hvordan man gør det, er det op til dig at bestemme. En typisk opsætning vil bestå af et sikret databaselag, som kun kan tilgås fra proxy-niveau, og om nødvendigt bør der implementeres en form for springvært, hvis det kræves til automatiserings- og administrationsopgaver.
Applikationsservere bør ikke have direkte adgang til databasen - det behøver de ikke. Det eneste, applikationen skal gøre, er at oprette forbindelse til belastningsbalanceren. Load balancers skal kunne oprette forbindelse til databasen. En load balancer som ProxySQL er perfekt i stand til at udføre læse/skrive opdelingen og sende læsninger og skrivninger til de korrekte databasenoder. Applikationen skulle være i stand til at oprette forbindelse til ProxySQL, og resten vil blive håndteret af proxyen - databasegodkendelse, trafikformning, fordeling af trafikken på tværs af adskillige replikaer, som du måtte have. Al unødvendig adgang bør begrænses. Sikkerhedsgrupper, firewalls - det er de værktøjer, du vil bruge til at sikre dit miljø.
Kort sagt, adgang til databaseværterne bør kun tillades på de nødvendige porte. For MariaDB vil det naturligvis være en port, der bruges til databasen, men også andre porte, hvis det er nødvendigt - du kan have en slags eksportører eller agenter installeret. For Galera skal du åbne porte til intra-klyngekommunikation. Du vil måske også have en åben port til SSH-forbindelser. Ideelt set skal du begrænse adgangen pr. vært; kun et begrænset sæt værter kan få adgang til en given port. For eksempel kan databaseporten være tilgængelig fra de andre databasenoder, localhost og proxy-lag. Der er ingen grund til at holde den åben for andre noder. Dine databasenoder kan endda være placeret på et separat undernet, hvilket sikrer, at sikkerheden er endnu strammere.
Med hensyn til porte ville bedste praksis være at ændre dem fra standardindstillingerne til noget andet. Ideelt set noget tilfældigt. Ændring af SSH-port fra 22 til 2222 eller MariaDB-port fra 3306 til 33306 kan hjælpe med at undgå nogle af de automatiske angreb, men det kan stadig finde ud af, om nogen aktivt søger at komme ind på dit netværk. Hvis du vil have bedre sikkerhed, kan du bare gå videre med nogle tilfældige værdier. Indstil SSH til 5762 og MariaDB til 24359. Det er ret sandsynligt, at ingen vil være i stand til at gætte dem. Indstil dine TCP-timeouts, så portscanningerne bliver meget lange og dyre, og det vil helt sikkert øge dine chancer.
SSL
Ud over VPN og firewall bør du sikre dig, at din databasetrafik er krypteret med SSL.
Ideelt set vil du beskytte både frontend-forbindelser (fra belastningsbalancererne) og kommunikationen mellem dine databasenoder (det være sig replikering eller intra-cluster-overførsel i Galera-klynger). ClusterControl kan hjælpe dig med at aktivere disse muligheder med blot et par klik.
Alt du skal gøre er at lade ClusterControl oprette nye certifikater eller bruge et af de eksisterende - du kan importere dit eget certifikat, hvis du vil. At have SSL aktiveret sikrer, at databasetrafikken ikke kan læses, selv af en person, der har fået adgang til dit netværk.
Databasesikkerhed
Selvfølgelig er netværket ikke det eneste vigtige aspekt af sikkerheden. Ja, det er kritisk, især i hybrid cloud-miljøet, men der er også andre meget vigtige aspekter. En af dem er adgangskontrollen indlejret i MariaDB.
Rollebaseret adgangskontrol til MariaDB
MariaDB leveres med et sæt instrumenter til at sikre, at databaseadgangen administreres korrekt og begrænses, hvor end det er nødvendigt. Den første linje af godkendelse er brugere. Alle og alt, der har adgang til MariaDB, bør bruge en tildelt bruger til at oprette forbindelse til databasen. Sådanne brugere vil have en korrekt adgangskode - du kan have adgangskodevalideringen aktiveret i MariaDB for at sikre, at adgangskoderne er stærke nok. Ideelt set ville du kun begrænse brugerens adgangsvært til værtsnavne eller IP'er for belastningsbalancere - dette bør altid være måden, brugerne opretter forbindelse til databasen på. For nogle administrative brugere vil du måske beholde den lokale værtsadgang, hvis det kræves. Ud over at håndhæve den korrekte adgangskodestyrke kan du konfigurere adgangskoden til at udløbe inden for en vis periode eller gennemtvinge adgangskoderotation på brugerne. Som du kan forestille dig, er en ordentlig adgangskoderotationspolitik noget, du gerne vil have implementeret.
Hver bruger i MariaDB kan have flere privilegier tildelt. Privilegier kan tildeles på flere niveauer - globalt niveau, databaseniveau, tabelniveau eller endda kolonneniveau. Den bedste praksis er at give brugerne et begrænset sæt privilegier som muligt. Hvis brugeren kun kræver adgang til en bestemt tabel, skal du bare give ham det. Det er ikke nødvendigt for denne bruger at få adgang til andre tabeller for ikke at nævne andre skemaer. Du kan definere ret detaljerede adgangsrettigheder ved hjælp af et stort sæt privilegier, som du kan give brugere. Det spænder fra rettigheder til at læse, opdatere eller slette data gennem databasestyringsprivilegier op til "super"-privilegiet, der giver brugeren mulighed for at udføre handlinger som at administrere replikeringstrådene og omgå read_only-indstillingen.
Oven i købet kommer MariaDB med roller - for at gøre brugeradministration nemmere er det muligt at definere roller med et givet sæt tildelte privilegier og derefter tildele disse roller til brugerne. Sådanne brugere vil arve bevillinger relateret til den rolle, de er blevet tildelt, hvilket gør det meget nemmere at administrere bevillinger i stor skala:I stedet for at ændre bevillingerne for flere brugere kan du tildele dem til en specifik rolle og derefter administrere alle deres privilegier ved at ændre de privilegier, der er givet til den rolle, de er blevet tildelt.
Du bør også sikre dig, at du ikke har nogen allerede eksisterende brugere uden en tildelt adgangskode eller med et for stort sæt privilegier. En sådan sikkerhedsrevision bør udføres fra tid til anden for at sikre, at du er opmærksom på potentielle sikkerhedsrisici, og du kan planlægge at handle på dem.
Revisionslog
Hvis din database kommer med revisionslog, ligesom MariaDB gør, bør du overveje at bruge den til at spore de handlinger, der sker i databasen. Revisionsloggen hjælper dig med at opnå det. Med det aktiveret vil du være i stand til at spore selv detaljerne som hvilken bruger der udførte hvilken forespørgsel. Hvis du tilfældigvis bruger ClusterControl, kan du aktivere revisionsloggen med et par klik:
For at opsummere denne blog er der et par ting, du bør overveje, når du designer en MariaDB-implementering i det hybride cloudmiljø. Nogle af dem er strengt relateret til den måde, miljøet er designet på, nogle er ret meget relateret til den databasetype, du bruger, og det faktum, at du bruger hybrid cloud, ændrer ikke meget. Det, der virkelig er vigtigt, er at sikre, at din database er ordentligt beskyttet - det er det ultimative mål, uanset hvilket miljø der er.