{"id":21435,"date":"2026-09-15T18:21:14","date_gmt":"2026-09-15T16:21:14","guid":{"rendered":"https:\/\/webhosting.de\/redis-acls-multi-user-umgebungen-sicherheit\/"},"modified":"2026-09-15T18:21:14","modified_gmt":"2026-09-15T16:21:14","slug":"redis-acls-omgevingen-met-meerdere-gebruikers-beveiliging","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/redis-acls-multi-user-umgebungen-sicherheit\/","title":{"rendered":"Redis ACL\u2019s veilig inzetten voor omgevingen met meerdere gebruikers"},"content":{"rendered":"<p>Ik stel <strong>redis acl<\/strong> in multi-user-omgevingen doelgericht in om commando\u2019s, sleutelprefixen en Pub\/Sub-kanalen strikt van elkaar te scheiden. Zo zorg ik voor <strong>Beveiliging<\/strong> aan de serverzijde: beperk onjuiste toegangsverzoeken tot een minimum en zorg ervoor dat rollen duidelijk te beheren zijn.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Scheiding<\/strong> van commando's, sleutels en kanalen per gebruiker<\/li>\n  <li><strong>Aan de serverzijde<\/strong> Controle in plaats van logica in de app<\/li>\n  <li><strong>Naamruimten<\/strong> per sleutelprefix per klant<\/li>\n  <li><strong>ACL-bestand<\/strong> voor onderhoudbaarheid en versiebeheer<\/li>\n  <li><strong>Audits<\/strong> met ACL LIST en ACL USERS<\/li>\n<\/ul>\n\n<h2>Basisprincipes van ACL\u2019s in multi-user-omgevingen<\/h2>\n\n<p>Ik maak voor elke toepassing, elk team of elke klant een aparte gebruiker aan en stel diens rechten strikt in via <strong>ACL<\/strong>-regels. Zo voorkom ik dat \u00e9\u00e9n enkel algemeen wachtwoord alle deuren opent en dat gegevens per ongeluk worden overschreven. Ik verdeel rechten op basis van commando\u2019s, 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 <strong>Transparantie<\/strong> in het beveiligingsmodel. Juist in gedeelde instanties behoud ik zo het overzicht over wie welke bewerking in welke naamruimte mag uitvoeren.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-acl-umgebung-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rechtenmodellen: commando\u2019s, sleutels en kanalen duidelijk van elkaar scheiden<\/h2>\n\n<p>Ik ken beheerrechten gedetailleerd toe, bijvoorbeeld per categorie zoals <strong>@lezen<\/strong> en @write, en verwijder risicovolle groepen zoals @dangerous, die configuratie- of beheerderscommando\u2019s 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 <strong>Scheiding<\/strong> tussen rollen, datarooms en communicatiekanalen.<\/p>\n\n<h2>Pub\/Sub veilig beperken<\/h2>\n\n<p>Voor Pub\/Sub sta ik uitsluitend de kanalen toe die een applicatie echt nodig heeft, en sluit ik al het andere consequent uit <strong>ACL<\/strong>-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 <strong>Controle<\/strong> over gegevensstromen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_acl_sicherheit_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gebruikers- en regelbeheer in de praktijk<\/h2>\n\n<p>Ik maak nieuwe gebruikers aan met ACL SETUSER, wijs een sterk wachtwoord toe en activeer precies die commando\u2019s die de dienst nodig heeft, bijvoorbeeld <strong>+@lezen<\/strong> 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 <strong>Administratie<\/strong> beknopt, begrijpelijk en reproduceerbaar.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>ACL-\/Auth-commando<\/th>\n      <th>Doel<\/th>\n      <th>Voorbeeld<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>ACL SETUSER<\/td>\n      <td>Gebruiker aanmaken\/wijzigen<\/td>\n      <td>ACL SETUSER app1 on &gt;veiligWachtwoord +@read +@write -@dangerous ~app1:*<\/td>\n    <\/tr>\n    <tr>\n      <td>ACL-LIJST<\/td>\n      <td>Regels weergeven<\/td>\n      <td>ACL-LIJST<\/td>\n    <\/tr>\n    <tr>\n      <td>ACL-GEBRUIKERS<\/td>\n      <td>Gebruikers weergeven<\/td>\n      <td>ACL-GEBRUIKERS<\/td>\n    <\/tr>\n    <tr>\n      <td>ACL LADEN\/OPSLAAN<\/td>\n      <td>ACL-bestand laden\/opslaan<\/td>\n      <td>ACL SAVE; ACL LOAD<\/td>\n    <\/tr>\n    <tr>\n      <td>AUTH<\/td>\n      <td>Aanmelding bij de server<\/td>\n      <td>AUTH app1 veiligWachtwoord<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Configuratie: ACL-bestand of redis.conf?<\/h2>\n\n<p>Ik sla eenvoudige instellingen rechtstreeks op in de <strong>redis.conf<\/strong>, maar bij meerdere gebruikers en rollen houd ik het bij \u00e9\u00e9n 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 <a href=\"https:\/\/webhosting.de\/nl\/redis-beveiliging-open-poorten-beveiligen-cacheserver-gevorderd\/\">open poorten beveiligen<\/a> en onnodige kwetsbare punten weg te werken. Alles bij elkaar genomen verhoogt dat de <strong>Beveiliging<\/strong> en vereenvoudigt het gebruik.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/secure-redis-acl-multiuser-8172.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Naamruimten en scheiding van klanten<\/h2>\n\n<p>Ik ontwerp sleutelprefixen zo dat ze tenant-ID\u2019s en applicatienamen duidelijk weergeven, bijvoorbeeld <strong>tenantA:<\/strong>app1:session:{id}. Zo cre\u00eber ik een duidelijk zichtbare afscherming rond de gegevens van elke partij, die bovendien door ACL-regels wordt beveiligd. Voor migratietrajecten gebruik ik consistente naamgevingsschema\u2019s, 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 <strong>Klanten<\/strong> netjes gescheiden.<\/p>\n\n<h2>Microservices en teamrollen in de dagelijkse praktijk<\/h2>\n\n<p>Ik stel per service \u00e9\u00e9n 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\u2019s 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 <strong>Productief<\/strong>-Gegevens bewerken. Zo verdeel ik de verantwoordelijkheden duidelijk, zonder de beveiliging te verzwakken.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_acls_tech_office_7432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Beperkingen van ACL's en isolatieniveaus<\/h2>\n\n<p>Ik interpreteer ACL's correct: ze controleren de toegang, maar zorgen niet voor isolatie <strong>Bronnen<\/strong> zoals CPU, RAM of I\/O op procesniveau. In strenge compliance-scenario\u2019s 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 <strong>afscherming<\/strong> voor een hoger veiligheidsniveau.<\/p>\n\n<h2>Bedrijf: audits, rotatie en logboekregistratie<\/h2>\n\n<p>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\u2019s of ontbrekende voorvoegsels in configuraties signaleren. Dit <strong>Procedure<\/strong> bespaart tijd en beperkt bedrijfsonderbrekingen tot een minimum.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_acls_multiuser_env_7435.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Architectuurkeuzes: gedeeld of toegewezen<\/h2>\n\n<p>Ik overweeg of meerdere klanten \u00e9\u00e9n gemeenschappelijke instantie gaan gebruiken of dat ik afzonderlijke servers ga inrichten, aangezien beide hun eigen <strong>Risico's<\/strong> en voordelen heeft. Shared bespaart kosten, maar vereist strikte ACL\u2019s, 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 <a href=\"https:\/\/webhosting.de\/nl\/redis-gedeeld-versus-dedicated-prestaties-veiligheid-cacheboost\/\">Gedeeld versus toegewijd<\/a> ik bekijk het en voer belastingstests uit. Uiteindelijk neem ik een beslissing op basis van gegevenstoegang, compliance-eisen en <strong>Budget<\/strong>.<\/p>\n\n<h2>Cluster of standalone \u2013 wat past bij ACL\u2019s?<\/h2>\n\n<p>Ik pas ACL\u2019s 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 <strong>Breuk<\/strong> 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 <a href=\"https:\/\/webhosting.de\/nl\/redis-cluster-versus-standalone-bij-webhosting-en-redis-hosting\/\">Cluster versus standalone<\/a> zich hierop richten en vervolgens de ACL-strategie op de juiste manier implementeren.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-acls-umgebung-1678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planning en Bootstrap: een veilige start<\/h2>\n\n<p>Ik begin met een schone Bootstrap. De ingebouwde \u201edefault\u201c-gebruiker krijgt geen uitgebreide rechten: ofwel schakel ik hem volledig uit, ofwel ontneem ik hem standaard alle commando\u2019s, 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.<\/p>\n\n<pre><code># Veilige opstart in het ACL-bestand\nuser default off\nuser admin on &gt;SterkAdminWachtwoord +@admin -@dangerous allkeys allchannels\n<\/code><\/pre>\n\n<p>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 \u00e9\u00e9n stap, wat de protocolversie expliciet vastlegt en randgevallen voorkomt.<\/p>\n\n<h2>Patronen en valkuilen bij sleutel- en kanaal-ACL\u2019s<\/h2>\n\n<p>Bij sleutelpatronen werk ik uitsluitend met toestemmingslijsten. Ik begin met <em>resetknoppen<\/em> 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 <em>kanalen resetten<\/em> en verleen alleen &amp;tenantA:* en uitsluitend de kanalen die nodig zijn voor Keyspace-meldingen, indien aanwezig.<\/p>\n\n<pre><code># Sleutels en kanalen strikt\nACL SETUSER tenantA:app1 on &gt;Pass +@read +@write -@dangerous \\\n  resetkeys ~tenantA:app1:* \\\n  resetchannels &amp;tenantA:app1:* \n<\/code><\/pre>\n\n<p>Ik merk op dat commando\u2019s zoals RENAME, MIGRATE of DUMP\/RESTORE over prefixgrenzen heen zouden kunnen schrijven. Dergelijke commando\u2019s blijven geblokkeerd in productieve serviceaccounts. Hash-velden, lijstitems of leden van gesorteerde sets zijn geen afzonderlijke sleutels \u2013 de ACL is van toepassing op sleutelniveau, niet binnen de gegevensstructuur. Daarom volstaat een duidelijk concept voor sleutelprefixen om ook deze structuren te dekken.<\/p>\n\n<h2>Commando-categorie\u00ebn bewust sturen<\/h2>\n\n<p>Ik activeer alleen wat ik echt nodig heb. Voor klassieke CRUD-workloads volstaan vaak +@read en +@write. Categorie\u00ebn met een verhoogd risico blokkeer ik altijd: <strong>@admin<\/strong> en <strong>@dangerous<\/strong> 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\u2019s (+COMMAND) toe in plaats van hele categorie\u00ebn vrij te geven.<\/p>\n\n<h2>Rotatie en wijzigingen zonder downtime<\/h2>\n\n<p>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 <em>resetpass<\/em> 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.<\/p>\n\n<pre><code># Rotatieprocedure\nACL SETUSER app1 &gt;NieuwWachtwoord # nieuw wachtwoord extra instellen\n# Clients omzetten ...\nACL SETUSER app1 resetpass &gt;NieuwWachtwoord # oud wachtwoord verwijderd, nieuw wachtwoord blijft behouden\n<\/code><\/pre>\n\n<h2>Tests, foutopsporing en audits verdiepen<\/h2>\n\n<p>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.<\/p>\n\n<pre><code># Rechten simuleren\nACL DRYRUN app1 GET otherprefix:key\n# huidige gebruikersidentiteit controleren\nACL WHOAMI\n# mislukte toegangspogingen bekijken\/resetten\nACL LOG\nACL LOG RESET\n# commando\u2019s per categorie weergeven\nACL CAT @write\n<\/code><\/pre>\n\n<p>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.<\/p>\n\n<h2>Scripting, functies en veilige uitvoering<\/h2>\n\n<p>Lua-scripts en server-side functies zijn krachtig \u2013 maar kunnen ook een potenti\u00eble 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.<\/p>\n\n<h2>Replicatie, hoge beschikbaarheid en consistentie van de ACL's<\/h2>\n\n<p>In gerepliceerde opstellingen scheid ik applicatiegebruikers van replicatiegebruikers. Voor de replicatie richt ik een speciaal technisch account in, dat alleen de commando\u2019s krijgt die nodig zijn voor SYNC\/PSYNC\/REPLCONF en dergelijke. Ik houd het ACL-bestand op alle knooppunten synchroon \u2013 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.<\/p>\n\n<p>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 (\u201e\u00e9\u00e9n prefix, \u00e9\u00e9n gegevensruimte, veel slots\u201c). Tijdens een failover zorg ik ervoor dat replicatiegebruikers en beheerdersaccounts al beschikbaar zijn op het doelnode, zodat de omschakeling transparant verloopt.<\/p>\n\n<h2>Verandering van klant, migraties en back-ups<\/h2>\n\n<p>Bij het hernoemen van prefixen of tenant-ID\u2019s houd ik vooraf rekening met de gevolgen voor de ACL\u2019s. 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 \u2013 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.<\/p>\n\n<h2>Client-integratie en beveiligde protocollen<\/h2>\n\n<p>Aan de clientzijde maak ik consequent gebruik van gebruikersnaam\/wachtwoord, in plaats van een globale \u201erequirepass\u201c te gebruiken. Voor moderne clients gebruik ik de HELLO-handshake om de protocolversie en authenticatie in \u00e9\u00e9n 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.<\/p>\n\n<pre><code># Voorbeeld: authenticatie in \u00e9\u00e9n stap\nHELLO 3 AUTH app1 veiligWachtwoord\n<\/code><\/pre>\n\n<h2>CI\/CD-automatisering en configuratiesjablonen<\/h2>\n\n<p>Ik modelleer ACL\u2019s als code. Rollen en gebruikers worden gegenereerd op basis van sjablonen, die ik per omgeving vul met variabelen (voorvoegsel, kanalen, categorie\u00ebn). In de pijplijn vinden validaties plaats: linters controleren of er geen @dangerous\/@admin-commando\u2019s in service-accounts terechtkomen, tests voeren DRYRUN\u2019s uit op representatieve sleutels en een smoke-test-container start kort op tegen een ge\u00efsoleerde Redis-instantie om AUTH, GET\/SET en Pub\/Sub end-to-end te verifi\u00ebren. Wijzigingen worden pas uitgerold als alle controles groen zijn, en bij een rollback is het vorige ACL-bestand onmiddellijk beschikbaar.<\/p>\n\n<h2>Operationele details: zichtbaarheid en opruimen<\/h2>\n\n<p>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 \u2013 wat vooral in complexe toolchains van groot belang is. Ik ruim regelmatig \u201ezombie\u201c-accounts op: gedeactiveerde diensten verliezen hun gebruikers (\u201eoff\u201c), wachtwoorden worden verwijderd (\u201eresetpass\u201c), sleutel- en kanaalrechten worden gewist (\u201eresetkeys\u201c, \u201eresetchannels\u201c). Ik houd me aan naamgevingsconventies voor gebruikers (bijvoorbeeld team_service_env), wat audits en incidentrespons versnelt.<\/p>\n\n<h2>Kort samengevat<\/h2>\n\n<p>Ik ben van plan <strong>ACL's<\/strong> Vanaf het begin maak ik per dienst een gebruiker aan en beperk ik diens commando\u2019s, 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\u2019s houd ik bovendien rekening met architecturale scheiding, zodat toegangscontrole en technische isolatie op elkaar aansluiten. Zo wordt een gedeelde Redis-instantie een beheersbare, <strong>veilig<\/strong> Platform voor diverse gebruikersgroepen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Redis ACL's voor omgevingen met meerdere gebruikers zorgen voor meer Redis-beveiliging door middel van duidelijke gebruikersrechten, sleutelregels en gecontroleerde toegang.<\/p>","protected":false},"author":1,"featured_media":21428,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-21435","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"107","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"redis acl","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21428","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21435","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21435"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21435\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21428"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21435"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21435"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21435"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}