Magento admin beveiligen in acht lagen: 2FA, admin URL, IP-allowlist, rollen en rechten, sessies, API-tokens, logging en offboarding. Praktisch stappenplan.
Je Magento admin is de deur naar je klantdata, je prijzen en je betalingsinstellingen. Toch staat die deur bij veel shops nog op /admin, met één gedeeld account en zonder IP-beperking.
Onze Magento 2 security checklist loopt over de volle breedte. Dit artikel gaat diep op één onderdeel: wie komt er in je backend, hoe, en wat kunnen ze daar doen. Je werkt acht lagen af, van binnen naar buiten.
Dit is technische informatie, geen garantie dat je shop niet gehackt wordt. Controleer instellingen altijd tegen de documentatie van jouw Magento-versie.
Overzicht: de acht lagen
| Laag | Wat het doet | Waar je het instelt |
|---|---|---|
| 1. 2FA | Tweede factor bij login | Magento_TwoFactorAuth |
| 2. Admin URL | Haalt de default-route weg | env.php / config |
| 3. IP-allowlist | Alleen bekende netwerken bereiken /admin | nginx, Varnish, Cloudflare |
| 4. Rollen en rechten | Least privilege per persoon | System > Permissions |
| 5. Sessie en wachtwoord | Beperkt schade bij gestolen sessie | Stores > Configuration > Advanced > Admin |
| 6. API en integraties | Tokens met minimale scope | System > Integrations |
| 7. Logging | Zien wie wat deed | Logs, webserver, extensie |
| 8. Offboarding | Toegang direct weg bij vertrek | Proces plus checklist |
1. Magento 2FA: aan laten staan
Vanaf Magento 2.4 zit 2FA voor de admin standaard in de installatie, via de module Magento_TwoFactorAuth. Adobe vermeldt in de Admin security-documentatie dat 2FA vereist is voor de Admin.
In de praktijk zie je dat ontwikkelaars de module uitzetten op staging en dat die instelling mee naar productie gaat. Dat is de fout die we het vaakst tegenkomen in discussies rond admin-incidenten.
Concreet:
- Controleer op productie of de module actief is:
bin/magento module:status Magento_TwoFactorAuth. - Laat geen enkele admin-gebruiker zonder tweede factor toe.
- Kies een authenticator-app (TOTP) boven e-mail of SMS. Welke providers je versie ondersteunt, staat in Stores > Configuration > Security > 2FA. Controleer dat per versie.
- Sla de herstelprocedure op: wie reset 2FA als iemand zijn telefoon verliest? Leg dat vast voordat het gebeurt.
Let op: op internet circuleren handleidingen om 2FA uit te zetten via module:disable. Dat is bedoeld voor lokale ontwikkeling. Zet het nooit uit op een omgeving met echte klantdata. Gebruik op development liever een aparte bypass-module of -configuratie die niet in je productie-deploy terechtkomt.
Twee dingen die 2FA niet oplost:
- Phishing van een live sessie. Een aanvaller die je cookie steelt, heeft je tweede factor niet nodig.
- Kwetsbaarheden die zonder login werken. Daarom blijft patchen nodig, zie security patches zonder downtime.
2. Magento admin URL wijzigen
De admin-route staat in app/etc/env.php onder backend > frontName. Standaard is dat admin. Adobe adviseert in dezelfde documentatie een custom Admin URL die lastig te raden is.
Zo pak je het aan:
- Kies een frontName die niet in woordenlijsten staat. Geen
beheer,backendofbestelling. - Pas hem aan in
env.phpof viabin/magento setup:config:set --backend-frontname="jouw-route". - Draai daarna
bin/magento cache:flush. - Zet "Add Secret Key to URLs" aan (Stores > Configuration > Advanced > Admin > Security).
- Zorg dat monitoring, deploy-scripts en je team de nieuwe URL kennen.
De eerlijke versie: een verborgen URL is geen beveiliging. Het is ruisfilter. Bots die blind /admin proberen, vallen weg. Een gerichte aanvaller vindt de route alsnog. Reken het daarom nooit als vervanging voor 2FA of een IP-filter.
3. Magento admin IP whitelist
Dit is de sterkste laag voor weinig werk. Als alleen jouw kantoor-IP en VPN de admin kunnen bereiken, kan de rest van de wereld niet eens een loginformulier zien.
Je hebt drie plekken om dit te doen. Kies bij voorkeur zo ver mogelijk vooraan.
Cloudflare
Bij gebruik van Cloudflare maak je een firewallregel (WAF custom rule) die verkeer naar het pad van je admin blokkeert, tenzij het IP in je allowlist zit. Alternatief is Cloudflare Access, waarbij medewerkers inloggen met hun bedrijfsidentiteit. De exacte regelsyntax en plangrenzen wijzigen regelmatig, check de actuele Cloudflare-documentatie.
Varnish
Varnish kan in VCL requests naar het admin-pad afhandelen en een 403 teruggeven voor IP's die niet in een ACL staan. Let op dat Varnish achter een load balancer of Cloudflare het echte client-IP uit een header moet halen. Doe je dat verkeerd, dan sta je iedereen toe of sluit je jezelf buiten.
nginx
Op de webserver zet je in de location voor je admin-pad allow-regels voor je eigen IP's, gevolgd door deny all. Concept:
location /jouw-admin-route { allow; allow ; deny all; ... } - Op Hypernode doe je dit via de beschikbare nginx-configuratie en
hypernode-systemctl-instellingen. Raadpleeg hun documentatie voor de juiste plek.
Vergeet niet:
- Het pad is nu ook geblokkeerd voor de webhooks of integraties die erop leunen. Test of je REST- en GraphQL-endpoints buiten het admin-pad blijven werken.
- Dynamische IP's thuis zijn lastig. Een VPN met vast uitgaand IP is stabieler dan elke week je allowlist aanpassen.
- Houd een noodroute: SSH-toegang waarmee je de regel kunt aanpassen als je jezelf buitensluit.
4. Magento rollen en rechten
Eén account admin dat vijf mensen delen, is het slechtste scenario. Je weet niet wie wat deed, en je kunt niemand afsluiten zonder iedereen af te sluiten.
Werk volgens least privilege:
- Elk persoon heeft een eigen account. Geen gedeelde logins.
- Maak rollen onder System > Permissions > User Roles. Per rol vink je alleen de resources (ACL) aan die nodig zijn.
- Geef de rol "Alle resources" alleen aan de mensen die echt beheerder zijn. Houd dat getal klein.
- Rechten die gevaarlijk zijn en zelden nodig: gebruikers en rollen beheren, integraties beheren, configuratie wijzigen, cache- en indexbeheer, en alles rond betalings- en verzendmethodes.
Een werkbare opzet voor een gemiddelde shop:
| Rol | Mag wel | Mag niet |
|---|---|---|
| Content/marketing | CMS, blokken, promoties | Configuratie, gebruikers, integraties |
| Klantenservice | Orders, klanten, creditnota's | Catalogus, configuratie, gebruikers |
| Catalogusbeheer | Producten, categorieën, voorraad | Orders, betaling, gebruikers |
| Developer (extern) | Alleen wat nodig is, tijdelijk | Gebruikers en rollen beheren |
| Owner | Alles | Niets, maar beperk tot 1-2 personen |
Voor externe partijen geldt: geef een eigen account met einddatum. Plan het afsluiten in je agenda op de dag dat je het account aanmaakt.
5. Sessie en wachtwoord
In Stores > Configuration > Advanced > Admin staan de instellingen voor sessie en inlogbeveiliging. De Adobe-documentatie beschrijft ze. Relevante velden:
- Admin Session Lifetime: in seconden. Korter betekent minder tijd voor misbruik van een achtergelaten of gestolen sessie. Een uur of korter is voor de meeste teams werkbaar. Dat is onze richtlijn, geen Adobe-norm.
- Maximum Login Failures to Lockout Account: volgens de documentatie standaard 6.
- Lockout Time: volgens de documentatie standaard 30 minuten.
- Password Lifetime: volgens de documentatie standaard 90 dagen. Leeg betekent geen verloop.
- Add Secret Key to URLs: zet aan, zie hierboven.
Daarnaast:
- Gebruik een wachtwoordmanager. Lange unieke wachtwoorden verslaan complexe wachtwoorden die je herhaalt.
- Voeg CAPTCHA toe aan de admin-login als je het IP-filter niet kunt gebruiken. Adobe noemt dit als optie in de security-documentatie.
- Check of de standaardwaarden in jouw versie kloppen. Ze wijzigen niet vaak, maar controleer ze.
6. API- en integratietokens
Je admin is niet de enige toegang. Elke integratie onder System > Extensions > Integrations krijgt een token. Dat token werkt buiten je 2FA en buiten je IP-filter om, tenzij je dat apart afdekt.
- Geef elke integratie alleen de API-resources die het nodig heeft.
- Eén integratie per koppeling. Zo kun je er één intrekken zonder de rest te breken.
- Verwijder integraties die niemand meer gebruikt. Controleer de lijst per kwartaal.
- Bewaar tokens in een secret manager of de omgevingsvariabelen van je koppeling. Niet in code of tickets.
- Roteer een token direct als iemand met toegang vertrekt.
Meer over het afdekken van koppelingen lees je in API-beveiliging voor e-commerce integraties.
7. Logging: wie deed wat
Hier zit een verschil tussen edities. Volgens leveranciers van audit-extensies, zoals Moogento, heeft Adobe Commerce een eigen action log (System > Action Log) en mist Open Source die module. Die bronnen verkopen zelf extensies, dus controleer dit in de officiële Adobe-documentatie voor jouw versie.
Wat je in Open Source in elk geval zelf regelt:
- Webserver-logs. Bewaar toegangslogs van het admin-pad. Je ziet IP's, tijden en loginpogingen.
- Failed logins monitoren. Alarm bij pieken in mislukte logins of logins vanaf onbekende landen.
- Een audit-extensie als je per wijziging wilt zien wie wat deed. Beoordeel die op onderhoud en op wat hij opslaat, want logs bevatten zelf ook gevoelige data.
- Database- of bestandsintegriteit. Wijzigingen in
core_config_dataof nieuwe admin-gebruikers zijn verdachte signalen. Een nieuw admin-account dat jij niet aanmaakte, is de klassieke aanwijzing van een inbraak.
Zie je zoiets? Volg dan het stappenplan in Magento 2 gehackt: wat nu?.
8. Offboarding: de vergeten laag
Een ex-medewerker met werkende admin-toegang is een risico dat niemand opmerkt, tot er iets gebeurt. Maak er een vaste checklist van:
- [ ] Admin-account op inactief zetten of verwijderen (System > Permissions > All Users)
- [ ] Sessies van die gebruiker beëindigen
- [ ] 2FA-device ontkoppelen
- [ ] Integratietokens die die persoon beheerde roteren
- [ ] VPN- en IP-allowlist bijwerken
- [ ] SSH-sleutels en hosting-toegang intrekken
- [ ] Wachtwoordmanager en gedeelde kluizen opschonen
- [ ] Toegang tot Cloudflare, payment provider en e-mailsystemen controleren
Doe dit op de laatste werkdag, niet de week erna. Voor externe bureaus geldt hetzelfde bij einde samenwerking.
Volgorde als je weinig tijd hebt
Begin hier, in deze volgorde:
- Controleer dat 2FA op productie actief is voor iedereen.
- Zet een IP-allowlist op het admin-pad.
- Ruim accounts op en maak rollen met least privilege.
- Verkort de sessie en controleer de lockout-instellingen.
- Loop je integratietokens na.
- Pas de admin URL aan en zet de secret key aan.
- Zet logging en alarmering op.
- Maak de offboarding-checklist vast onderdeel van je proces.
Meer over onze aanpak vind je op de security-pagina. Wil je dat iemand dit structureel bewaakt, kijk dan naar Magento support.
Veelgestelde vragen
Is 2FA verplicht in Magento 2?
Vanaf Magento 2.4 zit 2FA voor de admin standaard in de installatie en noemt Adobe het vereist. Technisch kun je de module via de command line uitschakelen. Doe dat alleen op lokale ontwikkelomgevingen, nooit op productie.
Helpt het wijzigen van de admin URL echt?
Een beetje. Het stopt bots die blind /admin proberen. Het houdt geen gerichte aanvaller tegen. Combineer het altijd met 2FA en een IP-allowlist.
Waar blokkeer ik het beste het admin-pad op IP?
Zo ver mogelijk voor je applicatie: Cloudflare of een andere WAF, daarna Varnish of nginx. Hoe eerder het verkeer stopt, hoe minder belasting en minder aanvalsoppervlak. Test na afloop of je API's en webhooks nog werken.
Heeft Magento Open Source een admin action log?
Volgens leveranciers van audit-extensies heeft alleen Adobe Commerce een ingebouwde action log. Voor Open Source heb je webserver-logs en eventueel een extensie nodig. Controleer dit in de Adobe-documentatie voor jouw versie.
Hoe vaak moet ik admin-accounts controleren?
Minimaal elk kwartaal, en altijd bij personeelswisselingen of het einde van een samenwerking met een extern bureau. Controleer ook integratietokens en IP-allowlists.
Hulp nodig bij het afdichten van je admin?
Wil je weten hoe jouw backend ervoor staat? Neem contact op. We kijken mee naar 2FA, IP-filtering, rollen en tokens, en geven je een concrete lijst van wat eerst moet.

Geschreven door Ruthger Idema
15+ jaar ervaring in e-commerce development. Gespecialiseerd in Magento, Shopify en Laravel maatwerk.
Meer over ons team →


