Керування доступами віддаленої команди стає складним, коли одна людина працює одразу в кількох сервісах. Створити обліковий запис зазвичай легко. Набагато важче пояснити, хто дозволив доступ до клієнтських файлів, чому тимчасовий підрядник досі бачить репозиторій і чи перестав працювати старий токен після завершення договору.
Розгляньмо вигадану студію, де дизайнер переходить у роль менеджера проєкту. Йому потрібні звіти та бюджет конкретного замовлення, проте доступ до попереднього клієнтського простору вже зайвий. Якщо система лише додає нову роль поверх старої, щоденна робота поступово розширює дозволи без усвідомленого рішення керівника.
Створіть реєстр систем і власників
Почніть із переліку робочих сервісів: пошта, репозиторії, хмарний кабінет, підтримка, файлові сховища та адміністративні панелі власних продуктів. Для кожного визначте власника, спосіб надання прав і спосіб підтвердити відкликання. Невелика актуальна таблиця корисніша за портал, який не охоплює половину реальних систем команди.
Опис доступу має містити конкретний простір або проєкт, а не лише назву сервісу. Доступ читача до одного репозиторію відрізняється від адміністрування організації. Окремо обліковуйте сервісні облікові записи та інтеграції: вони можуть продовжувати працювати після блокування особистого профілю, хоча не повинні належати випадковому колишньому працівнику.
Зміну ролі оформлюйте як заміну набору прав
У запиті на нову роль покажіть поточні дозволи, бажані дозволи й різницю між ними. Керівник має погоджувати зміст зміни, а не абстрактне підвищення рівня. Якщо частина старих прав потрібна для передачі справ, задайте строк і відповідального за повторний перегляд, не залишайте виняток без кінцевої умови.
Сервер повинен перевіряти право на кожну захищену дію. Тестуйте зміну ролі з уже відкритою вкладкою: старий інтерфейс може залишатися на екрані, але наступний запит більше не повинен виконувати заборонену операцію. Те саме стосується експорту, фонових завдань і збережених прямих посилань на файли іншого проєкту.
Вихід працівника потребує підтвердження в кожній системі
Визначте час завершення доступу та порядок термінового блокування. Після відключення перевірте активні сесії, ключі API, особисті токени, спільні секрети й дозволи зовнішніх інтеграцій у межах їхніх можливостей. Не позначайте сервіс виконаним лише тому, що автоматизація надіслала команду: потрібен результат або явний запис про ручну перевірку.
Передавайте власність на робочі документи та автоматичні процеси за окремим маршрутом. Блокування автора не повинно непомітно зупинити звіт чи резервне копіювання. При цьому не копіюйте весь його обліковий запис іншій людині. Новий відповідальний отримує власну ідентичність, необхідний обсяг прав і зрозумілу історію передачі робочих ресурсів.
Перевіряйте сценарій, а не кількість зелених позначок
Для приймання створіть тестового учасника, надайте обмежений доступ, змініть роль і заверште співпрацю. Спробуйте відкрити старий файл, повторити запит із попередньої сесії та використати окремо виданий токен. Перевірте також збій одного зовнішнього сервісу: завдання має залишитися відкритим із власником, а не зникнути серед успішних кроків.
Журнал повинен допомогти відповісти, хто погодив права і коли фактично завершилося відкликання, не розкриваючи секрети. Brainbaby Labs може спроєктувати такий адміністративний процес і потрібні інтеграції. Почніть із переліку систем, прикладу переходу між ролями та одного реального типу тимчасового доступу; це дозволить визначити перевірювані межі першої версії.