Del via

Sikre standardmiljøet

  • Artikkel

Hver ansatt i organisasjonen har tilgang til standardmiljøet i Power Platform. Som Power Platform-administrator må du vurdere måter å sikre miljøet på, og samtidig holde det tilgjengelig for utvikleres personlige produktivitetsbruk. Denne artikkelen inneholder forslag.

Tilordne administratorroller med omhu

Vurder om administratorbrukerne må ha rollen Power Platform-administrator. Passer kanskje rollen miljøadministrator eller systemansvarlig bedre? Begrens uansett den kraftigere rollen Power Platform-administrator til bare noen få brukere. Finn ut mer om administrasjon av Power Platform miljøer.

Kommuniser hensikt

En av hovedutfordringene til Power Platform Center of Excellence-teamet (CoE) er å meddele den tiltenkte bruken av standardmiljøet. Her finner du noen anbefalinger.

Endre navn på standardmiljøet

Standardmiljøet opprettes med navnet TenantName (standard). Du kan endre miljønavnet til noe mer beskrivende, for eksempel Personlig produktivitetsmiljø, som tydelig viser hensikten.

Bruk Power Platform-senteret

Microsoft Power Platform-senteret er en mal for SharePoint-kommunikasjonsområde. Det er et utgangspunkt for en sentral informasjonskilde for utviklere om organisasjonens bruk av Power Platform. Startinnhold og sidemaler gjør det enkelt å gi utviklere informasjon, for eksempel følgende:

  • Bruksområder for personlig produktivitet
  • Hvordan apper og flyter bygges
  • Hvor apper og flyter skal bygges
  • Hvordan du kontakter CoE-kundestøtteteamet
  • Regler for integrering med eksterne tjenester

Legg til koblinger til andre interne ressurser som utviklerne kan ha nytte av.

Begrens deling med alle

Utviklere kan dele appene sine med andre individuelle brukere og sikkerhetsgrupper. Som standard er deling med hele organisasjonen, eller Alle, deaktivert. Vurder å bruke en inngjerdet prosess rundt mye brukte apper for å håndheve retningslinjer og krav som disse:

  • Sikkerhetsgjennomgangspolicy
  • Forretningsgjennomgangspolicy
  • Krav for administrasjon av programlivssyklus (ALM)
  • Krav til brukeropplevelse og varemerker

Del med alle-funksjonen er deaktivert som standard i Power Platform. Vi anbefaler at du holder denne innstillingen deaktivert for å begrense overeksponeringen av lerretsapper med utilsiktede brukere. Alle-gruppen for organisasjonen inneholder alle brukere som noen gang har logget på leieren, som inkluderer gjester og interne medlemmer. Det er ikke bare alle interne ansatte i leietakeren din. I tillegg kan ikke medlemskapet i Alle-gruppen redigeres eller vises. Hvis du vil lære mer om Alle-gruppen , kan du gå til /windows-server/identity/ad-ds/manage/understand-special-identities-groups#everyone.

Hvis du vil dele med alle interne ansatte eller en stor gruppe personer, bør du vurdere å dele med en eksisterende sikkerhetsgruppe med disse medlemmene eller opprette en sikkerhetsgruppe og dele appen med denne sikkerhetsgruppen.

Når Del med alle er deaktivert, kan bare en liten gruppe administratorer dele et program med alle i miljøet. Hvis du er administrator, kan du kjøre følgende PowerShell-kommando hvis du trenger å aktivere deling med alle.

  1. Først åpner du PowerShell som administrator og logger på kontoen din Power Apps ved å kjøre denne kommandoen.

    Add-PowerAppsAccount

  2. Kjør cmdleten Get-TenantSettings for å hente listen over organisasjonens leierinnstillinger som et objekt.

    Objektet powerPlatform.PowerApps inneholder tre flagg:

    Skjermbilde av tre flagg i objektet $settings.powerPlatform.PowerApps.

  3. Kjør følgende PowerShell-kommandoer for å hente settings-objektet, og angi variabelen disableShareWithEveryone til $false.

    $settings=Get-TenantSettings 
$settings.powerPlatform.powerApps.disableShareWithEveryone=$false

  4. Kjør cmdleten Set-TenantSettings med innstillingsobjektet for å tillate utviklere å dele appene sine med alle i leieren.

      Set-TenantSettings $settings

    For å deaktivere deling med alle, følg de samme trinnene, men angi $settings.powerPlatform.powerApps.disableShareWithEveryone = $true.

Opprett en policy for hindring av datatap

Du kan også sikre standardmiljøet ved å opprette en policy for hindring av datatap for det. Det er spesielt viktig å ha en policy for hindring av datatap på plass for standardmiljøet fordi alle ansatte i organisasjonen har tilgang til det. Her er noen anbefalinger som kan være til hjelp når du skal håndheve policyen.

Tilpass styringsmeldingen for hindring av datatap

Tilpass feilmeldingen som skal vises hvis en utvikler lager en app som bryter organisasjonens policy for hindring av datatap. Henvis utvikleren til organisasjonens Power Platform-senter, og oppgi e-postadressen til CoE-teamet.

Etter hvert som CoE-teamet finjusterer policyen for hindring av datatap over tid, kan det hende at du utilsiktet bryter policyen for noen apper. Kontroller at meldingen om brudd på policyen for hindring av datatap inneholder kontaktdetaljer eller en kobling til mer informasjon, slik at utviklerne vet hva de skal gjøre.

Bruk følgende PowerShell-cmdleter til å tilpasse styringspolicymeldingen:

Command Bekrivelse
Set-PowerAppDlpErrorSettings Angi styringsmelding
Set-PowerAppDlpErrorSettings Oppdater styringsmelding

Blokkere nye koblinger i standardmiljøet

Som standard plasseres alle nye koblinger i Nonbusiness-gruppen i DLP-policyen. Du kan alltid endre standardgruppen til Forretning eller Blokkert. Når det gjelder en policy for hindring av datatap som gjelder for standardmiljøet, anbefaler vi at du konfigurerer Blokkert-gruppen som standard for å sikre at nye koblinger forblir ubrukelige før de er gjennomgått av en av administratorene.

Begrens utviklere til forhåndsbygde koblinger

Begrens utviklere til bare grunnleggende koblinger som ikke kan blokkeres, for å forhindre tilgang til resten.

  1. Flytt alle koblingene som ikke kan blokkeres, til forretningsdatagruppen.

  2. Flytt alle koblingene som kan blokkeres, til den blokkerte datagruppen.

Begrens egendefinerte koblinger

Egendefinerte koblinger integrerer en app eller flyt med en egenutviklet tjeneste. Disse tjenestene er ment for tekniske brukere, for eksempel utviklere. Det er en god idé å redusere fotavtrykket for API-er utviklet av organisasjonen som kan aktiveres fra apper eller flyter i standardmiljøet. Hvis du vil forhindre at utviklere oppretter og bruker egendefinerte koblinger for API-er i standardmiljøet, oppretter du en regel for å blokkere alle nettadressemønstre.

Hvis du vil gi utviklere tilgang til noen API-er (for eksempel en tjeneste som returnerer en liste over firmaferier), konfigurerer du flere regler som klassifiserer ulike nettstedsmønstre i datagrupper for forretning og ikke-forretning. Kontroller at tilkoblinger alltid bruker HTTPS-protokollen. Finn ut mer om DLP-policy for egendefinerte koblinger.

Sikre integrering med Exchange

Office 365 Outlook-koblingen er en av standardkoblingene som ikke kan blokkeres. Den gjør at utviklere kan sende, slette og svare på e-postmeldinger i postboksene de har tilgang til. Risikoen med denne koblingen er også en av de kraftigste funksjonene – muligheten til å sende e-post. En utvikler kan for eksempel opprette en flyt for masseutsendelse av én e-postmelding.

Exchange-administratoren i organisasjonen kan konfigurere regler på Exchange-serveren for å forhindre at e-postmeldinger sendes fra apper. Det er også mulig å utelate bestemte flyter eller apper fra reglene som er konfigurert til å blokkere utgående e-poster. Du kan kombinere disse reglene med en tillatelsesliste over e-postadresser for å sikre at e-post fra apper og flyter bare kan sendes fra en liten gruppe postbokser.

Når en app eller flyt sender en e-postmelding via Office 365 Outlook-koblingen, setter den inn bestemte SMTP-hoder i meldingen. Du kan bruke reserverte uttrykk i hodene til å identifisere hvorvidt e-postmeldingen kom fra en flyt eller en app.

SMTP-hodet som settes inn i en e-postmelding som er sendt fra en flyt, ser ut som følgende eksempel:

 x-ms-mail-application: Microsoft Power Automate; 
 User-Agent: azure-logic-apps/1.0 (workflow 2321aaccfeaf4d7a8fb792e29c056b03;version 08585414259577874539) microsoft-flow/1.0
 x-ms-mail-operation-type: Send
 x-ms-mail-environment-id: 0c5781e0-65ec-ecd7-b964-fd94b2c8e71b

Overskriftsdetaljer

Følgende tabell beskriver verdiene som kan vises i hodet x-ms-mail-application, avhengig av hvilken tjeneste som brukes:

Tjeneste Verdi
Power Automate Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow <GUID>; version <version number>) microsoft-flow/1.0
Power Apps Microsoft Power Apps; User-Agent: PowerApps/ (; AppName= <app name>)

Følgende tabell beskriver verdiene som kan vises i hodet x-ms-mail-operation-type, avhengig av hvilken handling som utføres:

Verdi Bekrivelse
Svar For operasjoner for svar på e-post
Fremover For operasjoner for videresending av e-post
Send For operasjoner for sending av e-post, inkludert SendEmailWithOptions og SendApprovalEmail

Overskriften x-ms-mail-environment-id inneholder verdien for miljø-ID-en. Tilstedeværelsen av denne overskriften avhenger av produktet du bruker:

  • I Power Apps er den alltid til stede.
  • I Power Automate finnes den bare i tilkoblinger opprettet etter juli 2020.
  • I Logic Apps er den aldri til stede.

Potensielle Exchange-regler for standardmiljøet

Her er noen e-posthandlinger du kan blokkere ved hjelp av Exchange-regler.

  • Blokker utgående e-postmeldinger til eksterne mottakere: Blokker alle utgående e-postmeldinger som sendes til eksterne mottakere fra Power Automate og Power Apps. Denne regelen forhindrer at utviklere sender e-postmeldinger til partnere, leverandører eller klienter fra appene eller flytene sine.

  • Blokker utgående videresending: Blokker alle utgående e-postmeldinger videresendt til eksterne mottakere fra Power Automate og Power Apps der avsenderen ikke kommer fra en tillatt liste over postbokser. Denne regelen forhindrer at utviklere oppretter en flyt som automatisk videresender innkommende e-postmeldinger til en ekstern mottaker.

Unntak å vurdere med regler for e-postblokkering

Her er noen potensielle unntak fra Exchange-reglene for å blokkere e-post for å legge til fleksibilitet:

  • Utelat bestemte apper og flytprosesser: Legg til en unntaksliste i reglene foreslått tidligere, slik at godkjente apper eller flyter kan sende e-post til eksterne mottakere.

  • Tillatelsesliste på organisasjonsnivå: I dette scenarioet er det fornuftig å flytte løsningen til et dedikert miljø. Hvis flere flyter i miljøet må sende utgående e-poster, kan du opprette en rammeunntaksregel for å tillate utgående e-postmeldinger fra det miljøet. Utvikler- og administratortillatelsen for det miljøet må kontrolleres og begrenses.

Hvis du vil ha mer informasjon om hvordan du konfigurerer de riktige eksfiltreringsreglene for Power Platform relatert e-posttrafikk, kan du gå til E-posteksfiltreringskontroller for koblinger.

Bruk kryssleietakerisolasjon

Power Platform har et system for koblinger basert på Microsoft Entra som gjør at autoriserte Microsoft Entra-brukere kan koble apper og flyter til datalagre. Leierisolasjon styrer flyttingen av data fra Microsoft Entra-autoriserte datakilder til og fra leieren.

Leierisolasjon brukes på leiernivå og påvirker alle miljøer i leieren, inkludert standardmiljøet. Siden alle ansatte er utviklere i standardmiljøet, er det svært viktig å konfigurere en kraftig leierisolasjonspolicy for å sikre miljøet. Vi anbefaler at du eksplisitt konfigurerer leiere som de ansatte kan koble til. Alle de andre leiere bør dekkes av standardregler som blokkerer både inngående og utgående dataflyter.

Power Platform-leierisolasjon er forskjellig fra Microsoft Entra ID-bred leierbegrensning. Den påvirker ikke Microsoft Entra ID-basert tilgang utenfor Power Platform. Den fungerer bare for koblinger som bruker Microsoft Entra ID-basert godkjenning, for eksempel koblingene for Office 365 Outlook eller SharePoint.

Se også

Begrens innkommende og utgående tilgang på tvers av leier (forhåndsversjon)

Get-PowerAppTenantIsolationPolicy (Microsoft.PowerApps. Administrasjon.PowerShell)