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