Redis: cachelagring och meddelanden (Pub/Sub, Streams) · Lektion

Autentisering och auktorisering

Konfigurera Redis-lösenord, ACL:er och användarhantering för att styra åtkomsten till era Redis-instanser.

Lektion 1 av 411 steg

Autentisering och auktorisering är en gratis lektion i Redis: cachelagring och meddelanden (Pub/Sub, Streams) på CoddyKit. Detta är lektion 1 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Redis: cachelagring och meddelanden (Pub/Sub, Streams), och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Redis: cachelagring och meddelanden (Pub/Sub, Streams) innehåller totalt 4 lektioner.

Varför bör ni säkra Redis?

Redis är extremt snabbt och innehåller ofta känsliga data. Utan rätt säkerhet kan dina data exponeras eller ändras av obehöriga användare. Precis som ert hus behöver även er databas lås!

I den här lektionen lär ni er att konfigurera grundläggande autentisering med lösenord och avancerad auktorisering med hjälp av Access Control Lists (ACL:er) för att skydda era Redis-instanser.

Grundläggande lösenordsskydd

Det enklaste sättet att skydda Redis är att använda direktivet requirepass i filen redis.conf. Det anger ett globalt lösenord som klienter måste ange för att köra alla kommandon.

Det är som en enda huvudnyckel för alla.

requirepass your_strong_password_here

Logga in med AUTH

När requirepass har angetts måste klienter som ansluter till Redis autentisera sig med kommandot AUTH. Om lösenordet är fel misslyckas de flesta kommandon.

Så här ansluter ni via redis-cli och autentiserar er:

redis-cli
127.0.0.1:6379> AUTH your_strong_password_here
OK
127.0.0.1:6379> SET mykey "hello"
OK
127.0.0.1:6379> GET mykey
"hello"

Nackdelen med ett globalt lösenord

Även om requirepass är enkelt att konfigurera har det en stor begränsning: det är ett enda lösenord för alla och allt. Alla autentiserade klienter har full åtkomst till alla kommandon och data.

  • Inga specifika användarkonton.
  • Inga detaljerade behörigheter (till exempel skrivskydd för vissa).
  • Svårt att hantera i komplexa applikationer.

Det är här Redis Access Control Lists (ACL:er) kommer till användning!

Detaljerad åtkomst med ACL:er

Redis ACL:er (Access Control Lists) gör det möjligt att definiera flera användare, var och en med sitt eget lösenord och en specifik uppsättning behörigheter. Det ger mycket bättre kontroll över vem som får göra vad.

Ni kan styra:

  • Vilka kommandon en användare får köra.
  • Vilka nycklar en användare får komma åt.

Det är som att ha olika nycklar till olika rum i ert hus.

Skapa och konfigurera användare

Ni hanterar ACL:er direkt via Redis-kommandon, antingen i redis-cli eller programmatiskt. Kommandot ACL SETUSER är centralt för att definiera användare och deras egenskaper.

Vi skapar en ny användare med namnet app_user och ett lösenord. Tecknet > före lösenordet anger att det är ett lösenord.

ACL SETUSER app_user ON >some_secret_password
ACL SETUSER another_user ON >another_secret_pass_123
ACL LIST
user default on #... (default user)
user app_user on #... (our new user)

Styra kommandon

Med ACL:er kan ni ange exakt vilka kommandon en användare får köra. Behörigheter anges ofta i kategorier (som @all, @read, @write) eller med specifika kommandonamn.

  • +@read: Ger åtkomst till alla skrivskyddade kommandon.
  • -@admin: Tar bort åtkomsten till alla administrativa kommandon.
  • +SET: Ger endast åtkomst till kommandot SET.

Här är ett exempel för vår app_user, där läsning och skrivning tillåts men administrativa kommandon nekas:

ACL SETUSER app_user +@read +@write -@admin
ACL SETUSER metrics_user ON >metrics_pass +INFO +MONITOR
ACL CAT @admin
# ... lists admin commands

