Hvordan kan SQL-databaser migreres og sikres i Azure-skyen med tanke på administratorkompetanse og autentisering?

Overgangen fra tradisjonelle lokale SQL-servere til skybaserte løsninger i Microsoft Azure representerer et betydelig teknologisk skifte for mange databaseadministratorer, særlig for dem som, som Ralph i eksemplet, har bred erfaring med on-premises SQL Server-miljøer, men begrenset skykompetanse. For å bevare nærhet til kjent administrasjon samtidig som man utnytter skytjenestens fordeler, bør valget av distribusjonsmodell tilpasses administratorens ekspertise og bedriftens behov.

Når det gjelder skalerbarhet, kan eksisterende skyinstanser økes i kapasitet ved «scaling up», det vil si ved å tilføre mer prosesseringskraft, minne eller lagring på samme server. Dette er en effektiv måte å møte økte krav uten behov for å distribuere flere separate instanser («scaling out» eller sharding), som krever mer kompleks administrasjon.

Selve migrasjonen fra lokal SQL Server til Azure krever bruk av dedikerte verktøy. Azure Database Migration Service (DMS) står sentralt i denne prosessen og utfører selve dataflyttingen. Verktøy som Azure Migrate og Azure Data Studio bidrar til planlegging, analyse og koordinering, men det er DMS som faktisk migrerer dataene. Å forstå denne arbeidsdelingen er essensielt for å kunne planlegge og gjennomføre en trygg og effektiv overgang til skyen.

Sikkerhet og tilgangskontroll i skyen skiller seg vesentlig fra tradisjonelle løsninger. Lokale SQL Server-installasjoner benytter ofte Active Directory Domain Services (AD DS) som autentiseringsmekanisme, med domenekontrollere som håndterer brukertilganger og rettigheter. I Azure tar Microsoft Entra ID over denne rollen. Entra ID, tidligere kjent som Azure Active Directory, tilbyr avanserte sikkerhetsmekanismer som betinget tilgang og multifaktorautentisering, noe AD DS ikke støtter. Denne utviklingen representerer en styrking av sikkerhetsnivået, spesielt for skybaserte databaser.

Når en Azure SQL Database opprettes, må administratorer velge hvilken autentiseringsmetode som skal brukes: enten Entra ID alene, SQL-autentisering alene, eller begge deler. For bedrifter med eksisterende investeringer i Microsoft 365 og Azure, vil bruk av Entra ID gi integrasjon med bedriftens øvrige sikkerhets- og tilgangsløsninger. I tillegg kan man deaktivere SQL-autentisering i eksisterende databaser for å redusere risiko.

Administrasjon av Entra ID-brukere foregår enten via Azure-portalen eller gjennom automatiserte kommandolinjeverktøy som Azure CLI og PowerShell. Dette muliggjør effektiv brukeradministrasjon i store miljøer, inkludert opprettelse, oppdatering og fjerning av identiteter.

For å kunne navigere i denne komplekse overgangen, må databaseadministratorer ikke bare forstå teknologien, men også endringene i sikkerhetsprinsipper og tilgangsstyring. Cloud-løsninger krever et skifte fra tradisjonell nettverksbasert sikkerhet til identitetsbasert sikkerhet, der brukere og tjenester autentiseres og autoriseres gjennom moderne, sikre protokoller. I tillegg er det viktig å forstå hvordan skaleringsmuligheter i skyen kan utnyttes for å møte vekstbehov uten å kompromittere ytelse eller sikkerhet.

Endelig er det viktig å huske at migrering til skyen ikke bare handler om teknologi, men også om organisasjonsendring. Opplæring av ansatte, revisjon av sikkerhetspolicyer og etablering av nye prosedyrer for overvåkning og feilsøking i skyen er nødvendige for å sikre at bedriftens data forblir beskyttet og tilgjengelige. Med en grundig forståelse av Azure SQL-miljøet og de tilhørende sikkerhetsmekanismene, kan databaseadministratorer trygt og effektivt utnytte skyens potensial.

Hvordan fungerer rettighetsstyring og roller i SQL Server og Azure SQL?

I SQL Server og SQL Managed Instance eksisterer et omfattende og hierarkisk rollebasert tilgangssystem som gjør det mulig å kontrollere brukertilgang på både server- og databasenivå. Rollene er forhåndsdefinerte og strukturert for å gi spesifikk funksjonell tilgang, fra full administrativ kontroll til svært begrenset tilgang.

På databasenivå finnes også rollen db_owner, som gir full administrativ tilgang til databasen, og public, som igjen er en standardrolle uten iboende tillatelser, men som kan tildeles ekstra rettigheter av administratorer. I motsetning til andre roller kan public-rollen tilpasses ved å tildele eller fjerne spesifikke tillatelser, noe som kan være både en fordel og en sikkerhetsrisiko.

Azure SQL Database avviker strukturelt, ettersom den ikke har en fysisk server i tradisjonell forstand. I stedet eksisterer en logisk server hovedsakelig for kompatibilitet med applikasjoner som forventer et slikt konsept. Dermed er antall tilgjengelige roller begrenset. De to sentrale rollene er dbmanager, som kan opprette databaser, og loginmanager, som kan opprette pålogginger på servernivå.

Funksjoner og prosedyrer har egne tillatelser som ALTER for å endre definisjonen, EXECUTE for å kjøre dem, og de samme innsynstillatelsene som andre objekter.

Rettigheter tildeles gjennom T-SQL med kommandoene GRANT, REVOKE og DENY. GRANT gir eksplisitt tillatelse, mens REVOKE fjerner en tidligere tildelt tillatelse uten å forhindre tilgang dersom brukeren har fått tillatelsen gjennom andre roller. DENY, derimot, overstyrer alle andre tillatelser og blokkerer eksplisitt tilgang, selv om brukeren har tilgang fra en annen kilde.

Et eksempel på å gi en bruker tilgang til å lese og oppdatere en database, er kommandoen:

sql
Copy code
GRANT SELECT, UPDATE ON DATABASE::testdb TO testuser;

For å fjerne disse tillatelsene, kan man bruke:

sql
Copy code
REVOKE SELECT, UPDATE ON DATABASE::testdb TO testuser;

Og for å eksplisitt nekte tilgang:

sql
Copy code
DENY SELECT, UPDATE ON DATABASE::testdb TO testuser;

Tillatelser er kumulative, hvilket innebærer at en bruker kan arve tilgang fra flere roller eller grupper. Men DENY overstyrer alltid GRANT, uavhengig av arvesti. Dette prinsippet er avgjørende for sikkerhetsmodellen i SQL Server og Azure SQL.