Комментарии 47
Вопрос без подвоха — в чем возможностей Active Directory не хватает для решения таких задач?
Хватает. Она даже может являться «интерфейсом» всей системы. Только она не со всем стыкуется. Вот тут и надо либо велосипед изобретать, либо готовую систему купить.
Не может. Потому как встаёт задача синхронизации базы пользователей.
Учетка в AD должна заводиться синхронно с остальными производственными документами. ИМХО, ЗУП для этого — самое место.
Учетка в AD должна заводиться синхронно с остальными производственными документами. ИМХО, ЗУП для этого — самое место.
О чем и говорю. AD — интерфейс, а данные из неё расползаются по всем остальным системам.
Он хочет, чтобы кадровичка заполняла, не давать же ей доступ к АД?
Давать. Заводить группу пользователей для отдела кадров и давать кадровикам право создания учёток (где будут храниться все данные пользователя). Права выдавать на основании role-based модели, когда должность (исполняемые сотрудником роли в компании) определяют его права доступа. А потом безопасники должны подтверждать учётки перед их использованием.
Именно такая модель предлагается MS.
Именно такая модель предлагается MS.
А я так и не понял в статье речь про какую-то конкретную реализацию idm(название которой просто опускают), самописную систему под конкретного клиента или это чисто теоретические рассуждения о том, что какая-то система над AD нужна?
И всё же остаются некоторые непонятки.
Взять, к примеру, 1С восьмерку, конкретнее — зарплату и управление персоналом. Никакая смена должности сотрудника не пройдет мимо отдела кадров — а туда же и штатное расписание, и положение в иерархии компании, и всё остальное.
Факт создания или обновления пользователя в 1С — вполне себе повод для создания или обновления учетной записи в OU, соответствующем подразделению компании. Смена должности внутри подразделения — смена Security Group, смена подразделения — смена OU. Увольняем сотрудника -> блокируем запись, выкидываем в треш-OU.
Да, нужны скрипты, но в IdM ведь тоже они нужны (насколько я понял, это и есть «адаптеры»).
А с управлением учетками на уровне администрации отделов — по сути, делегирование лишних полномочий для начальников отделов. Если шаблонной учетке начинает не хватать каких-то прав — то это явно не проблема администрации. Да и как показывает практика, даже при наличии таких полномочий начальство конкретных отделов во избежание лишних вопросов начинает раздавать чуть ли не максимальные права при первом появлении ошибки «Access Denied». Мол, людям работать нужно, а вы потом разбирайтесь.
В общем, я так и не проникся целесообразностью внедрения подобного решения. На бумажке-то оно красиво всё, а в жизни «совокупная стоимость владения» звучит не так убедительно, как цифра в несколько сотен долларов, умноженная на количество сотрудников.
Взять, к примеру, 1С восьмерку, конкретнее — зарплату и управление персоналом. Никакая смена должности сотрудника не пройдет мимо отдела кадров — а туда же и штатное расписание, и положение в иерархии компании, и всё остальное.
Факт создания или обновления пользователя в 1С — вполне себе повод для создания или обновления учетной записи в OU, соответствующем подразделению компании. Смена должности внутри подразделения — смена Security Group, смена подразделения — смена OU. Увольняем сотрудника -> блокируем запись, выкидываем в треш-OU.
Да, нужны скрипты, но в IdM ведь тоже они нужны (насколько я понял, это и есть «адаптеры»).
А с управлением учетками на уровне администрации отделов — по сути, делегирование лишних полномочий для начальников отделов. Если шаблонной учетке начинает не хватать каких-то прав — то это явно не проблема администрации. Да и как показывает практика, даже при наличии таких полномочий начальство конкретных отделов во избежание лишних вопросов начинает раздавать чуть ли не максимальные права при первом появлении ошибки «Access Denied». Мол, людям работать нужно, а вы потом разбирайтесь.
В общем, я так и не проникся целесообразностью внедрения подобного решения. На бумажке-то оно красиво всё, а в жизни «совокупная стоимость владения» звучит не так убедительно, как цифра в несколько сотен долларов, умноженная на количество сотрудников.
Обходной лист при любом кадровом изменении решает большую часть проблем.
Не решает в случае распределенных и удаленных рабочих мест. Есть целые службы, которые должны работать удаленно в «поле» и подписать обходной лист просто не в состоянии.
Все что касается безопасности — должно быть максимально автоматизировано и не зависеть от человеческого фактора. Иначе порядка не будет или придется постоянно заниматься перманентной «инвентаризацией» всего и вся, что с точки зрения затрат — не есть хорошо.
Все что касается безопасности — должно быть максимально автоматизировано и не зависеть от человеческого фактора. Иначе порядка не будет или придется постоянно заниматься перманентной «инвентаризацией» всего и вся, что с точки зрения затрат — не есть хорошо.
В случае c idm человеческий фактор никуда не уходит. В приведенной статье изначально был бардак, потом волевым усилием навели порядок.
Обходной лист это не обязательно кусок бумаги.
Про удаленные места аргумент мне непонятен. Если человек вне информационной системы компании, то к чему он тогда получает доступ?
Обходной лист это не обязательно кусок бумаги.
Про удаленные места аргумент мне непонятен. Если человек вне информационной системы компании, то к чему он тогда получает доступ?
Сотрудник работает в поле в другом городе, иногда в другом государстве, на выделенном ему предприятием оборудовании. В офисе бывает в лучшем случае на каком-то семинаре/треннинге, да может еще на корпоративе. Про увольнение по собственному желанию докладывает своему региональному начальнику/супервайзеру, ему же и сдает оборудование.
Кому он доложен привести и показать обходной лист?
Кому он доложен привести и показать обходной лист?
Наверное туда где лежит его трудовая книжка. Либо воспользоваться системой электронного документооборота.
Я не против idm. Но на мой взгляд проблемы показанные на частном примере этой статьи лишь следствие несоблюдения элементарной дисциплины в конкретной компании, а не проблема любой крупной компании. И внедрение idm ровным счетом ничего не поменяет. руководитель этого подчиненного точно также как и раньше ничего не сделает с его правами после увольнения.
Я не против idm. Но на мой взгляд проблемы показанные на частном примере этой статьи лишь следствие несоблюдения элементарной дисциплины в конкретной компании, а не проблема любой крупной компании. И внедрение idm ровным счетом ничего не поменяет. руководитель этого подчиненного точно также как и раньше ничего не сделает с его правами после увольнения.
Мне очень не нравится когда в рекламе своих, возможно полезных и хороших продуктов, применяют один заезженный дешевый прием. Показывают как было плохо до, и как стало великолепно после, и это все благодаря именно чудо средству. Причинно следственная связь в таких статьях обычно притянута за уши и реальные достоинства увы теряются.
Ситуация дo:
— Сложно управлять идентификационными данными и доступом пользователей во множестве систем.
— Большое количество ручных операций по управлению учетными записями правами доступа в системах, что приводит к увеличению числа ошибок (неполные данные, дублирующиеся записи, избыточные права, одинаковые роли имеют разные права, «сиротские» учетных записи и др.)
— Отсутствует актуальная информация по количеству действительных пользователей систем, отсутствует консолидированная информация по правам пользователей в системах (кто к чему имеет доступ и на каком основании).
Ситуация после:
— Идентификационные данные в системах актуальные, согласованные, отсутствуют «сиротские» учетные записи.
— Пользователи получают доступ к системам в течение утвержденного регламентного времени.
— Пользователи получают минимально необходимые и достаточные права доступа для работы в системах.
— Руководство получает актуальную отчетную информацию по правам пользователей в системах – какие пользователи к каким системам имеют доступ и на каком основании.
— Сложно управлять идентификационными данными и доступом пользователей во множестве систем.
— Большое количество ручных операций по управлению учетными записями правами доступа в системах, что приводит к увеличению числа ошибок (неполные данные, дублирующиеся записи, избыточные права, одинаковые роли имеют разные права, «сиротские» учетных записи и др.)
— Отсутствует актуальная информация по количеству действительных пользователей систем, отсутствует консолидированная информация по правам пользователей в системах (кто к чему имеет доступ и на каком основании).
Ситуация после:
— Идентификационные данные в системах актуальные, согласованные, отсутствуют «сиротские» учетные записи.
— Пользователи получают доступ к системам в течение утвержденного регламентного времени.
— Пользователи получают минимально необходимые и достаточные права доступа для работы в системах.
— Руководство получает актуальную отчетную информацию по правам пользователей в системах – какие пользователи к каким системам имеют доступ и на каком основании.
Вся ваша ситуация до это следствие того, что сервисы не имеют интеграции с ad, используют свои собственный каталоги пользователей.
Ситуация после вообще никакого отношения не имеет к idm и ad. Это вопрос соблюдения или не соблюдения рабочей дисциплины.
>— Пользователи получают минимально необходимые и достаточные права доступа для работы в системах.
Это вызывает особое недоумение. Да это хорошо, но к idm не имеет никакого отношения. Так должно быть всегда и везде.
Ситуация после вообще никакого отношения не имеет к idm и ad. Это вопрос соблюдения или не соблюдения рабочей дисциплины.
>— Пользователи получают минимально необходимые и достаточные права доступа для работы в системах.
Это вызывает особое недоумение. Да это хорошо, но к idm не имеет никакого отношения. Так должно быть всегда и везде.
Если человек вне информационной системы компании, то к чему он тогда получает доступ?
Зависит от бизнеса компании. Пример: подрядчик, партнер или другое лицо получает доступ к бизнес-ресурсам вашей компании
> Всего около 10 тысяч сотрудников.
Ребята, вы не пробовали проще себя вести? Скажем сценарий на автомат ставить, чтобы каждую ночь оно по АД по учеткам пробегало и атрибут lastLogon анализировало — те, что старше скажем трех месяцев — в дизейбл. А те, что в дизейбле уже больше трех лет — в корзину. Кулибины…
Ну, наверно, так у админов (кто по уму делает) делается. Вот только в моей практике был случай, когда сотрудник юр. подразделения уволился, а данные к своей учётке оставил сотрудникам в кабинете. Об увольнении я узнал уже спустя месяц, когда возникли вопросы (после проверки логов). Оказалось, что пароль уже разошёлся не только по данному кабинету. Появился и новый сотрудник, которого оставшиеся люди в отделе и усадили под эту же учётку.
И в такой ситуации лэстлогон не поможет вообще.
И в такой ситуации лэстлогон не поможет вообще.
В этой ситуации отлично помогают две вещи:
1. Привязка аккаунта к оборудованию. Зачем сотруднику (в т.ч. с «удаленки») лезть к ресурсам предприятия не со своего штатного ПК?
2. Административная ответственность. Пару выговоров или предупреждений «отличившимся» сотрудникам здорово «бодрят» коллектив.
В нашей практике были случаи когда «из уст в уста» передавали учетные данных от учеток, имеющих доступ к серьезной информации (например к ПК с КБ) либо писали их на листочке рядом с ПК. Виновные были жестоко наказаны…
А еще есть «обезличенные» учетки, когда скажем на складе операторы (у которых сильная текучка) просто работают под «Оператор1...2...3». Для тех — просто автоматом раз в месяц заставить менять пароль.
Безопасность — это параноя.
1. Привязка аккаунта к оборудованию. Зачем сотруднику (в т.ч. с «удаленки») лезть к ресурсам предприятия не со своего штатного ПК?
2. Административная ответственность. Пару выговоров или предупреждений «отличившимся» сотрудникам здорово «бодрят» коллектив.
В нашей практике были случаи когда «из уст в уста» передавали учетные данных от учеток, имеющих доступ к серьезной информации (например к ПК с КБ) либо писали их на листочке рядом с ПК. Виновные были жестоко наказаны…
А еще есть «обезличенные» учетки, когда скажем на складе операторы (у которых сильная текучка) просто работают под «Оператор1...2...3». Для тех — просто автоматом раз в месяц заставить менять пароль.
Безопасность — это параноя.
Перефразирую известно. Строгость регламента компенсируется необязательностью его исполнения. Вот так и получается, что если нет осознания необходимости обеспечения безопасности, то какую бы там ответственность не сулили, всё в конце концов разбивается о действия начальства «Ну бывает...».
С этим бороться очень и очень тяжко. Никому ничего никогда не надо, если это требует каких-то телодвижений. Ровно до того момента, как случится какой-нибудь инцидент. Вот только поздно бывает уже.
Живём не в идеальном мире с большой долей человеческого фактора. Так что от этого и пляшем.
И да. Лично я с последней фразой категорически согласен.
С этим бороться очень и очень тяжко. Никому ничего никогда не надо, если это требует каких-то телодвижений. Ровно до того момента, как случится какой-нибудь инцидент. Вот только поздно бывает уже.
Живём не в идеальном мире с большой долей человеческого фактора. Так что от этого и пляшем.
И да. Лично я с последней фразой категорически согласен.
> Всего около 10 тысяч сотрудников. Системный администратор работает грамотный
У вас на компанию в 10 тысяч сотрудников работает один системный администратор???
У вас на компанию в 10 тысяч сотрудников работает один системный администратор???
Какие есть примеры open-source'ных IdM?
Прочитал, и понял, что предложенная система — немного чёрный ящик, беззащитный перед троллингом. Гипотетически, можно выбрать управленческую схему любой сложности. Но необходимо, чтобы схема была ясна, стандартна, управляема, чтобы могли сопровождать не только вы, как специалист, но и в масштабе предприятия — ведь незаменимых людей нет. Чтобы на сопровождение не уходило много рабочего времени, иначе будет действительно ад. Нужно задокументировать это решение, потому как основание для деятельности — не порядок или беспорядок у специалиста в голове, не ваше настроение или отсутствие на работе по болезни, а договорённость о мере [бес]порядка в IT-инфраструктуре на предприятии, что надо зафиксировать на материальном носителе. Иначе управленческая схема в скором времени будет представлять из себя ржавый велосипед. Важно, чтобы схема работала и была хорошо изучена, не пугала других фингерпринтами интеллекта разработчика. Терминологию важно объяснять, давать конкретные и однозначные определения, источники, откуда взяли, особенно если это аббревиатуры, т.к. при неясности слов, без подачи их изначально, бессмысленно строить архитектурные конструкции на их основе, хотя бы они и казались весьма благозвучны. Ну и неплохо бы обосновать, почему именно такой способ выбрали. Если уже известный и устоявшийся термин, покажите, где это уже было применено. Сравнить с другими схемами и решениями, которые могли бы быть применены в данной ситуации, и по каким причинам не подходят. Конкретный вопрос: почему в центре человек, а не, скажем, чепловек+должность: ведь при не очень маленьком уровне текучки кадров надо постоянно перепиливать систему (понятно, что должности могут дублироваться, но, в основном не ключевые)? И конечно, немного риторический вопрос, жаль что про IdM есть статья в английской википедии, не в русской. Как-то так комментарий.
Решение задачи по управлению идентификационными данными и доступом – процесс, который состоит не просто из внедрения той или иной системы.
Необходимо:
— Разработать процессы по управлению идентификационными данными и доступом в системах компании.
— Разработать и согласовать организационно-распорядительную документацию по управлению идентификационными данными и доступом – регламенты работы процессов, инструкции персоналу. Сотрудники должны понимать, как работают процессы.
— Разработать и внедрить технические решения по управлению идентификационными данными и доступом – здесь возможны различные варианты реализации (готовое техническое решение – коммерческое или open source, собственная разработка)
— Ввести в действие разработанные организационные и технические решения.
Есть, конечно еще вариант ничего не делать в части внедрения тех. решения, а четко задокументировать процедуры и обеспечить штат специалистов, которые будут заводить учетные записи и предоставлять доступ. Но, как показывает практика, такой вариант хорошо работает в небольших компаниях. В больших гетерогенных инфраструктурах при таком варианте появляются ошибки, связанные с человеческим фактором (рассогласование идентификационных данных в системах, избыточные или недостаточные права доступа, появление «сиротских» учетных записей), увеличивается время простоя пользователей из-за отсутствия доступа к той или иной системе, отсутствует целостная картина (отчетность) по правам доступа пользователей в системах.
Необходимо:
— Разработать процессы по управлению идентификационными данными и доступом в системах компании.
— Разработать и согласовать организационно-распорядительную документацию по управлению идентификационными данными и доступом – регламенты работы процессов, инструкции персоналу. Сотрудники должны понимать, как работают процессы.
— Разработать и внедрить технические решения по управлению идентификационными данными и доступом – здесь возможны различные варианты реализации (готовое техническое решение – коммерческое или open source, собственная разработка)
— Ввести в действие разработанные организационные и технические решения.
Есть, конечно еще вариант ничего не делать в части внедрения тех. решения, а четко задокументировать процедуры и обеспечить штат специалистов, которые будут заводить учетные записи и предоставлять доступ. Но, как показывает практика, такой вариант хорошо работает в небольших компаниях. В больших гетерогенных инфраструктурах при таком варианте появляются ошибки, связанные с человеческим фактором (рассогласование идентификационных данных в системах, избыточные или недостаточные права доступа, появление «сиротских» учетных записей), увеличивается время простоя пользователей из-за отсутствия доступа к той или иной системе, отсутствует целостная картина (отчетность) по правам доступа пользователей в системах.
Несколько вопросов:
1. Отдел обучения
Сотрудники приходят на обучение и должны логинится под своими УЗ. Но в 1С например их еще рано создавать. А еще они должны попасть в систему тестирования, их должны проверить СБ. Нужны ли на них лицензии?
2. Где сравнение (+ и -) по сравнению другими системами?
3. Мало скриншотов (хотя бы презентацию на продукт)
1. Отдел обучения
Сотрудники приходят на обучение и должны логинится под своими УЗ. Но в 1С например их еще рано создавать. А еще они должны попасть в систему тестирования, их должны проверить СБ. Нужны ли на них лицензии?
2. Где сравнение (+ и -) по сравнению другими системами?
3. Мало скриншотов (хотя бы презентацию на продукт)
1. Да, нужны. Куда они должны попадать — неважно, важно, что они являются объектами в системе. Но есть нюансы в разных системах. У многих вендоров есть такое понятие как лицензия на внешнего пользователя. Стоимость в несколько раз ниже.
2. Учитывая, что ни одна система не упоминается, такое сравнение лучше делать по факту. Если нужны детали — расскажите мне в личку или почту свою ситуацию.
3. Мало скриншотов? Да их там выше вообще нет :)
На всякий случай: система может быть любой, например Novell или Microsoft. Выбирается обычно под задачу. Самая сложная часть — интеграция.
2. Учитывая, что ни одна система не упоминается, такое сравнение лучше делать по факту. Если нужны детали — расскажите мне в личку или почту свою ситуацию.
3. Мало скриншотов? Да их там выше вообще нет :)
На всякий случай: система может быть любой, например Novell или Microsoft. Выбирается обычно под задачу. Самая сложная часть — интеграция.
а я тут вот что подумал: как система спасёт от социально-инженерного запроса от менеджера Васи: «уважаемый директор, прошу выдать мне права на установку пакета кодеков [ + хитрого бэкдура ], так как наш клиент принёс ролик, а для его воспроизведения требуется редкий кодек»? ведь директор нифига не разбирается в таких вещах! он не начитанный сисадмин
Надо понимать, что IDM — это идеология и пласт задач централизованного управления учетными записями.
В части интеграционных и консалтинговых задач, сюда, в общем случае входя вопросы, начинающиеся:
1) от банальной синхронизации каталогов идентификационных данных;
2) построения единой точки согласования прав доступа, распространения изменений и отчетности (классическое понимание задачи, описанное в посте);
3) до построения динамической ролевой модели и управления рисками доступа.
Какие задачи, в каком объеме и на базе каких решений они будут реализованы — зависит от Заказчика. Можно даже использовать скрипты. Если выбирается вендорный продукт, то, в большинстве случаев, он будет представлять собой конструктор, который может видоизмениться в результате до неузнаваемости. Например, в качестве системы согласования будет использоваться существующая СЭД.
По сложности решаемых задач можно сказать, что полномасштабное внедрение IDM сопоставимо с внедрением ERP.
В части интеграционных и консалтинговых задач, сюда, в общем случае входя вопросы, начинающиеся:
1) от банальной синхронизации каталогов идентификационных данных;
2) построения единой точки согласования прав доступа, распространения изменений и отчетности (классическое понимание задачи, описанное в посте);
3) до построения динамической ролевой модели и управления рисками доступа.
Какие задачи, в каком объеме и на базе каких решений они будут реализованы — зависит от Заказчика. Можно даже использовать скрипты. Если выбирается вендорный продукт, то, в большинстве случаев, он будет представлять собой конструктор, который может видоизмениться в результате до неузнаваемости. Например, в качестве системы согласования будет использоваться существующая СЭД.
По сложности решаемых задач можно сказать, что полномасштабное внедрение IDM сопоставимо с внедрением ERP.
IdM штука бесспорно полезная, даже в моновендорной среде (а сейчас с AD умеет работать практически всё). Как минимум аудит — уже весьма полезно. Только мне видится в этом одна проблема. Чтобы такая система была реально полезной, административных изменений нужно больше чем технических, нужно понимание того как это должно работать. Потом долго и крапотливо все это в интегрированном виде имплементировать в некой системе. При этом в процессе наверняка будут возникать всякие нестыковки, дополнительные хотелки и т.п. Не превратиться ли в конечном счете все это в такой же бардак, только на другом уровне. Тьма разных комбинаций правил, огромное количество различных параметров, каждый из которых надо сконфигурировать, а потом выбрать для тех или иных сотрудников. Нужно еще и от отвественных лиц понимание работы этой системы. Нет, понятно что бардака будет меньше, но он все равно будет.
Пароль сотрудник сбрасывает себе сам
Это, прошу прощения… как? Сотрудника не надо прежде авторизовать?
Да, вполне возможно. Благодарю, коллеги.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ад с учётными записями — почему в одной компании пользователей было в 3 раза больше, чем сотрудников