Microsoft gaat VBA-macro's in Office standaard blokkeren

Microsoft gaat het moeilijker maken voor Office-gebruikers om gedownloade Visual Basic for Applications-macro's uit te voeren. Gebruikers krijgen te zien dat de macro's zijn geblokkeerd en uitvoeren zal alleen mogelijk zijn door de bestanden handmatig te ontgrendelen.

Momenteel toont Microsoft in documenten met VBA-macro's dat die schadelijke inhoud kunnen bevatten. Gebruikers kunnen met een enkele druk op een knop bij die waarschuwing de macro alsnog activeren. In de nieuwe situatie is dat niet meer het geval. Gebruikers zien dan een rode melding met de tekst: 'Security risk' en een knop voor meer informatie. Het is niet meer mogelijk om de macro's te activeren vanuit die melding. Dat kan alleen als gebruikers bij de eigenschappen van het bestand de vergrendeling handmatig verwijderen.

Nieuwe melding

Microsoft zegt de aanpassingen te doen om gebruikers te beschermen tegen kwaadaardige software. Macro's in Office-programma's zijn al decennia een manier voor criminelen om toegang te krijgen tot systemen. Beveiligingsonderzoeker Marcus Hutchins, die de WannaCry-malware wist te stoppen, juicht de stap toe, maar is er ook cynisch over. Hij schrijft: "30 jaar en miljarden malwareinfecties later heeft Microsoft besloten om het absolute minimum te doen."

De wijziging wordt voor het eerst doorgevoerd in de Preview van Office van begin april. Ergens daarna moet de verandering worden toegepast bij alle Microsoft 365-gebruikers. De blokkade van VBA-macro's komt naar de Windows-versies van Access, Excel, PowerPoint, Visio en Word. Ook oudere Office-versies krijgen de blokkade. Dat gaat om Office LTSC, Office 2021, Office 2019, Office 2016 en Office 2013.

Reacties (102)

[Prince]

VBA gaat weg, Office Scripts komt in de plaats; dat was toch al langer zo?
Je hebt ook Javascript Office Scripts; zeer vergelijkbaar met wat de G Suite gebruikt.

https://docs.microsoft.com/en-gb/office/dev/scripts/

[JB Zimmerman]

Het is me niet helemaal duidelijk wat de vervanger word. Zelf heb ik iets ontwikkeld met Excel DNA https://excel-dna.net/

Ik had .net libraries nodig die konden communiceren met Azure. Dat lukte niet via VBA. En daarnaast wou ik het wat meer future proof maken door het in C# te schrijven.

Maar ik lees ook over VSTO. Lijkt niet echt gemakkelijk te zijn: https://stackoverflow.com...cons-of-vsto-vs-excel-dna

Ik lees dat Office Scripts zich richt op web gebruik en de individuele gebruiker. Office Web-add-ins richten zich op de ontwikkelaar. https://docs.microsoft.com/en-us/office/dev/add-ins/

[Reactie gewijzigd door JB Zimmerman op 24 juli 2024 15:50]

[Tent2019]

Nu ben ik geen ontwikkelaar maar vraag mij af wat je dan doet met Excel en Azure?
Ik lees op https://excel-dna.net/ wat je er allemaal mee kan maar ik zie de link niet naar Azure
Wil jij dat kort uitleggen?

[Prince]

Office Scripts (in welke taal dan ook) is zoals VBA. Dus clear text met een JIT compiler-achtige constructie.

VSTO is een gecompileerde add-in die je in Visual Studio kan maken om Office pakketten uit te breiden.

Waar dus bij VSTO de sky de limit is tot wat je kan doen, maar in Office Scripts je binnen bepaalde grenzen moet wandelen.

Waarom zijn Office Scripts handig voor MS? Javascript in een sandbox draaien is iets wat reeds gebeurt in de browser en alle security issues die opgelost worden zullen ook direct een positieve invloed hebben op de Office Scripts.
VBA was een taal en tak die afzonderlijk te onderhouden was. Ook was VBA single threaded (los van een paar truckjes), maar met JS kan je direct al veel meer.
Ook is JS hoe hij vandaag is, klaar op de cloud, waar VBA dit in de verste verte niet was.

[fre0n]

Waarom is een andere scripting language geen probleem, wat is t dan specifiek aan VBA waardoor t zo te misbruiken is?

[joost00719]

Javascript is eenvoudig in een sandbox te runnen. Daarmee is het enorm lastig om jouw systeem om zeep te helpen.

[Ablaze]

Het heeft niets met de taal te maken. VBA komt uit de '90s en de implementatie heeft daardoor niet het veiligheidsniveau dat we nu vereisen.
VBA kan ook gewoon in een sandbox, het is net zo goed interpreted.

[Mars4i]

Eigenlijk zou MS 2 niveaus van macro's moeten maken.

Niveau 1 met alleen simpele functies zonder toegang tot het file systeem of registry. Deze zouden zonder problemen toegestaan kunnen worden.

Niveau 2 met alle functionaliteit. Hier moeten macro's pas activeren na waarschuwing.

Ook dan zouden ze bv een samenvatting kunnen geven van het soort functies dat gebruikt wordt. Als jij een spreadsheet opent waarin je macro's verwacht die wat speciale berekeningen uitvoeren, en de waarschuwing geeft aan dat die het file systeem benadert, weet je dat er iets mis is.

[GertMenkel]

Helaas werkt dat niet zonder alle bestaande macro's kapot te maken. De kracht van VBA is dat je data van internet kan koppelen met data uit willekeurige bestanden. Daar valt lastig een sandbox voor te schrijven die niet binnen een week omzeild wordt. Je kunt een heel Android-stijl permissiemodel aan sheets hangen maar ieder sheet zal toch toegang vragen tot vanalles en nog wat en mensen klikken al die waarschuwingen toch gewoon door.

Als je voor speciale berekeningen macro's nodig hebt, betekent dat eigenlijk gewoon dat Excel een functie mist (of een functie niet goed adverteert).

Wat misschien beter zou zijn is als de ingebouwde sandboxfunctionaliteit van Windows standaard gebruikt wordt voor sheets met macro's. Als er een virus in zit, zit dat alleen in je sandbox en kunnen er stappen worden ondernomen om te voorkomen dat er serieuze schade optreedt. Als je alleen maar berekeningen in je macro's doet, heb je daar verder ook geen last van.

Alternatief is het misschien tijd om VBA te laten vallen en een nieuw macrosysteem op te zetten. Baseer het maar op PowerShell of C# of VB.NET, en neem veiligheid deze keer mee in het ontwerp. Nog steeds zal zo'n systeem stikken van de virussen maar de huidige problematiek kun je er flink mee indammen.

Een leuke truc voor IT-beheerders: je kunt de tekst van de knop om macro's in te schakelen veranderen zodat de nepsheets die gebruikers oproepen op een bepaalde knop te klikken niet meer klopt. Misschien de effectiefste oplossing zou zijn om van de knop "installeer virus" te maken, dan blijven hopelijk de mensen die niet weten wat het gevaar van VBA is van dat ding af.

[beerse]

Juist het voorstel om niet 1 alles-of-niets schakelaar te maken maar dat in 2 of 3 stappen te doen is wel een aardig idee. Natuurlijk, met elke blokkade maak je macro's stuk. Maar door dat in 2 of 3 niveaus te doen sloop je minder of hoef je minder 'beveiligingen' te 'doorbreken'.

Mijn ideeën voor stappen:
Laag 0: Geen vba en zo.
Laag 1: alleen document interne zaken. Zoals opmaak, inhoudsopgaves en dergelijke.
Laag 2: bestanden kunnen lezen.
Laag 3: bestanden kunnen schrijven.
Laag 4: externe commando's opstarten/aansturen.

Daarnaast ben ik al jaren van mening dat visual basic niet echt een taal is om voor dit soort zaken te gebruiken. Met een microsoft pet op zou ik tegenwoordig een powershell interface wensen.
Met een unix/linux pet op had het natuurlijk al lang al een universele script interface moeten zijn met een #! constructie waarbij naar keuze sed, awk, sh/ksh/bash of perl gebruikt kan worden en ondertussen ook andere talen zoals python en dergelijke.

[PageFault]

In powershell kun je nog wel meer schade aanrichten dan met VBA.

Die lagen klinkt theoretisch leuk, maar waarschuwingen naar eindgebruikers doet me denken aan cookie walls, toestemming geven voor 'benodigde' resources voor een Android app en zelfs toestemming geven wanneer de authenticator app er om vraagt. Na een tijdje is iedereen het zat en klikt uit ellende gewoon "accept all". Dan schiet je je veiligheidsdoel dus ook voorbij.

[Yoshi]

