Share via

Zřízení strategie prostředí

  • Článek

Prostředí Power Platform jsou kontejnery, které mohou správci použít ke správě aplikací, toků, připojení a dalších prostředků; spolu s oprávněními umožňujícím členům organizace využívat zdroje. Tento článek vás provede důležitými podrobnostmi o prostředích v Microsoft Power Platform a diskutuje o doporučených způsobech, jak těžit z jejich proaktivního řízení. Další informace: Přehled prostředí Microsoft Power Platform

Vývoj strategie prostředí znamená konfiguraci prostředí a dalších vrstev zabezpečení dat způsobem, který podporuje produktivní vývoj ve vaší organizaci a zároveň zajišťuje a organizuje zdroje. Strategie pro správu zajišťování a přístupu k prostředí a řízení zdrojů v nich je důležitá pro:

  • Zabezpečte data a přístup.
  • Pochopte, jak správně používat výchozí prostředí.
  • Spravujte správný počet prostředí, abyste zabránili rozrůstání a šetřili kapacitu.
  • Usnadněte správu životního cyklu aplikací (ALM).
  • Uspořádejte prostředky do logických oddílů.
  • Podporu operací (a helpdesk) při identifikaci aplikací, které jsou v provozu, tím, že je budete mít ve vyhrazených prostředích.
  • Zajistěte, aby se data ukládala a přenášela v přijatelných zeměpisných oblastech (z důvodu výkonu a dodržování předpisů).
  • Zajistěte izolaci vyvíjených aplikací.

Pochopení prostředí

Než začneme, podívejme se na klíčová fakta o prostředí a zabezpečení:

  • Prostředí jsou svázána s geografickou polohou, která je nakonfigurována v okamžiku vytvoření prostředí.
  • Prostředí lze použít k cílení na různé cílové skupiny nebo pro různé účely, jako je vývoj, testování a produkce.
  • Zásady ochrany před únikem informací (DLP) lze použít na jednotlivá prostředí nebo na klienta.
  • Každý klient má výchozí prostředí.
  • Jiná než výchozí prostředí mohou vytvářet uživatelé s licencí na Power Apps, Power Automate a Dynamics 365. Vytváření lze omezit pouze na globální správce a správce služeb prostřednictvím nastavení klienta.
  • Nestandardní prostředí nabízejí větší kontrolu oprávnění.
  • Prostředí může mít jednu nebo nula instancí Microsoft Dataverse.
  • Prostředí zahrnují předdefinované role zabezpečení, které odrážejí běžné uživatelské úlohy s definovanými úrovněmi přístupu odpovídajícími cíli podle doporučených postupů pro zabezpečení a které poskytují přístup k minimálnímu množství obchodních dat potřebných pro používání aplikace.
  • Výchozí směrování prostředí je prémiová funkce řízení. Tato funkce umožňuje správcům Power Platform automaticky směrovat své nové tvůrce do jejich vlastního, osobního vývojářského prostředí, když poprvé přejdou na adresu make.powerapps.com.

Typy prostředí

Než začnete vyvíjet strategii prostředí, musíte rozumět různým typům prostředí.

Vypracování strategie

