Magento security-onderhoud: wat hoort er in je contract?

Een onderhoudscontract dat "security" noemt zegt weinig. Dit hoort er concreet in te staan, en dit zijn de vragen waarmee je het controleert.

Veel Magento-shops hebben een contract met een bureau of hostingpartij. Op papier staat er "onderhoud en beveiliging". In de praktijk betekent dat soms: één keer per jaar een update, als iemand eraan denkt. Bij de grote lekken van de afgelopen jaren bleek hoe duur dat is. Wat TrojanOrders, CosmicSting en SessionReaper ons leren komt in dat artikel aan bod. Hier gaat het om de praktijk: wat laat je vastleggen?

Waarom "security" in een contract vaag blijft

Security is geen product maar een reeks gewoontes. Een contract moet die gewoontes benoemen. Anders heb je geen basis om iets te eisen als het misgaat.

Let op deze signalen van een vaag contract:

• Het woord "beveiligingsupdates" zonder termijn.
• Geen onderscheid tussen kritieke patches en gewone updates.
• Geen rapportage, dus je weet niet wat er is gedaan.
• Alles "naar redelijkheid" of "op verzoek".

Een goed contract is specifiek, ook over wat er niet in zit.

1. Patchritme en reactietijd op kritieke lekken

Dit is het belangrijkste onderdeel. Adobe publiceert security-releases en losse patches, en zodra een lek bekend is, begint de klok. Aanvallers scannen bij kritieke lekken razendsnel op kwetsbare shops. Dat zagen we bij CosmicSting en SessionReaper.

Laat vastleggen:

• Reactietijd bij kritieke lekken. Binnen hoeveel uur of werkdagen wordt een kritieke patch beoordeeld en uitgerold? Een getal in het contract, niet "zo snel mogelijk".
• Ritme voor gewone security-releases. Bijvoorbeeld maandelijks of per release.
• Wie beslist. Wordt de patch altijd uitgerold, of wacht men op jouw akkoord? Bij een kritiek lek wil je niet drie dagen op een akkoord wachten.
• Hoe wordt uitgerold. Via staging, met een test van checkout en betaling, en zonder downtime waar het kan. Hoe dat werkt lees je in security patches zonder downtime.

Wij kunnen hier geen vast getal voor je invullen, want dat hangt af van je shop en je risico. Een shop met veel omzet per uur wil een kortere reactietijd dan een nichewinkel. Maar het getal moet er staan.

2. Extensie-updates en beoordeling van third-party code

Veel kwetsbaarheden zitten niet in Magento zelf maar in extensies. Een goed contract beschrijft:

• Hoe vaak extensies worden bijgewerkt en door wie.
• Wat er gebeurt als een extensie niet meer wordt onderhouden.
• Of nieuwe extensies vooraf worden beoordeeld voordat ze live gaan.
• Of er composer audit of vergelijkbare controles in het proces zitten.

Een extensie die niet meer wordt bijgewerkt is een risico dat je moet benoemen, niet verstoppen. Meer hierover staat in Magento-extensies veilig houden.

3. Monitoring

Monitoring vangt wat patchen niet vangt: een gestolen wachtwoord, een nieuwe admin, een wijziging op de betaalpagina. Vraag wat er precies bewaakt wordt.

• Bestandswijzigingen op productie.
• Nieuwe admin-gebruikers en wijzigingen in configuratie.
• Beschikbaarheid en foutpercentages van de checkout.
• Wie ontvangt het alarm, en wie handelt het af?

Het laatste punt wordt vaak vergeten. Een alarm dat in een mailbox belandt die niemand leest, is geen monitoring. We schreven daar meer over in incident response en monitoring voor webshops.

4. Back-ups en herstel

Een back-up die je nooit hebt teruggezet, is een aanname. Laat vastleggen:

• Wat er wordt geback-upt: database, media, app/etc/env.php en configuratie, en code in git.
• Hoe lang back-ups bewaard blijven.
• Of back-ups buiten de productieserver staan, zodat een aanvaller ze niet kan wissen.
• Of er een restore-test is, en hoe vaak.

5. Toegangsbeheer, 2FA en rollen

Magento heeft sinds versie 2.4.0 standaard 2FA voor de admin. Een contract hoort te regelen dat dat ook aan blijft en dat het beheer van gebruikers klopt.

• Wie heeft admin-toegang, en wie keurt nieuwe accounts goed?
• Worden vertrokken medewerkers en oud-medewerkers van het bureau direct verwijderd?
• Zijn rollen beperkt tot wat mensen nodig hebben?
• Is de admin extra afgeschermd, bijvoorbeeld met een IP-allowlist of VPN?

Het ontbreken van dit onderdeel zien wij bij overnames vaak: accounts van voormalige freelancers die nog actief zijn. Meer praktische instellingen staan in Magento admin beveiligen en in het artikel over brute force op de admin.

6. Rapportage

Zonder rapportage weet je niet of er iets gebeurt. Vraag om een korte, vaste terugkoppeling.

• Welke patches en updates zijn uitgerold, en wanneer?
• Welke kwetsbaarheden zijn open, en wat is het plan?
• Welke incidenten of afwijkingen zijn er geweest?
• Welke versie van Magento en PHP draait er, en wanneer loopt de ondersteuning af? Zie Magento 2.4 versies en end-of-support.

Een halve pagina per maand is genoeg. Het gaat om zichtbaarheid, niet om dikke documenten.

7. Versie- en PHP-beleid

Een shop op een versie zonder ondersteuning krijgt geen security-patches meer, hoe goed het onderhoud verder ook is. Het contract hoort te zeggen wie bewaakt wanneer een upgrade nodig is, en hoe dat wordt begroot. Anders sta je met een verlopen versie en een verrassingsfactuur.

Wat zit er meestal niet in, en waarom

Een eerlijk contract noemt ook wat niet is inbegrepen. Dat is geen trucje, het voorkomt ruzie later.

Waarom apart? Een pentest of audit is een eenmalige, diepgaande beoordeling. Een onderhoudscontract is doorlopend werk. Dat zijn verschillende dingen. Hoe die zich verhouden lees je op /security/audit en /security/pentest.

Opruimen na een hack hoort er meestal niet in, omdat de omvang niet te voorspellen is. Wel hoort er in te staan wat de afspraak is als het gebeurt: wie pakt het op, met welke prioriteit?

Vragen die je aan je huidige partij kunt stellen

Neem deze lijst mee naar je volgende gesprek. De antwoorden zeggen veel.

1. Wat was de laatste kritieke patch die jullie hebben uitgerold, en hoeveel dagen na publicatie?
2. Hoe testen jullie een patch voordat die live gaat?
3. Wie krijgt het alarm als er iets afwijkt op productie, ook in het weekend?
4. Wanneer is er voor het laatst een back-up teruggezet?
5. Welke extensies in mijn shop worden niet meer onderhouden?
6. Wie heeft er nu admin- en servertoegang tot mijn shop?
7. Op welke Magento- en PHP-versie zitten we, en tot wanneer is die ondersteund?
8. Wat doen jullie als er een hack is, en wat kost dat?

Als een partij hier niet snel en concreet op antwoordt, weet je genoeg.

Wanneer is een zwaar contract overkill?

Niet elke shop heeft 24/7-bewaking nodig. Een kleine shop met weinig omzet, weinig extensies en een gehoste betaalpagina kan prima met een lichtere variant: maandelijkse updates, een afgesproken reactietijd op kritieke lekken en goede back-ups. Zwaarder wordt het pas zinvol als stilstand of een datalek snel veel geld kost, of als je zelf kaartgegevens in je checkout verwerkt en onder PCI DSS valt.

Het draait om de verhouding tussen risico en kosten. Reken uit wat een dag stilstand je kost en wat een hack kost, en leg dat naast de prijs van het contract.

Hoe wij het aanpakken

Bij Coding werk je niet met een servicedesk of accountmanager. Je praat met het vaste team dat ook de patches uitrolt. Dat betekent korte lijnen als er iets kritieks speelt, en afspraken die we kunnen nakomen omdat de mensen die ze maken ook het werk doen. Wat we doen staat op /magento-support en /security/magento.

Veelgestelde vragen

Wat kost Magento security-onderhoud?

Dat hangt af van de omvang van je shop, het aantal extensies, hoeveel custom code er is en welke reactietijd je wilt. Vraag altijd een offerte op basis van een korte scan van je huidige situatie, en vergelijk wat er precies in zit, niet alleen de prijs.

Is patchen niet gewoon automatisch?

Nee. Magento past patches niet vanzelf toe. Iemand moet ze beoordelen, installeren, testen en uitrollen. Bij custom code of veel extensies kan een patch iets breken, dus testen op staging hoort erbij.

Moet een kritieke patch binnen 24 uur live?

Bij actief misbruikt lek is snel handelen verstandig. Of 24 uur haalbaar is hangt af van de patch, je testproces en je shop. Leg een realistische reactietijd vast en zorg dat de partij in het weekend ook bereikbaar is.

Valt een pentest onder onderhoud?

Meestal niet. Een pentest is een aparte, eenmalige opdracht met eigen scope. Onderhoud houdt je shop op niveau, een pentest toetst of dat voldoende is.

Hoe controleer ik of mijn bureau echt patcht?

Vraag welke versie en welke patches nu op productie staan en vergelijk met wat Adobe heeft gepubliceerd. Vraag om rapportage met datums. Een partij die dit niet kan laten zien, doet het waarschijnlijk niet structureel.

Wil je weten hoe jouw huidige afspraken ervoor staan? Neem contact op en we lopen de punten uit dit artikel samen door, zonder verplichtingen.