Ад с учётными записями — почему в одной компании пользователей было в 3 раза больше, чем сотрудников

    Прыдстория. В одной производственной компании было около двух десятков(!) кадровых баз. Это базы обособленных подразделений, и в каждой по несколько сотен человек. Всего около 10 тысяч сотрудников. Системный администратор работает грамотный, есть рабочая MS Active Directory.

    Квест начался в тот момент, когда безопасники попросили проверить некоего Петрова. По их ощущениям, прав у него было куда больше, чем ему дали по заявкам от подразделений. Админу пришлось поднимать все эти бумажные документы из архива и обходить половину подразделений компании. Ради одного сотрудника. Пока он ходил около двух недель, проверить решили целый отдел.

    Параллельно админ понял ещё одну страшную вещь: в компании по факту работает примерно в три раза меньше людей, чем учёток у него в системе. Почему? Да всё просто: учётки заводились по письменным заявкам, а при увольнениях и переводах обновлять статус зачастую забывали.

    В этот момент мы начали работать над внедрением общего решения по управлению учетными записями и правами доступа, IdM. Для начала пришлось избавиться от раздробленности и свести все кадровые базы в одну промежуточную кадровую систему. Её связали с Active Directory через новый центр-репозиторий. Потом подключили к репозиторию остальные бизнес-системы вот так:



    Дальше мы удалили все лишние учётки, оставили только действительных сотрудников (заодно увидели пару уволенных, но активно логинящихся). Потом нашли пару очень странных людей...

    Например, были учётки А. М. Иванова и А. М. Ивaнова (визуально – один сотрудник, но у второго буква a в фамилии английская: либо ошибка, либо кто-то специально его «клонировал»).

    Затем автоматизировали процесс назначения прав по документам кадровиков. Сделали портал самообслуживания, где сотрудники могли запросить доступ, куда было нужно. И уже не админ, а руководитель соответствующего подразделения его подтверждал. На аудит и понимание процессов ушло месяца два, ещё два на допиливание софта и тесты, последний — на внедрение и обучение IT-специалистов.

    Вот примерно так. История эта в целом реальная, но некоторые детали я специально изменил, чтобы не раскрывать заказчика. Самое интересное в ней то, что мало кто, оказывается, вообще понимал, как работают IdM-системы. Поэтому я и пишу этот топик.

    Общее об IdM


    Обычно в крупной компании в какой-то момент начинается настоящий ад с учётными записями пользователей. У одного сотрудника появляется минимум 3-4 разных учётных записи. Управлять ими из единого центра не получается. При переводе из отдела в отдел нужно делать кучу вещей руками. Плюс появляются требования законодательства по защите персональных данных, политике безопасности по каждой учётке и так далее.

    С этим можно жить, увеличивая количество ручных операций, а можно настраивать IdM — систему управления идентификационными данными и правами доступа.

    Как это выглядит? Довольно красиво: например, при всё том же переводе сотрудника из одного подразделения в другое, вы обновляете его данные в одном репозитории. Дальше, например, в 1С меняются права, в корпоративном телефонном справочнике меняется должность, в бизнес-приложении обновляется учётка, в системе документооборота появляются новые связи по бизнес-процессам. И так далее.

    Итак, если ваша компания достаточно большая, то есть три варианта развития ситуации:
    С учётками наблюдается некоторый хаос. Например, когда приходит на работу сотрудник, ему необходимо предоставить доступ во множество информационных систем. Первые пару дней он может вообще не использовать корпоративные ресурсы, либо сидеть с учётки предшественника, что не очень хорошо. Во-вторых, если всё делается вручную — будут ошибки, типа избыточных прав в ряде систем. В-третьих, если нет точного процесса, многое будет завязано на конкретных людей, при повышении или уходе которых придётся заново восстанавливать систему управления доступами. Когда такие звоночки появляются, это, собственно говоря, является поводом, чтобы задуматься над внедрением IdM.
    У вас полный порядок, но много действий делается руками. IdM поможет это автоматизировать. Чем больше вендоров корпоративных систем, тем больше «стыков» можно будет построить через IdM.
    У вас системы одного вендора (когда IdM просто не нужна, всё и так делается через одну учётку), либо есть IdM в том или ином виде. Я видел, например, что в одновендорных системах действует согласование заявок (да хоть по почте, если бизнес-процессы отлажены), и всё работает. Так что здесь всё просто.


    Каждому сотруднику компании соответствует пользователь IdM-системы, создаваемый на основании кадровых данных, получаемых из доверенной системы (например, HR-системы). Учетные записи в целевых информационных системах создаются только с помощью IdM-системы и привязываются к конкретному сотруднику. Таким образом, любой учетной записи в информационной системе всегда соответствует её владелец — сотрудник компании

    Надо сказать, что внедрение IdM в сложной мультивендорной среде с множеством разных систем и ещё географически разделёнными подразделениями — задача нетривиальная. И сложная для руководства. Обычно действует принцип — «не трогай, пока работает», поэтому надо думать о таких вещах либо заранее, когда ещё легко внедрить систему, либо искать доводы. И вот здесь вашими лучшими друзьями становятся безопасники. Потому что они-то уж точно знают, чего может стоить всего одна учётка. И более того, наверняка у них есть примеры весьма неприятных ситуаций для компании, повторения которых они бы о-очень не хотели. И вы можете им помочь.

    Как система выдаёт права?


    Есть два способа: на основе правил, настраиваемых в системе (например, всем сотрудникам безопасности — доступны такие-то ресурсы, всем руководителям подразделений — такие-то и так далее). И по заявкам. Например, кто-то из закупки хочет больше данных о товаре и ему нужно получить доступ в 1С. Он отправляет заявку, система отслеживает иерархию, отправляет её, например, финдиректору. Если он подтверждает заявку, человек получает доступ.

    Как идёт внедрение


    Первый этап — это обязательное проведение обследования. По результатам этого аудита мы определяем сложившиеся бизнес-процессы, связанные с управлением учётными данными и доступом. И второе, мы рисуем целевую картину, в которой систему должны реализовать, и предлагаем техническое решение, с помощью которого эту идею, в общем-то, можно, опять же, реализовать.

    В этап обследования обязательно включается аудит — проверка технической инфраструктуры. Речь идёт о том, что одна система может хранить идентификационные данные, например, в базе данных, другая система – в плоском файле. Ещё мы обследуем интерфейсы, по которым эти системы могут общаться в будущем с IdM (интерфейс и протоколы) для того, чтобы понять возможность вообще и трудоёмкость интеграции.

    Тут, главное, без излишнего фанатизма. Знаете, как бывает — «потратил 5 часов на написание алгоритма, который решает за 5 секунд задачу, которую я считал бы вручную 3 часа». Так вот, есть системы, которые не надо полностью интегрировать. Например, в компании тысяча сотрудников и в одной из систем работает только 50 человек. И это один отдел, и текучка этого отдела очень небольшая. Возможно, есть экономическая необходимость не интегрировать эту систему с IBT-менеджером, а скрестить её с IdM в ручном режиме. То есть, администратору этой системы будет при необходимости отправляться письмо с просьбой выдать права доступа тому или иному сотруднику. Такие варианты тоже возможны. У нас, в частности, был пример в компании на 10 тысяч человек, когда кадровая система, в которой работает 5 человек, имела технические ограничения, и мы предложили заказчику рассмотреть именно такой вариант. В итоге так и сделали.

    Для интеграции разрабатываются коннекторы — небольшие программные модули, которые позволяют забирать данные из систем и, наоборот, эти данные в системы предоставлять. Обычно делается или доработка штатных коннекторов или разработка с нуля (чаще всего для отечественных систем: у американцев обычно всё сразу из коробки заточено под нужды крупного бизнеса).

    Чтобы пользователи работали по привычным схемам, большая часть событий может дублироваться в почту. Как подтверждал раньше финдиректор доступ письмом, так и может продолжать — только теперь письмо ему пишет робот из IdM и просит просто кликнуть по ссылке «да» или «нет».

    Счастье безопасников


    Когда всё готово, получается схема, где у каждого человека в компании прописаны права. И это — настоящее счастье для всего отдела безопасности и финансового директора. Появляется комплексная отчётность и целостное видение. Например, до внедрения системы понимание того, у кого какие права есть, — это был целый квест с обходом всех подразделений. После внедрения — пара кликов. Два любимых вопроса на этой стадии: «насколько выданные права соответствуют правам, запрошенным в заявках», «насколько они соответствуют служебной необходимости и корпоративным политикам безопасности». Ответы исчерпывающи и часто неожиданны для тех, кто только оценил уровень ошибок до внедрения системы.

    Параллельно появляется вторая часть математической задачи — расчёт оптимальных прав. Да-да, мы делаем некоторый Data Mining (хотя, громковато сказано для большей части случаев). И показываем, как можно оптимально разделять права. Выявляются какие-то вещи, которые не должны быть в нормальной структуре, которые могут привести к повышению рисков, связанных именно с доступом.

    Ещё одна особенность: каждое изменение прав имеет основание. Например, когда раньше админ руками проставлял новому сотруднику права — это всегда было на его страх и риск. Сейчас система отрабатывает по основаниям: приказу о приёме человека, подтверждению запроса от руководителя и так далее. Просто взять и поменять данные в корпоративном справочнике не получится: данные от кадровиков считаются более доверенными.

    Очень радует удобство обновления прав. Системы IdM умеют следить за ситуациями, когда права выданы, но человеку уже не нужны. Например, по должности сотрудник не выполняет работу, требующую доступа к финансовым отчётам компании, а такой доступ у него имеется. Система может обнаружить эту закономерность и выдать рекомендацию эти права убрать.

    Счастье пользователей


    Потом счастливыми становятся пользователи. У них — система одного входа, когда достаточно один раз залогиниться на рабочем месте и автоматически получать доступы в рамках своих полномочий. Никаких бумажек с паролями с кучей приложений и сервисов — помнить надо только свой, на вход (обратите внимание, это более широкая задача SSO, не всегда системы IdM решают её).

    Счастье IT-отдела


    После внедрения, когда вся компания косо смотрела на «выдумщиков» из IT-отдела, меняющих привычный уклад вещей, можно расслабиться и начать получать удовольствие. Изменения из одного места, удобная картина прав, заскриптованные действия, типа создания ящика новому сотруднику по факту обновления документов у кадровиков и так далее, — это кайф. Пароль сотрудник сбрасывает себе сам, учётку разблокирует его руководитель, а у IT-отдела есть лог действий, если понадобится найти причину проблемы. Правда, придётся некоторое время попотеть с кропотливой настройкой (будет период довольно продолжительного «допиливания»), но это того стоит.

    Да, вы правильно поняли, что IdM очень бережёт нервы. Дело в том, что заявки на доступ отправляются уже не системному администратору, а тому, кто должен такой доступ подтверждать. Руководителю подразделения, финансовому директору, безопасникам — в общем, тем, кто прямо отвечает за вопрос. И это значит, что если раньше, когда что-то было не так, был виноват админ, то сейчас чётко понятно, кто, что и кому дал. А админ только обеспечил протокол.

    Бухгалтерия тоже счастлива


    Для них есть специальные слова, которые как музыка ласкают слух всего отдела. Это уменьшение суммарной стоимости внедрения, снижение стоимости владения, уменьшение требуемых технических ресурсов, прозрачность архитектуры, снижение затрат на обслуживание и эксплуатацию решения, поэтапность внедрения решения без влияния на непрерывность процессов компании. Уф. В общем, это как рефакторинг и оптимизация сразу.

    Идеология


    В США и Европе такие системы уже давно, и к ним многие привыкли. Было бы странно, если бы в нашей стране не было особенностей менталитета, связанных с правами доступа. Главная проблема — доверенность источников. Например, кадровики много где просто обожают заносить все данные задним числом в систему, уже при увольнении. Это профессиональный сдвиг, ведь рабочая книжка заполняется по факту именно в этот момент.

    Часто бывают ситуации, когда нужно делать особые привилегии руководству. То есть, вводится какое-то правило, но по факту топы ему не следуют. Когда правило автоматизируется, боссов может ждать сюрприз — например, автоматическая выгрузка сотовых телефонов в общий справочник контактов компании. Понятно, что после пары звонков от клиентов сразу директору, мы такое правило на практике доработали.

    Деньги


    Лицензии дорогие. Условий множество, но обычно получается от десятков до нескольких сотен долларов на сотрудника. Впрямую, за счёт сэкономленного времени, системы окупаются за 3-4 года, но обычно оценка идёт всё-таки по выгодам безопасников и прозрачной отчётности. Ещё особенность — когда компания проходит аудит, например, перед продажей (слиянием) или сертификацией, такие системы воспринимаются очень позитивно.

    Эволюция


    Изначально, как таковых репозиториев управления доступами не было. Стояла задача понять, «кто и куда имеет право заходить». Ко всем точкам логина подключались модули, которые просто фиксировали, кто входит. Медленно выстраивалась карта доступов, которая шла в отчёт. С другой стороны, параллельно развивались центры выдачи единых прав, которые такую карту формировали. В итоге сейчас появились симбиозные решения: сначала они действуют в режиме read-only и собирают актуальные данные по правам, потом переносят модуль за модулем в активный менеджмент, а потом позволяют сделать глобальную автоматизацию. И это всё спокойно, плавно и без рывков для пользователей.

    P.S. Если у вас есть вопросы по конкретной конфигурации для вашего случая или вы не можете задать вопрос в комментариях, пишите прямо мне на AZaikin@croc.ru.
    КРОК
    558,30
    IT-компания
    Поделиться публикацией

    Комментарии 47

      +2
      Вопрос без подвоха — в чем возможностей Active Directory не хватает для решения таких задач?
        +2
        Хватает. Она даже может являться «интерфейсом» всей системы. Только она не со всем стыкуется. Вот тут и надо либо велосипед изобретать, либо готовую систему купить.
          0
          Не может. Потому как встаёт задача синхронизации базы пользователей.
          Учетка в AD должна заводиться синхронно с остальными производственными документами. ИМХО, ЗУП для этого — самое место.
            0
            О чем и говорю. AD — интерфейс, а данные из неё расползаются по всем остальным системам.
              0
              Он хочет, чтобы кадровичка заполняла, не давать же ей доступ к АД?
                +1
                Давать. Заводить группу пользователей для отдела кадров и давать кадровикам право создания учёток (где будут храниться все данные пользователя). Права выдавать на основании role-based модели, когда должность (исполняемые сотрудником роли в компании) определяют его права доступа. А потом безопасники должны подтверждать учётки перед их использованием.
                Именно такая модель предлагается MS.
          +2
          А я так и не понял в статье речь про какую-то конкретную реализацию idm(название которой просто опускают), самописную систему под конкретного клиента или это чисто теоретические рассуждения о том, что какая-то система над AD нужна?
            0
            Это обобщенный опыт реализации проектов по внедрению решений класса IdM.
              0
              Вот бы еще перечень систем, подходящих под расписанные чудеса…
        0
        И всё же остаются некоторые непонятки.

        Взять, к примеру, 1С восьмерку, конкретнее — зарплату и управление персоналом. Никакая смена должности сотрудника не пройдет мимо отдела кадров — а туда же и штатное расписание, и положение в иерархии компании, и всё остальное.

        Факт создания или обновления пользователя в 1С — вполне себе повод для создания или обновления учетной записи в OU, соответствующем подразделению компании. Смена должности внутри подразделения — смена Security Group, смена подразделения — смена OU. Увольняем сотрудника -> блокируем запись, выкидываем в треш-OU.

        Да, нужны скрипты, но в IdM ведь тоже они нужны (насколько я понял, это и есть «адаптеры»).

        А с управлением учетками на уровне администрации отделов — по сути, делегирование лишних полномочий для начальников отделов. Если шаблонной учетке начинает не хватать каких-то прав — то это явно не проблема администрации. Да и как показывает практика, даже при наличии таких полномочий начальство конкретных отделов во избежание лишних вопросов начинает раздавать чуть ли не максимальные права при первом появлении ошибки «Access Denied». Мол, людям работать нужно, а вы потом разбирайтесь.

        В общем, я так и не проникся целесообразностью внедрения подобного решения. На бумажке-то оно красиво всё, а в жизни «совокупная стоимость владения» звучит не так убедительно, как цифра в несколько сотен долларов, умноженная на количество сотрудников.
          0
          Обходной лист при любом кадровом изменении решает большую часть проблем.
            +1
            Не решает в случае распределенных и удаленных рабочих мест. Есть целые службы, которые должны работать удаленно в «поле» и подписать обходной лист просто не в состоянии.
            Все что касается безопасности — должно быть максимально автоматизировано и не зависеть от человеческого фактора. Иначе порядка не будет или придется постоянно заниматься перманентной «инвентаризацией» всего и вся, что с точки зрения затрат — не есть хорошо.
              0
              В случае c idm человеческий фактор никуда не уходит. В приведенной статье изначально был бардак, потом волевым усилием навели порядок.
              Обходной лист это не обязательно кусок бумаги.
              Про удаленные места аргумент мне непонятен. Если человек вне информационной системы компании, то к чему он тогда получает доступ?
                0
                Сотрудник работает в поле в другом городе, иногда в другом государстве, на выделенном ему предприятием оборудовании. В офисе бывает в лучшем случае на каком-то семинаре/треннинге, да может еще на корпоративе. Про увольнение по собственному желанию докладывает своему региональному начальнику/супервайзеру, ему же и сдает оборудование.
                Кому он доложен привести и показать обходной лист?
                  0
                  Наверное туда где лежит его трудовая книжка. Либо воспользоваться системой электронного документооборота.
                  Я не против idm. Но на мой взгляд проблемы показанные на частном примере этой статьи лишь следствие несоблюдения элементарной дисциплины в конкретной компании, а не проблема любой крупной компании. И внедрение idm ровным счетом ничего не поменяет. руководитель этого подчиненного точно также как и раньше ничего не сделает с его правами после увольнения.
                    0
                    Мне очень не нравится когда в рекламе своих, возможно полезных и хороших продуктов, применяют один заезженный дешевый прием. Показывают как было плохо до, и как стало великолепно после, и это все благодаря именно чудо средству. Причинно следственная связь в таких статьях обычно притянута за уши и реальные достоинства увы теряются.
                      0
                      Ситуация дo:
                      — Сложно управлять идентификационными данными и доступом пользователей во множестве систем.
                      — Большое количество ручных операций по управлению учетными записями правами доступа в системах, что приводит к увеличению числа ошибок (неполные данные, дублирующиеся записи, избыточные права, одинаковые роли имеют разные права, «сиротские» учетных записи и др.)
                      — Отсутствует актуальная информация по количеству действительных пользователей систем, отсутствует консолидированная информация по правам пользователей в системах (кто к чему имеет доступ и на каком основании).

                      Ситуация после:
                      — Идентификационные данные в системах актуальные, согласованные, отсутствуют «сиротские» учетные записи.
                      — Пользователи получают доступ к системам в течение утвержденного регламентного времени.
                      — Пользователи получают минимально необходимые и достаточные права доступа для работы в системах.
                      — Руководство получает актуальную отчетную информацию по правам пользователей в системах – какие пользователи к каким системам имеют доступ и на каком основании.
                        –1
                        Вся ваша ситуация до это следствие того, что сервисы не имеют интеграции с ad, используют свои собственный каталоги пользователей.
                        Ситуация после вообще никакого отношения не имеет к idm и ad. Это вопрос соблюдения или не соблюдения рабочей дисциплины.

                        >— Пользователи получают минимально необходимые и достаточные права доступа для работы в системах.
                        Это вызывает особое недоумение. Да это хорошо, но к idm не имеет никакого отношения. Так должно быть всегда и везде.
                          0
                          Обычный рост предприятия — покупка мелких компаний.
                          Похерить все накопленные данные? Заменить все «железные» системы? Тут idm очень к месту будет.
                  0
                  Если человек вне информационной системы компании, то к чему он тогда получает доступ?

                  Зависит от бизнеса компании. Пример: подрядчик, партнер или другое лицо получает доступ к бизнес-ресурсам вашей компании
                +1
                > Всего около 10 тысяч сотрудников.
                  0
                  Тем более. Для проформы конечно обходной должен существовать, но надеяться на него нельзя. Никак.
                  У нас поменее, чуть более полутысячи рабмест, пользователей чуть больше конечно. И хотя все по ITIL-у да по ISO — все равно бардак и без автоматики — никак.
                    0
                    Немного другое имел в виду.
                    Бумажный обходной лист — это для масштабов менее сотни сотрудников. 10 тысяч — это однозначная и безусловная автоматизация.
                    Причём в таких масштабах обычно уже используются какие-то типовые схемы бизнес-процессов.
                –6
                Ребята, вы не пробовали проще себя вести? Скажем сценарий на автомат ставить, чтобы каждую ночь оно по АД по учеткам пробегало и атрибут lastLogon анализировало — те, что старше скажем трех месяцев — в дизейбл. А те, что в дизейбле уже больше трех лет — в корзину. Кулибины…
                  +2
                  Ну, наверно, так у админов (кто по уму делает) делается. Вот только в моей практике был случай, когда сотрудник юр. подразделения уволился, а данные к своей учётке оставил сотрудникам в кабинете. Об увольнении я узнал уже спустя месяц, когда возникли вопросы (после проверки логов). Оказалось, что пароль уже разошёлся не только по данному кабинету. Появился и новый сотрудник, которого оставшиеся люди в отделе и усадили под эту же учётку.
                  И в такой ситуации лэстлогон не поможет вообще.
                    –1
                    В этой ситуации отлично помогают две вещи:
                    1. Привязка аккаунта к оборудованию. Зачем сотруднику (в т.ч. с «удаленки») лезть к ресурсам предприятия не со своего штатного ПК?
                    2. Административная ответственность. Пару выговоров или предупреждений «отличившимся» сотрудникам здорово «бодрят» коллектив.

                    В нашей практике были случаи когда «из уст в уста» передавали учетные данных от учеток, имеющих доступ к серьезной информации (например к ПК с КБ) либо писали их на листочке рядом с ПК. Виновные были жестоко наказаны…

                    А еще есть «обезличенные» учетки, когда скажем на складе операторы (у которых сильная текучка) просто работают под «Оператор1...2...3». Для тех — просто автоматом раз в месяц заставить менять пароль.

                    Безопасность — это параноя.
                      0
                      Перефразирую известно. Строгость регламента компенсируется необязательностью его исполнения. Вот так и получается, что если нет осознания необходимости обеспечения безопасности, то какую бы там ответственность не сулили, всё в конце концов разбивается о действия начальства «Ну бывает...».

                      С этим бороться очень и очень тяжко. Никому ничего никогда не надо, если это требует каких-то телодвижений. Ровно до того момента, как случится какой-нибудь инцидент. Вот только поздно бывает уже.

                      Живём не в идеальном мире с большой долей человеческого фактора. Так что от этого и пляшем.

                      И да. Лично я с последней фразой категорически согласен.
                  0
                  > Всего около 10 тысяч сотрудников. Системный администратор работает грамотный
                  У вас на компанию в 10 тысяч сотрудников работает один системный администратор???
                    +1
                    Наверно конкретно за АД отвечает как раз один.
                      +2
                      Хорошо звучит
                    0
                    Какие есть примеры open-source'ных IdM?
                      0
                      Например, OpenIDM.
                      0
                      Прочитал, и понял, что предложенная система — немного чёрный ящик, беззащитный перед троллингом. Гипотетически, можно выбрать управленческую схему любой сложности. Но необходимо, чтобы схема была ясна, стандартна, управляема, чтобы могли сопровождать не только вы, как специалист, но и в масштабе предприятия — ведь незаменимых людей нет. Чтобы на сопровождение не уходило много рабочего времени, иначе будет действительно ад. Нужно задокументировать это решение, потому как основание для деятельности — не порядок или беспорядок у специалиста в голове, не ваше настроение или отсутствие на работе по болезни, а договорённость о мере [бес]порядка в IT-инфраструктуре на предприятии, что надо зафиксировать на материальном носителе. Иначе управленческая схема в скором времени будет представлять из себя ржавый велосипед. Важно, чтобы схема работала и была хорошо изучена, не пугала других фингерпринтами интеллекта разработчика. Терминологию важно объяснять, давать конкретные и однозначные определения, источники, откуда взяли, особенно если это аббревиатуры, т.к. при неясности слов, без подачи их изначально, бессмысленно строить архитектурные конструкции на их основе, хотя бы они и казались весьма благозвучны. Ну и неплохо бы обосновать, почему именно такой способ выбрали. Если уже известный и устоявшийся термин, покажите, где это уже было применено. Сравнить с другими схемами и решениями, которые могли бы быть применены в данной ситуации, и по каким причинам не подходят. Конкретный вопрос: почему в центре человек, а не, скажем, чепловек+должность: ведь при не очень маленьком уровне текучки кадров надо постоянно перепиливать систему (понятно, что должности могут дублироваться, но, в основном не ключевые)? И конечно, немного риторический вопрос, жаль что про IdM есть статья в английской википедии, не в русской. Как-то так комментарий.
                        0
                        Решение задачи по управлению идентификационными данными и доступом – процесс, который состоит не просто из внедрения той или иной системы.
                        Необходимо:
                        — Разработать процессы по управлению идентификационными данными и доступом в системах компании.
                        — Разработать и согласовать организационно-распорядительную документацию по управлению идентификационными данными и доступом – регламенты работы процессов, инструкции персоналу. Сотрудники должны понимать, как работают процессы.
                        — Разработать и внедрить технические решения по управлению идентификационными данными и доступом – здесь возможны различные варианты реализации (готовое техническое решение – коммерческое или open source, собственная разработка)
                        — Ввести в действие разработанные организационные и технические решения.

                        Есть, конечно еще вариант ничего не делать в части внедрения тех. решения, а четко задокументировать процедуры и обеспечить штат специалистов, которые будут заводить учетные записи и предоставлять доступ. Но, как показывает практика, такой вариант хорошо работает в небольших компаниях. В больших гетерогенных инфраструктурах при таком варианте появляются ошибки, связанные с человеческим фактором (рассогласование идентификационных данных в системах, избыточные или недостаточные права доступа, появление «сиротских» учетных записей), увеличивается время простоя пользователей из-за отсутствия доступа к той или иной системе, отсутствует целостная картина (отчетность) по правам доступа пользователей в системах.
                        0
                        Несколько вопросов:
                        1. Отдел обучения
                        Сотрудники приходят на обучение и должны логинится под своими УЗ. Но в 1С например их еще рано создавать. А еще они должны попасть в систему тестирования, их должны проверить СБ. Нужны ли на них лицензии?
                        2. Где сравнение (+ и -) по сравнению другими системами?
                        3. Мало скриншотов (хотя бы презентацию на продукт)

                          0
                          1. Да, нужны. Куда они должны попадать — неважно, важно, что они являются объектами в системе. Но есть нюансы в разных системах. У многих вендоров есть такое понятие как лицензия на внешнего пользователя. Стоимость в несколько раз ниже.
                          2. Учитывая, что ни одна система не упоминается, такое сравнение лучше делать по факту. Если нужны детали — расскажите мне в личку или почту свою ситуацию.
                          3. Мало скриншотов? Да их там выше вообще нет :)

                          На всякий случай: система может быть любой, например Novell или Microsoft. Выбирается обычно под задачу. Самая сложная часть — интеграция.
                          –1
                          а я тут вот что подумал: как система спасёт от социально-инженерного запроса от менеджера Васи: «уважаемый директор, прошу выдать мне права на установку пакета кодеков [ + хитрого бэкдура ], так как наш клиент принёс ролик, а для его воспроизведения требуется редкий кодек»? ведь директор нифига не разбирается в таких вещах! он не начитанный сисадмин
                            +1
                            Директор делает запрос в IT-Дирекцию, те передают запрос администраторам офиса, те разбираются, какой кодек нужен и зачем.
                            Нормальная иерархическая организация рабочего процесса.
                            +5
                            Надо понимать, что IDM — это идеология и пласт задач централизованного управления учетными записями.

                            В части интеграционных и консалтинговых задач, сюда, в общем случае входя вопросы, начинающиеся:
                            1) от банальной синхронизации каталогов идентификационных данных;
                            2) построения единой точки согласования прав доступа, распространения изменений и отчетности (классическое понимание задачи, описанное в посте);
                            3) до построения динамической ролевой модели и управления рисками доступа.

                            Какие задачи, в каком объеме и на базе каких решений они будут реализованы — зависит от Заказчика. Можно даже использовать скрипты. Если выбирается вендорный продукт, то, в большинстве случаев, он будет представлять собой конструктор, который может видоизмениться в результате до неузнаваемости. Например, в качестве системы согласования будет использоваться существующая СЭД.

                            По сложности решаемых задач можно сказать, что полномасштабное внедрение IDM сопоставимо с внедрением ERP.
                              +1
                              IdM штука бесспорно полезная, даже в моновендорной среде (а сейчас с AD умеет работать практически всё). Как минимум аудит — уже весьма полезно. Только мне видится в этом одна проблема. Чтобы такая система была реально полезной, административных изменений нужно больше чем технических, нужно понимание того как это должно работать. Потом долго и крапотливо все это в интегрированном виде имплементировать в некой системе. При этом в процессе наверняка будут возникать всякие нестыковки, дополнительные хотелки и т.п. Не превратиться ли в конечном счете все это в такой же бардак, только на другом уровне. Тьма разных комбинаций правил, огромное количество различных параметров, каждый из которых надо сконфигурировать, а потом выбрать для тех или иных сотрудников. Нужно еще и от отвественных лиц понимание работы этой системы. Нет, понятно что бардака будет меньше, но он все равно будет.
                                0
                                Вы все правильно понимаете и описали стандартный набор организационных/технических проблем, с которыми приходится сталкиваться в проектах внедрения процессов IDM
                                  0
                                  Конечно превратится.
                                  Но уровень будет существенно более обозримый.
                                  0
                                  Пароль сотрудник сбрасывает себе сам

                                  Это, прошу прощения… как? Сотрудника не надо прежде авторизовать?
                                    0
                                    Рискну предположить, что via SMS: ведь в базе все мобилки прописаны.
                                      0
                                      Вариант: авторизовать прежним паролем и пойти задать новый.
                                      Если сбрасывает админ — то опять же, авторизовать прежним паролем и затребовать, чтобы пользователь после входа задал себе новый.

                                      Или Вы не о том?
                                      0
                                      Да, вполне возможно. Благодарю, коллеги.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое