3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Что такое IAM и как его выбрать

Что такое IAM и как его выбрать?

Технологии Identity & Access Management (IAM) предоставляют всем приложениям компании единый сервис управления идентификацией, что существенно упрощает жизнь пользователей и повышает безопасность систем. Чтобы избежать распространенных ошибок (например, внедрения перегруженных технологий и, как следствие, существенной траты ресурсов), начинать построение системы управления доступом в компании следует именно с внедрения сервисов IAM.

Михаил Ванин, генеральный директор “РЕАК СОФТ”

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

В цифровом мире информационные системы и приложения подобны арендаторам офисов в бизнес-центрах. Приложениям нужна своя пропускная система, и в этой системе для пользователя должна быть заведена учетная запись и назначены полномочия. Каждый пользователь должен проходить идентификацию и аутентификацию, подобно прохождению через охрану в бизнес-центре. Вот только вместо паспорта для входа ему понадобятся логин и пароль, а вместо пропуска будет создана сессия и выдан маркер безопасности, так называемый Security Token. Тогда приложению останется проверить, что предъявленный пользователем маркер безопасности не просрочен, не отозван, а указанные в нем права соответствуют запрашиваемому доступу.

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

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

С ростом числа используемых приложений и развитием парольного хаоса компании приходят к осознанию потребности в централизованном управлении доступом. Что же должна представлять такая система?

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

Прыдстория. В одной производственной компании было около двух десятков(!) кадровых баз. Это базы обособленных подразделений, и в каждой по несколько сотен человек. Всего около 10 тысяч сотрудников. Системный администратор работает грамотный, есть рабочая MS 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 и собирают актуальные данные по правам, потом переносят модуль за модулем в активный менеджмент, а потом позволяют сделать глобальную автоматизацию. И это всё спокойно, плавно и без рывков для пользователей.

Контроль привилегированных пользователей, или Privileged Account Management (PAM) – это группа решений, предназначенных для осуществления мониторинга и контроля учетных записей сотрудников IT-подразделений, системных администраторов, сотрудников аутсорсинговых организаций, занимающихся администрированием инфраструктуры компании, управления аутентификацией и авторизацией указанных сотрудников, аудита выполняемых действий, контроля доступа и записи их сессий. Помимо аббревиатуры PAM для обозначения систем контроля привилегированных пользователей, встречаются другие наименования данного класса решений, например, Privileged User Management (PUM), Privileged Identity Management (PIM), Privileged Access Management (PAM), Privileged Password Management (PPM), Privileged Account Security (PAS).

Решения, позволяющие контролировать действия учетных записей сотрудников, имеющих расширенные права, относятся к группе систем управления учетными данными (IdM/IAM-системы). Требования по мониторингу действий, выполняемых от имени учетных записей с повышенными привилегиями, возникли в связи с потребностью многих организаций передавать некоторые задачи администрирования и обслуживания инфраструктуры в руки сторонних организаций. Передача критичных ресурсов на IT-аутсорсинг подразумевает под собой серьезные риски. PAM-системы подразумевают под собой наличие следующих функций:

  • Централизованное управление учетными записями с расширенными возможностями;
  • Аудит действий привилегированных сотрудников;
  • Управление настройками парольной защиты;
  • Контроль доступа сотрудников к административным ресурсам;
  • Управление процессом аутентификации и авторизации;
  • Запись сессии, запущенной из-под учетной записи из списка привилегированных.

В зависимости от выполняемых функций, системы контроля пользователей с расширенными возможностями делятся на четыре категории:

  • решения, позволяющие управлять паролями сотрудников и осуществлять контроль доступа к общим учетным записям (SAPM);
  • решения, позволяющие управлять сессиями привилегированных пользователей к системам организации используя единую точку входа или Single Sign-On (PSM). При этом они позволяют осуществлять мониторинг, записывать и хранить информацию о действиях пользователей в рамках привилегированной сессии;
  • решения, позволяющие анализировать команды, которые использует администратор системы, а также выполнять их фильтрацию (SPM);
  • решения, позволяющие производить контроль встроенных или служебных учетных записей, которые используются различными приложениями и сервисами для выполнения собственных функций (AAPM).

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

По своей архитектуре PAM-системы могут быть выполнены как в виде программных, так и программно-аппаратных решений. Более того, по организации PAM-системы могут быть:

  • Локальные, требующие высоких капитальных затрат и операционных расходов.
  • Облачные, которые позволяют сокращать затраты за счет отсутствия необходимости организации и поддержки инфраструктуры.
  • Гибридные.

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

  • охват всех существующих каналов администрирования систем;
  • оперативное распознавание несанкционированных действий сотрудников;
  • однозначная идентификация пользователей, совершающих несанкционированные действия;
  • накопление доказательной базы поведения привилегированных пользователей.

Такой разный IAM

В IAM выделяют два различных технологических подхода:

  • технология корпоративного единого входа (Enterprise SSO, ESSO);
  • технология поставщика идентификации (Web SSO, Identity Provider, IDP).

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

После этого пользователь может запустить нужное ему приложение. В свою очередь, приложение ничего не знает об использовании ESSO и во время запуска попробует показать пользователю экран запроса логина и пароля. Но агент ESSO перехватывает экран входа и сам подставляет за пользователя его логин и пароль.

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

Есть еще один важный момент в использовании ESSO – ограниченность устройств, на которых возможна установка агента. Могут возникнуть проблемы с поддержкой Linux и macOS, iOS и Android.

Второй технологический подход – внедрение IDP. Этот подход лишен недостатков ESSO. Пользователь может использовать любые устройства, а для работы достаточно веб-браузера. В качестве устройств могут применяться не только ПК и смартфоны, но и голосовые станции, игровые приставки и Smart TV.

Читать еще:  Как настроить и использовать Родительский контроль в Windows 10

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

При использовании IDP пользователь обращается в приложение, а оно вместо отображения своего экрана входа отправляет серверу запрос на идентификацию. Если IDP уже знает пользователя, то происходит проверка разрешения на вход в приложение и регистрация факта посещения. После этого сведения о пользователе, полученные из каталога учетных записей компании, вернутся приложению. Если же IDP не знает пользователя, то попросит его сначала пройти идентификацию и аутентификацию. Вместо простой проверки логина/пароля IDP может использовать дополнительные методы аутентификации, в зависимости от контекста входа и политики доступа. Например, при входе в приложение из рабочей сети пользователь может быть автоматически идентифицирован по результатам проверки в домене (технология Kerberos SSO). Если пользователь хочет зайти в какое-то очень важное приложение или, например, осуществляет вход из сети Интернет с незнакомого устройства, то IDP может запросить подтверждение – потребовать ввести разовый пароль, отправленный по СМС, либо сгенерированный мобильным приложением выработки разовых паролей.

Для идентификации IDP может также сам обратиться к внешней системе входа, например к ЕСИА, социальным сетям, Apple ID.

Выбор решений IAM на рынке достаточно разнообразен. Есть решения, которые можно устанавливать на серверах компании, и решения, которые можно арендовать в формате облачного сервиса (Identity as a Service). Можно также разработать свой IAM на основе Open Source-решений или внедрить проприетарное ПО, в том числе разработанное отечественными компаниями, включенное в единый реестр российских программ.

Еще раз подчеркну, что начинать создание системы управления доступом целесообразно именно с внедрения IAM.

Сервер аутентификации Blitz Identity Provider

Производитель: ООО «РЕАК СОФТ»
Сертификат: изделие не подлежит сертификации Назначение: комплексная IAM-система
Особенности: унифицирует доступ сотрудников, контрагентов, клиентов в собственные приложения компании и используемые облачные сервисы

Рекомендации Considerations

Система управления Governance

Используйте URL-адрес https:// /Lists/SiteCollectionAppCatalogs/AllItems.aspx для получения списка всех семейств веб-сайтов в клиенте, для которых включен каталог приложений. To list all site collections in the tenant that have the site collection app catalog enabled, use the URL https:// /Lists/SiteCollectionAppCatalogs/AllItems.aspx .

Безопасность Security

Перед развертыванием решений в каталогах приложений для семейств веб-сайтов администраторы этих семейств должны проверять соответствие решений политикам организации. Before deploying solutions to site collection app catalogs, site collection administrators should verify that these solutions meet organizational policies. Решения, установленные в каталогах приложений для семейств веб-сайтов, можно использовать только в соответствующих семействах, но они могут получать доступ к ресурсам с других сайтов клиента, поэтому администраторам следует убедиться, что развертываемые решения работают надлежащим образом. Although solutions installed in site collection app catalogs can only be used in these particular site collections, they can potentially access resources from other sites in the tenant so administrators should ensure that the solutions they are about to deploy work as intended.

Контроль привилегированных пользователей, или Privileged Account Management (PAM) – это группа решений, предназначенных для осуществления мониторинга и контроля учетных записей сотрудников IT-подразделений, системных администраторов, сотрудников аутсорсинговых организаций, занимающихся администрированием инфраструктуры компании, управления аутентификацией и авторизацией указанных сотрудников, аудита выполняемых действий, контроля доступа и записи их сессий. Помимо аббревиатуры PAM для обозначения систем контроля привилегированных пользователей, встречаются другие наименования данного класса решений, например, Privileged User Management (PUM), Privileged Identity Management (PIM), Privileged Access Management (PAM), Privileged Password Management (PPM), Privileged Account Security (PAS).

Решения, позволяющие контролировать действия учетных записей сотрудников, имеющих расширенные права, относятся к группе систем управления учетными данными (IdM/IAM-системы). Требования по мониторингу действий, выполняемых от имени учетных записей с повышенными привилегиями, возникли в связи с потребностью многих организаций передавать некоторые задачи администрирования и обслуживания инфраструктуры в руки сторонних организаций. Передача критичных ресурсов на IT-аутсорсинг подразумевает под собой серьезные риски. PAM-системы подразумевают под собой наличие следующих функций:

  • Централизованное управление учетными записями с расширенными возможностями;
  • Аудит действий привилегированных сотрудников;
  • Управление настройками парольной защиты;
  • Контроль доступа сотрудников к административным ресурсам;
  • Управление процессом аутентификации и авторизации;
  • Запись сессии, запущенной из-под учетной записи из списка привилегированных.

В зависимости от выполняемых функций, системы контроля пользователей с расширенными возможностями делятся на четыре категории:

  • решения, позволяющие управлять паролями сотрудников и осуществлять контроль доступа к общим учетным записям (SAPM);
  • решения, позволяющие управлять сессиями привилегированных пользователей к системам организации используя единую точку входа или Single Sign-On (PSM). При этом они позволяют осуществлять мониторинг, записывать и хранить информацию о действиях пользователей в рамках привилегированной сессии;
  • решения, позволяющие анализировать команды, которые использует администратор системы, а также выполнять их фильтрацию (SPM);
  • решения, позволяющие производить контроль встроенных или служебных учетных записей, которые используются различными приложениями и сервисами для выполнения собственных функций (AAPM).

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

По своей архитектуре PAM-системы могут быть выполнены как в виде программных, так и программно-аппаратных решений. Более того, по организации PAM-системы могут быть:

  • Локальные, требующие высоких капитальных затрат и операционных расходов.
  • Облачные, которые позволяют сокращать затраты за счет отсутствия необходимости организации и поддержки инфраструктуры.
  • Гибридные.

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

  • охват всех существующих каналов администрирования систем;
  • оперативное распознавание несанкционированных действий сотрудников;
  • однозначная идентификация пользователей, совершающих несанкционированные действия;
  • накопление доказательной базы поведения привилегированных пользователей.

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

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

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

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

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

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

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

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

Общее об IdM

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

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

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

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

Читать еще:  Как починить Windows с помощью DISM


Каждому сотруднику компании соответствует пользователь 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 и собирают актуальные данные по правам, потом переносят модуль за модулем в активный менеджмент, а потом позволяют сделать глобальную автоматизацию. И это всё спокойно, плавно и без рывков для пользователей.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector