VIOMS Blog

Blog

  • Netwerksegmentatie: waarom één vlak netwerk risico is

    Netwerksegmentatie: waarom één vlak netwerk risico is

    Eén plat netwerk: alles ziet alles

    In veel MKB-omgevingen is het netwerk in de loop van de jaren organisch gegroeid. Er is één subnet, één wifi-netwerk en één switch-configuratie waar alles op aangesloten wordt: laptops, de bestandsserver, printers, de NAS, de camerarecorder, de thermostaat, het tijdregistratiesysteem en de kassa. Dat werkt, tot het moment dat één apparaat besmet raakt of iemand met kwade bedoelingen op het gastnetwerk zit.

    In een plat netwerk hoeft een aanvaller namelijk niets bijzonders te doen om verder te komen. Vanaf één besmette laptop is de hele adresreeks bereikbaar: bestandsshares, remote desktop, de beheerinterface van de switch en apparaten die nog op hun standaardwachtwoord staan. Die zijwaartse beweging door het netwerk is precies de fase waarin ransomware van één werkplek naar de hele organisatie uitbreidt. Segmentatie maakt die stap moeilijker en bovendien zichtbaar.

    Drie apparaatgroepen die u zeker apart zet

    Niet elk netwerk hoeft in tien zones opgedeeld te worden. Begin met de groepen waar het risico het grootst is en de scheiding het eenvoudigst te realiseren.

    Gasten en BYOD

    Bezoekers, telefoons van medewerkers en alles waar u geen beheer over heeft.

    • Eigen SSID met client-isolatie
    • Alleen internet, geen toegang tot het LAN
    • Bandbreedte begrenzen zodat gasten geen capaciteit opeisen

    Camera’s, IoT en gebouwbeheer

    Apparaten die zelden updates krijgen en vaak jaren blijven hangen.

    • Geen internettoegang tenzij aantoonbaar nodig
    • Alleen bereikbaar vanaf de recorder of beheersoftware
    • Standaardwachtwoorden vervangen en vastleggen

    Kassa’s en betaalautomaten

    Systemen met een smalle, goed te definiëren verkeersstroom.

    • Eigen segment met minimale firewallregels
    • Alleen verkeer naar de leverancier of payment provider
    • Op deze apparaten niet mailen of browsen

    Van apparaatgroepen naar zones

    Zodra u dit doortrekt naar de hele omgeving, ontstaat een beperkt aantal zones met per zone een duidelijke afspraak over wat er in en uit mag. Onderstaande indeling werkt voor de meeste organisaties met tien tot tweehonderdvijftig werkplekken.

    ZoneVoorbeeldenInternetToegang tot andere zones
    WerkplekkenLaptops, desktops, dockingstationsJaAlleen naar servers en printers, op specifieke poorten
    Servers en opslagBestandsserver, applicatieserver, NASBeperkt en uitgaandGeen initiatief naar werkplekken
    BeheerSwitches, access points, firewall, out-of-band managementNeeAlleen bereikbaar vanaf beheerwerkplek of VPN
    TelefonieVoIP-toestellen, DECT-basisstationsJa, naar de providerGeen
    Gasten en BYODBezoekers, privételefoonsJaGeen, met client-isolatie
    IoT en camera’sCamera’s, sensoren, deurbeheer, klimaatNee of sterk beperktAlleen naar de bijbehorende recorder of controller
    BetaalverkeerKassa’s, pinautomatenAlleen naar de payment providerGeen

    VLAN’s aanmaken is niet hetzelfde als segmenteren

    Een VLAN scheidt broadcastdomeinen, niet meer dan dat. De winst zit in wat er op de grens tussen die VLAN’s gebeurt. Zonder filtering op de zonegrens heeft u vooral een overzichtelijker netwerk gemaakt, geen veiliger netwerk. Vier punten die het verschil maken:

    • Standaard staat al het verkeer tussen zones dicht en opent u alleen wat aantoonbaar nodig is: DNS, DHCP-relay, printen, authenticatieverkeer en de poorten van uw applicaties.
    • Het beheernetwerk is niet bereikbaar vanaf werkplekken. Beheer gaat via een aparte werkplek of via VPN.
    • Wifi volgt dezelfde indeling: een eigen SSID per zone, of dynamische VLAN-toewijzing op basis van 802.1X. Zie ook wifi-oplossingen.
    • Log wat op de zonegrens geblokkeerd wordt. Die logs vertellen u binnen een week welke verkeersstromen u vergeten was, en later of iemand aan het rondkijken is.

    De firewall is hierin het centrale punt, maar bij grotere omgevingen doet ook de core switch een deel van het routeren en filteren. Wat past bij uw situatie hangt af van het aantal locaties en het type applicaties; dat komt aan de orde in het netwerkontwerp.

    Wat NIS2 en uw verzekeraar hiervan vinden

    Netwerksegmentatie staat in vrijwel elk raamwerk voor basismaatregelen, en komt terug in de risicobeheersmaatregelen rond NIS2 en in de vragenlijsten van cyberverzekeraars. Wat daarbij vaak onderschat wordt: niet alleen de techniek telt, maar ook de vastlegging. Een actuele netwerktekening, een adresplan, een overzicht van de regels op de zonegrens en de reden waarom een uitzondering bestaat, zijn precies de documenten waar een auditor of schadebehandelaar om vraagt.

    Wilt u eerst weten of uw organisatie onder de richtlijn valt en wat er dan van u verwacht wordt? Lees dan wat de NIS2-richtlijn voor uw bedrijf betekent. Voor de vastlegging en periodieke controle is compliance en auditing het vertrekpunt, en voor de inrichting van de zonegrens netwerkbeveiliging.

    Zo voert u het in zonder de zaak plat te leggen

    Segmentatie invoeren in een bestaand netwerk is vooral een kwestie van volgorde. De grootste risico’s zitten niet in de techniek, maar in vergeten apparaten en onbekende verkeersstromen.

    1. Inventariseer wat er werkelijk aan het netwerk hangt, inclusief de vergeten thermostaat, de deurbel en het apparaat dat een leverancier drie jaar geleden heeft opgehangen.
    2. Groepeer op functie en risico, niet op afdeling. Twee laptops van verschillende afdelingen horen in dezelfde zone; een camera en een laptop niet.
    3. Maak een adresplan en beschrijf per zone welke communicatie noodzakelijk is. Dit is het moment om leveranciers te vragen welke poorten hun apparatuur nodig heeft.
    4. Bouw de nieuwe zones naast het bestaande netwerk op, zodat u kunt terugvallen als iets niet werkt.
    5. Migreer per groep en begin met de minst kritische: gasten en camera’s eerst, servers en kassa’s als laatste.
    6. Test per zone met een schone laptop wat wel en niet bereikbaar is. Vertrouw niet op de configuratie, maar op de meting.
    7. Zet monitoring en logging aan en beoordeel de regelset elk kwartaal opnieuw.

    Veelgemaakte fouten

    • Tijdens de migratie regels ruim openzetten om verder te kunnen, en ze daarna nooit meer dichtzetten.
    • Printers in het serversegment plaatsen, waardoor iedere werkplek daar alsnog bij moet.
    • Beheerinterfaces van switches en access points in het werkplek-VLAN laten staan.
    • Eén wifi-netwerk voor personeel en gasten, met alleen een ander wachtwoord als scheiding. Zie ook BYOD-beleid: risico’s en best practices.
    • Niets documenteren, waardoor na een jaar niemand meer weet waarom een uitzondering is gemaakt.

    Begin met weten wat er hangt

    Segmentatie hoeft geen project van maanden te zijn. In de meeste omgevingen levert een inventarisatie plus drie extra zones al het grootste deel van de risicoreductie op, zonder dat gebruikers er iets van merken. Wij brengen uw huidige netwerk in kaart, geven aan welke zones voor uw situatie zinvol zijn en wat de invoering praktisch betekent. Bekijk ook onze aanpak voor netwerkbeheer

    Plan een adviesgesprek
  • Proactief beheer: storing voorkomen in plaats van melden

    Proactief beheer: storing voorkomen in plaats van melden

    Reactief beheer is duurder dan het lijkt

    De meeste IT-problemen kondigen zich aan. Een schijf die vol loopt, een back-up die twee nachten mislukt, een certificaat dat verloopt, een access point dat elke nacht herstart: dat zijn allemaal signalen die dagen tot weken voor de storing zichtbaar zijn. Bij reactief beheer ziet niemand ze, en begint het werk pas als de eerste medewerker belt dat iets niet meer werkt.

    Reken het voor uw eigen organisatie eens door. Veertig medewerkers die een halve dag niet bij de bestandsserver kunnen, zijn honderdzestig verloren uren. Daar komen de spoedkosten bij, plus het inhaalwerk en het gesprek met de klant die zijn levering niet op tijd kreeg. De aanpassing die de storing had voorkomen, was in dit voorbeeld een uur werk en een nieuwe schijf. Dat verschil is de kern van proactief beheer.

    Wat er continu gemeten wordt

    Proactief beheer is geen houding, maar een meetsysteem. Op elk relevant onderdeel van uw omgeving staat een agent of een controle die zich met vaste tussenpozen meldt. Blijft die melding uit, of komt er een waarde uit die buiten de afgesproken grens valt, dan ontstaat er een alert.

    Infrastructuur en servers

    De onderdelen waar een storing meteen de hele organisatie raakt.

    • Schijfruimte, geheugen en processorbelasting
    • Back-upjobs, foutmeldingen en restorepunten
    • Verlopende certificaten en licenties

    Netwerk en verbindingen

    Signalen die vaak al degraderen voordat iets echt uitvalt.

    • Beschikbaarheid van firewall, switches en access points
    • Pakketverlies en latency op de internetverbinding
    • Firmware- en patchniveau van apparatuur

    Werkplekken

    Klachten over trage laptops zijn meestal meetbaar te maken.

    • Schijfgezondheid, batterijstatus en temperatuur
    • Update- en antivirusstatus per apparaat
    • Terugkerende crashes en trage opstarttijden

    De signalen die een storing aankondigen

    Onderstaande voorbeelden komen uit de dagelijkse praktijk. Ze lijken klein, maar het zijn precies de meldingen die een dag uitval schelen.

    SignaalWat het vaak betekentWat er dan gebeurt
    Systeemschijf boven 85 procent gevuldUpdates gaan mislukken en de server loopt binnen weken vastOpschonen of uitbreiden in een gepland onderhoudsvenster
    SMART-meldingen op een harde schijfDe schijf gaat op korte termijn defectPreventief vervangen terwijl de omgeving nog draait
    Back-upjob twee nachten op rij misluktEr is op dit moment geen bruikbaar herstelpuntDirect onderzoek, want dit raakt uw hele herstelstrategie
    Certificaat verloopt binnen dertig dagenWebsite, VPN of mailflow valt op de vervaldatum uitVernieuwen en uitrollen voor de deadline
    Oplopend pakketverlies op de WAN-verbindingDe lijn of de apparatuur degradeertMelding bij de provider, onderbouwd met meetgegevens
    UPS-batterij aan het einde van zijn levensduurBij de eerste stroomstoring valt de server hard uitBatterij vervangen voor het stormseizoen
    Herstarts buiten het onderhoudsvensterHardware-, voeding- of geheugenprobleemLogs analyseren voordat het apparaat definitief uitvalt

    Dat tweede signaal over de back-up is het belangrijkste van de rij. Een back-upschema is alleen waard wat de laatste geslaagde run waard is; zie ook de 3-2-1 backup rule uitgelegd en onze back-up en disaster recovery.

    Een alert is nog geen oplossing

    Monitoring aanzetten is een middag werk. Er waarde uit halen is een proces. Zonder dat proces krijgt u vooral een mailbox vol meldingen die niemand meer leest, en dat is gevaarlijker dan geen monitoring, omdat het schijnzekerheid geeft. Wat er minimaal geregeld moet zijn:

    • Drempelwaarden per systeem in plaats van standaardwaarden. Een testserver op 90 procent schijfgebruik is geen incident, uw bestandsserver wel.
    • Ruis actief opruimen. Elke melding die drie keer geen actie opleverde, is een verkeerd ingestelde drempel.
    • Prioritering en escalatie: wie krijgt wat, binnen welke tijd, en wie wordt gebeld als er niemand reageert.
    • Duidelijkheid over dekking buiten kantooruren. Monitoring die 24 uur per dag meet maar van negen tot vijf wordt bekeken, is precies dat.
    • Elke alert eindigt in een ticket of een bewuste onderdrukking, zodat er achteraf navolgbaar is wat er gebeurd is.

    Bij werkplekbeheer en endpoint management zit dit proces standaard in de dienst, inclusief maandelijkse rapportage over wat er gemeten en opgelost is.

    Monitoring is geen securitymonitoring

    Een belangrijk misverstand: beschikbaarheidsmonitoring vertelt u of systemen werken en presteren, niet of iemand zich in uw omgeving heeft genesteld. Een aanvaller zorgt er juist voor dat alles normaal blijft draaien. Detectie van verdacht gedrag vraagt andere middelen: endpointdetectie, logverzameling en analyse door mensen die daar continu naar kijken.

    Dat zijn dus twee aparte lagen die u beide nodig heeft. Zie managed detection and response en incident response voor de securitykant, en netwerkmonitoring voor de beschikbaarheidskant.

    Zes vragen aan uw IT-partner

    Vrijwel elke IT-dienstverlener noemt zichzelf proactief. Deze vragen maken snel duidelijk wat daar in de praktijk achter zit.

    1. Wat wordt er precies gemonitord, en wat expliciet niet? Vraag om een lijst, niet om een geruststelling.
    2. Wat is de afgesproken reactietijd, en is dat ook een hersteltijd? Dat zijn twee verschillende afspraken.
    3. Wie kijkt er buiten kantooruren naar de meldingen, en hoe verloopt de escalatie ’s nachts?
    4. Ontvang ik een maandrapportage die ik aan de directie kan laten zien, met opgeloste en voorkomen incidenten?
    5. Welke acties voert u zelfstandig uit, en waarvoor vraagt u eerst toestemming?
    6. Hoeveel drempelwaarden zijn het afgelopen jaar bijgesteld? Een partij die daar geen antwoord op heeft, tunet niet.

    Van storingen naar onderhoud

    Het doel van proactief beheer is niet dat er nooit meer iets stukgaat, maar dat vervanging en onderhoud op een gepland moment gebeuren in plaats van op het slechtst mogelijke. Wij brengen in kaart wat er in uw omgeving nu wel en niet gemeten wordt, en wat de eerste tien controles zijn die het meeste opleveren.

    Plan een adviesgesprek
  • TeamCity-lek CVE-2026-63077 wordt actief misbruikt: dit moet je nu doen

    TeamCity-lek CVE-2026-63077 wordt actief misbruikt: dit moet je nu doen

    Gebruik je TeamCity On-Premises als CI/CD-server? Dan is dit het moment om even alles anders te laten liggen. JetBrains liet op 7 augustus 2026 weten dat het kritieke lek CVE-2026-63077 inmiddels daadwerkelijk wordt misbruikt door aanvallers. Servers die nog niet zijn bijgewerkt, lopen op dit moment een reëel risico op volledige overname.

    In dit artikel leggen we uit wat het lek precies doet, waarom juist een build- en releaseserver zo’n aantrekkelijk doelwit is, welke versies veilig zijn, hoe je stap voor stap controleert of jouw omgeving is geraakt en welke maatregelen je structureel zou moeten nemen.

    Wat is er aan de hand?

    JetBrains publiceerde eind juli 2026 een beveiligingsmelding over een kritieke kwetsbaarheid in TeamCity On-Premises, met kenmerk CVE-2026-63077. Tegelijk met die melding waren er al gepatchte versies en een losse patch-plug-in beschikbaar. Ruim een week later volgde een aanvullende waarschuwing: er komen meldingen binnen van zowel geslaagde als mislukte aanvalspogingen op TeamCity-servers die nog niet zijn bijgewerkt.

    Daarmee verschuift de situatie van “belangrijk om snel op te pakken” naar “nu direct handelen”. Zodra een kwetsbaarheid in het wild wordt uitgebuit, worden kwetsbare systemen doorgaans binnen enkele dagen geautomatiseerd gescand en aangevallen. Het maakt daarbij niet uit hoe klein of onbekend je organisatie is: aanvallers zoeken op poort en protocol, niet op naam.

    Gebruik je TeamCity Cloud? Dan hoef je zelf niets te doen. JetBrains heeft de benodigde maatregelen daar al doorgevoerd. Deze blog gaat dus specifiek over zelf beheerde (on-premises of in eigen cloudomgeving gehoste) TeamCity-servers.

    Waarom dit lek zo gevaarlijk is

    Er is geen inlog nodig

    De kwetsbaarheid is uit te buiten zonder authenticatie. Iedereen die via HTTP of HTTPS bij je TeamCity-server kan komen, kan de aanval uitvoeren via het protocol waarmee build-agents de server bevragen. Er zijn dus geen gestolen wachtwoorden, tokens of interne toegang nodig. Bij succes voert de aanvaller commando’s uit op het besturingssysteem, met dezelfde rechten als het TeamCity-serverproces.

    Je secrets liggen op één plek

    Een CI/CD-server is per definitie een verzamelplaats van gevoelige gegevens: verbindingsgegevens naar repositories, deploytokens voor productieomgevingen, cloud-credentials, certificaten en API-keys. Wordt de server overgenomen, dan zijn niet alleen de projectconfiguraties en build-historie in gevaar, maar in potentie alle systemen waar die server naartoe mag deployen.

    Supply chain-risico voor je eigen software

    Het meest onderschatte gevolg is manipulatie van de build zelf. Een aanvaller die build-stappen of artifacts kan aanpassen, kan kwaadaardige code meesturen in software die jij vervolgens zelf naar productie of naar je klanten uitrolt. Zo’n aanpassing valt niet op in je broncode, omdat de wijziging pas ná de checkout gebeurt. Dat maakt een gecompromitteerde buildserver tot een probleem dat verder reikt dan één server.

    Welke versies zijn veilig?

    JetBrains heeft het probleem verholpen in TeamCity 2025.11.7 en 2026.1.3. Draai je een oudere release en kun je niet meteen upgraden, dan is er een security patch plug-in beschikbaar voor TeamCity 2017.1 en nieuwer. Let op: die plug-in dicht uitsluitend dit ene lek en is dus een tijdelijke noodmaatregel, geen alternatief voor bijwerken.

    SituatieActie nodig?Wat je moet doen
    TeamCity 2025.11.x vóór 2025.11.7Ja, directBijwerken naar 2025.11.7
    TeamCity 2026.1.x vóór 2026.1.3Ja, directBijwerken naar 2026.1.3
    Oudere versies (vanaf 2017.1)Ja, directUpgraden, of tijdelijk de security patch plug-in installeren
    TeamCity 2025.11.7 / 2026.1.3 of nieuwerNeeWel controleren op eerdere aanvalspogingen
    TeamCity CloudNeeJetBrains heeft dit al afgehandeld

    Wat je nu moet doen

    1. Breng in kaart welke servers je hebt

    Begin met de vraag die vaak wordt overgeslagen: waar draait TeamCity eigenlijk allemaal? Naast de productie-instantie zijn er in de praktijk vaak vergeten test- of legacy-servers, of een oude instantie die “voor de zekerheid” nog aan staat. Controleer per server het versienummer en of de server vanaf internet bereikbaar is.

    2. Werk bij naar een gepatchte versie

    Bijwerken naar 2025.11.7 of 2026.1.3 is de enige volledige oplossing. Maak vooraf een back-up van de datamap en de database, plan een kort onderhoudsvenster en controleer na de upgrade of agents weer verbinden en builds normaal draaien. Loopt de upgrade over meerdere stappen? Zorg dan dat de server tijdens dat traject niet vanaf internet bereikbaar is.

    3. Kun je niet direct bijwerken? Dicht de deur

    Lukt bijwerken niet op korte termijn, installeer dan de security patch plug-in én beperk tegelijk de netwerktoegang. Staat de server publiek open, haal hem dan tijdelijk achter een VPN of firewallregel tot je de fix hebt toegepast. Externe bereikbaarheid intrekken is bijna altijd sneller te regelen dan een volledige upgrade, en verkleint het risico onmiddellijk.

    Controleren op misbruik: waar let je op?

    Patchen is stap één, maar de vraag “is er al iets gebeurd?” is even belangrijk. JetBrains noemt drie concrete aanwijzingen die je zelf kunt nalopen in de serverlogs en de beheerinterface.

    Verdachte logmelding

    Zoek in de TeamCity-serverlogs op com.thoughtworks.xstream.converters.ConversionException. Deze melding alleen bewijst geen inbraak, maar kan wijzen op een poging of een geslaagde aanval en verdient nader onderzoek.

    Geblokkeerde poging

    Heb je al gepatcht? Zoek dan op com.thoughtworks.xstream.security.ForbiddenClassException. Die melding betekent dat iemand het heeft geprobeerd nádat de fix actief was en dat de poging is tegengehouden.

    Onbekende build-agents

    Bekijk de lijst met niet-geautoriseerde agents. Onverwachte namen die met scan beginnen, duiden op een aanvalspoging tegen een server die van buitenaf bereikbaar was. Zulke agents mag je verwijderen.

    Belangrijk detail bij die laatste controle: de datum die bij een niet-geautoriseerde agent staat, zegt niets over het moment van de aanvalspoging. Gebruik voor tijdlijnen altijd de timestamps uit de logbestanden. Twijfel je over de interpretatie van je logs, dan kun je een ticket openen bij de TeamCity-support van JetBrains.

    Wat te doen bij een vermoeden van misbruik

    Vind je aanwijzingen dat de aanval bij jou is geslaagd, ga dan uit van een volledig gecompromitteerde server. Patchen alleen verwijdert namelijk niet wat een aanvaller al heeft achtergelaten of meegenomen. Werk in dat geval de volgende punten af:

    1. Isoleer de server van internet en van omgevingen waar hij naartoe kan deployen, voordat je verder onderzoekt.
    2. Bewaar bewijs. Maak kopieën van logs en van de datamap voordat je gaat opschonen of herinstalleren.
    3. Roteer alle secrets die op de server stonden: deploytokens, SSH-keys, cloud-credentials, certificaten en API-keys. Ga ervan uit dat alles wat de server kon lezen, is gelezen.
    4. Controleer build-configuraties op onverwachte wijzigingen, extra build-stappen of gewijzigde scripts.
    5. Verifieer recente artifacts en releases die na de eerste verdachte logregel zijn gebouwd, en bouw ze bij twijfel opnieuw vanaf een schone omgeving.
    6. Controleer accounts en rechten in TeamCity zelf en op de onderliggende server, inclusief nieuwe gebruikers, tokens en geplande taken.
    7. Documenteer je bevindingen en beoordeel of er een meldplicht geldt, bijvoorbeeld richting de Autoriteit Persoonsgegevens of vanuit NIS2-verplichtingen.

    Structurele maatregelen voor je CI/CD-omgeving

    Dit lek is opgelost, maar het volgende komt er ooit. Een buildserver verdient daarom dezelfde bescherming als je andere kroonjuwelen. Deze drie pijlers beperken de schade van een toekomstige kwetsbaarheid aanzienlijk:

    Netwerktoegang beperken

    • Niet direct aan het internet hangen
    • Toegang via VPN of extra beveiligingslaag
    • Alleen vertrouwde netwerken toestaan
    • Agents in een apart netwerksegment

    Minimale rechten

    • Serverproces met zo weinig rechten als mogelijk
    • Server op een eigen host, los van build-agents
    • Deploytokens beperken tot wat echt nodig is
    • Secrets in een kluis, niet in build-configuraties

    Patchen en monitoren

    • Vaste updateronde voor CI/CD-tooling
    • Abonneren op security-advisories van je leveranciers
    • Logs centraal wegschrijven en bewaren
    • Alerteren op onbekende agents en afwijkende builds

    De compliance-kant: dit is geen vrijblijvend advies

    Val je onder NIS2, dan is het tijdig verwerken van bekende kwetsbaarheden geen kwestie van goede bedoelingen, maar onderdeel van je zorgplicht. Aantoonbaar patchmanagement, logging die je daadwerkelijk kunt terugzoeken en een incidentproces dat werkt, zijn precies de onderdelen waar bij een audit of incident naar wordt gekeken. Een misgelopen update op een buildserver is dan niet alleen een technisch risico, maar ook een aantoonbaar tekortkomen in je beheerproces.

    Verwerk deze casus daarom ook administratief: leg vast wanneer je hebt gepatcht, wat je in de logs hebt gecontroleerd en welke conclusie je daaraan verbond. Dat kost een kwartier en is later goud waard.

    Conclusie

    CVE-2026-63077 is het type kwetsbaarheid waar je niet mee wilt wachten: geen authenticatie nodig, uitvoering van commando’s op de server en een doelwit dat toegang heeft tot vrijwel al je omgevingen. Nu er actief misbruik is gemeld, is bijwerken naar 2025.11.7 of 2026.1.3 de belangrijkste taak van vandaag. Direct daarna volgt de controle of er in jouw logs al sporen te vinden zijn.

    De volledige technische melding en de instructies voor de patch-plug-in staan in de aanvullende blogpost van JetBrains. Wil je hulp bij het bijwerken, het nalopen van je logs of het structureel dichtzetten van je CI/CD-omgeving? Neem dan contact met ons op.

    1. Actief misbruik gemeld: onbijgewerkte TeamCity On-Premises-servers worden nu daadwerkelijk aangevallen.
    2. Fix beschikbaar: update naar TeamCity 2025.11.7 of 2026.1.3; de patch-plug-in is enkel een tijdelijke noodoplossing.
    3. Geen inlog nodig: een aanvaller met HTTP(S)-toegang kan commando’s uitvoeren met de rechten van het serverproces.
    4. Controleer je logs op de genoemde exception-meldingen en je agentlijst op onbekende namen die met scan beginnen.
    5. Bij vermoeden van inbraak: isoleer, bewaar bewijs, roteer alle secrets en verifieer je recente builds.
    6. TeamCity Cloud-klanten hoeven zelf niets te doen.
  • Een SLA lezen: reactietijd is geen oplostijd

    Een SLA lezen: reactietijd is geen oplostijd

    Een serviceovereenkomst is het document waar niemand naar kijkt tot er iets stilstaat. Op dat moment blijkt de afspraak vaak iets anders te betekenen dan wat u ervan had onthouden. De belangrijkste bron van dat misverstand is één woord: reactietijd. Dat is niet de tijd waarin uw probleem is opgelost, en soms zelfs niet de tijd waarin er iemand aan begint.

    Vier termijnen die door elkaar lopen

    In vrijwel elke overeenkomst staan termijnen met verschillende betekenis. Zoek ze op in uw eigen contract en zet erbij wat er staat.

    TermWat het betekentWaar u op let
    ReactietijdTermijn waarin u antwoord krijgt dat de melding is ontvangenIs dat een mens of een automatische bevestiging?
    AanvangstijdTermijn waarin een engineer daadwerkelijk begintDeze term staat er vaak niet in, en dat is het gat
    OplostijdTermijn waarin de storing verholpen isMeestal een streven, geen garantie
    Tijdelijke oplossingWerkbare omweg terwijl de oorzaak nog open staatStopt hiermee de klok van de oplostijd?

    Een overeenkomst met een reactietijd van dertig minuten en geen aanvangstijd belooft in feite een snelle ontvangstbevestiging. Vraag daarom naar de gemiddelde en de hoogste doorlooptijd van de afgelopen zes maanden, uitgesplitst per prioriteit. Die cijfers bestaan in elk ticketsysteem en zeggen meer dan de tabel in het contract.

    Wie bepaalt de prioriteit?

    Alle termijnen hangen aan de prioriteit van de melding, en die wordt in de praktijk door de leverancier vastgesteld. Laat daarom in de overeenkomst opnemen welke situaties in elk geval de hoogste prioriteit krijgen: uw hele locatie zonder internet, uw bedrijfsapplicatie onbereikbaar, e-mail eruit, of een vermoeden van een securityincident. Leg ook vast wie bij u mag opschalen als u het niet eens bent met de indeling, en hoe. Een escalatiepad met functienamen en telefoonnummers is bruikbaarder dan een boeteclausule, want die boete is bijna altijd symbolisch ten opzichte van uw schade.

    Servicevenster en bereikbaarheid

    Termijnen gelden binnen het servicevenster. Is dat op werkdagen van acht tot zes en gaat uw fileserver op vrijdag om half zeven plat, dan begint de klok maandagochtend. Voor een organisatie die alleen kantoortijden werkt, is dat een verdedigbare keuze en scheelt het geld. Werkt u met ploegen, buitendienst of internationale klanten, dan heeft u een wachtdienst nodig en moet u weten wat een oproep buiten venster kost. Kijk ook naar de manier van melden: telefonisch, per e-mail of via een portaal, en of alleen aangewezen contactpersonen mogen melden. Onze helpdesk en de bijbehorende serviceafspraken beschrijven hoe wij dat inrichten.

    Wat er standaard buiten valt

    Discussies over facturen gaan vrijwel nooit over het uurtarief, maar over de vraag of iets binnen beheer viel. Deze drie categorieën staan in bijna elke overeenkomst buiten de vaste prijs.

    Projecten en wijzigingen

    Beheer houdt in stand wat er staat. Een verhuizing, migratie of nieuwe applicatie is een project met een eigen opdracht en prijs.

    • Vraag naar de grens: wanneer is iets een wijziging?
    • Laat kleine wijzigingen binnen beheer vallen
    • Spreek een tarief per projecturen af

    Licenties en verbruik

    Abonnementen, opslag en dataverkeer staan los van beheer. Ze bewegen mee met uw organisatie en dus met uw factuur.

    • Prijs per werkplek per maand
    • Afspraak bij groei en krimp
    • Wie zegt licenties op bij vertrek?

    Derden en leveranciers

    Storingen bij uw internetprovider of softwareleverancier vallen buiten de termijnen, maar iemand moet ze wel oppakken.

    • Wie is regiehouder richting derden?
    • Wachttijd bij derden pauzeert de klok
    • Leg vast wie mag melden bij wie

    Rapportage: zonder cijfers is er geen afspraak

    Een overeenkomst zonder maandelijkse of kwartaalrapportage is niet controleerbaar, want de leverancier meet zijn eigen prestatie in zijn eigen systeem. Vraag om een vast overzicht: aantal meldingen per prioriteit, gehaalde termijnen, terugkerende oorzaken, uitgevoerd onderhoud en openstaande risico’s. Dat laatste punt is het waardevolste, omdat het het gesprek verschuift van storingen naar voorkomen. Hoe dat werkt, staat in ons artikel over proactief beheer.

    Vijf vragen voordat u tekent

    1. Wat is de aanvangstijd per prioriteit, en wat waren de werkelijke cijfers van het afgelopen halfjaar?
    2. Welke situaties krijgen automatisch de hoogste prioriteit, en wie mag bij u opschalen?
    3. Wat valt binnen de vaste prijs en wat wordt nagefactureerd, met een voorbeeld van beide?
    4. Welke tests en welk onderhoud voert u uit zonder dat wij daarom vragen, en wat rapporteert u daarover?
    5. Wat gebeurt er bij opzegging: welke documentatie, wachtwoorden en data krijgen wij mee, in welk formaat en binnen welke termijn?

    De uitgang staat in het begin

    Let op de looptijd, de opzegtermijn en de stilzwijgende verlenging. Een jaarcontract met drie maanden opzegtermijn dat automatisch met een jaar verlengt, betekent dat u negen maanden per jaar niet kunt overstappen. Belangrijker nog is de overdracht: eigendom van uw domeinnamen, beheerderswachtwoorden, netwerkdocumentatie en export van uw data. Wie dat aan het begin regelt, houdt de regie. Wij hebben daar de IT-verhuischeck voor, waarmee u ziet wat een overstap in uw situatie inhoudt.

    Wilt u uw huidige overeenkomst tegen deze punten laten aflopen? Wij lezen hem door en geven aan welke afspraken ontbreken, ook als u besluit bij uw huidige leverancier te blijven.

    Adviesgesprek aanvragen
  • Restoretest: is uw back-up echt terug te zetten?

    Restoretest: is uw back-up echt terug te zetten?

    De bekende back-upregels beschrijven hoeveel kopieën u bewaart en waar. Ze zeggen niets over de enige vraag die telt op de dag dat het misgaat: komt uw data er ook weer uit, binnen de tijd die u zich kunt permitteren? De nul in de 3-2-1-0-regel staat voor nul fouten bij verificatie, en juist dat onderdeel blijft in de praktijk het vaakst liggen.

    Een groene back-upjob is geen bewijs

    Een geslaagde job betekent dat er data is weggeschreven, niet dat die data bruikbaar is. De klassieke verrassingen bij een echte herstelactie: een database die zonder applicatieconsistentie is meegenomen en niet wil starten, een nieuwe schijf of virtuele machine die nooit aan het schema is toegevoegd, een versleutelde back-up waarvan de sleutel in dezelfde omgeving lag die u kwijt bent, en de eerlijkste van allemaal: het terugzetten lukt wel, maar het duurt vier dagen terwijl u dacht dat het een middag was.

    Eerst de eis, dan de test

    Testen zonder norm levert een gevoel op, geen conclusie. Leg daarom per systeem vast hoeveel dataverlies acceptabel is (RPO) en hoe lang het mag duren voordat u weer werkt (RTO). Die twee getallen zijn een directiebesluit, niet een technische keuze, want ze bepalen wat de oplossing kost.

    SysteemMaximaal dataverliesMaximale hersteltijdGevolg bij overschrijding
    Financiële administratie1 uur4 uurBetalingen en facturatie stil
    Bestanden en samenwerking4 uur1 werkdagProductieverlies, geen omzetstop
    E-mail15 minuten2 uurKlantcontact valt weg
    Archief en oude projecten1 week1 weekHinder, geen stilstand

    Zodra deze tabel bestaat, weet u wat u moet aantonen. Loopt de gemeten hersteltijd structureel uit de norm, dan is dat geen testfout maar een ontwerpfout in uw back-up- en herstelinrichting.

    Drie niveaus van testen

    Niet elke test hoeft een complete uitwijk te zijn. Combineer een lichte test die u vaak doet met een zware test die u zelden doet.

    Steekproef op bestandsniveau

    Elke maand een willekeurig bestand en een postvakitem terugzetten van een willekeurige dag. Kost een kwartier en ontdekt stille fouten in het schema.

    • Maandelijks
    • Geen impact op productie
    • Controleert bewaartermijnen

    Volledig systeemherstel

    Eén keer per kwartaal een complete server terugzetten in een afgeschermde testomgeving, opstarten en de applicatie daadwerkelijk gebruiken.

    • Per kwartaal
    • Meet de echte hersteltijd
    • Toont ontbrekende afhankelijkheden

    Uitwijkoefening op papier

    Jaarlijks een scenario doorlopen met directie, beheer en leverancier: alles versleuteld op maandagochtend. Wie beslist, wie communiceert, wat eerst?

    • Jaarlijks, twee uur
    • Legt besluitvorming vast
    • Sluit aan op incidentrespons

    Wat u van elke test vastlegt

    1. Datum, uitvoerder en welk systeem of bestand is teruggezet.
    2. Van welke dag de kopie kwam en of dat overeenkomt met het afgesproken dataverlies.
    3. De gemeten tijd van start tot werkend, niet de tijd die de software rapporteert.
    4. Wat niet lukte of ontbrak, ook als u het tijdens de test hebt opgelost.
    5. Eén actiepunt met een eigenaar en een datum. Zonder dat laatste verandert er niets.

    Dit dossier is bovendien wat een verzekeraar of auditor van u wil zien. Een schema met groene vinkjes is daarvoor niet genoeg; een testverslag met een gemeten hersteltijd wel.

    Wat testen kost en wat stilstand kost

    De weerstand tegen testen is bijna altijd tijd. Reken het daarom een keer door. Een maandelijkse steekproef kost een kwartier, een kwartaaltest van een complete server twee tot vier uur, en een jaarlijkse oefening een halve dag voor drie mensen. Zet daar de kosten van een dag stilstand tegenover: loonkosten van medewerkers die niets kunnen doen, gemiste orders, herstelwerk achteraf en de tijd die directie kwijt is aan communicatie met klanten. Voor een organisatie met vijftig werkplekken loopt dat per dag in de tienduizenden euro’s. Vier keer per jaar testen kost minder dan een half uur stilstand.

    Valkuilen die u in een test wilt ontdekken

    De meest voorkomende blokkade is het beheerwachtwoord van de back-upomgeving dat alleen in de omgeving zelf bestond. Bewaar toegangsgegevens, licentiesleutels en een netwerkschema ook buiten uw eigen infrastructuur, op papier of in een kluis elders. Verder: houd minstens één kopie onveranderbaar of fysiek gescheiden, zodat ransomware de back-up niet meeneemt, en test niet in productie met dezelfde namen en IP-adressen. Een herstel dat uw actieve omgeving overschrijft, maakt een storing tot een incident. Onze pagina over back-upoplossingen gaat in op die scheiding.

    Vergeet uw cloudomgeving niet

    Microsoft en andere aanbieders houden uw platform in de lucht, maar zijn niet verantwoordelijk voor het terugzetten van wat u zelf verwijdert of laat versleutelen. Bewaartermijnen in de prullenbak zijn geen back-up. Wat er in de praktijk bij komt kijken, staat in ons artikel over herstel na een ransomware-aanval in Microsoft 365. Voor de bredere afweging tussen de verschillende schema’s is er het overzicht van back-upregels.

    Leg vast wie test

    Bij veel organisaties gaat iedereen ervan uit dat de ander test. Zet daarom in uw dienstverleningsafspraken welke tests uw IT-partner uitvoert, met welke frequentie, en welk verslag u daarvan ontvangt. Bewaakt uw leverancier alleen de jobs, dan controleert hij het proces en niet de uitkomst. Het verschil tussen die twee merkt u pas op de verkeerde dag.

    Wij voeren restoretests uit als vast onderdeel van beheer en leggen de gemeten hersteltijd per systeem vast, zodat u weet waar u aan toe bent voordat het nodig is.

    Adviesgesprek aanvragen
  • MFA en conditional access: verder dan een sms-code

    MFA en conditional access: verder dan een sms-code

    De meeste incidenten in MKB-omgevingen beginnen niet met een geavanceerde aanval op de firewall, maar met een geldig wachtwoord in verkeerde handen. Multifactorauthenticatie is daar het antwoord op, en veel organisaties hebben het inmiddels aan staan. Toch verschilt de bescherming die u eraan overhoudt sterk per implementatie: de ene vorm van MFA houdt een phishingaanval tegen, de andere niet.

    Wat MFA wel en niet oplost

    MFA zorgt ervoor dat een gestolen wachtwoord op zichzelf niet genoeg is om binnen te komen. Dat is een grote stap, want wachtwoorden lekken doorlopend via datasets van andere diensten en via nagemaakte inlogpagina’s. Wat MFA niet oplost: malware op een werkplek die een geldige sessie meeneemt, protocollen die de tweede factor helemaal niet ondersteunen, en uitzonderingen die iemand ooit “tijdelijk” heeft aangezet. Wie MFA inricht, richt dus vooral het geheel eromheen in. Dat valt onder identity en access management.

    Niet elke tweede factor is even sterk

    Er zijn grofweg drie niveaus in gebruik. Het verschil zit in de vraag of een aanvaller de tweede factor kan onderscheppen of aan de gebruiker kan ontfutselen.

    Code via sms of e-mail

    De zwakste variant. Een code is net zo goed door te geven aan een nagemaakte inlogpagina als een wachtwoord, en sms is gevoelig voor simkaartfraude.

    • Beter dan alleen een wachtwoord
    • Onderschepbaar en phishbaar
    • Alleen als tijdelijke tussenstap

    Authenticator met nummermatching

    De gebruiker neemt een nummer over van het inlogscherm naar de app. Blind op “goedkeuren” tikken kan niet meer, en dat blokkeert de meeste massale pogingen.

    • Geen blinde goedkeuring
    • Werkt ook zonder mobiel bereik
    • Inbegrepen in Microsoft 365

    Passkey of hardwaresleutel

    De sleutel is cryptografisch gebonden aan het echte inlogdomein. Een nagemaakte pagina krijgt niets bruikbaar, ook niet als de gebruiker meewerkt.

    • Phishing-resistent
    • Geen code om over te typen
    • Begin hiermee bij beheerders

    MFA-moeheid en pushmeldingen

    Zodra een aanvaller een wachtwoord heeft, is een veelgebruikte tactiek om eindeloos inlogpogingen te doen tot de gebruiker de melding uit ergernis goedkeurt, vaak midden in de nacht. Nummermatching haalt die tactiek onderuit, omdat er geen knop meer is om zomaar op te tikken. Vertel gebruikers daarbij expliciet wat ze doen bij een melding die ze niet zelf hebben veroorzaakt: niet negeren, maar melden bij de helpdesk, want het betekent dat hun wachtwoord bekend is.

    Conditional access: voorwaarden in plaats van alles of niets

    MFA bij elke aanmelding op elk apparaat levert weerstand op bij gebruikers en dus creatieve omwegen. Met conditional access maakt u de eis afhankelijk van de situatie: wie, waarvandaan, op welk apparaat en naar welke data. Onderstaande set regels werkt voor de meeste organisaties met tien tot tweehonderdvijftig werkplekken.

    SituatieRegelGevolg voor de gebruiker
    Beheerd apparaat, bekende locatieApparaat moet compliant zijnAanmelden zonder extra stappen
    Onbekend of prive-apparaatMFA verplicht, geen download van bestandenWebtoegang, lezen en bewerken in de browser
    Beheerdersrol gebruikenPhishing-resistente MFA verplichtPasskey of hardwaresleutel
    Aanmelding uit een land waar u niet werktBlokkerenMelding bij de beheerder

    Zet elke nieuwe regel eerst in rapportagemodus. U ziet dan een week mee wie erdoor geraakt zou worden, zonder dat iemand buitengesloten raakt. Voor de inrichting binnen Microsoft 365 gaat dit hand in hand met de beveiliging van uw Microsoft 365-omgeving.

    Wat u minimaal regelt

    1. MFA voor alle accounts, dus ook voor beheerders, directie en accounts die u zelden gebruikt.
    2. Verouderde aanmeldprotocollen blokkeren. Blijft POP, IMAP of SMTP met alleen een wachtwoord open, dan is uw MFA omzeilbaar. Dit hoort bij e-mailbeveiliging.
    3. Twee noodaccounts buiten de regels, met lange unieke wachtwoorden in een kluis en een alarm zodra ze gebruikt worden. Zonder die accounts sluit een foute regel u buiten uw eigen omgeving.
    4. Toegang tot bedrijfsdata koppelen aan de staat van het apparaat, wat vraagt om centraal endpoint management.
    5. Uitzonderingen alleen met einddatum en met een naam erbij, en elk kwartaal opnieuw langs.

    Licenties en randvoorwaarden

    Basis-MFA zit in elke Microsoft 365-omgeving. Voor conditional access heeft u Entra ID P1 nodig, dat onderdeel is van Microsoft 365 Business Premium. Voor de meeste MKB-organisaties is dat voldoende; u heeft geen enterprise-licentie nodig om bovenstaande regels in te voeren. Houd er rekening mee dat u de inrichting moet kunnen aantonen, bijvoorbeeld richting een verzekeraar of in het kader van de NIS2-richtlijn en uw AVG-verplichtingen.

    Invoeren zonder chaos op de helpdesk

    De praktische kant wordt vaak onderschat. Reken op een korte registratieperiode waarin gebruikers zelf hun app of sleutel koppelen, met een duidelijke einddatum en een instructie van een half A4. Begin met de IT-beheerders, dan een afdeling die meedenkt, daarna de rest. Plan de uitrol niet in een week met een deadline of een vakantiepiek, en zorg dat de helpdesk vooraf weet hoe een gebruiker weer toegang krijgt als de telefoon stuk of kwijt is. Die herstelprocedure is het onderdeel waar het in de praktijk op vastloopt, niet de techniek.

    Van invoering naar beheer

    Een eenmalige uitrol verliest binnen een jaar zijn waarde: er komen accounts bij, uitzonderingen blijven staan en apparaten vallen buiten beheer. Het onderhouden van deze regels hoort daarom bij proactief beheer, net als het opvolgen van meldingen. Gaat het ondanks alles mis, dan bepaalt uw voorbereiding hoe snel u weer werkt; dat leest u terug in ons artikel over herstel na een ransomware-aanval.

    Wilt u weten welke van deze regels in uw omgeving al actief zijn en welke uitzonderingen er nog open staan? Wij lopen uw aanmeldbeleid door en leveren een overzicht met concrete stappen, zonder dat uw mensen er iets van merken.

    Adviesgesprek aanvragen
  • Microsoft Teams als telefonieoplossing: hoe werkt dat?

    Microsoft Teams als telefonieoplossing: hoe werkt dat?

    Microsoft Teams is voor veel organisaties al het centrale platform voor videovergaderen en samenwerken. Maar Teams biedt meer dan chat en videocalls: met Microsoft Teams Phone (voorheen Teams Calling) kun je het platform ook gebruiken als volledige vervanging van je traditionele telefoonsysteem. Je belt dan gewoon via Teams — zowel intern als naar externe nummers.

    In dit artikel leggen we uit hoe Teams als telefonieoplossing werkt, welke opties je hebt, voor wie het geschikt is en wat de voor- en nadelen zijn.

    Wat is Microsoft Teams Phone?

    Microsoft Teams Phone is de telefoniemodule binnen Microsoft Teams waarmee je:

    • Externe telefoongesprekken kunt voeren en ontvangen via het PSTN (het reguliere telefoonnetwerk)
    • Een zakelijk telefoonnummer kunt koppelen aan je Teams-account
    • Functionaliteit krijgt zoals doorschakelen, wachtrijen, automatische beantwoording en voicemail
    • Kunt bellen via de Teams-app op laptop, smartphone of een gecertificeerde VoIP-telefoon

    De functionaliteit vereist een Microsoft Teams Phone-licentie (als add-on of onderdeel van Microsoft 365 Business Voice) en een koppeling met het telefoonnetwerk.

    Calling Plans

    Microsoft levert de PSTN-verbinding rechtstreeks. Eenvoudig, maar minder flexibel en duurder dan Operator Connect.

    Operator Connect

    Een gecertificeerde telecomprovider levert de verbinding via een directe koppeling met Teams. Meer controle en doorgaans lagere kosten.

    Direct Routing

    Verbind Teams via een eigen SBC (Session Border Controller) met elke gewenste telefonieprovider. Maximale flexibiliteit voor complexe omgevingen.

    De drie connectie-opties uitgelegd

    1. Microsoft Calling Plans

    Bij Calling Plans koopt je telefooncapaciteit direct bij Microsoft. Dit is de eenvoudigste optie: alles is in één hand en wordt beheerd via het Microsoft 365-beheercentrum. Het nadeel is dat Calling Plans duurder zijn dan marktpartijen en dat je afhankelijk bent van Microsoft voor nummers en tarieven.

    2. Operator Connect

    Operator Connect koppelt een gecertificeerde telecomprovider rechtstreeks aan je Teams-omgeving via een door Microsoft goedgekeurd platform. Nummerbeheer en verbindingsbeheer verloopt via de Teamsbeheerconsole. Voordelen: doorgaans lagere gesprekskosten dan Calling Plans, behoud van bestaande nummers en meer flexibiliteit in tarieven.

    3. Direct Routing

    Direct Routing verbindt Teams via een Session Border Controller (SBC) — een soort slimme gateway — met het telefoonnetwerk van jouw keuze. Dit geeft maximale flexibiliteit: je kunt elke telecomprovider gebruiken, bestaande SIP-trunken behouden en complexe routeringsregels instellen. Direct Routing vereist meer technische expertise en is vooral geschikt voor grotere of complexere omgevingen.

    Voordelen van Teams als telefonieoplossing

    • Één platform voor alles: chat, video, samenwerken én bellen in één applicatie — minder app-wissel, minder beheerslast.
    • Overal bereikbaar: medewerkers bellen via hun laptop of smartphone, op kantoor of thuis, zonder verschil.
    • Rijke functionaliteit: wachtrijen, IVR, doorschakelen, voicemail naar e-mail, gespreksdelegatie.
    • Integraties: naadloze integratie met Microsoft 365-applicaties zoals Outlook, SharePoint en Dynamics.
    • Centrale beheerconsole: nummers, belrouting en rapportages beheer je vanuit het Microsoft 365-beheercentrum.
    • Schaalbaar: nieuwe gebruikers toevoegen is een kwestie van licentie toewijzen.

    Nadelen en aandachtspunten

    • Internetafhankelijkheid: zonder werkende internetverbinding werkt ook de telefonie niet.
    • Licentiekosten: Teams Phone vereist een aparte add-on licentie bovenop Microsoft 365.
    • Noodoproepen: bij het gebruik van softphones is de locatiebepaling voor noodoproepen minder precies dan bij traditionele lijnen.
    • Implementatiecomplexiteit: Direct Routing en geavanceerde belplannen vereisen IT-expertise.
    • Niet voor iedereen: organisaties zonder Microsoft 365-omgeving hebben minder voordeel van de integratie.

    Voor wie is Teams Phone geschikt?

    Teams Phone is een uitstekende keuze als:

    • Je al Microsoft 365 gebruikt en wilt consolideren naar één platform
    • Medewerkers hybride of volledig op afstand werken
    • Je een moderne vervanging zoekt voor een verouderde telefooncentrale
    • Je kosten wilt besparen door meerdere communicatietools samen te voegen

    Teams Phone is minder geschikt voor organisaties die geen Microsoft 365-gebruikers zijn, omgevingen met zeer complexe telefonievereisten die beter worden bediend door gespecialiseerde telefoniesoftware, of locaties met een onbetrouwbare internetverbinding.

    Praktisch: hoe verloopt de overstap?

    • Inventariseer de huidige situatie: hoeveel lijnen, nummers, functies gebruik je nu?
    • Kies een connectiemethode: Calling Plans, Operator Connect of Direct Routing — afhankelijk van grootte en complexiteit.
    • Porteer bestaande nummers: bestaande telefoonnummers kun je in de meeste gevallen meenemen.
    • Configureer belplannen: stel wachtrijen, IVR en doorschakeling in via de Teams-beheersconsole.
    • Train medewerkers: de overstap naar een softphone vraagt wennen — plan een korte training.

    Conclusie

    Microsoft Teams als telefonieoplossing is voor veel Microsoft 365-organisaties een logische en kostenefficiënte keuze. Het consolideert communicatie in één platform, maakt hybride werken eenvoudiger en biedt professionele telefooniefunctionaliteit zonder de beheerslast van een traditionele telefooncentrale.

    1. Teams Phone maakt van Teams een volwaardig telefoonsysteem voor extern bellen.
    2. Drie connectie-opties: Calling Plans (eenvoudig), Operator Connect (flexibel) of Direct Routing (maximale controle).
    3. Grote voordelen bij organisaties die al Microsoft 365 gebruiken.
    4. Internetafhankelijkheid is het voornaamste aandachtspunt.
    5. Overstap vereist planning: nummers porteren, belplannen configureren en medewerkers trainen.
  • VoIP vs. traditionele telefonie: de voor- en nadelen

    VoIP vs. traditionele telefonie: de voor- en nadelen

    Telefonie is voor veel bedrijven een onmisbaar communicatiemiddel. Toch is de manier waarop we bellen de afgelopen decennia fundamenteel veranderd. Traditionele telefoonlijnen — gebaseerd op het analoge PSTN-netwerk of ISDN — maken steeds meer plaats voor VoIP (Voice over IP): telefoneren via het internet. Maar wat zijn de daadwerkelijke verschillen, en welke oplossing past het beste bij jouw bedrijf?

    In dit artikel vergelijken we VoIP en traditionele telefonie op de belangrijkste criteria: kosten, betrouwbaarheid, functies, schaalbaarheid en beheer.

    Wat is traditionele telefonie?

    Traditionele telefonie maakt gebruik van het PSTN (Public Switched Telephone Network): een analoog of digitaal netwerk van vaste telefoonlijnen. In Nederland was ISDN (Integrated Services Digital Network) lange tijd de standaard voor zakelijke verbindingen. KPN heeft ISDN inmiddels afgebouwd; organisaties die nog gebruikmaken van traditionele lijnen moeten overstappen.

    Wat is VoIP?

    VoIP staat voor Voice over Internet Protocol. Gesprekken worden omgezet naar digitale datapakketjes die via het internet worden verstuurd, net zoals e-mail of een videostream. VoIP kan werken via een softwareapplicatie op een computer of smartphone, via een speciale VoIP-telefoon of via een cloudgebaseerde telefooncentrale (hosted PBX).

    Lagere kosten

    VoIP-gesprekken zijn vrijwel altijd goedkoper dan traditionele telefonie, met name voor nationale en internationale gesprekken.

    Flexibele schaalbaarheid

    Lijnen toevoegen of verwijderen doe je met een paar klikken, zonder fysieke aanpassingen aan de infrastructuur.

    Rijkere functies

    Voicemail naar e-mail, videobellen, wachtrijbeheer, CRM-integraties — VoIP biedt standaard functionaliteit die bij traditionele systemen duur of onmogelijk was.

    VoIP vs. traditionele telefonie: de vergelijking

    Kosten

    Traditionele telefonie heeft relatief hoge vaste kosten: lijnaansluitingen, hardware (telefooncentrale, toestellen) en gesprekskosten per minuut. VoIP werkt doorgaans op abonnementsbasis met lage of geen belkosten, zeker voor binnenlandse gesprekken. De initiële investering in VoIP is lager omdat hardware vaak vervangen wordt door software.

    Gesprekskwaliteit

    Vroeger was VoIP berucht om slechte geluidskwaliteit. Modern VoIP — zeker op een stabiele, voldoende breedbandverbinding — biedt echter HD-geluidskwaliteit die traditionele telefonie overtreft. De kwaliteit is wel afhankelijk van de internetverbinding; bij een slecht netwerk kunnen vertragingen en onderbrekingen optreden.

    Betrouwbaarheid

    Traditionele telefonie werkt onafhankelijk van het internet — ook bij een stroomstoring (via POTS) of netwerkstoring. VoIP is afhankelijk van een werkende internetverbinding en stroom. Bij cloudgebaseerde VoIP-oplossingen biedt de provider echter zelf hoge beschikbaarheid via redundante datacenters.

    Schaalbaarheid

    Traditionele telefooninstallaties zijn lastig en duur op te schalen: elke nieuwe lijn vereist fysieke bekabeling en hardware-aanpassingen. Met VoIP voeg je in minuten nieuwe gebruikers of locaties toe via een beheerpanel — ideaal voor groeiende organisaties of bedrijven met meerdere vestigingen.

    Functies

    VoIP biedt standaard uitgebreide functionaliteit:

    • Voicemail naar e-mail of app
    • Gespreksdoorschakeling naar mobiel of thuiswerker
    • Automatische wachtrijen en IVR (keuzemenu’s)
    • Videobellen en scherm delen
    • Integratie met CRM- en helpdesksoftware
    • Gespreksopnames en rapportages

    Deze functionaliteit is bij traditionele systemen doorgaans alleen beschikbaar via dure PBX-hardware of add-ons.

    Beheer en onderhoud

    Traditionele telefonie vereist een fysieke telefooncentrale die op locatie wordt onderhouden. Updates, storingen en uitbreidingen vragen een monteur ter plaatse. Cloudgebaseerde VoIP wordt beheerd via een webbeheeromgeving; onderhoud en updates worden door de provider uitgevoerd.

    Wanneer kies je voor welke oplossing?

    Kies traditionele telefonie als:

    • Jouw internetverbinding onbetrouwbaar of traag is
    • Je al een recente investering hebt gedaan in telefoonhardware
    • Internetonafhankelijkheid absoluut vereist is (denk aan bepaalde hulpdienstlocaties)

    Kies VoIP als:

    • Je wilt besparen op telefonie- en beheerkosten
    • Medewerkers op meerdere locaties of thuis werken
    • Je wilt kunnen schalen zonder fysieke infrastructuuraanpassingen
    • Je integratiegmogelijkheden wilt met andere zakelijke software
    • Je toe wilt naar een moderne, uniforme communicatieoplossing

    Veelgemaakte fouten bij de overstap naar VoIP

    • Onvoldoende internetbandbreedte: VoIP vereist een stabiele verbinding — meet van tevoren of je netwerk toereikend is.
    • Geen QoS ingesteld: zonder Quality of Service-instellingen op je netwerk concurreert telefonie met ander dataverkeer.
    • Nummers niet overgezet: vergeet je bestaande nummers te porteren naar de nieuwe VoIP-aanbieder.
    • Geen noodplan: zorg voor een alternatief (doorschakeling naar mobiel) bij een internetstoring.

    Conclusie

    De overstap van traditionele telefonie naar VoIP is voor de meeste organisaties niet langer een kwestie van of, maar van wanneer. Met de afbouw van ISDN in Nederland is VoIP de toekomst van zakelijke telefonie. Voor het MKB biedt het lagere kosten, meer flexibiliteit en rijkere functionaliteit.

    1. VoIP is goedkoper in gebruik en beheer dan traditionele telefonie.
    2. De gesprekskwaliteit van modern VoIP is uitstekend bij een goede internetverbinding.
    3. Schaalbaarheid is een groot voordeel: meer lijnen toevoegen is kinderspel.
    4. Rijke functies zoals voicemail-naar-e-mail en CRM-integratie zijn standaard.
    5. Afhankelijkheid van internet is het voornaamste aandachtspunt — zorg voor een noodplan.
  • BYOD beleid: risico’s en best practices

    BYOD beleid: risico’s en best practices

    Medewerkers die hun eigen smartphone, laptop of tablet gebruiken voor werkdoeleinden — het klinkt praktisch en kostenbesparend. Maar Bring Your Own Device (BYOD) brengt ook serieuze beveiligingsrisico’s met zich mee die je als organisatie niet kunt negeren. Zonder een duidelijk beleid loop je het risico op datalekken, infecties met malware en compliance-problemen.

    Toch hoeft BYOD geen probleem te zijn. Met de juiste aanpak combineer je de flexibiliteit die medewerkers willen met de beveiliging die jouw bedrijf nodig heeft. In dit artikel lees je wat BYOD precies inhoudt, welke risico’s er kleven aan een ongecontroleerde BYOD-omgeving en hoe je een effectief beleid opstelt.

    Wat is BYOD?

    BYOD staat voor Bring Your Own Device: medewerkers gebruiken hun persoonlijke apparaten — smartphones, laptops, tablets — voor werkgerelateerde taken. Ze lezen e-mail, werken in bedrijfssystemen of slaan documenten op via hun eigen hardware.

    BYOD is populair omdat het medewerkers flexibiliteit geeft en organisaties hardware-kosten bespaart. Maar het creëert ook een grijs gebied tussen privé en zakelijk gebruik, met alle beveiligingsuitdagingen van dien.

    Beveiligingsrisico’s

    Onbeheerde apparaten zijn een open deur voor malware, datalekken en ongeautoriseerde toegang tot bedrijfsdata.

    Compliance-uitdagingen

    AVG, NIS2 en sectorspecifieke regelgeving stellen eisen aan de beveiliging van data, ook op privéapparaten.

    Beheersbaarheid

    Zonder Mobile Device Management (MDM) heb je als IT-afdeling geen zicht op wat er op die apparaten gebeurt.

    De belangrijkste risico’s van BYOD

    1. Datalekken bij apparaatverlies of -diefstal

    Een gestolen smartphone zonder schermbeveiliging of encryptie geeft directe toegang tot zakelijke e-mail, bestanden en applicaties. Dit is niet alleen een beveiligingsprobleem — het kan ook een meldingsplichtig datalek zijn onder de AVG.

    2. Onbeveiligde netwerken

    Medewerkers verbinden hun apparaten vaak met openbare wifi-netwerken: in cafés, hotels of op luchthavens. Zonder VPN of Zero Trust-beveiliging kunnen aanvallers meelezen met het dataverkeer en inloggegevens onderscheppen.

    3. Verouderde software en ontbrekende updates

    Zakelijke apparaten worden centraal beheerd en voorzien van patches. Privéapparaten niet. Een medewerker die maanden achterloopt met updates draagt een apparaat met bekende kwetsbaarheden het bedrijfsnetwerk in.

    4. Schaduw-IT en ongeautoriseerde apps

    Op privéapparaten installeren medewerkers apps die niet door de IT-afdeling zijn goed- of afgekeurd. Zo belandt bedrijfsdata in consumentendiensten zonder zakelijke privacywaarborgen, of worden gevoelige bestanden gedeeld via niet-goedgekeurde kanalen.

    5. Problemen bij uitdiensttreding

    Wanneer een medewerker het bedrijf verlaat, moet je er zeker van zijn dat alle bedrijfsdata van zijn of haar persoonlijk apparaat is verwijderd. Zonder MDM is dat nauwelijks afdwingbaar — en kan data lang na vertrek nog toegankelijk zijn.

    Best practices voor een effectief BYOD-beleid

    Stel een duidelijk BYOD-beleid op

    De basis is een schriftelijk beleid dat medewerkers ondertekenen. Dit document beschrijft welke apparaten zijn toegestaan, welke apps verboden zijn, welke data beschikbaar is via privéapparaten en wat de consequenties zijn bij misbruik of verlies.

    Implementeer Mobile Device Management (MDM)

    MDM-oplossingen zoals Microsoft Intune stellen je in staat om zakelijke data op privéapparaten te beheren en te scheiden van persoonlijke inhoud. Via een MDM kun je op afstand de zakelijke container wissen, beleid afdwingen en apps centraal beheren — zonder toegang tot persoonlijke foto’s of berichten van de medewerker.

    Verplicht multi-factor authenticatie (MFA)

    Zelfs als een inlogcombinatie wordt gestolen via phishing of via een onbeveiligd netwerk, voorkomt MFA dat aanvallers daadwerkelijk toegang krijgen. MFA is een minimumvereiste voor elk apparaat dat toegang heeft tot bedrijfssystemen.

    Gebruik een Zero Trust-benadering

    Zero Trust gaat uit van het principe “vertrouw nooit, verifieer altijd”. Elk apparaat — ook een bekende laptop — moet zich bij iedere sessie opnieuw authenticeren en bewijzen dat het voldoet aan de beveiligingseisen. Dit beperkt de schade als een apparaat gecompromitteerd raakt.

    Vereis encryptie en schermbeveiliging

    Apparaten die toegang hebben tot bedrijfsdata moeten versleuteld zijn en beveiligd zijn met een pincode, wachtwoord of biometrie. Dit is de minimale drempel bij diefstal of verlies.

    Train medewerkers regelmatig

    Technische maatregelen helpen, maar medewerkers zijn de eerste verdedigingslinie. Zorg voor periodieke bewustwordingstraining over phishing, veilig wifi-gebruik, het herkennen van verdachte apps en de juiste omgang met zakelijke data op privéapparaten.

    BYOD vs. COPE vs. CYOD: wat past bij jouw organisatie?

    BYOD is niet de enige optie. Er zijn meerdere modellen voor apparaatbeheer, elk met een andere verhouding tussen vrijheid en controle:

    • BYOD (Bring Your Own Device): medewerker is eigenaar, organisatie stelt beveiligingseisen.
    • COPE (Corporate-Owned, Personally Enabled): bedrijf is eigenaar, medewerker mag het apparaat ook privé gebruiken.
    • CYOD (Choose Your Own Device): medewerker kiest uit een goedgekeurde lijst, bedrijf koopt en beheert het apparaat.
    • COBO (Corporate-Owned, Business Only): zakelijk apparaat, uitsluitend voor werkdoeleinden.

    Voor kleinere organisaties met beperkt IT-budget is BYOD met MDM vaak de meest pragmatische keuze. Grotere of meer risicovolle omgevingen kiezen vaker voor COPE of CYOD.

    Veelgemaakte fouten bij BYOD-beleid

    • Geen schriftelijk beleid: mondeling afspraken maken werkt niet als er iets misgaat.
    • MDM overgeslagen: zonder technisch beheer heb je geen grip op wat er op apparaten gebeurt.
    • MFA niet verplicht: één wachtwoord is onvoldoende bescherming voor zakelijke systemen.
    • Uitdiensttreding niet geregeld: zorg voor een vast offboarding-proces waarbij zakelijke data altijd wordt gewist.
    • Medewerkers niet getraind: beleid zonder bewustwording werkt niet.

    Hoe begin je met een BYOD-beleid?

    Stel jezelf eerst de volgende vragen:

    • Welke medewerkers gebruiken al privéapparaten voor werk — met of zonder officieel beleid?
    • Welke bedrijfsdata is bereikbaar via deze apparaten?
    • Hebben wij een MDM-oplossing of is dat nog niet geïmplementeerd?
    • Is er een offboarding-procedure die ook apparaatbeheer omvat?
    • Voldoen wij aan de AVG-vereisten voor de verwerking van data op privéapparaten?

    Op basis van de antwoorden kun je prioriteren: start met een beleidsdocument, implementeer MFA en MDM, en zorg daarna voor bewustwordingstraining.

    Conclusie

    BYOD is een realiteit in de moderne werkomgeving. Medewerkers gebruiken hun eigen apparaten — of je nu een beleid hebt of niet. De vraag is dus niet of je BYOD toestaat, maar hoe je het veilig inricht.

    1. Stel een schriftelijk BYOD-beleid op dat medewerkers ondertekenen.
    2. Implementeer MDM om zakelijke data te scheiden en te beheren.
    3. Verplicht MFA voor toegang tot alle bedrijfssystemen.
    4. Pas Zero Trust toe als beveiligingsfilosofie voor apparaat- en netwerktoegang.
    5. Vereis encryptie en schermbeveiliging op alle toegestane apparaten.
    6. Train medewerkers regelmatig over veilig gebruik van privéapparaten.
    7. Regel uitdiensttreding zodat zakelijke data altijd wordt gewist bij vertrek.
  • On-premise vs. cloud vs. hybride: wat past bij jouw bedrijf?

    On-premise vs. cloud vs. hybride: wat past bij jouw bedrijf?

    Wanneer organisaties nadenken over hun IT-infrastructuur, staan ze vroeg of laat voor een fundamentele keuze: zetten we onze systemen on-premise neer, migreren we naar de cloud, of kiezen we voor een hybride combinatie? Het antwoord is niet voor iedereen hetzelfde — en hangt af van factoren als budget, veiligheid, schaalbaarheid en de aard van je bedrijfsprocessen.

    In dit artikel leggen we de drie modellen naast elkaar, bespreken we de voor- en nadelen van elk en helpen we je bepalen welke aanpak het beste past bij jouw organisatie.

    De drie modellen uitgelegd

    On-Premise

    Servers en systemen staan fysiek bij jou op locatie. Volledige controle, maar ook volledige verantwoordelijkheid voor beheer en beveiliging.

    Cloud

    Systemen draaien bij een externe cloudprovider. Flexibel, schaalbaar en weinig eigen hardware — maar afhankelijk van internet en derde partijen.

    Hybride

    Een combinatie van on-premise en cloud. Kritieke systemen blijven lokaal, terwijl andere workloads naar de cloud worden gebracht.

    On-Premise: volledige controle, hoge verantwoordelijkheid

    Bij een on-premise infrastructuur staan de servers fysiek op jouw locatie of in een eigen datacenter. Jij beheert de hardware, software, beveiliging en updates. Dit model bood decennialang de standaard voor zakelijke IT.

    Voordelen van on-premise

    • Volledige controle: je bepaalt zelf welke software draait, wanneer updates worden doorgevoerd en wie toegang heeft.
    • Geen internetafhankelijkheid: systemen draaien ook bij internetstoringen.
    • Geschikt voor strenge compliance: sommige sectoren (zorg, finance, overheid) vereisen dat data fysiek op eigen locatie blijft.
    • Vaste kosten: na aanschaf zijn de lopende kosten voorspelbaar.

    Nadelen van on-premise

    • Hoge initiële investering: servers, licenties en infrastructuur vergen een forse kapitaaluitgave.
    • Beperkte schaalbaarheid: uitbreiding betekent nieuwe hardware aanschaffen.
    • Eigen beheer en expertise nodig: patching, monitoring en beveiliging zijn volledig jouw verantwoordelijkheid.
    • Verouderde hardware: hardware moet periodiek worden vervangen — een onzichtbare kostenpost.

    Cloud: flexibiliteit en schaalbaarheid op aanvraag

    Bij cloud-computing draaien applicaties en data op servers van een externe provider, zoals Microsoft Azure, Amazon Web Services (AWS) of Google Cloud. Je betaalt voor wat je gebruikt, en de provider beheert de onderliggende infrastructuur.

    Voordelen van cloud

    • Schaalbaar op aanvraag: meer rekenkracht of opslag activeer je in minuten.
    • Lage startskosten: geen hardware-investering, je betaalt per gebruik (OpEx in plaats van CapEx).
    • Toegankelijk overal: medewerkers werken vanaf elke locatie met een internetverbinding.
    • Automatische updates: de provider zorgt voor patches en onderhoud.
    • Hoge beschikbaarheid: grote cloudproviders garanderen 99,9%+ uptime via geografisch verspreide datacenters.

    Nadelen van cloud

    • Internetafhankelijkheid: bij een storing in de verbinding ligt de toegang plat.
    • Vendor lock-in: overstappen naar een andere provider kan complex en kostbaar zijn.
    • Lopende kosten: op de lange termijn kunnen cloudkosten oplopen, zeker bij ongecontroleerd gebruik.
    • Minder directe controle: je bent afhankelijk van de beveiliging en het beleid van de provider.

    Hybride: het beste van twee werelden

    Een hybride infrastructuur combineert on-premise systemen met cloudoplossingen. Kritieke of gevoelige data blijft on-premise, terwijl minder gevoelige workloads, samenwerking en schaalbaarheid worden afgenomen vanuit de cloud.

    Een typisch voorbeeld: een organisatie bewaart patiëntgegevens op eigen servers voor compliance, maar gebruikt Microsoft 365 voor e-mail en samenwerking, en Azure voor back-ups en uitwijkscenario’s.

    Voordelen van hybride

    • Flexibiliteit: kies per workload de meest geschikte omgeving.
    • Gefaseerde migratie: je hoeft niet alles tegelijk te migreren.
    • Compliance en controle: gevoelige data blijft lokaal, overige diensten profiteren van cloudvoordelen.
    • Uitwijkoptie: de cloud fungeert als back-uplocatie bij on-premise storingen.

    Nadelen van hybride

    • Complexer beheer: twee omgevingen vereisen integratie, monitoring en expertise in beide.
    • Hogere beheerskosten: je betaalt zowel voor on-premise hardware als cloudabonnementen.
    • Beveiligingsuitdagingen: meer koppelingen betekent meer aanvalsoppervlak.

    Vergelijking op een rij

    CriteriumOn-PremiseCloudHybride
    Initiële kostenHoogLaagGemiddeld
    SchaalbaarheidBeperktHoogHoog
    ControleVolledigBeperktGedeeld
    BeheerslastHoogLaagGemiddeld
    InternetafhankelijkheidGeenHoogGedeeltelijk
    Compliance-geschiktheidHoogAfhankelijk van providerHoog

    Welk model past bij jouw organisatie?

    • Kies on-premise als je in een zwaar gereguleerde sector werkt, internetonafhankelijkheid essentieel is of als je al een grote hardware-investering hebt gedaan die nog niet is afgeschreven.
    • Kies cloud als je snel wil schalen, een klein IT-team hebt, medewerkers flexibel werken en je geen grote kapitaalinvestering wil doen.
    • Kies hybride als je gevoelige data lokaal wil houden maar toch wil profiteren van clouddiensten voor samenwerking, schaalbaarheid of back-up.

    Veelgemaakte fouten bij de keuze

    • Alles tegelijk migreren: een gefaseerde aanpak reduceert risico’s aanzienlijk.
    • Cloudkosten onderschatten: zonder kostenbeleid lopen cloudabonnementen snel op.
    • Beveiliging als afterthought: elk model vereist een eigen beveiligingsstrategie.
    • Geen exitstrategie: denk vooraf na over hoe je overstapt als de gekozen oplossing niet meer voldoet.

    Conclusie

    De keuze tussen on-premise, cloud en hybride is strategisch en heeft gevolgen voor kosten, beveiliging en wendbaarheid op de lange termijn.

    1. On-premise biedt maximale controle, maar vraagt hoge investeringen en eigen beheerscapaciteit.
    2. Cloud is flexibel en schaalbaar, maar vraagt vertrouwen in externe partijen en bewust kostenbeheer.
    3. Hybride combineert beide, maar vereist meer beheerscomplexiteit.
    4. Compliance-eisen bepalen mede welke data waar mag staan.
    5. Een gefaseerde aanpak is bijna altijd beter dan een big bang-migratie.