Sikring af app'en og dataene
Når du har fundet ud af, hvilken datastruktur der skal bruges, skal du på det næste trin overveje, hvordan dataene skal beskyttes. Du bør overveje, hvilke data der skal tilgås af hvem, og gå tilbage til de opgaver, forretningsprocesser og personer, som du har angivet i planlægningsfasen. I denne artikel forklares de generelle sikkerhedsbegreber for de personer, der ikke er fortrolige med dem. Du kan finde flere oplysninger om de tekniske aspekter af sikkerhed i Sikkerhedsroller og rettigheder.
Sikkerhedslag
Når du konfigurerer sikkerhed, er der fire forskellige sikkerhedslag, som du kan konfigurere i en app.
Sikkerhed på appniveau
Sikkerhed på app-niveau begrænser adgangen til appen.
Sikkerhed på app-niveau beskytter ikke placeringen af dit datalager. Hvordan dine data er sikret, varierer, afhængigt af funktionerne i datakilderne. Når du deler din app, skal du sikre dig, at brugerne også har de nødvendige rettigheder til de underliggende data.
Sikkerhed på formularniveau
I forbindelse med modelbaserede apps giver sikkerhed på formularniveau dig mulighed for kun at tillade bestemte sikkerhedsgrupper at få adgang til bestemte formularer. Dette er nyttigt, hvis du vil begrænse, hvordan brugerne angiver eller får vist data efter deres arbejdsrolle.
En app til godkendelsesproces kan f.eks. have én formular for medarbejdere til at oprette og sende godkendelsesanmodningen og en separat formular, hvor godkenderne kan gennemgå det, der er sendt. Sikkerhed på formularniveau vil passe godt til dette scenarie. Få flere oplysninger her: Kontroller adgangen til formularer i modelbaserede apps.
Sikkerhed på postniveau
Sikkerhed på postniveau er en form for sikkerhed, hvor du kan tildele adgang til bestemte poster. Forestil dig, at der i øjeblikket er et ark i en Excel-projektmappe. Sikkerhed på postniveau giver dig mulighed for at konfigurere sikkerheden for de enkelte rækker.
Der findes fire forskellige typer af adgang, nemlig CRUD (oprettelse, læsning, opdatering og sletning), som du kan angive for sikkerhed på postniveau:
Opret giver brugeren mulighed for at oprette nye data (f.eks. tilføje en ny række i Excel).
Læsning giver brugeren mulighed for at få vist dataene.
Opdatering giver en bruger mulighed for at ændre data, der allerede findes. Dette adskiller sig fra oprettelse, da det at oprette er tilføjelse af nye data.
Sletning giver brugeren mulighed for at slette data (f.eks. fjerne en række i Excel).
For Microsoft Dataverse findes der yderligere fire typer af adgang: tilføj, tilføj til, tildel og del. Flere oplysninger: Standardsikkerhedsroller og rettigheder
Sikkerhed på feltniveau
Sikkerhed på feltniveau er en mere specifik sikkerhed i en enkelt post. Det er som at angive sikkerheden for en enkelt kolonne i Excel. Der er som regel lignende adgangsniveauer som sikkerhed på postniveau, blot på feltniveau.
Sådan relaterer de forskellige sikkerhedsniveauer sig til hinanden
De sikkerhedsniveauer, der er nævnt ovenfor, er ligesom lag. Designet af din app skal overveje et eller flere af disse sikkerhedsniveauer, så de passer til dine behov. I følgende tabel vises de enkelte kontrolelementer for sikkerhedsniveauer i en apps funktionsmåde.
| Sikkerhedsniveau | Eksempel |
|---|---|
| Sikkerhed på appniveau | Adgang til "Salgsapp" |
| Sikkerhed på formularniveau | Adgang til "Kundekort" |
| Sikkerhed på postniveau | Adgang til "Contoso Ltd." |
| Sikkerhed på feltniveau | Adgang til "Omsætningsbeløb" |
De fem trin for design af sikkerhed
Forskellige sikkerhedsniveauer kan virke temmelig komplekst og overvældende, men du kan dele det op i følgende fem trin:
Trin 1: Identificer, hvem eller hvilke persongrupper (f.eks. afdelinger, sektioner eller teams) der har adgang til selve appen. Det skal være det samme sæt af personer, som du har identificeret i planlægningsfasen.
Trin 2: Blandt de brugere, du har identificeret i trin 1, skal du opdele dem i de grupper, der vil (eller ikke) få adgang til begrænsede oplysninger.
Trin 3: Identificer kravene for, hvem der kan se posterne.
Trin 4: Hvis du bruger andre datakilder end Dataverse—eller tjenester, der ikke har Office 365- eller Microsoft Entra-godkendelse—skal du overveje, hvordan du giver adgang til disse systemer. Hvis du ikke er ansvarlig for disse systemer, skal du søge rådgivning fra disse tjenesteadministratorer.
Trin 5: Afhængigt af ovenstående trin skal du overveje, hvordan disse forskellige grupper skal administreres. Det anbefales, at du anvender alle sikkerhedsgrupper.
Eksempel: Sikkerhed for udgiftsrapportløsning
I et scenarie med omkostningsgodkendelse kan alle medarbejdere sende udgiftsrapporter, så de har alle brug for at have adgang til appen til oprettelse af udgiftsrapporter. Derudover skal godkenderne have adgang til appen til godkendelse.
Vi har brug for en sikkerhedsgruppe for Alle medarbejdere, der har adgang til appen for udgiftsrapportering, og de data, den bruger. Vi skal bruge en sikkerhedsgruppe for Godkendere, der har adgang til appen for godkendelser.
Regnskabsafdelingen skal muligvis have adgang til mere følsomme data, f.eks. medarbejderens bankkonto til refusion.
Vi har brug for en sikkerhedsgruppe for Regnskabsgruppen, der er den eneste sikkerhedsgruppe, der har adgang til oplysninger om medarbejdernes bankoplysninger.
Vi ønsker nok ikke, at medarbejderne skal kunne se hinandens udgiftsrapporter, så det er nødvendigt at konfigurere sikkerhed på postniveau for at give medarbejdere tilladelse til kun at tilgå deres egne poster. Vi skal dog også sikre, at godkenderne kan se de rapporter, de modtager til godkendelse. Og vi har brug for at revisionsteamet kan se alle udgiftsrapporter (men ikke ændre dem).
Vi har brug for en sikkerhedsgruppe for Revisorer. Vi er nødt til at give den og sikkerhedsgruppen Godkendere adgang til alle poster, og vi skal kun give gruppen Alle medarbejdere adgang til "poster, som jeg opretter".
Flere oplysninger: Sikkerhed i Dataverse
Bemærk
Kan du fortælle os om dine sprogpræferencer for dokumentation? Tag en kort undersøgelse. (bemærk, at denne undersøgelse er på engelsk)
Undersøgelsen tager ca. syv minutter. Der indsamles ingen personlige data (erklæring om beskyttelse af personlige oplysninger).