Розгортання управління

Рівень Execute і параметр «Завжди вимагати підтвердження» формують два режими роботи:

• Швидкий шлях для одних, підтвердження для решти. Заблокуйте політику з параметром «Завжди вимагати підтвердження» ВИМКНЕНО. Учасники, чий профіль містить Execute, виконують запити негайно; решта проходить через підтвердження. Блокування не дає жодній особі послабити правила наодинці.
• Підтвердження для всіх. Заблокуйте політику з параметром «Завжди вимагати підтвердження» УВІМКНЕНО. Кожен запит, зокрема й Власника, проходить незалежне підтвердження. Жодна особа не може самостійно завершити керовану операцію.

Різні робочі процеси можуть працювати в різних режимах. Поширена схема: підтвердження для всіх у Withdrawal Request, швидкий шлях у Transfer Request (кошти залишаються всередині Організації) та підтвердження у Manage Policies для захисту самих правил.

Перші три кроки можна вільно скасувати. Блокування — це остаточне рішення.

Крок 1 – Початкове налаштування

Власник починає роботу із системним профілем Адміністратора та роллю Повного доступу: Виконання в кожному робочому процесі, усі дозволи для кожного облікового запису. Політика кожного робочого процесу початково відкрита. В Організації з одним учасником Ви працюєте так само, як і раніше: ніщо не очікує на затвердження, оскільки затверджувати нікому.

Крок 2 – Налаштування

Налаштуйте процес затвердження для одного робочого процесу — зазвичай спочатку для Запиту на виведення, — поки параметр «Завжди вимагати затвердження» лишається вимкненим (OFF):

1. Запросіть учасників і призначте їм профілі робочого процесу з рівнем Затвердження для цільового робочого процесу. Системний профіль Затверджувача надає права затвердження в усіх робочих процесах; Менеджер коштів охоплює ініціювання та затвердження переказів і виведень.
2. Призначте ролі облікових записів так, щоб ініціатори мали необхідні дозволи на переміщення коштів на відповідних облікових записах.
3. Встановіть необхідну кількість затверджень для цільового робочого процесу.
4. Якщо Ви плануєте блокування (Крок 4), налаштуйте маршрут розблокування в розділі Керування політиками вже зараз: учасник, який може ініціювати запит у Керуванні політиками, а також стільки інших учасників із рівнем Затвердження в Керуванні політиками, скільки вимагає цей робочий процес. Система не перевіряє це, перш ніж дозволити Вам виконати блокування.

Поки що жодних обмежень не застосовано. Ви зберігаєте рівень Execute і продовжуєте працювати у звичайному режимі, поки налаштування впроваджуються.

Крок 3 – Перевірка

Увімкніть «Завжди вимагати схвалення» для потрібного робочого процесу. Кожен запит, зокрема Ваш, тепер потрапляє до черги. Перевірте за допомогою реальних запитів:

• Схвалювачі бачать запити в очікуванні та можуть їх схвалювати або відхиляти.
• Необхідну кількість схвалень можна набрати в межах поточної команди.
• Наскрізний процес – від ініціювання до завершення – працює належним чином. Переконайтеся, що згенеровані події безпеки містять посилання на відповідні запити.

Це безпечний період: управління вже діє, але політику ще не заблоковано, тож Ви можете вимкнути налаштування, внести зміни й повторити спробу стільки разів, скільки потрібно. До блокування політики визначте, якою має бути її кінцева конфігурація: із «Завжди вимагати схвалення» увімкненим чи вимкненим.

Крок 4 – Блокування

Заблокуйте політику. Саме блокування є запитом Manage Policies: якщо Manage Policies вже вимагає схвалення, блокування набирає чинності після схвалення іншим Учасником. З цього моменту:

• Усі запити підпорядковуються налаштованим правилам схвалення.
• Будь-яка зміна цієї політики – кількості схвалень, налаштування «Завжди вимагати схвалення», розблокування – потребує підтвердження іншого Учасника з рівнем Approve у Manage Policies. Рівень Execute у Manage Policies не дає обходу: блокування скасовує миттєве виконання для заблокованої політики.
• Зміни Власника проходять таку саму перевірку, як і зміни будь-кого іншого.

Крок 5 – Повторення

Усі інші робочі процеси зберігають поточний стан, поки Ви не повернетесь до Кроку 2 для кожного з них. Будь-яке поєднання керованих і некерованих робочих процесів є допустимим стабільним станом – послідовність є рекомендацією, а не вимогою.

Фінальний крок – блокування Manage Policies

Manage Policies має власну політику та власне блокування. Блокування цього розділу є кінцевим станом впровадження: відтоді будь-яка зміна правил в Організації — налаштування політик, блокування та розблокування — для будь-якого робочого процесу вимагатиме незалежного підтвердження, і жодна окрема особа більше не зможе послабити управління через продукт.

Виконуйте цей крок останнім – лише після того, як усі робочі процеси, які Ви плануєте контролювати, налаштовано й заблоковано. Спочатку переконайтесь, що запит Manage Policies можна ініціювати та підтвердити без Вас: потрібен хтось, хто може його створити, а також стільки інших Учасників із правом Approve у Manage Policies, скільки вимагає цей робочий процес, — усі перевірені та активні. Заблоковані політики залишаються змінюваними лише доти, доки цей маршрут існує, — система не перевіряє це за Вас. Докладніше про те, як працює це блокування, читайте в розділі «Політики, підтвердження та управління».

Фінансовий директор хоче самостійно виконувати виведення коштів негайно, тоді як кожне виведення від керуючих фондами проходить через її перевірку.

Профілі робочого процесу:

Усі троє мають роль облікового запису, що надає право на виведення коштів з операційних рахунків. Рівні в цьому прикладі стосуються лише запиту на виведення коштів. Системний профіль «Ініціатор» також надає право ініціювати всі інші робочі процеси. Використовуйте власний профіль, якщо менеджери фонду мають ініціювати виведення коштів, але не інші підконтрольні операції.

Політика запиту на виведення: необхідна кількість підтверджень — 1, «Always require approval» вимкнено, політику заблоковано.

Результат: виведення коштів фінансовим директором виконуються негайно через право Execute. Виведення коштів кожного менеджера фонду очікує на одне підтвердження — на практиці від фінансового директора, оскільки вона єдина, хто має право підтверджувати. Ніхто не може змінити ці правила самостійно, оскільки політику заблоковано.

Перед блокуванням переконайтеся, що запит Manage Policies можна підтвердити без особи, яка його ініціює: має бути стільки учасників із правом Approve у робочому процесі Manage Policies, скільки вимагає цей робочий процес. Ці учасники підтверджуватимуть майбутні зміни політики та запити на розблокування. Система не перевіряє це автоматично.

Подальше посилення. Коли компанія вирішить, що всі виведення коштів, зокрема й від фінансового директора, потребують перевірки, зміна проходить через запит на зміну політики (потрібне незалежне підтвердження, оскільки політику заблоковано):

1. Перенесіть менеджерів фонду до профілю з правом Approve, щоб вони могли перевіряти запити одне одного та запити фінансового директора.
2. Підвищте необхідну кількість підтверджень до 2.
3. Увімкніть «Always require approval».

Право Execute фінансового директора залишається в її профілі в неактивному стані. Якщо компанія колись знову помʼякшить політику, її прискорений маршрут відновиться без повторного призначення доступу.

Команда з чотирьох осіб у робочому процесі запиту на виведення — показано, як визначається право на підтвердження для кожного запиту:

Політика: необхідна кількість підтверджень — 2, «Always require approval» увімкнено (тож право Execute власника неактивне).

• Запит на виведення налаштовано, перевірено та заблоковано
• Режим запиту на переказ визначено (швидкий шлях або повне погодження) та заблоковано
• Вимоги до схвалення в розділі «Керування адресами» встановлено; білий список контролює кожне виведення
• Політики «Керування командою та доступом» і «Керування ключами API» налаштовано; зміни доступу та нові облікові дані варто переглядати
• «Керування політиками» переведено під управління, а як фінальний крок заблоковано його власну політику, щоб самі правила були захищені
• Запит у розділі «Керування політиками» можна ініціювати та схвалити без участі будь-якої окремої особи: потрібен ініціатор і стільки інших учасників із рівнем «Схвалити» на цьому робочому процесі, скільки вимагає політика, — це забезпечує можливість змінювати заблоковані політики
• Заплановано регулярний перегляд доступу за допомогою журналу подій безпеки