Отличительные особенности КУБ

Автоматизация управления учетными записями невозможна без интеграции с системой кадрового учета (СКУ), используемой в организации. В ответ на происходящие в ней события, такие как прием на работу, увольнение, перемещение с должности на должность и другие КУБ автоматически создает, изменяет или блокирует учетные записи сотрудников к целевым системам, и выдает им необходимые права доступа.

КУБ имеет ряд особенностей:

• во-первых, КУБ может быть интегрирован с несколькими СКУ и такая практика использования разнородных систем распространена в крупных предприятиях имеющих регионально распределенную филиальную сеть;
• во-вторых, КУБ умеет учитывать специфику работы с учетными записями и правами доступа сотрудников, работающих по совместительству и исполняющих несколько ролей;
• в-третьих, новых сотрудников можно создавать в самой системе КУБ и управлять их правами доступа. Это актуально, например, при наличии внекадровых сотрудников или сотрудников на аутсорсинге. Информация о таких сотрудниках, как правило, в СКУ не хранится.

КУБ контролирует факты и сроки исполнения заявок на доступ к информационным ресурсам.

Система мониторит все изменения, происходящие в информационных системах, сопоставляя их с пулом открытых инструкций. При совпадении – соответствующая заявка получает статус исполненной. Если заявка по какой-либо причине не выполнена в положенный срок, ее автор получает уведомление о задержке, а самой заявке присваивается один из статусов:

• просроченное согласование
• просроченная актуализация
• просроченное исполнение

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

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

Делегирование может быть выполнено вручную или автоматически.

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

Сотрудник, которому были делегированы обязанности, получает уведомление с указанием причины делегирования.

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

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

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

На практике может оказаться так, что такая система вообще не имеет какого-либо API, позволяющего управлять ей с помощью внедряемого IDM. Либо API существует, но по ряду причин разработка коннектора к такой системе очень трудоемкая и может затянуться на неопределенное время.

Для таких ситуаций в КУБ есть специальный механизм, позволяющий "подключать" подобные информационные системы.

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

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

В случае, если для информационной системы не существует API, с ограничениями ничего поделать будет нельзя. Если же API существует, впоследствии можно разработать полноценный коннектор, позволяющий автоматизировать процесс предоставления доступа и контролировать состояние информационной системы.

Управление доступом на основе ролевой модели необходимый функционал, без которого внедрение IDM, фактически, бессмысленно. Однако, данный подход не всегда является приемлемым.

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

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

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

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

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

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

При разработке «КУБ» мы учли эту проблему на уровне архитектуры системы и обеспечили непрерывный контроль прав пользователей в режиме реального времени.

КУБ постоянно хранит так называемый «слепок» состояний всех целевых систем, учитывая изменения, произошедшие на основе согласованных заявок. То есть после согласования заявки сначала изменяется внутреннее состояние КУБ, а затем изменения производятся в самой целевой системе. Таким образом можно сказать, что КУБ находится в «состоянии равновесия». И если после этого в целевой системе произошло несанкционированное изменение, КУБ обнаружит это изменение и сравнит текущее состояние целевой системы со своим внутренним состоянием. Если обнаружится расхождение, то будут сгенерированы несоответствия и сохранены в специальном журнале. О несоответствиях моментально узнает офицер ИБ.

Несоответствие может быть согласовано или отклонено. Согласование означает, что офицер ИБ согласен с данными изменениями, и КУБ снова приходит в состояние равновесия. В противном случае при отклонении несоответствия произойдет автоматический откат произведенных несакнционированных изменений в целевой системе.

Коннектор Windows/Active Directory (AD) является частью системы КУБ и предназначен для управления учетными записями и правами доступа к файловым ресурсам.

При управлении доступом к файловым ресурсам КУБ контролирует права, выданные конкретной учетной записи, и права, выданные через группы AD. Кстати, большинство современных IDM контролировать права, выданные через группы, не умеют.

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

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

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

Эта возможность нужна, чтобы при необходимости можно было установить, кто, когда и на каком основании запросил или согласовал доступ сотрудника к ресурсу. При наличии электронной подписи ее автор уже не сможет сказать – это не я!

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

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

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

Созданные заявки и заявки в фазе согласования, подписанные ЭП, попадают на сервер КУБ. На сервере также проводится проверка ЭП для того, чтобы выявить ее подмену, которая могла произойти при пересылке информации на сервер. Причем проверка выполняется в тот момент времени, когда заявка принимается сервером к исполнению или когда на сервере выполняется операция согласования заявки. С учетом результатов проверки ЭП принимается решение – принять или отклонить заявку.

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

Политика информационной безопасности некоторых компаний запрещает автоматическое исполнение заявок на предоставление доступа к информационным ресурсам. Поэтому в КУБ предусмотрены два режима работы коннекторов: автоматический и ручной.

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

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

Контроль состояния информационных систем должен быть непрерывным, поскольку, только в этом случае можно говорить о своевременном выявлении неверно предоставленных прав.

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

В КУБ есть 2 режима исполнения заявок: основной - автоматически и дополнительный - ручной. В ряде случаев ручной режим является единственным приемлемым.

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

Для определения списка согласующих сотрудников используется понятие "ответственность". Ответственность назначается сотруднику. С помощью механизма ответственностей определяется перечень событий, на которые должен реагировать сотрудник, получивший конкретную ответственность.

Например:

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

и так далее

