Wekelijks verzamelt ChannelConnect de opvallendste, leukste of beste nieuwsitems en tools. Met natuurlijk speciale aandacht voor de toepassingen ervan voor IT-dienstverleners en msp’s. Het overzicht van de afgelopen week.

Nieuws

Tools*

AI in Nederland en Europa

Als je vandaag een nieuwe applicatie aansluit of een extra vestiging toevoegt, denk je waarschijnlijk na over netwerksegmentatie. De vraag is alleen of de manier waarop je segmenteert nog past bij wat je probeert te beschermen. De oplossing? Microsegmentatie.

Vrijwel elk netwerk heeft segmentatie. VLAN’s hier, een firewallregel daar, en ergens een diagram dat de architectuur goed weergeeft. Dat werkt meestal. Tot het netwerk verandert, het gebruik verschuift, of een incident ineens laat zien hoe breed sommige segmenten eigenlijk zijn. In de praktijk blijkt segmentatie vaak grover dan het op basis van het risicoprofiel zou moeten zijn. Terwijl dreigingen steeds specifieker worden, blijven netwerken opvallend vaak ingericht rond brede zones en vaste aannames over vertrouwen. Die spanning wordt vooral zichtbaar buiten het datacenter. Op vestigingsniveau, waar gebruikers, IoT, OT en cloudapplicaties samenkomen, lopen klassieke segmentatiemodellen tegen hun grenzen aan.

VLAN’s zijn niet meer genoeg

Het punt is namelijk dat VLAN’s zijn ontworpen voor overzicht en schaal, niet voor context. Ze delen een netwerk op in logische blokken, gebaseerd op locatie, functie of afdeling. Dat is prima, zolang alle systemen binnen zo’n blok vergelijkbare risico’s hebben en zich voorspelbaar gedragen. Maar dat is steeds minder vaak het geval:

• Werkplekken, printers, camera’s en SaaS-connectors delen hetzelfde VLAN omdat ‘dat zo gegroeid is’.
• Een applicatieomgeving is logisch gescheiden, maar gebruikers krijgen via VPN alsnog breed netwerktoegang.
• Nieuwe cloudapplicaties vereisen uitzonderingen op bestaande firewallregels, en zo verdwijnt langzaam het overzicht.

Het probleem zit niet in VLAN’s zelf, maar in het feit dat ze geen rekening houden met identiteit, gedrag of context. Alles binnen een VLAN wordt in principe vertrouwd, terwijl risico’s juist per device, per gebruiker of per applicatie verschillen.

Daar komt bij dat aanvallen zelden netjes binnen één zone blijven. Laterale beweging, privilege-escalatie en misbruik van legitieme accounts maken klassieke netwerkgrenzen poreus. Als één endpoint binnen een VLAN wordt gecompromitteerd, ligt de rest vaak open.

Microsegmentatie buiten het datacenter

Microsegmentatie wordt vaak geassocieerd met datacenters en cloudomgevingen, bijvoorbeeld bij workload-isolatie, east-west traffic control en software-defined networking. Maar hetzelfde principe is minstens zo relevant op vestigingsniveau. Daar verschuift de focus van de klassieke vraag waar iets zich in het netwerk bevindt naar wat het precies is en welke rol het vervult.

Niet de netwerkpoort of het VLAN is leidend, maar de identiteit van een gebruiker, device of applicatie. Wat mag dit systeem doen, met welke andere onderdelen mag het communiceren en onder welke voorwaarden is die toegang toegestaan? Context zoals locatie, status van het apparaat, authenticatie en gedrag weegt mee, waardoor toegang niet langer impliciet is, maar telkens opnieuw wordt afgedwongen.

In plaats van brede netwerkzones werk je met policies die verkeer toestaan op basis van identiteit, rol en context. Een werkplek krijgt dan niet ‘toegang tot het netwerk’, maar toegang tot specifieke diensten. Een camera mag alleen praten met zijn videoplatform. Een applicatiecomponent mag alleen communiceren met zijn backend, en zo voort.

Technisch kan dat op verschillende manieren:

• Network Access Control (NAC) op basis van device-identiteit en posture
• Host-based firewalls met centrale policy
• Software-defined networking in campus- of WAN-omgevingen
• Cloud-native policies die on-prem en cloud verbinden

Het belangrijke verschil met klassieke segmentatie is dat de scheiding niet meer primair aan de netwerklaag hangt, maar aan beleid.

Segmentatie op device-, rol- en applicatieniveau

En daarbij wordt microsegmentatie nog interessanter wanneer je verschillende invalshoeken combineert.

Device-niveau
Niet elk apparaat is gelijk. Een beheerde werkplek met EDR en actuele patches vormt een ander risico dan een IoT-sensor of een BYOD-apparaat. Door devices te classificeren en daar policies aan te koppelen, beperk je wat ze überhaupt mogen.

Rol-niveau
Gebruikers hebben verschillende verantwoordelijkheden. Iemand van finance heeft andere applicaties nodig dan iemand in productie. Segmentatie op rolniveau voorkomt dat netwerktoegang breder is dan functioneel noodzakelijk, ook als gebruikers van locatie wisselen.

