De Cloud Security Baseline: 10 kritieke auditpunten voor AWS, Azure en GCP

Een ijzersterke Cloud Security Baseline is de onbetwiste basis voor elke organisatie die compliant en veerkrachtig wil opereren binnen multi-cloud infrastructuren zoals AWS, Azure en GCP.

De snelle adoptie van Cloud Computing (via platforms als AWS, Microsoft Azure en Google Cloud Platform) heeft de manier waarop organisaties IT leveren fundamenteel veranderd. Deze transformatie is echter niet zonder gevolgen gebleven voor de klassieke discipline van de IT-Audit. Waar auditors zich voorheen konden concentreren op fysieke datacenters en on-premise servers, verschuift hun focus echter nu naar het controleren van digitale configuraties, toegangsrechten en geautomatiseerde beleidsregels.

De traditionele, periodieke audit volstaat niet meer in een omgeving waar we nieuwe services met een paar muisklikken uitrollen en configuraties bovendien real-time veranderen. De Cloud vereist daarom een verschuiving van incidentele controle naar continue monitoring en auditing.

Het doel van dit artikel is om de IT-professional en -auditor te voorzien van een concrete, actiegerichte leidraad voor het controleren van de fundamentele beveiliging van een cloud-omgeving, namelijk: de Cloud Security Baseline.

Waarom een Cloud Security Baseline cruciaal is

Een Cloud Security Baseline is de verzameling van minimale, verplichte beveiligingscontroles en configuraties die als geheel in de cloud-omgeving van een organisatie die we moeten afdwingen. Dit is dus het fundament van de Cloud Governance en dient om de meest voorkomende en ernstige risico’s te mitigeren.

• Bescherming tegen Standaardfouten: De meeste datalekken in de cloud zijn het gevolg van menselijke configuratiefouten, dus niet van exploits in de cloud-infrastructuur zelf (denk aan publiekelijk toegankelijke S3 buckets of zwakke Identity and Access Management (IAM) beleidsregels).
• Compliancy Grondslag: Organisaties moeten voldoen aan regelgeving (zoals AVG/GDPR, ISO 27001 of NEN 7510). De baseline vormt tevens de eerste en meest directe bewijslast dat een omgeving aan de beveiligingseisen voldoet.
• Schaalbaarheid van Audit: Door te controleren op een gestandaardiseerde baseline, kan men de audit op een efficiënte en geautomatiseerde manier uitvoeren, wat ook de snelheid van de audit ten goede komt.

De Nieuwe Regel: Het Shared Responsibility Model

Voordat we duiken in de auditpunten, is het cruciaal om het Shared Responsibility Model te begrijpen. Dit model definieert de expliciete scheiding tussen de beveiligingsverantwoordelijkheden van de Cloud Service Provider (CSP) en die van de Klant.

Verantwoordelijkheid	Cloud Service Provider (CSP)	Klant (Gebruiker)
Beveiliging van de Cloud	Fysieke beveiliging van datacenters, netwerkinfrastructuur, hypervisors.	N.V.T.
Beveiliging in de Cloud	N.V.T.	Gegevens, IAM, Besturingssysteem, Netwerkconfiguratie (Firewalls, Security Groups), Applicaties.

De cruciale auditverschuiving: De CSP (AWS/Azure) garandeert namelijk dat de Cloud zelf veilig is. De auditor moet zich daarom volledig richten op de klantverantwoordelijkheid: de beveiliging in de Cloud. Dit betekent dat de focus ligt op de configuratie van diensten zoals Identity and Access Management (IAM), virtuele netwerken en de data-opslag.

De tien kritieke auditpunten die we in de volgende sectie behandelen, richten zich uitsluitend op deze klantverantwoordelijkheden en bieden de handvatten om de Cloud Security Baseline effectief te controleren in zowel AWS als Azure omgevingen.

Het Shared Responsibility Model in Detail: Wie Controleert Wat?

Het begrijpen van het Shared Responsibility Model (SRM) is niet zomaar een theoretische oefening; het is namelijk de startvoorwaarde voor elke geldige Cloud Audit. Zonder een helder beeld van de scheidslijn tussen de verantwoordelijkheden van de Cloud Service Provider (CSP) en de klant, loopt de auditor eveneens het risico de verkeerde zaken te controleren of kritieke risico’s over het hoofd te zien.

De fundamentele deling

Het model is te vereenvoudigen tot de volgende mantra:

De Cloud Service Provider (CSP) is verantwoordelijk voor de Beveiliging ván de Cloud. De Klant is echter verantwoordelijk voor de Beveiliging ín de Cloud.

Dit betekent dat de CSP (zoals Amazon Web Services, Microsoft Azure of Google Cloud) de verantwoordelijkheid draagt voor de fysieke beveiliging van de datacenters, de onderliggende infrastructuur (hardware, netwerken) en de hypervisors die de scheiding tussen virtuele machines garanderen. Dit dekt de CSP af met certificeringen zoals ISO 27001 en SOC 2.

De Klantverantwoordelijkheid: Het Audit-Focusgebied

Alle risico’s en controls in onze Cloud Security Baseline Checklist vallen dus onder de klantverantwoordelijkheid. De klant beslist hoe de services worden geconfigureerd en gebruikt, en daarmee waar de gevoelige data zich bevindt en wie er toegang toe heeft.

Deze verantwoordelijkheid van de klant neemt toe naarmate men minder abstracte services gebruikt:

Service Model	Klantverantwoordelijkheid	Voorbeelden
IaaS (Infrastructure as a Service)	Maximaal. Dus inclusief Besturingssysteem, Middleware, Applicaties en Data.	Virtuele Machines (VM’s), Ongeconfigureerde Storage.
PaaS (Platform as a Service)	Gemiddeld. Focus op Applicatieconfiguratie, Identity en Data. CSP beheert het OS.	Azure SQL Database, AWS Lambda, PaaS App Services.
SaaS (Software as a Service)	Minimaal. Focus op Toegangsbeheer (IAM) en Data Classification.	Microsoft 365, Salesforce.

De configuratie als nieuw auditdomein

De traditionele IT-auditor controleerde vaak of systemen ‘gepatched’ waren of in een fysiek afgesloten ruimte stonden. Maar in de cloud is dit vervangen door het controleren van Configuration as Code (CaC) of de configuratie van Identity and Access Management (IAM).

Twee aspecten zijn hierbij cruciaal voor de auditor:

1. Identity and Access Management (IAM) is de nieuwe Perimeter: Omdat de klassieke netwerkperimeter vervaagt (data is overal), wordt IAM de primaire control. De audit moet zich daarvoor richten op het minst noodzakelijke privilege-principe (Least Privilege). Is Multi-Factor Authenticatie (MFA) bijvoorbeeld verplicht? Hebben service-accounts alleen toegang tot de diensten die ze écht nodig hebben?
2. Standaardinstellingen zijn Risico’s: De default instellingen van veel cloud-diensten zijn dus ontworpen voor gebruiksgemak, niet voor maximale beveiliging. Een S3-bucket in AWS of een Blob Storage in Azure is standaard vaak niet versleuteld en kan, indien verkeerd geconfigureerd, publiekelijk toegankelijk zijn. De Cloud Security Baseline dwingt echter af dat we deze standaardinstellingen direct aanscherpen.

De 10 Kritieke Auditpunten in de volgende sectie zijn de directe vertaling van deze klantverantwoordelijkheid. Ze bieden de auditor daardoor de focus om de belangrijkste configuratiezwakheden in te identificeren.

We introduceren nu de tien meest kritieke beveiligingscontroles. Dit zijn de punten waarop IT-auditors en beveiligingsteams zich als eerste moeten focussen om 80% van de cloud-risico’s af te dekken.

De top 10 kritieke Cloud Security Baseline Controls

De Cloud Security Baseline is het directe antwoord op het Shared Responsibility Model. Deze baseline moeten we echter afdwingen met de meest effectieve controls om configuratiefouten en ongewenste toegang te voorkomen.

Op basis van best practices van het CIS (Center for Internet Security) en ervaringen met grote cloud-migraties, kunnen we de 10 kritieke controls onderscheiden. Ze zijn thematisch te verdelen over vier cruciale domeinen van de klantomgeving in zowel AWS als Azure: Identiteit, Data, Netwerk en Monitoring.

Deze tien punten vormen dus de kern van de audit en moeten we continu monitoren.

Nr.	Domein	Kritieke Cloud Security Control	Kernfunctie
1	Identiteit (IAM)	Verplichte Multi-Factor Authenticatie (MFA)	Voorkomt overname van beheerdersaccounts (Root/Global Admin).
2	Identiteit (IAM)	Principe van Least Privilege	Minimaliseert de schade bij een gecompromitteerd account.
3	Data	Encryptie van Data-at-Rest (opslag)	Garandeert dat data op schijf onleesbaar is (bv. S3, Blob Storage).
4	Data	Blokkeren van Publieke Toegang (Storage)	Voorkomt dat storage buckets/containers onbedoeld publiek worden.
5	Netwerk	Audit van Standaard Netwerkconfiguratie	Controleert op ongeautoriseerde ‘alle poorten open’-regels.
6	Netwerk	Micro-segmentatie via Security Groups/NSG’s	Garandeert strikte, service-tot-service communicatie.
7	Monitoring	Uniforme Logging van Cloud API-activiteit	Legt elke actie van elke gebruiker/service account vast (CloudTrail/Activity Log).
8	Monitoring	Alerting op Kritieke Beveiligingsincidenten	Waarschuwt direct bij ongebruikelijke beheeractiviteiten (bijv. root login).
9	Configuratie	Geautomatiseerd Secrets Management	Voorkomt het gebruik van hard-coded wachtwoorden in code of configuraties.
10	Configuratie	Cloud Security Posture Management (CSPM)	Dwingt naleving van de Baseline continu af middels geautomatiseerde tools.

De gedetailleerde Audit checklist: van Control naar Controleerbaar bewijs

De volgende tien punten vormen de operationele checklist voor de IT-auditor. Voor elk kritiek controlepunt wordt aangegeven wat het risico is, hoe de controle technisch wordt geïmplementeerd in AWS, Azure, GCP, en welke bewijsstukken de auditor moet verzamelen.

Cloud Security Baseline domein: Identiteit en Toegangsbeheer (IAM)

1. Verplichte Multi-Factor Authenticatie (MFA)

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	Zorgt ervoor dat geen enkel bevoorrecht account (Root, Administrator) kan inloggen met alleen een wachtwoord. MFA verkleint namelijk de kans op accountovername (credential compromise) aanzienlijk.
Audit Vraag	Is MFA verplicht en afgedwongen voor alle beheeraccounts (root, Global Administrators, Security Admins) en voor gebruikers met verhoogde rechten (bijv. degenen die virtuele machines kunnen starten)?
Vereist Bewijs	IAM-beleid dat MFA afdwingt; rapport dat MFA-status van root account en beheerrollen toont.	Conditional Access Policy (CAP) die MFA vereist voor beheerdersrollen; rapport van Azure AD Security Score.	Identity-Aware Proxy (IAP) en Organization Policy Service afdwingen MFA. Controleer Cloud Identity/Workspace beleid voor Super Admins.

2. Principe van Least Privilege

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	Gebruikers en service-accounts mogen alleen de rechten krijgen die strikt noodzakelijk zijn voor hun taak. Vermijd daarom het gebruik van ‘star permissions’ (*) en de brede, ingebouwde rollen.
Audit Vraag	Worden aangepaste (custom) rollen gebruikt in plaats van ingebouwde beheerdersrollen? Wordt periodiek (minimaal driemaandelijks) gecontroleerd op ongebruikte of overbodige rechten?
Vereist Bewijs	Review van de IAM Policies met focus op de Action en Resource elementen; rapport van IAM Access Analyzer of vergelijkbare tool.	Review van Custom Azure Roles en de Role Assignments; output van Azure AD Identity Governance voor access reviews.	Review van Custom IAM Roles en Role Bindings. Gebruik van Policy Intelligence en Recommender om overbodige rechten te minimaliseren.

Cloud Security Baseline domein: Data Protectie

3. Encryptie van Data-at-Rest (Opslag)

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	Alle gevoelige en niet-vluchtige data die in de cloud wordt opgeslagen, moet versleuteld zijn om te voorkomen dat ze bij fysieke diefstal of ongeautoriseerde toegang leesbaar zijn.
Audit Vraag	Zijn alle S3 Buckets, RDS Databases, EBS volumes en de standaard storage accounts voorzien van ‘default encryption’? Wordt eventueel gebruikgemaakt van een Customer Managed Key (CMK) via KMS?
Vereist Bewijs	Output van AWS Config Rule of Azure Policy die ‘Encryption by Default’ afdwingt voor alle opslagdiensten; auditlog van het Key Management System (KMS/Key Vault).	Azure Policy geconfigureerd om ‘Encryption by Default’ af te dwingen voor Storage Accounts, Azure SQL Database en Cosmos DB. Controleer op gebruik van Azure Key Vault (CMK).	Cloud Storage en Cloud SQL geconfigureerd voor Default Encryption (KMS of Cloud Storage-Managed). Controleer op gebruik van Cloud KMS voor Customer-Managed Encryption Keys (CMEK).

4. Blokkeren van Publieke Toegang (Storage)

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	De meest voorkomende datalekken zijn het gevolg van per ongeluk publiek gemaakte opslag. De standaardinstelling voor alle storage moet dus zijn dat deze privé is.
Audit Vraag	Is de S3 Block Public Access-functie ingeschakeld op Account Level? Zijn er geen Azure Blob Containers ingesteld op ‘anonieme leestoegang’?
Vereist Bewijs	Screenshot/rapportage dat de Account-level Block Public Access-instelling toont; output van Azure Security Center/Defender for Cloud over openbare opslag.	Instelling ‘Allow Blob public access’ op Disabled op Storage Account-niveau. Output van Azure Defender for Cloud over openbare opslag. Controleer op Azure Private Endpoints.	Gebruik van Uniform Bucket-Level Access op Cloud Storage Buckets. Controleer op VPC Service Controls (VPC-SC) om datalekken te voorkomen.

Cloud Security Baseline domein: Netwerkbeveiliging

5. Audit van Standaard Netwerkconfiguratie

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	Voorkom dat er ‘any-any’ of ‘0.0.0.0/0’ regels worden gebruikt voor onnodige netwerkpoorten (vooral poort 22, 3389 voor beheer).
Audit Vraag	Worden de Default Security Groups (AWS) of de standaard Network Security Groups (NSG’s) (Azure) actief gebruikt? Zo ja, zijn deze beperkt tot het Least Privilege-principe?
Vereist Bewijs	Rapport van alle Security Groups die in de VPC’s worden gebruikt. Controle op ‘0.0.0.0/0’ regels voor beheerpoorten (22/3389).	Review van de Inbound Security Rules van de relevante Network Security Groups (NSG’s). Controle op ‘0.0.0.0/0’ voor RDP/SSH. Controle op gebruik van Azure Bastion.	Review van VPC Firewall Rules op het netwerk- en subnet-niveau. Controle op ‘0.0.0.0/0’ voor poorten 22/3389. Gebruik van Identity-Aware Proxy (IAP) voor tunneltoegang.

6. Micro-segmentatie via Security Groups/NSG’s

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	Netwerkverkeer tussen applicatielagen (bijv. webserver naar databaseserver) moet expliciet beperkt zijn op basis van het principe van zero trust binnen de virtuele netwerken.
Audit Vraag	Zijn er Network Access Control Lists (NACLs) Rules geconfigureerd om verkeer tussen Development, Test en Productie omgevingen te blokkeren?	Zijn er Firewall Rules geconfigureerd om verkeer tussen Development, Test en Productie omgevingen te blokkeren?
Vereist Bewijs	Review van Network Access Control Lists (NACLs) en Security Groups tussen subnetten/omgevingen.	Gebruik van Application Security Groups (ASG’s) of Azure Firewall voor verkeerssegmentatie. Review van NSG-regels op zowel subnet- als NIC-niveau.	Gebruik van VPC Firewall Rules met Network Tags om verkeer te segmenteren. Implementatie van Cloud Armor voor Layer 7-beveiliging.

Cloud Security Baseline domein: Monitoring, Logging en Configuratie

7. Uniforme Logging van Cloud API-activiteit

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	Elke actie die een gebruiker of service-account uitvoert (bijv. een server starten, een recht wijzigen) moet centraal worden gelogd, opgeslagen en beveiligd tegen wijziging.
Audit Vraag	Is AWS CloudTrail geactiveerd en geconfigureerd om logs over alle regio’s af te vangen?	Is de Azure Activity Log geëxporteerd en wordt deze bewaard in een beveiligde, onveranderbare (immutable) opslag?
Vereist Bewijs	Configuratie van AWS CloudTrail (alle regio’s) naar een beveiligde, onveranderbare (immutable) S3 bucket.	Configuratie van Diagnostic Settings (op abonnementsniveau) om de Azure Activity Log naar een Log Analytics Workspace of Immutable Storage te exporteren.	Configuratie van Cloud Audit Logs en Cloud Logging (Logs Router) om alle beheerdersactiviteit centraal naar een beveiligde Cloud Storage Bucket te exporteren (met retentie en immutability).

8. Alerting op Kritieke Beveiligingsincidenten

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	Zelfs met goede controls, moet een organisatie direct gewaarschuwd worden bij ‘red flag’-activiteit, zoals het inloggen van het root-account of het wijzigen van beveiligingsbeleid.
Audit Vraag	Zijn er real-time waarschuwingen ingesteld voor: 1) Het deactiveren van loggen (CloudTrail/Activity Log)? 2) Pogingen tot brute force? 3) Wijzigingen in de IAM/Conditional Access Policies?
Vereist Bewijs	Overzicht van actieve waarschuwingsregels in Amazon CloudWatch of Security Hub voor ‘red flag’-activiteit (bijv. root login).	Overzicht van actieve Alert Rules in Azure Monitor of de Analytic Rules in Azure Sentinel voor kritieke beveiligingswijzigingen.	Overzicht van Cloud Monitoring Alerting Policies ingesteld op logmetrieken uit Cloud Audit Logs (bijv. deactivering van logging, toewijzing van Admin-rollen).

9. Geautomatiseerd Secrets Management

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control Uitleg	Beveiligingscodes, API-sleutels en database-wachtwoorden mogen nooit in code of configuratiebestanden hard-coded worden, maar moeten worden opgehaald uit een veilige kluis.
Audit Vraag	Wordt een Secrets Manager gebruikt voor alle gevoelige credentials in de CI/CD pipeline? Worden credentials automatisch geroteerd?
Vereist Bewijs	Auditlog van de AWS Secrets Manager; review van CI/CD code om hard-coded secrets uit te sluiten.	Configuratie van Azure Key Vault Access Policies; controle op het gebruik van Managed Identities voor Azure Resources in plaats van secrets.	Gebruik van Secret Manager voor het opslaan van API-sleutels en certificaten. Controle op het gebruik van Service Accounts en hun key-rotatiebeleid.

10. Cloud Security Posture Management (CSPM)

Aspect	AWS Implementatie	Azure Implementatie	GCP Implementatie
Control uitleg	De naleving van de Baseline moet continu en geautomatiseerd worden gecontroleerd, om te voorkomen dat de Baseline na de audit weer afzakt.
Audit vraag	Wordt een CSPM-tool (zoals AWS Security Hub, of een 3rd party tool) gebruikt om continu de naleving van de CIS Benchmarks of de interne Baseline af te dwingen?	Wordt een CSPM-tool (Azure Defender for Cloud, of een 3rd party tool) gebruikt om continu de naleving van de CIS Benchmarks of de interne Baseline af te dwingen?
Vereist bewijs	Dashboard van AWS Security Hub dat de huidige compliance score (CIS Benchmarks) toont. Bewijs van geautomatiseerde herstelacties.	Dashboard van Azure Defender for Cloud (ADC) Secure Score; configuratie van kritieke Azure Policies voor auditing en herstel (deployIfNotExists).	Dashboard van Security Command Center (SCC) dat de huidige Security Health Check en naleving van de CIS Benchmarks toont. Configuratie van Organization Policies.

De Rol van Automatisering: Cloud Security Posture Management (CSPM)

Het uitvoeren van de in Sectie 4 beschreven tien auditpunten met handmatige methoden is, gezien de snelheid en omvang van de cloud, niet schaalbaar. De virtuele infrastructuur van een organisatie kan immers elke minuut veranderen. Een handmatige audit is daarom bij oplevering van de rapportage al technisch verouderd.

De moderne IT-Auditor en Security Engineer gebruiken daarom Cloud Security Posture Management (CSPM)-oplossingen.

Wat is CSPM en Waarom is het Onmisbaar?

