Започнете с решението за напускане и отговорниците
Човешки ресурси или упълномощеният ръководител трябва да предостави момента на прекратяване и одобрените указания през доверен процес. ИТ не трябва да извежда условията от неформално съобщение. Определете кой координира, кой отговаря за всяка система и кой решава липсващата информация. Планираното напускане и неотложното ограничаване може да изискват различна последователност.
Разделете премахването на личния достъп от запазването на организационните данни. Поща, проектен файл или автоматизация може да се нуждае от нов собственик. Изисквания за съхранение или правно задържане могат да повлияят на изтриването и лицензите. Microsoft публикува последователност за напуснали служители, обхващаща достъп, поща и файлове; проверете актуалните условия за вашия тенант и лицензи преди необратими промени.
Опишете достъпа извън основния каталог
Попитайте ръководителя какво действително е използвал служителят и съпоставете отговора с наличните записи за идентичности, устройства и приложения. Включете външни облачни услуги, партньорски портали, хранилища за код, облачни конзоли, VPN, общи акаунти и контакти за възстановяване. Единният вход улеснява част от администрирането, но не доказва, че всяка услуга участва в същото прекратяване.
Търсете собственост, а не само членство. Служителят може да притежава планирана интеграция, да одобрява плащания или да е единственият администратор на доставчик. Премахването без прехвърляне на отговорността може да прекъсне работата. Обратно, запазването на целия личен акаунт заради една интеграция оставя ненужен достъп.
Записвайте отделно промяната и ефекта
| Път за достъп | Действие за съгласуване | Въпрос за проверка |
|---|---|---|
| Основна идентичност | Блокиране на вход и отнемане на съответните сесии | Отказва ли ресурсът достъпа според очакването? |
| Външно приложение | Премахване на членство или блокиране на местния акаунт | Остава ли самостоятелен начин за вход? |
| Обща парола | Смяна и актуализиране на разрешените зависимости | Старата парола престава ли да работи? |
| Устройство или възстановяване | Одобрени действия по устройството и възстановяването | Може ли още да възстанови или запази достъп? |
| Притежавана автоматизация | Прехвърляне на собственост и преглед на права | Работи ли процесът без личния достъп? |
Доставчик може да запази приложна сесия след промяна в идентичността според архитектурата и поддръжката на отнемане. Запишете проверените ресурси и часове. Статията за MFA и защита на сесиите обяснява защо входът и издадената сесия се разглеждат отделно.
Използвайте контролирана проверка за приемане
При планирано упражнение договорете тестови акаунти, ресурси, разрешени действия и граница за спиране. Проверявайте съответните пътища с минимално излагане на реални данни. Резултатът в едно приложение не установява поведението на друго с различен модел на сесиите.
При действително напускане използвайте административните записи, наблюденията при ресурса и одобрените процедури за проверка. Не искайте от бившия служител да разкрива парола или да влиза отново, за да доказва процеса. Ако проверка не може да се изпълни, посочете неизвестното, отговорника и временното ограничение.
Измислен пример: забравеният портал на доставчик
Централният акаунт е блокиран навреме, но портал за покупки има отделен местен вход и посочва служителя като единствен контакт за възстановяване. Записът от основния каталог потвърждава само част от резултата. Отговорникът за портала трябва да уреди упълномощен заместник, да премахне стария достъп и да провери новия път за възстановяване.
Примерът показва зависимост в достъпа, а не клиентски резултат на Диасол. Важният въпрос за приемане е дали бившият потребител може да достигне бизнес ресурса по друг път. Той е по-полезен от броенето на завършените задачи в каталога.
Приключете записа с бизнес отговорника
Използвайте списъка за проверка при отписване, за да запишете системите, отговорниците, момента, промените, доказателствата и останалите изключения. Пазете препратки към чувствителните доказателства, а не пароли, кодове за възстановяване или стойности на токени. Запишете кой приема всяко изключение и кога то изтича.
Завършеният запис трябва да посочва и прехвърлените файлове, отговорността за пощата, собствеността на приложенията и оборудването, когато са в обхват. Планирайте последваща проверка за забавени действия на доставчици или нерешен достъп. Приключване означава изпълнение на договорените критерии, а не само изчезване на името от каталога.
Къде може да помогне Диасол
Практическата проверка на достъпа може да опише пътищата и повторимите проверки с вашия ИТ екип. Ако резултатът е нужен на клиент, свържете записа с доказателствата към въпросник за сигурност. Отговаряйте за проверения обхват и дата; едно успешно отписване не доказва, че всеки исторически акаунт е проверен.