I en tid hvor data er en av de mest verdifulle ressursene en organisasjon besitter, og samtidig et av de mest utsatte elementene for kompromittering, blir det avgjørende å sikre at sensitive data ikke kan manipuleres uten at det oppdages. Microsofts Ledger-funksjonalitet for Azure SQL representerer et teknologisk gjennombrudd i dette området, ved å gjøre databaser og tabeller manipulasjonssikre gjennom kryptografisk verifiserbar historikk.

Når Ledger aktiveres i en database, forvandles vanlige SQL-tabeller til såkalte ledger-tabeller. Disse finnes i to varianter: oppdaterbare og append-only. Oppdaterbare ledger-tabeller er konstruert for scenarioer der det skjer kontinuerlige oppdateringer, innsettinger og slettinger. Systemet oppretter da en tilhørende historikktabell, hvor tidligere versjoner av hver rad lagres i en kryptografisk hashet struktur. På denne måten dannes det en uforanderlig kjede av transaksjoner – en blockchain – som gjør ethvert forsøk på å manipulere historiske data både detekterbart og sporbart.

I tillegg til at selve dataene hashes og lenkes sammen, kan systemet generere digests – digitale signaturer av hele databasen – som lagres eksternt. Disse kan senere brukes til å verifisere integriteten til data, også i tilfeller hvor databasen har blitt flyttet eller kopiert.

Append-only ledger-tabeller retter seg mot scenarier der det kun forekommer innsetting av nye data, for eksempel i logging- eller hendelseshåndteringssystemer. Disse tabellene blokkerer alle forsøk på å oppdatere eller slette rader, noe som eliminerer behovet for historikktabeller. Strukturen forblir dermed lineær og uforanderlig, noe som ytterligere styrker tilliten til datakildens autentisitet.

Aktivering av Ledger-funksjonaliteten i Azure-portalen under opprettelsen av en ny database er en irreversibel operasjon: alle eksisterende og fremtidige tabeller i databasen konverteres til oppdaterbare ledger-tabeller. Alternativt kan man ved hjelp av T-SQL aktivere ledger-funksjonaliteten selektivt for enkeltstående tabeller. Her spesifiseres parameteren LEDGER = ON i CREATE TABLE-kommandoen. For append-only tabeller brukes i tillegg APPEND_ONLY = ON, og parameteren SYSTEM_VERSIONING kan da utelates, ettersom det ikke forekommer versjonering.

Men selv med uforanderlige data må tilgangen kontrolleres. Her kommer radbasert sikkerhet (Row-Level Security) inn som et effektivt tiltak. I stedet for å beskytte hele kolonner eller tabeller, defineres sikkerhetspolicyer som begrenser hvilke rader en gitt bruker får tilgang til, basert på betingelser knyttet til brukeridentitet eller roller. For eksempel kan en HR-database ha én rad per ansatt, men ledere får kun se de ansatte som tilhører deres egne avdelinger. Dette oppnås ved hjelp av funksjoner i T-SQL og sikkerhetspolicyer som filtrerer data dynamisk.

Gjennom en firestegs prosess oppretter man et separat sikkerhetsskjema, definerer en funksjon som returnerer tillatte rade

Hvordan sikrer Azure høy tilgjengelighet og katastrofegjenoppretting for SQL Server?

Azure tilbyr robuste mekanismer for høy tilgjengelighet (HA) og katastrofegjenoppretting (DR) som fungerer uavhengig av programvaren som kjører på virtuelle maskiner (VM). Disse inkluderer tilgjengelighetssett og tilgjengelighetssoner som bidrar til å spre virtuelle maskiner over forskjellige feil- og oppdateringsdomener, samt ulike datasentre for å minimere risikoen for at én enkelt feil påvirker flere ressurser samtidig.

Tilgjengelighetssett segmenterer datasentre i feilområder og oppdateringsområder. Feilområder sørger for at VMer i samme sett ikke kjører på samme fysiske maskin, mens oppdateringsområder sikrer at oppdateringer og vedlikehold ikke utføres på alle VMer samtidig. Dette reduserer sjansen for at maskinvarefeil eller planlagt vedlikehold påvirker mer enn én VM i et sett.

Tilgjengelighetssoner fungerer på et høyere nivå ved å distribuere VMer på tvers av forskjellige datasentre innen samme Azure-region. En region kan ha opptil tre soner, og ved å plassere VMer i separate soner sikres det at en katastrofe som rammer ett datasenter ikke slår ut alle VMene i regionen.

Azure Site Recovery gir mulighet for replikering av VM-er til en annen region, slik at driften kan opprettholdes selv om en hel region skulle bli utilgjengelig. Denne løsningen opererer på VM-nivå og kjenner ikke til SQL Server-transaksjoner eller annen programvare.

For at disse løsningene skal være effektive, må de testes grundig. Testprosedyrer kan variere fra sjekklister og bordøvelser, til simulerings- og parallelltesting, og til slutt fullstendig produksjonsavbrudd for å etterligne reelle hendelser. Hver metode har sine fordeler og ulemper, hvor spesielt fullstendig avbrudd gir mest realistisk innsikt, men samtidig innebærer høy risiko for virksomheten.

Selv om mange HA/DR-løsninger kan være kostbare og komplekse, er sikkerhetskopiering og gjenoppretting av databaser et minimum som må være på plass. For SQL Server i Azure finnes det flere lag av backup-muligheter, avhengig av om tjenesten kjører på IaaS- eller PaaS-plattform. IaaS gir muligheter til å ta backup på SQL Server-nivå, operativsystemnivå og i Azure-miljøet. Ved opprettelse av VMer i Azure kan man aktivere automatisert backup som gir mulighet for å konfigurere lagring og tilbakeholdelsesperioder.

I PaaS-miljøer som Azure SQL Database og Azure SQL Managed Instance skjer backup automatisk med en full backup ukentlig, differensialbackup to ganger daglig og transaksjonsloggbackup hvert tiende minutt. Backuper lagres i geo-redundant Azure blob storage, noe som sikrer at dataene er tilgjengelige selv om et datasenter skulle bli utilgjengelig.

SQL Server Management Studio (SSMS) tilbyr et grensesnitt for å utføre både backup og gjenoppretting. Her kan man velge mellom full backup, differensialbackup og transaksjonsloggbackup, samt angi destinasjon for backupfiler. Ved gjenoppretting kan administrator velge tidspunkt for gjenoppretting og gjenopprettingsmodus, som styrer hvordan databasen håndterer transaksjoner under prosessen.

Det er viktig å forstå at gjenoppretting i SQL Server innebærer å fullføre eventuelle ufullstendige transaksjoner før databasen settes online igjen. Valg av gjenopprettingsmodus påvirker muligheten til å legge på flere backup-nivåer i etterkant, som differensial- eller loggbackup.

Å velge riktig backup- og gjenopprettingsstrategi krever innsikt i organisasjonens behov, plattformen databasen kjører på, og de økonomiske og administrative ressursene tilgjengelig. Selv om mange HA/DR-løsninger kan virke som et stort løft, er en solid backup- og gjenopprettingsplan helt essensiell for å sikre dataintegritet og tilgjengelighet.

Videre er det viktig å erkjenne at teknologiske løsninger alene ikke er nok; de må integreres med klare prosedyrer, opplæring og regelmessig testing for å være effektive i en krisesituasjon. Organisasjoner bør også vurdere muligheten for automatisering og overvåkning for å redusere menneskelige feil og oppdage problemer tidlig. Backupdata må beskyttes mot korrupsjon og uautorisert tilgang, og lagringsløsninger må jevnlig gjennomgås for å sikre at de møter dagens sikkerhets- og tilgjengelighetskrav.

Hvordan nullmodene påvirker fluktuasjoner i magnetiske systemer
Hvordan kan vi forstå de førkristne gudinnene i den tidlige germanske verden?
Hva må til for å kjøre Windows 11 på din enhet?
Hvordan opprettholdes rørledningsintegritet i praksis?