Ceļvedis par mākoņplūsmas koplietošanu un atļaujām

Šī rokasgrāmata var palīdzēt identificēt piemērotus plūsmas koplietošanas scenārijus un noteikt atļaujas lietotāju piekļuves pārvaldīšanai un drošības nodrošināšanai.

Atļauju un lomu pārvaldība vidē Power Automate

Lai uzturētu drošu un sakārtotu Power Automate vidi, ir būtiski pārvaldīt, kas var izveidot, rediģēt vai vienkārši izpildīt plūsmas. Power AutomateDrošības modelis darbojas vairākos atļauju līmeņos:

Vides līmeņa lomas (piemēram, vides administrators un vides veidotājs): pārvalda lietotāja spēju pārvaldīt vai izveidot resursus noteiktā vidē.
Dataverse drošības lomas (ja vidē ir datu bāze Dataverse ): piemēram, pamata lietotājs, sistēmas pielāgotājs un citi, kas kontrolē piekļuvi datiem un entītijām. Piemēram, lietotājiem parasti ir nepieciešama vismaz pamata lietotāja loma, lai palaistu programmas vai plūsmas, kurās tiek izmantoti Dataverse dati.
Plūsmas līmeņa atļaujas: kopīgojiet iestatījumus atsevišķās plūsmās, kas padara citus lietotājus par līdzīpašniekiem (ar rediģēšanas tiesībām) vai tikai izpildes lietotājiem.

Vides lomas un drošība

Katrā vidē resursus var izveidot vai pārvaldīt tikai lietotāji ar atbilstošām lomām.

Vides administrators: pilnībā kontrolē vidi. Vides administrators var pārvaldīt visus resursus, tostarp skatīt visas plūsmas, pievienot un noņemt lietotājus, kā arī iestatīt politikas. Vidēs bez tās Dataverse, tikai šī loma var veikt administratora uzdevumus. Iespējotās Dataverse vidēs sistēmas administratora loma Dataverse kalpo līdzīgam nolūkam datu operācijām.
Vides veidotājs: šī loma ļauj lietotājiem vidē izveidot jaunus resursus, piemēram, plūsmas, programmas un savienojumus. Vides veidotāja loma nepiešķir piekļuvi esošajiem Dataverse datiem — tā tikai piešķir iespēju veidot un koplietot artefaktus. Microsoft izmanto minimālo privilēģiju modeli iepriekš definētām lomām: Vides veidotājam ir minimālā piekļuve, kas nepieciešama, lai izveidotu programmas/plūsmas, neatspoguļojot datus, kurus tās nav atļauts parādīt. Veidotāji pēc vajadzības var koplietot izveidotās programmas/plūsmas ar citiem organizācijas darbiniekiem, taču viņi nevar paaugstināt savas privilēģijas lasīt datus, ja vien viņiem nav piešķirtas papildu Dataverse lomas.
Vides lietotājs (pamata lietotājs): Dataverse vidēs regulāriem lietotājiem ir jāpiešķir pamata lietotāja drošības loma (dažreiz saukta Common Data Service par lietotāju), lai palaistu programmas vai izmantotu plūsmas, kas mijiedarbojas ar Dataverse datiem. Pēc noklusējuma, pievienojot lietotāju videi, it īpaši, ja videi ir datu bāze Dataverse , var būt nepieciešams skaidri piešķirt šādu lomu. Tas nodrošina, ka viņi var palaist risinājumus, bet tikai ar pamata privilēģijām attiecībā uz datiem. Vidēs bez tās Dataverse, ja lietotājs tiek koplietots tikai izpildei, tas var netikt parādīts vides lietotāju sarakstā, ja vien tas nav manuāli pievienots. Viņu atļaujas tiek sniegtas tikai caur plūsmas koplietošanu.

Individuālās plūsmas līmenī īpašnieki var koplietot mākoņplūsmu divos galvenajos veidos: pievienot līdzīpašniekus vai piešķirt tikai izpildes lietotājus. Ir svarīgi saprast atšķirību.

Īpašnieks/līdzīpašnieks: līdzīpašniekam būtībā ir tādas pašas privilēģijas kā sākotnējam plūsmas radītājam. Līdzīpašnieki var skatīt izpildes vēsturi, rediģēt plūsmas noformējumu, mainīt tās iestatījumus, sākt un apturēt plūsmu, pārvaldīt savienojumus un pievienot vai noņemt citus īpašniekus. Citiem vārdiem sakot, pilnīga kontrole tiek piešķirta jebkuram līdzīpašniekam, izņemot to, ka viņi nevar noņemt sākotnējo satura veidotāju. Līdzīpašnieki arī parāda plūsmu savā grupas plūsmu sarakstā un var to pārvaldīt tāpat kā jebkuru pašu izveidoto plūsmu. Šo atļauju plašuma dēļ kā līdzīpašniekiem jāpievieno tikai uzticamas personas vai grupas.

Piemērs: Ja Alise ir Boba plūsmas līdzīpašniece, Alise var modificēt šo plūsmu vai to izdzēst, tāpēc Boba komandai vajadzētu pievienot Alisi tikai tad, ja šāda piekļuve ir paredzēta.

Tikai palaišanas lietotājs: tikai palaišanas lietotājs var izpildīt plūsmu, parasti izmantojot manuālu trigeri, piemēram, pogu vai SharePoint vienuma trigeri. Viņi nevar atvērt plūsmu rediģēšanas režīmā, skatīt tās iekšējo loģiku vai skatīt iepriekšējo izpildes vēsturi. Tas ir ideāli piemērots scenārijiem, kuros vēlas, lai kolēģi gūtu labumu no automatizācijas. Piemēram, palaidiet pogu plūsmu vai tūlītēju datu apstrādes uzdevumu, nepiešķirot viņiem noformēšanas tiesības. Tikai izpildes lietotāji parāda plūsmas nosaukumu un var to palaist, bet, ja viņi mēģina pārbaudīt detaļas, viņiem ir ierobežota redzamība. Viņi arī nevar pievienot citus vai jebkādā veidā mainīt plūsmu.

Piemērs: palīdzības dienestam ir pogas plūsma Power Automate Izveidot biļeti un nosūtīt apstiprinājumu. Visi frontes darbinieki tiek pievienoti kā tikai palaišanas lietotāji, lai viņi varētu aktivizēt plūsmu no savām ierīcēm, bet viņi nevar mainīt plūsmas darbību.

Resursiem specifiska drošība salīdzinājumā ar vides lomām

Vides lomas un plūsmas koplietošanas atļaujas darbojas tandēmā. Vides administrators vai noteiktas Dataverse privilēģijas var ļaut lietotājiem skatīt vai modificēt plūsmas neatkarīgi no skaidras koplietošanas, pateicoties to plašajai piekļuvei.

Administrators vai vides administrators pēc būtības var parādīt un pārvaldīt visas plūsmas vidē, Power Platform pat ja tās nav atsevišķi kopīgotas ar viņiem. Piemēram, globālais administrators var pievienot sevi kā īpašnieku jebkurai plūsmai, ja nepieciešams.
Un otrādi, lietotājam, kuram nav vides lomas, var piešķirt piekļuvi noteiktai plūsmai, izmantojot koplietošanu. Šajā gadījumā lietotājs kļūst par īpašo gadījumu dalībnieku šajā vienā plūsmā, bet, iespējams, viņam nav piekļuves citiem vides resursiem.

Lai efektīvi pārvaldītu atļaujas, organizācijām ir jāformalizē, kuri lietotāji ir plūsmas veidotāji , bet kuri ir plūsmas patērētāji* (skrējēji), un pēc tam attiecīgi jālieto lomas. Turpmākajās sadaļās ir izskaidrota labākā prakse šo atšķirību ieviešanai un riska samazināšanai.

Atļauju līmeņi Power Automate — īpašnieki salīdzinājumā ar tikai palaišanas lietotājiem

Galvenais plūsmas drošības pārvaldības aspekts ir izpratne par dažādu koplietošanas atļauju līmeņu iespējām. Tālāk esošajā tabulā ir apkopotas atšķirības starp līdzīpašniekiem un tikai palaišanas lietotājiem mākoņa plūsmai. Tas salīdzina plūsmas līdzīpašnieku un tikai palaišanas lietotāju atļaujas un iespējas Power Automate.

Spēja / piekļuve	Līdzīpašnieks (var rediģēt)	Tikai palaišanas lietotājs (var palaist)
Plūsmas definīcijas skatīšana un rediģēšana	Jā. Ir pilnīga piekļuve, lai skatītu un modificētu plūsmas darbības, iestatījumus un savienojumus.	Nē. Nevar atvērt plūsmu redaktorā vai iegūt tās konfigurāciju. Viņi saņem tikai palaišanas saskarni.
Skrējiet/aktivizējiet plūsmu	Jā. Var manuāli palaist plūsmu un modificēt trigerus.	Jā. Var aktivizēt plūsmu (piemēram, atlasīt pogu vai izmantot norādīto trigera darbību), kā to atļauj plūsmas īpašnieks.
Izpildes vēstures skatīšana (izpildes žurnāli)	Jā. Var skatīt iepriekšējos skrējienus, veiksmes un neveiksmes statusu, kā arī izpildes vēstures izvades.	Nē. Nevar parādīt plūsmas izpildes vēsturi vai detalizētu informāciju par iepriekšējiem izpildiem.
Pārvaldīt plūsmu (iespējot/atspējot, pārdēvēt, dzēst)	Jā. Var mainīt plūsmas rekvizītus, ieslēgt vai izslēgt, atjaunināt savienojumus un pilnībā izdzēst plūsmu.	Nē. Nevar veikt izmaiņas plūsmas statusā vai iestatījumos. Viņiem ir tikai atļauja to izsaukt.
Plūsmas koplietošana ar citiem	Jā. Var pievienot vai noņemt citus līdzīpašniekus, izņemot to, ka viņi nevar noņemt sākotnējo satura veidotāju. Var arī piešķirt tikai palaišanas lietotājus.	Nē. Nevar koplietot plūsmu ar citu personu. Viņi ir piekļuves saņēmēji, nevis piekļuves saņēmēji.
Izmantot savus savienojumus (izsaukums)	NAV. Līdzīpašnieki izmanto plūsmas definētos savienojumus. Ja nepieciešams, viņi var atjaunināt savienojumus.	Atkarīgs. Tikai palaišanas lietotājiem, iespējams, būs jāizmanto savi savienojumi, ja plūsma ir konfigurēta ar savienotājam Nodrošina tikai palaišanas lietotājs . Pretējā gadījumā plūsma izmanto īpašnieka savienojumus.
Redzamība lietotāja saskarnē Power Automate	Parādās sadaļā Komandas plūsmas visiem īpašniekiem. Līdzīpašnieka vārds ir norādīts sarakstā Īpašnieki .	Tiek parādīts plūsmas sarakstā Tikai izpildīti lietotāji (detalizēta informācija par plūsmu) īpašniekiem; tomēr tikai izpildes lietotāji saņem plūsmu tikai kontekstos, kuros viņi to var palaist (piemēram, pogā vai programmā; nav norādīts viņu īpašumā esošajās vai grupas plūsmās).

Praksē šīs atšķirības nozīmē, ka līdzīpašniekiem vajadzētu būt tikai lietotājiem, kuriem patiešām ir jāsadarbojas plūsmas izstrādē vai uzturēšanā, savukārt plūsmas funkcionalitātes plašai izplatīšanai priekšroka tiek dota tikai izpildes koplietošanai. Microsoft norādījumi to pastiprina: "Pievienojiet līdzīpašniekus plūsmas sadarbībai tikai pēc vajadzības. Vairumā gadījumu, ja plūsma ir jākoplieta, kopīgojiet to ar tikai izpildes atļaujām. Tas nodrošina, ka lietotāji var gūt labumu no automatizācijas, neriskējot ar nesankcionētām izmaiņām vai plūsmas iekšējo elementu iedarbību.

Ļaujot lietotājiem, kas nav vides dalībnieki, piekļūt plūsmām, var rasties daži riski:

Pārvaldības aklās zonas: administratori var neapzināties, kam ir piekļuve.
Iespējamā datu iedarbība: ja plūsmas apstrādā sensitīvus datus.
Tikai izpildes piekļuve: var radīt bažas, ja trigeri atļauj parametru ievades vai izvades redzamību un izmaiņu kontroles zudumu. Tas ir tad, kad līdzīpašnieki ārpus komandas veic neparedzētus labojumus.

Lai mazinātu šos riskus, organizācijām jāpieņem politikas, tehniskās kontroles un uzraudzības kombinācija.

Vides piekļuves kontroles ieviešana: pamata paraugprakse ir ierobežot dalību vidē, izmantojot Microsoft Entra (Azure AD) drošības grupas. Sasaistot drošības grupu ar vidi, vides lomām var pievienottikai šīs grupas lietotājus. Tas nozīmē, ka pat tad, ja veidotājs mēģina koplietot plūsmu ar personu ārpus grupas, šī persona netiek automātiski pievienota videi. Vidēs ar saistītu drošības grupu jebkurš lietotājs, kas nav grupā, būtībā ir nepiederošais un tam ir ierobežotas iespējas, līdz administrators piešķir piekļuvi. Šī iestatīšana bloķē nepiederošo personu piekļuvi vides resursiem, ja vien administrators tos nepārprotami nepievieno, pievienojot tos drošības grupai katrai politikai.

Piemēram, ja Contoso HR Apps vide ir saistīta ar drošības grupu HR-Team , lietotājs no Finance nevar tikt padarīts par plūsmas HR Apps līdzīpašnieku, ja administrators viņu vispirms nav pievienojis HR-Team grupai. Šādā veidā izmantojot drošības grupas, organizācijas palīdz saglabāt skaidru robežu par to, kurš ir apstiprināts izmantot katru vidi.
Pārskatiet un ierobežojiet kopīpašumtiesības: plūsmu koplietošana ar līdzīpašniekiem jāveic taupīgi. Katrs līdzīpašnieks faktiski kļūst par pilntiesīgu plūsmas īpašnieku, tāpēc ierobežojiet līdzīpašnieku skaitu tikai tiem, kas nepieciešami. Ja plūsma tika kopīgota ar ārēju personu, piemēram, izstrādātāju vai konsultantu no citas komandas problēmu novēršanai, pārliecinieties, ka pēc problēmas novēršanas noņemat līdzīpašniekus. Dariet to, ja vien nav pastāvīgas vajadzības. Organizācijas var ieviest pārvaldības procesus, kuros, pievienojot līdzīpašnieku ārpus vides, tiek aktivizēts brīdinājums vai nepieciešams apstiprinājums. To var panākt, izmantojot Power Automate pārvaldības rīkus (piemēram, administratora plūsmu, kas izmanto Power Platform administrēšanas savienotājus, lai noteiktu, kad plūsmai tiek pievienots jauns īpašnieks). Pēc tam viņi paziņo IT vai izcilības centra komandai Power Platform .
Dod priekšroku tikai izpildes koplietošanai ārējiem lietotājiem: ja koplietošana ar lietotājiem, kas nav vides dalībnieki, ir neizbēgama vai pamatota, izmantojiet tikai izpildes atļaujas, ja iespējams, pilnu rediģēšanas tiesību vietā. Tikai izpildes piekļuve ievērojami samazina risku: lietotājs nevar skatīt plūsmas loģiku vai to mainīt, un viņi saņem iepriekšējos izpildes datus, kas var saturēt sensitīvas lietderīgās slodzes.

Piemēram, ja plūsma nosūta klientu datus pa e-pastu, tikai izpildes lietotājs var aktivizēt šo e-pasta ziņojumu, bet nevar atvērt plūsmu, lai iegūtu klienta informāciju, kas tika apstrādāta vakar. Šis princips atbilst vismazākajām privilēģijām — piešķiriet minimālo piekļuvi, kas nepieciešama lietotāja lomai. Tikai run-only koplietošana bieži var sasniegt biznesa prasību ļaut kādam aktivizēt vai izmantot plūsmu, nenododot kontroli.
Izmantojiet drošības lomas, lai segmentētu pienākumus: pārliecinieties, ka lietotājiem, kuriem ir paredzēts tikai vadīt plūsmas, bet ne tās izveidot, nav vides veidotāja lomas. Saglabājot šos lietotājus kā pamata vides lietotājus vai pilnīgi ārpus vides, izmantojot tikai izpildes plūsmas piekļuvi, jūs samazināsiet iespēju, ka viņi var izveidot vai importēt negodīgas plūsmas. Tikai izraudzītajiem veidotājiem vajadzētu būt izgatavotāja privilēģijām, bet citi var patērēt tikai plūsmu rezultātus.

Papildinformāciju uzziniet sadaļā Drošības lomu un grupu izmantošana: veidotāju pārvaldība salīdzinājumā ar tikai palaišanas lietotājiem.
Datu zuduma novēršanas (DLP) politiku ieviešana: lai gan DLP politikas ir vairāk saistītas ar savienotāja lietošanas kontroli, tās netieši palīdz mazināt risku, neļaujot koplietotām plūsmām izmantot aizliegtus savienotājus. Piemēram, ja ārējam cilvēkam tiek piešķirta tikai izpildes piekļuve plūsmai, stingra DLP politika nodrošina, ka plūsma nevar pēkšņi sākt virzīt datus uz neautorizētu pakalpojumu. DLP neaptur pašu koplietošanu, bet ierobežo iespējamo kaitējumu, ja plūsma tiek nejauši vai tīši ļaunprātīgi izmantota. Kā labāko praksi klasificējiet savienotājus biznesa un neuzņēmumu kategorijās un bloķējiet visas bīstamas kombinācijas. Tādā veidā, pat ja plūsmas tiek koplietotas plaši, tās nenoplūdīs datus uz neapstiprinātiem galapunktiem.
Regulāra auditēšana un uzraudzība: izveidojiet rutīnu (piemēram, katru mēnesi vai ceturksni) audita plūsmas atļaujām. Šajā pārskatā identificējiet visas plūsmas, kurām ir neparasta koplietošana, jo īpaši ar ārējiem īpašniekiem vai lieliem tikai palaišanas lietotāju sarakstiem. Pārskatiet tos, ja tie joprojām ir nepieciešami. Microsoft dokumentācija mudina periodiski pārskatīt atļaujas, lai nodrošinātu, ka tās atbilst pašreizējām biznesa vajadzībām, un noņemt piekļuvi lietotājiem, kuriem tā vairs nav nepieciešama.

Uzraudzību var automatizēt. Piemēram, administrators var iestatīt plūsmu Power Automate , izmantojot administratora savienotāju, kas nosūta pārskatu par visām plūsmām ar to īpašniekiem un pēdējo modificēto datumu. Plūsma izceļ plūsmas, kuru īpašnieki ir ārpus noteikta apstiprināto personu saraksta. Turklāt apsveriet iespēju izmantot Power Platform Admin Analytics informācijas paneļus. Tas var parādīt kopējo lietojumu un, iespējams, filtrēt, lai uzzinātu, cik lietotāju darbojas katru plūsmu.
Izglītojiet veidotājus un īstenojiet politiku: dažreiz risku rada informētības trūkums. Dokumentējiet un paziņojiet skaidru koplietošanas politiku, piemēram, nepievienojiet lietotājus ārpus X vides kā līdzīpašniekiem bez apstiprinājuma. Izmantojiet tikai izpildes piekļuvi, ja tas nepieciešams lietotājiem ārpus darba grupas. Apmācot Power Automate veidotājus par šīm vadlīnijām, jūs samazināsiet nejaušu iedarbību. Ja jūsu organizācijā ir iekšēja Power Platform kopiena vai čempionu tīkls, kopīgojiet atgādinājumus par koplietošanas plūsmu ietekmi plašā mērogā. Galu galā lietotājiem ir jāsaprot, ka, lai Power Automate gan koplietošana ir vienkārša, ir atbilstības un drošības pasākumi, kas jāievēro jebkurai sadarbībai starp vidēm.
Izmantojiet atsevišķas vides plašai koplietošanai: dažos gadījumos var būt saprātīgi izveidot īpašu vidi plūsmām, kas jāizmanto plašai auditorijai. Piemēram, organizācija var izveidot koplietojamo pakalpojumu vidi , kas ir atvērta daudziem lietotājiem ar atbilstošu drošības grupu. Plūsmas, kas paredzētas plašam patēriņam, var attīstīt un mitināt tur, nevis dalīt tās no ierobežotākas vides. Tādā veidā tiek saglabātas vides robežas. Jūsu stingri kontrolētā vide joprojām ir stingra, un atvērtā vide ir paredzēta starpfunkcionālai koplietošanai ar pienācīgu uzraudzību. Ja izmantojat šo stratēģiju, pārliecinieties, ka atvērtajā vidē joprojām ir stingra DLP politika un uzraudzība, jo tai ir lielāka lietotāju bāze.
Apsveriet iespēju kopēt plūsmas, nevis tiešu koplietošanu: ja lietotājiem citā vidē ir nepieciešama plūsmas funkcionalitāte, cita pieeja ir eksportēt plūsmu kā pakotni un koplietot pakotni, nevis koplietot tiešo plūsmu. Microsoft iesaka šo pieeju scenārijos, kad lietotājs nav jūsu Power Automate vides dalībnieks, varat nosūtīt viņam plūsmas kopiju, ko viņš importē savā vidē. Pēc tam adresāts izveido savus savienojumus un izpilda plūsmu patstāvīgi. Tas mazina risku, izvairoties no tiešas piekļuves sākotnējās vides plūsmai. Tas būtībā dod viņiem risinājumu, nedodot viņiem pamatu jūsu vidē. Kompromiss ir tāds, ka visi plūsmas atjauninājumi netiks automātiski sinhronizēti, jo tā ir atsevišķa kopija. Tomēr vienreizējām vajadzībām vai kopīgošanai ar ārējām komandām šī metode nodrošina tīru atdalīšanu.

Kopumā ar koplietošanas plūsmām saistīto risku mazināšana kopumā ir saistīta ar stingru vides piekļuves kontroli, piesardzīgu koplietošanas iespēju izmantošanu un piesardzīgu uzraudzību. Apvienojot tehniskos aizsardzības pasākumus (piemēram, drošības grupu kontrolētas vides un DLP politikas) ar procesu aizsardzības pasākumiem (piemēram, īpašnieku pievienošanas apstiprinājumiem un periodiskiem auditiem), organizācijas var izmantot sadarbības priekšrocības Power Automate , vienlaikus samazinot drošības un atbilstības problēmas.

Nākamajā sadaļā galvenā uzmanība pievērsta konkrētam pārvaldības aspektam: lomu un grupu izmantošana, lai definētu, kurš ir veidotājs salīdzinājumā ar to, kurš ir tikai plūsmu skrējējs.

Drošības lomu un grupu izmantošana: veidotāju pārvaldība salīdzinājumā ar tikai izpildes lietotājiem

Kritisks pārvaldības lēmums ir noteikt, kuriem lietotājiem vajadzētu būt veidotājiem, kuri var izveidot un piederēt plūsmām, un kuriem vajadzētu aprobežoties ar plūsmām, kas, iespējams, var patērēt rezultātus. Power Automate un Power Platform piedāvā vairākus mehānismus, lai īstenotu šo atšķirību, galvenokārt izmantojot drošības lomas un drošības grupas.

Atšķirt veidotājus no neražotājiem

Uzņēmuma scenārijā ne katram lietotājam ar licenci Power Automate obligāti jāveido plūsmas katrā vidē. Pēc dizaina vides veidotājs var izveidot plūsmas un citus resursus šajā vidē. Īpašās vidēs vides veidotāja loma ir apzināti jāpiešķir tikai tiem lietotājiem vai grupām, kas ir atbildīgi par risinājumu izveidi. Piemēram, jūs varat nolemt, ka Finance Automation vidē tikai Finance IT komandai un dažiem pieredzējušiem lietotājiem ir veidotāja atļaujas.

Izpildiet to, rīkojoties šādi:

Piešķiriet vides veidotāja drošības lomu tieši konkrētiem lietotājiem vides iestatījumos.
Izmantojiet Azure Active Directory (AD) drošības grupu. Pievienojiet grupai visus paredzētos veidotājus (piemēram, Finanšu veidotāju grupu) un, ja videi nav Dataverse, piešķiriet visai grupai vides veidotāja lomu. Iespējotās Dataverse vidēs, iespējams, būs jāpievieno grupas dalībnieki atsevišķi vai jāizmanto grupas grupas ar drošības lomām.
Lai iegūtu plašu kontroli, saistiet vidi ar drošības grupu , lai vidē varētu atrasties tikai dalībnieki. Pēc tam piešķiriet veidotāja lomas atbilstošajai apakškopai. Šī divu līmeņu pieeja nozīmē, ka nepiederošos cilvēkus nevar ievest neatklāti kā veidotājus, un iekšējo personu vidū tikai dažiem ir veidotāja loma. Cienījami norādījumi iesaka lietot vides drošības grupas līdzekli visās ražošanas un sensitīvajās vidēs, lai novērstu nevēlamu lietotāju klātbūtni.

Drošības grupu izmantošana tikai izpildes piekļuvei

Lai gan nav tikai vides izpildes lomas, varat pārvaldīt tikai izpildes atļaujas mērogā, izmantojot grupas. Kopīgojot plūsmu, īpašnieki var ievadīt grupas nosaukumu, nevis atsevišķus lietotājus, lai piekļūtu līdzīpašniekam vai tikai izpildei. Tas nozīmē, ka varat izveidot drošības grupu, piemēram, Pārdošanas pārskatu plūsmas lietotāji , un piešķirt šo grupu kā tikai izpildes lietotāju attiecīgajās plūsmās. Pēc tam visi grupas dalībnieki mantotu šo plūsmu palaišanas atļauju. Vadība kļūst vieglāka. Lai atsauktu piekļuvi konkrētam lietotājam, noņemiet viņu no grupas. Viņi zaudē izpildes piekļuvi visām plūsmām, kurām grupa tika piešķirta. Tāpat, lai piešķirtu jaunai personai piekļuvi vairākām plūsmām, pievienojiet tās grupai. Tādējādi drošības grupas palīdz vienkāršot atļauju pārvaldību, to ārēji.

Power Automate plūsmām nav jānorāda 50 lietotāji kā tikai izpildei; Tajos ir uzskaitīta viena grupa, un jūsu Azure AD vai Microsoft 365 administrators apstrādā dalību.

Piezīmes

Ja pati vide ir bloķēta drošības grupai, plūsmas koplietošanai izmantotajai grupai jābūt vienādai vai apakškopai. Ja koplietojat plūsmu ar grupu, kurā ir cilvēki ārpus vides atļautajiem lietotājiem, viņi, iespējams, nevarēs to palaist atkarībā no vides iestatījumiem. Grupas lietošana jāsaskaņo ar vides piekļuves politikām.

Lomu piešķiršana veidotājiem salīdzinājumā ar skrējējiem

Vidē Dataverse drošības lomas var slāņot, lai precīzi noregulētu to, ko var darīt veidotāji salīdzinājumā ar tikai palaišanas lietotājiem.

Veidotāji: Vismaz viņiem ir nepieciešama vides veidotāja loma, lai izveidotu plūsmas. Ja to plūsmas mijiedarbojas ar Dataverse tabulām, tām var būt nepieciešamas arī papildu Dataverse lomas, piemēram, sistēmas pielāgotājs vai atļaujas noteiktās tabulās, lai tās pareizi noformētu un pārbaudītu. Vides veidotāja un lomas, kas piešķir piekļuvi datiem (ja nepieciešams), kombinācija ļauj viņiem izveidot pilnus risinājumus. Labākā prakse ir piešķirt veidotājiem tikai nepieciešamās privilēģijas. Piemēram, ja veidotājs tikai automatizē SharePoint un e-pastu, viņam var nebūt nepieciešama Dataverse loma, izņemot to, ka viņi atrodas vidē. Tomēr, ja veidotājs veido plūsmu, lai atjauninātu ierakstu Dataverse , viņam ir nepieciešama atļauja šajā tabulā. Plānojiet savas drošības lomas tā, lai veidotāji, ja nepieciešams, iegūtu atsevišķu veidotāja datu lomu , nevis piešķirtu viņiem pārmērīgi plašas lomas.
Tikai izpildes lietotāji: šiem lietotājiem nav nepieciešama vides veidotājs. Ja vidē ir datu bāze Dataverse un plūsma pieskaras Dataverse datiem, tai var būt nepieciešama pamata lietotāja loma (vai cita loma), lai būtu lasīšanas/rakstīšanas piekļuve pamatā esošajiem datiem, kad plūsma tiek rādīta viņu kontekstā. Piemēram, manuāla trigera plūsma var izveidot ierakstu Dataverse skrējēja vārdā. Ja tā, skrējējam ir nepieciešama atļauja, lai izveidotu šo ierakstu. Izmantojot savienojuma opciju Tikai palaist lietotājs nodrošina savienojumu , plūsma tiek izpildīta tikai palaižamā lietotāja akreditācijas datu kontekstā. Šādos gadījumos jums ir jānodrošina, ka šiem lietotājiem ir visas minimālās tiesības, kas nepieciešamas, izmantojot Dataverse lomas vai attiecīgās sistēmas atļaujas, lai veiktu plūsmas veiktās darbības. Ja plūsma vienmēr izmanto īpašnieka savienojumu, tikai palaišanas lietotājam, iespējams, nav nepieciešama īpaša loma Dataverse — viņš nospiež pogu, un plūsma izmanto īpašnieka privilēģiju. Šī nianse ir rūpīgi jāapsver. Droša pieeja ir nodrošināt tikai palaišanas lietotājiem lasīšanas piekļuvi datiem, kurus viņi var parādīt, un ne vairāk. Daudzi uzņēmumi izveido pielāgotu Dataverse lomu vai izmanto pamata lietotāju ar minimālām lasīšanas tiesībām un piešķir to visiem lietotājiem, lai izpildītu šo prasību par programmu un plūsmu palaišanu.

Lomu vadība, paturot prātā pārvaldību

Sekojiet līdzi tam, kam ir kāda loma. Administrators var uzskaitīt visus lietotājus vidē un viņiem piešķirtās Power Platform drošības lomas administrēšanas centrā vai izmantojot PowerShell. To var salīdzināt ar gaidāmo veidotāju sarakstu. Tā ir pārvaldības labākā prakse, lai uzturētu inventāru, piemēram, Environment X veidotāji: Alise, Bobs, Kerols; Vide X tikai palaišana/patērētāji: visi lietotāji Mārketinga nodaļā Skaidrībā par to, kad tiek pieprasīts pievienot jaunu veidotāju, varat pārbaudīt, vai tas ir apstiprināts grupā, vai saņemt nepieciešamos apstiprinājumus, lai paplašinātu loku.

Scenāriji un piemēri

Šajā sarakstā ir izskaidroti daži scenāriji un risinājumu piemēri.

Scenārijs: departamenta vide, kurā tikai nelielai komandai vajadzētu veidot plūsmas, bet daudzi nodaļā tās vada.
Risinājums: nodaļas IT vadītājam tiek piešķirts vides administrators. Grupā Azure AD Dept Makers ir pieci cilvēki, kas veido programmas un plūsmas. Šī grupa tiek pievienota vides veidotāja lomai. Tas tiek darīts vai nu tieši, vai arī indivīdi tiek piešķirti, ja grupas piešķiršana nav pieejama. Visi nodaļas dalībnieki ir grupā Dept lietotāji , kas ir saistīti ar vidi, tāpēc viņiem visiem ir piekļuve lietotājiem. Vidē izveidotās plūsmas, kas jāpalaiž visai nodaļai, tiek koplietotas ar grupu Dept Users kā tikai izpildes. Tādā veidā veidotāji veido un dalās. Nodaļas loceklis var darboties, bet cilvēki, kas nav nodaļas locekļi, nevar piekļūt, jo viņi nav vides grupā.
Scenārijs: ražošanas vide ar sensitīvām plūsmām, kuras nedrīkst rediģēt nevienam, izņemot divus risinājumu īpašniekus.
Risinājums: Tikai šie divi indivīdi ir vides veidotāji. Nevienam citam nav veidotāja lomas. Ja citiem lietotājiem ir jāaktivizē plūsmas, viņiem tiek piešķirta tikai izpildes piekļuve. Iespējams, īpašs pakalpojumu konts vai pakalpojuma principāls faktiski ir plūsmu īpašnieks stabilitātei, un abi īpašnieki ir līdzīpašnieki uzturēšanai. Pakalpojuma principa izmantošana kā primārais īpašnieks uzlabo kritisko plūsmu pārvaldību. Visi pastāvīgie darbinieki vai nu neatrodas šajā vidē, vai arī viņiem ir tikai lietotāja loma. Vidi varētu piesaistīt drošības grupai, kas satur tikai nepieciešamos kontus, lai vēl vairāk nodrošinātu ekskluzivitāti.
Scenārijs: izcilības centra vide, kurā pārvaldības komandas veido uzraudzības plūsmas visās vidēs.
Risinājums: piekļuve ir tikai izcilības centra komandai. Viņi pēc lomas ir vides veidotāji. Nav nepieciešama tikai izpildes koplietošana, jo šīs plūsmas ir vairāk iekšējas. Šeit tā izšķirošajiem izcilības centra cilvēkiem, iespējams, ir administratora Power Platform loma nomnieka līmenī, kas netieši piešķir viņiem tiesības visās vidēs.

Lomu segregācijas priekšrocības

Skaidri norobežojot veidotāju un skrējēju, jūs sasniedzat sekojošo:

Vismazākās privilēģijas: lietotāji saņem tikai nepieciešamās atļaujas. Tikai palaišanas lietotājs nevar pēkšņi sākt veidot plūsmas, kas apiet IT uzraudzību, jo viņam trūkst šīs lomas. Veidotāji iegūst brīvību radīt, bet, tā kā šis iedzīvotāju skaits ir mazāks un zināms, jūs varat vieglāk viņus apmācīt un uzraudzīt.
Vienkāršota dzīves cikla pārvaldība: kad darbinieks aiziet vai maina lomas, ir vieglāk atjaunināt piekļuvi. Piemēram, ja Džo bija veidotājs un pārceļas no komandas, jūs viņu noņemat no veidotāju drošības grupas. Viņš uzreiz zaudē iespēju izveidot un rediģēt šajā vidē, vienlaikus saglabājot palaišanas piekļuvi, ja viņš paliek lietotāju grupā. Pēc tam jūs varat pievienot viņa aizstājēju grupai Makers. Šī grupas uzturēšana ir tīrāka nekā manuāla desmitiem plūsmas atļauju pievienošana un noņemšana.
Atbilstības saskaņošana: daudzi noteikumi prasa kontrolētu piekļuvi. Spēja parādīt auditoram, ka tikai šie konkrētie indivīdi var modificēt automatizāciju šajā vidē; visi pārējie var tikai aktivizēt apstiprinātas plūsmas , var palīdzēt demonstrēt spēcīgu iekšējo kontroli. Revidentiem var arī piešķirt vides lomu piešķiršanu kā izpildes pierādījumu.
Izvairieties no neskaidrībām: ja visiem būtu veidotāja tiesības, mazāk tehnisko lietotāju var nejauši izveidot vai mainīt plūsmas vai tikt sajaukts ar Power Automate interfeisu. Ierobežojot veidotāja lomu, jūs nodrošināsiet, ka plūsmas projektē tikai apmācīts personāls, kas var samazināt kļūdas.

Šie pasākumi periodiski jāpārskata. Mainoties biznesa vajadzībām, kādam, kurš ir patērētājs, var būt jākļūst par veidotāju (piemēram, jaudīgs lietotājs parādās jaunā komandā), vai arī ražotājam var būt jākļūst par patērētāju. Pārvaldības modelim jābūt pietiekami elastīgam, lai to pielāgotu ar pienācīgiem apstiprinājumiem. Dokumentējiet kritērijus, lai saņemtu vides veidotāja privilēģijas, un to pieprasīšanas procesu, lai nodrošinātu pārredzamību un konsekvenci. Tāpat definējiet, kādi nosacījumi var izraisīt veidotāja piekļuves atsaukšanu, piemēram, pārcelšanos uz citu nodaļu.

Izmantojot drošības lomas un grupas tandēmā, organizācijas var panākt skaidru un uzturamu nošķiršanu starp tiem, kas izstrādā automatizāciju, un tiem, kas izmanto automatizāciju. Tas uzlabo gan drošību, gan produktivitāti vidē Power Automate .

Atsauksmes

Vai šī lapa bija noderīga?

Last updated on 2025-06-16