Політики визначають, як виконуються керовані операції: негайно або після перевірки іншими Учасниками. Кожен робочий процес має одну політику, яка встановлюється один раз для всієї Організації. У цій статті описано життєвий цикл запиту, налаштування політик і блокування. Про те, хто може створювати та схвалювати запити, читайте в розділі Ролі, профілі та дозволи.
Політики належать робочим процесам, а не обліковим записам. В Організації діє одна політика запитів на виведення — а не окрема для кожного облікового запису. Щоб визначити, хто може виводити кошти з якого облікового запису, використовуйте дозволи на переміщення коштів у розділі «Ролі облікового запису»; щоб налаштувати суворість перевірки виведень, скористайтеся єдиним параметром для всього робочого процесу.
Кожна керована операція проходить однаковий шлях — незалежно від того, чи вона переміщує кошти, чи змінює конфігурацію самої Організації:
1 – Ініціювання. Учасник, чий Профіль робочого процесу має роль Initiate (або Execute) для відповідного робочого процесу, створює запит. Для виведень і переказів також необхідний відповідний дозвіл на переміщення коштів для задіяних облікових записів.
2 – Перевірка можливості негайного виконання. Якщо Учасник має роль Execute, а налаштування «Завжди вимагати схвалення» у робочому процесі вимкнено (OFF), запит виконується негайно. Готово. Один виняток: запит на зміну заблокованої політики завжди очікує на схвалення — незалежно від ролі ініціатора. Докладніше — у розділі «Блокування політик» нижче.
3 – Черга на схвалення. В інших випадках запит очікує на перевірку. Учасники з роллю Approve для цього робочого процесу бачать запит у своїй черзі.
4 – Вирішення. Коли набрано необхідну кількість незалежних схвалень, запит виконується та набирає чинності. Будь-який окремий схвалювач може натомість відхилити запит — тоді він закривається без наслідків.
Виконані запити фіксуються як події безпеки із посиланням на відповідний запит та його ланцюжок схвалень.
Учасник не може схвалити власний запит. Система забезпечує це для кожного робочого процесу, і жодні дозволи, профілі чи налаштування політик не змінюють цього правила.
Єдиний спосіб, у який один Учасник може самостійно виконати керовану операцію, — це роль Execute, і лише якщо політика робочого процесу допускає негайне виконання.
Політика кожного робочого процесу має два параметри:
Налаштування | Що робить |
|---|---|
Необхідні схвалення | Скільки окремих Учасників мають схвалити запит, перш ніж його буде виконано. Схвалювачами можуть бути Учасники з роллю «Схвалення» у відповідному робочому процесі; ініціатор завжди виключається зі схвалювачів власного запиту. |
Завжди вимагати схвалення | Якщо УВІМКНЕНО, кожен запит проходить через чергу на схвалення, включно із запитами від Учасників з роллю «Виконання». Якщо ВИМКНЕНО, Учасники з роллю «Виконання» завершують запити негайно. |
Взаємодія між «Виконанням» і параметром «Завжди вимагати схвалення»:
Профіль Учасника в робочому процесі | Завжди вимагати схвалення | Результат |
|---|---|---|
Ініціювання, без Виконання | ВИМК або УВІМК | Запит очікує схвалення |
Ініціювання + Виконання | ВИМК | Запит виконується негайно |
Ініціювання + Виконання | ON | Запит очікує схвалення, Виконання неактивне |
Роль «Виконання» ніколи не скасовується політикою — вона залишається в профілі, позначена як неактивна, поки параметр «Завжди вимагати схвалення» УВІМКНЕНО, і відновлює дію, якщо цей параметр згодом ВИМКНУТИ.
Зміни політик самі по собі є керованими операціями в межах робочого процесу Manage Policies. Якщо цей робочий процес вимагає погодження, Ваша зміна очікує в черзі, як і будь-який інший запит.
Кожна політика також зберігає власну історію змін: кожне оновлення, блокування та розблокування відображається там разом із запитом на погодження, що його супроводжував, тому Ви завжди можете побачити, що змінилося, хто ініціював зміну і хто її підтвердив. Завершені зміни також фіксуються як події безпеки.
Учасники не можуть погоджувати власні запити, тому кількість погоджувачів слід рахувати з погляду того, хто ініціює запит. Погоджувач, який ніколи не ініціює запити, зараховується для всіх; погоджувач, який також ініціює запити, не може зараховуватися для власних. Дві погодження забезпечать два погоджувачі, які лише погоджують, але не два погоджувачі, які також ініціюють запити. Система заблокує конфігурацію, яку неможливо виконати, а редактор політик відображає доступних погоджувачів поруч із потрібною кількістю.
Блокування — це крок остаточного закріплення системи управління. Воно вимагає незалежного підтвердження для кожної майбутньої зміни політики відповідного робочого процесу, включно зі зміною кількості підтверджень, зміною параметра «Завжди вимагати підтвердження» або розблокуванням.
Будь-яка зміна політики виконується як запит Manage Policies незалежно від того, заблокована цільова політика чи ні; блокування не змінює маршрут запиту — лише спосіб його завершення:
Після блокування жодна окрема особа не може самостійно послабити систему управління робочого процесу. Зміни залишаються буденною процедурою — розглянути й затвердити їх може будь-який учасник, чий Workflow Profile надає право підтвердження в Manage Policies, — проте завжди потрібні щонайменше дві особи.
Блокування застосовується до окремого робочого процесу. Блокування Withdrawal Request жодним чином не стосується Transfer Request чи інших робочих процесів — Ви посилюєте контроль над одним робочим процесом за раз, у власному темпі. Рекомендовану послідовність дій див. у розділі Розгортання системи управління.
Блокування та розблокування — теж запити
У рамках робочого процесу Manage Policies виконується три типи запитів. Їхні назви відображатимуться в черзі підтверджень, в історії змін кожної політики та в подіях безпеки:
Запросить | Що робить |
|---|---|
Оновлення політики | Змінює параметри політики: кількість підтверджень або «Завжди вимагати підтвердження» |
Блокування політики | Блокує політику |
Розблокування політики | Розблоковує заблоковану політику |
Блокування не є винятком із власних правил: запит на блокування проходить той самий життєвий цикл, що й будь-який інший запит Manage Policies. Якщо Ви маєте право Execute на Manage Policies і параметр «Завжди вимагати підтвердження» вимкнено, блокування набирає чинності негайно; в іншому разі запит очікує в черзі, а політика залишається незаблокованою до його затвердження.
Як завершується зміна політики
Узагальнюючи, результат будь-якого запиту Manage Policies:
Цільова політика | Рівень ініціатора запиту в Manage Policies | «Завжди вимагати схвалення» в Manage Policies | Результат |
|---|---|---|---|
Заблоковано | Будь-який, включно з Execute | УВІМК або ВИМК | Очікує схвалення — рішення за блокуванням |
Розблоковано | Ініціювання, без Виконання | УВІМК або ВИМК | Очікує схвалення |
Розблоковано | Виконати | ON | Очікує схвалення, Execute неактивний |
Розблоковано | Виконати | ВИМК | Виконується негайно |
Два способи керувати змінами політик
Механізм контролю | Охоплення | Дія |
|---|---|---|
Блокування політики | Політика одного робочого процесу | Зміни цієї політики потребують незалежного схвалення; інші робочі процеси не зачіпаються. |
«Завжди вимагати схвалення» в Manage Policies | Усі політики | Кожна зміна політики в кожному робочому процесі проходить через схвалення. Загальний перемикач управління. |
Ці два механізми доповнюють один одного й ніколи не конфліктують: якщо застосовується будь-який із них, зміна очікує на схвалення, а одночасна активація обох нічого не змінює додатково. Використовуйте блокування для поступового посилення контролю; використовуйте налаштування Manage Policies, коли потрібно, щоб усі зміни політик проходили перевірку одразу.
Блокування самого Manage Policies
Manage Policies — це робочий процес, як і будь-який інший: він має власну політику, а ця політика має власне блокування. Його блокування — фінальний крок у впровадженні системи управління. Після блокування політики Manage Policies будь-яка зміна правил в Організації — зокрема розблокування будь-якої політики й розблокування самого Manage Policies — потребуватиме незалежного схвалення. Після цього жодна окрема особа не зможе послабити систему управління через продукт.
Саме тому перед блокуванням слід переконатися, що маршрут розблокування залишається доступним, — як описано в розділі «Захисні механізми» нижче. Ніщо в продукті не завадить Вам заблокувати політику в стані, який згодом ніхто не зможе змінити. Про те, коли робити цей крок, див. Впровадження системи управління.
Перед блокуванням переконайтеся, що розблокування все ще можливе. Розблокування є запитом Manage Policies щодо заблокованої політики, тому Execute не може пришвидшити цей процес. Вам потрібен Учасник, який може ініціювати запит Manage Policies, а також стільки інших Учасників із правом Approve у Manage Policies, скільки вимагає цей робочий процес, — усі верифіковані й активні. Система не перевіряє це автоматично, а для відновлення заблокованої політики без маршруту до схваленої зміни знадобиться допомога Служби підтримки Kraken.
Захист від блокування. Зміна відхиляється, якщо вона залишить робочий процес без можливості виконати ініційовані в ньому запити. Оскільки Учасники не можуть схвалювати власні запити, це відбувається щойно необхідна кількість схвалень перевищує ту, яку будь-який окремий ініціатор може зібрати для своїх запитів. Перевірка виконується з обох боків: під час редагування політики та під час зміни профілю робочого процесу Учасника або ролі облікового запису.
Попередження про деактивацію. Перевірте наявність достатньої кількості схвалювачів перед деактивацією Учасника з правом Approve. Деактивація виконується, навіть якщо через неї кількість схвалювачів у робочому процесі опуститься нижче необхідної, а запити в черзі залишаються привʼязаними до порогу, що діяв на момент їх створення.
Коли призначення політик стане зрозумілим, стаття Впровадження системи управління допоможе запровадити їх безпечно: налаштуйте, перевірте, а потім заблокуйте — по одному робочому процесу за раз, із практичними прикладами.
Для цього робочого процесу ввімкнено параметр «Always require approval». Поки цей параметр увімкнено, Execute неактивний; кожен запит надходить до черги на незалежне затвердження. Щоб відновити негайне виконання, вимкніть цей параметр у розділі «Policies». Зверніть увагу: це дія Manage Policies, тож вона сама може потребувати затвердження.
Якщо йдеться про запит на зміну політики, перевірте також цільову політику: зміни до заблокованої політики завжди очікують на затвердження, незалежно від Execute. Це означає, що блокування працює саме так, як задумано.
Блокування саме є запитом Manage Policies. Якщо для Manage Policies увімкнено «Always require approval» або Ваш Workflow Profile не містить Execute для цього процесу, запит на блокування очікує на незалежне затвердження, як і будь-який інший запит. Політика залишається розблокованою, доки запит на блокування не буде затверджено; його можна знайти в черзі на затвердження, а після завершення — в історії змін політики.
Порахуйте активних Учасників із роллю Approve для цього робочого процесу, не враховуючи себе. До затверджень зараховуються лише ті Учасники, які прийняли запрошення та пройшли верифікацію: запрошений Учасник не враховується, доки не виконано обидві умови, навіть якщо він відображається у списку команди. Якщо затверджувача деактивовано після створення запиту, решта затверджувачів може не набрати необхідну кількість голосів. Запит, що очікує розгляду, зберігає поріг, який діяв на момент його створення, навіть якщо політику згодом було змінено. Реактивуйте Учасника або надайте роль Approve іншому активному Учаснику, щоб розблокувати запит.
Перевірте свій Workflow Profile: для блокування потрібна роль Initiate або Execute у робочому процесі Manage Policies. Якщо запит на блокування створено, але нічого не змінилося, він очікує на затвердження, а не відхилений — див. пункт вище.
Система не відмовляє в блокуванні через відсутність незалежного затверджувача, тому перед блокуванням самостійно перевірте шлях розблокування: потрібен Учасник, який може ініціювати запит Manage Policies, а також стільки інших Учасників із роллю Approve на Manage Policies, скільки вимагає цей робочий процес.
Необхідна кількість затверджень перевищує ту, яку може зібрати Учасник, що ініціює запити, адже ніхто не може затвердити власний запит. Редактор політики вказує на причину: один або кілька Учасників мають одночасно ролі Initiate і Approve, тому для кожного з них доступно на одного затверджувача менше, ніж загалом. Зменште необхідну кількість затверджень або надайте роль Approve іншому Учаснику, який не ініціює запити в цьому робочому процесі.