Hoe je bedrijfskritische software beveiligd en onderhoudt

Ergens in uw bedrijf zit een systeem dat, als het een dag uitvalt, ervoor zou zorgen dat facturen niet verstuurd worden, orders niet gepickt worden, of uw serviceteam geen klanten kan helpen. De meeste bedrijven weten precies welk systeem dat is. Veel minder bedrijven kunnen met zekerheid zeggen wie het laatst de toegangsrechten heeft gecontroleerd, wanneer het voor het laatst is geback-upt en getest, of wat er gebeurt als de ontwikkelaar die het heeft gebouwd vertrekt.

Dit artikel loopt door wat het werkelijk kost om bedrijfskritische software op lange termijn veilig en onderhoudbaar te houden — niet als eenmalig project, maar als doorlopende discipline.

Wat maakt software eigenlijk "bedrijfskritisch"?

Een systeem krijgt deze aanduiding wanneer het uitvallen directe, onmiddellijke financiële of operationele gevolgen heeft. Nuttige testvragen:

• Als dit systeem 4 uur down is, stopt de inkomstenstroming dan?
• Als dit systeem een hele dag down is, merken klanten dat?
• Is er een handmatig alternatief, of stopt het werk gewoon?

Voor veel mkb's gaat het om een ERPsysteem, een aangepaste FileMaker-applicatie voor orderverwerking of magazijnlogistiek, of een API-connector die orders synchroniseert tussen een webshop en boekhoudingsoftware. Als het eerlijke antwoord op een van de bovenstaande vragen "ja" is, hoort het systeem in een formeel beveiligings- en continuiteitplan — niet alleen in het hoofd van degene die het heeft gebouwd.

Waarom worden aangepaste en legacy-systemen verwaarloosd op het gebied van beveiliging?

Off-the-shelf SaaS-producten drukken beveiligingsupdates meestal automatisch door en adverteren hun nalevingscertificeringen luidruchtig. Zelf gebouwde of op platforms gebaseerde systemen — een FileMaker-oplossing van tien jaar geleden, een reeks Excel-macro's die stilletjes kritiek werd, een intern hulpmiddel waarvan niemand meer weet dat het is aangeschaft — adverteren hun risico niet op dezelfde manier. Die stilte wordt voor veiligheid aangezien.

In de praktijk gaan meestal drie dingen fout:

1. Niemand is verantwoordelijk. De oorspronkelijke ontwikkelaar is vertrokken, naar een ander team gegaan, of was een freelancer die niet meer bereikbaar is. Niemand is verantwoordelijk voor het patchen of controleren ervan.
2. Toegang stapelt zich op. Accounts worden aangemaakt voor projecten, aannemers en stagiairs, en worden nooit verwijderd. Twee jaar later hebben zes voormalige werknemers nog steeds inloggegevens voor het ordersysteem.
3. "Het werkt nog steeds" wordt behandeld als "het is nog steeds veilig". Een systeem kan aan de buitenkant perfect draaien terwijl het draait op een niet-ondersteunde database-engine, een verouderde plug-in, of een certificaat dat zonder dat iemand het merkt is verlopen tot een klant klaagt dat hun formulieren niet laden.

Hoe ziet een echt beveiligings- en onderhoudsplan eruit?

Een werkbaar plan voor een bedrijfskritisch systeem bestrijkt vier lagen. Het overslaan van een daarvan is hoe bedrijven eindigen met een systeem dat is geback-upt maar niet veilig, of veilig maar zonder continuiteitplan als de server sterft.

1. Toegangscontrole

• Elk gebruikersaccount is gekoppeld aan een benoemd persoon — nooit een gedeelde login.
• Toegang is op rollen gebaseerd: een magazijnmedewerker hoeft geen toegang tot prijstabellen; een financieel gebruiker hoeft geen beheerdersrechten over het databaseschema.
• Toegang wordt minstens twee keer per jaar gecontroleerd, en direct wanneer iemand vertrekt.
• Beheerder-/ontwikkelaarsaccounts gebruiken multi-factor authenticatie, punt uit — dit is het account dat aanvallers eerst aanvallen omdat het alles ontgrendelt.

2. Gegevensbescherming

• Gegevens worden versleuteld onderweg (TLS) en, waar het platform dit ondersteunt, in rust.
• Backups draaien automatisch — en worden teruggezet op een testsysteem volgens een schema, niet alleen aangemaakt en blindelings vertrouwd. Een backup die niemand ooit heeft teruggezet, is een hoop, geen plan.
• Gevoelige velden (salarissgegevens, persoonlijke klantgegevens, medische of HR-gegevens) krijgen extra beveiligingmogelijkheden op veldniveau of encryptie, niet alleen dezelfde toegangsregels als alles anders.

3. Patch- en afhankelijkheidsbeheer

• Server-OS, database-engine en alle plug-ins of connectoren volgen een gedocumenteerd updateschema — niet "wanneer iemand eraan denkt".
• Plug-ins van derden zijn het meest vergeten onderdeel: een FileMaker-oplossing die gebruik maakt van een oude streepjescode-scan-plug-in die jaren niet is bijgewerkt, is een echt, veel voorkomend voorbeeld van een stille kwetsbaarheid in een ander goed draaiend systeem.
• Updates worden getest in een staging-kopie van het systeem voordat productie wordt aangeraakt — een vijf minuten durende controle die talloze bedrijven heeft gered van een update die een kritiek script midden op de werkdag breekt.

4. Continuïteit en herstel

• Een schriftelijk, specifiek antwoord op: "Als deze server vannacht verdwijnt, wat doen we morgenochtend?"
• Een benoemd persoon (niet "IT" in het algemeen) verantwoordelijk voor het starten van herstel.
• Een geteste hersteltijd — geen veronderstelde. Veel bedrijven ontdekken dat hun werkelijke hersteltijd 3 dagen is, niet de 3 uur die ze aannahmen, alleen tijdens een werkelijke storing.

Hoe veranderen AI-tools en low-code-invoegingen het beveiligingsplaatje?

Moderne bedrijfssystemen pluggen steeds vaker extra mogelijkheden in in plaats van alles vanaf nul op te bouwen — een AI-assistent die inkomende facturen leest, een service zoals Klai die conversatie-AI bovenop een FileMaker-database voegt, of een formulierhulpmiddel zoals FmBetterforms dat webvriendelijke formulieren rendert voor een systeem dat als desktoptoepassing begon. Deze toevoegingen verbeteren echt bruikbaarheid en snelheid. Ze openen ook elk een nieuwe deur die dezelfde governance nodig heeft als het coresysteem:

• Welke gegevens ziet de invoegtoepassing werkelijk? Een AI-laag die klantrecords leest om vragen te beantwoorden, heeft dezelfde toegangscontrole nodig als een menselijke werknemer.
• Waar gaan de gegevens naartoe? Als een AI-service gegevens buiten uw eigen infrastructuur verwerkt, dat is een nieuwe gegevensverwerkingsrelatie — het hoort thuis in uw gegevensbeschermingsbeleid en, in de EU, uw GDPR-documentatie.
• Wie patcht de connector? Een formulierlaag of AI-integratie is nog steeds software. Het heeft een benoemd eigenaar nodig en een plek in het patchschema, net als de database zelf.

De fout die u moet vermijden, is deze tools als "gewoon een plug-in" te behandelen die buiten het beveiligingsgesprek staat. In de praktijk zijn het nieuwe eindpunten naar hetzelfde kritieke systeem en moeten ze als zodanig worden beheerd.

Wie zou dit eigenlijk dagelijks moeten bezitten?

Beveiliging en continuïteit falen meestal niet door gebrek aan hulpmiddelen, maar door gebrek aan een benoemd eigenaar. Een werkbaar model voor de meeste mkb's:

