Банальна прогалина в процесі звільнення співробітника обернулася для однієї компанії фінансовими втратами в сотні тисяч доларів. Історію розповів Яд Сенапаті, генеральний директор Project Management Training Institute в Далласі.
За його словами, коли одного зі співробітників звільнили, ніхто так і не заблокував йому доступ до внутрішніх систем. Розлючений колишній працівник просто увійшов у свій обліковий запис і почав діяти: видаляв файли, блокував облікові записи інших користувачів і навіть пошкодив базу даних компанії.
Чому так вийшло
Як стверджує Сенапаті, облікові дані цього чоловіка залишалися активними ще кілька днів після того, як його виключили з платіжної відомості. Проблема полягала не в технічному збої, а в елементарній відсутності відповідальних: у відділі кадрів вважали, що доступ вимкне ІТ-відділ одразу після оформлення звільнення, а ІТ-відділ, своєю чергою, чекав на офіційний запит від HR. Коли за процес не відповідає конкретна людина і немає чіткого дедлайну, такі речі легко випадають з уваги — і виявляються вже тоді, коли проблема сталася.
Ситуацію ускладнював масштаб доступу, який мав звільнений працівник: спільні адміністративні облікові дані, керування обліковими записами та системи відстеження проєктів. Кожна з цих систем, своєю чергою, відкривала доступ до інших — вийшов ефект доміно, яким колишній співробітник і скористався, щоб помститися всій організації.
Загальні збитки, за оцінкою Сенапаті, сягнули сотень тисяч доларів, а важливий проєкт компанії затримався на кілька тижнів. Ситуацію додатково ускладнювала іронія: відновлювати пошкоджені системи було особливо важко саме тому, що краще за всіх на це здатен був той самий колишній працівник, який їх і зламав.
Керівник підкреслює, що звільнений не був якимось геніальним хакером — він просто зберіг доступ, і ніхто не змінив облікові дані та не перевірив адміністративні права. Проблема, за його словами, полягала ще й у тому, що цей конкретний співробітник мав значно ширші права, ніж пересічний користувач, тож ІТ-відділ навіть не до кінця розумів, що саме потрібно було відключити.
Що радять робити інакше
Сенапаті наполягає: перевірка й скасування доступу мають бути таким самим обов’язковим пунктом офбординг-чек-листа, як і повернення робочого ноутбука. За його словами, ситуації можна було уникнути, якби компанія практикувала видалення доступу день у день зі звільненням, примусовий повторний перегляд усіх спільних облікових записів і принцип нульової толерантності до того, щоб одна людина одноосібно володіла цілою системою.
Автор матеріалу, оглядач The Register Аврам Пільч, який спілкувався з Ядем Сенапаті, додає до цього власний досвід: після звільнення з попередньої роботи він одразу втратив доступ до пошти, чату й спільних дисків — але через кілька місяців колишній керівник запитав, чи не може той усе ще увійти у важливу зовнішню базу даних і показати, як нею користуватися. Виявилося, що доступ так і залишився активним.