Zero Trust-principes toepassen op Azure Storage
Samenvatting: Als u Zero Trust-principes wilt toepassen op Azure Storage, moet u gegevens (at rest, in transit en in gebruik) beveiligen, gebruikers controleren en de toegang controleren, kritieke gegevens scheiden of scheiden met netwerkbesturingselementen en Defender for Storage gebruiken voor geautomatiseerde detectie en beveiliging van bedreigingen.
Dit artikel bevat stappen voor het toepassen van de principes van Zero Trust op Azure Storage:
| Zero Trust-principe | Definitie | Ontmoet door |
|---|---|---|
| Expliciet verifiëren | Altijd verifiëren en autoriseren op basis van alle beschikbare gegevenspunten. | Controleer de gebruikersreferenties en -toegang. |
| Toegang met minimale bevoegdheden gebruiken | Beperk gebruikerstoegang met Just-In-Time en Just-Enough-Access (JIT/JEA), op risico gebaseerd adaptief beleid en gegevensbeveiliging. | Toegang tot opslaggegevens beheren met minimale bevoegdheden. |
| Stel dat er sprake is van een schending | Minimaliseer straal en segmenttoegang. Controleer end-to-end-versleuteling en gebruik analyse om zichtbaarheid te krijgen, detectie van bedreigingen te stimuleren en verdediging te verbeteren. | Bescherm data-at-rest, gegevens die worden overgedragen en gegevens die in gebruik zijn. Scheid kritieke gegevens met netwerkbesturingselementen. Defender for Storage gebruiken voor geautomatiseerde detectie en beveiliging van bedreigingen. |
Dit artikel maakt deel uit van een reeks artikelen die laten zien hoe u de principes van Zero Trust toepast in een omgeving in Azure die Azure Storage-services bevat ter ondersteuning van een IaaS-workload. Zie Zero Trust-principes toepassen op de Azure-infrastructuur voor een overzicht.
Opslagarchitectuur in Azure
U past Zero Trust-principes toe voor Azure Storage in de architectuur, van tenant- en directoryniveau tot aan de opslagcontainer op de gegevenslaag.
In het volgende diagram ziet u de onderdelen van de logische architectuur.
In het diagram:
- Het opslagaccount voor de referentiearchitectuur bevindt zich in een toegewezen resourcegroep. U kunt elk opslagaccount in een andere resourcegroep isoleren voor gedetailleerdere op rollen gebaseerde toegangsbeheer (RBAC). U kunt RBAC-machtigingen toewijzen om het opslagaccount te beheren op het niveau van de resourcegroep of resourcegroep en deze controleren met logboekregistratie van Microsoft Entra-id's en hulpprogramma's zoals Privileged Identity Management (PIM). Als u meerdere toepassingen of workloads uitvoert met meerdere bijbehorende opslagaccounts in één Azure-abonnement, is het belangrijk om de RBAC-machtigingen van elk opslagaccount te beperken tot de bijbehorende eigenaren, gegevensbewaarders, controllers, enzovoort.
- Azure Storage-services voor dit diagram bevinden zich in een toegewezen opslagaccount. U kunt één opslagaccount hebben voor elk type opslagworkload.
- Zie het overzicht van Zero Trust toepassen op Azure IaaS voor een breder overzicht van de referentiearchitectuur.
Het diagram bevat geen Azure Queues en Azure Tables. Gebruik dezelfde richtlijnen in dit artikel om deze resources te beveiligen.
Wat staat er in dit artikel?
In dit artikel worden de stappen beschreven voor het toepassen van de principes van Zero Trust in de referentiearchitectuur.
| Stap | Taak | Zero Trust-principe(en) toegepast |
|---|---|---|
| 1 | Gegevens beveiligen in alle drie de modi: data-at-rest, gegevens in transit, gegevens die in gebruik zijn. | Stel dat er sprake is van een schending |
| 2 | Controleer gebruikers en beheer de toegang tot opslaggegevens met minimale bevoegdheden. | Expliciet verifiëren Toegang met minimale bevoegdheden gebruiken |
| 3 | Logisch gescheiden of gescheiden kritieke gegevens met netwerkbesturingselementen. | Stel dat er sprake is van een schending |
| 4 | Defender for Storage gebruiken voor geautomatiseerde detectie en beveiliging van bedreigingen. | Stel dat er sprake is van een schending |
Stap 1: Gegevens in alle drie de modi beveiligen: data-at-rest, gegevens in transit, gegevens die worden gebruikt
U configureert de meeste instellingen voor het beveiligen van data-at-rest, in transit en in gebruik wanneer u het opslagaccount maakt. Gebruik de volgende aanbevelingen om ervoor te zorgen dat u deze beveiligingen configureert. Overweeg ook Microsoft Defender voor Cloud in te schakelen om uw opslagaccounts automatisch te evalueren op basis van de Microsoft-cloudbeveiligingsbenchmark die een beveiligingsbasislijn voor elke Azure-service beschrijft.
Zie hier voor meer informatie over deze besturingselementen voor opslagbeveiliging.
Versleuteling tijdens overdracht gebruiken
Beveilig uw gegevens door beveiliging op transportniveau in te schakelen tussen Azure en de client. Gebruik altijd HTTPS om de communicatie via het openbare internet te beveiligen. Wanneer u de REST API's aanroept voor toegang tot objecten in opslagaccounts, kunt u het gebruik van HTTPS afdwingen door beveiligde overdracht vereist voor het opslagaccount. Elke aanvraag die afkomstig is van een onveilige verbinding, wordt geweigerd.
Deze configuratie is standaard ingeschakeld wanneer u een nieuw Azure Storage-account implementeert (standaard beveiligd).
Overweeg een beleid toe te passen om de implementatie van onveilige verbindingen voor Azure Storage (beveiligd per ontwerp) te weigeren.
Voor deze configuratie is ook SMB 3.0 met versleuteling vereist.
Anonieme openbare leestoegang voorkomen
Openbare blobtoegang is standaard verboden, maar een gebruiker met de juiste machtigingen kan een toegankelijke resource configureren. Als u wilt voorkomen dat gegevensschendingen anonieme toegang krijgen, moet u opgeven wie toegang heeft tot uw gegevens. Als u dit op het niveau van het opslagaccount verhindert, voorkomt u dat een gebruiker deze toegang inschakelt op container- of blobniveau.
Zie Anonieme openbare leestoegang tot containers en blobs voorkomen voor meer informatie.
Autorisatie van gedeelde sleutels voorkomen
Deze configuratie dwingt het opslagaccount om alle aanvragen met een gedeelde sleutel te weigeren en in plaats daarvan Microsoft Entra-autorisatie te vereisen. Microsoft Entra ID is een veiligere keuze, omdat u op risico's gebaseerde toegangsmechanismen kunt gebruiken om de toegang tot gegevenslagen te beperken. Zie Autorisatie van gedeelde sleutels voorkomen voor een Azure Storage-account voor meer informatie.
U configureert gegevensbeveiliging voor alle drie de modi van de configuratie-instellingen van een opslagaccount, zoals hier wordt weergegeven.
Deze instellingen kunnen niet worden gewijzigd nadat u het opslagaccount hebt gemaakt.
Een minimaal vereiste versie van TLS (Transport Layer Security) afdwingen
De hoogste versie die momenteel door Azure Storage wordt ondersteund, is TLS 1.2. Het afdwingen van een minimale TLS-versie weigert aanvragen van clients die oudere versies gebruiken. Zie Een minimaal vereiste versie van TLS afdwingen voor aanvragen naar een opslagaccount voor meer informatie.
Het bereik voor kopieerbewerkingen definiëren
Definieer het bereik voor kopieerbewerkingen om kopieerbewerkingen te beperken tot alleen die van bronopslagaccounts die zich binnen dezelfde Microsoft Entra-tenant bevinden of die een Private Link hebben naar hetzelfde virtuele netwerk (VNet) als het doelopslagaccount.
Het beperken van kopieerbewerkingen tot bronopslagaccounts met privé-eindpunten is de meest beperkende optie en vereist dat het bronopslagaccount privé-eindpunten heeft ingeschakeld.
U configureert een bereik voor kopieerbewerkingen vanuit de configuratie-instellingen van een opslagaccount, zoals hier wordt weergegeven.
Begrijpen hoe versleuteling at rest werkt
Alle gegevens die naar Azure Storage worden geschreven, worden automatisch versleuteld door Storage Service Encryption (SSE) met een 256-bits AES-coderingscode (Advanced Encryption Standard). Bij het schrijven naar Azure Storage worden gegevens via SSE automatisch versleuteld. Wanneer u gegevens van Azure Storage leest, worden de gegevens eerst ontsleuteld voordat ze worden geretourneerd. Voor dit proces worden geen extra kosten in rekening gebracht. Het proces heeft geen nadelige gevolgen voor de prestaties. Het gebruik van door de klant beheerde sleutels (CMK) biedt extra mogelijkheden om de rotatie van de sleutelversleutelingssleutel te beheren of gegevens cryptografisch te wissen.
U schakelt CMK in vanaf de blade Versleuteling bij het maken van een opslagaccount, zoals hier wordt weergegeven.
U kunt ook infrastructuurversleuteling inschakelen, die dubbele versleuteling biedt op service- en infrastructuurniveau. Deze instelling kan niet worden gewijzigd nadat u het opslagaccount hebt gemaakt.
Notitie
Als u een door de klant beheerde sleutel wilt gebruiken voor opslagaccountversleuteling, moet u deze inschakelen tijdens het maken van het account en moet u beschikken over een Key Vault met Sleutel en Beheerde identiteit met de juiste machtigingen die al zijn ingericht. Optioneel kan 256-bits AES-versleuteling op het niveau van de Azure Storage-infrastructuur ook worden ingeschakeld.
Stap 2: gebruikers controleren en de toegang tot opslaggegevens beheren met de minste bevoegdheden
Gebruik eerst de Microsoft Entra-id om de toegang tot opslagaccounts te beheren. Met op rollen gebaseerd toegangsbeheer met opslagaccounts kunt u de functie op basis van toegang nauwkeurig definiëren met behulp van OAuth 2.0. U kunt uw gedetailleerde toegang tot uw beleid voor voorwaardelijke toegang uitlijnen.
Het is belangrijk om te weten dat rollen voor opslagaccounts moeten worden toegewezen op beheer- of gegevensniveau. Als u dus Microsoft Entra-id gebruikt als verificatie- en autorisatiemethode, moet aan een gebruiker de juiste combinatie van rollen worden toegewezen om hen de minste hoeveelheid bevoegdheden te geven die nodig is om hun functie te voltooien.
Zie Ingebouwde Azure-rollen voor Opslag voor gedetailleerde toegang voor een lijst met opslagaccountrollen. RBAC-toewijzingen worden uitgevoerd via de optie Toegangsbeheer in het opslagaccount en kunnen op verschillende bereiken worden toegewezen.
U configureert toegangsbeheer vanuit de IAM-instellingen (Access Control) van een opslagaccount, zoals hier wordt weergegeven.
U kunt de toegangsniveaus van gebruikers, groepen, service-principals of beheerde identiteiten controleren en een roltoewijzing toevoegen.
Een andere manier om machtigingen te bieden die tijdsgebonden zijn, is via Shared Access Signatures (SAS). Aanbevolen procedures voor het gebruik van SAS op hoog niveau zijn:
- Gebruik altijd HTTPS. Als u het voorgestelde Azure-beleid voor Azure-landingszones hebt geïmplementeerd, wordt beveiligde overdracht via HTTPS gecontroleerd.
- Een intrekkingsplan hebben.
- Configureer het SAS-verloopbeleid.
- Valideer machtigingen.
- Gebruik waar mogelijk een SAS voor gebruikersdelegatie. Deze SAS is ondertekend met Microsoft Entra ID-referenties.
Stap 3: Kritieke gegevens logisch scheiden of scheiden met netwerkbesturingselementen
In deze stap gebruikt u de aanbevolen besturingselementen om de netwerkverbindingen van en naar Azure Storage-services te beveiligen.
In het volgende diagram worden de netwerkverbindingen met de Azure Storage-services in de referentiearchitectuur gemarkeerd.
| Opdracht | Beschrijving |
|---|---|
| Voorkom openbare toegang, maak netwerksegmentatie met Privé-eindpunt en Private Link. | Met een privé-eindpunt kunt u verbinding maken met services met behulp van één privé-IP-adres op het VNet met behulp van Azure Private Link. |
| Azure Private Link gebruiken | Gebruik Azure Private Link om toegang te krijgen tot Azure Storage via een privé-eindpunt in uw VNet. Gebruik de goedkeuringswerkstroom om, indien van toepassing, automatisch goedkeuring te geven of handmatig aan te vragen. |
| Openbare toegang tot uw gegevensbronnen voorkomen met behulp van service-eindpunten | U kunt netwerksegmentatie uitvoeren met behulp van service-eindpunten door privé-IP-adressen in een VNet in te schakelen om een eindpunt te bereiken zonder openbare IP-adressen te gebruiken. |
U configureert privé-eindpunten vanuit de netwerkinstellingen van een opslagaccount, zoals hier wordt weergegeven.
Stap 4: Defender for Storage gebruiken voor geautomatiseerde detectie en beveiliging van bedreigingen
Microsoft Defender voor Storage biedt dat extra intelligentieniveau waarmee ongebruikelijke en mogelijk schadelijke pogingen worden gedetecteerd om gebruik te maken van uw opslagservices. Microsoft Defender voor Storage is ingebouwd in Microsoft Defender voor Cloud.
Defender for Storage detecteert afwijkende toegangspatroonwaarschuwingen, zoals:
- Toegang vanaf ongebruikelijke locaties
- Anomalie van toepassing
- Anonieme toegang
- Afwijkende waarschuwingen voor extraheren/uploaden
- Gegevensexfiltratie
- Onverwacht verwijderen
- Azure Cloud Service-pakket uploaden
- Waarschuwingen voor verdachte opslagactiviteiten
- Wijziging van toegangsmachtiging
- Toegangsinspectie
- Gegevens verkennen
Zie het overzicht Van Zero Trust toepassen op Azure IaaS voor meer informatie over bedreigingsbeveiliging in de referentiearchitectuur.
Zodra deze optie is ingeschakeld, ontvangt u een waarschuwing over beveiligingswaarschuwingen en aanbevelingen voor het verbeteren van de beveiligingspostuur van uw Azure-opslagaccounts.
Hier volgt een voorbeeld van een beveiligingswaarschuwing voor een opslagaccount met een beschrijving van de waarschuwings- en preventiemaatregelen gemarkeerd.
Aanbevolen training
Opslagbeveiliging configureren
| Training | Opslagbeveiliging configureren |
|---|---|
|
Meer informatie over het configureren van algemene Azure Storage-beveiligingsfuncties, zoals handtekeningen voor opslagtoegang. In deze module leert u het volgende: |
Zie deze resources in de Microsoft-catalogus voor meer training over beveiliging in Azure:
Beveiliging in Azure | Microsoft Learn
Volgende stappen
Zie deze aanvullende artikelen voor het toepassen van Zero Trust-principes op Azure:
- Overzicht van Azure IaaS
- Azure Virtual Desktop
- Azure Virtual WAN
- IaaS-toepassingen in Amazon Web Services
- Microsoft Sentinel en Microsoft Defender XDR
Technische illustraties
Deze poster biedt in één oogopslag een overzicht van de onderdelen van Azure IaaS als referentie- en logische architecturen, samen met de stappen om ervoor te zorgen dat voor deze onderdelen de principes 'nooit vertrouwen, altijd verifiëren' van het Zero Trust-model worden toegepast.
| Item | Beschrijving |
|---|---|
 PDF | Visio Bijgewerkt in maart 2024 |
Gebruik deze afbeelding samen met dit artikel: Zero Trust-principes toepassen op azure IaaS-overzicht Verwante oplossingsgidsen |
Deze poster bevat de referentie- en logische architecturen en de gedetailleerde configuraties van de afzonderlijke onderdelen van Zero Trust voor Azure IaaS. Gebruik de pagina's van deze poster voor afzonderlijke IT-afdelingen of specialiteiten of pas met de Microsoft Visio-versie van het bestand de diagrammen voor uw infrastructuur aan.
| Item | Beschrijving |
|---|---|
 PDF | Visio Bijgewerkt in maart 2024 |
Gebruik deze diagrammen samen met de artikelen die hier beginnen: Zero Trust-principes toepassen op azure IaaS-overzicht Verwante oplossingsgidsen |
Klik hier voor aanvullende technische illustraties.
Verwijzingen
Raadpleeg de onderstaande koppelingen voor meer informatie over de verschillende services en technologieën die in dit artikel worden genoemd.
- Veilige overdracht voor Azure Storage-accounts
- Anonieme openbare leestoegang tot containers en blobs configureren
- Autorisatie van gedeelde sleutels voor een Azure Storage-account voorkomen
- Netwerkbeveiliging voor opslagaccounts
- Privé-eindpunten en Private Link voor opslagaccounts
- Storage Service Encryption (SSE)
- Op rollen gebaseerd toegangsbeheer voor opslagaccounts
- Azure Blob Backup
- Aanbevolen procedures bij het gebruik van SAS
- Beoordeling van privé-eindpunten
- Beoordeling van service-eindpunten
- Microsoft Defender voor Storage
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor