Microsoft maakt cloudlogging gratis voor zakelijke klanten na hackerophef

Microsoft gaat cloudlogs gratis beschikbaar stellen aan zakelijke klanten. Dat doet het bedrijf na ophef eerder deze week, toen Microsoft logs alleen nog beschikbaar stelde aan bepaalde betalende klanten, terwijl het bedrijf ook waarschuwde voor staatshackers.

Microsoft schrijft in een blogpost dat het cloudlogs in de komende maanden algemeen beschikbaar maakt voor alle zakelijke klanten, ongeacht hun abonnement. Het gaat om logs die worden gemaakt in clouddiensten zoals Exchange Online of Microsoft 365. Beheerders daarvan moeten extra betalen als zij uitgebreide logs willen zien; daarvoor was Microsoft Purview Audit nodig, of een pakket waarin dat zat, zoals Enterprise E5 of G5 voor Microsoft 365.

Purview Audit wordt nu gratis beschikbaar voor alle klanten met een cloudabonnement. Wel wordt het pakket opgesplitst. De gratis versie heet Standard en bevat logs van e-mailtoegang en 'dertig andere types logdata die eerder alleen voor betalende klanten beschikbaar waren'. De standaard bewaartermijn gaat ook omhoog. Die was altijd 90 dagen, maar dat worden er 180.

Daarnaast komt er een betaalde versie van Purview Audit uit. Die heet Premium. Dat pakket is beschikbaar voor E5- en G5-klanten. Die heeft dezelfde mogelijkheden als Standard, maar heeft ook extra analyses en kan met een api in Office 365 worden geïntegreerd. Ook is de bewaartermijn langer met standaard één jaar, maar optioneel zelfs tien jaar.

Microsoft zegt dat het voor het aanbieden samenwerkt met de Amerikaanse Cybersecurity and Infrastructure Security Agency of CISA. Welke vorm die samenwerking heeft, is niet bekend. Het is dus niet duidelijk of de Amerikaanse overheid geld betaalt om het programma te bekostigen.

De stap wordt gezet nadat er vorige week ophef ontstond over Microsofts logbeleid. Het bedrijf waarschuwde toen dat de vermoedelijk Chinese staatshackersgroep Storm-0558 in de inboxen van klanten was binnengedrongen. Klanten die wilden weten of zij potentieel slachtoffer waren, konden dat opzoeken in logs, maar die waren alleen beschikbaar als zij betaalden. CISA zegt blij te zijn met de stap. "Bedrijven vragen om te betalen voor noodzakelijke logging zorgt voor onvoldoende zichtbaarheid bij het onderzoeken van cybersecurityincidenten." Hackers zouden daarmee 'gevaarlijke successen kunnen boeken in het aanvallen van Amerikaanse organisaties', zegt de overheidsinstantie.

Reacties (42)

[D11]

Dan maar hopen dat je binnen 180 dagen in de gaten hebt dat je gehackt bent.

[Csotranme]

Je kan binnen no-time een storage account opzetten in Azure waar je de logs naartoe pompt.
Dan bepaal je dus zelf hoe lang je ze wilt bewaren.

Tevens zijn er zat mogelijkheden om die logs geautomatiseerd te annalyseren/triggers aan te hangen.

[Cergorach]

Maar daar betaal je ook gewoon voor. Persoonlijk ben ik van mening dat de logs in M365 standaard op veel te kort staan!

[SED]

Als dat belangrijk voor je is dan sla je de logs zelf langer op, zolang als je wilt.
Als dat te complex is neem je de betaalde versie.
Geen probleem maken waar er geen is.

[Csotranme]

Dat is een andere discussie, waar ik het overigens mee eens ben.

Hoe vaak ik wel niet de vraag krijg van een klant om iets te controleren van 1 a 2 jaar geleden en er vervolgens geen storage account oid aanwezig blijkt te zijn.
Men is vaak verbaasd dat het default niet x aantal jaar is.

Maar goed, MS maakt wel vaker gekke default keuzes zoals bijvoorbeeld een nieuwe VM default open aan het internet pleuren...

[Andreplusplus]

Dat van die VM slaat natuurlijk nergens op. Het is maar net hoe jij hem deployed. En als je dat vanuit de portal doet ipv uit code, tja

[Csotranme]

via code/template is een ideale wereld. Met de klanten waar ik mee werk rollen ze dermate weinig uit of hebben ze zo weinig mutaties dat er gewoon de GUI gepakt wordt.

Overigens wel netjes afgedekt met policies dat rechtstreeks aan het internet niet kan natuurlijk en een NSG die het niet toestaat mocht het om wat voor reden dan toch lukken om iets rechtstreeks aan het internet te hangen.

[Luchtbakker]

Als je de logs periodiek kan exporteren dan kan je het zo scripten dat afwijkend gedrag gedetecteerd wordt aan de hand van de logs.

[Skywalker27]

Binnen de security wereld wordt min een jaar aanbevolen, maar er zijn veel verschillende niveau's, je kan de logs ook centraliseren en dan analyseren voor de activity monitoring.

[Reactie gewijzigd door Skywalker27 op 22 juli 2024 22:11]

[Bor]

Nee hoor. Binnen de security wereld draait het om risico en welk risico je acceptabel vindt. Dat is niet met een vast termijn als "een jaar" standaard te vatten maar wordt bepaald in het beleid. Hierbij komt ook nog wet- en regelgeving om de hoek kijken die van toepassing kan zijn. Daarnaast heb je nog het kostenaspect. Het opslaan van veel logging op een manier dat je er forensisch gezien ook nog iets aan hebt is niet goedkoop.

[Skywalker27]

Dat klopt helemaal maar IT Security Architects zeggen allemaal 1 jaar min. Voor cloud en internet faced diensten. Bij ons in de IRAM zijn cloud diensten en internet fased allemaal risk very serious en gaan we de IT Security arch. review doen die weer input is voor je TVA. Ja het kan i.d.d. Een stukje beleid bij ons zijn maar dat wel ergens op gebaseerd. Ja en daarnaast is het team belachelijk groot dat ik misschien een beetje in een bubble zit

[Bor]

Dat klopt helemaal maar IT Security Architects zeggen allemaal 1 jaar min.

Het hele punt van mijn vorige reactie is nu juist dat dit niet klopt. Deze vlieger gaat misschien op voor het bedrijf waar jij werkt maar dit is geen algemene stelregel en ook zeker niet iets dat alle security architecten zeggen. Je zou zelfs kunnen beargumenteren dat het een slecht advies kan zijn. Het juiste advies is "it depends" en doorvragen naar verplichtingen, doelen etc.

[Skywalker27]

Dat bedoelde ik met de bubble

[OruBLMsFrl]

Een jaar is ergens ook een mooie ronde menselijke termijn. Ik heb als het er financieel op aankomt wel eens gezien dat er om 90 vs 180 dagen flink onderhandeld wordt, en uiteindelijk toch voor die in totaal 6 maanden log retention extra wordt betaald. 12 maanden logs op die manier nog niet gezien, dan zijn aanvallers ook wel al extreem lang binnen toch.

[Reactie gewijzigd door OruBLMsFrl op 22 juli 2024 22:11]

[Skywalker27]

In het verleden waren de tijden veel langer dat men binnen was. Tegenwoordig zie je dat de bezoekers 10 tot 14 dagen binnen zijn en dan toeslaan.

[bartje]

ik hoop meer dat ik niet gehacked wordt.
maar ze kunnen deze logs niet tot in de oneindigheid bewaren natuurlijk.

dit is een goede zet. ik vind sowieso dat logs over eigen gebruik altijd gratis ingezien moeten kunnen worden.

[closefuture]

> maar ze kunnen deze logs niet tot in de oneindigheid bewaren natuurlijk.

Facebook kan wel eindeloos foto's van honden en katten bewaren maar Microsoft kan maar 180 dagen aan platte tekst bewaren voor betalende klanten?

[Reactie gewijzigd door closefuture op 22 juli 2024 22:11]

[Hatsjoe]

Dat kan je natuurlijk niet vergelijken. Bij een bedrijf van middelgroot formaat kan je zo terabytes aan logs per maand hebben. Dat is even wat anders dan die foto van 3MB waarvan je er misschien 1 per dag (en dat is al veel) plaatst.

[Krulliebol]

Goed punt, al is platte tekst wel zeer goed te comprimeren tot een fractie van de oorspronkelijke omvang.

[Hatsjoe]

Maar daarmee ook meteen veel minder doorzoekbaar aangezien het dan een heel kostbaar proces is. Je moet dan terabytes aan data decomprimeren om te kunnen doorzoeken. En om te kunnen decomprimeren heb je ook het hele bestand nodig, en dat betekent veel dataverkeer.

Daarom zijn tools zoals ElasticSearch zo populair, het maakt enorme hoeveelheden data goed doorzoekbaar, terwijl de data zo optimaal mogelijk op schijven weggeschreven wordt, en de eindgebruiker enkel de gewenste data te zien krijgt. Dit is enorm efficiënt.

Voor middelgrote bedrijven is simpelweg logs comprimeren niet wenselijk en haalbaar gezien alle eisen die aan log systemen gehangen worden.

Ik vind het wel gek dat de retentie niet gewoon volledig in te stellen is door de gebruiker. Zo werkt het bijvoorbeeld bij AWS wel. Alle AWS services die logs genereren kunnen deze naar "CloudWatch Logs" sturen (of doen dit standaard al). Het is dan aan jou om te bepalen wat de retentie is voor een bepaalde log group. Zo zou je kunnen stellen dat access logs een maand bewaard blijven, en inlog logs bijvoorbeeld 10 jaar of zelfs permanent.

[Krulliebol]

Of gebruik gewoon ZFS als bestandssysteem. Dan kun je je bestanden gecomprimeerd op je schijf hebben staan, terwijl ze toch direct toegankelijk zijn.

[closefuture]

Maar daarmee ook meteen veel minder doorzoekbaar aangezien het dan een heel kostbaar proces is. Je moet dan terabytes aan data decomprimeren om te kunnen doorzoeken.

Daarom zijn tools zoals ElasticSearch zo populair, het maakt enorme hoeveelheden data goed doorzoekbaar, terwijl de data zo optimaal mogelijk op schijven weggeschreven wordt, en de eindgebruiker enkel de gewenste data te zien krijgt. Dit is enorm efficiënt.

Wat is je punt precies? Is er nou wel of geen probleem met het comprimeren van data volgens jou?

Elasticsearch comprimeert data gewoon en gebruikt indexes om de data doorzoekbaar te houden. Je kunt plain text logs dus prima comprimeren en doorzoekbaar houden.

Daarnaast als je het artikel leest dan zie je dat wat Microsoft bewaard voor de logs geen platte tekst is hoogstwaarschijnlijk. Bijvoorbeeld: "What e-mails were send, read or forwarded?". Met andere woorden de "log recods" zullen veelal bestaan uit een paar ID's (mail ID, user ID, actie ID). Dat neemt helemaal weinig ruimte in.

[Reactie gewijzigd door closefuture op 22 juli 2024 22:11]

[Hatsjoe]

Uit het artikel:

De gratis versie heet Standard en bevat logs van e-mailtoegang en 'dertig andere types logdata die eerder alleen voor betalende klanten beschikbaar waren'.

Het gaat dus om veel meer dan dat jij nu doet schetsen.

Wanneer we het hebben over access logs dan groeien die al snel met 1MB per 10.000 requests. En dan hebben we het over 1 log type voor een enorm klein aantal requests. Het kan dus echt wel richting de terabytes gaan bij middelgrote bedrijven.

Wanneer we 250 werknemers hebben die ieder 1 request per minuut naar de mailserver sturen, dan heb je het omgerekend al over 3.6GB per maand. Zoals je ziet kan het dus snel doortikken.

Mijn punt over compression is dat het niet mogelijk is voor het doeleinde van deze logs (intrusion detection en andere soortgelijke zaken). Full text search doen door compressed bestanden is gewoon niet efficient. En wanneer je het hebt over indexes opbouwen zoals ES dat doet, dan heb je het in feite over ES zelf opbouwen.

Voor logs die gearchiveerd worden is compression inderdaad slim, maar voor alles dat doorzoekbaar moet blijven wil je geen gzip overheen gooien.

[closefuture]

Full text search doen door compressed bestanden is gewoon niet efficient. En wanneer je het hebt over indexes opbouwen zoals ES dat doet, dan heb je het in feite over ES zelf opbouwen.

Het lijkt mij nogal onwaarschijnlijk dat Microsoft deze logs opslaat als plain text regels in plaats van in een speciaal gebouwd systeem hiervoor.

Wanneer we het hebben over access logs dan groeien die al snel met 1MB per 10.000 requests.

Nergens uit blijkt dat Microsoft een dergelijke hoeveelheid opslag kwijt is voor de logging die zij hier doen. Zoals gezegd gaat het hoogstwaarschijnlijk niet om plain text maar om regels met enkele database ID's.

Wanneer we 250 werknemers hebben die ieder 1 request per minuut naar de mailserver sturen, dan heb je het omgerekend al over 3.6GB per maand.

"No way" dat Microsoft 3.6GB voor 1 maand kwijt is voor enkel al de e-mail audit logs voor 250 werknemers.

[Reactie gewijzigd door closefuture op 22 juli 2024 22:11]

[closefuture]

Ja je kunt terabytes aan log files hebben. Als je het originele artikel leest zie je snel genoeg dat wat Microsoft logged waarschijnlijk eerder in de MB's per maand zit dan in de TB's.

[Hatsjoe]

Copy paste uit mijn andere reactie:

Uit het artikel:

De gratis versie heet Standard en bevat logs van e-mailtoegang en 'dertig andere types logdata die eerder alleen voor betalende klanten beschikbaar waren'.

Het gaat dus om veel meer dan dat jij nu doet schetsen.

Wanneer we het hebben over access logs dan groeien die al snel met 1MB per 10.000 requests. En dan hebben we het over 1 log type voor een enorm klein aantal requests. Het kan dus echt wel richting de terabytes gaan bij middelgrote bedrijven.

Wanneer we 250 werknemers hebben die ieder 1 request per minuut naar de mailserver sturen, dan heb je het omgerekend al over 3.6GB per maand. Zoals je ziet kan het dus snel doortikken.

[Djerro123]

Het staat je vrij om zelf je logs op te slaan, je hebt er 180 dagen de tijd voor.

[Verwijderd]

logs kunnen ze niet verkopen aan de hoogste bieder! (oh shit, nu breng ik ze vast op ideeen)

[Verwijderd]

Oneindig veel logs voor een enkele klant komen op veel meer schijfruimte (kan makkelijk oplopen tot in de terabytes) uit dan de kapotgecomprimeerde plaatjes van een groep gebruikers van Facebook.

[Tweak3D]

Dat kan elke dag, alleen kun je vanaf dat moment 180 dag3n terug kijken, eerdere hacktiviteiten zijn niet beschikbaar. En wat let je om nu al je logs naar je clouddienst datalake over te pompen, als je daar 180 dagen in opslaat heb je zomaar na 360 dagen bijna een jaar aan logs. Maar goed, wie denkt er aan.

[Djerro123]

Hele terechte move dit van Microsoft en echt een flater van jewelste. In de enterprise wereld staan ze bekend om de partij die (op gebied van security) mee wil denken (in tegenstelling tot die andere Amerikaan), maar door deze flater heeft dit imago wel een knauw opgelopen.

[Verwijderd]

No offense maar dat klopt echt niet. Microsoft staat juist bekend als het bedrijf waarbij je moet betalen voor beveiliging. Dat zie je simpelweg overal terug in hun E5 / M5 producten en deze logging problemen zijn wederom een prima voorbeeld.

[himlims_]

Blijf mooi vinden hoe sommige cloud als de heilige graal beschouwen; ja maar draait bij microsoft dan is het goed. jah/nee; je moet het wel zelf inrichten, beheren en zorgen dat jouw randvoorwaarden goed staan. Heeft geen reet met microsoft te doen.

//edit; i know - maar dat beweert/denkt men (hier) dus wel.

[Reactie gewijzigd door himlims_ op 22 juli 2024 22:11]

[Verwijderd]

Goed, aan de keerzijde hiervan heb je tig systeembeheerders met hun eigen domeincontrollers en wat VB scriptjes die denken dat ze de publieke cloud ver vooruit zijn. Het is geen heilige graal, maar ik vraag me af (stiekem weet ik het zeker) of 9/10 het on-prem wel veiliger of beter inrichten. Heb heel wat geknoei gezien over de jaren.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 22:11]

[Defragging]

Niemand beweert dat "Public cloud" hosting per definitie veiliger is... Het is gewoon ander woord "gehost bij iemand anders" , en MS is naar mijn mening duidelijk over wat *jou* verantwoordelijkheden zijn op het platform...

[Cergorach]

Niemand beweert dat "Public cloud" hosting per definitie veiliger is...

Ja en nee. Dat ligt er aan welk deel je bedoeld en waar je dat mee vergelijkt. Ik zou willen stellen dat de servers waar bv. AAD op draait bij MS veiliger zijn dan de domain controllers on-premises bij de doorsnee MKB organisatie (en ook bij genoeg Enterprise omgevingen). En als je een 'default' omgeving neerzet bij M365, dan zal ook die per definitie veiliger zijn dan wat je even standaard installeert in een MKB omgeving. Als je echter verder gaat kijken kan je ook in een M365 omgeving aardig openzetten of niet dicht genoeg timmeren dan wat een expert heeft gedaan op een on-premises omgeving.

Ik ben van mening dat, je een M365 omgeving sneller kan neerzetten, sneller veilig kan krijgen, er minder onderhoud aan hebt en het uiteindelijk goedkoper is (licenties/hardware/personeel/huur/stroom/verzekeringen/airco/etc.). Niet in alle gevallen, maar wel in de meeste. De crux zit hem gewoon in de kwaliteit van het personeel (kennis/kunde/ervaring) wat het ontwerp maakt, het implementeert en die het onderhoud/beheert.

Het verschil tussen een MS en zo een beetje elke ander (non-IT) bedrijf: MS is bezig met zijn core business en IT voor de rest een noodzakelijk kwaad is. Dat betekend verre van dat MS perfect is, het is op heel veel vlakken gewoon onvolwassen en not fit for business, dat heeft over het algemeen meer te maken met de featureset/functionaliteit van een bepaalde oplossing dan de algehele veiligheid. Na 10+ jaar O365/M365 is mijn indruk daarvan dat het allemaal met ducttape aan elkaar hangt, maar het werkt beter dan de ducttape constructies on-premises.

[IrBaboon79]

Dat is hoe men het soms presenteert en door bepaalde lagen (meestal minder technische mensen) geinterpreteerd; public cloud is effectief uitbesteden/afkopen van hardware en het fysieke gedoe (ietwat simpel gezegd: CAPEX -> OPEX) eromheen. Het operationele deel blijft je eigen verantwoordelijkheid en - sterker nog - nu je aan internet hangt krijg je er een bak extra bij want netwerk, security en dergelijke zaken (die je offline vrij lang kon uitstellen want uptime/moeilijk/geld/tijd/<insert zwam verhaal>/sjakie van hiernaast fixed dat wel ffkes) moet je ook ineens allemaal goed inregelen. Er zitten ook wat nadelen aan al die mooie cloud verhalen

[Reactie gewijzigd door IrBaboon79 op 22 juli 2024 22:11]

[Djerro123]

Nieuwe paradigma’s brengen nieuwe uitdagingen met zich mee. Ik durf te stellen dat ik een expert ben op het gebied van Azure, van core services tot de PaaS diensten. In theorie kan ik een veilig, robuuste, schaalbare totaal oplossing ontwerpen en implementeren. Bijvoorbeeld voor als ik zelf een (SaaS) bedrijf wil starten.

“Bij iemand anders gehost” is toch echt wel wat anders, en dan had ik dat nooit gekund; je moet met allerlei verschillende partijen schakelen (DC, hardware, software) en veel diepere kennis van de onderdelen hebben om met zekerheid te kunnen stellen dat je je risico’s op gebied van security bijvoorbeeld met adequate maatregelen hebt afgedekt. In de public cloud (okay, ik zal specifiek tot Azure beperken) heb ik kennis nodig van networking, maar niet op het niveau dat ik een BigIP F5 firewall hoef in te kunnen spoelen en af te configureren.

En dan nog de integratie met automatiseringstools zoals Azure Devops, ongeëvenaard vergeleken met niet private cloud of colo oplossingen.

Ik heb ervaringen in beide trouwens; ben geen broekie in het vakgebied zullen we maar zeggen. En de public cloud is lang niet voor alles een halleluja verhaal maar “xyz komt er ook allemaal nog eens bij” is gewoon een slecht tegenargument. Vergeleken met de problematiek van “oud” lost PC dat allemaal op; het brengt alleen nieuwe uitdagingen met zich mee waar we vroeger nog geen last van hadden. Het klinkt altijd als “ja en je moet je auto ook altijd tanken, dat hoeft bij paarden niet”.

[itlee]

T jammere van alle cloud producten van MS met name Azure producten (op office 365 business na) alleen betaalbaar is voor de extreem grote bedrijven. De filosofie is van MS is zet maar een CAP op je monitoring dat als je ergens uit dreigt te lopen je een bericht krijgt dat je geld op is (bij wijze van).

Ik doe ondersteuning voor MKB en ik heb hele discussies gehad met MS icm de distributeur in nederland dat het prijspunt wat MS hanteert buiten alle proporties is. Vroeger als je een lokale server had, had je gewoon de programma's of logging zonder dat je maar overal voor moet betalen.

Ze hanteren het Volkswagen/PON/BMW/Mercedes syndroom, alles is optie en u zal betalen.

Wat krijg je dus nu al, early adopters die eerst riepen we moeten naar Azure want het is geweldig komen hier nu van terug en krijg je al te zien dat er split oplossingen komen. lokaal servertje met lokale software en waar nodig zaken in azure. waarom? of kosten te besparen.

De jongere IT generatie groeit op met alles maar in de cloud (bij wijze van) en dat is niet erg, maar als oldscool IT professional is t ook belangerijk om breder te blijven kijken, zo ook dit verhaal. Dikke subs betalen voor iets wat normaal standaard aan boord had moeten zijn. Soort van hier heb je een auto zonder het rempedaal, als je er op trapt en lang op trapt moet je (meer) betalen. Je moet namelijk altijd wel een keer remmen.

Als je kijkt hoe goed de hardware is van tegenwoordig (desktop, laptop, server hardware), hoe lang t meegaat en je tegenwoordig 6 tot 8 jr met (server) of netwerk hardware kan doen adviseer ik om soms oldscool te doen en lokaal (of in een rek van een datacentre) wat spulletjes op te hangen.

En begin niet over TCO, TCO op je cloud is er niet, schrijf maar MCO (Max cost of owner ship)....

[Csotranme]

Cloud is ook totaal geen holy grail en ik geloof er zelf heilig in dat er altijd (nouja komende 10 jaar) een hybride situatie het meest voorkomende is.

Ik word ook wel eens benaderd door IT partijen die me willen hebben maar roepen dan heel popiejopie dat ze alleen cloud doen. "Cloud is the next thing! Dat on-prem geneuzel moet je niet meer willen joh!"

Betreft MS en zijn kosten: Als je het goed inricht/schaalt is het vaak best te doen/verantwoorden.
Je gaat in Azure natuurlijk niet een dikke VM aanschaffen op de groei zoals je dat on-prem wel met een server doet.
Waar ik me ook een beetje aan stoor is de verborgen paar centen die sommige zaken kosten in Azure.
Als jij een VM aanmaakt zie je wat dat ding je gaat kosten per uur.
Heel veel kleine dingen klik je zo bij elkaar maar nergens noemen ze een prijs en die tellen wel lekker op zo zonder dat je het door hebt.

Ergens is dit natuurlijk ook gewoon onderdeel van het verdienmodel bij MS. Je goedkoop/makkelijk/snel binnen harken. Vervolgens groeit je omgeving steeds meer en kom je op een punt dat het te duur wordt en tevens ook erg duur om je data daar weer weg te krijgen en af te schalen.

Een alert "u bent door het budget van je sub heen" heb je natuurlijk niks aan in een prod omgeving.
Je kan niet zomaar even die ene DB of scaleset uitknallen..

[itlee]

Ben het helemaal met je eens....

Praktijk voorbeeld, op een sql server hangt er ergens een proces, cpu op 100% om 200 uur snachts, niemand, ram je dus door je budget heen, of de server gaat uit, of de server blijft aan en je krijgt de rekening.... en 100% cpu kan hard oplopen in de kosten,.... kan zo een paar honderd eurootjes in een nacht zijn. (mee gemaakt namelijk).

Als je zelf een server hebt met bijv. vmware, dan maakt t dus niks uit. gebruiker meld sochtends joh server is traag of iets,....ok ff rebootje en weer door. bij azure doe je praktisch hetzelfde alleen je vm'tje heeft wel even een paar honderd piek er door heen gefikt in een nacht. (leg dat maar is uit aan je mkb klant).

Bij MS draait ook gewoon die hp of dell of ibm server, met een cpu en geheugen en storage wat ze 1x hebben afgetikt, licenties hoeven ze zelf al niet te betalen dus die omgeving is en snel terug verdiend en ze lopen helemaal binnen.....

En dan heb ik t nog niet eens gehad als je iets verkeerd configt en je krijgt wat je zegt verborgen kosten.... en t loopt maar door en door....