Åtkomst på nyckelnivå

Utöver kommandon kan ACL:er begränsa åtkomsten till specifika nycklar eller nyckelmönster. Det är mycket användbart i applikationer med flera klienter eller i mikrotjänster.

  • ~mykey: Åtkomst endast till nyckeln 'mykey'.
  • ~data:*: Åtkomst till alla nycklar som börjar med 'data:'.
  • ~*: Åtkomst till alla nycklar (använd med försiktighet!).

Vi begränsar nu app_user så att användaren endast får åtkomst till nycklar som börjar med user_data::

ACL SETUSER app_user ON >some_secret_password +@read +@write ~user_data:*
ACL SETUSER readonly_user ON >read_only_pass +@read ~cache:*

Säkra ACL-rutiner

Följ dessa rekommenderade metoder för att maximera säkerheten med ACL:er:

  • Principen om minsta privilegium: Ge endast de behörigheter som behövs. Undvik +@all om det inte är absolut nödvändigt.
  • Starka lösenord: Använd unika och komplexa lösenord för varje användare. Byt dem regelbundet.
  • Inaktivera standardanvändaren: Om den inte används bör ni inaktivera användaren default eller ge den ett starkt lösenord och minimala behörigheter.
  • Granska regelbundet: Kontrollera regelbundet era ACL-konfigurationer med ACL LIST.

Testa era ACL-kunskaper

Anta att ni har en Redis-instans där ni vill att en användare med namnet report_viewer ska:

  • Endast läsa data.
  • Endast komma åt nycklar som börjar med reports:.
  • Ha lösenordet ViewerPass!.

Vilket av följande kommandon konfigurerar användaren korrekt?

Sammanfattning: Skydda er Redis!

Bra jobbat! Ni har lärt er hur ni skyddar era Redis-instanser:

  • requirepass: Ger ett enkelt, globalt lösenordsskydd.
  • AUTH: Kommandot som klienter använder för att autentisera sig.
  • ACL:er: Ger avancerad och detaljerad kontroll över användare, kommandon och specifika nycklar.
  • ACL SETUSER: Det huvudsakliga kommandot för att skapa och ändra användare samt ange deras behörigheter.
  • Rekommenderade metoder: Följ alltid principen om minsta privilegium, använd starka lösenord och granska era konfigurationer.

Det är avgörande att skydda era data, och Redis tillhandahåller kraftfulla verktyg för just detta!

Gratis att börja

Lär dig Redis: cachelagring och meddelanden (Pub/Sub, Streams) med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
12
Lektioner
48

Vanliga frågor

Är lektionen ”Autentisering och auktorisering” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Redis: cachelagring och meddelanden (Pub/Sub, Streams), inklusive ”Autentisering och auktorisering”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Redis: cachelagring och meddelanden (Pub/Sub, Streams) innehåller totalt 4 lektioner.

Vad lär jag mig i ”Autentisering och auktorisering”?

Konfigurera Redis-lösenord, ACL:er och användarhantering för att styra åtkomsten till era Redis-instanser. Ni övar på Redis: cachelagring och meddelanden (Pub/Sub, Streams) med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Redis: cachelagring och meddelanden (Pub/Sub, Streams)?

Du behöver inga förkunskaper. Utbildningen i Redis: cachelagring och meddelanden (Pub/Sub, Streams) på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 1 av 4.

Hur lång tid tar lektionen ”Autentisering och auktorisering”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Redis: cachelagring och meddelanden (Pub/Sub, Streams)-lektionen?

Ja. Varje Redis: cachelagring och meddelanden (Pub/Sub, Streams)-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Autentisering och auktorisering
  2. Nätverkssäkerhet för Redis
  3. Bästa praxis för drift
  4. Kryptering under överföring med TLS
← Tillbaka till Redis: cachelagring och meddelanden (Pub/Sub, Streams)