Waarom een server opzetten niet hetzelfde is als een hostingplatform

Als een site online is, lijkt de basis vaak “goed genoeg”. Er staat een server. Packages zijn geïnstalleerd. Nginx antwoordt. Klaar.

Tot er iets misgaat. Of tot er een CVE binnenkomt. Of tot je een tweede project op dezelfde machine zet en merkt dat alles dezelfde rechten deelt.

Een webapplicatie is meer dan de applicatiecode. Er draait PHP, een database, een webserver, een Linux-basis, certificaten, backups, logs en monitoring. Securitymeldingen landen ergens in die keten. Soms in Composer. Soms in een Ubuntu-package. Soms in de manier waarop processen op de host mogen werken.

Daarom behandelen wij hosting niet als iets wat je na livegang “even regelt”. Als je niet weet wat er draait, hoe projecten van elkaar zijn gescheiden, of hoe je dezelfde inrichting opnieuw kunt uitrollen, wordt beheer al snel reactief. Dan patch je op gevoel. Of je durft niet te patchen, omdat niemand meer precies weet wat er kapot kan gaan.

Met platform bedoelen we: elke server start vanaf hetzelfde fundament. Elk project krijgt een eigen, voorspelbare plek. Wijzigingen gaan via Ansible, niet via een SSH-sessie die niemand documenteert.

Onze basis is Ubuntu Server LTS. Daarop staat een vaste set defaults voor firewall, SSH, updates, logging, PHP, nginx en database. Staging en productie gebruiken dezelfde bouwstenen. Staging precies hetzelfde. Maar dan nog meer afgeschermd van de buitenwereld (allowlist, basic auth).

Als omgevingen dezelfde bouwstenen delen, kun je triage en patching structureel doen. Is elke host anders, dan is elke securitymelding opnieuw detectivewerk.

Een paar principes die bij ons niet optioneel zijn:

• Processen krijgen alleen de rechten die ze nodig hebben
• Eén beveiligingslaag is nooit genoeg
• Servers en projecten staan in code, zodat je kunt zien wat er is veranderd
• Updates horen erbij, maar niet blind: eerst context, dan actie
• Zonder metrics en logs gok je
• Backups horen bij de standaarduitrol, niet bij “dat regelen we later”

Keuzes die je kunt uitleggen als iemand vraagt waarom een project zo is ingericht.

Op OS-niveau houden unattended upgrades de basis bij. Linux-packages krijgen CVE’s, net als frameworks.

Op applicatieniveau werken we zoals in ons CVE-verhaal: een score is input, geen automatisch besluit. Eerst kijken of de component echt draait, of de functionaliteit bereikbaar is, of configuratie/isolation al iets mitigeert, en wat een update doet met maatwerk en koppelingen.

Blind alles tegelijk updaten klinkt daadkrachtig. Het is vooral een manier om twee problemen tegelijk te krijgen: een half begrepen CVE en een half begrepen regressie.

We rollen servers en projecten uit met Ansible. “Infrastructure as Code” klinkt zeker mooi, het is ook gewoon heel praktisch. Handwerk schaalt niet. En is ook niet makkelijk te reviewen. Zeker niet als je losse commando's over SSH uitvoert. In de praktijk betekent dit dus. Een nieuwe server is gebruikmaken van een gestandaardiseerd playbook. Een nieuw project, gebruiken van het gestandaardiseerde deploy playbook die alles volgens onze wensen configureert(domeinen, PHP, databases). Alle secrets zijn encrypted en dus nooit plaintext in git.

Staging gebruikt de exact zelfde methodes. Maar dan nog iets meer authenticatie ervoor zodat we deze projecten kunnen testen zonder dat deze al open staan voor het hele internet.

Die speciaal opgezette servers die alleen één persoon snapt zijn in de praktijk een security- en availability-risico. Een verbeteringsstap op één machine is geen verbetering van het platform; het is een uitzondering die je later weer vergeet, niet goet uitwerkt, of geen rekening mee houdt.