Applicatieniveau
Steeds meer verkeer is applicatiegericht en versleuteld. Door policies te baseren op applicatie-identiteit in plaats van IP-adressen, sluit segmentatie beter aan bij moderne omgevingen. Dat geldt zowel voor on-prem applicaties als voor SaaS en cloud-native diensten.

De niveaus versterken elkaar. Een onbekend device met een geldige gebruikerslogin krijgt dan alsnog beperkte toegang. Een bekende werkplek buiten compliance valt automatisch in een restrictiever profiel.

De relatie met zero trust

Microsegmentatie is een praktisch onderdeel van zero trust-architecturen. Het uitgangspunt blijft hetzelfde: vertrouw niets impliciet, verifieer continu en beperk toegang tot wat strikt noodzakelijk is.

Terwijl zero trust vaak abstract blijft, maakt microsegmentatie het concreet. Policies worden afdwingbaar op netwerk- en applicatieniveau, ook buiten het datacenter. Dat betekent dat ‘binnen’ en ‘buiten’ steeds minder relevant worden. Het gaat dus om de context.

Een veelgehoorde zorg is dat fijnmazige segmentatie beheercomplexiteit toevoegt. En dat is inderdaad een risico, vooral als je microsegmentatie benadert als een technisch kunstje in plaats van als een architectuur.

Met de juiste segmentatie wordt het beheer juist overzichtelijker. Verkeersstromen liggen expliciet vast in beleid, waardoor duidelijk is welk verkeer wordt verwacht en welk niet. Afwijkingen vallen sneller op en zijn eenvoudiger te herleiden tot een specifieke oorzaak.

Tegelijk blijven incidenten beter afgebakend, omdat verstoringen of compromittering zich niet automatisch door grote delen van de omgeving kunnen verspreiden. De sleutel zit in zichtbaarheid en tooling.

Hoe ver ga je zonder het onnodig complex te maken?

Pas op met de verleiding om alles tegelijk te segmenteren. Dat werkt zelden. Effectieve microsegmentatie begint klein en groeit mee met inzicht.

Een paar praktische uitgangspunten:

• Start met de meest risicovolle assets of processen
• Segmenteer op basis van daadwerkelijk verkeer, niet op aannames
• Automatiseer waar mogelijk, handmatig beheer schaalt slecht
• Documenteer intentie, niet alleen regels

Belangrijker nog: microsegmentatie is geen project met een einddatum. Het is een structurele maatregel die meebeweegt met veranderingen in applicaties, werkvormen en dreigingen. Nieuwe vestiging? Nieuwe applicatie? Dan hoort segmentatie daar standaard bij, niet als sluitstuk, maar als ontwerpprincipe.

Van netwerkontwerp naar gedragsmodel

VLAN’s brengen vooral orde in infrastructuur, microsegmentatie over controle op gedrag. Dat vraagt een andere manier van denken. Minder focus op fysieke of logische grenzen, meer op context en intentie. Op vestigingsniveau is die verschuiving misschien wel het meest zichtbaar. Juist daar komen oude netwerkmodellen en nieuwe realiteit hard met elkaar in aanraking. Wie daar durft los te laten dat alles binnen één locatie vertrouwd is, zet een belangrijke stap. De bottom line: het netwerk wordt er niet simpeler van, maar wel een stuk realistischer.

Jarenlang was het netwerk de beveiligingsperimeter. Wie binnen was, mocht praten. Firewalls, VLAN’s en ACL’s bepaalden wie waarheen kon. Die logica werkte zolang applicaties, gebruikers en data zich grotendeels binnen dezelfde infrastructuur bevonden. Dat landschap bestaat niet meer.

Gebruikers werken overal, applicaties draaien verspreid over cloudplatforms en data beweegt continu tussen omgevingen. In die werkelijkheid verschuift de kernvraag van ‘waar komt dit verkeer vandaan’ naar ‘wie of wat probeert hier toegang te krijgen’. Identity staat daarmee centraal in toegang, segmentatie en risicobeheersing.

Het perimeterprobleem

Het klassieke beveiligingsmodel gaat uit van een duidelijke binnen- en buitenkant. Zodra verkeer door de firewall is, geldt impliciet vertrouwen. Dat model is onder moderne omstandigheden niet meer houdbaar. VPN’s verlengen het netwerk naar onbeheerde apparaten, SaaS-diensten omzeilen het netwerk volledig, en API’s communiceren buiten het zicht van traditionele controles.

Voor jou als msp betekent dit dat netwerkmaatregelen alleen onvoldoende context bieden. Ze zien verkeer, maar niet de intentie erachter. Identity levert die context wel. Wie is de gebruiker of workload? Vanaf welk apparaat? In welke toestand? Onder welke voorwaarden? Die vragen bepalen steeds vaker of toegang verleent moet worden, en dus niet het IP-adres of subnet.

Identity als controlepunt

Identity gaat daarnaast ook niet meer alleen over inloggen. Moderne IAM-oplossingen functioneren als realtime beslissingslaag. Elke toegangspoging wordt beoordeeld op meerdere signalen tegelijk. Denk aan:

• gebruikersidentiteit en rol,
• apparaatstatus en compliance,
• locatie en tijdstip,
• gedragspatronen,
• gevoeligheid van de gevraagde resource.

Met conditional access koppel je die signalen aan beleid. Toegang wordt verleend, beperkt of geweigerd op basis van context. Dat maakt identity tot een dynamisch controlepunt, vergelijkbaar met wat firewalls ooit waren voor netwerkverkeer. Daarmee verschuift het zwaartepunt van securitybeheer naar minder vaste regels, meer beleid, dat continu wordt toegepast en aangepast.

Relatie met netwerksegmentatie

Identity vervangt netwerksegmentatie niet, maar verandert de rol ervan. Segmentatie blijft relevant om laterale beweging te beperken en impact te isoleren. Het verschil zit in de aansturing. In plaats van toegang te bepalen op basis van netwerkpositie, wordt toegang gekoppeld aan identiteit. Een gebruiker krijgt toegang tot een applicatie omdat zijn identiteit en context dat toestaan, niet omdat hij zich op het juiste VLAN bevindt. Netwerksegmentatie ondersteunt dat model door verkeer technisch te scheiden, terwijl identity bepaalt wie er gebruik van mag maken.

Voor jou betekent dat dat ontwerpkeuzes veranderen. Segmentatie verschuift van grofmazige netwerkscheiding naar fijnmazige toegang op applicatie- en dienstniveau. Identity fungeert daarbij als lijm tussen netwerk, applicaties en cloudplatforms.

Workloads krijgen ook een identiteit

Een belangrijk technisch punt dat vaak wordt onderschat: identity geldt niet alleen voor mensen. Workloads, services en API’s krijgen steeds vaker een eigen identiteit. Denk aan service accounts, managed identities en certificaatgebaseerde authenticatie. Dat heeft grote gevolgen voor architectuur. Hardcoded credentials verdwijnen uit configuraties. Toegang wordt tijdelijk en contextafhankelijk. Services krijgen alleen rechten zolang ze actief zijn en alleen voor wat ze nodig hebben.

Voor msp’s vraagt dit om ander beheer. Niet langer gebruikersaccounts aanmaken en vergeten, maar levenscycli beheren van identiteiten die automatisch ontstaan en verdwijnen. Governance en automatisering worden daarmee randvoorwaarden.

Impact op gebruikerservaring

Identity raakt direct aan veiligheid en gebruiksgemak. Slecht ingerichte IAM-oplossingen veroorzaken extra prompts, blokkades en frustratie. Goede inrichting zorgt ervoor dat toegang grotendeels onzichtbaar verloopt. Context speelt hierin een sleutelrol. Een gebruiker die vanaf een beheerd apparaat werkt, binnen bekende patronen, kan vrijwel ongemerkt toegang krijgen. Afwijkend gedrag vraagt extra bevestiging. Dat maakt security adaptief zonder onnodige frictie.

Gebruikerservaring wordt dan onderdeel van securityontwerp. Identity raakt direct aan acceptatie, productiviteit en vertrouwen. Dat betekent dat je vaker moet afstemmen met klanten over risicoacceptatie en gebruiksscenario’s.

Ontwerpimplicaties voor msp’s

Identity als fundament dwingt tot andere ontwerpkeuzes. Enkele implicaties die je in de praktijk tegenkomt:

• IAM-architectuur krijgt een centrale plek in het landschap, niet als bijlage.
• Netwerkontwerp en identitybeleid worden samen besproken.
• Applicaties worden beoordeeld op hun integratie met identitydiensten.
• Legacy-systemen vragen extra aandacht vanwege beperkte ondersteuning.

De rol van de msp verschuift naar architectuur en regie. Identitybeleid fungeert als uitgangspunt voor technische controles die consistent worden toegepast over netwerk, applicaties en cloudomgevingen.

Nederlandse organisaties geven hun digitale weerbaarheid gemiddeld een 7,1, maar schieten tekort op het gebied van dreigingsmonitoring, crisisoefeningen en ketenbeveiliging. Dat blijkt uit het onderzoek Cyberweerbaar Nederland 2026 van KPN onder meer dan 250 IT- en securityprofessionals uit grote organisaties in vitale sectoren.

Het onderzoek laat zien dat organisaties stappen zetten in het versterken van hun digitale weerbaarheid, maar dat belangrijke basismaatregelen nog niet overal structureel zijn ingericht. Met name in sectoren als energie, zorg, overheid en financiële dienstverlening kan uitval of verstoring directe gevolgen hebben voor essentiële diensten.

Volgens de onderzoekers bestaat er een verschil in perceptie tussen management en IT- en securityprofessionals. Waar het management de volwassenheid hoger inschat, signaleren professionals knelpunten in governance, securitymonitoring en crisisvoorbereiding. Gebrek aan duidelijk eigenaarschap en besluitvorming zorgt er volgens hen voor dat kwetsbaarheden blijven liggen en incidenten ad hoc worden aangepakt.

Het voldoen aan strengere Europese wet- en regelgeving wordt het vaakst genoemd als strategische prioriteit. Daarnaast besteden organisaties veel aandacht aan het veilig gebruik van AI, het vergroten van het bewustzijn onder medewerkers en het beveiligen van cloudomgevingen en toegangsbeheer. Het onderzoek laat zien dat AI al breed wordt toegepast, terwijl verantwoordelijkheden, monitoring en besluitvorming daarover nog niet altijd zijn vastgelegd.

