AUT-0462· Персонал
Перегляд доступів після зміни посади або відділу
Зміна ролі працівника запускає перевірку старих і потрібних нових доступів із погодженим переходом та підтвердженням результату.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Працівника переводять до іншого відділу або змінюють його посаду. Нові права додають за запитом менеджера, але старі доступи часто залишаються активними, а власники систем не бачать повної зміни ролі.
02 / Результат
Для кожної кадрової зміни визначені старі права, схвалені нові права, дата переходу, власники систем і перевірений результат відкликання та надання доступів.
03 / Процес
ТригерУ кадровому джерелі змінилася посада, відділ або керівник працівника.
Отримати підтверджену кадрову подію з ідентифікатором працівника, старою та новою посадою, підрозділом, керівником і датою чинності.
Перевірити попередній і новий профілі доступу за каталогом ролей; невідомі або надмірно широкі призначення передати власнику ресурсу.
Скласти перелік прав до відкликання, нових прав на погодження та дозволених тимчасових винятків для передавання роботи.
Надіслати рішення керівнику й власникам відповідних систем; несумісні ролі або конфлікти обов’язків ескалювати окремому погоджувачу.
Запланувати зміну на дату переходу: старі права відкликати у погоджений строк, нові надати після потрібних погоджень.
Для перехідного доступу встановити власника й дату автоматичного завершення; відсутність відповіді не продовжує права.
Передати затверджені зміни до перевірених систем або виконавцям, зберігаючи окремий статус для кожного застосунку й групи.
Повторно прочитати поточні призначення, порівняти їх із погодженим набором і залишити невиконані відкликання відкритими винятками.
Зберегти кадрову подію, версію профілю, рішення погоджувачів, виконавців, часові мітки й результат для аудиту.
04 / Реалізація2 варіанти
Приклад · Подієва синхронізація профілів доступу
Подія зміни підрозділу запустила перевірку профілів, зняла дві старі групи в дату переходу, додала погоджену групу продажів і залишила одну систему відкритим винятком для адміністратора.
Спосіб реалізації
- Читати кадрові зміни з унікальним ID і підтримувати повторну доставку без дубльованих дій.
- Обчислювати різницю між погодженими старими й новими профілями доступу.
- Застосовувати, перечитувати й журналювати зміну кожного доступу окремо.
Що потрібно для реалізації
- Кадрове джерело передає достовірні зміни ролі та дату набрання ними чинності.
- Є погоджений каталог профілів доступу, власників систем і матриця несумісних повноважень.
- Визначені правила строків відкликання, тимчасового доступу, винятків і підтвердження фактичного стану систем.
- Перевірені API, тестовий контур і призначені власники профілів доступу.
Обмеження
- Кадрова зміна не доводить, що нові права вже погоджені або що всі системи підтримують автоматичне відкликання.
- Профілі доступу, матрицю несумісних обов’язків і винятки потрібно затвердити для кожного клієнта.
- Картка охоплює подію зміни ролі; планові перегляди доступів і вихід працівника залишаються окремими процесами.
- Ліцензії Microsoft Entra, доступність задач і затримки обробки залежать від цільової конфігурації та плану підписки.
- Години попередні; джерела кадрових подій, кількість застосунків та інтерфейси відкликання уточнюють після аудиту.
- Системи без API потребують контрольованої ручної задачі; не можна вважати відсутність відповіді погодженням.
Що потрібно уточнити (2)
- Чи потрібно змінювати доступи більш ніж у трьох системах?
Вкажіть системи, власників і спосіб підтвердження фактичних змін.
- Чи потрібні тимчасові старі доступи для передачі роботи?
Потрібні власник винятку, дозволений обсяг прав і точна дата завершення.