Excel gaat naar alle waarschijnlijkheid javascript ondersteunen
https://techcrunch.com/20...ings-javascript-to-excel/
Misschien wordt dat wel wat, nuja, niet dat je met javascript geen malacious code kan uitvoeren
Verder, die macro's horen gewoon op een trusted location te staan, dat houd ook al veel gezeik tegen maar vereist idd een zekere samenwerking met je IT departement. (imho)

De wijziging die jij voorhoudt, houdt veel in en gaat meer kapot maken dan enkel ervoor zorgen dat het niet loopt. En legacy is vrij belangrijk bij bedrijven, zeker wat betreft die macro's die jaar geleden zijn geschreven door iemand die al lang met pensioen is en waarin een kat haar jongen niet meer kan vinden. (of het is hoe je het bekijkt, ook daar valt veel over te zeggen)

[Reactie gewijzigd door Yoshi op 24 juli 2024 15:50]

[Mars4i]

Excel kan moeilijk ale mogelijke functies bevatten. b.v. de conversie van allerlei Imperial units naar SI eenheden. Je kan daar eenvoudig een functie voor maken in Excel. Het is zeer irritant dat voor dit soort simpele functies allerlei beveiligingsfuncties activeren. Niet alleen in Excel (MS office), maar ook virusscanners in e-mail programma's.

Ben het er mee eens dat ze het XLSM format met rust moeten laten. Maar ze zouden een naast XLSX een derde format kunnen maken met een beperkte VBA functionaliteit. In mijn ideale wereld zou dan het complexe XLSM bestand, dat met geavanceerde macro's allerlei data uit allerlei bestanden ophaalt en converteert, opgeslagen kunnen worden in dit derde formaat welke naar klanten gestuurd kan worden met beperkte functionaliteit (zoals de genoemde unit conversie). Dromen mag altijd

[Anoniem: 1322]

Alternatief is het misschien tijd om VBA te laten vallen en een nieuw macrosysteem op te zetten.
Zoiets als Google appscript? Of meer in de trend van Power automate?

Het probleem van VBA macro's is niet dat de tools er niet voor zijn, het probleem is dat men te lui is om er mee bezig te gaan

Ik heb bij verschillende organisaties macro's eruit gewerkt. Microsoft biedt hier prima tooling voor om ze ook in kaart te brengen. Je kunt de beveiliging ook gefaseerd opvoeren. VBA macro's werken ook helemaal niet in een moderne werkplek dus het is vooral oud zeer waar men niet aan wil zitten (als in, het draait toch?).

[RxTweak]

Een soort sandbox omgeving of een readonly omgeving zou ook een oplossing kunnen zijn.

[naaitsab]

Tijdje geleden bij Microsoft Azure meegekregen dat ze bezig zijn met Office containers. Soort Docker idee. Al was dit vooral geënt op het snel publishen van apps in je Azure omgeving. Nadeel alleen van Office pakketten is dat het eigenlijk 50/50 is dat je bij bestanden moet komen met schrijfrechten. Voor iets wat meestal read-only is zoals een PDF is het makkelijk af te vangen maar denk dat het lastig gaat worden met een documenten tool.

Wat het nog lastiger maakt is dat men ook vaak bestanden vanaf het netwerk benaderd in zakelijke omgevingen. Dus schrijfrechten beperken tot de Documenten map en toegang naar buiten blokkeren bijvoorbeeld is ook geen optie.

Aan de andere kant worden VBA Marcro's ook vaak mis-/gebruikt om Office apps om te bouwen tot bedrijfsapps in plaats van dedicated software kopen/maken. Dus dat dit links en rechts een beetje wordt uitgefaseerd vind ik ook wel weer een bonus. Vaak genoeg gezien dat een bedrijfstak runt op Excel macro's en dan meestal iets antieks wat gemaakt is door iemand die al lang weg is bij het bedrijf....

[Wizard]

Aan de andere kant worden VBA Marcro's ook vaak mis-/gebruikt om Office apps om te bouwen tot bedrijfsapps in plaats van dedicated software kopen/maken. Dus dat dit links en rechts een beetje wordt uitgefaseerd vind ik ook wel weer een bonus. Vaak genoeg gezien dat een bedrijfstak runt op Excel macro's en dan meestal iets antieks wat gemaakt is door iemand die al lang weg is bij het bedrijf....

Het probleem met veel bedrijfsapps is dat ze vaak slechts 25% business logica bevatten en voor de rest gewoon draaien op 75% office standaarden.

Dan kan je idd best de 75% office standaarden gaan nabouwen in je eigen officiele apps, maar je baas zal toch echt vrolijker zijn als je die 25% in vba douwt... Iets met efficiëntie etc.

[Verderf]

Office kan je al in containers draaien met Application Guard.

Ik ben dit toevallig zelf aan het testen voor onze eigen omgeving.
https://docs.microsoft.co...guard?view=o365-worldwide

[JurGor]

Dit. 100% helemaal dit.

Ik script zelf ook handelingen in VBA en daar heb ik echt geen functies voor nodig die door kwaadwillenden misbruikt kunnen worden.

Als ik iets maak in VBA, neem ik de acties die ik wil laten doen eerst op, vervolgens schrijf ik de opgenomen macro om zodat deze goed werkt. Eventueel een dialoogvenster erbij, koppelen aan een knop in de sheet en dan is het dat alweer. Maar het scheelt me een hoop onnodige herhaalde manuele acties.

Dat soort simpel niveau macro's moet niet in de weg gezeten worden door, op zichzelf broodnodige, beveiliging.

[martburg]

de beveiliging geldt voor ge-download-de macro's. Ga lekker je gang, en dupliceer de gemaakte macro's naar andere mensen in jouw organisatie door tekstfiles te mailen, die iemand kan plakken in een eigen gemaakte nieuwe macro. Veilig want er komt meer bij kijken dan alleen een KLIK.

[JurGor]

Ik weet niet of ik houtje-touwtje oplossingen waarbij je eindgebruikers vraagt om "code" als tekst (dus scanners omzeilend) te knippen en plakken en in andere documenten uit te voeren echt als veilig moet zien.

Maar het is inderdaad een manier om de beveiliging te omzeilen, da's zeker waar.

[Wizard]

Dan ga je een beetje log4j problematiek krijgen.

Functies kunnen er heel simpel uitzien, maar via via via via mogelijkheden kan je dan toch nog iets wegschrijven.

Normaliter maak je dit soort niveau's ook enkel als je een systeem van scratch gaat opzetten zodat je exact weet wat alles doet en wat de impact is.
Bij een bestaand systeem is dit onderscheid bijna niet te maken en gaat het zo goed als altijd fout.

[uiltje]

Je filtert op de IO laag, niet op de functie inhoud. Dat is zelfs theoretisch onmogelijk om helemaal correct te doen.

[laurens0619]

Dat bestaat ook voor een gedeelte: ASR rules
Daar kun je regels instellen als:
- Block all Office applications from creating child processes
- Block Office applications from creating executable content
- Block Office applications from injecting code into other processes
- Block Office communication application from creating child processes
- Block persistence through WMI event subscription

Daarmee hou je het meeste van de reguliere malware tegen als Trickbot en Emotet.
Helaas vallen hier ook enkele legitieme business applicaties mee om (te ranzig voor woorden hoe sommige macros geschreven zijn) maar gelukkig kun je ook met ASR deze business bestanden whitelisten.

Rigogeur macros blokkeren, ik moet maar zien of ze dat echt gaan doorvoeren (met basic authentication hadden ze grote plannen). Denk dat een goede eerste stap zou zijn om malicious macro gedrag te blokkeren dmv ASR

[BoAC]

Een handige toevoeging hierbij zou zijn: trustlocaties voor url's en bestandslocaties. Het probleem is echter dat met vba com-objecten kunnen worden ingeladen, en dan is het hek van de dam..

[loewie1984]

Zoals ik het zie heb je hier meerdere opties om toe te passen om je organisatie te wapenen tegen onveilige macro's:
1. Indien je gebruik maakt van MS365 een contentfilter op bestandsextensies in e-mail bijlages, waaronder dotm, xlsm en xlm bestanden
2. het correct inregelen van je macro policies waarbij je onder andere gebruik maakt van veilige locaties in Office
3. de keuze om eigen macro's digitaal te ondertekenen (kanttekening is wel, als je veel macro's hebt en een korte geldigheidsduur van je certificaat je ze iedere keer allemaal individueel opnieuw komt te ondertekenen)
4. dit onderdeel te laten zijn van je user awareness training
5. het gebruik van macro's beperken dan wel mijden (niet altijd haalbaar)

[glaaj]