CSPM is een categorie van beveiligingsinstrumenten die continu de configuratie en naleving van cloud-omgevingen monitoren ten opzichte van een gedefinieerde baseline (zoals de CIS Benchmarks, ISO 27001 of, in ons geval, de 10 Kritieke Controls).

1. Continue naleving: In plaats van een momentopname (de traditionele audit), biedt CSPM een doorlopende score van de beveiligingshouding. Dit is essentieel voor DevSecOps-omgevingen.
2. Identificatie van Configuratie-Drift: CSPM detecteert onmiddellijk wanneer een engineer een configuratie wijzigt (bijvoorbeeld een S3-bucket publiek maakt) die afwijkt van de baseline.
3. Geautomatiseerde Remediatie (herstel): Veel CSPM-tools kunnen automatisch kleine beveiligingsfouten herstellen. Bijvoorbeeld: als MFA niet is ingeschakeld voor een beheerdersaccount, kan de tool dit afdwingen of de rechten intrekken totdat het is gecorrigeerd.

CSPM in AWS, Azure en GCP

Zowel AWS als Azure bieden native CSPM-functionaliteit, die direct bruikbaar is voor het controleren van onze tien baseline-punten:

• AWS Security Hub: Dit is een centrale dienst die de beveiligingsbevindingen van verschillende AWS-beveiligingsdiensten (zoals GuardDuty, Inspector en Macie) aggregeert en toetst aan de CIS Benchmarks en AWS best practices. Het biedt bovendien een Compliance Score die de auditor direct kan gebruiken.
• Azure Defender for Cloud (voorheen Azure Security Center): Dit is als de centrale hub voor de beveiligingshouding van Azure. Het biedt de Secure Score, die fungeert als een continu meetinstrument van de naleving van de gedefinieerde beveiligingsstandaarden. Het platform biedt ook Regulatory Compliance Dashboards voor AVG/GDPR en ISO 27001.
• Google Cloud Security Command Center (SCC): Dit is dus de uniforme security- en risicobeheeroplossing van Google Cloud. SCC verzamelt bevindingen van alle GCP-beveiligingsservices (zoals Cloud DLP en Web Security Scanner) en biedt een centraal overzicht van de beveiligingshouding. Het toetst de configuraties namelijk continu aan de CIS Google Cloud Computing Foundations Benchmark en is de primaire bron voor de auditor om de naleving van de Baseline te controleren.

De Implicatie voor de Audit

De aanwezigheid van een goed geconfigureerde CSPM-oplossing is zelf echter een kritiek controlepunt (punt 10 van onze checklist). Voor de auditor betekent dit namelijk dat de focus verschuift van het handmatig controleren van elke resource naar het auditen van de CSPM-tool zelf:

• Is de CSPM-tool correct ingesteld om alle omgevingen te dekken?
• Wordt de gegenereerde Secure Score serieus genomen en leiden bevindingen vervolgens tot acties?
• Worden de bevindingen die door de tool worden gemeld, correct gelogd en daarna opgelost binnen een acceptabele termijn?

Door CSPM te omarmen, transformeert de IT-audit van een arbeidsintensieve periodieke check naar een controle van het geautomatiseerde beveiligingsproces. Dit is dus de toekomst van de audit in de cloud.

Conclusie & volgende stappen: van Cloud SecurityBaseline naar blijvende beveiliging

De verschuiving naar de cloud heeft de aard van IT-audit radicaal veranderd. De focus is namelijk verschoven van de fysieke beveiliging van het datacenter naar de logische beveiliging en de configuratie van de diensten in de cloud. De kern van deze nieuwe discipline is het afdwingen van een sterke en controleerbare Cloud Security Baseline.

De noodzaak van consistentie

Zoals we hebben gezien, zijn de tien kritieke controls die we hebben uitgewerkt geen optionele verbeteringen, maar de minimale vereisten voor elke organisatie die compliant en veilig wil opereren in AWS en Azure. Het falen om deze basiscontroles (zoals MFA of de blokkering van publieke storage) af te dwingen, is inmiddels de meest voorkomende oorzaak van ernstige beveiligingsincidenten. Voor de IT-Auditor betekent dit dat de nadruk moet liggen op de actieve monitoring van deze baseline. De vragen in Sectie 4 dienen als de basis voor zowel handmatige controles als de configuratie van geautomatiseerde tools.

Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn.