Velg og konfigurer riktige metoder for å beskytte mot datasikkerhetstrusler, inkludert myk sletting, sikkerhetskopier, versjonskontroll og uforanderlig lagring
Azure Storage tilbyr omfattende databeskyttelse for Blob Storage og Azure Data Lake Storage Gen2 for å hjelpe deg å forberede deg på situasjoner hvor du må gjenopprette data som er slettet eller overskrevet. Databeskyttelse er en kritisk komponent i din sikkerhetsstrategi, i tråd med Zero Trust-prinsippene ved å anta brudd og sikre at du kan komme deg etter sikkerhetshendelser. Det er viktig å tenke på hvordan du best kan beskytte dataene dine før en hendelse inntreffer som kan kompromittere dem, enten fra ondsinnede aktører, utilsiktet sletting eller driftsfeil.
Anbefalinger for grunnleggende databeskyttelse
Hvis du leter etter grunnleggende databeskyttelsesdekning for lagringskontoen og dataene den inneholder, anbefaler Microsoft å ta følgende trinn til å begynne med:
- Konfigurer en Azure Resource Manager-lås på lagringskontoen for å beskytte kontoen mot sletting eller konfigurasjonsendringer. Dette forhindrer utilsiktet eller uautorisert sletting av hele lagringskontoen.
- Aktiver container soft delete for lagringskontoen for å gjenopprette en slettet container og innholdet derfra. Dette gir et sikkerhetsnett mot utilsiktet sletting av containere.
-
Lagre tilstanden til en blob med jevne mellomrom:
- For Blob Storage-arbeidsbelastninger kan du aktivere blob-versjonskontroll for å lagre tilstanden til dataene automatisk hver gang en blob overskrives.
- For Azure Data Lake Storage-arbeidsbelastninger kan du ta manuelle øyeblikksbilder for å lagre tilstanden til dataene på et bestemt tidspunkt.
Oversikt over alternativer for databeskyttelse
Tabellen nedenfor oppsummerer alternativene som er tilgjengelige i Azure Storage for vanlige scenarioer for databeskyttelse. Velg scenarioene som gjelder for din situasjon, for å lære mer om alternativene som er tilgjengelige for deg. Ikke alle funksjoner er tilgjengelige på dette tidspunktet for lagringskontoer med et hierarkisk navneområde aktivert.
Sikkerhetsmerknad: Å implementere flere lag med databeskyttelse gir dybdeforsvar og sikrer at du kan komme deg etter ulike typer hendelser, inkludert løsepengevirusangrep, utilsiktede slettinger og endringer i ondsinnede data.
| scenario | alternativ for databeskyttelse | anbefalinger | beskyttelsesfordel | tilgjengelig for data lake storage |
|---|---|---|---|---|
| Hindre at en lagringskonto slettes eller endres. | Azure Resource Manager-lås Finn ut mer... |
Lås alle lagringskontoene med en Azure Resource Manager-lås for å hindre sletting av lagringskontoen. | Beskytter lagringskontoen mot sletting eller konfigurasjonsendringer. Beskytter ikke beholdere eller blober i kontoen fra å bli slettet eller overskrevet. |
Ja |
| Hindre at en BLOB-versjon slettes for et intervall du kontrollerer. | Uforanderlighetspolicy på en BLOB-versjon Finn ut mer... |
Angi en uforanderlighetspolicy for en individuell BLOB-versjon for å beskytte forretningskritiske dokumenter, for eksempel for å oppfylle juridiske eller forskriftsmessige samsvarskrav. | Beskytter en blob-versjon fra å bli slettet, og metadataene blir overskrevet. En overskrivingsoperasjon oppretter en ny versjon. Hvis minst én beholder har aktivert uforanderlighet på versjonsnivå, er lagringskontoen også beskyttet mot sletting. Sletting av beholder mislykkes hvis det finnes minst én blob i beholderen. |
Nei |
| Hindre at en beholder og blobene slettes eller endres for et intervall du kontrollerer. | Uforanderlighetspolicy på en beholder Finn ut mer... |
Angi en uforanderlighetspolicy for en beholder for å beskytte forretningskritiske dokumenter, for eksempel for å oppfylle juridiske eller forskriftsmessige samsvarskrav. | Beskytter en beholder og blobene fra alle slettinger og overskrivinger. Når en juridisk sperring eller en låst tidsbasert oppbevaringspolicy er i kraft, er lagringskontoen også beskyttet mot sletting. Beholdere som det ikke er angitt noen uforanderlighetspolicy for, er ikke beskyttet mot sletting. |
Ja |
| Gjenopprette en slettet beholder i et angitt intervall. | Myk sletting av beholder Finn ut mer... |
Aktiver sletting av beholder for alle lagringskontoer, med et minimum oppbevaringsintervall på sju dager. Aktiver blob versjonskontroll og blob myk sletting sammen med beholder myk sletting for å beskytte individuelle blober i en beholder. Lagre beholdere som krever forskjellige oppbevaringsperioder i separate lagringskontoer. |
En slettet beholder og innholdet kan gjenopprettes i oppbevaringsperioden. Bare operasjoner på beholdernivå (for eksempel Slett beholder) kan gjenopprettes. Sletting av beholderen gjør det ikke mulig å gjenopprette en individuell blob i beholderen hvis bloben slettes. |
Ja |
| Lagre tilstanden til en BLOB automatisk i en tidligere versjon når den overskrives. | Blob-versjonskontroll Finn ut mer... |
Aktiver blob-versjonskontroll, sammen med myk sletting av beholder og blob-sletting, for lagringskontoer der du trenger optimal beskyttelse for BLOB-data. Lagre blob-data som ikke krever versjonskontroll i en egen konto for å begrense kostnadene. |
Hver blob-skriveoperasjon oppretter en ny versjon. Gjeldende versjon av en blob kan gjenopprettes fra en tidligere versjon hvis den gjeldende versjonen slettes eller overskrives. | Nei |
| Gjenopprette en slettet BLOB- eller BLOB-versjon i et angitt intervall. | Myk blob-sletting Finn ut mer... |
Aktiver myk blob-sletting for alle lagringskontoer, med et minimum oppbevaringsintervall på sju dager. Aktiver blob-versjonskontroll og myk sletting av beholder sammen med blob-myk sletting for optimal beskyttelse av BLOB-data. Lagre blober som krever forskjellige oppbevaringsperioder i separate lagringskontoer. |
En slettet BLOB- eller BLOB-versjon kan gjenopprettes i oppbevaringsperioden. | Ja |
| Gjenopprette et sett med blokkblob til et tidligere tidspunkt. | Punkt-i-tid-gjenoppretting Finn ut mer... |
Hvis du vil bruke punkt-i-tid-gjenoppretting til å gå tilbake til en tidligere tilstand, utformer du programmet for å slette individuelle blokkblober i stedet for å slette beholdere. | Et sett med blokkblob kan gå tilbake til tilstanden på et bestemt punkt i fortiden. Bare operasjoner som utføres på blokkblob, tilbakestilles. Alle operasjoner som utføres på beholdere, sideblob eller tilføyingsblob, tilbakestilles ikke. |
Nei |
| Lagre tilstanden til en blob manuelt på et gitt tidspunkt. | Blob-øyeblikksbilde Finn ut mer... |
Anbefales som et alternativ til blob-versjonskontroll når versjonskontroll ikke passer for scenarioet, på grunn av kostnader eller andre hensyn, eller når lagringskontoen har et hierarkisk navneområde aktivert. | En blob kan gjenopprettes fra et øyeblikksbilde hvis bloben overskrives. Hvis bloben slettes, slettes også øyeblikksbilder. | Ja |
| En blob kan slettes eller overskrives, men dataene kopieres regelmessig til en annen lagringskonto. | Rull din egen løsning for kopiering av data til en annen konto ved hjelp av Azure Storage-objektreplikering eller et verktøy som AzCopy eller Azure Data Factory. | Anbefalt for trygghetsbeskyttelse mot uventede bevisste handlinger eller uforutsigbare scenarioer. Opprett den andre lagringskontoen i samme område som primærkontoen for å unngå å påløpe utgående belastninger. |
Data kan gjenopprettes fra den andre lagringskontoen hvis primærkontoen er kompromittert på noen måte. | AzCopy og Azure Data Factory støttes. Objektreplikering støttes ikke. |
Databeskyttelse etter ressurstype
Tabellen nedenfor oppsummerer databeskyttelsesalternativene for Azure Storage i henhold til ressursene de beskytter.
| alternativ for databeskyttelse | Beskytter en konto mot sletting | Beskytter en beholder mot sletting | Beskytter et objekt mot sletting | Beskytter et objekt mot overskrivinger |
|---|---|---|---|---|
| Azure Resource Manager-lås | Ja | Nei | Nei | Nei |
| Uforanderlighetspolicy på en BLOB-versjon | Ja | Ja | Ja | Ja |
| Uforanderlighetspolicy på en beholder | Ja | Ja | Ja | Ja |
| Myk sletting av beholder | Nei | Ja | Nei | Nei |
| Blob-versjonskontroll | Nei | Nei | Ja | Ja |
| Myk blob-sletting | Nei | Nei | Ja | Ja |
| Punkt-i-tid-gjenoppretting | Nei | Nei | Ja | Ja |
| Blob-øyeblikksbilde | Nei | Nei | Nei | Ja |
| Rull din egen løsning for kopiering av data til en annen konto | Nei | Ja | Ja | Ja |
Å forstå nyansene i databeskyttelse i Azure Storage avslører flere operative innsikter og begrensninger som er viktige for både sikkerhet og etterlevelse:
- En Azure Resource Manager-lås beskytter ikke en container mot sletting, bare selve lagringskontoen.
- Sletting av lagringskontoer feiler hvis det finnes minst én container med versjonsnivå uforanderlig lagring aktivert, noe som gir beskyttelse mot utilsiktet sletting av kontoen.
- Containersletting feiler hvis minst én blob finnes i containeren, uavhengig av om uforanderlighetspolicyen er låst eller ulåst.
- Overskriving av innholdet i den gjeldende versjonen av bloben oppretter en ny versjon. En uforanderlighetspolicy beskytter en versjons metadata mot å bli overskrevet, og sikrer dataintegritet.
- Selv om en lovlig oppbevaring eller en låst tidsbasert oppbevaringspolicy gjelder i containeromfang, er lagringskontoen også beskyttet mot sletting, noe som gir samsvarsbeskyttelse.
- Støttes for øyeblikket ikke for Data Lake Storage-arbeidsbelastninger (gjelder for blob-versjonering og punkt-i-tid-gjenoppretting).
- AzCopy og Azure Data Factory er alternativer som støttes for både Blob Storage og Data Lake Storage-arbeidsbelastninger. Objektreplikering støttes bare for Blob Storage-arbeidsbelastninger.
Gjenopprette slettede eller overskrevne data
Hvis du må gjenopprette data som er overskrevet eller slettet, avhenger måten du fortsetter på, avhengig av hvilke alternativer for databeskyttelse du har aktivert, og hvilken ressurs som ble påvirket. Tabellen nedenfor beskriver handlingene du kan utføre for å gjenopprette data.
| Slettet eller overskrevet ressurs | Mulige gjenopprettingshandlinger | krav til gjenoppretting |
|---|---|---|
| Lagringskonto | Forsøk på å gjenopprette den slettede lagringskontoen |
Lagringskontoen ble opprinnelig opprettet med Distribusjonsmodellen for Azure Resource Manager og ble slettet i løpet av de siste 14 dagene. En ny lagringskonto med samme navn er ikke opprettet siden den opprinnelige kontoen ble slettet. |
| Beholder | Gjenopprette beholderen med myk sletting og innholdet |
Myk sletting av beholder er aktivert, og oppbevaringsperioden for beholderen er ikke utløpt ennå. |
| Beholdere og blober | Gjenopprette data fra en annen lagringskonto | Alle beholder- og blob-operasjoner er effektivt replisert til en annen lagringskonto. |
| Blob (hvilken som helst type) | Gjenopprette en blob fra en tidligere versjon |
Blob-versjonskontroll er aktivert, og BLOB-en har én eller flere tidligere versjoner. |
| Blob (hvilken som helst type) | Gjenopprette en myk slettet BLOB |
Myk blob-sletting er aktivert, og oppbevaringsintervallet for myk sletting er ikke utløpt. |
| Blob (hvilken som helst type) | Gjenopprette en blob fra et øyeblikksbilde |
Bloben har ett eller flere øyeblikksbilder. |
| Sett med blokkblob | Gjenopprette et sett med blokkblob til tilstanden på et tidligere tidspunkt |
Punkt-i-tid-gjenoppretting er aktivert, og gjenopprettingspunktet er innenfor oppbevaringsintervallet. Lagringskontoen er ikke kompromittert eller skadet. |
| Blob-versjon | Gjenopprette en myk slettet versjon |
Myk blob-sletting er aktivert |
Sammendrag av kostnadshensyn
| alternativ for databeskyttelse | Kostnadshensyn |
|---|---|
| Azure Resource Manager-lås for en lagringskonto | Ingen kostnad for å konfigurere en lås på en lagringskonto. |
| Uforanderlighetspolicy på en BLOB-versjon | Ingen kostnad for å aktivere uforanderlighet på versjonsnivå på en beholder. Oppretting, endring eller sletting av en tidsbasert oppbevaringspolicy eller juridisk sperring på en blob-versjon resulterer i et skrivetransaksjonsgebyr. |
| Uforanderlighetspolicy på en beholder | Ingen kostnad for å konfigurere en uforanderlighetspolicy på en beholder. |
| Myk sletting av beholder | Ingen kostnad for å aktivere sletting av beholder for en lagringskonto. Data i en beholder med myk sletting faktureres i samme hastighet som aktive data til beholderen med myk sletting slettes permanent. |
| Blob-versjonskontroll | Ingen kostnad for å aktivere blob-versjonskontroll for en lagringskonto. Når blob-versjonskontroll er aktivert, oppretter hver skrive- eller sletteoperasjon på en blob i kontoen en ny versjon, noe som kan føre til økte kapasitetskostnader. En BLOB-versjon faktureres basert på unike blokker eller sider. Kostnadene øker derfor etter hvert som basisbloben avviker fra en bestemt versjon. Endring av et blob- eller blob-versjonsnivå kan ha en faktureringsinnvirkning. Hvis du vil ha mer informasjon, kan du se Priser og fakturering. Bruk livssyklusbehandling til å slette eldre versjoner etter behov for å kontrollere kostnadene. Hvis du vil ha mer informasjon, kan du se Optimalisere kostnader ved å automatisere tilgangsnivåer for Azure Blob Storage. |
| Myk blob-sletting | Ingen kostnad for å aktivere blob myk sletting for en lagringskonto. Data i en myk slettet blob faktureres i samme hastighet som aktive data til den myk-slettede bloben slettes permanent. |
| Punkt-i-tid-gjenoppretting | Ingen kostnad for å aktivere punkt-i-tid-gjenoppretting for en lagringskonto. Aktivering av punkt-i-tid-gjenoppretting muliggjør imidlertid også blob-versjonskontroll, myk sletting og endringsfeed, som hver kan resultere i andre belastninger. Du faktureres for punkt-i-tid-gjenoppretting når du utfører en gjenopprettingsoperasjon. Kostnaden for en gjenopprettingsoperasjon avhenger av mengden data som gjenopprettes. Hvis du vil ha mer informasjon, kan du se Priser og fakturering. |
| Blob-øyeblikksbilder | Data i et øyeblikksbilde faktureres basert på unike blokker eller sider. Kostnadene øker derfor etter hvert som basisbloben avviker fra øyeblikksbildet. Endring av et blob- eller øyeblikksbildenivå kan ha en faktureringsinnvirkning. Hvis du vil ha mer informasjon, kan du se Priser og fakturering. Bruk livssyklusbehandling til å slette eldre øyeblikksbilder etter behov for å kontrollere kostnadene. Hvis du vil ha mer informasjon, kan du se Optimalisere kostnader ved å automatisere tilgangsnivåer for Azure Blob Storage. |
| Kopiere data til en annen lagringskonto | Vedlikehold av data i en annen lagringskonto vil medføre kapasitets- og transaksjonskostnader. Hvis den andre lagringskontoen er plassert i et annet område enn kildekontoen, vil kopiering av data til den andre kontoen i tillegg medføre utgående belastninger. |
Katastrofegjenoppretting
Azure Storage opprettholder alltid flere kopier av dataene slik at de er beskyttet mot planlagte og ikke-planlagte hendelser, inkludert midlertidige maskinvarefeil, nettverks- eller strømbrudd og massive naturkatastrofer. Redundans sikrer at lagringskontoen oppfyller tilgjengelighets- og holdbarhetsmålene selv i møte med feil.
Hvis det oppstår en feil i et datasenter, og lagringskontoen din er redundant på tvers av to geografiske regioner (geo-redundant), har du muligheten til å overføre kontoen fra primærregionen til sekundærregionen. Denne kapasiteten er avgjørende for forretningskontinuitet og planlegging av katastrofegjenoppretting.
Viktig!
Kundeadministrert failover støttes for øyeblikket ikke for lagringskontoer med et hierarkisk navneområde aktivert.
Beste praksis for implementering av databeskyttelse
Når du implementerer databeskyttelse for Azure Storage, bør du vurdere disse anbefalingene:
- Implementer forsvar i dybden: Bruk flere beskyttelsesmekanismer sammen. For eksempel, kombiner blob-versjonering, myk sletting og uforanderlighetspolicyer for omfattende beskyttelse mot ulike typer datatap.
- Regelmessig testing: Test jevnlig prosedyrene for datagjenoppretting for å sikre at de fungerer som forventet og at teamet ditt er kjent med gjenopprettingsprosessen.
- Planlegging av oppbevaringstid: Sett passende oppbevaringsperioder basert på dine krav til etterlevelse, men vurder også lagringskostnadene knyttet til lagring av mykslettede data og versjoner.
- Bruk uforanderlighetspolicyer for etterlevelse: For regulerte bransjer, implementer uforanderlighetspolicyer på containere eller blob-versjoner for å oppfylle WORM (Write Once, Read Many) compliance-krav.
- Overvåk beskyttelsesstatus: Bruk Azure Monitor og Azure Policy for å spore hvilke lagringskontoer som har databeskyttelsesfunksjoner aktivert og identifisere eventuelle hull i beskyttelsesstrategien din.
- Dokumenter strategien din: Oppretthold tydelig dokumentasjon av din databeskyttelseskonfigurasjon, inkludert hvilke funksjoner som er aktivert, oppbevaringsperioder og gjenopprettingsprosedyrer.
- Vurder kostnad versus beskyttelse: Selv om omfattende databeskyttelse er viktig, bør du balansere beskyttelsesnivået mot lagringskostnader. Bruk livssyklusstyringspolicyer for automatisk å slette gamle versjoner og snapshots basert på dine behov.
- Geo-redundans for kritiske data: For forretningskritiske data, bruk geo-redundant lagring (GRS eller GZRS) for å sikre datatilgjengelighet selv om en hel region blir utilgjengelig.
- Kombiner med sikkerhetskopieringsløsninger: For ekstra beskyttelse, vurder å bruke Azure Backup for Azure Files eller tredjeparts sikkerhetskopieringsløsninger som tilbyr ekstra gjenopprettingsmuligheter og langsiktig lagring.