Постъпващи, преместващи се и напускащи: поддържайте отчетност за достъпа

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

Постъпващите, преместващите се и напускащите се нуждаят от процес, който свързва бизнес събитие с одобрено състояние на достъпа, изпълнява необходимите промени и проверява резултата. От гледна точка на техническото ръководство важният въпрос не е дали съществува контролен списък за напускане. Въпросът е дали процесът обхваща системите, които хората реално използват, дали обработва неуспехите и дали оставя доказателства за това какво и кога е променено.

Определете жизнения цикъл и предаванията в него

Третирайте всяко събитие от жизнения цикъл като промяна в разрешения достъп на дадено лице, а не просто като заявка за създаване или деактивиране на акаунт. Записът за събитието трябва да идентифицира лицето, статуса на трудовото правоотношение или ангажимента, мениджъра или спонсора, датата и часа на влизане в сила и засегнатата роля. Използвайте стабилен идентификатор, вместо да разчитате само на имена или имейл адреси.

Събитията за служителите често се инициират от HR. Събитията за външни изпълнители може да се инициират от отговорник по снабдяването, ръководител на проект или вътрешен спонсор. Изберете авторитетен източник за всяка група и определете как корекциите, отменените постъпвания, удълженията на договори и спешните напускания достигат до ИТ.

Разделете четири отговорности, дори когато в малък екип няколко от тях са възложени на едно и също лице:

Посочете заместници и път за ескалация. Планирано напускане не бива да зависи от наличността на един администратор. При чувствителни промени независим проверяващ осигурява полезна проверка; когато персоналът не позволява това, документирайте договореността и използвайте последващ преглед.

Определете критерии за завършване за всяко събитие. Постъпващият е готов, когато одобреният достъп и изискваните контроли за устройствата са проверени. Преместването е завършено, когато са проверени както добавянията, така и премахванията. Напускането е завършено, когато пътищата за достъп са отменени, а нерешените въпроси, свързани с активи, данни или идентификационни данни, имат изрични собственици.

Това са практически препоръки за проектиране на контроли, а не универсални законови срокове. В рамките на ISMS по ISO 27001 контролите за достъп трябва да отразяват обхвата на организацията и третирането на риска. Вижте Приложение А на ISO 27001 на практика за по-широкия контекст на контролите.

Установете покритието, преди да автоматизирате промените

Започнете с описа на приложенията. За всяка система запишете собственика ѝ, източника на идентичности, метода на предоставяне на достъп, метода на удостоверяване, поддържаните действия за отнемане на достъпа и метода за проверка. Включете централно управляваните приложения и тези с локални акаунти.

Единният вход не означава непременно пълно управление на жизнения цикъл. Приложението може да удостоверява чрез доставчика на идентичности, като същевременно поддържа локални администратори, API ключове, активни сесии или възможности за възстановяване. Конектор за предоставяне на достъп може да деактивира потребител, без да премахне всяко право. Документирайте какво реално прави всеки механизъм.

Включете тези по-малко видими пътища за достъп:

• Привилегировани акаунти, отделни от ежедневния акаунт на лицето.
• VPN достъп, сертификати, SSH ключове и инструменти за отдалечена поддръжка.
• Лични токени за достъп, API идентификационни данни и пароли за приложения.
• Споделени идентификационни данни, които лицето е знаело или е можело да извлече.
• Акаунти за гости, външни пространства за сътрудничество и среди, управлявани от клиенти.
• Идентичности на услуги, чийто собственик или пазител на идентификационните данни се сменя.

Не деактивирайте автоматично всяка идентичност на услуга, свързана с напускащ служител: тя може да изпълнява продукционно натоварване. Вместо това прехвърлете собствеността, прегледайте правата и сменете разкритите идентификационни данни, когато е уместно. Целта е да се премахне достъпът на лицето, без да се предизвика прекъсване, което може да бъде избегнато.

Периодично съгласувайте описа с експорти от системата за идентичности, записи за устройствата, записи за покупки и декларации на екипите. Нито един източник сам по себе си няма непременно да разкрие всяко приложение. Откритите неуправлявани системи трябва да влизат в процеса на жизнения цикъл, вместо да остават неформални изключения.