Анализируя создаваемую заявку, КУБ выбирает подходящие ответственности и рассылает уведомления сотрудникам, на которых выбранные ответственности назначены. В случае отсутствия согласующего лица на работе в список согласующих лиц автоматически включается его заместитель. Если заместитель также отсутствует, а для ответственности включен режим делегирования, то в список согласующих лиц автоматически включается один из непосредственных руководителей отсутствующего согласующего лица.

Данный механизм является гибким и понятным пользователям, так как совпадает с понятием ответственности из реальной жизни.

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

В КУБ любые несоответствия выявляются в режиме онлайн и фиксируются в журнале несоответствий. Сотрудник, ответственный за соблюдение политики ИБ в системе, где обнаружено несоответствие, получает оповещение. После получения оповещения ему следует расследовать данное несоответствие и выяснить, кто и с какой целью выполнил несанкционированное изменение прав доступа.

Как правило, предоставление доступа в обход установленного порядка происходит в следующих случаях:

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

В случае, если несоответствие возникло из-за неправильной реализации требований заявки на доступ, ответственный должен перевести несоответствие в статус «отклонено», создать корректирующую заявку и направить ее на реализацию.

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

Если же по итогам расследования выясняется, что несоответствие возникло в результате злонамеренных действий, ответственный за соблюдение политики ИБ должен оценить последствия несанкционированных действий, устранить несоответствия (блокировать учетную запись, ограничить доступ и т.п.), выявить обстоятельства и принять меры в соответствии с правилами внутреннего распорядка.

После устранения несоответствие сохраняется в архиве для последующего анализа в других процессах.

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

При использовании IDM для пользователей значительно упрощаются и ускоряются процессы выдачи и отъема прав доступа. Однако остается одно неудобство - необходимость запоминания большого количества паролей к используемым целевым системам.

Для решения данной проблемы существует отдельный класс решений – SSO (Single Sigh-On). Такие системы позволяют пользователю пройти аутентификацию один единственный раз и получить доступ ко всем информационным системам.

Система КУБ интегрирована с продуктом Indeed-Id Enterprise SSO для того, чтобы обеспечить решение следующих задач:

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

Схема комплексного решения описанных выше задач выглядит так:

Весь процесс условно разделяется на 5 шагов:

1. Сотрудник отдела кадров регистрирует запись о новом сотруднике в системе учета персонала (HR система).
2. Данные о новом сотруднике попадают в КУБ через коннектор к HR системе.
3. На основе этого события КУБ с помощью коннекторов создает для сотрудника учетные записи во всех приложениях и выдает ему необходимые права доступа, согласно установленным в организации правилам и политикам. На этом же шаге также создаются учетная запись и пароль для аутентификации в домене.
4. Коннектор КУБ к Indeed-Id Enterprise SSO создает профиль доступа сотрудника в БД Indeed-Id Enterprise SSO, копируя в него учетные данные пользователя.
5. При первом доступе к своему компьютеру пользователь указывает имя доменной учетной записи и пароль. После успешного входа в систему пользователь может настроить для последующего использования альтернативные аутентификаторы (смарт-карту, токен, генераторы одноразовых паролей, средства биометрической аутентификации и т.д.). После того как все необходимые настройки выполнены, пользователь может использовать выбранные аутентификаторы для доступа в домен и ко всем приложениями. Помнить пароль, использованный для первого входа в систему, больше нет необходимости.

КУБ интегрирован с ITSM системами, например HP Service Manager, Инфраменеджер и другими.

Напомним, что ITSM системы предназначены для выстраивания процесса обращения пользователей в ИТ службу за получением каких-либо сервисов, например, оборудование рабочих мест, замена техники, helpdesk и так далее. Встроив в эту схему КУБ, мы автоматизировали процесс получения прав и управление доступом, используя при этом единый портал для пользователей по любым техническим вопросам.

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

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

Что получает пользователь при комплексном решении IDM+ITSM?

• Единый портал для пользователей по любым техническим вопросам
• Центр контроля трудозатрат ИТ-сотрудников и затрат на ИТ-сервисы
• Единый центр управления всеми ИТ-услугами
• Интеллектуальное согласованное управление разными операциями
• Управление и контроль доступа к информационным системам организации, в том числе, к функциям самой ITSM-системы, средствами КУБ
• Автоматическое выполнение инструкций с учетом требований информационной безопасности.

В системе «КУБ» есть уникальный функционал, которого, на сегодняшний день, нет ни в одном IDM решении - это управление и контроль программно-аппаратных конфигураций (ПАК). Под конфигурацией мы понимаем установленные программные и аппаратные средства на серверах и рабочих станциях.

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

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

Для управления ПАК «КУБ» использует специальные шаблоны, которые включают в себя список элементов программно-аппаратного обеспечения. Администратор назначает шаблоны на сервера и рабочие станции и, в дальнейшем, контролирует соответствие шаблонов реальному состоянию.

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

Уникальная возможность системы, не реализованная в других IDM. Чем это хорошо для пользователей?

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

В КУБ пользователь составляет только одну заявку на необходимый доступ и дальше может ни о чем не беспокоиться. После согласования Заявки исполнители получат автоматически сгенерированные инструкции в понятной им терминологии, когда, где, кому и что необходимо сделать, чтобы запрошенный доступ был получен в нужные сроки.

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

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

КУБ содержит средства поиска новых ресурсов и механизмы автоматизированного определения владельцев ресурсов. Анализ производится исходя из иерархии ресурсов и существующих прав доступа к ним. Специализированный мастер позволяет определить владельца или отнести ресурсы к общекорпоративным.

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

Инвентаризация позволяет существенно снизить риски утечки ценной для компании информации благодаря строгому категорированию ресурсов и персонализации доступа к ним.