Ілля Зав'ялов

Облік

Ілля Зав'ялов пояснює, як зробити перелік доступів, що переживе перший місяць

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

Версія українською мовою для України.

Огляд / Блог

· 12 хв читання · Ілля Зав'ялов

Ілля Зав'ялов пояснює, як зробити перелік доступів, що переживе перший місяць
Ілля Зав'ялов пояснює, як зробити перелік доступів, що переживе перший місяць

01

Три причини, з яких перелік доступів помирає

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

Друга причина стосується авторства. Рядки заповнює людина, яка доступів не видає: помічник, менеджер проєкту, іноді засновник наприкінці кварталу. Вона відновлює чужі дії по пам'яті із затримкою в кілька тижнів. Кожен такий запис неточний уже в момент появи, бо точної ролі і точної дати ніхто не тримає в голові. Після двох циклів такого оновлення довіра до таблиці зникає, і команда повертається до питань у чаті.

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

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

02

Мінімальний рядок, який справді заповнюють

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

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

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

03

Момент запису: доступ і рядок з'являються разом

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

Щоб правило працювало, видача доступів має проходити одним каналом. Заявка приходить у трекер або в один робочий чат, там же приймається рішення, там же залишається слід. Коли каналів кілька, частина видач проходить повз перелік, і таблиця знову відстає. Один канал коштує дешевше за будь-яку спробу відновити картину заднім числом.

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

04

День звільнення як перевірка переліку

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

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

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

05

Підрядники і доступ із датою закінчення

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

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

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

06

Сервісні акаунти, інтеграції і ключі без власника

Частина доступів не належить жодній людині. Ключі до платіжного провайдера, підключені інтеграції, боти в робочому чаті, вивантаження в аналітику: усе це працює роками і не має обличчя. Коли людина, яка це налаштувала, іде з команди, залишається робочий доступ, про який ніхто не думає. Такі доступи рідко потрапляють у перелік, бо їх створюють під час технічної роботи, коли про перелік нікому не спадає на думку.

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

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

07

Перелік як відповідь на підробку особи

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

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

Масштаб проблеми видно у звітності. За даними FBI Internet Crime Complaint Center за 2025 рік, компрометація ділового листування дала 3,046 мільярда доларів заявлених втрат і посіла друге місце після інвестиційного шахрайства. Federal Trade Commission за той самий рік зафіксувала близько мільярда доларів втрат на підробці під компанії, причому найбільші втрати були в тих, кому дзвонили нібито зі служби банку. Обидві категорії тримаються на тому, що людина по той бік не має швидкого способу перевірити чужу роль.

08

Квартальна звірка: таблиця проти дійсності

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

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

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

09

Ролі навколо переліку доступів

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

Друга роль належить тим, хто видає доступи. Таких людей варто залишити небагато і назвати поіменно, бо кожен додатковий видавець збільшує кількість шляхів, якими доступ обходить перелік. Ці люди пишуть рядки і відповідають за їх своєчасність. Коли видавців доступу набирається більше трьох, варто перевірити, чи кожен з них справді потребує цього права.

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

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

10

Ознаки того, що перелік живий

Живий перелік розпізнається за трьома ознаками. Останній запис у ньому не старший за останню зміну в команді. Будь-хто з тих, хто видає доступи, відкриває його за кілька секунд без пошуку посилання. І в ньому стоїть дата останньої звірки, зроблена в поточному кварталі. Є ще одна непряма ознака: у команді перестають ставити в чаті питання про те, хто має доступ до конкретного сервісу.

Практичний ефект такої дисципліни видно на статистиці спроб. За даними Federal Trade Commission за 2025 рік, у чотирьох зверненнях про підробку особи з п'яти грошової втрати не було зовсім, тобто спроб відбувається набагато більше, ніж успіхів. Той самий рік у звіті FBI Internet Crime Complaint Center дав 1 008 597 звернень і майже 21 мільярд доларів втрат, на 26 відсотків більше, ніж роком раніше. Фон навколо будь-якої команди щільний, і різницю робить швидкість відповіді на питання про чужі права.

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

Що потрапляє в перелік доступів після кожної події
ПодіяЩо записуютьХто робить запис
Нова людина в командіСервіс, роль, дата, хто підтвердивТой, хто видав доступ
Зміна ролі або правНова роль і дата зміниТой, хто змінив права
Доступ підрядникуРоль і дата закінченняКерівник проєкту
Нова інтеграція або ключСервіс і людина-власникТой, хто підключив
ЗвільненняДата відключення по кожному рядкуТой, хто закриває доступи
Квартальна звіркаДата звірки і виправлені рядкиВласник процесу
ІнцидентЩо відкликано і о котрій годиніТой, хто веде реагування

Питання і відповіді

Що має бути в переліку доступів?

Людина, сервіс, роль, дата видачі і той, хто підтвердив рішення. Для тимчасових доступів додається дата закінчення. Більша кількість полів це найчастіша причина, з якої перелік перестають заповнювати.

Хто має вести перелік доступів у невеликій команді?

Рядки пише той, хто видає доступ, у момент видачі. За форму, строки звірки і повноту переліку відповідає одна названа людина, зазвичай операційний керівник.

Як часто перевіряти перелік доступів?

Раз на квартал достатньо для команди до кількох десятків осіб. Звірка займає півдня і закінчується датою перевірки, інакше наступного разу ніхто не згадає, чи проводили її взагалі.

Чи потрібен перелік доступів команді з п'яти осіб?

Потрібен, бо в маленькій команді один звільнений або один підрядник тримає доступ до всього одразу. Обсяг роботи при цьому мінімальний: п'ять полів і кілька рядків на місяць.

Що робити з доступами підрядника після завершення проєкту?

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

Чи допомагає перелік доступів проти клонованого голосу і підробки особи?

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

Автор: Ілля Зав'ялов, консультант з цифрової безпеки. Огляд для невеликої команди