Beskytt sensitive data i SQL-database med microsoft Purview-beskyttelsespolicyer
Gjelder for:✅SQL-database i Microsoft Fabric
Microsoft Purview er en familie av datastyrings-, risiko- og samsvarsløsninger som kan hjelpe organisasjonen med å styre, beskytte og administrere hele dataeiendommen. Microsoft Purview gir deg blant annet mulighet til å merke SQL-databaseelementene med følsomhetsetiketter og definere beskyttelsespolicyer som styrer tilgang basert på følsomhetsetiketter.
Denne artikkelen forklarer hvordan Microsoft Purviews beskyttelsespolicyer fungerer sammen med Microsoft Fabric-tilgangskontroller og SQL-tilgangskontroller i SQL-databasen i Microsoft Fabric.
Hvis du vil ha generell informasjon om Microsoft Purview-funksjoner for Microsoft Fabric, inkludert SQL-database, kan du se artiklene som er oppført i relatert innhold.
Slik fungerer beskyttelsespolicyer i SQL-database
Hver beskyttelsespolicy for Microsoft Fabric er knyttet til en følsomhetsetikett. En beskyttelsespolicy styrer tilgangen til elementer som har den tilknyttede etiketten via to tilgangskontroller:
Tillat at brukere beholder lesetilgangen – Når det er aktivert, kan de angitte brukerne (eller brukerne som tilhører de angitte gruppene) beholde leseelementtillatelsen på merkede elementer hvis de angitte brukerne allerede har tillatelse. Eventuelle andre tillatelser de angitte brukerne har på elementet, fjernes. I SQL-database kreves leseelementtillatelsen for at en bruker skal kunne koble til en database. Hvis en bruker ikke er angitt i denne tilgangskontrollen, kan ikke brukeren koble til databasen.
Tillat brukere å beholde full kontroll – Når det er aktivert, kan de angitte brukerne (eller brukerne som tilhører de angitte gruppene) beholde full kontroll over det merkede elementet hvis de angitte brukerne allerede har det, eller andre tillatelser de måtte ha. For SQL-databaseelementer tillater denne kontrollen brukere å beholde skriveelementtillatelsen, noe som betyr at brukeren beholder full administrativ tilgang i databasen. Hvis en bruker ikke er angitt i denne tilgangskontrollen, fjernes skriveelementtillatelsen effektivt fra brukeren. Denne kontrollen har ingen innvirkning på brukerens opprinnelige SQL-tillatelser i databasen – hvis du vil ha mer informasjon, kan du se Eksempel 4 og Begrensninger.
Eksempler
Eksemplene i denne delen deler følgende konfigurasjon:
- En organisasjon har et Microsoft Fabric-arbeidsområde, kalt Produksjon.
- Arbeidsområdet inneholder et SQL-databaseelement, kalt Salg, som har etiketten for konfidensiell følsomhet.
- I Microsoft Purview finnes det en beskyttelsespolicy som gjelder for Microsoft Fabric. Policyen er knyttet til etiketten for konfidensiell følsomhet.
Eksempel 1
- En bruker er medlem av bidragsyterrollen for produksjonsarbeidsområdet.
- Tillat brukere å beholde tilgangskontrollen for lesetilgang er aktivert, men den inkluderer ikke brukeren.
- Tillat brukere å beholde full kontrolltilgangskontroll er deaktivert/inaktiv.
Policyen fjerner brukerens leseelementtillatelse, derfor kan ikke brukeren koble til salgsdatabasen. Brukeren kan derfor ikke lese eller få tilgang til data i databasen.
Eksempel 2
- En bruker har tillatelsen Leseelement for Salgsdatabasen.
- Brukeren er medlem av den db_owner opprinnelige databasenivårollen i databasen.
- Tillat brukere å beholde tilgangskontrollen for lesetilgang er aktivert, men den inkluderer ikke brukeren.
- Tillat brukere å beholde full kontrolltilgangskontroll er deaktivert/inaktiv.
Policyen fjerner brukerens leseelementtillatelse, derfor kan ikke brukeren koble til salgsdatabasen, uavhengig av brukerens opprinnelige SQL-tillatelser (gitt via brukerens medlemskap i db_owner rolle) i databasen. Brukeren kan derfor ikke lese eller få tilgang til data i databasen.
Eksempel 3
- En bruker er medlem av bidragsyterrollen for produksjonsarbeidsområdet.
- Brukeren har ingen opprinnelige SQL-tillatelser i databasen.
- Tillat brukere å beholde tilgangskontrollen for lesetilgang er aktivert, og den inkluderer brukeren.
- Tilgangskontrollen Tillat brukere å beholde full kontroll er aktivert, men den inkluderer ikke brukeren.
Som medlem av bidragsyterrollen har brukeren i utgangspunktet alle tillatelser i salgsdatabasen, inkludert Les, LesData og Skriv. Tillatelsen Tillat brukere å beholde tilgangskontrollen for lesetilgang i policyen gjør det mulig for brukeren å beholde lese- og ReadData-tillatelsene, men tillat brukere å beholde full kontrolltilgangskontroll fjerner brukerens skrivetillatelse. Som et resultat kan brukeren koble til databasen og lese data, men brukeren mister den administrative tilgangen til databasen, inkludert muligheten til å skrive/redigere data.
Eksempel 4
- En bruker har tillatelsen Leseelement for Salgsdatabasen.
- Brukeren er medlem av den db_owner opprinnelige databasenivårollen i databasen.
- Tillat brukere å beholde tilgangskontrollen for lesetilgang er aktivert, og den inkluderer brukeren.
- Tilgangskontrollen Tillat brukere å beholde full kontroll er aktivert, men den inkluderer ikke brukeren.
Tillat brukere å beholde tilgangskontrollen for lesetilgang i policyen gjør det mulig for brukeren å beholde lesetillatelsen. Siden brukeren i utgangspunktet ikke har full kontrolltilgang (tillatelsen Skriv element), har ikke tillatelsen Tillat brukere å beholde full kontrolltilgang på brukerens tillatelse gitt i Microsoft Fabric. Tillat brukere å beholde full kontrolltilgangskontroll påvirker ikke brukerens opprinnelige SQL-tillatelse i databasen. Som medlem av db_owner-rollen, fortsetter brukeren å ha administrativ tilgang til databasen. Se begrensninger.
Begrensninger
- Tillat brukere å beholde full kontrolltilgangskontroll i Microsoft Purview-beskyttelsespolicyer har ingen innvirkning på opprinnelige SQL-tillatelser, gitt til brukere i en database.