Ik ben benieuwd hoe lang het duurt voordat management bij de IT-afdeling aan de telefoon hangt om dit z.s.m weer aan te zetten zodat ze kunnen werken

[Finraziel]

Mja, het eerste wat ik nu ook denk is dat de waarschijnlijkheid dat users nu correct omgaan met mijn ontwikkelde Excel sheet flink keldert.
Ik begrijp de stap, maar toch jammer dat beveiliging de usability weer moet beperken.

[IStealYourGun]

mijn ontwikkelde Excel sheet

Klinkt als interne sheets? Dan zou er geen impact mogen zijn, want dit gaat enkel op voor sheets die gedownload zijn.

Microsoft legt het mooi uit in een chart: https://techcommunity.mic...ge-size/large?v=v2&px=999

[Finraziel]

Ah, dan ligt het wellicht aan de configuratie door IT hier want files die van onze sharepoint komen hebben wel regelmatig de macro's uitgeschakeld.

[Sjekster]

Zal bij ons dan ook zo zijn, ik moet nagenoeg altijd op macro's inschakelen drukken bij bestanden die op onze sharepoint omgeving staan.

[IStealYourGun]

Vermoedelijk download je ze dan eerst en open je ze niet rechtstreeks vanuit share Point. Sowieso als je de code signed, zou het ook geen issue mogen zijn.

Misschien best eens met je it department praten.

[SPee]

Weet de gemiddelde Office VBA programmer wel hoe de code gesigned moet worden.

[geekeep]

Mja, het eerste wat ik nu ook denk is dat de waarschijnlijkheid dat users nu correct omgaan met mijn ontwikkelde Excel sheet flink keldert.

Misschien iets anders proberen dan macro's in Excel (wat al tig jaar als onveilig wordt bestempeld) om te bereiken wat je wilt?

Ik begrijp de stap, maar toch jammer dat beveiliging de usability weer moet beperken.

Ik kan werkelijk geen enkele vorm van beveiliging bedenken die de usability verbetert of op z'n minst gelijk houdt. Een doodnormale deurklink in de fysieke wereld is al minder 'usable' dan een open doorloop. Beveiliging is altijd een 'blokkade' voor ongewenst bezoek, die met behulp van 'iets' door een rechtmatige gebruiker opgeheven kan worden.

[hansa1971]

Wat is het (veilige) alternatief? En wordt die ook als zodanig naar voren geschoven? Is dat duidelijk voor de excel gebruikers?
Volgens mij is het antwoord, Is er niet, Nee en Nee. En daardoor heeft het 0 kans van slagen.

[cracking cloud]

Gegevensvalidatie die onjuiste invoer en daarmee allerlei problemen voorkomt?

[AcidBanger]

Eigen add-ons schrijven voor Excel

[cracking cloud]

vaak is zo'n excel sheet al erg oud, in mijn geval een access database van bijna 15 jaar.

[walteij]

Dan rijst al snel de vraag of daar ondertussen geen betere oplossingen voor te vinden of te maken zijn, waar je die data naartoe kunt brengen.

[cracking cloud]

kost tijd en geld + mogelijkheid om nieuwe fouten te introduceren die er nu niet zijn. Voor de meeste (mkb) bedrijven geldt: waarom kosten maken als het werkt

[walteij]

Omdat er ook risico's hangen aan software die werkt maar niet meer aan de moderne veiligheidseisen voldoet. Je bedrijfsgegevens kunnen op straat komen te liggen, inclusief alle gegevens over je klanten.
De reputatieschade is dan al snel groter dan de kosten voor het vervangen van de software, die je dankzij het veiligheidslek toch moet vervangen.

Voor veel MKB is ICT een kostenpost in plaats van een resource, terwijl je ook als MKB bedrijf meer en meer afhankelijk wordt van die ICT. Wie weet zijn er ondertussen veel elegantere en betere oplossingen voor dit probleem, die ook nog eens gebruiksvriendelijker en/of sneller werken, doordat het bedrijfsproces gestroomlijnd kan worden.

[cracking cloud]

ja die theorie klinkt mooi, praktijk is vaak anders! gaat in dit geval niet om klantgegevens btw. er wordt trouwens gewerkt aan vernieuwing, maar dat kost nog wel wat tijd.

[Reactie gewijzigd door cracking cloud op 24 juli 2024 15:50]

[HansvDr]

En dan hangen ze het in een zelf geknutseld web-systeempje of nog erger en wordpress site die nooit meer geupdate wordt.

