Het model van gedeelde verantwoordelijkheid in de cloud: waar zijn MSP’s en klanten nu eigenlijk verantwoordelijk voor?
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 bij de overstap naar de cloud meer beveiligingsverantwoordelijkheid naar de provider wordt overgedragen dan in werkelijkheid het geval is. Deze aanname leidt tot beveiligingslekken 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 aanklacht tegen de beveiliging van de cloud. Het is een constatering over 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 bevinden zich bijna allemaal aan de kant van de klant.
In deze gids wordt duidelijk uitgelegd waarvoor cloudproviders precies verantwoordelijk zijn, waarvoor klanten en hun MSP’s verantwoordelijk zijn, en hoe de afbakening varieert tussen de verschillende clouddienstmodellen. Het platform van Kaseya dekt de klantzijde van het model van 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 hebben betrekking op de fysieke infrastructuur (datacenters, servers, netwerkhardware), de hypervisorlaag, de netwerkstructuur en de beschikbaarheid en betrouwbaarheid van de managed services die zij 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 veilig. De veiligheid hangt af van de mate waarin de klant de omgeving correct configureert. Een EC2-instance met een besturingssysteem waarvoor geen patches zijn geïnstalleerd, is het probleem van de klant. Een S3-bucket waarbij 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 geen van deze problemen 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 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.
Van alle servicemodellen draagt IaaS de grootste verantwoordelijkheid ten opzichte van de klant. Een MSP die de IaaS-omgeving van een klant beheert, is volledig verantwoordelijk voor de beveiligingsstack boven de hypervisor. Dit omvat het installeren van patches voor het besturingssysteem en applicaties, het instellen van firewallregels en beveiligingsgroepen, versleuteling van gegevens in rust en tijdens verzending, het configureren van IAM en het bijhouden van logbestanden. 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 de gegevens. Beheerde databasediensten, zoals Azure SQL Database, AWS RDS en platforms voor applicatiehosting, 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, omdat de aanbieder de applicatie beheert, ervan uitgaan dat de aanbieder 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 bulkverwijdering, 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 praktijkomgevingen aan het licht komen, 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 pakt dit probleem rechtstreeks aan 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 – wie welke rechten heeft in cloudomgevingen – valt altijd onder 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 endpointsen, waarbij gebruik wordt gemaakt van dezelfde agentgebaseerde implementatie en beleidsgestuurde automatisering als voor on-premises servers.
Configuratie van netwerkbeveiliging. Beveiligingsgroepen, netwerktoegangsbeheerlijsten 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 poorten 22 of 3389 toestaan; deze zijn er altijd omdat ze voor het oplossen van problemen open zijn gezet en vervolgens nooit meer 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 endpointsen 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 de toegevoegde waarde voor hun klanten nauwkeurig onder woorden brengen. MSP’s die het model niet begrijpen, hebben waarschijnlijk ongedocumenteerde hiaten in hun dekking en krijgen te maken met 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 een herstelprocedure
Voor SaaS-omgevingen:
- Implementeer Datto- SaaS Protection s voor Microsoft 365 en Google Workspace
- Controleer de rechten van het beheerdersaccount en pas MFA toe op alle accounts met verhoogde rechten via Kaseya 365 User
- Leg vast welke gegevens op welk SaaS-platform zijn opgeslagen en wat voor elk daarvan de herstelprocedure is
Voor alle cloudomgevingen:
- Geef aan en leg vast welke verantwoordelijkheden de MSP in de dienstverleningsovereenkomst 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 voor de klant
De documentatiestap is niet alleen van belang vanuit operationeel oogpunt. Wanneer een klant te maken krijgt met een claim op basis van een 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 behandelt
Het platform ‘ Kaseya 365 ’ biedt tools die inspelen op alle verantwoordelijkheidsniveaus van de klant binnen 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 endpointsen, waardoor het patchen van IaaS-omgevingen vanuit één enkele console wordt geregeld.
De Datto- SaaS Protection -oplossing dekt de verantwoordelijkheid voor SaaS-gegevensbescherming voor Microsoft 365 en Google Workspace, met drie back-ups per dag, onbeperkte bewaartermijn en onafhankelijke, onveranderlijke opslag.
Kaseya 365 De gebruiker is verantwoordelijk voor het identiteits- en toegangsbeheer binnen Microsoft 365 en daaraan gekoppelde cloudomgevingen, met inbegrip van het afdwingen van MFA en het monitoren van inloggegevens via Dark Web ID .
Kaseya SIEM neemt de verantwoordelijkheid voor logboekregistratie en monitoring op zich en integreert auditlogs van cloudplatforms, samen met telemetriegegevens van endpointsen en e-mail, in één geïntegreerde beveiligingsdetectielaag.
IT Glue omvat de verantwoordelijkheid voor de documentatie, het opslaan van de architectuur van de cloudomgeving, de IAM-structuur en runbooks voor herstel, met isolatie per klant en gecontroleerde toegang.
Kaseya Intelligence past geautomatiseerde patroonherkenning en reacties toe in alle beheerde cloudomgevingen, waarbij configuratieafwijkingen aan de klantzijde van de grens van gedeelde verantwoordelijkheid worden gedetecteerd en corrigerende maatregelen worden uitgevoerd zonder te wachten op handmatige controle.
