Policyer styr hur reglerade åtgärder slutförs: direkt, eller efter granskning av andra medlemmar. Varje arbetsflöde har en policy, som ställs in en gång för hela organisationen. Den här artikeln förklarar en förfrågans livscykel, policyinställningar och låsning. Information om vem som kan starta och godkänna förfrågningar finns under Roller, profiler och behörigheter.
Policyer tillhör arbetsflöden, aldrig konton. Det finns en policy för uttagsförfrågningar per organisation – inte en per konto. För att styra vem som kan ta ut medel från vilket konto använder du rörelsebehörigheter i kontobehörigheter. För att styra hur strikt uttag granskas finns en enda inställning för hela arbetsflödet.
Varje styrd åtgärd följer samma väg, oavsett om den flyttar medel eller ändrar organisationens egna inställningar:
1 – Initiering. En medlem vars arbetsflödesprofil innehåller Initiate (eller Execute) på arbetsflödet startar en förfrågan. För uttag och överföringar behöver de också rätt behörighet för medelsrörelse på berörda konton.
2 – Kontroll av omedelbart slutförande. Om medlemmen har Execute och arbetsflödets inställning "Kräv alltid godkännande" är AV slutförs förfrågan direkt. Klart. Ett undantag: en förfrågan som ändrar en låst policy väntar alltid på godkännande, oavsett vilken behörighet den som initierat den har – se "Låsa policyer" nedan.
3 – Godkännandekö. Annars väntar förfrågan på granskning. Medlemmar med Approve på det arbetsflödet ser förfrågan i sin kö.
4 – Avslutning. När det erforderliga antalet oberoende godkännanden har uppnåtts slutförs förfrågan och träder i kraft. En enskild godkännare kan i stället avvisa den, vilket avslutar förfrågan utan verkan.
Slutförda förfrågningar registreras som säkerhetshändelser, kopplade till förfrågan och dess godkännandekedja.
En medlem kan inte godkänna sin egen förfrågan. Systemet tillämpar detta på alla arbetsflöden – ingen behörighet, profil eller policykonfiguration kan åsidosätta regeln.
Det enda sättet för en enskild medlem att slutföra en reglerad åtgärd på egen hand är Execute, och bara när arbetsflödets policy tillåter omedelbart slutförande.
Varje arbetsflödes policy har två inställningar:
Inställning | Vad den gör |
|---|---|
Begärda godkännanden | Hur många distinkta medlemmar som måste godkänna innan en förfrågan slutförs. Godkännare hämtas från de medlemmar som har Approve på det arbetsflödet; initieraren är alltid undantagen från sin egen förfrågan. |
Kräv alltid godkännande | När den är PÅ går varje förfrågan genom godkännandekön, inklusive förfrågningar från medlemmar med Execute. När den är AV slutför medlemmar med Execute förfrågningar omedelbart. |
Samspelet mellan Execute och "Kräv alltid godkännande":
Medlemmens profil på arbetsflödet | Kräv alltid godkännande | Utfall |
|---|---|---|
Initiate, utan Execute | AV eller PÅ | Förfrågan väntar på godkännande |
Initiate + Execute | AV | Förfrågan slutförs omedelbart |
Initiate + Execute | PÅ | Förfrågan väntar på godkännande, Execute är vilande |
Execute tas aldrig bort av en policy – det finns kvar på profilen, synligt markerat som vilande när "Kräv alltid godkännande" är PÅ, och börjar fungera igen om inställningen senare sätts till AV.
Policyändringar är i sig styrda åtgärder under arbetsflödet Hantera policyer. Om arbetsflödet kräver godkännande hamnar din ändring i kön som vilken annan förfrågan som helst.
Varje policy har också sin egen ändringshistorik: varje uppdatering, låsning och upplåsning listas med den godkännandeförfrågan som genomförde den, så att du alltid kan se vad som ändrades, vem som begärde det och vem som godkände det. Slutförda ändringar registreras även som säkerhetshändelser.
Medlemmar kan inte godkänna sina egna förfrågningar, så räkna antalet godkännare utifrån den som initierar en förfrågan. En godkännare som aldrig initierar förfrågningar räknas för alla; en godkännare som även initierar förfrågningar kan inte räknas som godkännare för sina egna. Två godkännanden uppnås av två godkännare som bara godkänner, men inte av två godkännare som även initierar förfrågningar. Systemet blockerar en konfiguration som ingen kan uppfylla, och policyeditorn visar tillgängliga godkännare bredvid det antal du anger.
Låsning är styrningens förankringssteg. Det krävs ett oberoende godkännande för varje framtida ändring av arbetsflödets policy – inklusive ändring av antalet godkännanden, ändring av "Kräv alltid godkännande" eller upplåsning.
Varje policyändring hanteras som en Hantera policyer-förfrågan oavsett om målpolicyn är låst eller inte – låsningen påverkar inte vart en ändring skickas, bara hur den slutförs:
När ett arbetsflöde är låst kan ingen enskild person försvaga dess styrning på egen hand. Ändringar är fortsatt rutinmässiga – alla medlemmar vars Workflow Profile ger godkännandebehörighet på Hantera policyer kan granska och godkänna dem, men det krävs alltid minst två personer.
Låsning gäller per arbetsflöde. Att låsa Uttag-förfrågan påverkar inte Överföringsförfrågan eller något annat arbetsflöde – du skärper ett arbetsflöde i taget, i din egen takt. Se Implementera styrning för den rekommenderade ordningen.
Lås och upplåsning är också förfrågningar
Tre typer av förfrågningar hanteras under arbetsflödet Hantera policyer. Du ser dem namngivna i godkännandekön, i varje policys ändringshistorik och i säkerhetshändelser:
Request | Vad den gör |
|---|---|
Policyuppdatering | Ändrar en policys inställningar – antalet godkännanden eller "Kräv alltid godkännande" |
Lås policy | Låser en policy |
Upplåsning av policy | Låser upp en låst policy |
Låsning är inte undantagen från sina egna regler: en låsförfrågan följer samma flöde som alla andra förfrågningar under Hantera policyer. Om du har Execute på Hantera policyer och inställningen "Kräv alltid godkännande" är AV träder låsningen i kraft omedelbart. Annars väntar den i kön och policyn förblir olåst tills förfrågan godkänns.
Hur en policyändring slutförs
Sammanfattning – så här utfaller en förfrågan under Hantera policyer:
Målpolicy | Begärarens nivå på Hantera policyer | "Kräv alltid godkännande" på Hantera policyer | Utfall |
|---|---|---|---|
Låst | Alla, inklusive Execute | PÅ eller AV | Väntar på godkännande – låset avgör |
Upplåst | Initiate, utan Execute | PÅ eller AV | Väntar på godkännande |
Upplåst | Verkställ | PÅ | Väntar på godkännande, Execute är inaktiv |
Upplåst | Verkställ | AV | Slutförs omedelbart |
Två sätt att styra policyändringar
Kontroll | Omfattning | Effekt |
|---|---|---|
Lås policy | Policyn för ett arbetsflöde | Ändringar av den policyn kräver oberoende godkännande; övriga arbetsflöden påverkas inte. |
"Kräv alltid godkännande" på Hantera policyer | Alla policyer | Varje policyändring, i varje arbetsflöde, genomgår godkännande. En gemensam styrningsbrytare för alla policyer. |
De två kontrollerna kompletterar varandra och kolliderar aldrig: oavsett vilken som gäller väntar ändringen på godkännande, och att aktivera båda ändrar ingenting ytterligare. Använd låset för stegvis åtstramning; använd inställningen Manage Policies när du vill att alla policyändringar granskas på en gång.
Låsa Manage Policies
Manage Policies är ett arbetsflöde som vilket annat: det har sin egen policy, och den policyn har sitt eget lås. Att låsa det är det slutliga åtagandet i styrningsinfasningen. När Manage Policies-policyn är låst kräver varje regeländring i organisationen – inklusive upplåsning av vilken policy som helst och upplåsning av Manage Policies själv – ett oberoende godkännande. Från den punkten kan ingen enskild person urholka styrningen via produkten.
Det är också därför du bör bekräfta upplåsningsvägen innan du låser, enligt beskrivningen under "Skyddsåtgärder" nedan. Ingenting i produkten hindrar dig från att låsa en policy i ett tillstånd som ingen kan ändra. Se Implementera styrning för när du bör ta detta steg.
Bekräfta att upplåsning fortfarande är möjlig innan du låser. Upplåsning är en Manage Policies-förfrågan mot en låst policy, så Execute kan inte kringgå den. Du behöver en medlem som kan starta en Manage Policies-förfrågan, plus lika många andra medlemmar med Approve på Manage Policies som arbetsflödet kräver – alla verifierade och aktiva. Systemet kontrollerar inte detta åt dig, och en låst policy utan väg till en godkänd ändring kräver hjälp från Kraken Support för att återställas.
Skydd mot utestängning. En ändring avvisas om den skulle resultera i att ingen kan slutföra de förfrågningar som startats i arbetsflödet. Eftersom medlemmar inte kan godkänna sina egna förfrågningar inträffar detta så snart det antal godkännanden som krävs överstiger vad en enskild initierare kan samla in för sina egna förfrågningar. Kontrollen körs i båda riktningarna: när du redigerar en policy och när du ändrar en medlems arbetsflödesprofil eller en kontoroll.
Varning vid inaktivering. Kontrollera att det finns tillräckligt med godkännare innan du inaktiverar en medlem som har Approve. Inaktiveringen genomförs även om den sänker ett arbetsflöde under det antal godkännanden som krävs, och väntande förfrågningar fortsätter att gälla det tröskelvärde som gällde när de skapades.
När policyer är på plats går Implementera styrning igenom hur du inför dem på ett säkert sätt: konfigurera, validera och lås sedan – ett arbetsflöde i taget, med konkreta exempel.
"Kräv alltid godkännande" är PÅ för det arbetsflödet. Execute är inaktivt medan inställningen är PÅ – varje förfrågan köas för oberoende godkännande. Stäng av inställningen under Policyer för att återställa omedelbar slutförande. Observera att det här är en åtgärd under Hantera policyer och kan kräva godkännande.
Om förfrågan gäller en policyändring, kontrollera även målpolicyn: ändringar av en låst policy väntar alltid på godkännande, oavsett Execute. Det är låset som fungerar som avsett.
Låsning är i sig en Hantera policyer-förfrågan. Om "Kräv alltid godkännande" är PÅ för Hantera policyer, eller om din arbetsflödesprofil saknar Execute för det, väntar låset på oberoende godkännande – precis som vilken annan förfrågan som helst. Policyn förblir olåst tills låsförfrågan godkänns – du hittar den i godkännandekön och i policyns ändringshistorik när den är slutförd.
Räkna de aktiva medlemmar som har Godkänn för det arbetsflödet, exklusive dig själv. Endast medlemmar som har accepterat sin inbjudan och slutfört verifiering räknas mot godkännanden: en inbjuden medlem räknas inte förrän båda är klara, även om de visas i din teamlista. Om en godkännare inaktiverades efter att förfrågan skapades, kanske de återstående godkännarna inte längre når det krävda antalet – en väntande förfrågan håller sig till tröskeln från när den skapades, även om policyn har ändrats sedan dess. Återaktivera medlemmen eller tilldela Godkänn till en annan aktiv medlem för att häva blockeringen.
Kontrollera din arbetsflödesprofil – låsning kräver Initiera eller Execute för arbetsflödet Hantera policyer. Om låsförfrågan skapades men inget ändrades väntar den på godkännande i stället för att ha nekats – se avsnittet ovan.
Systemet nekar inte en låsning enbart för att en oberoende godkännare saknas, så kontrollera upplåsningsvägen själv innan du låser: en medlem som kan starta en Hantera policyer-förfrågan, plus så många andra medlemmar med Godkänn för Hantera policyer som arbetsflödet kräver.
Det begärda antalet godkännanden överstiger vad en medlem som initierar förfrågningar kan uppnå, eftersom ingen kan godkänna sin egen förfrågan. Policyeditorn visar orsaken: en eller flera medlemmar har både Initiera och Godkänn, vilket innebär att var och en av dem har en godkännare färre än övriga. Sänk det obligatoriska antalet godkännanden, eller tilldela Godkänn till en annan medlem som inte initierar förfrågningar i det här arbetsflödet.