In de dagelijkse praktijk zien professionals meerdere risico’s terugkomen. Menselijk gedrag speelt daarbij een grote rol, zoals onveilig klikgedrag en beperkt risicobesef, mede doordat training en opvolging niet altijd structureel zijn geregeld. Ook het gebruik van AI brengt nieuwe risico’s met zich mee, waaronder ongecontroleerd gebruik van tools en mogelijke datalekken. Verder blijkt dat veel organisaties beperkt zicht hebben op leveranciers en SaaS-diensten, waardoor ketenrisico’s onvoldoende worden beheerst. Verouderde systemen, ongeautoriseerde tools en onduidelijke rolverdelingen vergroten het aanvalsoppervlak.

Op het gebied van voorbereiding en signalering blijven organisaties eveneens achter. Een derde monitort digitale dreigingen onvoldoende of slechts op basaal niveau, waardoor incidenten vaak laat worden ontdekt. Daarnaast oefent 30 procent nooit of nauwelijks met cyberincidenten, terwijl een meerderheid aangeeft zich wel voorbereid te voelen.

Het onderzoek wijst erop dat verdere verbetering vooral zit in het concreet organiseren van de basis. Organisaties die vooruitgang boeken, richten zich op structureel toegangsbeheer, tijdige updates en continue monitoring, en betrekken leveranciers daarbij nadrukkelijk. Regelmatig oefenen met realistische scenario’s en duidelijke bestuurlijke betrokkenheid blijken daarbij bepalend. Structurele cyberweerbaarheid vraagt volgens de respondenten om blijvende investeringen. Ruim een derde geeft aan dat het huidige securitybudget onvoldoende is, terwijl twee derde verwacht dat dit budget in de komende periode zal toenemen.

Wekelijks verzamelt ChannelConnect de opvallendste, leukste of beste nieuwsitems en tools. Met natuurlijk speciale aandacht voor de toepassingen ervan voor IT-dienstverleners en msp’s. Het overzicht van de afgelopen week.

Nieuws

Tools*

AI in Nederland en Europa

Private 5G bereikt het mkb. Waar de technologie eerst vooral was voorbehouden aan grote industriële spelers, verschijnen nu de eerste concrete toepassingen bij middelgrote organisaties. Pilots in logistiek, zorg en industrie laten zien hoe 5G de stap vormt naar nieuwe netwerkdiensten en lokale autonomie, met betrouwbare dekking, eigen beheer en ruimte voor innovatie op de werkvloer.

Wat jarenlang een speeltuin leek voor telecomreuzen en industrieconcerns, begint nu door te sijpelen naar het middenbedrijf. Private 5G-netwerken – gesloten mobiele netwerken op eigen terrein, met gegarandeerde bandbreedte en lage latency – worden steeds toegankelijker. Apparatuur wordt betaalbaarder, spectrumbeleid versoepelt, en system integrators bieden kant-en-klare pakketten aan. De belofte is dat de klant maximale controle over het draadloze netwerk krijgt zonder afhankelijk te zijn van publieke operators.

Van industrie naar mkb

De eerste private 5G-netwerken werden gebouwd in omgevingen waar downtime kostbaar is: productiehallen, havens en luchthavens. Denk aan bedrijven als Tata Steel en Shell, die testlocaties inrichten waar autonome voertuigen, camera’s en robots onder één netwerk draaien. Inmiddels schuiven ook mkb+ organisaties aan.

Een van de aanjagers is het Nederlandse 3,5 GHz-spectrumbesluit, dat lokale licenties voor private netwerken mogelijk maakt. Daarmee kunnen bedrijven op hun eigen terrein een volledig gescheiden 5G-netwerk draaien, zonder afhankelijkheid van operators als KPN of Odido. Dat opent deuren voor sectoren die tot nu toe aangewezen waren op wifi of 4G-routers.

Nieuwe use cases in zicht

In de logistiek duiken de eerste voorbeelden op van distributiecentra die hun interne communicatie en voertuigtracking via private 5G laten lopen. De combinatie van hoge betrouwbaarheid en lage latency maakt het mogelijk om AGV’s (automated guided vehicles) en sensoren te koppelen aan realtime dashboards, zonder dat storingen van buitenaf roet in het eten gooien.

Ook in de zorg wordt geëxperimenteerd. Een ziekenhuis in het oosten van het land test een lokaal 5G-netwerk voor medische apparatuur en draadloze monitoring van patiënten. Dit biedt prioriteit voor kritieke data en gegarandeerde dekking in afgeschermde ruimtes waar wifi niet betrouwbaar genoeg is.

Ook in de industrie groeit de interesse snel. Fabrieken die overstappen op smart manufacturing willen hun OT- en IT-omgevingen strikt scheiden, maar wel verbonden houden. Met private 5G kan dat, terwijl het beheer via slicing of edge computing flexibel blijft.

Lokale autonomie

De kern van private 5G is autonomie. Bedrijven bepalen zelf wie toegang krijgt, hoe het netwerk wordt geconfigureerd en welke data het terrein verlaat. Dat past bij een bredere trend waarin organisaties meer regie nemen over hun digitale infrastructuur.

Voor het mkb+ betekent het dat zij niet langer hoeven te leunen op de SLA’s en prioriteiten van telecomproviders. Ze kunnen hun eigen kwaliteitseisen stellen, bijvoorbeeld voor latency of uptime, en deze direct koppelen aan hun bedrijfsprocessen. In sectoren waar iedere seconde telt – denk aan orderpicking, gezondheidsmonitoring of machinebesturing – kan dat het verschil maken tussen continuïteit en stilstand.

Nieuwe rol voor system integrators

De adoptie van private 5G vraagt wel om kennis die in het mkb+ niet vanzelfsprekend aanwezig is. System integrators en netwerkdienstverleners spelen daarom een sleutelrol. Zij leveren niet alleen de infrastructuur, maar ook het beheer, de beveiliging en de koppeling met bestaande IT-systemen.

Een interessant model dat nu opkomt, is 5G-as-a-service: een volledig beheerd privénetwerk dat als abonnement wordt afgenomen. Zo blijft de investering voorspelbaar en kan de oplossing meegroeien met de organisatie. Dat verlaagt de drempel, vooral voor bedrijven die nog experimenteren met IoT of edge computing.

Beveiliging als prioriteit

Een voordeel van private 5G is de ingebouwde beveiliging. Het netwerk draait geïsoleerd van publieke netwerken, waardoor de kans op afluisteren of interferentie klein is. Toch betekent dat niet dat het risico nul is. Bedrijven moeten hun beveiligingsarchitectuur blijven afstemmen op de 5G-omgeving, inclusief segmentatie, authenticatie en logging.

Voor system integrators ligt hier een kans om security-diensten te koppelen aan private 5G-oplossingen. Denk aan geautomatiseerde threat detection, netwerkmonitoring en compliance met ISO 27001 of NIS2.

De praktijk: eenvoud komt eraan

De grootste drempel voor mkb+ bedrijven was tot nu toe de complexiteit. Een 5G-core, antennes, SIM’s, slicing-configuraties – het klinkt als een project voor multinationals. Maar fabrikanten als Nokia, Ericsson en Celona brengen nu compacte, beheerde pakketten op de markt die binnen enkele dagen operationeel kunnen zijn.

Combineer dat met managed services van lokale integrators, en de technologie wordt ineens bereikbaar. Waar een paar jaar geleden nog miljoenen werden geïnvesteerd, kan een middelgroot bedrijf vandaag voor een fractie van dat bedrag een eigen netwerk draaien, met dezelfde garanties als de grote spelers.

Slimme netwerken als katalysator

Private 5G is natuurlijk geen doel op zich. De echte waarde zit in wat het mogelijk maakt: autonoom opererende machines, realtime videoanalyse, en lokale AI-toepassingen. In de maakindustrie bijvoorbeeld, waar camera’s productielijnen inspecteren op afwijkingen, kan de analyse direct op locatie plaatsvinden, zonder dat data via de cloud hoeft.

Ook voor het mkb+ met meerdere vestigingen opent dat nieuwe mogelijkheden. Een logistieke hub kan zijn eigen private 5G-netwerk koppelen aan de cloud voor centrale analyse, terwijl de operatie lokaal blijft draaien bij een storing. Dat vergroot de veerkracht en vermindert afhankelijkheid van internetverbindingen.

Europese context en toekomstverwachting

In Duitsland, Finland en het Verenigd Koninkrijk is de adoptie van private 5G al verder gevorderd. Nederlandse bedrijven kunnen daarvan leren. De verwachting is dat de vraag de komende twee jaar zal versnellen, mede door het vrijkomen van meer spectrum en de integratie van 5G in bestaande IT-platforms.

Volgens analisten van IDC zal het aantal private 5G-netwerken in Europa tegen 2027 verdrievoudigen, waarbij vooral middelgrote bedrijven de groeimotor vormen. De investeringen verplaatsen zich van proof-of-concepts naar operationele netwerken die bedrijfskritische processen ondersteunen.

De rol van partners

Voor telecomoperators en netwerkpartners verschuift de rol naar advies en co-creatie. Het mkb+ verwacht maatwerk, met aandacht voor beveiliging, integratie en support. Daarmee wordt 5G een verbindende technologie tussen IT en OT, tussen de werkvloer en de cloud. Wie die brug weet te slaan, heeft een sterke positie in het nieuwe netwerklandschap.

De komende jaren zal blijken hoe breed private 5G aanslaat in het mkb+. De technische voordelen zijn overtuigend, maar succes hangt af van eenvoud, ondersteuning en bewezen meerwaarde. Als die puzzelstukken op hun plaats vallen, kan private 5G uitgroeien tot een vaste bouwsteen in de digitale infrastructuur van middelgrote bedrijven.

Voorlopig is één ding duidelijk: de stap van wifi naar 5G is niet langer voorbehouden aan de grootindustrie. De autonomie die het oplevert, is ook fijn voor het mkb+.

