Del via

Planlægning af Power BI-implementering: Information Protection for Power BI

  • Artikel

Bemærk

Denne artikel er en del af power BI-implementeringsplanlægningsserierne. I denne serie fokuseres der primært på Power BI-oplevelsen i Microsoft Fabric. Du kan få en introduktion til serien under Planlægning af implementering af Power BI.

I denne artikel beskrives de planlægningsaktiviteter, der er relateret til implementering af beskyttelse af oplysninger i Power BI. Den er målrettet til:

  • Power BI-administratorer: De administratorer, der er ansvarlige for at styre Power BI i organisationen. Power BI-administratorer skal samarbejde med informationssikkerhed og andre relevante teams.
  • Center of Excellence, it og BI-teams: Andre, der er ansvarlige for at holde tilsyn med Power BI i organisationen. De skal muligvis samarbejde med Power BI-administratorer, informationssikkerhedsteams og andre relevante teams.

Vigtigt

Databeskyttelse og forebyggelse af datatab (DLP) er en vigtig virksomhed for hele organisationen. Dens omfang og virkning er langt større end Power BI alene. Denne type initiativ kræver finansiering, prioritering og planlægning. Forvent at involvere flere tværfunktionelle teams i din planlægnings-, brugs- og tilsynsindsats.

Mærknings- og klassificeringsaktiviteter rækker ud over Power BI og endda dataaktiver. De beslutninger, der beskrives i denne artikel, gælder for aktiver for hele organisationen, herunder filer og mails og ikke kun for Power BI. I denne artikel introduceres emner, der gælder for mærkning og klassificering generelt, da det er afgørende for, at forebyggelse af datatab lykkes i Power BI, når du træffer de rigtige organisatoriske beslutninger.

Denne artikel indeholder også en introduktion til, hvordan du definerer en struktur for følsomhedsmærkater. Teknisk set er strukturen af følsomhedsmærkaten en forudsætning for implementering af følsomhedsmærkater i Power BI. Formålet med at inkludere nogle grundlæggende oplysninger i denne artikel er at hjælpe dig med at forstå, hvad der er involveret. Det er vigtigt, at du samarbejder med it-afdelingerne om planlægning og implementering af beskyttelse af oplysninger i organisationen.

Formålet med følsomhedsmærkater

Brugen af følsomhedsmærkater fra Microsoft Purview Information Protection handler om at klassificere indhold. Tænk på en følsomhedsmærkat som et mærke, du anvender på et element, en fil, et websted eller et dataaktiv.

Der er mange fordele ved at bruge beskyttelse af oplysninger. Klassificering og mærkning af indhold hjælper organisationer med at:

  • Forstå, hvor følsomme data er placeret.
  • Spor krav til ekstern og intern overholdelse af angivne standarder.
  • Beskyt indhold mod uautoriserede brugere.
  • Oplær brugerne i, hvordan de skal håndtere data på en ansvarlig måde.
  • Implementer kontrolelementer i realtid for at reducere risikoen for datalækage.

Du kan få flere anvendelsessager til beskyttelse af oplysninger under Beskyttelse af oplysninger og DLP (Almindelige use cases).

Tip

Det hjælper at huske, at Microsoft Purview Information Protection er produktet. Følsomhedsmærkater er en bestemt funktion i det pågældende produkt.

En følsomhedsmærkat er en kort beskrivelse i klartekst. Konceptuelt kan du tænke på en følsomhedsmærkat som et mærke. Der kan kun tildeles én etiket til hvert element (f.eks. en semantisk Power BI-model – tidligere kaldet et datasæt – i Power BI-tjeneste) eller hver fil (f.eks. en Power BI Desktop-fil).

En etiket har følgende formål.

  • Klassificering: Den indeholder en klassificering til beskrivelse af følsomhedsniveauet.
  • Brugeruddannelse og -bevidsthed: Det hjælper brugerne med at forstå, hvordan de arbejder korrekt med indholdet.
  • Politikker: Den danner grundlag for anvendelse og håndhævelse af politikker og DLP.

Forudsætninger for beskyttelse af Power BI-oplysninger

På nuværende tidspunkt skulle du have fuldført de planlægningstrin på organisationsniveau, der er beskrevet i artiklen Planlægning af information på organisationsniveau. Før du fortsætter, skal du have klarhed over:

  • Aktuel tilstand: Den aktuelle tilstand for beskyttelse af oplysninger i din organisation. Du skal have en forståelse af, om følsomhedsmærkater allerede bruges til Microsoft Office-filer. I dette tilfælde er omfanget af det arbejde, der skal tilføjes Power BI, meget mindre, end hvis du for første gang giver organisationen beskyttelse af oplysninger.
  • Mål og krav : De strategiske mål for implementering af beskyttelse af oplysninger i din organisation. At forstå målene og kravene fungerer som en vejledning til din implementeringsindsats.

Hvis beskyttelse af oplysninger ikke bruges af din organisation, indeholder resten af dette afsnit oplysninger, der kan hjælpe dig med at samarbejde med andre om at introducere beskyttelse af oplysninger i din organisation.

Hvis information protection bruges aktivt i din organisation, anbefaler vi, at du bruger denne artikel til at bekræfte, at forudsætningerne er opfyldt. Hvis følsomhedsmærkater bruges aktivt, vil de fleste (eller alle) aktiviteter i udrulningsfaserne 1-4 (i næste afsnit) allerede være fuldført.

Udrulningsfaser

Vi anbefaler, at du planlægger at vedtage en gradvis udrulningsplan for implementering og test af beskyttelse af oplysninger. Målet for en gradvis udrulningsplan er at konfigurere dig selv til at lære, justere og gentage, mens du går. Fordelen er, at færre brugere påvirkes i de tidlige faser (når ændringer er mere sandsynlige), indtil beskyttelse af oplysninger til sidst udrulles til alle brugere i organisationen.

Indførelsen af beskyttelse af oplysninger er en vigtig opgave. Som beskrevet i artiklen Planlægning af information på organisationsniveau er mange af disse opgaver allerede fuldført, hvis din organisation allerede har implementeret beskyttelse af oplysninger til Microsoft Office-dokumenter.

Dette afsnit indeholder en oversigt over de faser, som vi anbefaler, at du inkluderer i din gradvise udrulningsplan. Det burde give dig en fornemmelse af, hvad du kan forvente. I resten af denne artikel beskrives andre beslutningskriterier for de vigtigste aspekter, der påvirker Power BI mest direkte.

Fase 1: Planlæg, beslut, forbered

I den første fase fokuseres der på planlægning, beslutningstagning og forberedende aktiviteter. I det meste af resten af denne artikel fokuseres der på denne første fase.

Så tidligt som muligt skal det afklares, hvor den indledende test finder sted. Dette valg påvirker, hvor du indledningsvist konfigurerer, publicerer og tester. Til den indledende test kan du bruge en ikke-produktionslejer (hvis du har adgang til en).

Tip

De fleste organisationer har adgang til én lejer, så det kan være en udfordring at udforske nye funktioner på en isoleret måde. For de organisationer, der har en separat udviklings- eller testlejer, anbefaler vi, at du bruger den til den indledende testfase. Du kan få flere oplysninger om administration af lejere, og hvordan du opretter en prøvelejer for at teste nye funktioner, under Lejerkonfiguration.

Fase 2: Konfigurer supplerende brugerressourcer

Den anden fase indeholder trin til konfiguration af ressourcer til understøttende brugere. Ressourcer omfatter din dataklassificerings- og beskyttelsespolitik og den brugerdefinerede hjælpside.

Det er vigtigt, at noget af brugerdokumentationen publiceres tidligt. Det er også vigtigt at have brugersupportteamet forberedt tidligt.

Fase 3: Konfigurer mærkater, og udgiv

I den tredje fase fokuseres der på definition af følsomhedsmærkater. Når alle beslutninger er truffet, er opsætningen ikke vanskelig eller tidskrævende. Følsomhedsmærkater konfigureres i Microsoft Purview-compliance-portal i Microsoft 365 Administration.

Fase 4: Publicer mærkatpolitik

Før en etiket kan bruges, skal du publicere den som en del af en mærkatpolitik. Mærkatpolitikker gør det muligt for visse brugere at bruge en etiket. Mærkatpolitikker publiceres i Microsoft Purview-compliance-portal i Microsoft 365 Administration.

Bemærk

Alt indtil nu er en forudsætning for at implementere beskyttelse af oplysninger i Power BI.

Fase 5: Aktivér indstillinger for Power BI-lejer

Der er flere lejerindstillinger for beskyttelse af oplysninger på Power BI-administrationsportalen. De skal aktivere beskyttelse af oplysninger i Power BI-tjeneste.

Vigtigt

Du skal angive lejerindstillingerne, når du har konfigureret og publiceret mærkaterne i Microsoft Purview-compliance-portal.

Fase 6: Indledende test

I den sjette fase udfører du indledende test for at kontrollere, at alt fungerer som forventet. I forbindelse med indledende test skal du kun publicere mærkatpolitikken for implementeringsteamet.

I denne fase skal du være sikker på at teste:

  • Microsoft Office-filer
  • Power BI-elementer i Power BI-tjeneste
  • Power BI Desktop-filer
  • Eksporterer filer fra Power BI-tjeneste
  • Andre områder, der er inkluderet i konfigurationen, f.eks. Teams-websteder eller SharePoint

Sørg for at kontrollere funktionaliteten og brugeroplevelsen ved hjælp af en webbrowser og også de mobilenheder, der ofte bruges. Opdater brugerdokumentationen i overensstemmelse hermed.

Vigtigt

Selvom kun nogle få medlemmer af teamet er autoriseret til at angive en følsomhedsmærkat, kan alle brugere se mærkater, der er tildelt indhold. Hvis du bruger din produktionslejer, undrer brugerne sig måske over, hvorfor de får vist mærkater, der er tildelt elementer i et arbejdsområde i Power BI-tjeneste. Vær klar til at understøtte og besvare brugerspørgsmål.

Fase 7: Indsaml brugerfeedback

Målet for denne fase er at få feedback fra en lille gruppe nøglebrugere. Feedbacken skal identificere forvirringsområder, huller i mærkatstrukturen eller tekniske problemer. Du kan også finde grunde til at forbedre brugerdokumentationen.

Til dette formål skal du publicere (eller publicere) mærkatpolitikken til et lille undersæt af brugere, der er villige til at give feedback.

Tip

Sørg for at indregne tilstrækkelig tid i din projektplan. I forbindelse med indstillinger for mærkater og mærkatpolitik anbefaler produktdokumentationen, at ændringerne kan træde i kraft i 24 timer . Denne gang er påkrævet for at sikre, at alle ændringer overføres til relaterede tjenester.

Fase 8: Udgiv iterativt

Implementeringsfasen er normalt en iterativ proces.

Det oprindelige mål er ofte at komme til en tilstand, hvor alt Power BI-indhold har fået tildelt en følsomhedsmærkat. Hvis du vil nå dette mål, kan du introducere en obligatorisk mærkatpolitik eller en standardnavnpolitik. Du kan også bruge API'erne til administration af information protection til at angive eller fjerne følsomhedsmærkater programmatisk.

Du kan gradvist inkludere flere grupper af brugere, indtil hele organisationen er inkluderet. Denne proces omfatter genudgivelse af hver mærkatpolitik til stadig større grupper af brugere.

I hele denne proces skal du sørge for at prioritere at levere vejledning, kommunikation og oplæring til dine brugere, så de forstår processen, og hvad der forventes af dem.

Fase 9: Overvåg, overvåg, juster, integrer

Der er andre trin, du skal udføre efter den indledende udrulning. Du bør have et primært team til at overvåge aktiviteter til beskyttelse af oplysninger og tilpasse dem over tid. Når der anvendes mærkater, kan du vurdere deres anvendelighed og identificere områder til justeringer.

Der er mange aspekter i forbindelse med beskyttelse af oplysninger om revision. Du kan få flere oplysninger under Overvågning af beskyttelse af oplysninger og forebyggelse af datatab i Power BI.

De investeringer, du foretager i forbindelse med konfiguration af beskyttelse af oplysninger, kan bruges i DLP-politikker for Power BI, som er konfigureret i Microsoft Purview-compliance-portal. Du kan få flere oplysninger, herunder en beskrivelse af DLP-funktioner, under Forebyggelse af datatab i Power BI.

Information Protection kan også bruges til at oprette politikker i Microsoft Defender for Cloud Apps. Du kan finde flere oplysninger, herunder en beskrivelse af de funktioner, du kan finde nyttige, i Defender for Cloud Apps for Power BI.

Tjekliste – Når du forbereder udrulningsfaserne for beskyttelse af oplysninger, omfatter de vigtigste beslutninger og handlinger:

  • Opret en plan for gradvis udrulning: Definer faserne for udrulningsplanen. Tydeliggør, hvad de specifikke mål er for hver fase.
  • Identificer, hvor testen skal udføres: Find ud af, hvor den indledende test kan udføres. Hvis du vil minimere indvirkningen på brugerne, skal du bruge en ikke-produktionslejer, hvis det er muligt.
  • Opret en projektplan: Opret en projektplan, der indeholder alle de vigtigste aktiviteter, den anslåede tidslinje, og hvem der skal være ansvarlig.

Struktur af følsomhedsmærkat

Strukturen af følsomhedsmærkaten er en forudsætning for implementering af følsomhedsmærkater i Power BI. Dette afsnit indeholder nogle grundlæggende oplysninger, der kan hjælpe dig med at forstå, hvad der er involveret, hvis du er involveret i oprettelse af mærkatstrukturen.

Dette afsnit er ikke en udtømmende liste over alle mulige overvejelser i forbindelse med følsomhedsmærkaten for alle mulige programmer. I stedet fokuseres der på overvejelser og aktiviteter, der direkte påvirker klassificeringen af Power BI-indhold. Sørg for, at du arbejder sammen med andre interessenter og systemadministratorer om at træffe beslutninger, der fungerer godt for alle programmer og use cases.

Grundlaget for implementering af beskyttelse af oplysninger begynder med et sæt følsomhedsmærkater. Slutmålet er at oprette et sæt følsomhedsmærkater, der er tydelige og ligetil for brugerne at arbejde med.

Den struktur for følsomhedsmærkater, der bruges i en organisation, repræsenterer en mærkat taksonomi. Det kaldes også ofte en taksonomi for dataklassificering, fordi målet er at klassificere data. Nogle gange kaldes det en skemadefinition.

Der er ikke et standardsæt eller et indbygget sæt mærkater. Hver organisation skal definere og tilpasse et sæt mærkater, så de passer til deres behov. Processen med at nå frem til det rette sæt mærkater involverer omfattende samarbejde. Det kræver gennemtænkt planlægning for at sikre, at mærkaterne opfylder mål og krav. Husk, at mærkater anvendes på mere end blot Power BI-indhold.

Tip

De fleste organisationer starter med at tildele mærkater til Microsoft Office-filer. De udvikler sig derefter til at klassificere andet indhold, f.eks. Power BI-elementer og -filer.

En etiketstruktur omfatter:

  • Navne: Navne udgør et hierarki. Hver etiket angiver følsomhedsniveauet for et element, en fil eller et dataaktiv. Vi anbefaler, at du opretter mellem tre og syv mærkater. Mærkaterne bør sjældent ændres.
  • Undermærkater: Undermærkater angiver variationer i beskyttelse eller omfang inden for en bestemt etiket. Ved at inkludere dem i forskellige mærkatpolitikker kan du områdeundermærkater til et bestemt sæt brugere eller til brugere, der er involveret i et bestemt projekt.

Tip

Selvom undermærkater giver fleksibilitet, bør de kun bruges i moderation for at opfylde kritiske krav. Oprettelse af for mange undermærkater resulterer i øget administration. De kan også overvælde brugere med for mange muligheder.

Navne udgør et hierarki, der starter med den mindst følsomme klassificering til den mest følsomme klassificering.

Nogle gange indeholder Power BI-indhold data, der strækker sig over flere mærkater. En semantisk model kan f.eks. indeholde produktlageroplysninger (generel intern brug) og salgstal for det aktuelle kvartal (begrænset). Når du vælger, hvilket mærkat der skal tildeles til den semantiske Power BI-model, skal brugerne lære at anvende den mest restriktive mærkat.

Tip

I næste afsnit beskrives politikken for dataklassificering og beskyttelse, der kan give brugerne vejledning i, hvornår de skal bruge hver mærkat.

Vigtigt