Tady je výchozí bod ke zvážení pro vaši strategii prostředí.

  • Přiřaďte svým správcům roli správce služby Microsoft Power Platform nebo správce služby Dynamics 365.
    Tyto role poskytují administrativní přístup k aplikacím plátna Power Apps, tokům, modelem řízeným aplikacím, prostředím, vlastním konektorům, připojením, branám, portálům Power Apps, modelům AI Builder a všem instancí Dataverse. Tato role by měla být přiřazena správcům, kteří nepotřebují globální přístup správce klienta a jsou vyhrazeni pro správu Microsoft Power Platform.

  • Omezte vytváření čistě nových produkčních prostředí na správce.
    Omezení vytváření prostředí je prospěšné udržovat kontrolu obecně: jak k zabránění neočekávané spotřeby kapacity, tak ke snížení počtu prostředí pro správu. Pokud uživatelé musí požadovat prostředí od centrálního IT, je snazší zjistit, na čem lidé pracují, pokud jsou správci vrátnými.

  • Považujte výchozí prostředí za prostředí produktivity pro uživatele a tým vašich obchodníh skupin.
    Přejmenování prostředí prostřednictvím centra pro správu se doporučuje, aby byl účel daného prostředí vysvětlitelný. Jasně sdělte, že výchozí se používá pro scénáře produktivity uživatelů a týmů, ale ne pro aplikace důležité z hlediska podnikání nebo zásadně důležité aplikace. Toto prostředí nelze deaktivovat ani odstranit, protože je hostitelem integrace s produkty jako SharePoint a Project. Doporučujeme odstupňovaný přístup k provozním prostředím uživatelů a týmů.

  • Vytvořte proces pro vyžádání přístupu nebo vytvoření prostředí.
    Když je vytváření prostředí uzamčeno a je ve výchozím nastavení vyhrazeno pro aplikace integrace první strany, ujasněte své organizaci, že by měl být zahájen správný vývojový projekt, a to požadavkem na nové vyhrazené prostředí, kde existuje jasná komunikace o záměru a podpoře mezi vývojáři a správci. Následující část obsahuje více podrobností o automatizovaném vytváření prostředí, což je jen jeden způsob, jak implementovat snadný proces formálního požadavku.

  • Vývojová / testovací / provozní prostředí pro konkrétní obchodní skupiny nebo aplikace.
    Fázované prostředí zajišťuje, že změny během vývoje nepoškodí uživatele v provozním prostředí a nenaruší data. Když jsou zdroje omezené, zaměřte se na tento model pro kritické a důležité aplikace nebo na obchodní jednotky, které mají největší potřebu vlastního vyhrazeného prostoru.

  • Prostředí pro individuální použití při dokazování a školení.
    Pokud chcete pořádat workshopy, hackatony a interní školení – jako App in a Day or Flow in a Day – vytvořte pro akci nové, oddělené prostředí, které zajistí uspořádání pro všechny. Požádejte uživatele, aby po události krátkodobě uložili zdroje, které potřebují, a vyčistili prostředí nebo jej resetovali pro jiné události. Použijte zkušební prostředí, která nevyužívají kapacitu pro tyto typy aktivit.

  • Stanovení zásad ochrany před únikem informací (DLP) na úrovni klienta a prostředí
    Zásady ochrany před únikem informací (DLP) fungují jako zábradlí, které pomáhá uživatelům zabránit v neúmyslném odhalení dat organizace a chránit zabezpečení informací v klientovi. Podstatná součást role správce Power Platform bude zavést a udržovat zásady DLP na úrovni klienta a prostředí.

Doporučujeme odstupňovaný přístup k provozním prostředím týmu a uživatele.

Abychom podpořili integraci, snížili počet potřebných prostředí a urychlili registraci, doporučujeme vytvořit několik sdílených prostředí, která mohou využívat jednotlivci i týmy.

Výchozí prostředí

Všichni ve vašem klientovi mají oprávnění k vytváření aplikací a toků zde. V současné době neexistuje způsob, jak blokovat přiřazení role tvůrce prostředí v tomto prostředí. Toto je také prostředí, které se používá pro integrace první strany, jako je vytváření aplikace ze seznamu SharePoint. Více informací: Výchozí prostředí

Aby se snížilo riziko pro data, typy konektorů používaných ve vašich aplikacích a tocích by měly být omezeny na méně tolerantní zásadu ochrany před únikem informací (DLP). Tato zásada by měla pokrývat běžné případy použití produktivity jednotlivců a malých týmů, jako je práce s daty SharePoint, odesílání e-mailů a pracovní postup schválení.

Prostředí pro pokročilé uživatele

Zatímco výchozí prostředí pokrývá mnoho případů použití, někteří pokročilí uživatelé budou mít pokročilejší potřeby svých aplikací a toků, jako je integrace s Microsoft Teams, Microsoft Entra ID nebo Azure DevOps.

Z tohoto důvodu doporučujeme vytvořit prostředí pro zkušené uživatele. Toto sdílené prostředí by mělo používat tolerantnější zásady DLP a správci by měli řídit seznam tvůrců tohoto prostředí.

Některé aspekty ke zvážení pro prostředí pro pokročilé uživatele:

  • Zkontrolujte dostupné konektory v tomto prostředí a ujistěte se, že je pro vaše uživatele vhodný.
  • Zdokumentujte účel a dostupné konektory v tomto prostředí jasně - například na webu SharePoint nebo wiki.
  • Vytvořte automatizovaný proces, který tvůrcům umožní požádat o přístup k prostředí pro pokročilé uživatele - například pomocí Microsoft Forms webu SharePoint nebo aplikace. V případě potřeby může tento proces zahrnovat schválení nadřízeným nebo IT.

Vlastní prostředí

Zatímco sdílená prostředí pokrývají mnoho případů použití pro aplikace, týmy a projekty mohou těžit z toho, že mají vlastní prostředí pro podporu případů použití specifických pro obchodní jednotky nebo scénářů správy životního cyklu aplikace.

Některé aspekty pro vlastní prostředí:

  • Spolupracujte s projektovými týmy nebo obchodními jednotkami a zjistěte, zda vyžadují vyhrazené vývojové, testovací a produkční prostředí nebo zda je pro jejich použití vhodnější vyhrazené vývojové prostředí a sdílené testovací a produkční prostředí.
  • Zvažte vyhrazená prostředí pro kritické projekty a pracovní zatížení. Vývojáři mají přístup tvůrce prostředí ve vývojovém prostředí, ale pouze přístup uživatelů v testovacím a produkčním prostředí. Koncoví uživatelé mají pouze přístup koncového uživatele k produkčnímu řešení, takže nikdo nemůže upravit produkční aplikace.
  • Uvažujte o sdílení testovacího a produkčního prostředí mezi důležitými, ale středně složitými aplikacemi. Jednotlivé projekty a obchodní jednotky mají vlastní vývojové prostředí pro ochranu dat, ale řešení jsou nasazena do sdílených testovacích a produkčních prostředí. Vývojáři jsou koncoví uživatelé v testovacím prostředí a koncoví uživatelé mají pouze základní uživatelský přístup k řešením a datům v produkčním prostředí.
  • Spolupracujte s obchodní jednotkou, abyste zjistili, které konektory jsou požadovány, a vytvořte zásadu výjimek.
  • Spolupracujte s obchodní jednotkou a určete, kdo bude v tomto prostředí tvůrcem a kdo bude správcem prostředí.
  • Každé prostředí spotřebovává 1 GB datové kapacity, takže spravujte vlastní prostředí moudře.

Kromě výše uvedených doporučení bude vaše strategie v oblasti prostředí také formovat a řídit vaši strategii DLP.

  • Každý je tvůrcem. Dejte všem vědět, že výchozí neslouží k vývoji kritických aplikací.
  • Přístup má pouze jeden uživatel. Prostředí pro vývojáře jsou zcela uzamčena pro všechny ostatní uživatele kromě uživatele, který se přihlásil k odběru komunitního plánu. V případě potřeby lze aplikace z prostředí přesunout.
  • Schválení uživatelé mají přístup. Sdílená prostředí pro scénáře produktivity uživatelů a týmů se seznamem schválených tvůrců.
  • Vyhrazená prostředí pro kritické projekty a pracovní zatížení. Vývojáři mají přístup tvůrce prostředí ve vývojovém prostředí, ale pouze přístup uživatelů v testovacím a produkčním prostředí. Koncoví uživatelé mají pouze přístup koncového uživatele k produkčnímu řešení, takže nikdo nemůže upravit produkční aplikace.
  • Sdílená testovací a produkční prostředí pro důležité, ale středně složité aplikace. Jednotlivé projekty a obchodní jednotky mají vlastní vývojové prostředí pro ochranu dat, ale řešení jsou nasazena do sdílených testovacích a produkčních prostředí. Vývojáři jsou koncoví uživatelé v testovacím prostředí a koncoví uživatelé mají pouze základní uživatelský přístup k řešením a datům v produkčním prostředí.

Další doporučení ke správě prostředí

Na základě úspěšných zkušeností se zapojením zákazníků je zde uveden seznam dalších doporučení, která mohou usnadnit správu prostředí.

  • K nasazení produkčních řešení použít účet služby: Vytvořte účet služby, který centrální IT spravuje pro nasazení v testovacím a produkčním prostředí. To je z mnoha důvodů přínosné:

    • Umožňuje všem členům IT spravovat zdroje správce (například testovací a provozní prostředí).
    • Pouze účet služby má oprávnění správce v prostředí.
    • Všichni ostatní uživatelé mají oprávnění koncového uživatele a nemohou vytvářet nové zdroje - to je důležité, protože pokud mají uživatelé přístup k datovému připojení, mohou vytvořit jakékoli nové rozhraní pro interakci s daty, která vývojář nezamýšlel.
    • Oddělení IT si je vědomo produkčních aplikací, které jsou nasazeny, protože jsou zapojeny do implementace.
    • Budou potřeba účty služby Microsoft Power Platform nebo oprávnění správce služby Dynamics 365 v PIM. Podle potřeby přiřaďte další licence v závislosti na tom, jaké konektory je třeba použít v procesu žádosti (například zda se používají Dataverse a Outlook, přiřadit prémiové Power Apps a Office Enterprise).
    • Při zobrazení podrobností o aplikaci se účet služby zobrazí jako autor, nikoli jako tvůrce. To pomůže koncovým uživatelům zjistit, na koho se obrátit v případě problémů s aplikací.

    Zvažte, zda jsou pro vás rizika spojená s účtem služby důležitá. Některým organizacím nevyhovuje účet služby, protože například sdílený zdroj s oprávněními správce nelze vysledovat k jedné osobě. To je platné, ale lze jej zmírnit kroky, jako je vynucení podmíněného přístupu založeného na poloze, sledování protokolů auditu podle IP nebo rozsáhlejší metody, jako je udržování zabezpečené pracovní stanice, která vyžaduje identifikaci uživatele během používání a omezení přístupu k účtu služby na toto zařízení.

  • Snížení počtu sdílených vývojových prostředí

    Mějte samostatná prostředí pro vývoj samostatných projektů, zejména při práci se zabezpečenými daty. Prostředí jsou kontejnery pro zdroje, jako jsou připojení k datům a ve vývojových prostředích může být více lidí s přístupem tvůrce prostředí. Pokud mají tvůrci přístup ke sdílenému datovému připojení a mohou vytvářet aplikace a toky, existuje riziko, že někdo vytvoří nové rozhraní pro čtení, aktualizaci a mazání dat, ke kterým mohl mít přístup. To je obzvláště důležité mít na paměti pro výchozí prostředí - vždy byste měli mít důležitá datová připojení, vlastní konektory a další zdroje, které vyžadují zabezpečení v izolovaných prostředích, aby byly chráněny.

  • Sdílení zdrojů se skupinami zabezpečení Microsoft Entra

    Ke správě přístupu lze použít skupiny zabezpečení Power Apps, toky, role zabezpečení Dataverse a ostatní služby Office 365 jako SharePoint Online. Tím se odstraní zatížení správce spojené s aktualizací přístupu k jednotlivým koncovým uživatelům pro každou komponentu (zejména pokud se jedná o více uživatelů) - vlastníci aplikace to mohou upravit na úrovni skupiny zabezpečení bez IT (pokud IT neomezuje přístup ke správě skupiny zabezpečení).

  • Automatizace vytváření prostředí

    Konektory správce (Microsoft Power Platform for Admins) umožňují vytvořit tok schválení, kde uživatelé požadují prostředí, když IT omezilo vytváření prostředí na správce. Centrální IT může zkontrolovat požadavek a schválit nebo odmítnout vytvoření prostředí, aniž by byl zodpovědný za ruční přechod do centra pro správu a vytvoření prostředí pro uživatele, jen pro ověření podrobností požadavku, obchodního odůvodnění, požadavků DLP a toho, zda je k dispozici dostačující kapacita.

  • Vytvoření dočasných vývojových prostředí

    Jak již bylo zmíněno, doporučuje se co nejvíce oddělit vývojová prostředí a konkrétně se vyhnout současnému vývoji aplikací pro kritická řešení ve výchozím prostředí. Pokud jsou prostředí vytvořena pro účely vývoje, stanovte termín, jak dlouho by mělo být prostředí k dispozici vývojářům, a vytvořte proces pro jejich zálohování a odebrání.

  • Méně je někdy více

    I když je důležité zajistit, aby byly zdroje rozumně rozděleny mezi projekty a obchodní jednotky využívající prostředí, je stále důležité najít dobrou rovnováhu mezi zabezpečením a proveditelností. Správa sdílených testovacích a produkčních prostředí je dobrý způsob, jak usnadnit větší počet důležitých řešení při zachování kapacity a dodržování osvědčených postupů. To udržuje omezená oprávnění, protože test a produkce mají omezená oprávnění prostředí, a proto koncoví uživatelé nemohou upravovat aplikace.

  • Zřizování prostředí s instancemi Dataverse v příslušné oblasti

    Ve společnostech, kde zaměstnanci pracují ve více zemích/oblatech, mohou existovat určité aspekty dodržování předpisů, pokud jde o to, kde jsou data ukládána a odesílána mezi zeměmi/oblastmi. Pokud má prostředí instanci Dataverse, data se fyzicky ukládají v oblasti. Zkontrolujte seznam podporovaných oblastí prostředí.

Faktory, které ovlivňují zřizování

Některé faktory ovlivňují, kdy zřizovat jaké typy prostředí:

  • Definované úrovně podpory aplikací

    Úroveň složitosti, to, jak kritická je aplikace a uživatelé ovlivnění aplikací (například měsíčně aktivní uživatelé / celkový počet uživatelů v organizaci) jsou všechna důležitá opatření, jak zřídit prostředí na podporu všech scénářů.

    Různé typy aplikací by měly být odděleny v různých prostředích podle toho, jak kritické jsou.

       
    Kritické aplikace. Použití kritických scénářů a/nebo vysoce složité použití a/nebo použití na úrovni celé organizace. Podpora vlastněná IT. Robustní ALM proces (vývojový/zkušební/provozní). Delší vývojový cyklus, často i více než 3 měsíce na minimum životaschopného produktu.
    Důležité aplikace. Důležité, ale ne kritické a/nebo středně složité a/nebo na obchodní jednotku zaměřené aplikace. Podpora vlastněná vlastníkem aplikace nebo obchodní jednotkou, schválená IT. Prostředí využívající ALM se doporučuje, ale nemusí být nutné. Vývoj obvykle za méně než tři měsíce na minimální životaschopný produkt.
    Aplikace produktivity. Aplikace produktivity, která nevyžaduje vysokou úroveň správy. Podpora vývojářem aplikací. Správa životního cyklu aplikace obvykle není nutná. Méně než dva týdny na minimum životaschopného produktu.

  • Kapacita

    Každé prostředí (kromě zkušebního a vývojářského prostředí) spotřebuje na počáteční zřízení 1 GB. To může být omezením pro zřizování prostředí, pokud vaše organizace neplatí za prémiové licence Power Apps nebo Dynamics 365 a je to také sdílená kapacita napříč klientem, která musí být přidělena těm, kdo ji potřebují.

    Kapacitu ušetřete pomocí:

    • Správa testovacích a produkčních prostředí. Na rozdíl od sdílených vývojových prostředí by oprávnění v testovacím a produkčním prostředí měla být omezena na přístup koncového uživatele pro testování.
    • Automatizujte vyčištění dočasných vývojových prostředí a podpořte používání zkušebních prostředí pro testování nebo pro práci na konceptu.

  • Zapojení správce

    Není vždy možné zapojit centrální IT do každého vývojového projektu probíhajícího v celém klientovi, zvláště pokud je tým IT menší nebo je třeba spravovat větší podnik.

    Snižte zátěž správce takto:

    • Automatizace vytváření prostředí, takže správce klienta musí pouze schválit požadavek.
    • Automatizace vyčištění vývojového prostředí s dočasnými prostředími.

Jasně sdělte strategii prostředí tvůrcům ve vaší organizaci.

Zřiďte web SharePoint nebo wiki, který jasně komunikuje:

  • Účel výchozího prostředí.
  • Účelem prostředí sdíleného týmu a produktivity uživatelů je kromě dalších sdílených prostředí umožnění tvůrcům přístupu k (například školicím prostředím) a proces, jak požádat o přístup k těmto prostředím.
  • Účel zkušebních prostředí a způsob, jak o ně požádat.
  • Účel prostředí pro vývojáře a způsob, jak je vytvořit
  • Proces vyžádání vlastních prostředí pro konkrétní obchodní jednotku nebo pro účely projektu.
  • Odpovědnosti tvůrce:
    • Dbejte na čištění klienta. Odstraňujte prostředí, aplikace a toky, pokud již nejsou potřeba. Pokud experimentujete, použijte testovací prostředí.
    • Sdílejte moudře. Dávejte pozor na nadměrné sdílení vašich prostředí, aplikací, toků a sdílených připojení.
    • Chraňte data organizace. Vyvarujte se přesunu dat z vysoce důvěrných nebo důvěrných zdrojů dat do nechráněného nebo externího úložiště.

Jasně sděltezásady DLP vaší organizace tvůrcům.