Hét informatieplatform over cloudoplossing en -bedrijven

Contact

Beveilig clouddata met shared responsibility model

Beveilig clouddata met shared responsibility model
13 October 2020 09:17 uur

Data die wordt opgeslagen in softwareComputerprogrammatuur ge�nstalleerd op onderliggende apparatuur om automatiseringsdiensten aan gebruikers te kunnen bieden as a service (saas)-applicaties zoals Microsoft365 en Google G Suite zijn net zo kwetsbaar voor ransomware, dataverlies of andere beveiligingsproblemen als gegevens die zijn opgeslagen in on-premise applicaties. In de gebruikersovereenkomsten van saas-applicaties staat duidelijk vermeld dat gegevensbescherming, beveiliging op gegevensniveau en behoud van data op lange termijn uiteindelijk de verantwoordelijkheid van de eindgebruiker zijn. Dat is ook de reden waarom Microsoft bijvoorbeeld backup door een andere partij aanraadt.

Het is een misvatting dat saas-data automatisch beschermd wordt op de juiste manier. De eindgebruiker is daar deels verantwoordelijk voor. Uiteraard zijn saas-aanbieders zelf ook voor een deel verantwoordelijk voor de data van hun gebruikers. Zo moeten zij zorgen voor de uptime van toepassingen, de beschikbaarheid van data, de basisopslag en de beveiliging op infrastructuurniveau. Omdat er na jaren nog altijd onduidelijkheid bestaat over wie nu precies waar verantwoordelijk voor is, ontwikkelde Amazon het ‘shared responsibility model’: een (visueel) model waarin in één oogopslag duidelijk is hoe de gedeelde verantwoordelijkheid is geregeld en wie nu precies verantwoordelijk is voor welk aspect van de gegevensbescherming.

En die duidelijkheid is nodig nu steeds vaker gekozen wordt voor saas en de cloud. Het recente onderzoek laat zien dat msp’s hun klanten in rap tempo migreren naar de cloud, voornamelijk naar Microsoft365-applicaties. De cloudmigratie bleek een belangrijke (zakelijke) focus voor 2020 en de Covid-19 -andemie heeft de vraag naar saas-applicaties flink doen toenemen. Zo gebruiken momenteel 60 procent van de msp-klanten saas-oplossingen.

Het model

 

Het shared responsibilty model (srm) werd door Amazon in het leven geroepen nadat de onwetendheid en onduidelijkheid over de gedeelde verantwoordelijkheid maar bleef toenemen. In het model wordt afgebakend dat de saas-partij verantwoordelijk is voor de it-infrastructuur en dienstverlening, maar dat het daar ook bij blijft. De verdere privacy, backup en beveiliging ligt bij de eindgebruiker.

Volgens het model zijn saas-aanbieders verplicht de data te beschermen tegen serviceonderbrekingen door hardwareDe verzameling aan apparatuur waarop software is ge�nstalleerd om automatiseringsdiensten aan gebruikers te kunnen bieden- of softwarefouten en verlies van een dienst of bereikbaarheid door een natuurramp of stroomstoring. De eindgebruiker moet gegevens beschermen tegen het per ongeluk verwijderen van data of bestanden, hackers, ransomware-aanvallen en andere malware en kwaadwillende insiders.

Een groot voordeel van het model is dat het visueel is opgezet. In principe vertelt het model namelijk niks nieuws. Het is nu alleen niet meer verwerkt in ellenlange contracten (die vaak niet volledig worden doorgelezen), maar in een visueel ontwerp. Het maakt het meteen begrijpelijker voor zowel cloudaanbieders als de eindklant en eventuele tussenliggende partijen. De afbakening is ineens ontzettend duidelijk en behapbaar voor alle betrokkenen.

Derde partij in het model

In het model ontbreekt echter nog de msp. Steeds vaker zien we dat organisaties – voornamelijk mkb – een msp opzoeken als partner in gegevensbescherming en -opslag. Daarmee wordt de msp een derde partij in het shared responsibility model, met eigen verantwoordelijkheden en verplichtingen. Als tussenpersoon tussen saas-provider en eindklant heeft de msp immers de kennis van deze gedeelde verantwoordelijkheid en is het zijn taak om klanten hierover te informeren. Het communiceren over de noodzaak van een saas-backup om het risico voor de organisatie te verminderen is daarbij essentieel, zo wordt altijd gesteld.

Toch gaat de betrokkenheid van een msp eigenlijk verder dan het enkel ‘informeren’ van zijn klant. We kunnen bijna stellen dat er een shared responsibility model 2.0 moet komen met niet twee, maar drie partijen. Een model waarin de msp een vaste plek krijgt en actief bijdraagt aan de gedeelde verantwoordelijkheid. Daarbij zou het de taak van de msp moeten zijn om bewustzijn te creëren over de aanwezigheid en regels van de verantwoordelijkheid, maar vooral ook over de risico’s. Zoals het model nu is ingericht kan een eindklant ervoor kiezen om zijn eigen verantwoordelijkheid niet te nemen en daarbij te kiezen voor een mindere beveiliging. Echter ligt dat niet zo simpel; aan de msp is het de taak om te zorgen voor het juiste bewustzijn over de risico’s. Een klant mag namelijk nooit zomaar ‘nee’ tegen beveiliging zeggen, zónder dat dat bewustzijn aanwezig is. De msp heeft daarin nog altijd de verplichting om vanuit de dienstverlening de security goed in te richten, of de klant dat nu wil of niet.

Dat msp’s die verantwoordelijkheid moeten nemen bleek deze zomer uit een rechtszaak tussen een msp en eindklant over de schade geleden bij een ransomware-aanval. De eindklant stelde geen backup nodig te hebben, en dus was die er ook niet. Toch stelde de rechtbank dat de msp in dit geval in gebreke was gebleven en dus aansprakelijk was voor de schade: de msp had immers nooit zomaar een ‘nee, geen backup’ van de klant mogen accepteren zonder de risico’s hiervan duidelijk te benadrukken.

Ondanks dat het shared responsibility model al langere tijd bestaat, blijft het belangrijk om hiernaar terug te blijven grijpen. Het is een essentieel onderdeel van de industrie en van security. Er heerst immers (zowel bij de eindklant als msp) nog vaak onduidelijkheid en onwetendheid. Aan de industrie de taak om de kennis hiervan op peil te brengen en te houden en de andere partners te onderwijzen. En dan is een shared responsibility model 2.0 geen gekke gedachte.

Bron: channelweb.nl

  • Nederland ICT