Ga naar de inhoud 
Ik stel redis acl in multi-user-omgevingen doelgericht in om commando’s, sleutelprefixen en Pub/Sub-kanalen strikt van elkaar te scheiden. Zo zorg ik voor Beveiliging aan de serverzijde: beperk onjuiste toegangsverzoeken tot een minimum en zorg ervoor dat rollen duidelijk te beheren zijn.
Centrale punten
- Scheiding van commando's, sleutels en kanalen per gebruiker
- Aan de serverzijde Controle in plaats van logica in de app
- Naamruimten per sleutelprefix per klant
- ACL-bestand voor onderhoudbaarheid en versiebeheer
- Audits met ACL LIST en ACL USERS
Basisprincipes van ACL’s in multi-user-omgevingen
Ik maak voor elke toepassing, elk team of elke klant een aparte gebruiker aan en stel diens rechten strikt in via ACL-regels. Zo voorkom ik dat één enkel algemeen wachtwoord alle deuren opent en dat gegevens per ongeluk worden overschreven. Ik verdeel rechten op basis van commando’s, sleutelpatronen en kanalen, zodat elk account alleen toegang heeft tot wat nodig is en niets meer dan dat. Deze isolatie aan de serverzijde ontlast de applicatie en verhoogt de Transparantie in het beveiligingsmodel. Juist in gedeelde instanties behoud ik zo het overzicht over wie welke bewerking in welke naamruimte mag uitvoeren.
Rechtenmodellen: commando’s, sleutels en kanalen duidelijk van elkaar scheiden
Ik ken beheerrechten gedetailleerd toe, bijvoorbeeld per categorie zoals @lezen en @write, en verwijder risicovolle groepen zoals @dangerous, die configuratie- of beheerderscommando’s bevatten. Voor sleutelruimten werk ik met unieke voorvoegsels zoals app1:*, app2:* of tenant_a:*, zodat lees- en schrijftoegang beperkt blijven tot een duidelijke naamruimte. Op deze manier kan een taak bijvoorbeeld SET en GET gebruiken, maar alleen onder zijn eigen voorvoegsel werken. Daarnaast beperk ik Pub/Sub-kanalen, zodat gebeurtenissen alleen in de daarvoor bestemde streams plaatsvinden. Het resultaat is een traceerbare Scheiding tussen rollen, datarooms en communicatiekanalen.
Pub/Sub veilig beperken
Voor Pub/Sub sta ik uitsluitend de kanalen toe die een applicatie echt nodig heeft, en sluit ik al het andere consequent uit ACL-regels. Zo voorkom ik dat een dienst externe gebeurtenissen ontvangt of berichten naar onverwachte abonnees publiceert. Juist in event-architecturen vermindert deze controle het risico op gegevenslekken of verstoring van andere diensten. Ik documenteer de vrijgegeven kanalen per gebruiker, zodat onboarding en audits overzichtelijk blijven. Zo behoud ik, ondanks een groeiende systeemomgeving, de Controle over gegevensstromen.
Gebruikers- en regelbeheer in de praktijk
Ik maak nieuwe gebruikers aan met ACL SETUSER, wijs een sterk wachtwoord toe en activeer precies die commando’s die de dienst nodig heeft, bijvoorbeeld +@lezen en +@write, waarbij risicovolle opdrachten tegelijkertijd worden geblokkeerd. De toegestane sleutelruimtes definieer ik aan de hand van passende patronen, en ik regel kanalen op dezelfde manier. Voor het overzicht gebruik ik ACL USERS en met ACL LIST krijg ik snel een beeld van de actieve regels. Wijzigingen laad of sla ik op met ACL LOAD en ACL SAVE, zodat de configuratie en het bestand synchroon blijven. Zo houd ik de Administratie beknopt, begrijpelijk en reproduceerbaar.
| ACL-/Auth-commando | Doel | Voorbeeld |
|---|---|---|
| ACL SETUSER | Gebruiker aanmaken/wijzigen | ACL SETUSER app1 on >veiligWachtwoord +@read +@write -@dangerous ~app1:* |
| ACL-LIJST | Regels weergeven | ACL-LIJST |
| ACL-GEBRUIKERS | Gebruikers weergeven | ACL-GEBRUIKERS |
| ACL LADEN/OPSLAAN | ACL-bestand laden/opslaan | ACL SAVE; ACL LOAD |
| AUTH | Aanmelding bij de server | AUTH app1 veiligWachtwoord |
Configuratie: ACL-bestand of redis.conf?
Ik sla eenvoudige instellingen rechtstreeks op in de redis.conf, maar bij meerdere gebruikers en rollen houd ik het bij één apart ACL-bestand. Dit bestand beheer ik met versiebeheer in de beveiligde repository, documenteer wijzigingen zorgvuldig en voer updates op een gecontroleerde manier door. Zo houd ik applicatieparameters gescheiden van de beveiligingslogica, wat het aantal foutbronnen vermindert. Tegelijkertijd versterk ik de beveiliging van de instantie op netwerkniveau, bijvoorbeeld door open poorten beveiligen en onnodige kwetsbare punten weg te werken. Alles bij elkaar genomen verhoogt dat de Beveiliging en vereenvoudigt het gebruik.
Naamruimten en scheiding van klanten
Ik ontwerp sleutelprefixen zo dat ze tenant-ID’s en applicatienamen duidelijk weergeven, bijvoorbeeld tenantA:app1:session:{id}. Zo creëer ik een duidelijk zichtbare afscherming rond de gegevens van elke partij, die bovendien door ACL-regels wordt beveiligd. Voor migratietrajecten gebruik ik consistente naamgevingsschema’s, zodat uitrol via Blue-Green of Canary soepeler verloopt. Ook bij back-ups en herstelbewerkingen helpt een eenduidige structuur, omdat ik dan alleen de relevante gegevenssets hoef te verwerken. Deze combinatie van naamgevingsconcept en ACL-regels houdt de Klanten netjes gescheiden.
Microservices en teamrollen in de dagelijkse praktijk
Ik stel per service één gebruiker in die uitsluitend de eigen dataruimtes kan lezen en schrijven, zonder toegang te krijgen tot andermans prefixen of beheerdersfuncties. Voor ontwikkelaarsaccounts stel ik restrictieve lees- of schrijfrechten in, terwijl beheerdersaccounts strikt beperkt blijven en worden gelogd. Batch-taken krijgen alleen de commando’s die ze nodig hebben om hun taken uit te voeren, zoals lezen, schrijven en TTL-wijzigingen, maar geen beheeropdrachten. Externe integraties beperk ik bovendien in de tijd of tot testomgevingen, zodat verkeerde configuraties geen Productief-Gegevens bewerken. Zo verdeel ik de verantwoordelijkheden duidelijk, zonder de beveiliging te verzwakken.
Beperkingen van ACL's en isolatieniveaus
Ik interpreteer ACL's correct: ze controleren de toegang, maar zorgen niet voor isolatie Bronnen zoals CPU, RAM of I/O op procesniveau. In strenge compliance-scenario’s overweeg ik daarom speciale instanties, afzonderlijke clusters of eigen knooppunten. De logische scheiding via ACL vermindert onbevoegde toegang, maar maakt nog steeds gebruik van dezelfde serverbronnen. Voor gevoelige workloads plan ik extra afscherming, bijvoorbeeld via netwerksegmenten, container- of VM-grenzen. Zo combineer ik toegangscontrole met technische afscherming voor een hoger veiligheidsniveau.
Bedrijf: audits, rotatie en logboekregistratie
Ik controleer regelmatig de rechten met ACL LIST en houd een wijzigingsschema bij, zodat ik tijdens audits snel kan vaststellen wat actief is. Ik wissel wachtwoorden op vaste tijdstippen af en registreer zorgvuldig aanmeldingen en ongebruikelijke patronen. Bij incidenten blokkeer ik de betrokken gebruikers onmiddellijk, laad ik bijgewerkte regels en test ik kritieke paden automatisch. In CI/CD integreer ik controles die verboden commando’s of ontbrekende voorvoegsels in configuraties signaleren. Dit Procedure bespaart tijd en beperkt bedrijfsonderbrekingen tot een minimum.
Architectuurkeuzes: gedeeld of toegewezen
Ik overweeg of meerdere klanten één gemeenschappelijke instantie gaan gebruiken of dat ik afzonderlijke servers ga inrichten, aangezien beide hun eigen Risico's en voordelen heeft. Shared bespaart kosten, maar vereist strikte ACL’s, overzichtelijke naamruimten en nauwgezette monitoring. Dedicated vermindert kruisinvloeden, maar kost meer aan hardware en onderhoud. Voor prestatie- en veiligheidskwesties geef ik de voorkeur aan vergelijkingen zoals Gedeeld versus toegewijd ik bekijk het en voer belastingstests uit. Uiteindelijk neem ik een beslissing op basis van gegevenstoegang, compliance-eisen en Budget.
Cluster of standalone – wat past bij ACL’s?
Ik pas ACL’s zowel in standalone-instanties als in clusters toe, maar let erop dat de regels op alle knooppunten consistent zijn. In clusters controleer ik hoe sleutels over de slots zijn verdeeld, zodat prefixen en rechten nog steeds op de juiste manier worden toegepast. Bij hoge beschikbaarheid eis ik dat een failover geen Breuk in de rechtenketen wordt gegenereerd en het ACL-bestand overal identiek is. Ik test migratiepaden van tevoren, zodat er bij replicatiewisselingen of upgrades geen hiaten ontstaan. Wie de architectuur afweegt, kan zich baseren op vergelijkingen zoals Cluster versus standalone zich hierop richten en vervolgens de ACL-strategie op de juiste manier implementeren.
Planning en Bootstrap: een veilige start
Ik begin met een schone Bootstrap. De ingebouwde „default“-gebruiker krijgt geen uitgebreide rechten: ofwel schakel ik hem volledig uit, ofwel ontneem ik hem standaard alle commando’s, sleutels en kanalen. Zo voorkom ik dat er per ongeluk zonder gebruikersscheiding wordt gewerkt. Voor operationele taken definieer ik bewust aparte beheerdersaccounts met meervoudige authenticatie op managementniveau (bijv. bastionhost/TLS-clientcertificaten) en strikte ACL's.
# Veilige opstart in het ACL-bestand
user default off
user admin on >SterkAdminWachtwoord +@admin -@dangerous allkeys allchannels
Sterke wachtwoorden genereer ik aan de serverzijde, zodat ze nooit in logbestanden of de shell-geschiedenis terechtkomen. Voor snelle, veilige tokens gebruik ik een generator op de server en wissel ik deze regelmatig af. Moderne clients verifieer ik bij voorkeur via HELLO met gebruikersnaam/wachtwoord in één stap, wat de protocolversie expliciet vastlegt en randgevallen voorkomt.
Patronen en valkuilen bij sleutel- en kanaal-ACL’s
Bij sleutelpatronen werk ik uitsluitend met toestemmingslijsten. Ik begin met resetknoppen en voeg vervolgens gericht ~-patronen toe, bijvoorbeeld ~tenantA:* en ~tenantA:app1:* voor nauwkeuriger afgebakende ruimtes. Overlappende prefixen vormen een probleem: Als een gebruiker ~tenantA:* heeft en geen toegang mag hebben tot gebieden zoals tenantA:archiv:*, dan plan ik de naamruimten zo dat gevoelige subsets een eigen prefix krijgen (bijv. tenantA:priv:*), die ik simpelweg niet vrijgeef. Soortgelijke regels gelden voor kanalen: ik stel kanalen resetten en verleen alleen &tenantA:* en uitsluitend de kanalen die nodig zijn voor Keyspace-meldingen, indien aanwezig.
# Sleutels en kanalen strikt
ACL SETUSER tenantA:app1 on >Pass +@read +@write -@dangerous \
resetkeys ~tenantA:app1:* \
resetchannels &tenantA:app1:*
Ik merk op dat commando’s zoals RENAME, MIGRATE of DUMP/RESTORE over prefixgrenzen heen zouden kunnen schrijven. Dergelijke commando’s blijven geblokkeerd in productieve serviceaccounts. Hash-velden, lijstitems of leden van gesorteerde sets zijn geen afzonderlijke sleutels – de ACL is van toepassing op sleutelniveau, niet binnen de gegevensstructuur. Daarom volstaat een duidelijk concept voor sleutelprefixen om ook deze structuren te dekken.
Commando-categorieën bewust sturen
Ik activeer alleen wat ik echt nodig heb. Voor klassieke CRUD-workloads volstaan vaak +@read en +@write. Categorieën met een verhoogd risico blokkeer ik altijd: @admin en @dangerous zijn taboe voor gebruikers van de applicatie. Scriptfuncties (EVAL, FUNCTION) laat ik in multi-tenant-opstellingen zoveel mogelijk helemaal buiten beschouwing. Voor Pub/Sub-services ontkoppel ik de rechten, zodat schrijfopdrachten op sleutels niet automatisch worden toegestaan. In de praktijk begin ik met een minimale configuratie en sta ik indien nodig gericht afzonderlijke commando’s (+COMMAND) toe in plaats van hele categorieën vrij te geven.
Rotatie en wijzigingen zonder downtime
Ik ben van plan om wachtwoorden te wisselen zonder downtime. Redis staat meerdere actieve wachtwoorden per gebruiker toe. De volgorde is eenvoudig: eerst een nieuw wachtwoord toevoegen, vervolgens de clients aanpassen en daarna het oude wachtwoord vervangen door resetpass verwijderen. Hetzelfde principe pas ik toe bij stapsgewijze wijzigingen van rechten: bij twijfel voer ik eerst tijdelijke DRY-runs en testgebruikers uit, voordat ik de productieve accounts aanpas.
# Rotatieprocedure
ACL SETUSER app1 >NieuwWachtwoord # nieuw wachtwoord extra instellen
# Clients omzetten ...
ACL SETUSER app1 resetpass >NieuwWachtwoord # oud wachtwoord verwijderd, nieuw wachtwoord blijft behouden
Tests, foutopsporing en audits verdiepen
Ik test wijzigingen voordat ze live gaan. Met een droogloop controleer ik of een gebruiker een commando op een bepaalde key of een bepaald kanaal mag uitvoeren, zonder het daadwerkelijk uit te voeren. Onbevoegde toegangspogingen en overtredingen van de regels houd ik bij in een speciaal ACL-logboek en stel ik daar zinvolle bewaar- en routeringsregels in naar mijn centrale logboekinfrastructuur. Voor de transparantie maak ik ook gebruik van de categorielijsten om te begrijpen welke commando's er achter een categorie schuilgaan.
# Rechten simuleren
ACL DRYRUN app1 GET otherprefix:key
# huidige gebruikersidentiteit controleren
ACL WHOAMI
# mislukte toegangspogingen bekijken/resetten
ACL LOG
ACL LOG RESET
# commando’s per categorie weergeven
ACL CAT @write
Voor audits bewaar ik naast de ACL LIST/USERS ook snapshots van het ACL-bestand in de versiebeheeromgeving. Elke wijziging krijgt een ticket/change request en doorloopt een merge-proces dat door een reviewer moet worden goedgekeurd. Zo kan ik op elk moment nagaan wie wanneer welke rechten heeft uitgebreid of beperkt.
Scripting, functies en veilige uitvoering
Lua-scripts en server-side functies zijn krachtig – maar kunnen ook een potentiële ontsnappingsroute uit de isolatie vormen als ze te breed worden toegestaan. In gedeelde omgevingen schakel ik EVAL/EVALSHA en functiebeheer standaard uit en sta ik ze alleen toe in duidelijk afgebakende beheerderscontexten. Als scripting nodig is, controleer ik nauwkeurig of de scripts uitsluitend toegang hebben tot toegestane sleutelprefixen, want ACL's zijn ook van toepassing bij aanroepen vanuit scripts. Dit vermindert het risico dat er indirect toegang wordt verkregen tot vreemde gebieden.
Replicatie, hoge beschikbaarheid en consistentie van de ACL's
In gerepliceerde opstellingen scheid ik applicatiegebruikers van replicatiegebruikers. Voor de replicatie richt ik een speciaal technisch account in, dat alleen de commando’s krijgt die nodig zijn voor SYNC/PSYNC/REPLCONF en dergelijke. Ik houd het ACL-bestand op alle knooppunten synchroon – bij handmatig onderhoud via configuratiebeheer, in beheerde clusters via de daarvoor bestemde mechanismen. Na wijzigingen sla ik de regels centraal op en laad ik ze op een gecontroleerde manier naar nieuwe knooppunten, zodat een failover geen inbreuk op de rechten veroorzaakt.
In clusters controleer ik bovendien of de sleutelprefixen nog steeds op een zinvolle manier zijn afgestemd op slotgrenzen. Dit is minder een ACL-kwestie dan een ontwerpaspect voor een gelijkmatige lastverdeling en een eenvoudigere rechtentoelichting („één prefix, één gegevensruimte, veel slots“). Tijdens een failover zorg ik ervoor dat replicatiegebruikers en beheerdersaccounts al beschikbaar zijn op het doelnode, zodat de omschakeling transparant verloopt.
Verandering van klant, migraties en back-ups
Bij het hernoemen van prefixen of tenant-ID’s houd ik vooraf rekening met de gevolgen voor de ACL’s. Als een tenant van tenantA: naar tenantA2: migreert, sta ik tijdelijk beide patronen toe en plan ik een duidelijke overgangsfase. Ik zorg ervoor dat migratietaken zelf een strikt beperkte gebruiker gebruiken, die alleen de benodigde prefixen leest en schrijft. Voor back-ups houd ik rekening met het volgende: het ACL-bestand staat los van RDB/AOF – ik maak er daarom apart een back-up van als onderdeel van de configuratie. Voor gedeeltelijke herstelbewerkingen helpen nauwkeurige prefixen, omdat ik zo gericht alleen de relevante sleutelruimten kan extraheren.
Client-integratie en beveiligde protocollen
Aan de clientzijde maak ik consequent gebruik van gebruikersnaam/wachtwoord, in plaats van een globale „requirepass“ te gebruiken. Voor moderne clients gebruik ik de HELLO-handshake om de protocolversie en authenticatie in één stap af te handelen. In productieomgevingen maak ik gebruik van TLS-versleuteling, zodat inloggegevens en gegevenspaden beschermd blijven. Daarnaast controleer ik of clients de gebruikersnaam niet in leesbare tekst in logbestanden vastleggen, of dat logbestanden op de juiste wijze worden gemaskeerd.
# Voorbeeld: authenticatie in één stap
HELLO 3 AUTH app1 veiligWachtwoord
CI/CD-automatisering en configuratiesjablonen
Ik modelleer ACL’s als code. Rollen en gebruikers worden gegenereerd op basis van sjablonen, die ik per omgeving vul met variabelen (voorvoegsel, kanalen, categorieën). In de pijplijn vinden validaties plaats: linters controleren of er geen @dangerous/@admin-commando’s in service-accounts terechtkomen, tests voeren DRYRUN’s uit op representatieve sleutels en een smoke-test-container start kort op tegen een geïsoleerde Redis-instantie om AUTH, GET/SET en Pub/Sub end-to-end te verifiëren. Wijzigingen worden pas uitgerold als alle controles groen zijn, en bij een rollback is het vorige ACL-bestand onmiddellijk beschikbaar.
Operationele details: zichtbaarheid en opruimen
In het dagelijks werk kunnen kleine hulpmiddelen een groot verschil maken. Met ACL WHOAMI kan ik snel controleren onder welk account een client daadwerkelijk werkt – wat vooral in complexe toolchains van groot belang is. Ik ruim regelmatig „zombie“-accounts op: gedeactiveerde diensten verliezen hun gebruikers („off“), wachtwoorden worden verwijderd („resetpass“), sleutel- en kanaalrechten worden gewist („resetkeys“, „resetchannels“). Ik houd me aan naamgevingsconventies voor gebruikers (bijvoorbeeld team_service_env), wat audits en incidentrespons versnelt.
Kort samengevat
Ik ben van plan ACL's Vanaf het begin maak ik per dienst een gebruiker aan en beperk ik diens commando’s, sleutelvoorvoegsels en kanalen strikt. Voor onderhoudsvriendelijke opstellingen gebruik ik een apart ACL-bestand, voer ik wijzigingen op gecontroleerde wijze door en documenteer ik elke stap. Namespaces met duidelijke prefixen beschermen klanten, terwijl audits, rotatie en logboekregistratie de werking betrouwbaar houden. Voor gevoelige scenario’s houd ik bovendien rekening met architecturale scheiding, zodat toegangscontrole en technische isolatie op elkaar aansluiten. Zo wordt een gedeelde Redis-instantie een beheersbare, veilig Platform voor diverse gebruikersgroepen.
