Het model van gedeelde verantwoordelijkheid in de cloud is een van de belangrijkste concepten op het gebied van cloudbeveiliging, en tegelijkertijd een van de concepten die het vaakst verkeerd worden begrepen. Dit misverstand volgt een specifiek patroon: organisaties gaan ervan uit dat de overstap naar de cloud meer beveiligingsverantwoordelijkheid bij de provider legt dan in werkelijkheid het geval is. Deze aanname leidt tot beveiligingslacunes waar aanvallers actief misbruik van maken.
Gartner schat dat tot en met 2026 99% van de beveiligingsincidenten in de cloud te wijten zal zijn aan de klant, voornamelijk als gevolg van verkeerde configuraties. Dat cijfer is geen kritiek op de beveiliging van de cloud. Het geeft aan waar de grens van de verantwoordelijkheid ligt. De infrastructuur van de cloudprovider is over het algemeen goed beveiligd. De verkeerde configuraties, de blootgestelde opslagbuckets, de IAM-rollen met te ruime rechten en de niet-gepatchte VM's vallen bijna allemaal aan de kant van de klant.
In deze gids wordt duidelijk uitgelegd waarvoor cloudproviders verantwoordelijk zijn, waarvoor klanten en hun MSP’s verantwoordelijk zijn, en hoe de grenzen verschillen tussen de verschillende clouddienstmodellen. Het platform van Kaseya dekt de klantzijde van het model voor gedeelde verantwoordelijkheid voor meer dan 50.000 MSP’s en IT-teams wereldwijd.
Het kernprincipe
Alle grote cloudproviders – AWS, Microsoft Azure en Google Cloud – publiceren een model voor gedeelde verantwoordelijkheid waarin de taakverdeling op het gebied van beveiliging is vastgelegd. Het principe is bij alle providers hetzelfde: de provider zorgt voor de beveiliging van de cloud; de klant zorgt voor de beveiliging van wat zich in de cloud bevindt.
De verantwoordelijkheden van de provider omvatten de fysieke infrastructuur (datacenters, servers, netwerkhardware), de hypervisorlaag, de netwerkstructuur en de beschikbaarheid en betrouwbaarheid van de managed services aanbieden. Alles wat een klant binnen de cloudomgeving implementeert – besturingssystemen, applicaties, gegevens, identiteitsconfiguratie en netwerktoegangscontroles – valt onder de verantwoordelijkheid van de klant of diens MSP.
De praktische consequentie: een cloudomgeving is niet standaard beveiligd. De beveiliging hangt volledig af van de mate waarin de klant deze correct configureert. Een EC2-instance met een besturingssysteem waarvoor geen patches zijn geïnstalleerd, is het probleem van de klant. Een S3-bucket waarvoor openbare toegang is ingeschakeld, is het probleem van de klant. Een IAM-rol met beheerdersrechten die is gekoppeld aan een dienst waarvoor alleen-lezen-toegang nodig is, is het probleem van de klant. De cloudprovider zal deze problemen niet opsporen of verhelpen.
Hoe de verantwoordelijkheid verschilt per dienstverleningsmodel
De precieze afbakening verschilt naargelang het gebruikte clouddienstmodel. Hoe hoger in de stack de dienst zich bevindt, hoe meer de aanbieder op zich neemt en hoe minder de klant op infrastructuurniveau hoeft te beheren. Maar gegevens, identiteit en toegangscontrole blijven in elk model de verantwoordelijkheid van de klant.
Infrastructuur als een dienst (IaaS)
De provider beheert de fysieke infrastructuur en de virtualisatielaag. De klant beheert alles daarboven: het besturingssysteem, de middleware, de runtime, de applicaties, de gegevens en de netwerkconfiguratie. Dit is het model voor in de cloud gehoste virtuele machines, zoals AWS EC2, Azure VM’s en Google Compute Engine.
Bij IaaS rust de grootste verantwoordelijkheid bij de klant van alle servicemodellen. Een MSP die de IaaS-omgeving van een klant beheert, is volledig verantwoordelijk voor de beveiligingsstack boven de hypervisor. Dit omvat het patchen van besturingssystemen en applicaties, het instellen van firewallregels en beveiligingsgroepen, versleuteling van gegevens in rust en tijdens verzending, IAM-configuratie en logboekregistratie. Dit wordt allemaal niet door de provider afgehandeld.
Platform as a Service (PaaS)
De provider beheert ook het besturingssysteem, de middleware en de runtime. De klant is verantwoordelijk voor de applicaties en gegevens. Beheerde databaseservices, zoals Azure SQL Database, AWS RDS en applicatiehostingplatforms, werken volgens dit model.
PaaS vermindert de beheerslast aanzienlijk. Klanten hoeven geen patches toe te passen op het onderliggende besturingssysteem en hoeven de database-engine niet te beheren. Zij blijven wel verantwoordelijk voor de gegevensbeveiliging, de toegangscontrole, de configuratie op applicatieniveau en de beveiliging van de applicatiecode.
Software as a Service (SaaS)
De provider beheert de volledige stack, van de infrastructuur tot en met de applicatie. De klant is verantwoordelijk voor de gegevens, het toegangsbeheer en de configuratie van de beveiligingsmaatregelen van de applicatie.
Microsoft 365, Google Workspace en Salesforce zijn allemaal SaaS-oplossingen. De meest voorkomende misvatting hier is dat klanten ervan uitgaan dat de aanbieder, omdat deze de applicatie beheert, ook de gegevens beveiligt. Dat is echter niet het geval. Microsoft is verantwoordelijk voor de beschikbaarheid en betrouwbaarheid van het Microsoft 365-platform. De gegevens binnen elke tenant, en de mogelijkheid om deze te herstellen, vallen onder de verantwoordelijkheid van de klant.
Een organisatie die Microsoft 365-gegevens kwijtraakt door een onbedoelde massale verwijdering, een kwaadwillende beheerder of ransomware die gesynchroniseerde OneDrive-bestanden versleutelt, kan niet vertrouwen op de bewaartools van Microsoft om deze gegevens te herstellen. Deze tools zijn gericht op naleving van regelgeving, hebben korte bewaartermijnen en zijn niet ontworpen voor operationeel herstel op een specifiek tijdstip.
De meest voorkomende tekortkomingen op het gebied van gedeelde verantwoordelijkheid
Het principe begrijpen is één ding. De hiaten die in de praktijk optreden, zijn specifiek en voorspelbaar. Deze vijf komen voor in vrijwel elke cloudomgeving die niet formeel is beoordeeld.
SaaS-back-up. Het meest voorkomende misverstand bij alle servicemodellen. Microsoft en Google maken geen back-ups van Microsoft 365- of Google Workspace-gegevens op een manier die operationeel herstel mogelijk maakt na onbedoelde verwijdering, ransomware of een inbreuk op het account. Datto SaaS Protection hiervoor SaaS Protection directe SaaS Protection door driemaal per dag een back-up te maken van Microsoft 365- en Google Workspace-gegevens naar een onafhankelijke, onveranderlijke Datto Cloud-opslagplaats met onbeperkte bewaartermijn en gedetailleerd herstel.
IAM-configuratie. Identiteits- en toegangsbeheer – dat wil zeggen: wie welke rechten heeft in cloudomgevingen – blijft altijd de verantwoordelijkheid van de klant, ongeacht het servicemodel. Een verkeerde IAM-configuratie is de belangrijkste oorzaak van datalekken in de cloud. Een kleine MSP die de AWS-omgeving van een nieuwe klant onder zijn hoede neemt, zal doorgaans IAM-rollen aantreffen waarvan de rechten veel verder reiken dan de diensten waarop ze betrekking hebben. Het verhelpen hiervan is saai en tijdrovend werk dat in vrijwel elke omgeving nodig is.
Het installeren van patches voor besturingssystemen en applicaties bij IaaS-workloads. Cloud-VM’s installeren zelf geen patches. Een AWS EC2-instance of Azure-VM met een besturingssysteem waarop geen patches zijn geïnstalleerd, is net zo kwetsbaar als een on-premises server in dezelfde toestand. VSA en Datto RMM breiden geautomatiseerd patchbeheer uit naar in de cloud gehoste eindpunten, waarbij gebruik wordt gemaakt van dezelfde agentgebaseerde implementatie en beleidsgestuurde automatisering als voor on-premises servers.
Configuratie van netwerkbeveiliging. Beveiligingsgroepen, lijst met netwerktoegangscontroles en de configuratie van VPC’s/VNet’s vallen in IaaS-omgevingen onder de verantwoordelijkheid van de klant. Bij beoordelingen van cloudomgevingen worden steevast beveiligingsgroepen aangetroffen die onbeperkte inkomende toegang op poort 22 of 3389 toestaan; deze zijn er altijd omdat ze voor probleemoplossing open zijn gezet en nooit zijn gesloten. Dit zijn eenvoudige problemen die met hoge prioriteit moeten worden aangepakt.
Logboekregistratie en monitoring. Cloudproviders stellen auditlogboeken ter beschikking, zoals AWS CloudTrail, Azure Monitor Activity Logs en Google Cloud Audit Logs, maar het is de verantwoordelijkheid van de klant om de logboekregistratie in te schakelen, de gegevens correct op te slaan en te controleren op beveiligingsincidenten. Een cloudomgeving waarin geen logboekregistratie is ingeschakeld, vormt een doodlopende weg bij het onderzoeken van incidenten. Kaseya SIEM verwerkt logboeken van cloudplatforms samen met telemetriegegevens van eindpunten en e-mail, waardoor beveiligingsincidenten van verschillende providers worden gestandaardiseerd binnen één detectielaag.
Wat dit betekent voor het ontwerp van MSP-diensten
Het model van gedeelde verantwoordelijkheid is niet alleen een beveiligingsconcept. Het is een raamwerk voor dienstontwerp. MSP’s die hun dienstenaanbod expliciet afstemmen op de verantwoordelijkheidscategorieën die zij bestrijken, kunnen hun toegevoegde waarde nauwkeurig aan klanten uitleggen. MSP’s die het model niet begrijpen, lopen het risico op ongedocumenteerde hiaten in hun dekking en op lastige gesprekken wanneer een incident deze hiaten aan het licht brengt.
Een praktische checklist voor de implementatie van elke nieuwe cloudomgeving voor klanten, opgesteld volgens het model van gedeelde verantwoordelijkheid:
Voor IaaS-workloads:
- Installeer de VSA- of Datto RMM-agent op alle cloud-VM’s en neem deze op in bestaande beleidsregels voor patchbeheer
- IAM-rollen en serviceaccounts controleren; buitensporige machtigingen vastleggen en corrigeren
- Controleer de configuraties van beveiligingsgroepen en netwerk-ACL’s; sluit alle onbeperkte toegang tot beheerpoorten af
- Controleer of auditlogging in alle regio’s is ingeschakeld en of de logbestanden worden doorgestuurd naar een onafhankelijke, bewaakte bestemming
- Controleer of de back-up onafhankelijk van het cloudaccount is geconfigureerd en test het herstelproces
Voor SaaS-omgevingen:
- Implementeer Datto SaaS Protection Microsoft 365 en Google Workspace
- Controleer de rechten van beheerdersaccounts en pas tweefactorauthenticatie (MFA) toe op alle accounts met beheerdersrechten via Kaseya 365
- Leg vast welke gegevens op welk SaaS-platform staan en wat voor elk daarvan de herstelprocedure is
Voor alle cloudomgevingen:
- Geef aan en leg vast welke verantwoordelijkheden de MSP in de serviceovereenkomst op zich neemt
- Controleer welke nalevingsvereisten (HIPAA, PCI DSS, CMMC, CCPA) van toepassing zijn op gegevens die in de cloud worden gehost en koppel deze aan de bestaande beheersmaatregelen
- Voeg de architectuur van de cloudomgeving en de IAM-structuur toe aan IT Glue de klant
De documentatiestap is niet alleen van belang vanuit operationeel oogpunt. Wanneer een klant te maken krijgt met een claim op zijn cyberverzekering of een nalevingscontrole, is het vaak het vermogen van de MSP om aan te tonen welke beveiligingsmaatregelen er op welk moment van kracht waren, dat de uitkomst bepaalt.
Hoe Kaseya 365 de klantzijde Kaseya 365
Het Kaseya 365 biedt tools die inspelen op alle aspecten van de verantwoordelijkheden van de klant op het gebied van IaaS, PaaS en SaaS.
VSA en Datto RMM automatiseren het beheer van patches voor besturingssystemen en applicaties voor zowel in de cloud gehoste VM’s als lokale eindpunten, waardoor het patchen van IaaS-omgevingen vanuit één enkele console wordt geregeld.
Datto SaaS Protection neemt de verantwoordelijkheid voor de gegevensbescherming van SaaS-diensten zoals Microsoft 365 en Google Workspace op zich, met driemaal daagse back-ups, onbeperkte bewaartermijnen en onafhankelijke, onveranderlijke opslag.
Kaseya 365 zorgt voor het identiteits- en toegangsbeheer binnen Microsoft 365 en gekoppelde cloudomgevingen, inclusief het afdwingen van MFA en het monitoren Dark Web ID .
Kaseya SIEM neemt de verantwoordelijkheid voor logboekregistratie en monitoring op zich en integreert auditlogs van cloudplatforms, samen met telemetriegegevens van eindpunten en e-mail, in één geïntegreerde beveiligingsdetectielaag.
IT Glue zorgt voor de documentatieverantwoordelijkheid, het opslaan van de architectuur van de cloudomgeving, de IAM-structuur en herstelrunbooks met isolatie per klant en gecontroleerde toegang.
Kaseya Intelligence past geautomatiseerde patroonherkenning en respons toe in beheerde cloudomgevingen, waarbij configuratieafwijkingen aan de klantzijde van de gedeelde verantwoordelijkheidsgrens worden gedetecteerd en corrigerende maatregelen worden uitgevoerd zonder te wachten op handmatige controle.
