I SQL Server og Azure SQL-databaser er administrasjon av sikkerhetsidentiteter avgjørende for å sikre tilgang og kontroll over dataressursene. Et sentralt element i dette er bruken av administrative kontoer, ofte tilknyttet en gruppeidentitet, som gir administrative rettigheter både på server- og databasenivå. Å bruke en gruppeidentitet for administratorer er anbefalt, da det forenkler håndtering av personalendringer uten å måtte modifisere individuelle kontoer.

I en tradisjonell lokal SQL Server-installasjon, som benytter Active Directory (AD) for autentisering, må man først sette opp en AD-infrastruktur ved å installere en Windows Server og tildele den rollen som domenekontroller. Domenekontrollere lagrer brukerinformasjon og tilbyr autentisering og autorisasjonstjenester for Windows og applikasjoner, inkludert SQL Server. Under installasjonen av SQL Server velges mellom Windows-autentiseringsmodus eller Mixed Mode. Windows-autentisering deaktiverer SQL Servers egne autentiseringsmekanismer, mens Mixed Mode tillater begge. Det finnes ikke et alternativ for kun SQL Server-autentisering fordi brukere alltid må logge inn på Windows, uavhengig av tilgang til SQL Server.

Det er viktig å merke seg at bruk av Active Directory ikke er obligatorisk for Windows-autentisering, og SQL Server kan autentisere brukere lokalt uten et sentralt domene. Likevel, når SQL Server er koblet til et AD-domene, vil administratoren ved opprettelse av SQL Server-administrator bli bedt om å velge en AD-bruker.

Microsoft Entra-identiteter, som brukes i Azure, muliggjør pålogging til Azure-tjenester. For å gi tilgang til SQL Database eller SQL Managed Instance basert på Entra-identiteter, må en administrator opprette en SQL-pålogging via T-SQL kommandoen CREATE LOGIN med FROM EXTERNAL PROVIDER-argumentet. Denne metoden binder SQL-påloggingen til Entra-identitetens legitimasjon. Man kan også spesifisere en objekt-ID for å opprette en pålogging som ikke nødvendigvis samsvarer med visningsnavnet i Entra.

I SQL representerer en sikkerhetsprinsipp (security principal) enhver entitet som kan be om tilgang til SQL Server-ressurser og som kan tildeles nødvendige rettigheter. Ressursene kalles securables og deles inn i tre nivåer: server, database og skjema. To hovedtyper sikkerhetsprinsipper i SQL er logins og users. Login er identiteten på servernivå, mens user er identiteten på databasenivå. For å bruke en database må en login mappes til en databasebruker.

Opprettelse av logins kan skje enten for Entra-identiteter eller for SQL-autentisering med brukernavn og passord. Databasebrukere opprettes inne i den aktuelle databasen ved hjelp av CREATE USER, hvor man kan knytte brukeren til en login eller direkte til en ekstern leverandør som Entra. Bruk av roller forenkler administrasjon ved at tillatelser tildeles roller, og brukere legges til eller fjernes fra disse rollene. Roller fungerer som sikkerhetsgrupper hvor alle medlemmer arver tillatelsene.

SQL Server og Azure SQL støtter både forhåndsdefinerte og egendefinerte roller på databasenivå. For serverroller gjelder dette kun SQL Server og Azure SQL Managed Instance. Noen av de viktigste forhåndsdefinerte rollene i en database inkluderer db_accessadmin for opprettelse av nye brukere, db_backupoperator for backup-operasjoner, db_datareader og db_datawriter for lesing og skriving av data, samt db_securityadmin for tildeling av tillatelser til andre brukere. Disse rollene gir en strukturert måte å delegere oppgaver på, samtidig som de sikrer at tilgangen begrenses etter behov.

Det er avgjørende å forstå skillet mellom autentisering og autorisasjon i SQL-miljøer. Autentisering bekrefter hvem brukeren er, mens autorisasjon bestemmer hvilke ressurser brukeren har tilgang til og hvilke operasjoner som kan utføres. I denne sammenhengen må en sikkerhetsprinsipp både autentiseres (som login) og autoriseres (som user eller medlem av en rolle) for å fungere i et databasesystem.

Videre er det viktig å være klar over at sikkerhetsmodellen i SQL Server og Azure SQL bygger på prinsippet om minst privilegium, som innebærer at brukere og tjenester kun får de rettigheter som er nødvendige for å utføre sine oppgaver. Overdreven tildeling av tillatelser kan føre til sikkerhetsrisikoer, derfor er nøye planlegging og kontinuerlig gjennomgang av roller og rettigheter nødvendig.

Administrasjon av sikkerhetsidentiteter i et sky- og hybridmiljø stiller også krav til synkronisering mellom lokale Active Directory og Azure AD (Microsoft Entra). Det kreves ofte en forståelse av identitetsforvaltning på tvers av plattformer for å opprettholde konsistens og sikkerhet i tilgangen til SQL-tjenester.

Hvordan oppnår man sikkerhetskopiering, gjenoppretting og høy tilgjengelighet i Azure SQL?

Administrasjon av sikkerhetskopiering og gjenoppretting i moderne databaser krever mer enn bare manuelle rutiner og periodiske eksportfiler. I Azure SQL Database og Azure SQL Managed Instance er det mulig å tilpasse gjenopprettingsmodellen til behovene for tilgjengelighet og presisjon i gjenopprettingen. Ved å endre Recovery model fra SIMPLE til FULL åpnes muligheten for transaksjonsloggsikkerhetskopier, som tillater punktgjenoppretting – noe som ikke er mulig med kun fullstendige sikkerhetskopier.

Transaksjonsloggsikkerhetskopier kan tas med intervaller så korte som 30 sekunder, og gir dermed et detaljert og fleksibelt tidslinjegrunnlag for gjenoppretting. I SQL Server Management Studio (SSMS) kan administratorer navigere i dette ved hjelp av Backup Timeline-vinduet, hvor ulike former representerer forskjellige typer sikkerhetskopier. Dette muliggjør presis seleksjon for restaurering, noe som er avgjørende i scenarier hvor selv sekunders datatap er kritisk.

For Azure SQL Database og Azure SQL Managed Instance er gjenopprettingsprosessen integrert i Azure-portalen. Ved å bruke Restore-funksjonen i oversiktsbildet til databasen, åpnes en veiviser som lar administrator spesifisere et nøyaktig tidspunkt for gjenoppretting. Denne prosessen skaper en ny databaseinstans basert på valgt tidspunkt, noe som gir en sikker og kontrollerbar tilnærming til gjenoppretting uten å påvirke eksisterende data.

Når det gjelder langtidslagring, tilbyr Azure støtte for Long-Term Retention (LTR), hvor sikkerhetskopier kan beholdes i opptil 10 år. Dette er særlig relevant for organisasjoner som er bundet av juridiske eller kontraktsmessige krav. LTR-konfigurasjonen håndteres per database gjennom Backup-siden i Azure-portalen, der man kan definere hvor lenge ukentlige, månedlige og årlige sikkerhetskopier skal bevares. Evnen til å konfigurere slike policyer på individnivå for databaser er essensiell for samsvar og risikoavlastning.

T-SQL gir fortsatt et kraftig verktøy for manuell kontroll. Enkle kommandoer som BACKUP DATABASE og RESTORE DATABASE lar administratorer utføre direkte operasjoner mot både lokal disk og eksterne lagringspunkter, som Azure Blob Storage. Ved bruk av URL som lagringsdestinasjon kreves det imidlertid autentisering via en SAS-nøkkel og en egen Azure Storage-konto med Blob Storage aktivert. Dette understreker viktigheten av sikkerhetskontroll i et hybrid miljø.

Under gjenoppretting fra skybasert lagring i SSMS, må administrator autentisere seg med Azure-abonnementet og eksplisitt velge riktig lagringskonto og container. Dette krever ikke bare forståelse av Azure-infrastruktur, men også kjennskap til hvordan SQL Server på virtuelle maskiner opererer isolert fra resten av Azure-miljøet. SQL Server i en VM har ingen innebygd bevissthet om Azure-økosystemet utenfor sin egen prosess, noe som gjør det avgjørende å håndtere tilkoblinger og sikkerhetsmekanismer separat.

For høy tilgjengelighet og katastrofegjenoppretting (HA/DR) tilbyr Azure flere løsninger. Aktiv geo-replikering i Azure SQL Database gir muligheten til å opprette en sekundær replika i en annen geografisk region. Dette gir kontinuitet selv i tilfeller av alvorlige regionale feil. Prosessen konfigureres via Azure-portalen ved å bruke Create replica-veiviseren. Replikaen kan plasseres i en annen Azure-konto om nødvendig, og kan overta hovedrollen ved manuell failover.

For mer omfattende løsninger i virtuelle maskiner, gir Always On Availability Groups støtte for enterprise-nivå HA/DR. Ved å legge databaser til slike grupper, blir de tilgjengelighetsdatabaser som automatisk kan feile over ved problemer, uten datatap. Kombinert med quorum-konfigurasjon i Windows Server Failover Clustering og mulighet for log shipping, tilbyr dette et fleksibelt og redundant arkitekturvalg for virksomheter med høye krav til oppetid.

Det er essensielt å forstå at selv om verktøyene er kraftige, krever de riktig konfigurasjon, overvåkning og forståelse for å fungere optimalt. Automatiserte sikkerhetskopier alene er ikke tilstrekkelige dersom man ikke har klart definerte gjenopprettingsstrategier, testede prosedyrer og forståelse for hvordan komponentene samspiller på tvers av lokale og skybaserte miljøer.

Administratorer må ikke bare kunne bruke verktøyene, men også kjenne grensene for hva som støttes i ulike tjenester – eksempelvis at Azure SQL Managed Instance ikke støtter aktiv geo-replikering, og heller benytter automatiske failover-grupper. Slik innsikt er kritisk for å unngå feilvurderinger i design og konfigurasjon av løsningen.

Hvordan maskiner påvirker miljøet og vårt daglige liv: En undersøkelse av teknologi og natur
Hvordan bruke musikk, bevegelse og enkle teknikker for å finne ro og fokus
Hvordan Marie og Pierre Curie og Andre Bidro til Revolusjonen innen Medisin og Fysikk
Hvordan lage perfekte bakverk med sitron- og bærfylling: Teknikker og tips
Hvordan komme i gang med tegning og bygge selvtillit som kunstner