Upprätta en miljöstrategi

Power Platform-miljöer är behållare som administratörer kan använda för att hantera program, flöden, anslutningar och andra resurser tillsammans med behörigheter att tillåta organisationsmedlemmar att använda resurserna. Den här artikeln innehåller viktig information om miljöer i Microsoft Power Platform och hjälper dig att hantera rekommenderade sätt att hantera dem. Mer information: Microsoft Power Platform-miljö, översikt

Utveckling av en miljöstrategi innebär att konfigurera miljöer och andra lager av datasäkerhet på ett sätt som stöder produktiv utveckling i organisationen, samtidigt som du säkrar och organiserar resurser. En strategi för att hantera miljöetableringen och åtkomst och kontroll av resurser inom dem är viktigt för:

• Skydda data och åtkomst.
• Lär dig hur du använder standardmiljön korrekt.
• Hantera rätt antal miljöer för att undvika tillväxt och bevara kapacitet.
• Underlätta hantering av programmets livscykel (ALM).
• Ordna resurser i logiska partitioner.
• Stödja åtgärder (och supportavdelning) för att identifiera program som är i produktion genom att använda dem i särskilda miljöer.
• Säkerställa att data lagras och överförs i godkända geografiska regioner (av effektivitets- och kvalitetsskäl).
• Säkerställa isolering av program som utvecklas.

Förstå miljöer

Innan vi börjar bör vi titta på några fakta om miljön och säkerhetsnyckeln:

• Miljöer är kopplade till en geografisk plats som konfigureras när miljön skapas.
• Miljöer kan användas för att rikta olika målgrupper eller för olika syften, t.ex. utveckling, test och produktion.
• Principer för dataförlustskydd (DLP) kan tillämpas på enskilda miljöer eller i klientorganisationen.
• Varje klientorganisation har en standardmiljö.
• Miljöer som inte är standard kan skapas av licensierade Power Apps, Power Automate och Dynamics 365-användare. Skapande kan begränsas till endast globala och tjänsteadministratörer via en inställning av klientorganisation.
• Miljöer som inte är standard ger bättre kontroll över behörigheter.
• En miljö kan ha en eller noll Microsoft Dataverse-instanser.
• Miljöer innehåller fördefinierade säkerhetsroller som motsvarar vanliga användaruppgifter med åtkomstnivåer som definierats för att matcha metodtipsmålet för säkerhet av att ge tillgång till den minsta mängden verksamhetsdata som krävs för att använda programmet.
• Standarddirigering för miljö är en premium-styrningsfunktion. Med den här funktionen kan Power Platform-administratörer automatiskt rikta nya beslutsfattare till sina egna, personliga utvecklarmiljöer när de besöker make.powerapps.com för första gången.

Miljötyper

Innan du börjar utveckla en miljöstrategi bör du se till att du förstår de olika typerna av miljöer.

Utveckling av en strategi

Här är en utgångspunkt för din miljöstrategi.

• Tilldela dina administratörer rollen Microsoft Power Platform tjänstadministratör eller Dynamics 365 tjänstadministratör.
  Dessa roller ger administrativ åtkomst till Power Apps arbetsyteappar, flöden, modellbaserade program, miljöer, anpassade anslutningsprogram, anslutningar, gateways, Power Apps-portaler, AI Builder-modeller och alla Dataverse-instanser. Den här rollen ska tilldelas administratörer som inte behöver ha åtkomst till den globala klientorganisationen och är endast avsedd för hantering av Microsoft Power Platform.

• Begränsa skapandet av net-new produktionsmiljöer till administratörer.
  Begränsa skapande av miljö är fördelaktigt för att behålla kontrollen i allmänhet: både för att förhindra outräknad kapacitetsförbrukning och för att minska antalet miljöer att hantera. Om användarna måste begära miljöer från central IT är det lättare att se vad användarna arbetar med om en administratör är en grindvakt.

