Woensdag 21 oktober om 15:43 kwam de beveiligingsupdate voor het grote PHP-lek uit. Om 16:56 waren RTL en Tweakers weer online, zo staat in het liveblog van de NOS. Hoe snel je na zo'n update weer veilig online bent, hangt vooral af van de route die een update moet afleggen voordat hij in productie staat.
Patchmanagement is het vaste proces waarmee je weet welke software je draait, updates binnenhaalt, test en uitrolt. Met een CI/CD-pipeline is een kritieke beveiligingsupdate een gewone wijziging: je verhoogt een versienummer, de pipeline bouwt en test, en na akkoord staat de update live. Terug naar de vorige versie is dan een kwestie van de vorige build opnieuw uitrollen.
Wat patchmanagement is, en wat het PHP-lek liet zien
Patchmanagement gaat verder dan op een knop drukken. Je moet weten welke versies er draaien, waar je updates vandaan komen, hoe je test dat alles nog werkt en hoe de update in productie komt. Valt een van die vier weg, dan wordt elke update een gok, en gokken stel je uit.
Waar je updates vandaan komen, bleek bij het PHP-lek meer uit te maken dan veel teams dachten. Volgens de advisory van het PHP-project kregen Linux-distributies en leveranciers met langdurige ondersteuning de patches al vóór de publicatie. Wie PHP-pakketten uit de door vrijwilligers onderhouden bron rpms.remirepo.net haalde, kreeg het advies over te stappen op de pakketten van de distributie of PHP zelf te bouwen, omdat daar die dag geen updates zouden komen. Twee servers met dezelfde PHP-versie konden dus uren verschillen in hoe snel ze veilig waren.
Wat je bij zo'n lek in de eerste uren doet, lees je in ons blog over de PHP-kwetsbaarheid van oktober. Dit blog gaat over de route die je daarvoor nodig hebt.
Waarom handmatig patchen vastloopt
Wie traag patcht, loopt meestal vast op de manier waarop servers en releases zijn ingericht:
- Servers die ooit met de hand zijn ingericht, wijken in de loop van de jaren van elkaar af. Niemand weet precies wat erop staat, dus elke update voelt als een risico.
- Zonder automatische tests betekent elke update dat iemand handmatig door de applicatie klikt. Dat kost een dag, dus updates worden opgespaard.
- Beheer werkt de server bij, de ontwikkelaars horen het pas als er iets stuk is. Een PHP-update die de applicatie breekt, wordt dan teruggedraaid en daarna vergeten.
Het gevolg is voorspelbaar: kleine updates blijven liggen, en als er een kritiek lek komt, moet je in één keer drie versies inhalen onder tijdsdruk.
Patchmanagement met CI/CD: zo werkt het
Met CI/CD wordt een update een wijziging zoals elke andere, via dezelfde route:
- Versies staan in code. De PHP-versie staat in het Dockerfile of in de serverconfiguratie in versiebeheer, de pakketversies in
composer.lock. Een update is een wijziging van één regel, bijvoorbeeld vanphp:8.4.26-apachenaarphp:8.4.27-apache. - Een bot meldt nieuwe versies. Renovate of Dependabot zet automatisch een voorstel klaar zodra er een nieuwe versie van een image of pakket is.
- De pipeline bouwt en test. Elke wijziging doorloopt dezelfde stappen: bouwen, unit- en integratietests, securityscans en uitrollen naar een testomgeving.
- Uitrollen gaat in stappen. Eerst een deel van de servers of gebruikers, dan de rest. Lopen de fouten op, dan stopt de uitrol vanzelf.
- Terug kan altijd. Het vorige image staat klaar, dus terugdraaien is de vorige versie opnieuw uitrollen.
Bij DevOps en CI/CD bouwen wij precies die route: een pipeline die een wijziging van commit tot productie brengt, met bouwen, testen, quality gates en uitrollen zonder handmatige stappen. De servers zelf leggen we vast als code, met Terraform voor de inrichting en Ansible voor de configuratie, zodat elke omgeving opnieuw op te bouwen is. Een server waar niemand meer aan durft te komen, bestaat dan niet.
Afspraken die je vooraf maakt
Een pipeline lost het technische deel op. Woensdag liet zien dat er ook beslissingen genomen moeten worden, en die neem je liever op een rustige dag:
- Een termijn per ernst. Bijvoorbeeld: een kritiek lek dat van buitenaf te misbruiken is, gaat dezelfde dag live; de rest gaat mee met de volgende gewone release.
- Wie beslist over offline gaan. Iemand moet de afweging kunnen maken tussen een site uit de lucht en het risico van een lek, ook buiten kantoortijd.
- Wie wat bijwerkt. Leg met je leverancier en hostingpartij vast wie het besturingssysteem, PHP, de applicatie en de plugins bijwerkt, en hoe snel. Wat je verder vóór de start van een project vastlegt, staat in ons blog over vendor lock-in bij maatwerksoftware.
- Wat je klanten hoort. Een korte melding op de site of in het portaal voorkomt telefoontjes en geruchten als je even offline moet.
Waar je begint
Je hoeft niet alles tegelijk om te bouwen. Begin met de applicatie met het meeste risico: die met een openbare inlog of met persoonsgegevens. Zet de versies daarvan in code, bouw er een pipeline omheen en zorg dat je na een uitrol ziet of het goed gaat. Wij richten monitoring zo in dat logging, metrics en alerts binnen seconden laten zien wanneer foutpercentages of prestaties veranderen, met drempels die we samen met het operationsteam bepalen.
Oefen de route daarna met een update die niet dringend is. De eerste keer dat een pipeline een PHP-update uitrolt, moet niet tijdens een crisis zijn. Werkt het, neem dan de volgende applicatie.
Veelgestelde vragen
Wat is het verschil tussen patchmanagement en updates installeren?
Updates installeren is één handeling. Patchmanagement is het proces eromheen: weten wat je draait, nieuwe versies opmerken, testen, uitrollen en vastleggen wat er is gebeurd. Zonder dat proces blijft installeren afhankelijk van wie er die dag aan denkt.
Moeten updates automatisch naar productie?
Niet per se. Bouwen en testen gaan automatisch, de stap naar productie kan een akkoord van een mens vragen. Voor kleine updates van pakketten met goede tests kiezen veel teams wel voor volledig automatisch.
Werkt dit ook voor WordPress of een standaardpakket?
Ja. Ook een WordPress-site kan in een container draaien met de PHP-versie in code, en plugin-updates kunnen eerst langs een testomgeving. Bij een pakket dat de leverancier host, gaat het vooral om afspraken over wie wanneer bijwerkt.
Hoe snel moet een kritieke update erop?
Dat hangt af van het lek en van wat er op het systeem staat. Een lek dat zonder inlog van buitenaf te misbruiken is, zoals dat in PHP, wil je dezelfde dag dicht hebben. Leg die termijn vooraf vast, dan hoeft niemand er op het moment zelf over te discussiëren.
Wil je weten hoe snel jouw applicaties een kritieke update kunnen krijgen, of waar de route nu vastloopt? Neem contact met ons op voor een kort gesprek. Je krijgt binnen 24 uur antwoord.