Tildeling af en etiket eller et undernavn påvirker ikke direkte adgangen til Power BI-indhold i Power BI-tjeneste. Etiketten indeholder i stedet en nyttig kategori, der kan vejlede brugerens funktionsmåde. Politikker til forebyggelse af datatab kan også være baseret på det tildelte navn. Der er dog intet, der ændrer den måde, adgangen til Power BI-indhold administreres på, undtagen når en fil krypteres. Du kan få flere oplysninger under Brug af krypteringsbeskyttelse.

Vær bevidst om de navne, du opretter, da det er en udfordring at fjerne eller slette en mærkat , når du har gjort fremskridt efter den indledende testfase. Da undernavne (eventuelt) kan bruges til et bestemt sæt brugere, kan de ændres oftere end mærkater.

Her er nogle bedste fremgangsmåder til definition af en mærkatstruktur.

  • Brug intuitive, entydige begreber: Klarhed er vigtigt for at sikre, at brugerne ved, hvad de skal vælge, når de klassificerer deres data. Det er f.eks. tvetydigt at have en tophemmelighedsmærkat og et meget fortroligt navn.
  • Opret en logisk hierarkisk rækkefølge: Rækkefølgen af mærkaterne er afgørende for, at alt fungerer godt. Husk, at den sidste etiket på listen er den mest følsomme. Den hierarkiske rækkefølge, kombineret med velvalgt udtryk, skal være logisk og intuitiv, så brugerne kan arbejde med den. Et klart hierarki gør det også nemmere at oprette og vedligeholde politikker.
  • Opret blot nogle få mærkater, der gælder på tværs af organisationen: Det vil være forvirrende at have for mange mærkater til, at brugerne kan vælge imellem. Det vil også føre til mindre nøjagtig markering af mærkater. Vi anbefaler, at du kun opretter nogle få mærkater til det oprindelige sæt.
  • Brug meningsfulde, generiske navne: Undgå at bruge branchejargon eller akronymer i navne på mærkater. I stedet for at oprette en mærkat med navnet Personligt identificerbare oplysninger skal du f.eks. bruge navne som Meget begrænset eller Meget fortroligt i stedet.
  • Brug ord, der let kan oversættes til andre sprog: For globale organisationer med handlinger i flere lande/områder er det vigtigt at vælge navneord, der ikke vil være forvirrende eller tvetydige, når de oversættes til andre sprog.

Tip

Hvis du planlægger mange mærkater, der er meget specifikke, kan du gå et skridt tilbage og revurdere din tilgang. Kompleksitet kan føre til forvirring blandt brugerne, reduceret indførelse og mindre effektiv beskyttelse af oplysninger. Vi anbefaler, at du starter med et indledende sæt mærkater (eller bruger det, du allerede har). Når du har fået mere erfaring, skal du forsigtigt udvide sættet af mærkater ved at tilføje mere specifikke navne, når det er nødvendigt.

Tjekliste – Når du planlægger din struktur for følsomhedsmærkater, omfatter vigtige beslutninger og handlinger:

  • Definer et indledende sæt følsomhedsmærkater: Opret et indledende sæt mellem tre og syv følsomhedsmærkater. Sørg for, at de har bred brug for en bred vifte af indhold. Planlæg at gentage på den indledende liste, når du afslutter dataklassificerings- og beskyttelsespolitikken.
  • Find ud af, om du har brug for undernavne: Beslut, om der er behov for at bruge undernavne til nogen af mærkaterne.
  • Bekræft lokalisering af mærkatudtryk: Hvis mærkater oversættes til andre sprog, skal de oprindelige talere bekræfte, at oversatte mærkater gengiver den tilsigtede betydning.

Område for følsomhedsmærkat

Et område for følsomhedsmærkater begrænser brugen af en etiket. Selvom du ikke kan angive Power BI direkte, kan du anvende mærkater på forskellige områder. Mulige områder omfatter:

  • Elementer (f.eks. elementer, der er publiceret til Power BI-tjeneste, filer og mails)
  • Grupper og websteder (f.eks. en Teams-kanal eller et SharePoint-websted)
  • Skematiserede dataaktiver (understøttede kilder, der er registreret i Oversigten over rensede data)

Vigtigt

Det er ikke muligt kun at definere en følsomhedsmærkat med et omfang af Power BI. Selvom der er nogle indstillinger, der gælder specifikt for Power BI, er omfanget ikke en af dem. Elementområdet bruges til Power BI-tjeneste. Følsomhedsmærkater håndteres anderledes end DLP-politikker, som er beskrevet i artiklen Forebyggelse af datatab for Power BI-planlægning , da nogle typer DLP-politikker kan defineres specifikt til Power BI. Hvis du vil bruge nedarvning af følsomhedsmærkater fra datakilder i Power BI, er der specifikke krav til mærkatområdet.

Hændelser, der er relateret til følsomhedsmærkater, registreres i aktivitetsoversigten. Logførte oplysninger om disse hændelser vil være betydeligt rigere, når omfanget er bredere. Du vil også være bedre forberedt på at beskytte data på tværs af en bredere vifte af programmer og tjenester.

Når du definerer det første sæt følsomhedsmærkater, bør du overveje at gøre det første sæt mærkater tilgængelige for alle områder. Det skyldes, at det kan blive forvirrende for brugerne, når de ser forskellige mærkater i forskellige programmer og tjenester. Med tiden kan du dog finde use cases til mere specifikke undernavne. Det er dog sikrere at starte med et ensartet og enkelt sæt indledende mærkater.

Navneområdet angives i Microsoft Purview-compliance-portal, når etiketten er konfigureret.

Tjekliste – Når der planlægges for mærkatomfanget, omfatter vigtige beslutninger og handlinger:

  • Beslut navneområdet: Diskuter, og beslut, om hver af dine indledende navne skal anvendes på alle områder.
  • Gennemse alle forudsætninger: Undersøg forudsætninger og nødvendige konfigurationstrin, der kræves for hvert område, du vil bruge.

Brug af krypteringsbeskyttelse

Der er flere muligheder for beskyttelse med en følsomhedsmærkat.

  • Kryptering: Krypteringsindstillinger vedrører filer eller mails. En Power BI Desktop-fil kan f.eks. krypteres.
  • Markeringer: Henviser til sidehoveder, sidefødder og vandmærker. Markeringer er nyttige til Microsoft Office-filer, men de vises ikke på Power BI-indhold.

Tip

Når nogen refererer til en mærkat som beskyttet, henviser de normalt til kryptering. Det kan være tilstrækkeligt, at kun mærkater på højere niveau, f.eks . Begrænset og Stærkt begrænset, krypteres.

Kryptering er en måde at kode oplysninger på kryptografisk. Kryptering har flere vigtige fordele.

  • Det er kun godkendte brugere (f.eks. interne brugere i din organisation), der kan åbne, dekryptere og læse en beskyttet fil.
  • Kryptering forbliver med en beskyttet fil, også selvom filen sendes uden for organisationen eller omdøbes.
  • Krypteringsindstillingen hentes fra det oprindelige navngivne indhold. Forestil dig, at en rapport i Power BI-tjeneste har følsomhedsmærkaten Yderst begrænset. Hvis den eksporteres til en understøttet eksportsti, forbliver etiketten intakt, og der anvendes kryptering på den eksporterede fil.

Azure RMS (Azure Rights Management Service) bruges til filbeskyttelse med kryptering. Der er nogle vigtige forudsætninger , der skal opfyldes, for at du kan bruge Azure RMS-kryptering.

Vigtigt

Der er en begrænsning, du skal overveje: En offlinebruger (uden en internetforbindelse) kan ikke åbne en krypteret Power BI Desktop-fil (eller en anden type Azure RMS-beskyttet fil). Det skyldes, at Azure RMS synkront skal bekræfte, at en bruger er autoriseret til at åbne, dekryptere og få vist filindholdet.

Krypterede mærkater håndteres forskelligt, afhængigt af hvor brugeren arbejder.

  • I Power BI-tjeneste: Krypteringsindstillingen har ikke en direkte indvirkning på brugeradgangen i Power BI-tjeneste. Power BI-standardtilladelser (f.eks. arbejdsområderoller, apptilladelser eller delingstilladelser) styrer brugeradgangen i Power BI-tjeneste. Følsomhedsmærkater påvirker ikke adgangen til indhold i Power BI-tjeneste.
  • Power BI Desktop-filer: En krypteret mærkat kan tildeles til en Power BI Desktop-fil. Etiketten bevares også, når den eksporteres fra Power BI-tjeneste. Det er kun godkendte brugere, der kan åbne, dekryptere og få vist filen.
  • Eksporterede filer: Microsoft Excel-, Microsoft PowerPoint- og PDF-filer, der eksporteres fra Power BI-tjeneste bevare deres følsomhedsmærkat, herunder krypteringsbeskyttelse. I forbindelse med understøttede filformater er det kun godkendte brugere, der kan åbne, dekryptere og få vist filen.

Vigtigt

Det er vigtigt, at brugerne forstår forskellen mellem Power BI-tjeneste og filer, som let forveksles. Vi anbefaler, at du angiver et ofte stillede spørgsmål sammen med eksempler for at hjælpe brugerne med at forstå forskellene.

Hvis du vil åbne en beskyttet Power BI Desktop-fil eller en eksporteret fil, skal en bruger opfylde følgende kriterier.

  • Internetforbindelse: Brugeren skal have forbindelse til internettet. Der kræves en aktiv internetforbindelse for at kommunikere med Azure RMS.
  • RMS-tilladelser: Brugeren skal have RMS-tilladelser, som er defineret i etiketten (i stedet for i mærkatpolitikken). RMS-tilladelser gør det muligt for godkendte brugere at dekryptere, åbne og få vist understøttede filformater.
  • Tilladt bruger: Brugere eller grupper skal angives i mærkatpolitikken. Tildeling af godkendte brugere er normalt kun påkrævet for indholdsoprettere og -ejere, så de kan anvende mærkater. Men når du bruger krypteringsbeskyttelse, er der et andet krav. Hver bruger, der skal åbne en beskyttet fil, skal angives i mærkatpolitikken. Dette krav betyder, at der kan være behov for licenser til beskyttelse af oplysninger for flere brugere.

Tip

Lejerindstillingen Tillad, at arbejdsområdeadministratorer tilsidesætter automatisk anvendte følsomhedsmærkater , gør det muligt for arbejdsområdeadministratorer at ændre en mærkat, der blev anvendt automatisk, også selvom beskyttelse (kryptering) er aktiveret for mærkaten. Denne funktion er især nyttig, når en mærkat automatisk blev tildelt eller nedarvet, men arbejdsområdeadministratoren ikke er en godkendt bruger.

Beskyttelse af mærkater angives i Microsoft Purview-compliance-portal, når du konfigurerer etiketten.

Tjekliste – Når du planlægger brugen af mærkatkryptering, omfatter vigtige beslutninger og handlinger:

  • Beslut, hvilke mærkater der skal krypteres: For hver følsomhedsmærkat skal du beslutte, om den skal krypteres (beskyttes). Overvej nøje de begrænsninger, der er involveret.
  • Identificer RMS-tilladelserne for hver etiket: Find ud af, hvilke brugertilladelser der skal være til at få adgang til og interagere med krypterede filer. Opret en tilknytning af brugere og grupper for hver følsomhedsmærkat for at hjælpe med planlægningsprocessen.
  • Gennemse og adresse RMS-krypteringsforudsætningerne: Sørg for, at de tekniske forudsætninger for at bruge Azure RMS-kryptering er opfyldt.
  • Planlæg at udføre grundige test af kryptering: På grund af forskellene mellem Office-filer og Power BI-filer skal du sikre, at du forpligter dig til en grundig testfase.
  • Medtag i brugerdokumentation og oplæring: Sørg for, at du inkluderer vejledning i din dokumentation og oplæring i, hvad brugerne skal forvente for filer, der er tildelt en følsomhedsmærkat, der er krypteret.
  • Udfør videnoverførsel med support: Lav specifikke planer for at gennemføre sessioner med overførsel af viden med supportteamet. På grund af krypteringens kompleksitet får de sandsynligvis spørgsmål fra brugerne.

Nedarvning af mærkater fra datakilder

Når du importerer data fra understøttede datakilder (f.eks. Azure Synapse Analytics, Azure SQL Database eller en Excel-fil), kan en semantisk Power BI-model eventuelt arve den følsomhedsmærkat, der er anvendt på kildedataene. Nedarvning hjælper med at:

  • Hæv ensartet mærkning.
  • Reducer brugerindsatsen ved tildeling af mærkater.
  • Reducer risikoen for, at brugere får adgang til og deler følsomme data med uautoriserede brugere, fordi de ikke er mærket.

Tip

Der er to typer nedarvning for følsomhedsmærkater. Nedarvning af downstream-elementer refererer til downstreamelementer (f.eks. rapporter), der automatisk nedarver en mærkat fra den semantiske Power BI-model. I dette afsnit fokuseres der dog på nedarvning af _upstream. Upstream-nedarvning refererer til en semantisk Power BI-model, der nedarver en etiket fra en datakilde, der er upstream fra den semantiske model.

Overvej et eksempel, hvor organisationens arbejdsdefinition for følsomhedsmærkaten for Stærkt begrænset indeholder økonomiske kontonumre. Da økonomiske kontonumre er gemt i en Azure SQL Database, er følsomhedsmærkaten Yderst begrænset tildelt til den pågældende kilde. Når data fra Azure SQL Database importeres til Power BI, er det hensigten, at den semantiske model nedarver mærkaten.

Du kan tildele følsomhedsmærkater til en understøttet datakilde på forskellige måder.

  • Dataregistrering og -klassificering: Du kan scanne en understøttet database for at identificere kolonner, der kan indeholde følsomme data. På baggrund af scanningsresultaterne kan du anvende nogle eller alle mærkatanbefalinger. Data discovery &classification understøttes for databaser som Azure SQL Database, Azure SQL Managed Instance og Azure Synapse Analytics. SQL Data Discovery &Classification understøttes for SQL Server-databaser i det lokale miljø.
  • Manuelle tildelinger: Du kan tildele en følsomhedsmærkat til en Excel-fil. Du kan også manuelt tildele mærkater til databasekolonner i Azure SQL Database eller SQL Server.
  • Automatisk mærkning i Microsoft Purview: Følsomhedsmærkater kan anvendes på understøttede datakilder, der er registreret som aktiver i Microsoft Purview Data Map.

Advarsel!

Oplysningerne om, hvordan du tildeler følsomhedsmærkater til en datakilde, er uden for denne artikels område. De tekniske funktioner udvikler sig med hensyn til, hvad der understøttes i forbindelse med nedarvning i Power BI. Vi anbefaler, at du udfører en teknisk blåstempling for at bekræfte dine mål, brugervenlighed, og om funktionerne opfylder dine krav.

Nedarvning sker kun, når du aktiverer lejerindstillingen Anvend følsomhedsmærkater fra datakilder på deres data i Power BI. Du kan få flere oplysninger om lejerindstillinger i afsnittet Indstillinger for Power BI-lejer senere i denne artikel.

Tip

Du skal blive fortrolig med funktionsmåden for nedarvning. Sørg for at inkludere forskellige omstændigheder i din testplan.

Tjekliste – Når du planlægger nedarvning af mærkater fra datakilder, omfatter vigtige beslutninger og handlinger:

  • Beslut, om Power BI skal nedarve mærkater fra datakilder: Beslut, om Power BI skal arve disse mærkater. Planlæg at aktivere lejerindstillingen for at tillade denne funktion.
  • Gennemse tekniske forudsætninger: Find ud af, om du skal udføre ekstra trin for at tildele følsomhedsmærkater til datakilder.
  • Funktioner til nedarvning af testmærkater: Fuldfør en teknisk blåstempling for at teste, hvordan nedarvning fungerer. Kontrollér, at funktionen fungerer som forventet under forskellige omstændigheder.
  • Medtag i brugerdokumentationen: Sørg for, at oplysninger om nedarvning af mærkater føjes til den vejledning, der gives til brugerne. Medtag realistiske eksempler i brugerdokumentationen.

Politikker for publicerede mærkater

Når du har defineret en følsomhedsmærkat, kan mærkaten føjes til en eller flere mærkatpolitikker. En mærkatpolitik er den måde, du publicerer etiketten på, så den kan bruges. Den definerer, hvilke mærkater der kan bruges af hvilket sæt godkendte brugere. Der er også andre indstillinger, f.eks. standardmærkaten og den obligatoriske etiket.

Det kan være nyttigt at bruge flere mærkatpolitikker, når du har brug for at målrette mod forskellige brugersæt. Du kan definere en følsomhedsmærkat én gang og derefter inkludere i en eller flere mærkatpolitikker.

Tip

En følsomhedsmærkat er ikke tilgængelig til brug, før en mærkatpolitik, der indeholder mærkaten, publiceres i Microsoft Purview-compliance-portal.