Doe dan maar een aantal VBA macro's

[walteij]

Dat is inderdaad een nog grotere draak.....
Maar met een fatsoenlijke dienstverlener en een duidelijk wensenpakket moet je als bedrijf de juiste keuzes kunnen maken.
Veel MKB bedrijven hebben een specialistische taak die vervuld moet worden, daarvoor is inderdaad vaak maatwerk nodig, maar voor de generieke zaken, zoals boekhouding, salarisadministratie, marketing, sales, HRM enzovoorts zijn juist prima SAAS oplossingen te vinden voor een schappelijke prijs, waarbij je dan de keuze hebt;
- Gaan we voor duur en flink maatwerk zodat we de huidige processen kunnen blijven gebruiken
- Gaan we kijken of we processen kunnen verbeteren, zodat we minder maatwerk in de software nodig hebben en daardoor minder kosten;
- Gaan we de processen aanpassen aan de standaard processen van de software, omdat deze effectief ook doen wat we nodig hebben.

Iedere MKB directeur denkt te weten wat het beste is voor zijn bedrijf en wat het beste werkt. En dat is meestal waar als het gaat om het product waar het bedrijf zich mee bezig houdt, maar de generieke zaken moet je zo weinig mogelijk maatwerk in proberen te zetten. Daar zijn SAAS oplossingen juist heel sterk in, de generaliseren de processen op een dusdanige manier dat bijna ieder bedrijf (en zeker MKB) hier goed mee overweg moet kunnen.

[HyperBart]

Waarom hebben jullie dan ooit een modernisering gedaan en zijn jullie overgestapt naar computers? Pen en papier werkte toch?

Gaat om risico’s kaderen en context schetsen. Leuke gesprekken.

[cracking cloud]

Deze applicatie was gemaakt bij de start van het bedrijf. Inmiddels is het bedrijf gegroeid en is er andere software in gebruik genomen voor de overige processen, maar 1 proces draait nog op deze office applicatie.

edit: laat ik het zo zeggen: alleen een wijziging vanuit de leverancier is niet voldoende reden om de zaak overhoop te gooien. (veranderende wensen, schaalvergroting e.d. bijvoorbeeld wel).

[Reactie gewijzigd door cracking cloud op 24 juli 2024 15:50]

[HyperBart]

Snap ik, maar voor jullie business is blijkbaar dan niet duidelijk wat de risico’s zijn door het gebruik van dit soort oplossingen. Stapje uit de techniek, risico-kader uitzetten. Wil je die risico’s wel nemen ondanks dat kans en impact (direct en indirect door loss or productivity) duidelijk geschetst zijn? Prima, dan heb je het ten minste aangekaart…

[martburg]

Ken ik ook,werk er zelf ook mee: access 2004 applicaties om vrijwilligers thuis op hun PCtje archiefgegevens in te laten voeren en/of te verifieren op basis van scans op het web. Zo'n organisatie is blij dat ze vrijwilligers hebben, die wil je toch niet wegjagen met "betere" programma's, die ze niet beheersen? Iets wat al 20 jaar feilloos werkt? Ik zie de bibliothecarissen al een voor een op bezoek gaan om ze in te leren!

[SuperDre]

Tja, dan moet je voor elke excelsheet een aparte addon schrijven die dan ook weer eerst voor gebruik geinstalleerd moet worden. Over nog omslachtiger gesproken, en nog meer troep die excel dan telkens bij moet laden.

[matroosoft]

Er is toch een ingebouwde gegevensvalidatie?

[Finraziel]

Normaal gesproken werken de betreffende users ook niet met dit soort files maar met software specifiek ontwikkeld voor het doel. In dit geval gaat het toevallig om een workaround omdat bepaalde functionaliteit absoluut geleverd moet worden terwijl het nog te lang duurt om de reguliere software te voorzien van de benodigde aanpassingen.

Goed, dat soort uitzonderingen ga je natuurlijk niet het wereldwijde beleid op Excel voor aanpassen maar ook lang niet alle bedrijven hebben de luxe van eigen interne software. Vooral wat kleinere bedrijven kunnen dat gewoon niet voor alle toepassingen betalen.

[raswic]

Precies dit.

Wat is nu eigenlijk een goed alternatief? Zonder dat de (excel) gebruiker extra software moet installeren.

[Nardon]

Helaas werkt usability en beveiliging vaak tegen elkaar. Lekker makkelijk voor gebruikers om allerlei scripts uit te kunnen voeren.. helaas ook lekker makkelijk voor de hacker.

Het een hele dans om usability / security goed te balanceren.

[Aetje]

Dit. Ik werk zelf op de helpdesk bij een grote IT speler in ons kikkerland. Je wilt niet weten hoeveel bedrijfskritische processen aan elkaar geknoopt zijn met wat handige Excel documentjes met scripting. En niet alleen zelf ontwikkelde tools. HR en Sales gaan zeker een probleem hebben.

Niet lang geleden had IT Security al een algeheel verbod op deze vorm van scripting uitgerold per policy. Dat duurde minder dan een week voordat iedereen die klaagde een "uitzondering" werd op de policy.

[LOTG]

Precies dit is het probleem. Men gaat zelf lopen hobbyen in Excel, of als er iets gemaakt moet worden word Excel als requirment gegeven in plaats van wat men wil bereiken.

Vaak zat gezien dat men een complete database in Excel zat te ontwikkelen. Data uit van allerlei files werd bij elkaar geharkt met links zo dat het lekker up to date was. En dan gaat er iets stuk en ligt het hele proces plat, word er een fix gemaakt en heeft maar de helft een nieuwe versie van de file en er waren er al drie in omloop die op shares werden gedumpt.

En dan mag je als developer dat komen fixen, en draait je maag al om als je er naar kijkt.

De helft kan gewoon daar waar het thuis hoort: de database, de rest kan in een fatsoenlijke add-in die ook mooi beheerd kan worden zo dat men met de zelfde versie werkt. En eigenlijk kan in veel gevallen die hele scheet vervangen worden door een applicatie die alles fatsoenlijk doet in plaats van het in Excel te hacken.

Men moet gewoon af van die extase die een excelsheet sommige mensen brengt. Dat het kan betekend niet dat het ook een goed idee is.

[Aetje]

Yep. Het leeuwendeel van die excel sheets hoort een frontend voor een Access database te zijn, oid. Maarja, Excel zat standaard in office tot een paar jaar terug. Access niet. Het was goedkoper om Excel als database te misbruiken.

[nullbyte]

2 seconden, maximaal...

[themadone]

Kunnen ze doen, ik zal ze de kalender laten zien die toch echt aangeeft dat we in 2022 leven.

Als kritische processen aan elkaar hangen van VBA macro's in een office pakket heb je het niet helemaal begrepen.

Met een beetje mazzel sloopt dit meteen alle oude access databases die wel handig waren ooit in het verleden en nooit vervangen zijn door wat knaps.

[i7x]

Ik maak ook regelmatig macro's met vba. Het doet wat je wilt en is redelijk eenvoudig. Desondanks kijk ik uit naar wanneer vba ooit zal verdwijnen. Organisaties zijn al snel geneigd enorme processen aan elkaar te knopen met Excel vba bestandjes die dan later ook nog moeten worden uitgebreid tot een onbegrijpelijke jungle aan code.

Meestal zou een veel betere oplossing zijn gewoon dedicated software gebruiken voor wat je eigenlijk wilt bereiken. Zal in het begin zeker prijziger zijn, maar wel veel duurzamer op termijn.

Ik denk dat Microsoft stiekem ook van vba af wil. Je merkt het in de kleine dingen; in Excel werken veel nieuwe attributen niet meer met vba, waar je er vroeger nog ongeveer alles mee kon aansturen (ik bedoel bijvoorbeeld nieuwe charts waarbij je niet meer alle details van de opmaak ook met vba kunt aansturen), en Microsoft ook eens een versie op de Mac uitgebracht zonder vba (2008). Dat is later wel weer teruggekomen, maar is wel een teken aan de wand natuurlijk. Je hebt ook nog gedoe met x64 dat minder vba features heeft.

[Reactie gewijzigd door i7x op 24 juli 2024 15:50]

[OxWax]

Ik maak ook regelmatig macro's met vba. Het doet wat je wilt en is redelijk eenvoudig. Desondanks kijk ik uit naar wanneer vba ooit zal verdwijnen. Organisaties zijn al snel geneigd enorme processen aan elkaar te knopen met Excel vba bestandjes die dan later ook nog moeten worden uitgebreid tot een onbegrijpelijke jungle aan code.

Office ADD INS
https://docs.microsoft.co...ew/learning-path-beginner