• Een bedrijfseigenaar of IT-manager die het risicodecision bezit — hoeveel downtime is aanvaardbaar, welk budget continuïteit krijgt.
• Een ontwikkelaar of technische partner (intern of extern) die de technische uitvoering bezit — patchen, backups, toegangsconfiguratie.
• Een kort schriftelijk beleid, zelfs één pagina, waarin staat wie wat doet en hoe vaak. Het hoeft geen 40-pagina compliancedocument te zijn om effectief te zijn; het hoeft gewoon daadwerkelijk te worden nageleefd.

Praktische checklist: wordt uw bedrijfskritische systeem daadwerkelijk gedekt?

• We weten precies welke systemen in ons bedrijf bedrijfskritisch zijn.
• Elk gebruikersaccount is benoemd, niet gedeeld, en twee keer per jaar gecontroleerd.
• Beheerder- en ontwikkelaarstoegang vereist multi-factor authenticatie.
• Backups zijn automatisch en test-teruggezet volgens een schema.
• Er is een gedocumenteerd patchschema voor het OS, database en alle plug-ins/connectoren.
• Updates worden getest op een staging-kopie voordat ze live gaan.
• Er is een schriftelijk, benoemd herstellplan met een geteste hersteltijd.
• Alle AI-tools of invoegingen die met het systeem zijn verbonden, zijn gecontroleerd op gegevenstoegang en verwerkingslocatie.
• Één benoemd persoon bezit dit plan — en controleert het minstens jaarlijks.

Als u vandaag de meeste van deze vakken niet kunt aanvinken, dat is niet ongebruikelijk — het is de normale staat waarin de meeste bedrijven ontdekken dat hun kritieke systeem eigenlijk in is, zodra iemand eindelijk de vraag stelt.

Veelgestelde vragen

Hoe vaak moet een bedrijfskritisch systeem een beveiligingscontrole ondergaan? Minimaal jaarlijks, en na enige grote wijziging — een nieuwe integratie, een nieuw AI-hulpmiddel verbonden, een wijziging van hostingprovider, of een wijziging in wie beheerderstoegang heeft.

Is een aangepast FileMaker-systeem minder veilig dan een off-the-shelf ERP? Niet van nature — FileMaker-systemen kunnen met sterke encryptie, op rollen gebaseerde toegang en audit-registratie worden gebouwd. Het risico ligt niet in het platform, maar in of het systeem een actieve eigenaar heeft die het geupdatet en gecontroleerd houdt. Een niet-onderhouden ERP is net zo blootgesteld als een niet-onderhouden FileMaker-app.

Wat is de eerste stap met de grootste impact als we dit nog nooit hebben gedaan? Voer eerst de toegangscontrole uit. Het is de snelste manier om echte blootstelling te vinden — voormalige werknemers, gedeelde logins, te brede machtigingen — en het kost niets behalve tijd.

Verhoogt het toevoegen van AI aan ons systeem onze nalevingsverplichting? Vaak ja, vooral onder GDPR als persoonlijke gegevens door een AI-service van derden worden verwerkt. Het is de moeite waard om precies in kaart te brengen welke gegevens de AI-laag bereiken voordat u dit bedrijfswijd uitrolt, niet erna.

Dit soort controle sluit direct aan bij de bredere vraag hoe een bedrijf zijn softwarelandschap veilig, veerkrachtig en goed bestuurd houdt in de loop van de tijd — een thema dat dieper wordt onderzocht in het kennisdomein Security, Continuity and Governance van Loggix.

Als deze checklist meer gaten aan het licht bracht dan u verwachtte, dat is een normaal startpunt, geen crisis. Loggix werkt met bedrijven precies in dit soort situatie — het reviseren van het toegangsmodel en de updategeschiedenis van een bestaand FileMaker- of ERP-systeem, het bouwen of versterken van de API-integraties en AI-tools die ermee zijn verbonden, en het uitstippelen van een realistisch, geprioriteerd plan zodat beveiliging en continuïteit niet langer afhankelijk zijn van iemands geheugen en deel uitmaken van hoe het systeem draait.