• Behandla Standardmiljön som en användar- och teamproduktivitetsmiljö för dina affärsgrupper.
  Det rekommenderas att du byter namn på miljön via administrationscenter för att göra syftet med den miljön självförklarande. Meddela tydligt att standardvärdet används för användar- och teamproduktivitetsscenarier, men inte affärsviktiga eller verksamhetskritiska program. Det går inte att inaktivera eller ta bort den här miljön eftersom den är värd för integrering med produkter som SharePoint och projekt. Vi rekommenderar en nivåbaserad metod för användar- och teamproduktivitetsmiljöer.

• Upprätta en process för att begära eller skapa miljöer.
  När skapande av miljön är låst och reserveras för första partens integreringsappar kan du göra det tydligt för organisationen att ett korrekt utvecklingsprojekt ska startas genom att begära en ny engagerande miljö där det finns en klar och detaljerad kommunikation mellan utvecklare och administratörer. Nästa avsnitt innehåller mer information om hur du skapar automatiserade miljöer, vilket är en metod för att implementera en enkel formell process för begäran.

• Utvecklings-/test-/produktionsmiljöer för specifika affärsgrupper eller program.
  Genom att använda fasbaserade miljöer försäkrar du dig om att ändringar under utveckling inte avbryter användarnas produktion och att data inte skadas. När resurser är begränsade kan du fokusera det här mönstret för verksamhetskritiska och viktiga program, eller på affärsenheter som har det största behovet av eget, dedikerat utrymme.

• Miljöer för enskilda användnings bevis för koncepttest och workshoppar.
  För att vara värd för workshoppar, hackathons och interna utbildningsevenemang som Program på en dag eller ett Flöde på en dag skapar du en ny, separat miljö för evenemanget så att alla kan organisera sig. Be användarna att spara de resurser de behöver på en kort tidsperiod efter evenemanget och rensa miljön eller återställ den för andra evenemang. Använd utvärderingsmiljöer som inte använder kapacitet för den här typen av aktiviteter.

• Upprätta DLP-principer (dataförlustskydd) för klientorganisations- och miljönivå
  DLP-principer (dataförlustskydd) fungerar som skyddsmekanismer för att förhindra att användare oavsiktligt exponerar organisationsdata och skyddar informationssäkerheten i klientorganisationen. En viktig del av Power Platform administratörsrollen är att upprätta och underhålla DLP-principer på klientorganisations- och miljönivå.

Nivåbaserad metod för team- och användarproduktivitetsmiljöer

Om du vill stödja integrering, minska antalet miljöer som behövs och påskynda registrering bör du skapa flera delade miljöer som kan användas av personer och team.

Standardmiljö

Alla i klientorganisationen har behörighet att skapa program och flöden här. Det finns för närvarande inget sätt att blockera rolltilldelningen för miljöskaparen i den här miljön. Det här är även den miljö som används för tredjepartsprogram, t.ex. för att skapa ett program från en SharePoint-lista. Mer information: Standardmiljön

För att minska risken för data bör de typer av anslutningar som används i dina program och flöden begränsas till en mindre tillåtande DLP-princip (dataförlustskydd). Den här principen bör täcka vanliga användningsfall för användarfall för enskilda och mindre teamproduktivitet, t.ex. arbeta med SharePoint-data, skicka e-post och ha ett arbetsflöde för godkännande.

Miljö för avancerade användare

Standardmiljön omfattar många användningsfall och vissa privilegierade användare har mer avancerade behov för program och flöden, som att integrera med Microsoft Teams, Microsoft Entra ID eller Azure DevOps.

Därför rekommenderar vi att du skapar en miljö för avancerade användare. Den här delade miljön bör använda mer tillåtande DKUP-principer och administratörer bör styra skaparlistan till den här miljön.

Tänk på följande för miljön för avancerade användare:

• Kontrollera tillgängliga anslutningar i den här miljön så att det passar dina användare.
• Dokumentera syftet och tillgängliga kontakter i den här miljön tydligt, till exempel på en SharePoint-webbplats eller en wiki.
• Skapa en automatiserad process för tillverkarna och begär åtkomst till miljön för avancerade användare, till exempel med hjälp av Microsoft Forms, en SharePoint-webbplats eller ett program. Om det behövs kan processen omfatta godkännande av linjechefen eller IT.

Anpassade miljöer

De delade miljöerna täcker många användningsfall för program, team och projekt kan dra nytta av att ha en anpassad miljö som stöd för affärsenhetens användningsfall eller scenarier för hantering av programmets livscykel.

Vissa överväganden för anpassade miljöer:

• Arbeta med projektteam eller affärsenheter för att fastställa om de kräver särskilda utvecklings-, test- och produktionsmiljöer eller om en särskild utvecklingsmiljö och en delad test- och produktionsmiljö passar för deras användningsfall.
• Använd dedikerade miljöer för kritiska projekt och arbetsbelastningar. Utvecklare har åtkomsten miljöskapare i utvecklingsmiljön, men bara användaråtkomst i test- och produktionsmiljöerna. Slutanvändare har endast åtkomst för slutanvändare till produktionslösningen så ingen kan ändra produktionsprogrammen.
• Överväg att dela test- och produktionsmiljöer mellan viktiga men medelhögt komplexa program. Enskilda projekt och affärsenheter har sin egen utvecklingsmiljö för att skydda data, men lösningar har distribuerats till delade test- och produktionsmiljöer. Utvecklare är slutanvändare i testmiljön och slutanvändare har endast grundläggande användaråtkomst till lösningar och data i produktionsmiljön.
• Arbeta med affärsenheten för att fastställa vilka anslutningsprogram som krävs och skapa en undantagsprincip.
• Arbeta med affärsenheten för att fastställa vem som ska vara en tillverkare i den här miljön och vem som ska vara miljöadministratör.
• Varje miljö förbrukar 1 GB datakapacitet, så hantera anpassade miljöer på ett bra sätt.

Utöver rekommendationerna ovan kan du också skapa en form och styra din DLP-strategi.

• Alla är en tillverkare. Kommunicera med alla att standard inte är för utveckling av viktiga appar.
• Endast en användare har åtkomst. Miljöer för Utvecklare är helt låsta för andra användare förutom de användare som prenumererar på community-planen. Program kan flyttas ut ur miljön vid behov.
• Godkända användare har åtkomst. Delade miljöer för användar- och teamproduktivitetsscenarier med godkänd skaparlista.
• Dedikerad miljöer för kritiska projekt och arbetsbelastningar. Utvecklare har åtkomsten miljöskapare i utvecklingsmiljön, men bara användaråtkomst i test- och produktionsmiljöerna. Slutanvändare har endast åtkomst för slutanvändare till produktionslösningen så ingen kan ändra produktionsprogrammen.
• Delad test- och produktionsmiljöer för viktiga men medelhögt komplexa program. Enskilda projekt och affärsenheter har sin egen utvecklingsmiljö för att skydda data, men lösningar har distribuerats till delade test- och produktionsmiljöer. Utvecklare är slutanvändare i testmiljön och slutanvändare har endast grundläggande användaråtkomst till lösningar och data i produktionsmiljön.

Ytterligare rekommendationer för hantering av miljöer

Här följer en lista över ytterligare rekommendationer som kan under lätta enklare hantering av miljöer med kundåtaganden.

• Använd ett tjänstkonto för att distribuera produktionslösningar: skapa ett tjänstkonto som centrala IT-chefer distribuerar till test- och produktionsmiljöer. Detta är fördelaktigt av många anledningar:

  • Tillåter alla medlemmar i IT att hantera administratörsresurser (t.ex. test- och produktionsmiljöer).
  • Endast tjänstkontot har administratörsbehörighet i miljön.
  • Alla andra användare har behörighet för slutanvändare och kan inte skapa nya resurser – detta är viktigt eftersom användare får åtkomst till en dataanslutning, de kan skapa ett nytt gränssnitt för att interagera med de data som inte är avsedda för utvecklare.
  • IT är medveten om program i produktionsklass som finns i distributionen eftersom de är inblandade i implementeringen.
  • Tjänstkonton behöver Microsoft Power Platform eller Dynamics 365 tjänstadministratörsbehörighet i PIM. Tilldela ytterligare licenser efter behov beroende på vilka anslutningsprogram som måste användas i förfrågningsprocessen (t.ex. om Dataverse och Outlook används, tilldela premium Power Apps och Office Enterprise).
  • När du visar information för ett program visas tjänstkontot som skaparen och inte utvecklaren. Detta hjälper slutanvändare att veta vem de ska kontakta i händelse av problem med programmet.

  Överväg om riskerna med att ha ett servicekonto är viktiga för dig. Vissa organisationer är inte bekväma med att ha ett tjänstkonto eftersom det till exempel inte går att spåra en delad resurs med administratörsprivilegier till en enskild person. Detta är giltigt men kan minskas med steg som framtvingad villkorlig åtkomst, spårning av spårningsloggar till en IP-adress eller mer omfattande metoder som att upprätthålla en arbetsstation med säker åtkomst som kräver användaridentifiering vid användning och begränsar tjänstkontot till den enheten.

• Minska antalet delade utvecklingsmiljöer

  Ha separata miljöer för separat projektutveckling, särskilt när du hanterar skyddade data. Miljöer är behållare för resurser som anslutningar till data och i utvecklingsmiljöer kan det finnas flera personer med åtkomst till miljöutvecklare. Om utvecklare har tillgång till en delad dataanslutning och kan skapa program och flöden, finns det en risk att någon kommer att skapa ett nytt gränssnitt för att läsa, uppdatera och ta bort data som kan ha tilldelats åtkomst till. Detta är särskilt viktigt för att komma ihåg standardmiljön – du bör alltid ha viktiga data anslutningar, anpassade anslutningar och andra resurser som behöver säkerhet i isolerade miljöer för att skydda dem.

• Dela resurser med Microsoft Entra säkerhetsgrupper

  Säkerhetsgrupper kan användas för att hantera åtkomst till Power Apps, flöden, Dataverse säkerhetsroller och andra Office 365-tjänster, t.ex. SharePoint Online. Detta tar bort administratörens börda för att uppdatera åtkomsten till enskilda slutanvändare för varje komponent (i synnerhet om flera berörs) – programmets ägare kan ändra på säkerhetsgruppens nivå utan den (såvida den inte begränsar åtkomst till säkerhetsgruppshantering).

• Automatisera kontrollmiljö

  Administratörsanslutningarna (Microsoft Power Platform for Admins) gör det möjligt att skapa en godkännandeprocess där användarna begär miljöer när miljön har begränsats till administratörer. Central IT kan granska en förfrågan och godkänna eller avvisa skapandet av miljön, utan att behöva ansvara för att du manuellt ska gå till administrationscenter och skapa miljön för användaren, enbart för att verifiera förfrågningsinformationen, affärsjusteringen, DLP-kraven och om det finns tillräckligt med kapacitet.

• Skapa tillfälliga utvecklingsmiljöer

  Vi rekommenderar att du i det här avsnittet avgränsar utvecklingsmiljöer så mycket som möjligt och undviker samtidigt program utveckling för kritiska lösningar i standardmiljön. Om du skapar miljöer för utvecklingsändamål bör du ange en tidsgräns för hur länge miljön ska vara tillgänglig för utvecklare och som har en process för att säkerhetskopiera och ta bort dem.

• Ju mindre desto bättre

  Det är viktigt att se till att alla resurser är partitionerade mellan projekt och affärsenheter med hjälp av miljöer, men det är fortfarande viktigt att hitta en bra balans mellan säkerhet och genomförbarhet. Hantering av delade test- och produktionsmiljöer är ett bra sätt att förenkla ett stort antal viktiga lösningar samtidigt som kapacitetsbegränsningar och följande bästa praxis bevaras. Detta upprätthåller begränsade behörigheter eftersom test och produktion har begränsad miljöbehörighet och att slutanvändarna inte kan ändra programmen.

• Etablera miljöer med Dataverse-instanser i rätt region

  I företag där anställda arbetar i flera länder/regioner kan vissa efterlevnadsbeaktanden behöva göras gällande var data lagras och skickas mellan länder/regioner. Om miljön har en Dataverse-instans lagras informationen fysiskt i regionen. Granska listan över stödda miljöregioner.

Faktorer som påverkar försörjningen

Vissa faktorer påverkar när de ska konfigurera vilka typer av miljöer:

• Definierade nivåer för appstöd

  Komplexitetsnivån, hur viktigt programmet är och vilka användare som påverkas av programmet (t.ex. månatliga aktiva användare/totala användare i en organisation) är alla viktiga åtgärder för att tillhandahålla miljöer som stöder alla scenarier.

  Olika typer av program bör skiljas åt i olika miljöer beroende på hur viktiga de är.

  	Verksamhetskritiska scenarier och/eller användning av mycket hög komplexitet och/eller för hela organisationen. Support som ägs av IT. Robust ALM-process (utveckling/test/produktion). Längre utvecklingscykel, ofta mer än 3 månader på en minsta lönsam produkt.
  	Viktigt men inte kritisk och/eller medelhög komplexitet och/eller omfattning för affärsenhet. Support som ägs av programägaren eller affärsenheten med hjälp från IT. ALM-användning av miljöer är kanske inte nödvändig. Utveckling som vanligtvis är mindre än tre månader för en minsta lönsam produkt.
  	Produktivitetsappar som inte kräver hög styrningsnivå. Support av programutvecklare. Vanligtvis behövs inte hantering av programmets livscykel. Mindre än två veckor för en minsta lönsam produkt.

• Kapacitet

  Varje miljö (förutom utvärderings- och utvecklingsmiljöer) kommer att förbruka 1 GB till den första etableringen. Det här kan vara ett villkor för etableringsmiljöer om din organisation inte betalar för premium Power Apps eller Dynamics 365-licenser och det är även en delad kapacitet mellan klientorgaisationer som måste allokeras till dem som behöver det.

  Bevara kapacitet genom att:

  • Hantera delade test- och produktionsmiljöer. Till skillnad från i en delad utvecklingsmiljö bör behörigheter i test- och produktionsmiljöer begränsas till slutanvändare för testning.
  • Automatisera en automatisk rensning av tillfälliga utvecklingsmiljöer och uppmuntra att använda utvärderingsmiljöer för testning eller proof-of-concept.

• Administratörsmedverkan

  Det är inte alltid möjligt att ha ett central IT involverad i alla utvecklingsprojekt i hela klientorganisationen, särskilt om IT-teamet är mindre eller om det finns ett större företag att hantera.

  Minska arbetsbördan på administratören genom att:

  • Skapa en automatiserad miljö så att klientadministratören endast behöver godkänna förfrågan.
  • Automatisera rensning utvecklingsmiljö med tillfälliga miljöer.

Kommunicera tydligt organisationens miljöstrategi till tillverkarna

Konfigurera en SharePoint-webbplats eller en wiki som klart meddelar:

• Syftet med standardmiljön.
• Syftet med delade team- och användarproduktivitetsmiljöer är att det kan hända att du har tillgång till (t.ex. utbildningsmiljöer) och hur du begär åtkomst till dessa miljöer.
• Syftet med utvärderingsmiljöer och hur du begär dem.
• Syftet med utvecklarmiljöer och hur man skapar dem
• Processen för att begära anpassade miljöer för specifika affärsenheter eller projektsyften.
• Ansvarsområdena för en utvecklare:
  • Håll klientorganisationen ren. Ta bort dina miljöer, program och flöden om de inte behövs längre. Använd testmiljöer vid experiment.
  • Dela klokt. Se upp för att dela upp dina miljöer, program, flöden och delade anslutningar.
  • Skydda organisationsdata. Undvik att flytta data från mycket konfidentiella eller konfidentiella datakällor till icke-skyddad eller extern lagring.

Förmedla också organisationens DLP-princip till utvecklarna.