Amazon Web Services heeft een nieuwe Europese soevereine cloud aangekondigd die volgens het bedrijf volledig binnen de Europese Unie wordt beheerd en geëxploiteerd. De stap volgt op jarenlange discussies over datasoevereiniteit, juridische zeggenschap en de afhankelijkheid van niet-Europese cloudaanbieders.

De introductie van een afzonderlijke Europese cloudinfrastructuur markeert een nieuwe fase in de positionering van AWS op de Europese markt. Waar het bedrijf eerder vooral wees op contractuele en technische maatregelen binnen bestaande regio’s, kiest het nu kennelijk voor een structurele scheiding in governance, personeel en operatie. Daarmee wil AWS aansluiten bij eisen die in verschillende EU-lidstaten steeds nadrukkelijker worden gesteld, met name door overheden en toezichthouders.

De timing van de aankondiging is relevant. Europese wetgeving rond gegevensbescherming en digitale autonomie is de afgelopen jaren aangescherpt, terwijl juridische onzekerheid blijft bestaan over de toepassing van Amerikaanse wetgeving op Europese data bij Amerikaanse aanbieders. Door een aparte Europese structuur op te zetten, probeert AWS die zorgen deels te adresseren, zonder afstand te doen van zijn bestaande dienstenportfolio.

Tegelijkertijd blijft het een model dat door AWS zelf is ingericht en gecontroleerd. De cloud is weliswaar operationeel gescheiden, maar blijft onderdeel van het AWS-ecosysteem. Voor sommige organisaties kan dat voldoende zijn, voor andere blijft de vraag in hoeverre dit verschilt van eerdere constructies waarbij compliance vooral contractueel werd ingevuld.

De uitbreiding met Local Zones in landen als Nederland, België en Portugal past binnen een bredere trend waarbij hyperscalers hun infrastructuur dichter bij eindgebruikers brengen. Dit ondersteunt niet alleen latency-eisen, maar speelt ook in op nationale wensen rond datalocatie. Daarmee vergroot AWS zijn dekking in Europa, terwijl het tegelijk inspeelt op politieke en beleidsmatige druk.

Voor de Europese cloudmarkt betekent de stap dat het debat over soevereine cloudoplossingen verder verschuift. Waar eerder vooral Europese aanbieders en samenwerkingsverbanden deze positie claimden, kiest nu ook een Amerikaanse hyperscaler expliciet voor een soeverein model. Dat vergroot de keuze voor afnemers, maar maakt de afweging tussen technische mogelijkheden, juridische zekerheid en strategische afhankelijkheid complexer.

Apple gaat de volgende generatie Apple Foundation Models baseren op Gemini-modellen en cloudtechnologie van Google. De meerjarige samenwerking moet de basis vormen voor nieuwe Apple Intelligence-functies, waaronder een vernieuwde versie van Siri die dit jaar beschikbaar komt.

De samenwerking betekent dat Apple bij de verdere ontwikkeling van zijn AI-functionaliteit deels leunt op technologie van Google. De Gemini-modellen worden geïntegreerd in Apple’s eigen software-ecosysteem en vormen de onderliggende laag voor nieuwe functies binnen Apple Intelligence. Dit platform is diep verweven met iOS, iPadOS en macOS en combineert generatieve AI met lokale verwerking en private cloudondersteuning.

Apple Intelligence is bedoeld om Siri natuurlijker en contextbewuster te laten functioneren. Daarnaast ondersteunt het platform functies zoals tekstgeneratie, het maken van afbeeldingen en het automatisch samenvatten van meldingen, e-mails en andere berichten. Volgens Apple draait een groot deel van deze verwerking op het apparaat zelf, aangevuld met rekenkracht uit een afgeschermde cloudomgeving.

Met de samenwerking versnelt Apple de modernisering van Siri, een traject dat al eerder is aangekondigd maar tot nu toe beperkt zichtbaar was voor eindgebruikers. Door samen te werken met een bestaande aanbieder van grootschalige AI-modellen verkort Apple de ontwikkeltijd en beperkt het de risico’s die gepaard gaan met het volledig intern ontwikkelen van nieuwe modellen. Voor Apple blijft de regie over gebruikersdata, identiteitsbeheer en beleidsafdwinging binnen de eigen infrastructuur.

Voor Google betekent de overeenkomst een uitbreiding van het commerciële bereik van Gemini en de bijbehorende cloudinfrastructuur. Analisten wijzen erop dat de samenwerking ook gevolgen heeft voor de concurrentieverhoudingen in de markt voor zoek- en assistenttoepassingen, waarin meerdere partijen inzetten op eigen AI-ecosystemen en consumentgerichte diensten.

Apple geeft aan dat het, ondanks de inzet van externe modellen en cloudtechnologie, vasthoudt aan zijn bestaande privacy- en beveiligingsprincipes. De integratie van Gemini vindt plaats binnen Apple’s eigen gecontroleerde omgeving, waarbij gebruikersgegevens niet vrij beschikbaar komen voor derden.

De cloudomgeving draait. Applicaties zijn bereikbaar, gebruikers kunnen werken en back-ups lopen. Voor veel klanten voelt dat als succes. Toch groeit bij msp’s het ongemak. Kosten lopen op zonder duidelijke verklaring. Performance blijft wisselend. Beheer voelt omslachtig, terwijl de belofte van flexibiliteit nou juist eenvoud was.

Dat spanningsveld komt vaak voort uit een lift-and-shift-migratie die technisch correct is uitgevoerd, maar architectonisch nooit is afgemaakt. De workload staat in de cloud, maar gedraagt zich nog hetzelfde als on-prem. Lift-and-shift heeft een slechte reputatie gekregen, maar dat is niet altijd terecht. Voor veel organisaties is het een logische eerste stap. Je verplaatst workloads met minimale aanpassing, beperkt risico en houdt de business draaiende. Zeker bij tijdsdruk of compliance-eisen is dat een verstandige keuze.

Het probleem ontstaat wanneer lift-and-shift het eindpunt wordt, in plaats van tussenfase. Virtuele machines blijven vervolgens permanent actief, sizing wordt niet herzien en architectuurkeuzes blijven gebaseerd op oude aannames. De cloud is dan feitelijk niet meer dan een externe hypervisor met een maandelijkse factuur. Als msp betekent dit dat je na de migratie steeds vaker vragen krijgt waar je geen eenvoudig antwoord op hebt. Waarom stijgen de kosten? Waarom voelt de applicatie trager dan verwacht? Waarom kost beheer meer tijd dan vroeger?

Technische schuld verschuift

On-prem technische schuld verdwijnt niet vanzelf door een migratie. Ze verandert van vorm. In de cloud uit zich dat onder andere in:

• permanent draaiende resources die nooit worden uitgeschakeld,
• overgedimensioneerde VM’s ‘voor de zekerheid’,
• monolithische applicaties die slecht schalen,
• netwerkontwerpen die latency introduceren,
• back-up- en snapshotstrategieën die elkaar overlappen.

Zolang alles werkt, blijft die schuld onzichtbaar. Pas bij groei, piekbelasting of kostenanalyse komt ze naar boven. Dan blijkt dat de cloudomgeving weliswaar technisch stabiel is, maar structureel niet erg efficiënt.

Wanneer is optimalisatie zinvol

Niet elke omgeving vraagt om herontwerp. Cloudoptimalisatie loont vooral wanneer meerdere signalen samenkomen. Een van die signalen is resourcegedrag. VM’s met lage gemiddelde CPU-belasting, maar hoge pieken, duiden vaak op verkeerd gekozen instance types. Constante belasting met voorspelbare patronen wijst juist op mogelijkheden voor reserved instances of schaalstrategieën.

Een tweede signaal is netwerkafhankelijkheid. Applicaties die intensief chatten tussen componenten, maar verspreid zijn over regio’s of subnetten, betalen latencybelasting. In on-prem omgevingen viel dat nauwelijks op. In cloudarchitecturen wordt dat direct voelbaar.

Ook operationele complexiteit speelt mee. Als beheer steeds meer scripts, uitzonderingen en handmatige checks vereist, is dat vaak een indicatie dat de architectuur niet meer past bij het gebruik.

Optimaliseren is geen refactorfeest

Een veelgemaakte denkfout is dat cloudoptimalisatie automatisch betekent: alles herbouwen. Dat schrikt klanten af en zet je als msp onnodig klem. In de praktijk zit de winst vaak in gerichte ingrepen.

Voorbeelden die je waarschijnlijk herkent:

• het opsplitsen van één grote VM in meerdere kleinere rollen,
• het verplaatsen van stateless componenten naar managed services,
• het loskoppelen van opslag en compute,
• het aanpassen van autoscaling-grenzen op basis van echte load.

Dit soort stappen vraagt technische analyse, maar geen complete herontwikkeling. Ze leveren vaak direct meetbaar resultaat op in kosten, performance en beheerbaarheid.

Cloud-native als principe

Cloud-native denken wordt vaak verward met specifieke technologieën. Containers, orchestratie en service meshes krijgen dan alle aandacht. Voor veel mkb-omgevingen is dat overkill. Het draait in de kern om een andere manier van kijken naar infrastructuur en applicaties. Resources worden niet gezien als vaste bouwstenen die je jarenlang in stand houdt, maar als tijdelijke onderdelen die je kunt vervangen zonder dat de omgeving instort. Componenten mogen verdwijnen, zolang de functionaliteit overeind blijft.

Schaalgedrag volgt daarbij het werkelijke gebruik. Capaciteit groeit of krimpt op basis van wat applicaties op dat moment nodig hebben, niet op basis van aannames vooraf. Dat betekent dat je minder vooruit reserveert en meer vertrouwt op meetgegevens en automatische aanpassing.

In zo’n architectuur worden fouten als normaal beschouwd. Systemen gaan stuk, verbindingen vallen weg en processen lopen vast. Ontwerpkeuzes zijn erop gericht om die situaties op te vangen, niet om ze koste wat kost te voorkomen. Herstelbaarheid, isolatie en automatische herstart krijgen daarmee een belangrijkere rol dan foutloosheid.

Beheer verschuift van handmatig ingrijpen naar beleid. In plaats van individuele resources aan te passen, leg je vast hoe de omgeving zich moet gedragen. Regels bepalen wie toegang heeft, hoelang resources blijven bestaan en onder welke voorwaarden wordt opgeschaald of afgebouwd. Dat maakt beheer consistenter en beter schaalbaar, zeker in omgevingen die blijven groeien of veranderen. Je kunt die principes toepassen zonder een volledig platform uit te rollen. Managed databases, object storage en serverless functies zijn vaak effectiever dan zelfbeheer op VM-niveau.

Kosten zijn symptoom

Veel optimalisatietrajecten beginnen bij kostenrapportages. Dat lijkt voor de hand te liggen, maar dat is niet optimaal. Kosten zijn het gevolg van architectuur, niet de oorzaak. Als je uitsluitend stuurt op besparen, loop je het risico performance of stabiliteit aan te tasten. Betere optimalisatie begint bij inzicht in gedrag. Monitoring, logging en tracing laten zien hoe applicaties zich werkelijk gedragen. Pas daarna volgt kostenoptimalisatie. Voor de msp verschuift het gesprek dan van ‘het is duur’ naar ‘dit is hoe de applicatie zich gedraagt’. Dat maakt keuzes uitlegbaar en verdedigbaar.

Cloudoptimalisatie zonder governance houdt geen stand. Zodra meerdere teams of klanten resources kunnen aanmaken zonder kader, ontstaat weer die verfoeide wildgroei. Naming conventions, tagging, lifecycle-regels en toegangsbeleid vormen daarom een technische randvoorwaarde. Goede governance maakt optimalisatie bovendien schaalbaar. Het voorkomt dat elke verbetering handmatig bewaakt moet worden. Cloudbeheer lijkt daardoor steeds meer op productontwikkeling. Je definieert standaarden, meet afwijkingen en stuurt bij.

Niets doen is ook beleid

Soms is niets doen de beste keuze. Sommige workloads draaien stabiel, voorspelbaar en tegen acceptabele kosten. Optimalisatie levert daar weinig op en je loopt kans risico’s te introduceren. De kunst zit in herkennen wanneer ‘goed genoeg’ ook echt goed genoeg is. Cloudoptimalisatie plaatst de msp nadrukkelijk in de rol van technisch adviseur. Je taak wordt voor zulke klanten minder uitvoerend, meer analyserend. Minder reageren op incidenten, meer sturen op ontwerp en gedrag.

Lift-and-shift blijft dus een valide startpunt. Maar optimalisatie bepaalt of de cloudomgeving ook op de lange termijn goed blijft functioneren tegen acceptabele kosten.

Veeam heeft de overname aangekondigd van Object First, een leverancier van object-storageoplossingen die specifiek zijn ontwikkeld voor Veeam-back-ups. Met de overname voegt Veeam voor het eerst eigen storagehardware toe aan zijn portfolio, terwijl het bedrijf benadrukt dat het software-first en hardware-agnostisch blijft opereren.

Object First werd in 2023 opgericht door de oprichters van Veeam en richtte zich sindsdien exclusief op het ontwikkelen van purpose-built storage voor Veeam-omgevingen. De bekendste oplossing van het bedrijf is een object-storage appliance die is ontworpen als immutable backup-target, bedoeld om back-ups te beschermen tegen ransomware en ongeautoriseerde wijzigingen. De technologie ondersteunt uitsluitend Veeam-workloads en positioneerde Object First daarmee nadrukkelijk als specialist binnen één ecosysteem.

Met de overname brengt Veeam deze gespecialiseerde opslag nu onder directe regie. Volgens het bedrijf verandert dat niets aan de bestaande strategie om klanten keuzevrijheid te bieden in infrastructuur en opslagplatforms. De oplossingen van Object First worden gepositioneerd als aanvullende optie binnen het Veeam-portfolio, met name voor organisaties die op zoek zijn naar een vooraf geïntegreerde oplossing voor ransomware-bestendige back-ups.

De stap past in een bredere ontwikkeling waarbij backup- en dataprotectieleveranciers meer aandacht besteden aan cyberweerbaarheid en herstel na incidenten. Immutable storage speelt daarin een steeds belangrijkere rol, omdat back-ups alleen effectief zijn wanneer ze niet kunnen worden aangepast of versleuteld door aanvallers. Door software en storage nauwer op elkaar af te stemmen, wil Veeam de betrouwbaarheid en eenvoud van dergelijke oplossingen vergroten.

Voor partners en klanten verandert er op korte termijn weinig aan bestaande implementaties. Veeam blijft samenwerken met storage- en cloudpartners en ondersteunt een breed scala aan opslagdoelen, waaronder on-premises systemen en public cloud-object storage. Tegelijkertijd ontstaat met Object First een meer geïntegreerde stack voor organisaties die dat prefereren, met één leverancier voor zowel backupsoftware als het onderliggende opslagplatform.

De overname onderstreept de nauwe historische band tussen beide bedrijven. Waar Object First tot nu toe als zelfstandige specialist opereerde, wordt de technologie nu onderdeel van de bredere Veeam-strategie rond data-resilience en herstel na cyberincidenten. Financiële details over de overname zijn niet bekendgemaakt.