Постъпващи: предоставете контролирано начално състояние

Изградете базови профили по роли с ограничени изключения

Определяйте пакетите за достъп около отговорностите, а не само около длъжностите. Анализатор в поддръжката може да се нуждае от достъп до клиентските заявки, но не и до експортите за фактуриране. Софтуерен инженер може да се нуждае от хранилищата с код и средите за разработка, без по подразбиране да получава администраторски права в продукционната среда.

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

Заявявайте допълнителния достъп отделно. Заявката трябва да посочва бизнес целта, одобряващия собственик на системата или данните, нивото на правата и срока на валидност, когато е уместно. Избягвайте копирането на пълния набор от права на съществуващ служител: това може да възпроизведе натрупани изключения и привилегии от предишни роли.

Подгответе акаунтите преди началната дата, когато това е полезно, но контролирайте активирането. Отменено назначение трябва да задейства почистване на подготвените акаунти, изпратените устройства и поканите. Външните изпълнители трябва да имат вътрешен спонсор и крайна дата или дата за преглед; удълженията трябва да изискват изрично решение, вместо мълчаливо да се превръщат в постоянен достъп.

Установете базовото ниво за устройствата и удостоверяването

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

Това са основани на риска избори при внедряването, а не твърдение, че всяка организация трябва да използва еднакви настройки. За личните устройства определете изрично разрешения достъп и боравенето с данни, вместо да ги третирате като равностойни на управляваните лаптопи.

Използвайте датирани наблюдения от системите за управление на устройства, когато са налични. Ръчният опис все пак може да е полезен, ако е съгласуван и подкрепен с доказателства; актуалният опис също изисква внимание, когато дадено устройство е спряло да докладва. Пазете времето на наблюденията, за да не се бърка старо добро състояние с текуща увереност.

Проверете регистрирането за удостоверяване и първоначалното предаване на идентификационните данни. Когато политиката ви изисква многофакторно удостоверяване, потвърдете, че то е активно, преди да започне достъпът, вместо да записвате само, че е изпратена покана за регистрация. Не включвайте идентификационни данни и кодове за възстановяване в заявките за жизнения цикъл.

Преместващи се: премахнете старата роля, а не само добавяйте новата

Преместванията често са най-трудните събития от жизнения цикъл, защото лицето остава на работа и съществуващият му акаунт продължава да работи. Новият достъп получава внимание, защото липсващите права прекъсват работата. Старият достъп може да се запази без видими симптоми.

Третирайте преместването като сравнение между три състояния: текущия достъп, одобрения нов базов профил и одобрените продължаващи изключения. Определете кои права трябва да бъдат добавени, запазени, намалени или премахнати. Проверете директните назначения, както и групите, вложените членства, администраторските роли и локалните права в приложенията.

Предишният мениджър трябва да помогне да се идентифицират отговорностите, които са приключили. Приемащият мениджър потвърждава новите задължения, а собствениците на системи или данни одобряват чувствителния достъп. Това не позволява новият мениджър имплицитно да разреши запазен достъп до информацията на друг отдел.

Преходен период може да бъде легитимен. Някой, който напуска финансовия отдел, може да се нуждае от ограничен достъп, за да завърши предаването на работата. Запишете конкретното право, обосновката, одобряващия собственик и срока на валидност. Когато е осъществимо, заменете широкия достъп за запис с по-тесен или само за четене. Включете изтичането на срока в изпълнима задача или системна настройка, а не само в коментар.

Промените може да засягат и устройства, споделени пощенски кутии, собствеността върху данни и привилегировани задължения. Преминаването в администраторска роля не бива автоматично да превръща ежедневния акаунт в привилегирована идентичност.

След изпълнението сравнете действителния набор от права с предвидения резултат. При преместване в друг отдел предоставянето на новата роля може да е лесно. Важната проверка е дали остава стар достъп до финансови, клиентски или администраторски функции. Извадка от премествания, която проверява само новото предоставяне на достъп, пропуска този риск.

Напускащи: координирайте отнемането на достъпа, активите и непрекъснатостта на дейността

Определете времето според риска и обстоятелствата

Запишете точно време за отнемане на достъпа, включително часовата зона. „Последен ден“ е твърде неясно за разпределени екипи и планирана автоматизация. Разграничавайте планираното напускане от спешно прекратяване, подозирано компрометиране или неочаквано отсъствие, изискващо временно спиране.

Съгласувайте времето с HR и съответното ръководство. Ограничете чувствителните подробности за прекратяването до тези, които се нуждаят от тях, като същевременно гарантирате, че изпълнителите получават достатъчно информация, за да действат. Напусканията с висок риск може да изискват координирани незабавни действия; рутинните напускания може да позволят планирано предаване на работата преди края на достъпа.

Не позволявайте прехвърлянето на данни или изпращането на устройства да забави отнемането на достъпа. Тези дейности могат да имат отделни дати за завършване и собственици. Ако задействащото събитие пристигне късно, запишете предвидения краен момент, действителното изпълнение и интервала на експозиция, вместо да променяте документите, за да изглежда събитието навременно.

Затворете всички съответни пътища за достъп

Деактивирайте основната идентичност и изпълнете специфичните за всяко приложение действия от описа. Обработете активните сесии, токените за опресняване, локалните акаунти, привилегированите акаунти, отдалечения достъп, сертификатите и личните идентификационни данни, според случая. Деактивирането на централния акаунт не доказва, че всяка съществуваща сесия или независимо издадени идентификационни данни са станали неизползваеми.

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

Записвайте отделните резултати. Изтичане на времето за изчакване на конектор не е успешно затваряне само защото цялостната задача е приключила. Насочвайте неуспехите към посочено отговорно лице, използвайте одобрена резервна процедура и проверявайте крайното състояние. Спешният нерешен достъп трябва да влиза в процеса за ескалация по сигурността.

Възстановявайте устройствата, без да приемате, че отдалечените команди са успели

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

Ако връщането се забави, използвайте наличните контроли за заключване или изтриване според политиката и риска. Разграничавайте издаването на команда от потвърждението и изпълнението ѝ от устройството. Лаптоп, който е офлайн, може да не получи командата. Оценете остатъчната експозиция чрез статуса на криптирането, локалните идентификационни данни, кешираните данни и наличните мрежови ограничения, вместо да третирате „изтриването е в опашката“ като доказателство за изтриване.

Запазете необходимите данни и си върнете лицензите

Определете приемник за бизнес документите, хранилищата, споделените процеси и собствеността върху услуги. Използвайте разрешени административни механизми за прехвърляне, вместо да молите някого да се представя за бившия служител. Ограничете обхвата на достъпа до пощенската кутия или файловете, запишете целта и ограничете кръга от хора, които го получават.

Разделете отнемането на достъпа, връщането на лицензите, съхранението и изтриването. Премахването на лиценз може да се отрази различно на наличността на данните в различните приложения. Проверете изискванията за съхранение и евентуално задължение за запазване на данни поради правен спор преди необратимо почистване.

По отношение на личните данни член 5 от ОРЗД установява ограничение на съхранението; той не създава един универсален срок за изтриване на акаунтите на служителите. Определете обосновани срокове за съхранение и отговорности за почистване. Член 32 изисква мерки за сигурност, съответстващи на риска, затова документирайте обосновката на контролите при напускане, вместо да третирате контролен списък като самостоятелно правно съответствие.

Пазете доказателства за действителната промяна

Полезният запис свързва разрешеното решение с наблюдавания резултат. Пазете събитието, одобрението, засегнатите системи, времето на изпълнение, резултатите от проверката и обработката на изключенията. Включете предвиденото време на влизане в сила, за да могат проверяващите да оценят навременността.

Практичният пакет с доказателства съдържа:

• Стабилен идентификатор на лицето и събитието, с иницииращия източник.
• Одобрения базов профил и всички запазени или допълнителни права.
• Действия, резултати, времеви отметки и съответни препратки към логове за всяка система.
• Проверка, показваща полученото състояние на достъпа.
• Резултати относно активите, прехвърлянето на данни и лицензите, когато е приложимо.
• Неуспешни действия и изключения със собственик, краен срок и доказателство за закриване.

Политиката доказва намерение. Заявката доказва координация. Резултатът от приложение или експортът на достъпа помагат да се докаже внедряването. Нито едно от тях не бива да замества другите. Екранните снимки могат да бъдат полезни, когато не са налични по-силни експорти, но включвайте достатъчно контекст, за да се идентифицират системата, лицето и времето на наблюдението.

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

Практически пример: преместване, последвано от напускане

Да разгледаме илюстративна компания с централен доставчик на идентичности, управлявани лаптопи и финансово приложение с локални права. Да приемем, че служител се премества от финансовите операции в отдела за работа с клиенти на 1 юни, нуждае се от пет работни дни за предаване на работата и по-късно напуска на 30 септември. Тези дати и договорености са примерни допускания, а не предписани срокове.

При преместването ИТ записва текущите права. Достъпът за отдела за работа с клиенти се одобрява, достъпът за запис във финансовото приложение се премахва в момента на влизане в сила, а ограниченият достъп за четене се запазва до изтичане на периода за предаване. Собственикът на финансовото приложение одобрява това изключение. Тъй като финансовото приложение поддържа локални права, неговият администратор изпълнява и проверява промяната отделно от актуализацията на групата в доставчика на идентичности.

При изтичането на срока проверката установява, че е останало локално право за експорт. Записът за преместването остава отворен, администраторът премахва правото, а проверяващият записва крайното състояние. Поуката е конкретна: промяната на ролята е успяла централно, но моделът на правата в приложението е изисквал допълнително действие.

При по-късното напускане процесът определя точен краен момент, прехвърля бизнес файловете на одобрен приемник, деактивира идентичностите, отменя приложимите сесии и токени и проверява директно акаунта във финансовото приложение. Лаптопът все още не е пристигнал с куриер. Връщането му остава изключение относно активите, като действията по ограничаване и наблюденията на устройството се записват отделно от отнемането на достъпа до акаунтите.

Получените доказателства показват както успешните промени, така и първоначалния неуспех при премахването. Скриването на неуспеха би загубило информацията, необходима за подобряване на процеса.

Тествайте покритието и направете следващото подобрение конкретно

Проверявайте извадка от реални събития от жизнения цикъл спрямо описа на приложенията. Включете външни изпълнители, привилегировани потребители, служители, работещи дистанционно, премествания с временно припокриване и приложения извън доставчика на идентичности. Прегледите на достъпа трябва също да проверяват дали текущите права все още съответстват на отговорностите на всяко лице; те допълват промените, задействани от събития, а не ги заменят.

Тествайте пътищата при неуспех, както и нормалното изпълнение: пропуснато HR събитие, неуспешен конектор, недостъпен администратор, забавено връщане на устройство или отменено постъпване. Проверете дали сигналите достигат до отговорно лице и дали повторните опити или ръчните действия дават проверими резултати.

Полезните показатели включват забавянето на отнемането на достъпа спрямо договорения краен момент, неуспешните действия, очакващи решение, просрочения временен достъп и събитията, закрити без проверка. Определете какво отчита всеки показател. Добрата средна стойност може да скрие едно дълготрайно привилегировано изключение. Използвайте констатациите, за да актуализирате базовите профили по роли, поведението на конекторите, собствеността и правилата за ескалация.

Secani може да подкрепи проверимия запис за контролите, като свързва изисквания със системи, собственици, доказателства и решения. Дръжте промените в акаунтите в оперативните системи за идентичности и устройства; използвайте работното пространство за съответствие, за да запазвате обхвата, качените резултати, изключенията и решенията от прегледите. Човешки проверяващи трябва да валидират всички заключения за доказателства, изготвени с помощта на ИИ, преди да се разчита на тях.

Започнете с един представителен екип и скорошно постъпване, преместване и напускане. Проследете всяко събитие от уведомлението до действителното състояние на системите. Коригирайте първото открито непокрито предаване или път за достъп, определете собственика му и го тествайте отново, преди да разширите процеса.