Vælg og konfigurer de relevante metoder til beskyttelse mod datasikkerhedstrusler, herunder blød sletning, sikkerhedskopier, versionering og uforanderligt lager
Azure Storage tilbyder omfattende databeskyttelse for Blob Storage og Azure Data Lake Storage Gen2 for at hjælpe dig med at forberede dig på situationer, hvor du skal gendanne data, der er blevet slettet eller overskrevet. Databeskyttelse er en kritisk komponent i din sikkerhedsstrategi, i overensstemmelse med Zero Trust-principperne ved at antage brud og sikre, at du kan komme dig over sikkerhedshændelser. Det er vigtigt at tænke over, hvordan du bedst beskytter dine data, før en hændelse opstår, som kan kompromittere dem, hvad enten det er fra ondsindede aktører, ved en fejl ved et uheld eller operationelle fejl.
Anbefalinger til grundlæggende databeskyttelse
Hvis du leder efter grundlæggende databeskyttelsesdækning for din lagerkonto og de data, den indeholder, anbefaler Microsoft, at du begynder med følgende trin:
- Konfigurér en Azure Resource Manager-lås på lagringskontoen for at beskytte kontoen mod sletning eller konfigurationsændringer. Dette forhindrer utilsigtet eller uautoriseret sletning af hele lagringskontoen.
- Aktiver container soft delete for lagringskontoen for at gendanne en slettet container og dens indhold. Dette giver et sikkerhedsnet mod utilsigtet containersletning.
-
Gem tilstanden af en blob med jævne mellemrum:
- I forbindelse med Blob Storage-arbejdsbelastninger skal du aktivere blobversioner for automatisk at gemme tilstanden af dine data, hver gang en blob overskrives.
- I forbindelse med Azure Data Lake Storage-arbejdsbelastninger skal du tage manuelle snapshots for at gemme tilstanden af dine data på et bestemt tidspunkt.
Oversigt over indstillinger for databeskyttelse
I følgende tabel opsummeres de tilgængelige indstillinger i Azure Storage til almindelige databeskyttelsesscenarier. Vælg de scenarier, der gælder for din situation, for at få mere at vide om de muligheder, der er tilgængelige for dig. Det er ikke alle funktioner, der er tilgængelige på nuværende tidspunkt for lagerkonti, hvor et hierarkisk navneområde er aktiveret.
Sikkerhedsnote: Implementering af flere lag af databeskyttelse giver dybdegående forsvar og sikrer, at du kan komme dig over forskellige typer hændelser, herunder ransomware-angreb, utilsigtede sletninger og ændringer af ondsindede data.
| scenarie | Mulighed for databeskyttelse | anbefalinger | beskyttelse | tilgængelig for Data Lake Storage- |
|---|---|---|---|---|
| Undgå, at en lagerkonto slettes eller ændres. | Lås til Azure Resource Manager Få mere at vide... |
Lås alle dine lagerkonti med en Lås i Azure Resource Manager for at forhindre sletning af lagerkontoen. | Beskytter lagerkontoen mod sletning eller konfigurationsændringer. Beskytter ikke objektbeholdere eller blobs i kontoen mod at blive slettet eller overskrevet. |
Ja |
| Undgå, at en blobversion slettes for et interval, som du styrer. | Uforanderlighedspolitik for en blobversion Få mere at vide... |
Angiv en uforanderlighedspolitik for en individuel blobversion for at beskytte forretningskritiske dokumenter, f.eks. for at opfylde lovmæssige eller lovmæssige krav til overholdelse af angivne standarder. | Beskytter en blobversion mod at blive slettet, og dens metadata bliver overskrevet. En overskrivningshandling opretter en ny version. Hvis mindst én objektbeholder har aktiveret uforanderlighed på versionsniveau, er lagerkontoen også beskyttet mod sletning. Sletning af objektbeholder mislykkes, hvis der findes mindst én blob i objektbeholderen. |
Nej |
| Undgå, at en objektbeholder og dens blobs slettes eller ændres for et interval, som du styrer. | Uforanderlighedspolitik for en objektbeholder Få mere at vide... |
Angiv en uforanderlighedspolitik for en objektbeholder for at beskytte forretningskritiske dokumenter, f.eks. for at opfylde lovmæssige eller lovmæssige krav til overholdelse af angivne standarder. | Beskytter en objektbeholder og dens blobs mod alle sletninger og overskrivninger. Når en juridisk bevarelsespolitik eller en låst tidsbaseret opbevaringspolitik er i kraft, er lagerkontoen også beskyttet mod sletning. Objektbeholdere, hvor der ikke er angivet en uforanderlighedspolitik, er ikke beskyttet mod sletning. |
Ja |
| Gendan en slettet objektbeholder inden for et angivet interval. | Blød sletning af objektbeholder Få mere at vide... |
Aktivér blød sletning af objektbeholder for alle lagerkonti med et minimum opbevaringsinterval på syv dage. Aktivér blød sletning af blobversioner og blød sletning af blob sammen med blød sletning af objektbeholder for at beskytte individuelle blobs i en objektbeholder. Gem objektbeholdere, der kræver forskellige opbevaringsperioder, i separate lagerkonti. |
En slettet objektbeholder og dens indhold kan gendannes inden for opbevaringsperioden. Det er kun handlinger på objektbeholderniveau (f.eks. Slet objektbeholder), der kan gendannes. Blød sletning af objektbeholder giver dig ikke mulighed for at gendanne en individuel blob i objektbeholderen, hvis den pågældende blob slettes. |
Ja |
| Gem automatisk tilstanden for en blob i en tidligere version, når den overskrives. | Blob-versionering Få mere at vide... |
Aktivér versionering af blob sammen med blød sletning af objektbeholder og blød sletning af blob for lagerkonti, hvor du har brug for optimal beskyttelse af blobdata. Gem blobdata, der ikke kræver versionering på en separat konto for at begrænse omkostningerne. |
Hver blobskrivningshandling opretter en ny version. Den aktuelle version af en blob kan gendannes fra en tidligere version, hvis den aktuelle version slettes eller overskrives. | Nej |
| Gendan en slettet blob- eller blobversion inden for et angivet interval. | Blød sletning af blob Få mere at vide... |
Aktivér blød sletning af blob for alle lagerkonti med et minimum opbevaringsinterval på syv dage. Aktivér blød sletning af blobversioner og objektbeholder sammen med blød sletning af blob for at sikre optimal beskyttelse af blobdata. Gem blobs, der kræver forskellige opbevaringsperioder i separate lagerkonti. |
En slettet blob- eller blobversion kan gendannes inden for opbevaringsperioden. | Ja |
| Gendan et sæt blokblopper til et tidligere tidspunkt. | Gendannelsestidspunkt Få mere at vide... |
Hvis du vil bruge gendannelsestidspunkt til at vende tilbage til en tidligere tilstand, skal du designe dit program til at slette individuelle blokblob i stedet for at slette objektbeholdere. | Et sæt blokblopper kan vende tilbage til deres tilstand på et bestemt tidspunkt i fortiden. Det er kun handlinger, der udføres på blokblob, der gendannes. Alle handlinger, der udføres på objektbeholdere, side-blobs eller vedhæft blobs, gendannes ikke. |
Nej |
| Gem tilstanden for en blob manuelt på et givet tidspunkt. | Snapshot af blob Få mere at vide... |
Anbefales som et alternativ til blobversioner, når versionering ikke passer til dit scenarie på grund af omkostninger eller andre overvejelser, eller når lagerkontoen har aktiveret et hierarkisk navneområde. | En blob kan gendannes fra et snapshot, hvis bloben overskrives. Hvis blob'en slettes, slettes snapshots også. | Ja |
| En blob kan slettes eller overskrives, men dataene kopieres jævnligt til en anden lagerkonto. | Rul din egen løsning til kopiering af data til en anden konto ved hjælp af Azure Storage-objektreplikering eller et værktøj som AzCopy eller Azure Data Factory. | Anbefales til beskyttelse mod uventede forsætlige handlinger eller uforudsigelige scenarier. Opret den anden lagerkonto i det samme område som den primære konto for at undgå gebyrer for udgående data. |
Data kan gendannes fra den anden lagerkonto, hvis den primære konto på nogen måde kompromitteres. | AzCopy og Azure Data Factory understøttes. Objektreplikering understøttes ikke. |
Databeskyttelse efter ressourcetype
I følgende tabel opsummeres indstillingerne for databeskyttelse i Azure Storage i henhold til de ressourcer, de beskytter.
| Mulighed for databeskyttelse | Beskytter en konto mod sletning | Beskytter en objektbeholder mod sletning | Beskytter et objekt mod sletning | beskytter et objekt mod overskrivning af |
|---|---|---|---|---|
| Lås til Azure Resource Manager | Ja | Nej | Nej | Nej |
| Uforanderlighedspolitik for en blobversion | Ja | Ja | Ja | Ja |
| Uforanderlighedspolitik for en objektbeholder | Ja | Ja | Ja | Ja |
| Blød sletning af objektbeholder | Nej | Ja | Nej | Nej |
| Blob-versionering | Nej | Nej | Ja | Ja |
| Blød sletning af blob | Nej | Nej | Ja | Ja |
| Gendannelsestidspunkt | Nej | Nej | Ja | Ja |
| Snapshot af blob | Nej | Nej | Nej | Ja |
| Opløft din egen løsning til kopiering af data til en anden konto | Nej | Ja | Ja | Ja |
Forståelsen af nuancerne i databeskyttelse i Azure Storage afslører flere operationelle indsigter og begrænsninger, som er vigtige for både sikkerhed og overholdelse:
- En Azure Resource Manager-lås beskytter ikke en container mod sletning, kun selve lagringskontoen.
- Sletning af lagringskonti fejler, hvis der er mindst én container med versionsniveau, uforanderlig lagring aktiveret, hvilket beskytter mod utilsigtet kontosletning.
- Container-sletning fejler, hvis der findes mindst én blob i containeren, uanset om uforanderlighedspolitikken er låst eller ulåst.
- Hvis du overskriver indholdet af den aktuelle version af blob'en, oprettes der en ny version. En uforanderlighedspolitik beskytter en versions metadata mod at blive overskrevet og sikrer dataintegritet.
- Selvom en lovlig tilbageholdelse eller en låst tidsbaseret opbevaringspolitik gælder i containerens omfang, er lagringskontoen også beskyttet mod sletning, hvilket giver overholdelsesbeskyttelse.
- Understøttes ikke i øjeblikket for Data Lake Storage workloads (gælder for blob-versionering og point-in-time gendannelse).
- AzCopy og Azure Data Factory er indstillinger, der understøttes for både Blob Storage- og Data Lake Storage-arbejdsbelastninger. Objektreplikering understøttes kun for Blob Storage-arbejdsbelastninger.
Gendan slettede eller overskrevne data
Hvis du skal gendanne data, der er blevet overskrevet eller slettet, afhænger den måde, du fortsætter på, af, hvilke databeskyttelsesindstillinger du har aktiveret, og hvilken ressource der blev påvirket. I følgende tabel beskrives de handlinger, du kan udføre for at gendanne data.
| Slettede eller overskrevne | Mulige genoprettelseshandlinger | Krav til genoprettelse |
|---|---|---|
| Lagerkonto | Forsøg på at gendanne den slettede lagerkonto |
Lagerkontoen blev oprindeligt oprettet med Azure Resource Manager-udrulningsmodellen og blev slettet inden for de seneste 14 dage. Der er ikke oprettet en ny lagerkonto med samme navn, siden den oprindelige konto blev slettet. |
| Beholder | Gendan den bløde slettede objektbeholder og dens indhold |
Blød sletning af objektbeholder er aktiveret, og opbevaringsperioden for blød sletning af objektbeholderen er endnu ikke udløbet. |
| Objektbeholdere og blobs | Gendan data fra en anden lagerkonto | Alle objektbeholder- og blobhandlinger er replikeret effektivt til en anden lagerkonto. |
| Blob (enhver type) | Gendan en blob fra en tidligere version |
Versionering af blob er aktiveret, og blob'en har en eller flere tidligere versioner. |
| Blob (enhver type) | Gendan en blød slettet blob |
Blød sletning af blob er aktiveret, og opbevaringsintervallet for blød sletning er ikke udløbet. |
| Blob (enhver type) | Gendan en blob fra et snapshot |
Blob'en har et eller flere snapshots. |
| Sæt blok-blobs | Gendan et sæt blokblopper til deres tilstand på et tidligere tidspunkt |
Gendannelsestidspunkt er aktiveret, og gendannelsespunktet er inden for opbevaringsintervallet. Lagerkontoen er ikke blevet kompromitteret eller beskadiget. |
| Blob-version | Gendan en blød slettet version |
Blød sletning af blob er aktiveret |
Oversigt over omkostningsovervejelser
| Mulighed for databeskyttelse | omkostningsovervejelser |
|---|---|
| Azure Resource Manager-lås til en lagerkonto | Det er gratis at konfigurere en lås på en lagerkonto. |
| Uforanderlighedspolitik for en blobversion | Det koster ikke noget at aktivere uforanderlighed på versionsniveau på en objektbeholder. Oprettelse, ændring eller sletning af en tidsbaseret opbevaringspolitik eller juridisk bevarelse af en blobversion medfører et gebyr for skrivning af transaktioner. |
| Uforanderlighedspolitik for en objektbeholder | Det er gratis at konfigurere en uforanderlighedspolitik for en objektbeholder. |
| Blød sletning af objektbeholder | Det er gratis at aktivere blød sletning af objektbeholder for en lagerkonto. Data i en blød slettet objektbeholder faktureres med samme hastighed som aktive data, indtil den midlertidigt slettede objektbeholder slettes permanent. |
| Blob-versionering | Det er gratis at aktivere blobversionsstyring for en lagerkonto. Når versionering af blob er aktiveret, opretter hver skrive- eller sletningshandling på en blob i kontoen en ny version, hvilket kan medføre øgede kapacitetsomkostninger. En blobversion faktureres baseret på entydige blokke eller sider. Omkostningerne øges derfor, efterhånden som basisblob'en afviger fra en bestemt version. Ændring af niveauet for en blob- eller blobversion kan have en faktureringsvirkning. Du kan finde flere oplysninger under Priser og fakturering. Brug livscyklusstyring til at slette ældre versioner efter behov for at styre omkostningerne. Du kan få flere oplysninger under Optimer omkostninger ved at automatisere Azure Blob Storage-adgangsniveauer. |
| Blød sletning af blob | Det er gratis at aktivere blød sletning af blob for en lagerkonto. Data i en blød slettet blob faktureres med samme hastighed som aktive data, indtil den blob, der er slettet midlertidigt, slettes permanent. |
| Gendannelsestidspunkt | Det er gratis at aktivere gendannelse på et tidspunkt for en lagerkonto. Aktivering af gendannelse på et tidspunkt muliggør dog også blobversioner, blød sletning og ændring af feed, hvilket hver især kan medføre andre gebyrer. Du faktureres for gendannelse på et tidspunkt, når du udfører en gendannelse. Omkostningerne ved en gendannelseshandling afhænger af mængden af data, der gendannes. Du kan finde flere oplysninger under Priser og fakturering. |
| Blobbilleder | Data i et snapshot faktureres på baggrund af entydige blokke eller sider. Omkostningerne øges derfor, efterhånden som basisblob'et afviger fra snapshottet. Ændring af niveauet for en blob eller et snapshot kan have en faktureringsvirkning. Du kan finde flere oplysninger under Priser og fakturering. Brug livscyklusstyring til at slette ældre snapshots efter behov for at styre omkostningerne. Du kan få flere oplysninger under Optimer omkostninger ved at automatisere Azure Blob Storage-adgangsniveauer. |
| Kopiér data til en anden lagerkonto | Vedligeholdelse af data på en anden lagerkonto medfører kapacitets- og transaktionsomkostninger. Hvis den anden lagerkonto er placeret i et andet område end kildekontoen, vil der desuden blive opkrævet udgående gebyrer for kopiering af data til den anden konto. |
It-katastrofeberedskab
Azure Storage vedligeholder altid flere kopier af dine data, så de er beskyttet mod planlagte og ikke-planlagte hændelser, herunder midlertidige hardwarefejl, netværks- eller strømafbrydelser og massive naturkatastrofer. Redundans sikrer, at din lagerkonto opfylder sine mål for tilgængelighed og holdbarhed, selv i tilfælde af fejl.
Hvis der sker en fejl i et datacenter, og din lagringskonto er redundant på tværs af to geografiske regioner (geo-redundant), har du mulighed for at overføre din konto fra primærregionen til sekundærregionen. Denne kapacitet er afgørende for forretningskontinuitet og katastrofeberedskabsplanlægning.
Vigtigt!
Kundeadministreret failover understøttes i øjeblikket ikke for lagerkonti med et hierarkisk navneområde aktiveret.
Bedste praksis for implementering af databeskyttelse
Når du implementerer databeskyttelse for Azure Storage, bør du overveje disse anbefalinger:
- Implementér forsvar i dybden: Brug flere beskyttelsesmekanismer sammen. For eksempel kan man kombinere blob-versionering, soft delete og uforanderlighedspolitikker for omfattende beskyttelse mod forskellige typer datatab.
- Regelmæssig testning: Test jævnligt dine datagendannelsesprocedurer for at sikre, at de fungerer som forventet, og at dit team er fortrolig med gendannelsesprocessen.
- Planlægning af opbevaringsperioder: Sæt passende opbevaringsperioder baseret på dine compliance-krav, men overvej også lagringsomkostningerne forbundet med at gemme blødt slettede data og versioner.
- Brug uforanderlighedspolitikker til overholdelse: For regulerede industrier skal uforanderlighedspolitikker implementeres på containere eller blob-versioner for at opfylde WORM (Write Once, Read Many) overholdelseskrav.
- Overvågningsbeskyttelsesstatus: Brug Azure Monitor og Azure Policy til at spore, hvilke lagringskonti der har databeskyttelsesfunktioner aktiveret, og identificere eventuelle huller i din beskyttelsesstrategi.
- Dokumentér din strategi: Vedligehold klar dokumentation af din databeskyttelseskonfiguration, herunder hvilke funktioner der er aktiveret, opbevaringsperioder og gendannelsesprocedurer.
- Overvej omkostninger versus beskyttelse: Selvom omfattende databeskyttelse er vigtig, bør du afveje beskyttelsesniveauet mod lagringsomkostningerne. Brug livscyklusstyringspolitikker til automatisk at slette gamle versioner og snapshots baseret på dine krav.
- Geo-redundans for kritiske data: For forretningskritiske data anvendes geo-redundant lagring (GRS eller GZRS) for at sikre datatilgængelighed, selv hvis en hel region bliver utilgængelig.
- Kombiner med backup-løsninger: For ekstra beskyttelse kan du overveje at bruge Azure Backup til Azure Files eller tredjeparts backup-løsninger, der tilbyder ekstra gendannelsesmuligheder og langvarig opbevaring.