Redis -kryptering

“Redis er en mye brukt høyytelsesdatabase som er i stand til å lagre en rekke datastrukturer. Siden det brukes av store applikasjoner på bedriftsnivå for å levere hurtigbufring, meldingssystemer og databasekapasiteter, er sikkerhets- og datakrypteringsaspektene like viktige som ytelsen. I løpet av det siste tiåret har det vært en økende trend i ondsinnede angrep som har blitt utløst mot databaser for å avsløre sensitiv informasjon eller for å endre dataene. Så risikoen er den samme med applikasjonene som bruker Redis backends.

Redis er grunnleggende designet for autoriserte forbindelser i pålitelige miljøer. Derfor anbefales det å ikke eksponere Redis -databaseporten for allmennheten eller Internett og ikke -tillitsfulle nettverk. I de fleste tilfeller der webapplikasjoner genererer innhold ved å spørre Redis Store og skyve data basert på klientforespørsler, er det obligatorisk å implementere et mellomlag for å begrense eller filtrere ut klientforespørsler som kommer gjennom webapplikasjonene. Redis gir en rekke kryptering og sikkerhetstiltak, for eksempel Access Control Lists (ACL), TLS -støtte og kryptering i ro for å beskytte data.”

Tillat pålitelig trafikk med Redis Authentication & ACL (tilgangskontrolllister)

Som nevnt, etter design, er Redis ikke trygt å utsette for ikke -tillitsfulle nettverk, internett og klientforbindelser. Hvis det er tilfelle, gir Redis en database -godkjenningsmekanisme der klienter skal autentisere ved hjelp av et brukernavn og passord. Hver bruker er assosiert med et begrenset sett med funksjonaliteter, Redis -nøkler og kommandoer. Det vil begrense visse klienter ved bare å ha tillatelser til å utføre lesekommandoer, men ikke skrivekommandoene. Videre brukes ACL til å begrense høyrisikokommandoer som Flushall og Flushdb fra ikke-tillitsfulle kilder. I tillegg har Redis en rekke konfigurasjonskommandoer introdusert for å administrere Redis-forekomsten i både på stedet og skyoppsett. Disse konfigurasjonskommandoene er ikke veldig nyttige for forbrukerne. Så ACL klarer å skjule disse kommandoene også for publikum.

Autentisering

Vanligvis inneholder Redis Config -filen en linje som heter kravpass som kan brukes til å aktivere passordgodkjenning for en gitt Redis -databaseinstans. Med dette alternativet aktivert, vil ikke uautentiserte klienter ikke få tilgang til databasen i det hele tatt. Auth -kommandoen brukes til å autentisere brukere til Redis -databasene. Den utvides fra Redis versjon 6, som kan brukes med to parametere som følger.

Auth

Inspisere ACL for en Redis -forekomst

Redis ACL -er kan inspiseres ved hjelp av ACL -listekommandoen, som vist på følgende. Generelt viser den detaljert informasjon relatert til en bruker, for eksempel et brukernavn, passordstatus (påkrevd eller ikke), tilgangsnøkler, kommandoer og pub/underkanaler.

ACL -liste

Ovennevnte utgang kan tolkes som følger.

Ulike ACL -regler er tilgjengelige for å opprette riktige brukere med minimum tilgangsnivåer til Redis -databaseforekomsten. ACL Setuser -kommandoen kan brukes til å konfigurere forskjellige brukere med forskjellige tilgangsnivåer.

Krypter overførte data ved hjelp av Redis TLS

Fra Redis versjon 6 har SSL/TLS blitt støttet. Det krypterer data sendt over alle Redis -kommunikasjonskanaler som klientforbindelser, klyngeforbindelser, vaktposter og replikeringskoblinger. Videre må Redis SSL/TLS være aktivert på kompileringstidspunktet.

Som standard kjøres Redis -servere i normal modus, som ikke støtter SSL/TLS -kryptering. Derfor må du eksplisitt starte Redis -forekomsten i TLS -modus, som vist i det følgende.

Redis-Server--TLS-Port 6379-Port 0--TLS-CERT-FILE ./reditls/tls/redis.CRT--TLS-Key-File ./reditls/tls/redis.Key--TLS-CA-CERT-File ./reditls/tls/ca.crt

Vi antar at alle SSL -sertifikater og nøkler er tilgjengelige. Tilsvarende, for å sette i gang en klientforbindelse, bør vi bruke -tls -flagget sammen med nødvendige SSL -nøkler og sertifikater som følger.

Redis-CLI--TLS--CERT ./reditls/tls/redis.CRT -Key ./reditls/tls/redis.Key - -Cacert ./reditls/tls/ca.crt

I tillegg bør Redis -forekomsten konfigureres med en x.509 sertifikat og privat nøkkel også.

SSL/TLS -kryptering i replikering, Sentinel og klyngekommunikasjon

Replikering

I Redis, når replikasjonen er aktivert, bruker masterforekomsten TLS-PORT og TLS-Auth-klienter alternativer for å la klienter kjenne til porten som godtar TLS -tilkoblinger og om klientgodkjenning er nødvendig eller ikke. Tilsvarende anbefales det i replika -tilfeller å bruke SSL/TLS -kryptering for utgående tilkoblinger til hovedforekomster. I så fall TLS-Replication Alternativet skal settes til ja.

vakt

Hver gang Redis Sentinel har blitt aktivert for behov for høy tilgjengelighet, TLS-Replication Alternativet bestemmer om TLS- eller ikke-TLS-tilkobling må brukes når du kobles til Master-servere. Tilsvarende styrer det samme direktivet at de innkommende tilkoblingene fra andre vaktposter er SSL/TL -er aktivert eller ikke. Hvis TLS-Replication Direktiv setter seg til ja, TLS-PORT alternativet bør også tilordnes med riktig port.

Klynge

Når klyngene brukes i Redis, anbefales det å gi sikre kommunikasjonskanaler for klyngebusser og klyngeklyngerkoblinger. Redis gir TLS-klyngen Direktiv for å bestemme støtten for SSL/TLS -kryptering blant klyngeknuter. Dette direktivet skal settes til ja Når du trenger en TLS -tilkobling for å sende data fra en node til en annen.

Kryptering i ro

Redis er utplassert i både lokal og skymiljøer og skymiljøer. I skyutplasseringer er hvilekommunikasjonen alltid kryptert. De største skyleverandørene som AWS, Azure og GCP Provision Redis -distribusjoner via krypterte kanaler. Videre gir Amazon Cloud krypteringsfunksjoner i transitt som er listet opp nedenfor.

• • Master-replica-kommunikasjon er kryptert i AWS-utplasserte Redis-forekomster.
  • SSL aktiverte server- og klientforbindelser
  • Klient- og servergodkjenningsstøtte ved hjelp av Redis authent -kommandoen diskutert i en tidligere seksjon.

Konklusjon

Oppsummert er Redis ikke designet for å eksponere sin TCP -port for ikke -tillit til klientforbindelser i upålitelige miljøer. Etter design er den bare utviklet for pålitelige kilder. Som nevnt, i tilfelle av Redis utsatt for publikum via en webapplikasjon, må et ekstra sikkerhetslag implementeres mellom klientforbindelsene og Redis -forekomsten. I følge denne artikkelen støtter Redis tilgangskontrolllister (ACLS), TLS -støtte og kryptering i ro for å dempe ondsinnede angrep. I tillegg har vi diskutert SSL/TLS -støtten også for Redis Cluster, Replica og Sentinel Communication. Totalt sett anbefales det å øve ovennevnte teknikker når Redis -forekomsten blir utsatt for publikum.