A*
👍
Size: a a a
2021 June 11
A*
Так и есть... :-(
RK
Аплодирую стоя👍👏
M
Благодарю. 🙂 Уже не занимаюсь внедрением IdM, но, как говорится, руки-то помнят...
RK
Все споры и прерия одним постом в нокаут) полезно, познавательно, по существу) уверен, инициаторы диалога оценят)
M
Нокаутировать кого-то цели не стояло, только прокомментировать и поделиться информацией. 🙂 Если кому-то интересна тема IdM, ещё в 2017-2018 годах я писала статьи на Хабр с общим заголовком "Внедрение IdM", легко найти. Там много информации, хотя все возможные сценарии внедрения, конечно, охватить невозможно. Может кому полезно будет.
V
Оценил. Ценно. 👍
V
В моей практике был случай, когда idm спас бизнес-аналитиков, пытавшихся руками! выстроить профили в ролевой модели. На входе было 3500 ролей) в итоге свели все к 18 профилям
AD
изначально вроде как вопрос был не про айдиэм, а про блокировку неактивных по времени учеток
M
Ну, IdM и это умеет 😁
Если возвращаться к первой теме, то считается хорошей практикой блокировать учётки при простое. Какой именно временной промежуток выбрать смотрите сами. Можно поставить фиксированный срок для всех систем (для примера - 60 дней) или установить для каких-то систем свой срок (зависит от разных факторов вроде критичности системы и конкретных прав доступа в учётке).
Если возвращаться к первой теме, то считается хорошей практикой блокировать учётки при простое. Какой именно временной промежуток выбрать смотрите сами. Можно поставить фиксированный срок для всех систем (для примера - 60 дней) или установить для каких-то систем свой срок (зависит от разных факторов вроде критичности системы и конкретных прав доступа в учётке).
M
Об эту тему столько копий сломано... Но да, без живого IdM формировать профили или ролевую модель - сизифов труд.
V
В споре родилась истина в виде эволюции от ракушки мощи до управления процессом управления доступом. Всем пятницы!
AD
а что хорошего в этой практике? я приводил примеры учеток для экстренного доступа, которые используются реже чем раз в 60 дней, и примеры что с отсутствующими сотрудниками необходимо поддерживать связь (например по почте - проверка почты почтовым клиентом не дает логона)
V
Ну, разум то в любом случае нужно включать. Есть учетки, которые нужно лочить, а есть вечно живущие, для сервисов, экстренных ситуаций и т.п.
AD
лочить чтоб что?
M
Практика применения данного подхода (ответ на вопрос "зачем?") многогранна. Вопрос в том, как эту самую практику применить в реалиях вашей инфраструктуры. Наверное же есть разные признаки активности по учётной записи, не только формальный логон. Стоит заметить, что из каждого правила есть исключения, может у вас такой случай по ряду учёток?
AD
ну проверка почты это активность или нет? это ж клиент почтовый проверяет почту, а человек не делает для этого никаких действий
V
Чтобы нивелировать "ой забыли" при увольнении сотрудника, завершения аудита, и тд
M
Ну так в вашем случае вопрос в том, чтобы определить активная учётка или нет, а не в том, чтобы не лочить...
AD
а если забыли, а уволенный активно пользуется, то у вас нет механизма его обнаружить? если нет, то блокировка неактивных вам не поможет