Comparteix a través de

Guia per compartir fluxos al núvol i permisos

Aquesta guia pot ajudar a identificar escenaris adequats per compartir fluxos i establir permisos per gestionar l'accés dels usuaris i garantir la seguretat.

Administrar permisos i funcions en Power Automate entorns

Gestionar qui pot crear, editar o simplement executar fluxos és fonamental per mantenir un entorn segur i ordenat Power Automate . Power AutomateEl model de seguretat de funciona en diversos nivells de permisos:

  • Funcions de nivell d'entorn (com ara administrador de l'entorn i creador de l'entorn): regeixen la capacitat d'un usuari per administrar o crear recursos en un entorn determinat.
  • Dataverse funcions de seguretat (si l'entorn té una Dataverse base de dades): com ara l'usuari bàsic, el personalitzador del sistema i altres, que controlen l'accés a dades i entitats. Per exemple, els usuaris solen necessitar almenys la funció d'usuari bàsic per executar aplicacions o fluxos que utilitzen Dataverse dades.
  • Permisos al nivell de flux: comparteix la configuració de fluxos individuals que converteix altres usuaris en copropietaris (amb drets d'edició) o usuaris només d'execució.

Funcions i seguretat de l'entorn

En cada entorn, només els usuaris amb les funcions adequades poden crear o administrar recursos.

  • Administrador de l'entorn: té control administratiu total sobre l'entorn. Un administrador de l'entorn pot administrar tots els recursos, inclosa la visualització de tots els fluxos, l'addició i eliminació d'usuaris i la configuració de polítiques. En entorns sense Dataverse, només aquesta funció pot realitzar tasques d'administració. En entorns habilitats Dataverse, una funció d'administrador del sistema té Dataverse un propòsit similar per a les operacions de dades.

  • Creador d'entorns: aquesta funció permet als usuaris crear recursos nous, com ara fluxos, aplicacions i connexions a l'entorn. La funció de creador d'entorns no concedeix accés a les dades existents Dataverse, només confereix la capacitat de crear i compartir artefactes. Microsoft segueix un model de privilegis mínims per a funcions predefinides: Environment Maker té l'accés mínim necessari per crear aplicacions o fluxos sense exposar dades que no poden mostrar. Els creadors poden compartir les aplicacions/fluxos que creen amb altres persones de l'organització segons sigui necessari, però no poden elevar els seus propis privilegis per llegir dades tret que se'ls donin funcions addicionals Dataverse .

  • Usuari de l'entorn (usuari bàsic): en entorns recolzats Dataverse, els usuaris finals habituals han de tenir la funció de seguretat d'usuari bàsic (de vegades anomenada Common Data Service usuari) per executar aplicacions o utilitzar fluxos que interactuïn amb Dataverse les dades. Per defecte, afegir un usuari a un entorn, especialment si l'entorn té una Dataverse base de dades, pot requerir l'assignació explícita d'aquesta funció. Això garanteix que puguin executar les solucions, però només amb privilegis bàsics sobre les dades. En entorns sense Dataverse, si un usuari comparteix un flux només d'execució, és possible que no aparegui a la llista d'usuaris de l'entorn tret que s'afegeixi manualment. Els seus permisos són únicament a través de l'ús compartit de fluxos.

Permisos de compartició al nivell de flux

Al nivell de flux individual, els propietaris poden compartir un flux de núvol de dues maneres principals: afegir copropietaris o assignar usuaris només d'execució. És essencial entendre la diferència.

  • Propietari/copropietari: un copropietari té essencialment els mateixos privilegis que el creador original del flux. Els copropietaris poden veure l'historial d'execucions, editar el disseny del flux, canviar-ne la configuració, iniciar i aturar el flux, gestionar les connexions i afegir o suprimir altres propietaris. En altres paraules, es dóna el control total a qualsevol copropietari, excepte que no poden eliminar el creador original. Els copropietaris també mostren el flux a la llista de fluxos d'equip i poden gestionar-lo com qualsevol flux que hagin creat ells mateixos. A causa de l'amplitud d'aquests permisos, només s'han d'afegir persones o grups de confiança com a copropietaris.

    Exemple: si l'Alice és copropietària del flux d'en Bob, l'Alícia pot modificar-lo o suprimir-lo, de manera que l'equip d'en Bob només hauria d'afegir l'Alícia si es pretén aquest accés.

  • Usuari només d'execució: un usuari només d'execució està restringit a executar el flux, normalment mitjançant un activador manual com un activador de botó o SharePoint d'element. No poden obrir el flux en mode d'edició, veure la seva lògica interna ni veure l'historial d'execució anterior. Això és ideal per a escenaris en què es vol que els companys es beneficiïn de l'automatització. Per exemple, executeu un flux de botons o una tasca de processament de dades instantània sense donar-los privilegis de disseny. Els usuaris només d'execució mostren el nom del flux i poden executar-lo, però si intenten inspeccionar els detalls, tenen una visibilitat limitada. Tampoc poden afegir altres ni alterar el flux de cap manera.

    Exemple: Un servei d'assistència té un Power Automate flux de botons per crear un till i enviar una confirmació. Tots els empleats de primera línia s'afegeixen com a usuaris només d'execució perquè puguin activar el flux des dels seus dispositius, però no poden canviar el que fa el flux.

Funcions de seguretat específiques del recurs versus de l'entorn

Les funcions d'entorn i els permisos de compartició de flux funcionen en conjunt. Ser administrador de l'entorn o tenir certs Dataverse privilegis pot permetre als usuaris veure o modificar els fluxos independentment de l'ús compartit explícitament, a causa del seu ampli accés.

  • Un Power Platform administrador o administrador de l'entorn pot mostrar i gestionar tots els fluxos de l'entorn, fins i tot si no es comparteixen individualment amb ells. Per exemple, un administrador global es pot afegir com a propietari a qualsevol flux si cal.
  • Per contra, un usuari sense rol d'entorn pot tenir accés a un flux específic mitjançant l'ús compartit. En aquest cas, aquest usuari es converteix en un participant de cas especial en aquest flux, però pot ser que no tingui accés a altres recursos de l'entorn.

Per gestionar els permisos de manera eficaç, les organitzacions haurien de formalitzar quins usuaris són creadors de flux i quins consumidors de flux* (corredors) i, a continuació, aplicar els rols en conseqüència. Les seccions següents expliquen les pràctiques recomanades per implementar aquestes distincions i minimitzar el risc.

Nivells de permisos en Power Automate: propietaris versus usuaris només d'execució

Un aspecte clau de la gestió de la seguretat del flux és entendre les capacitats dels diferents nivells de permisos d'ús compartit. A la taula següent es resumeixen les diferències entre els copropietaris i els usuaris només d'execució per a un flux de núvol. Compara els permisos i les capacitats Power Automate del copropietari del flux amb els d'usuari només d'execució.

Capacitat / Accés Copropietari (pot editar) Usuari només d'execució (es pot executar)
Visualitzar i editar la definició del flux Sí. Té accés complet per veure i modificar els passos, la configuració i les connexions del flux. No. No es pot obrir el flux a l'editor ni obtenir la seva configuració. Només tenen la interfície d'execució.
Executar/activar el flux Sí. Pot executar manualment el flux i modificar els triggers. Sí. Pot activar el flux (per exemple, seleccionar el botó o utilitzar l'acció d'activació designada) segons ho permeti el propietari del flux.
Visualitzar l'historial d'execució (registres d'execució) Sí. Pot veure les execucions anteriors, l'estat d'èxit i fracàs i les sortides a l'historial d'execucions. No. No es pot visualitzar l'historial d'execució del flux ni els detalls de les execucions anteriors.
Gestiona el flux (activa/desactiva, canvia el nom, suprimeix) Sí. Pot canviar les propietats del flux, activar-lo o desactivar-lo, actualitzar les connexions i suprimir el flux completament. No. No es poden fer canvis a l'estat ni a la configuració del flux. Només tenen permís per invocar-lo.
Comparteix el flux amb altres persones Sí. Pot afegir o suprimir altres copropietaris, excepte que no poden suprimir el creador original. També pot assignar usuaris només d'execució. No. No puc compartir el flux amb ningú més. Són beneficiaris de l'accés, no concessionaris d'accés.
Utilitzar connexions pròpies (invoker) N.P.. Els copropietaris utilitzen les connexions definides del flux. Poden actualitzar les connexions si cal. Depèn. És possible que els usuaris de només execució hagin d'utilitzar les seves pròpies connexions quan s'executen si el flux està configurat amb Proporcionat per un usuari de només execució per a un connector. En cas contrari, el flux utilitza les connexions del propietari.
Visibilitat a la Power Automate interfície d'usuari Apareix a Fluxos d'equip per a tots els propietaris. El nom del copropietari apareix a la llista de propietaris . Apareix a la llista d'usuaris només d'execució del flux (pàgina de detalls del flux) per als propietaris; no obstant això, els usuaris només d'execució reben el flux només en contextos on poden executar-lo (per exemple, en un botó o dins d'una aplicació; no apareixen als seus fluxos de propietat o d'equip).

A la pràctica, aquestes distincions signifiquen que els copropietaris s'han de limitar als usuaris que realment necessiten col·laborar en el disseny o el manteniment d'un flux, mentre que es prefereix compartir només l'execució per a una àmplia distribució de la funcionalitat d'un flux. La guia de Microsoft reforça això: "Afegiu només copropietaris per a la col·laboració de flux segons sigui necessari. En la majoria dels casos, si cal compartir un flux, compartiu-lo amb permisos de només execució". Això garanteix que els usuaris puguin beneficiar-se de l'automatització sense arriscar-se a modificacions no autoritzades o a l'exposició de fluxos interns.

Mitigar els riscos de compartir fluxos fora del seu entorn

Permetre que els usuaris que no són membres de l'entorn accedeixin als fluxos pot introduir alguns riscos:

  • Punts cecs de governança: és possible que els administradors no s'adonin de qui té accés.
  • Exposició potencial de dades: si els fluxos gestionen dades sensibles.
  • Accés només d'execució: podria ser un problema si els triggers permeten la visibilitat d'entrada o sortida de paràmetres i la pèrdua de control de canvis. Això és quan els copropietaris fora de l'equip fan edicions no desitjades.

Per mitigar aquests riscos, les organitzacions haurien d'adoptar una combinació de polítiques, controls tècnics i supervisió.

  • Aplicar controls d'accés a l'entorn: una pràctica recomanada fonamental és restringir la pertinença a l'entorn mitjançant Microsoft Entra grups de seguretat (Azure AD). En associar un grup de seguretat amb un entorn, només es poden afegir usuaris d'aquest grup a les funcions de l'entorn. Això vol dir que, fins i tot si un creador intenta compartir un flux amb algú de fora del grup, aquesta persona no s'afegeix a l'entorn automàticament. En entorns amb un grup de seguretat associat, qualsevol usuari que no estigui al grup és essencialment un foraster i té capacitats limitades fins que un administrador concedeix accés. Aquesta configuració impedeix que els externs accedeixin als recursos de l'entorn tret que un administrador els afegeixi explícitament afegint-los al grup de seguretat per política.

    Per exemple, si l'entorn de HR Apps Contoso està vinculat al HR-Team grup de seguretat, un usuari de Finance no es pot convertir en copropietari d'un flux tret HR Apps que un administrador l'afegeixi primer al HR-Team grup. L'ús de grups de seguretat d'aquesta manera ajuda les organitzacions a mantenir un límit clar de qui està aprovat per utilitzar cada entorn.

  • Revisar i limitar la copropietat: Compartir fluxos amb copropietaris s'ha de fer amb moderació. Cada copropietari es converteix efectivament en propietari ple del flux, així que limiteu el nombre de copropietaris només als necessaris. Si un flux s'ha compartit amb una persona externa, per exemple, un desenvolupador o un consultor d'un altre equip per resoldre problemes, assegureu-vos de suprimir la seva copropietat un cop resolt el problema. Fes-ho tret que hi hagi una necessitat contínua. Les organitzacions poden implementar processos de governança on l'addició d'un copropietari fora de l'entorn activa una alerta o requereix aprovació. Això es pot aconseguir mitjançant Power Automate eines de governança (per exemple, un flux d'administració que utilitza els connectors d'administració Power Platform per detectar quan s'afegeix un nou propietari a un flux). Després, ho notifiquen a TI o a un Power Platform equip del Centre d'Excel·lència.

  • Preferiu l'ús compartit només d'execució per a usuaris externs: si compartir amb usuaris que no són membres de l'entorn és inevitable o justificat, utilitzeu permisos de només execució sempre que sigui possible en lloc de drets d'edició complets. L'accés només d'execució redueix significativament el risc: l'usuari no pot veure la lògica del flux ni modificar-la, i obté dades d'execució anteriors, que poden contenir càrregues sensibles.

    Per exemple, si un flux envia dades del client per correu electrònic, un usuari només d'execució pot activar l'enviament de correu electrònic, però no pot obrir el flux per obtenir els detalls del client que es van processar ahir. Aquest principi s'alinea amb el privilegi mínim: doneu l'accés mínim necessari per a la funció de l'usuari. L'ús compartit només d'execució sovint pot assolir el requisit empresarial de permetre que algú activi o utilitzi un flux sense lliurar el control.

  • Utilitzar funcions de seguretat per segmentar tasques: assegureu-vos que els usuaris que només han d'executar fluxos però no crear-los no tinguin la funció de creador d'entorns. Si manteniu aquests usuaris com a usuaris bàsics de l'entorn o completament fora de l'entorn amb accés només al flux d'execució, reduïu la possibilitat que puguin crear o importar fluxos no autoritzats. Només els creadors designats haurien de tenir privilegis de fabricant, mentre que altres només podrien consumir les sortides dels fluxos.

    Obteniu més informació a Utilitzar funcions i grups de seguretat: administrar els creadors en comparació amb els usuaris de només execució.

  • Implementar polítiques de prevenció de pèrdua de dades (DLP): tot i que les polítiques DLP tenen més a veure amb el control de l'ús del connector, indirectament ajuden a mitigar el risc evitant que els fluxos compartits utilitzin connectors prohibits. Per exemple, si a un extern se li dóna accés només d'execució a un flux, una política DLP estricta garanteix que el flux no pugui començar a enviar dades a un servei no autoritzat. DLP no atura l'ús compartit en si, però limita el dany potencial si un flux s'utilitza accidentalment o intencionadament. Com a pràctica recomanada, classifiqueu els connectors en categories empresarials i no empresarials i bloquegeu qualsevol combinació perillosa. D'aquesta manera, fins i tot si els fluxos es comparteixen àmpliament, no filtraran dades a punts finals no aprovats.

  • Auditoria i supervisió periòdiques: establiu una rutina (per exemple, mensual o trimestral) per auditar els permisos de flux. Com a part d'aquesta revisió, identifiqueu els fluxos que tinguin una compartició inusual, especialment els que tenen propietaris externs o grans llistes d'usuaris només d'execució. Reviseu-los si encara són necessaris. La documentació de Microsoft fomenta les revisions periòdiques dels permisos per assegurar-se que s'alineen amb les necessitats empresarials actuals i per eliminar l'accés als usuaris que ja no ho necessiten.

    La supervisió es pot automatitzar. Per exemple, un administrador podria configurar un Power Automate flux mitjançant el connector d'administració que enviï un informe de tots els fluxos amb els seus propietaris i les dates de les últimes modificacions. El flux destaca els fluxos que tenen propietaris fora d'una llista especificada de persones aprovades. A més, considereu la possibilitat d'aprofitar els taulers Power Platform d'AdminAnalytics. Pot mostrar l'ús general i potencialment filtrar-se per saber quants usuaris executen cada flux.

  • Educar els creadors i fer complir les polítiques: de vegades el risc s'introdueix per la manca de consciència. Documenteu i comuniqueu una política clara sobre l'ús compartit, per exemple, no afegiu usuaris de fora de l'entorn X com a copropietaris sense aprovació. Utilitzeu l'accés només d'execució si cal per a usuaris de fora de l'equip. En formar Power Automate els creadors en aquestes directrius, reduïu l'exposició accidental. Si la vostra organització té una comunitat interna Power Platform o una xarxa de campions, compartiu recordatoris sobre les implicacions de compartir fluxos de manera àmplia. En última instància, els usuaris han d'entendre que, tot i Power Automate que facilita l'intercanvi, hi ha passos de compliment i seguretat que s'han de seguir per a qualsevol col·laboració entre entorns.

  • Utilitzeu entorns separats per compartir àmpliament: en alguns casos, pot ser prudent tenir un entorn dedicat per als fluxos que han de ser utilitzats per un públic ampli. Per exemple, una organització podria crear un entorn de serveis compartits obert a molts usuaris amb un grup de seguretat adequat. Els fluxos destinats a un consum ampli es poden desenvolupar i allotjar allà, en lloc de compartir-los des d'un entorn més restringit. D'aquesta manera, es mantenen els límits ambientals. Els vostres entorns altament controlats segueixen sent estrictes i l'entorn obert està dissenyat per a l'intercanvi multifuncional amb una supervisió adequada. Si adopteu aquesta estratègia, assegureu-vos que l'entorn obert encara tingui polítiques i supervisió DLP sòlides, ja que té una base d'usuaris més gran per disseny.

  • Si els usuaris d'un entorn diferent necessiten la funcionalitat d'un flux, un altre enfocament és exportar el flux com a paquet i compartir-lo en lloc de compartir-lo. Microsoft recomana aquest enfocament en escenaris en què l'usuari no és membre del vostre Power Automate entorn: podeu enviar-li una còpia del flux que importa al seu propi entorn. Aleshores, el destinatari estableix les seves pròpies connexions i executa el flux de manera independent. Això mitiga el risc evitant qualsevol accés directe al flux de l'entorn original. Essencialment, els dóna la solució sense donar-los un punt de suport al vostre entorn. La compensació és que les actualitzacions del flux no se sincronitzaran automàticament, ja que és una còpia independent. No obstant això, per a necessitats puntuals o compartint amb equips externs, aquest mètode garanteix una separació neta.

En resum, mitigar els riscos associats als fluxos compartits es redueix a un control estricte de l'accés a l'entorn, l'ús prudent de les opcions de compartició i una supervisió vigilant. En combinar salvaguardes tècniques (com ara entorns controlats per grups de seguretat i polítiques DLP) amb salvaguardes de processos (com aprovacions per afegir propietaris i auditories periòdiques), les organitzacions poden gaudir dels beneficis col·laboratius alhora que minimitzen els problemes de Power Automate seguretat i compliment.

La següent secció se centra en un aspecte específic de la governança: l'ús de rols i grups per definir qui és un creador versus qui és simplement un corredor de fluxos.

Utilitzar funcions de seguretat i grups: administrar els creadors en comparació amb els usuaris de només execució

Una decisió crítica de governança és determinar quins usuaris han de ser creadors, qui poden crear i posseir fluxos, i quins s'han de limitar a córrer fluxos, qui potser pot consumir els resultats. Power Automate i ofereixen Power Platform diversos mecanismes per fer complir aquesta distinció, principalment a través de rols de seguretat i grups de seguretat.

Distingir els fabricants dels no fabricants

En un escenari empresarial, no tots els usuaris amb una Power Automate llicència haurien de crear necessàriament fluxos en tots els entorns. Per disseny, un creador d'entorns pot crear fluxos i altres recursos en aquest entorn. Per als entorns dedicats, heu d'assignar intencionadament la funció de creador d'entorns només als usuaris o grups responsables de crear solucions. Per exemple, podeu decidir que a l'entorn d'automatització financera, només l'equip de TI financer i alguns usuaris avançats tenen permisos de fabricant.

Apliqueu-ho fent el següent:

  • Assigneu la funció de seguretat de l'Environment Maker directament a usuaris específics a la configuració de l'entorn.
  • Utilitzeu un grup de seguretat de l'Azure Active Directory (AD). Afegiu tots els creadors previstos a un grup (per exemple, Grup de creadors de finances) i, si l'entorn no té cap Dataverse, assigneu-li a tot el grup la funció de creador d'entorns. En entorns habilitats Dataverse, és possible que hàgiu d'afegir membres del grup individualment o utilitzar equips de grup amb funcions de seguretat.
  • Per a un control ampli, associeu l'entorn amb un grup de seguretat de manera que només els membres puguin estar a l'entorn. A continuació, concediu rols de creador al subconjunt adequat. Aquest enfocament de dos nivells significa que els forasters no poden passar desapercebuts com a creadors, i entre els de diners, només alguns tenen el paper de creador. Les directrius de bona reputació suggereixen aplicar la característica del grup de seguretat de l'entorn a tots els entorns sensibles i de producció per evitar la presència d'usuaris no desitjats.

Utilitzar grups de seguretat per a l'accés només d'execució

Tot i que no hi ha una funció de només execució de l'entorn, podeu administrar els permisos de només execució a escala mitjançant grups. Quan comparteixin un flux, els propietaris poden introduir un nom de grup en lloc d'usuaris individuals per a l'accés de copropietari o només d'execució. Això vol dir que podeu crear un grup de seguretat com ara Usuaris de flux d'informes de vendes i assignar-lo com a usuari només d'execució en fluxos rellevants. Tots els membres del grup heretarien el permís d'execució per a aquests fluxos. La gestió es fa més fàcil. Per revocar l'accés d'un usuari concret, suprimiu-lo del grup. Perden l'accés d'execució a tots els fluxos als quals s'ha assignat aquest grup. De la mateixa manera, per concedir a una persona nova accés d'execució a diversos fluxos, afegiu-los al grup. Els grups de seguretat ajuden a simplificar la gestió de permisos externalitzant-la.

Power Automate els fluxos no necessiten enumerar 50 usuaris com a només d'execució; Enumeren un grup i el vostre Azure AD o Microsoft 365 administrador processa la pertinença.

Nota

Si l'entorn en si està bloquejat a un grup de seguretat, el grup utilitzat per a l'ús compartit de flux ha de ser el mateix o un subconjunt. Si compartiu un flux amb un grup que conté persones fora dels usuaris permesos de l'entorn, és possible que no puguin executar-lo, en funció de la configuració de l'entorn. Heu de coordinar l'ús del grup amb les normes d'accés a l'entorn.

Assignació de rols per a creadors versus corredors

En Dataverse entorns, les funcions de seguretat es poden superposar per ajustar el que poden fer els creadors versus els usuaris només d'execució.

  • Makers: com a mínim, necessiten la funció de creador de l'entorn per crear fluxos. Si els seus fluxos interactuen amb Dataverse les taules, també poden necessitar funcions addicionals Dataverse , com ara el personalitzador del sistema, o privilegis en taules específiques, per dissenyar-les i provar-les correctament. La combinació d'Environment Maker més una funció que concedeix accés a les dades (si cal) els permet crear solucions completes. És una bona pràctica concedir als fabricants només els privilegis que necessiten. Per exemple, si un fabricant només automatitza i envia SharePoint un correu electrònic, és possible que no necessiti cap Dataverse funció a part d'estar present a l'entorn. Tanmateix, si un creador crea un flux per actualitzar un Dataverse registre, necessita permís per a aquesta taula. Planifiqueu les vostres funcions de seguretat de manera que els creadors obtinguin una funció de dades de creador independent si cal, en lloc de donar-los funcions excessivement àmplies.
  • Usuaris només d'execució: aquests usuaris no necessiten el Creador d'entorns. Si l'entorn té una base de Dataverse dades i el flux toca Dataverse dades, pot ser que necessitin la funció d'usuari bàsic (o una altra) per tenir accés de lectura/escriptura a les dades subjacents quan el flux s'executa en el seu context. Per exemple, un flux d'activador manual pot crear un Dataverse registre en nom del corredor. Si és així, el corredor necessita permís per crear aquest registre. Quan s'utilitza l'opció L'usuari només d'execució proporciona connexió , el flux s'executa en el context de les credencials de l'usuari només d'execució. En aquests casos, heu d'assegurar-vos que aquests usuaris tinguin els drets mínims necessaris a través de Dataverse funcions o permisos del sistema rellevants per dur a terme les accions que executa el flux. Si el flux utilitza sempre la connexió del propietari, és possible que l'usuari només d'execució no necessiti Dataverse cap funció especial: està prement un botó i el flux utilitza el privilegi del propietari. Aquest matís s'ha de tenir en compte acuradament. Un enfocament segur és donar als usuaris de només execució accés de lectura a les dades que poden mostrar i res més. Moltes empreses creen una funció personalitzada Dataverse o utilitzen l'usuari bàsic amb drets de lectura mínims i l'assignen a tots els usuaris finals per satisfer aquest requisit d'executar aplicacions i fluxos.

Gestió de rols tenint en compte la governança

Feu un seguiment de qui té quin paper. Un Power Platform administrador pot enumerar tots els usuaris d'un entorn i les funcions de seguretat assignades des del centre d'administració o mitjançant el PowerShell. Això es pot creuar amb la llista esperada de fabricants. És una bona pràctica de governança mantenir un inventari, per exemple, Creadors d'Entorn X: Alice, Bob, Carol; Només execució de l'entorn X/consumidors: tots els usuaris del departament de màrqueting. En tenir claredat sobre això, quan arriba una sol·licitud per afegir un nou creador, podeu comprovar si estan aprovats pel grup o obtenir les aprovacions necessàries per ampliar el cercle.

Escenaris i exemples

La llista següent explica alguns escenaris i exemples de solucions per a ells.

  • Escenari: Un entorn departamental on només un equip petit hauria de crear fluxos, però molts del departament els executen.
  • Solució: el responsable de TI del departament rep l'administrador de l'entorn. Un Azure AD grup Dept Makers conté les cinc persones que creen aplicacions i fluxos. Aquest grup s'afegeix a la funció de creador de l'entorn. Això es fa directament o s'assignen les persones si l'assignació de grup no està disponible. Tots els membres del departament estan al grup d'usuaris del departament, que està associat amb l'entorn, de manera que tots tenen accés per ser usuaris. Els fluxos creats a l'entorn que han de ser executats per tot el departament es comparteixen amb el grup d'usuaris del departament com a només d'execució . D'aquesta manera, els creadors construeixen i comparteixen. Un membre del departament pot executar-se, però les persones que no són del departament no poden accedir-hi, ja que no estan al grup de l'entorn.
  • Escenari: un entorn de producció amb fluxos sensibles que no hauria de ser editat per ningú excepte dos propietaris de solucions.
  • Solució: Només aquests dos individus són creadors de medi ambient. Ningú més té el paper de creador. Si altres usuaris necessiten activar fluxos, se'ls dóna accés només d'execució. Possiblement, un compte de servei dedicat o una entitat de servei és en realitat el propietari dels fluxos per a l'estabilitat, amb els dos propietaris com a copropietaris per al manteniment. L'ús d'una entitat de servei com a propietari principal millora la governança dels fluxos crítics. Tots els empleats regulars no estan en aquest entorn o només tenen el rol d'usuari. L'entorn podria estar lligat a un grup de seguretat que contingui només els comptes necessaris per garantir encara més l'exclusivitat.
  • Escenari: un entorn de centre d'excel·lència on els equips de governança creen fluxos de supervisió en tots els entorns.
  • Solució: només hi té accés a l'equip del Centre d'Excel·lència. Són creadors de l'entorn per paper. No cal compartir només l'execució perquè aquests fluxos són més interns. Aquí, la seva gent crucial del Centre d'Excel·lència potser té el paper d'administrador a nivell d'inquilí Power Platform , que implícitament els dóna drets en tots els entorns.

Beneficis de la segregació de rols

Delineant clarament el fabricant versus el corredor, s'aconsegueix el següent:

  • Privilegi mínim: els usuaris només obtenen els permisos que necessiten. Un usuari només d'execució no pot començar de sobte a crear fluxos que evitin la supervisió de TI, perquè no tenen aquesta funció. Els creadors tenen llibertat per crear, però com que aquesta població és més petita i coneguda, podeu entrenar-los i vigilar-los més fàcilment.
  • Gestió simplificada del cicle de vida: quan un empleat deixa o canvia de rol, és més fàcil actualitzar l'accés. Per exemple, si Joe era un creador i s'allunya de l'equip, l'elimineu del grup de seguretat Makers. Perd instantàniament la capacitat de crear i editar en aquest entorn, mentre conserva l'accés d'execució si roman al grup d'usuaris. Aleshores podríeu afegir el seu substitut al grup Makers. Aquest manteniment basat en grups és més net que afegir i eliminar manualment desenes de permisos de flux.
  • Alineació de compliment: moltes regulacions demanen accés controlat. Ser capaç de mostrar a un auditor que només aquestes persones específiques poden modificar l'automatització en aquest entorn; tots els altres poden simplement desencadenar fluxos aprovats pot ajudar a demostrar forts controls interns. Els auditors també poden exportar assignacions de funcions ambientals com a prova de l'aplicació.
  • Eviteu confusions: si tothom tingués drets de fabricant, menys usuaris tècnics podrien crear o alterar fluxos sense voler, o confondre's amb la interfície Power Automate . En limitar el paper del fabricant, us assegureu que només el personal format dissenyi fluxos, cosa que pot reduir els errors.

Aquestes mesures s'han de revisar periòdicament. A mesura que canvien les necessitats empresarials, algú que és un consumidor pot necessitar convertir-se en un creador (per exemple, un usuari avançat sorgeix en un nou equip) o un creador pot necessitar convertir-se en un consumidor. El model de governança hauria de ser prou flexible per adaptar-se a això amb les aprovacions adequades. Documenteu els criteris per obtenir privilegis de creador d'entorns i el procés per sol·licitar-los, de manera que hi hagi transparència i coherència. De la mateixa manera, definiu quines condicions poden activar la revocació de l'accés del creador, per exemple, passar a un departament diferent.

Mitjançant l'ús de rols i grups de seguretat en tàndem, les organitzacions poden aconseguir una separació clara i mantenible entre els que creen l'automatització i els que utilitzen l'automatització. Això millora tant la seguretat com la productivitat en Power Automate els entorns.