Open source cms'en worden steeds populairder. Pakketten als Alfresco, Joomla, WordPress en Drupal worden steeds vaker ingezet voor interne en externe websites. Deze pakketten voldoen aan de criteria voor de volgende generatie cms'en, oftewel ze passen prima binnen Enterprise 2.0. Forrester (1) signaleerde in 2008 dat cio's serieus zouden moeten kijken naar met name Drupal en Alfreso. Een uitspraak die mede is gebaseerd op het feit dat de stabilteit en het aantal implementaties voldoende zijn om het als serieuze optie te overwegen, zoals later wordt toegelicht in een interview met CNET (2).
Zijn open source cms'en echter ook op security vlak enterprise waardig? Een artikel uit Informationweek dat vrijwel tegelijkertijd met het zojuist genoemde Forrester rapport uitkwam, zet een aantal kwetsbaarheden in verschillende pakketten op een rij voor onder meer Moveable Type, WordPress, Drupal en Joomla.
Toegegeven, niet elk lek is even ernstig, maar sommige toch zeker wel. Zo kwam er in Joomla 1.5.x vorig jaar augustus een lek aan het licht dat het mogelijk maakte om volledige controle te krijgen over het cms. Ook kon In versie 4 van Drupal relatief eenvoudig zelfgeschreven programmacode door internetgebruikers worden uitgevoerd dankzij een lek in basis van het systeem. Een analyse van de andere open source cms'en laat zien dat (ernstige) lekken daar net zo goed voorkomen.
Veiligheid in open source laat dus te wensen over. Vooropgesteld dat veiligheid geen exacte wetenschap is, kunnen er zeker een aantal nuances bij deze bewering worden geplaatst.
Zo is het aantal installaties van Drupal en Joomla aanzienlijk hoger dan van bekende closed source cms'en zoals Tridion, Green Valley of SiteCore. Daardoor wordt het een meer aantrekkelijke prooi voor hackers en raken lekken sneller bekend. Ook is het aantal modules bij open source veel groter. Voor Drupal zijn er duizenden modules en voor closed source cms'en gemiddeld minder dan vijftig. Doordat er meer modules zijn, is de kans dat er één een veiligheidslek bevat groter. Daarnaast is het gebruikelijk om veiligheidslekken snel bekend te maken bij open source, wat bij kleinere closed source cms'en ook minder aan de orde is.
Verder is het zo dat er een aspect is te benoemen dat zeer belangrijk is voor veilige (cms-) software. Dat betreft de integrale inbedding van reviews op code en anticipatie op mogelijke gevaren. Kortom: veiligheid is iets dat besloten moet zijn in de software ontwikkeling van een cms. Deze bevinding is ook te lezen in een rapport dat is geschreven over de veiligheid van Drupal. Hierin wordt gesteld dat securtiytraining van ontwikkelaars en het beschikbaar stellen van een eenvoudige api sleutelfactoren zijn voor een veilig systeem.
Nu lijkt het trainen van de ontwikkelaars lastig te organiseren voor de community van bijvoorbeeld Drupal. Dit is dus een punt van aandacht, wat dan ook geadresseerd is. Pakketten zoals Drupal en Joomla hebben een integrale controle op de veiligheid van alle modules door een verplichte review door een security team.
Na al deze punten op een rijtje te hebben gezet, kan denk ik worden gesteld dat een open source cms niet per se veiliger of onveiliger is dan een closed source cms. Immers, hoeveel veiligheidsissues lost Microsoft niet op in bijvoorbeeld Internet Explorer. En hoe veilig is SharePoint als cms nu eigenlijk? Als we hier op afgaan, lijkt het aantal security incidenten eerder een verband te hebben met de schaal waarop de software wordt toegepast , dan met het feit of het open of closed source is.
Met dat in het achterhoofd, is er toch nog een belangrijk verschil te benoemen. De verantwoorlijkheid ligt bij open source anders dan bij closed source. Waar bij closed source de verantwoordelijkheid voor de security meer bij de Vendor ligt, zal deze bij open source meer bij de implementerende partij liggen. Immers, de open source community kan moeilijk aansprakelijk worden gesteld als rechtspersoon. Dit kan met een system integrator echter wel.
Om deze verantwoordelijkheid goed te nemen zal de implementerende partij bij het gebruiken van cms-modules telkens extra moeten toetsen op security. Ook zal de integrator moeten controleren of modules zijn vrijgegeven door een security team, er een goede ondersteuning is en of er patches beschikbaar zijn.
(1) Forrester, 2008. http://forrester.com/Research/Document/Excerpt/0,7211,46162,00.html
(2) CNET, 2008. http://news.cnet.com/8301-13505_3-9973824-16.html
Een pakket als WordPress heeft tegenwoordig een geweldige auto-update functies, ook voor de plugins. Bij het bedrijfsmatig gebruik van dergelijke pakketten is het belangrijk om afspraken te maken over regelmatige updates. Bedrijven die dit niet doen, snijden zichzelf in de vingers. Ten eerste hebben ze een boze klant en ten tweede kunnen ze geld verdienen door een vast bedrag per maand/jaar te vragen voor het bijhouden van de software.
Deze open source pakketten zijn in de regel zeer veilig. Patches zijn vaak snel gemaakt en worden snel vrijgegeven. De problemen met bijvoorbeeld Joomla zijn vrijwel altijd te wijten aan het niet bijhouden van security updates. Doordat het op zo’n grote schaal gebruikt wordt, is het voor crackers interessant om gericht en geautomatiseerd op zoek te gaan naar Joomla sites.
Een open source pakket zoals Drupal, Joomla, WordPress of Typo3 heeft ook als voordeel dat er zeer veel ontwikkelaars tegelijk mee bezig zijn, waardoor er veel sneller security-leaks ontdekt kunnen worden en er dus ook veel sneller een oplossing voor wordt aangeboden.
http://www.mia.be
Dit is een tamelijk ongenuanceerd artikel, er zijn namelijk enkele honderden open source CMS-sen. Ik geloof niet dat dhr. Wasse die allemaal kent.
@Jan: ik heb geprobeerd de meest gebruikte Open Source CMS-en te bekijken. Verder kijk ik naar het model waarmee open source software tot stand komt. Dat zou dus niet heel anders moeten zijn bij andere CMS’en.
Dus wellicht zijn sommige Open Source CMS’en veiliger of gaan ze anders met veiligheid om. Dit neemt mijn punt niet weg.
Aardig artikel en inzichtelijk. Echter, refereren naar veiligheidsissues in Drupal 4 is niet echt relevant nu versie 7 alweer in de maak is. Van Drupal is ook een commerci?le variant, Aquaio, waar het voor een implementerende partij mogelijk is om middels ??n beheerinterface de benodigde updates te zien van alle door deze partij gemaakte websites. Zo kan een beheer-afdeling eenvoudig zorg dragen voor het patchen van veiligheidslekken. Versie 6 van Drupal heeft de Update Status module ingebakken, zodat de beheerder gelijk doorkrijgt via de mail of de site aan een update toe is.
Open Source leveranciers als Alfresco, Joomla, WordPress en Drupal op een hoop gooien, is wat mij betreft hetzelfde als oplossingen als FileNet van IBM, Documentum van EMC en Smartsite over een kam scheren. Dit is blogsoftware, web content management en Document Management/ECM op een hoop gooien. Beetje ongenuanceerd inderdaad. Dat je geen bedrijfskritische online uitingen moet draaien in eenvoudige “freeware” oplossingen lijkt me een kwestie van GBV. Ga dan voor supported versies van Open Source die wel Enterprise Solutions bieden. Het jammerlijke van dit soort uitingen is dat het bijdraagt aan een onfundeerd angstig sentiment ten opzichte van Open Source.
En wat te denken van e-commerce systemen als Magento? Als er ergens waardevolle informatie vandaan gehaald kan worden, dan is het wel bij e-commerce systemen.
@Paul: Ik herken koudwater vrees om een open source CMS bedrijfsmatig toe te passen. Dit sentiment probeerde ik te adresseren ten aanzien van het hiermee verbonden veiligheidsaspect.
Er is volgens mij dus in de basis GEEN reden tot extra voorzichtigheid, het is wel zaak om (technische) support goed te borgen. Het nemen van een commercieel ondersteunde variant van een OS CMS kan inderdaad een prima oplossing zijn.
Jammer dat er in dit artikel alleen naar bronnen van Amerikaanse origine is gekeken. Een pakket als TYPO3 heeft inderdaad in Amerika minder naamsbekendheid en toepassing, maar is in Europa een van de meest toegepaste open source content management systemen. Amerika is echt anders dan Europa.
Roy schreef: “Veiligheid in open source laat dus te wensen over.”
Reactie: Bij closed source software is het veel slechter gesteld als het gaat om het fixen van bugs (want daar hebben we het hier over). Microsoft moet bijvoorbeeld om de haverklap nieuwe security patches uitbrengen. Bij open source kan hier een hele community aan werken. Bij closed source (vaak) alleen de editor. Dus het risico is bij closed source veel groter.
Roy schreef: “Waar bij closed source de verantwoordelijkheid voor de security meer bij de Vendor ligt, zal deze bij open source meer bij de implementerende partij liggen.”
Reactie: “Security” heeft vooral te maken met de wijze waarop software wordt geimplementeerd en de processen eromheen. Closed source vendors nemen geen verantwoordelijkheid als het gaat om de veiligheid van de software of implementatie. Welke verantwoordelijkheid nemen bijvoorbeeld Microsoft of Oracle als het gaat om veiligheid? Bij closed source sluit je een licentieovereenkomst af om gebruik te mogen maken van de software en een support contract zodat je ze helpen bij problemen. That’s it. Bij open source software zie je juist dat bugs sneller en beter worden opgelost dan bij closed source. De active community heeft een zeer waardevolle rol. Voor gebruikers en system integrators is het wenselijk (soms vereist) dat zij terug kunnen vallen op een professionele supportorganisatie. Ook deze dienst wordt bij open source vaak aangeboden.