Godkendte brugere og grupper

Når du opretter en mærkatpolitik, skal en eller flere brugere eller grupper vælges. Mærkatpolitikken bestemmer, hvilke brugere der kan bruge mærkaten. Det giver brugerne mulighed for at tildele dette navn til bestemt indhold, f.eks. en Power BI Desktop-fil, en Excel-fil eller et element, der er publiceret til Power BI-tjeneste.

Vi anbefaler, at du holder de godkendte brugere og grupper så enkle som muligt. En god tommelfingerregel er, at de primære mærkater publiceres for alle brugere. Nogle gange er det hensigtsmæssigt, at et undernavn tildeles eller begrænses til et undersæt af brugere.

Vi anbefaler, at du tildeler grupper i stedet for enkeltpersoner, når det er muligt. Brugen af grupper forenkler administrationen af politikken og reducerer, hvor ofte den skal publiceres igen,

Advarsel!

Godkendte brugere og grupper for et mærkat er forskellige fra de brugere, der er tildelt Azure RMS for et beskyttet (krypteret) navn. Hvis en bruger har problemer med at åbne en krypteret fil, skal du undersøge krypteringstilladelserne for bestemte brugere og grupper (som er konfigureret i etiketkonfigurationen i stedet for i mærkatpolitikken). I de fleste situationer anbefaler vi, at du tildeler de samme brugere til begge. Denne konsistens vil undgå forvirring og reducere supportanmodninger.

Godkendte brugere og grupper angives i Microsoft Purview-compliance-portal, når mærkatpolitikken udgives.

Tjekliste – Når du planlægger godkendte brugere og grupper i din mærkatpolitik, omfatter vigtige beslutninger og handlinger:

  • Find ud af, hvilke mærkater der gælder for alle brugere: Diskuter, og beslut, hvilke følsomhedsmærkater der skal være tilgængelige for alle brugere.
  • Find ud af, hvilke undernavne der gælder for et undersæt af brugere: Diskuter, og beslut, om der er nogen undernavne, der kun skal være tilgængelige for et bestemt sæt brugere eller grupper.
  • Identificer, om der er behov for nye grupper: Find ud af, om der skal oprettes nye Microsoft Entra ID-grupper (tidligere kaldet Azure Active Directory) for at understøtte de godkendte brugere og grupper.
  • Opret et planlægningsdokument: Hvis tilknytningen af godkendte brugere til følsomhedsmærkater er kompliceret, skal du oprette en tilknytning af brugere og grupper for hver mærkatpolitik.

Standardetiket til Power BI-indhold

Når du opretter en mærkatpolitik, kan du vælge et standardnavn. Etiketten Generelt internt brug kan f.eks. angives som standardetiketten. Denne indstilling påvirker nye Power BI-elementer, der er oprettet i enten Power BI Desktop eller Power BI-tjeneste.

Du kan konfigurere standardnavnet i mærkatpolitikken specielt til Power BI-indhold, som er adskilt fra andre elementer. De fleste beslutninger og indstillinger for beskyttelse af oplysninger gælder mere bredt. Standardindstillingen for mærkaten (og den obligatoriske etiketindstilling, der beskrives næste), gælder dog kun for Power BI.

Tip

Selvom du kan angive forskellige standardnavne (for Power BI og ikke-Power BI-indhold), skal du overveje, om det er den bedste løsning for brugerne.

Det er vigtigt at forstå, at en ny standardetiketpolitik gælder for indhold, der er oprettet eller redigeret, når mærkatpolitikken er publiceret. Standardnavnet tildeles ikke med tilbagevirkende kraft til eksisterende indhold. Din Power BI-administrator kan bruge API'erne til beskyttelse af oplysninger til at angive følsomhedsmærkater samlet for at sikre, at eksisterende indhold er tildelt en standardfølsomhedsmærkat.

Standardindstillingerne for navne angives i Microsoft Purview-compliance-portal, når mærkatpolitikken udgives.

Tjekliste – Når du planlægger, om der skal anvendes et standardnavn til Power BI-indhold, omfatter vigtige beslutninger og handlinger:

  • Beslut, om der skal angives et standardnavn: Diskuter, og beslut, om en standardmærkat er relevant. Hvis det er tilfældet, skal du bestemme, hvilken mærkat der er bedst egnet som standard.
  • Medtag i brugerdokumentationen: Sørg om nødvendigt for, at oplysninger om standardmærkaten er nævnt i vejledningen til brugerne. Målet er, at brugerne skal forstå, hvordan de afgør, om standardnavnet er relevant, eller om det skal ændres.

Obligatorisk mærkning af Power BI-indhold

Dataklassificering er et almindeligt lovmæssigt krav. Hvis du vil opfylde dette krav, kan du vælge at kræve, at brugerne skal mærke alt Power BI-indhold. Dette obligatoriske mærkningskrav træder i kraft, når brugerne opretter eller redigerer Power BI-indhold.

Du kan vælge at implementere obligatoriske mærkater, standardmærkater (beskrevet i forrige afsnit) eller begge dele. Du bør overveje følgende punkter.

  • En obligatorisk mærkatpolitik sikrer, at mærkaten ikke er tom
  • En obligatorisk mærkatpolitik kræver, at brugerne vælger, hvad mærkaten skal være
  • En obligatorisk mærkatpolitik forhindrer brugerne i helt at fjerne en mærkat
  • En standardnavnpolitik er mindre påtrængende for brugerne, fordi den ikke kræver, at de udfører handlinger
  • En standardnavnpolitik kan resultere i indhold, der er forkert mærket, da en bruger ikke udtrykkeligt har foretaget valget
  • Aktivering af både en standardnavnpolitik og en obligatorisk mærkatpolitik kan give yderligere fordele

Tip

Hvis du vælger at implementere obligatoriske mærkater, anbefaler vi, at du også implementerer standardnavne.

Du kan konfigurere den obligatoriske mærkatpolitik specifikt til Power BI-indhold. De fleste indstillinger for beskyttelse af oplysninger gælder mere bredt. Den obligatoriske etiketindstilling (og standardindstillingen for mærkater) gælder dog specifikt for Power BI.

Tip

En obligatorisk mærkatpolitik gælder ikke for tjenesteprincipaler eller API'er.

De obligatoriske navneindstillinger angives i Microsoft Purview-compliance-portal, når mærkatpolitikken udgives.

Tjekliste – Når du planlægger, om obligatorisk mærkning af Power BI-indhold skal være påkrævet, omfatter vigtige beslutninger og handlinger:

  • Beslut, om mærkater skal være obligatoriske: Diskuter og beslut, om obligatoriske mærkater er nødvendige af hensyn til overholdelse af angivne standarder.
  • Medtag i brugerdokumentationen: Hvis det er nødvendigt, skal du sørge for, at oplysninger om obligatoriske mærkater føjes til den vejledning, der gives til brugerne. Målet er, at brugerne skal forstå, hvad de kan forvente.

Licenskrav

Der skal være specifikke licenser på plads, før du kan arbejde med følsomhedsmærkater .

Der kræves en Microsoft Purview Information Protection-licens til:

  • Administration istratorer: De administratorer, der skal konfigurere, administrere og kontrollere mærkater.
  • Brugere: De indholdsforfattere og ejere, der skal være ansvarlige for at anvende mærkater på indhold. Brugerne inkluderer også dem, der har brug for at dekryptere, åbne og få vist beskyttede (krypterede) filer.

Du har muligvis allerede disse funktioner, fordi de er inkluderet i licenspakker, f.eks . Microsoft 365 E5. Du kan også købe Microsoft 365 E5 Overholdelse egenskaber som en separat licens.

Der kræves også en Power BI Pro- eller Premium pr. bruger-licens til brugere, der anvender og administrerer følsomhedsmærkater i Power BI-tjeneste eller Power BI Desktop.

Tip

Hvis du har brug for oplysninger om licenskrav, skal du tale med dit Microsoft-kontoteam. Vær opmærksom på, at Microsoft 365 E5 Overholdelse-licensen indeholder yderligere funktioner, der ikke er omfattet af denne artikel.

Tjekliste – Når du evaluerer licenskrav til følsomhedsmærkater, omfatter vigtige beslutninger og handlinger:

  • Gennemse krav til produktlicenser: Kontrollér, at du gennemser alle licenskravene.
  • Gennemse krav til brugerlicenser: Kontrollér, at alle brugere, du forventer at tildele mærkater, har Power BI Pro- eller Premium pr. bruger-licenser.
  • Køb yderligere licenser: Hvis det er relevant, skal du købe flere licenser for at låse op for den funktionalitet, du vil bruge.
  • Tildel licenser: Tildel en licens til hver bruger, der tildeler, opdaterer eller administrerer følsomhedsmærkater. Tildel en licens til hver bruger, der interagerer med krypterede filer.

Indstillinger for Power BI-lejer

Der er flere indstillinger for Power BI-lejere, der er relateret til beskyttelse af oplysninger.

Vigtigt

Indstillingerne for Power BI-lejeren til beskyttelse af oplysninger skal først angives, når alle forudsætninger er opfyldt. Mærkaterne og mærkatpolitikkerne skal konfigureres og publiceres i Microsoft Purview-compliance-portal. Indtil nu er du stadig i beslutningsprocessen. Før du angiver lejerindstillingerne, skal du først bestemme en proces for, hvordan du tester funktionaliteten med et undersæt af brugere. Derefter kan du beslutte, hvordan du foretager en gradvis udrulning.

Brugere, der kan anvende mærkater

Du skal beslutte, hvem der skal have tilladelse til at anvende følsomhedsmærkater på Power BI-indhold. Denne beslutning bestemmer, hvordan du angiver indstillingen Tillad brugere at anvende følsomhedsmærkater for indholdslejer.

Det er typisk indholdsforfatteren eller -ejeren, der tildeler mærkaten under deres normale arbejdsproces. Den mest enkle fremgangsmåde er at aktivere denne lejerindstilling, som gør det muligt for alle Power BI-brugere at anvende mærkater. I dette tilfælde bestemmer standardarbejdsområderoller, hvem der kan redigere elementer i Power BI-tjeneste (herunder anvendelse af en mærkat). Du kan bruge aktivitetsloggen til at spore, hvornår en bruger tildeler eller ændrer en mærkat.

Navne fra datakilder

Du skal beslutte, om følsomhedsmærkater skal nedarves fra understøttede datakilder, der er upstream fra Power BI. Hvis kolonner i en Azure SQL Database f.eks. er defineret med følsomhedsmærkaten Yderst begrænset , arver en semantisk Power BI-model, der importerer data fra den pågældende kilde, dette navn.

Hvis du beslutter at aktivere nedarvning fra upstream-datakilder, skal du angive lejerindstillingen Anvend følsomhedsmærkater fra datakilder på deres data i Power BI. Vi anbefaler, at du planlægger at aktivere nedarvning af datakildenavne for at fremme ensartethed og reducere indsatsen.

Mærkater til downstream-indhold

Du skal beslutte, om følsomhedsmærkater skal nedarves af downstreamindhold. Hvis en semantisk Power BI-model f.eks. har en følsomhedsmærkat med høj begrænsning, arver alle downstreamrapporter denne mærkat fra den semantiske model.

Hvis du beslutter at aktivere nedarvning efter downstream-indhold, skal du angive indstillingen Anvend automatisk følsomhedsmærkater på downstreamindholdslejer. Vi anbefaler, at du planlægger at aktivere nedarvning efter downstreamindhold for at fremme ensartethed og reducere indsatsen.

Arbejdsområdeadministrator tilsidesætter

Denne indstilling gælder for etiketter, der er anvendt automatisk (f.eks. når standardnavne anvendes, eller når etiketter nedarves automatisk). Når en etiket har beskyttelsesindstillinger, tillader Power BI kun godkendte brugere at ændre mærkaten. Denne indstilling gør det muligt for arbejdsområdeadministratorer at ændre en mærkat, der blev anvendt automatisk, selvom der er beskyttelsesindstillinger på etiketten.

Hvis du beslutter at tillade navneopdateringer, skal du angive lejerindstillingen Tillad, at arbejdsområdeadministratorer tilsidesætter automatisk anvendte følsomhedsmærkater. Denne indstilling gælder for hele organisationen (ikke individuelle grupper). Det gør det muligt for arbejdsområdeadministratorer at ændre navne, der blev anvendt automatisk.

Vi anbefaler, at du overvejer at give administratorer af Power BI-arbejdsområder tilladelse til at opdatere mærkater. Du kan bruge aktivitetsloggen til at spore, hvornår de tildeler eller ændrer en etiket.

Tillad ikke deling af beskyttet indhold

Du skal beslutte, om beskyttet (krypteret) indhold kan deles med alle i din organisation.

Hvis du beslutter dig for ikke at tillade deling af beskyttet indhold, skal du angive lejerindstillingen Begræns indhold med beskyttede mærkater til at blive delt via link til alle i organisationen. Denne indstilling gælder for hele organisationen (ikke individuelle grupper).

Vi anbefaler på det kraftigste, at du planlægger at aktivere denne lejerindstilling for ikke at tillade deling af beskyttet indhold. Når funktionen er aktiveret, er det ikke tilladt at dele handlinger med hele organisationen for mere følsomt indhold (defineret af de mærkater, der har defineret kryptering). Når du aktiverer denne indstilling, reducerer du risikoen for datalækage.

Vigtigt

Der er en lignende lejerindstilling med navnet Tillad links, der kan deles, for at give adgang til alle i din organisation. Selvom det har et lignende navn, er dets formål anderledes. Den definerer, hvilke grupper der kan oprette et delingslink for hele organisationen, uanset følsomhedsmærkaten. I de fleste tilfælde anbefaler vi, at denne funktion begrænses i din organisation. Du kan få flere oplysninger i artiklen Rapportér planlægning af forbrugersikkerhed.

Understøttede eksportfiltyper

På Power BI-administrationsportalen er der mange indstillinger for eksport og deling af lejere. I de fleste tilfælde anbefaler vi, at muligheden for at eksportere data er tilgængelig for alle (eller de fleste) brugere for ikke at begrænse brugernes produktivitet.

Stærkt regulerede brancher kan dog have et krav om at begrænse eksporten, når beskyttelse af oplysninger ikke kan gennemtvinges for outputformatet. En følsomhedsmærkat, der anvendes i Power BI-tjeneste følger indholdet, når den eksporteres til en understøttet filsti. Den indeholder Excel-, PowerPoint-, PDF- og Power BI Desktop-filer. Da følsomhedsmærkaten forbliver sammen med den eksporterede fil, bevares beskyttelsesfordelene (kryptering, der forhindrer uautoriserede brugere i at åbne filen) for disse understøttede filformater.

Advarsel!

Når du eksporterer fra Power BI Desktop til en PDF-fil, bevares beskyttelsen ikke for den eksporterede fil. Vi anbefaler, at du uddanner dine indholdsforfattere til at eksportere fra Power BI-tjeneste for at opnå maksimal beskyttelse af oplysninger.

Ikke alle eksportformater understøtter beskyttelse af oplysninger. Formater, der ikke understøttes, f.eks. .csv, .xml, .mhtml eller .png filer (tilgængelige, når api'en ExportToFile bruges) kan være deaktiveret i indstillingerne for Power BI-lejeren.

Tip

Vi anbefaler, at du kun begrænser eksport af egenskaber, når du skal opfylde specifikke lovmæssige krav. I typiske scenarier anbefaler vi, at du bruger Power BI-aktivitetsloggen til at identificere, hvilke brugere der udfører eksporter. Du kan derefter lære disse brugere om mere effektive og sikre alternativer.

Tjekliste – Når du planlægger, hvordan lejerindstillinger konfigureres på Power BI-administrationsportalen, omfatter vigtige beslutninger og handlinger:

  • Beslut, hvilke brugere der kan anvende følsomhedsmærkater: Diskuter og beslut, om følsomhedsmærkater kan tildeles til Power BI-indhold af alle brugere (baseret på Power BI-standardsikkerhed) eller kun af visse grupper af brugere.
  • Bestem, om mærkater skal nedarves fra upstream-datakilder: Diskuter og beslut, om mærkater fra datakilder automatisk skal anvendes på Power BI-indhold, der bruger datakilden.
  • Bestem, om etiketter skal nedarves af downstream-elementer: Diskuter og beslut, om etiketter, der er tildelt til eksisterende semantiske Power BI-modeller, automatisk skal anvendes på relateret indhold.
  • Beslut, om administratorer af Power BI-arbejdsområder kan tilsidesætte mærkater: Diskuter, og beslut, om det er passende for arbejdsområdeadministratorer at ændre beskyttede mærkater, der automatisk er tildelt.
  • Bestem, om beskyttet indhold kan deles med hele organisationen: Diskuter, og beslut, om delingslinks for "personer i din organisation" kan oprettes, når der er tildelt et beskyttet (krypteret) navn til et element i Power BI-tjeneste.
  • Beslut, hvilke eksportformater der er aktiveret: Identificer lovmæssige krav, der påvirker, hvilke eksportformater der er tilgængelige. Diskuter og beslut, om brugerne skal kunne bruge alle eksportformater i Power BI-tjeneste. Find ud af, om visse formater skal deaktiveres i lejerindstillingerne, når eksportformatet ikke understøtter beskyttelse af oplysninger.

Politik for dataklassificering og beskyttelse

Det er nødvendigt at konfigurere din etiketstruktur og publicere dine mærkatpolitikker. Der er dog mere at gøre for at hjælpe din organisation med at klassificere og beskytte data. Det er vigtigt, at du giver brugerne vejledning om, hvad der kan og ikke kan gøres med indhold, der er tildelt til en bestemt etiket. Det er her, du kan finde en politik for dataklassificering og beskyttelse er nyttig. Du kan betragte det som dine retningslinjer for mærkater.

Bemærk

En politik for dataklassificering og beskyttelse er en intern styringspolitik. Du kan vælge at kalde det noget andet. Det vigtigste er, at det er dokumentation, som du opretter og leverer til dine brugere, så de ved , hvordan de bruger mærkaterne effektivt. Da mærkatpolitikken er en bestemt side i Microsoft Purview-compliance-portal, kan du prøve at undgå at kalde din interne styringspolitik med det samme navn.

Vi anbefaler, at du iterativt opretter din politik for dataklassificering og beskyttelse, mens du er i beslutningsprocessen. Det betyder, at alt er klart defineret, når det er tid til at konfigurere følsomhedsmærkater.

Her er nogle af de vigtigste oplysninger, som du kan inkludere i din dataklassificerings- og beskyttelsespolitik.

  • Beskrivelse af etiketten: Ud over navnet på etiketten skal du angive en komplet beskrivelse af etiketten. Beskrivelsen skal være klar, men kort. Her er nogle eksempelbeskrivelser:
    • Generel intern brug – til private, interne forretningsdata
    • Begrænset – for følsomme forretningsdata, der kan forårsage skade, hvis de kompromitteres eller er underlagt lovmæssige krav eller overholdelseskrav
  • Eksempler: Angiv eksempler, der kan hjælpe med at forklare, hvornår mærkaten skal bruges. Her er nogle eksempler:
    • Generel intern brug – til de fleste interne kommunikationer, ikke-følsomme supportdata, undersøgelsessvar, anmeldelser, bedømmelser og upræcise placeringsdata
    • Begrænset – for personidentificerbare oplysninger ,f.eks. navn, adresse, telefon, mail, government ID-nummer, race eller etnicitet. Omfatter leverandør- og partnerkontrakter, ikke-offentlige økonomiske data, medarbejder- og HR-data. Omfatter også beskyttede oplysninger, immaterielle rettigheder og præcise placeringsdata.
  • Påkrævet mærkat: Beskriver, om tildeling af en mærkat er obligatorisk for alt nyt og ændret indhold.
  • Standardnavn: Beskriver, om dette navn er en standardetiket, der automatisk anvendes på nyt indhold.
  • Adgangsbegrænsninger: Yderligere oplysninger, der tydeliggør, om interne og/eller eksterne brugere har tilladelse til at se indhold, der er tildelt til denne mærkat. Her er nogle eksempler:
    • Alle brugere, herunder interne brugere, eksterne brugere og tredjeparter med aktive NDA'er (Non-Disclosure Agreements) på plads, kan få adgang til disse oplysninger.
    • Interne brugere kan kun få adgang til disse oplysninger. Ingen partnere, leverandører, entreprenører eller tredjeparter, uanset NDA eller fortrolighedsaftalestatus.
    • Intern adgang til oplysninger er baseret på jobrollegodkendelse.
  • Krypteringskrav: Beskriver, om data skal krypteres under inaktive data og under overførsel. Disse oplysninger svarer til, hvordan følsomhedsmærkaten er konfigureret, og påvirker de beskyttelsespolitikker, der kan implementeres til filkryptering (RMS).
  • Tilladte downloads og/eller offlineadgang: Beskriver, om offlineadgang er tilladt. Den kan også definere, om downloads er tilladt til organisatoriske eller personlige enheder.
  • Sådan anmoder du om en undtagelse: Beskriver, om en bruger kan anmode om en undtagelse til standardpolitikken, og hvordan det kan gøres.
  • Overvågningsfrekvens: Angiver hyppigheden af overholdelsesgennemgange. Højere følsomme mærkater bør omfatte hyppigere og grundige revisionsprocesser.
  • Andre metadata: En datapolitik kræver flere metadata, f.eks. politikejer, godkender og ikrafttrædelsesdato.

Tip

Når du opretter din politik for dataklassificering og beskyttelse, skal du fokusere på at gøre den til en enkel reference for brugerne. Det skal være så kort og klart som muligt. Hvis det er for komplekst, vil brugerne ikke altid bruge tid på at forstå det.

En måde at automatisere implementeringen af en politik, f.eks. dataklassificerings- og beskyttelsespolitikken, er med Vilkår for anvendelse af Microsoft Entra. Når der er konfigureret en vilkår for anvendelsespolitik, skal brugerne bekræfte politikken, før de får tilladelse til at besøge Power BI-tjeneste for første gang. Det er også muligt at bede dem om at blive enige igen på tilbagevendende basis, f.eks. hver 12. måned.

Tjekliste – Når du planlægger den interne politik for at styre forventningerne til brug af følsomhedsmærkater, omfatter vigtige beslutninger og handlinger:

  • Opret en politik for dataklassificering og beskyttelse: Opret et centraliseret politikdokument for hver følsomhedsmærkat i din struktur. Dette dokument skal definere, hvad der kan eller ikke kan gøres med indhold, der er tildelt hver etiket.
  • Opnå enighed om dataklassificerings- og beskyttelsespolitikken: Sørg for, at alle nødvendige personer i det team, du samlede, har accepteret bestemmelserne.
  • Overvej, hvordan du håndterer undtagelser fra politikken: Stærkt decentraliserede organisationer bør overveje, om der kan opstå undtagelser. Selvom det er at foretrække at have en standardiseret politik for dataklassificering og beskyttelse, skal du beslutte, hvordan du vil håndtere undtagelser, når der foretages nye anmodninger.
  • Overvej, hvor du kan finde din interne politik: Overvej, hvor dataklassificerings- og beskyttelsespolitikken skal publiceres. Sørg for, at alle brugere nemt kan få adgang til den. Planlæg at medtage den på den brugerdefinerede Hjælp-side, når du publicerer mærkatpolitikken.

Brugerdokumentation og oplæring

Før du udruller funktioner til beskyttelse af oplysninger, anbefaler vi, at du opretter og udgiver vejledningsdokumentation til dine brugere. Formålet med dokumentationen er at opnå en problemfri brugeroplevelse. Forberedelse af vejledningen til dine brugere hjælper dig også med at sikre, at du har overvejet alt.

Du kan publicere vejledningen som en del af følsomhedsmærkatens brugerdefinerede hjælpside. En SharePoint-side eller en wikiside på din centraliserede portal kan fungere godt, fordi det er nemt at vedligeholde. Et dokument, der er uploadet til et delt bibliotek eller et Teams-websted, er også en god fremgangsmåde. URL-adressen til den brugerdefinerede Hjælp-side er angivet i Microsoft Purview-compliance-portal, når du publicerer mærkatpolitikken.

Tip

Den brugerdefinerede hjælpside er en vigtig ressource. Links til det er gjort tilgængelige i forskellige programmer og tjenester.

Brugerdokumentationen skal indeholde den dataklassificerings- og beskyttelsespolitik , der er beskrevet tidligere. Denne interne politik er målrettet alle brugere. Interesserede brugere omfatter indholdsforfattere og forbrugere, der har brug for at forstå konsekvenserne for mærkater, der er tildelt af andre brugere.

Ud over politikken for dataklassificering og beskyttelse anbefaler vi, at du forbereder en vejledning til dine indholdsoprettere og -ejere om:

  • Visning af mærkater: Oplysninger om, hvad hver etiket betyder. Korreler hvert navn med din dataklassificerings- og beskyttelsespolitik.
  • Tildeling af mærkater: Vejledning i, hvordan du tildeler og administrerer mærkater. Medtag oplysninger, de skal vide, f.eks. obligatoriske mærkater, standardmærkater, og hvordan nedarvning af mærkater fungerer.
  • Arbejdsproces: Forslag til, hvordan du tildeler og gennemser mærkater som en del af deres normale arbejdsproces. Mærkater kan tildeles i Power BI Desktop , så snart udviklingen starter, hvilket beskytter den oprindelige Power BI Desktop-fil under udviklingsprocessen.
  • Situationsmeddelelser: Opmærksomhed om systemoprettede meddelelser, som brugerne kan modtage. Et SharePoint-websted er f.eks. tildelt til en bestemt følsomhedsmærkat, men en individuel fil er blevet tildelt en mere følsom (højere) mærkat. Den bruger, der har tildelt den højere etiket, modtager en mailmeddelelse om, at den mærkat, der er tildelt filen, ikke er kompatibel med det websted, hvor den er gemt.

Medtag oplysninger om, hvem brugerne skal kontakte, hvis de har spørgsmål eller tekniske problemer. Da beskyttelse af oplysninger er et projekt i hele organisationen, ydes der ofte support af it-afdelingerne.

Ofte stillede spørgsmål og eksempler er især nyttige i brugerdokumentationen.

Tip

Nogle lovmæssige krav omfatter en specifik uddannelseskomponent.

Tjekliste – Når du forbereder brugerdokumentation og -oplæring, omfatter vigtige beslutninger og handlinger:

  • Identificer, hvilke oplysninger der skal medtages: Find ud af, hvilke oplysninger der skal inkluderes, så alle relevante målgrupper forstår, hvad der forventes af dem, når det gælder beskyttelse af data på vegne af organisationen.
  • Publicer den brugerdefinerede Hjælp-side: Opret og publicer en brugerdefineret hjælpside. Medtag vejledning om mærkning i form af ofte stillede spørgsmål og eksempler. Medtag et link for at få adgang til dataklassificerings- og beskyttelsespolitikken.
  • Publicer politikken for dataklassificering og beskyttelse: Publicer det politikdokument, der definerer, hvad der præcist kan eller ikke kan gøres med indhold, der er tildelt til hver etiket.
  • Find ud af, om der er behov for specifik oplæring: Opret eller opdater din brugeruddannelse, så den indeholder nyttige oplysninger, især hvis der er et lovmæssigt krav om at gøre det.

Brugersupport

Det er vigtigt at bekræfte, hvem der er ansvarlig for brugersupport. Det er almindeligt, at følsomhedsmærkater understøttes af en central it-helpdesk.

Du skal muligvis oprette en vejledning til helpdesk (også kaldet en runbook). Du skal muligvis også udføre videnoverførselssessioner for at sikre, at helpdesk er klar til at besvare supportanmodninger.

Tjekliste – Når du forbereder dig på brugersupportfunktionen, omfatter vigtige beslutninger og handlinger:

  • Identificer, hvem der skal yde brugersupport: Når du definerer roller og ansvarsområder, skal du sørge for at inkludere, hvordan brugerne får hjælp til problemer, der er relateret til beskyttelse af oplysninger.
  • Sørg for, at brugersupportteamet er klar: Opret dokumentation, og udfør sessioner til overførsel af viden for at sikre, at helpdesk er klar til at understøtte beskyttelse af oplysninger. Fremhæv komplekse aspekter, der kan forvirre brugerne, f.eks. krypteringsbeskyttelse.
  • Kommuniker mellem teams: Diskuter processen og forventningerne med supportteamet samt dine Power BI-administratorer og Center of Excellence. Sørg for, at alle involverede er forberedt på potentielle spørgsmål fra Power BI-brugere.

Oversigt over implementering

Når beslutningerne er truffet, og forudsætningerne er opfyldt, er det tid til at begynde at implementere beskyttelse af oplysninger i henhold til din gradvise udrulningsplan.

Følgende tjekliste indeholder en opsummeret liste over implementeringstrinnene fra ende til anden. Mange af trinnene indeholder andre oplysninger, der blev beskrevet i tidligere afsnit i denne artikel.

Tjekliste – Når du implementerer beskyttelse af oplysninger, omfatter vigtige beslutninger og handlinger:

  • Kontrollér den aktuelle tilstand og de aktuelle mål: Sørg for, at du har klarhed over den aktuelle tilstand for beskyttelse af oplysninger i organisationen. Alle mål og krav til implementering af information beskyttelse bør være klare og aktivt bruges til at drive beslutningsprocessen.
  • Beslut: Gennemse og diskuter alle de nødvendige beslutninger. Denne opgave skal udføres, før du konfigurerer noget i produktionen.
  • Gennemse licenskrav: Sørg for, at du forstår kravene til produktlicenser og brugerlicenser. Indkøb og tildel flere licenser, hvis det er nødvendigt.
  • Publicer brugerdokumentation: Publicer din politik for dataklassificering og beskyttelse. Opret en brugerdefineret hjælpside, der indeholder de relevante oplysninger, som brugerne skal bruge.
  • Forbered supportteamet: Udfør videnoverførselssessioner for at sikre, at supportteamet er klar til at håndtere spørgsmål fra brugere.
  • Opret følsomhedsmærkater: Konfigurer hver af følsomhedsmærkater i Microsoft Purview-compliance-portal.
  • Publicer en politik for følsomhedsmærkat: Opret og publicer en mærkatpolitik i Microsoft Purview-compliance-portal. Start med at teste med en lille gruppe brugere.
  • Angiv lejerindstillingerne for Power BI: Angiv lejerindstillingerne for beskyttelse af oplysninger på Power BI-administrationsportalen.
  • Udfør indledende test: Udfør et indledende sæt test for at kontrollere, at alt fungerer korrekt. Brug en lejer, der ikke er produktionsbaseret, til indledende test, hvis den er tilgængelig.
  • Indsaml brugerfeedback: Publicer mærkatpolitikken til et lille undersæt af brugere, der er villige til at teste funktionaliteten. Få feedback om processen og brugeroplevelsen.
  • Fortsæt iterative udgivelser: Publicer mærkatpolitikken til andre grupper af brugere. Onboarder flere grupper af brugere, indtil hele organisationen er inkluderet.

Tip

Disse kontrollisteelementer opsummeres til planlægningsformål. Du kan finde flere oplysninger om disse kontrollisteelementer i de forrige afsnit i denne artikel.

Løbende overvågning

Når du har fuldført implementeringen, skal du rette opmærksomheden mod overvågning og justering af følsomhedsmærkater.

Power BI-administratorer og administratorer af sikkerhed og overholdelse af angivne standarder skal samarbejde fra tid til anden. For Power BI-indhold er der to målgrupper, der beskæftiger sig med overvågning.

  • Power BI-administratorer: En post i Power BI-aktivitetsloggen registreres, hver gang en følsomhedsmærkat tildeles eller ændres. Aktivitetsloggen registrerer oplysninger om hændelsen, herunder bruger, dato og klokkeslæt, elementnavn, arbejdsområde og kapacitet. Andre hændelser i aktivitetsloggen (f.eks. når en rapport vises) omfatter det følsomhedsmærkat-id, der er tildelt elementet.
  • Administratorer af sikkerhed og overholdelse af angivne standarder: Organisationens sikkerheds- og overholdelsesadministratorer bruger typisk Microsoft Purview-rapporter, -beskeder og -overvågningslogge.

Tjekliste – Når du overvåger beskyttelse af oplysninger, omfatter vigtige beslutninger og handlinger:

  • Bekræft roller og ansvarsområder: Sørg for, at du er klar over, hvem der er ansvarlig for hvilke handlinger. Oplær og kommuniker med dine Power BI-administratorer eller sikkerhedsadministratorer, hvis de vil være direkte ansvarlige for nogle aspekter.
  • Opret eller valider din proces til gennemsyn af aktivitet: Sørg for, at sikkerheds- og overholdelsesadministratorerne er klar over forventningerne til regelmæssigt at gennemse aktivitetsoversigten.

Tip

Du kan få mere at vide om overvågning under Overvågning af beskyttelse af oplysninger og forebyggelse af datatab i Power BI.

Relateret indhold

I den næste artikel i denne serie kan du få mere at vide om forebyggelse af datatab i Power BI.