https://docs.microsoft.co...in-for-excel?view=vs-2022

[Reactie gewijzigd door OxWax op 24 juli 2024 15:50]

[MattiVM]

Daar ben ik het helemaal niet mee eens. Niet voor alles bestaat er "dedicated software" die alle functionaliteiten aanbiedt die je nodig hebt. Zoek maar eens software die hetzelfde kan als Excel/Access in combinatie met VBA en macro's... EN dat een leek kan begrijpen en gebruiken!

[SPee]

Is MS met Azure en O365 niet bezig om zich daar wat meer op te richten?
Met Power Apps, Power Automate en Power BI willen ze het makkelijker maken om "kleine dedicated apps" te maken. Voordeel voor MS is dan ook gelijk dat het geen offline applicatie is en dus grotere afhankelijkheid met hun cloud heeft.

[i7x]

Access is nog zoiets dat ik op termijn wel zie verdwijnen. Wie zet er vandaag de dag nog een nieuwe Access database op? Iig niet in mijn omgeving. En wat de ander ook al aangaf, toekomst lijkt een beetje richting Power Automate te gaan. Daarbij heb je inderdaad vast niet voor alles een pasklare oplossing, maar zeker wel voor een hoop zaken. En voor de rest denk ik dat het ook zeker geen kwaad kan anders eens je gehele processen te heroverwegen als ze al 10+ jaar leunen op excel vba bestandjes die her en der worden rondgestuurd.

Nogmaals, ik schrijf ze nota bene zelf regelmatig, maar ik zie ook heel veel nadelen van deze manier van processen draaiende houden. Bijvoorbeeld, wij hebben hele work flows in excel met vba, telkens gedoe omdat het op SharePoint staat en je kunt wel raden hoe dat ongeveer verloopt. Dan denk ik gebruik gewoon Asana oid, maar zo werkt men al 10 jaar en dat gaat er dus echt niet in.

[SinergyX]

Uit onbekende bron werd deze toch standaard al uitgeschakeld? Al blijft het altijd een raar principe wat nu precies een 'untrusted source' is, een excelsheet met VBA zelf opslaan is trusted, maar deze via onedrive weer openen is opeens een 'untrusted source'... logica.

[Mellow Jack]

Excel kan lastig zien of iets uit jou onedrive komt of dat je een bestand wilt openen die met jou gedeeld is

[lighting_]

Een extra stap. Das beter voor veiligheid.

[Mi Chiel]

Security through obscurity.

[bazzi]

Tenzij die stap achter een policy kan komen en uit staat voor iedereen

[Mi Chiel]

Mja deze situatie is alleen van toepassing als alle policies die hiervoor zijn al uit staan he
https://techcommunity.mic...ge-size/large?v=v2&px=999

[Reactie gewijzigd door Mi Chiel op 24 juli 2024 15:50]

[bazzi]

Weer wat geleerd, weet gelukkig weinig van windows en de policies

[bartje]

Ik heb ooit een opdracht gehad om een vba applicatie te maken. Hier kwam ook een word installer.
Met 1 keer toegang kom ik register keys toevoegen om macro’s in andere bestanden zonder vragen uit te voeren.
Was niet echt veilig. Maar wel de enige manier waar gebruikers er mee konden werken.

[cricque]

Krijg rillingen als ik terugdenk aan wat ik allemaal vroeger gezien heb. Enja ik heb ook nog vba scripts gemaakt etc. Waar het wel goed voor is, is automatisatie (dat kon vroeger moeilijk anders, begin jaren 2000). Word documentje opmaken en dingen uit jouw applicatie invullen enzo. Maar is een goede zaak. Velen klikken maar weg. VBA zal nooit verdwijnen, veel te veel bedrijven steunen er op (helaas). En de kost om iets anders op poten te zetten is te hoog, we hebben nu toch iets dat werkt, dus waarom moeten we iets anders hebben.
Een rekenblad is een rekenblad en daar moet je geen hele bedrijfsautomatisatie achter steken.

[Faust]

Is het sowieso niet handiger om een 'virusscanner' in office/excel in te bouwen?
Ik begrijp dat het programma ontworpen is om blijkbaar volledige toegang tot elk systeem te hebben, en met een kwaadwillende macro kan een systeem volledig gecompromitteerd zijn, maar dan zou je denken dat ze beter gewoon een scanner in excel doen als de gewone windows virusscanners het niet kunnen opvangen.