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

Современные предприятия вкладывают огромные средства в различные системы ИБ, начиная от базовых (антивирусы, межсетевые экраны) и заканчивая высокоинтеллектуальными системами типа DLP или SIEM. Внедрение этого мощного арсенала средств защиты создаёт у организации чувство защищенности, однако, как показывает практика, даже в самых мощных системах обязательно находятся абсолютно нелепые дыры, через которые и утекают важные и ценные данные.

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

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

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

Однако на практике в большинстве российских компаний предоставление прав доступа к информационным системам организовано не системно, а стихийно складывается с течением времени. Новому сотруднику те или иные права предоставляются на основании мнения его непосредственного руководителя, причем далеко не всегда права эти согласованы и утверждены с внутренними службами (ИТ, ИБ, HR) или внутренними аудиторами. В дальнейшем сотруднику предоставляются все новые и новые права, т.к. меняется бизнес-процессы, характер его работы, участие в рабочих группах, а зачастую и должность. При этом новые права доступа также далеко не всегда проходят какие-либо согласования, частенько все решается за счет личных договоренностей с системным администратором. Само собой, при такой практике объем прав доступа только нарастает, и практически никто и никогда не пытается разобраться, какие права уже не требуются сотруднику и могут быть закрыты за ненадобностью. В итоге, используя длинный шлейф доступов ко множеству информационных систем организации, старый сотрудник может воспользоваться ими по своему усмотрению, далеко не всегда в благих целях.

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

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

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

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

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

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

Как работают и что умеют современные системы класса IDM (Identity Management)

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

На современном ИТ-рынке сформировалось целое направление информационных систем, решающих описанные выше вопросы. Это направление получило название IDM (Identity Management). Давайте попробуем разобраться, как работают эти системы и что они умеют.

Если сказать совсем просто, то IDM-система сама, в автоматическом режиме, открывает, изменяет и отзывает права доступа сотрудников.

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

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

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

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

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

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

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

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

Технически это выглядит так. По установленному расписанию (например, каждые 30 минут) IDM автоматически сверяет с ролевой моделью реальные права доступа всех пользователей, существующие в ИТ-системах компании. Выявив несоответствия, система направляет уведомление всем ответственным лицам (например, администратору IDM и офицеру безопасности) и делает записи об инцидентах в журнале аудита. Получив такое уведомление, ответственное лицо открывает нужные записи этого журнала и получает удобный интерфейс для осмысления и реагирования на найденные отклонения. Прямо в журнале аудита он может выполнить одно из трех действий:

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

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

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

Потенциальные трудности при внедрении IDM систем и пути их преодоления

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

Высокая стоимость

Первая волна активного продвижения систем класса IDM относится к середине 2000-х. И как часто бывает, пионерами на новом рынке стали крупнейшие западные корпорации: Oracle, Sun, IBM. Как всегда, эти гранды разработали большие промышленные IDM-системы, ориентированные на крупнейших корпоративных заказчиков и стоящие миллионы долларов. Столь высокая цена стала первым серьезным барьером, который удержал множество организаций не только от запуска проектов, но даже от серьезных попыток оценить потенциальные выгоды такой системы для своей организации. Но, как нередко бывает, с появлением новых игроков и усилением конкуренции, ценовые предложения становятся более гуманными. Да и появление на рынке российских IDM-систем, таких как Avanpost и КУБ, существенно снизило затраты на внедрение, что привело к резкому расширению рынка.
В первое время у западных решений имелись серьезные преимущества в плане более полной функциональности. Но по состоянию на 2013 год, возможности ведущих российских и западных IDM-решений настолько сблизились, что это преимущество уже практически не актуально.

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

Сложность создания ролевой модели

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

В этом типичном случае поставщики IDM-решений предлагают клиентам провести консалтинговый проект и создать РМ непосредственно в ходе внедрения самой IDM-системы. На первый взгляд, этот шаг выглядит вполне логично, но на практике все оказывается не так просто. Дело в том, что ручная разработка такого документа в крупной компании может занять не один месяц. Но даже пройдя этот сложный путь и потратив на его реализацию немалые деньги, компания сталкивается с еще более сложной задачей — необходимостью согласовать построенную модель со всеми заинтересованными руководителями. Именно процесс согласования очень часто становиться камнем преткновения, поскольку мнения расходятся, каждый участник, пытаясь оптимизировать и улучшить модель, вносит и отстаивает предложения, которые плохо стыкуются, а зачастую и противоречат друг другу. В итоге, поиски консенсуса затягивается очень надолго и совсем не редки случаи, когда только на утверждение уже созданной модели уходят десятки месяцев! Но самое обидное, что даже пройдя этот путь до конца и согласовав таки ролевую модель, компания может столкнуться с новой напастью. Родившаяся в таких муках матрица доступа за время согласования безнадежно устарела и не может быть использована. И это понятно, ведь права доступа динамичны и меняются очень быстро.

Осознав эту проблему, производители IDM-решений приступили к серьезной проработке возможности автоматизировать вопрос создания ролевой модели.

Как обычно, пионером и в этом вопросе стали крупные западные игроки. Именно компания Oracle первой на рынке включила в свою линейку специальный продукт RoleManager, который позволял автоматизировать создание базовой версии ролевой модели. Но коллеги из Oracle допустили стратегическую ошибку, заключавшуюся в том, что этот продукт позиционировался и лицензировался отдельно от модуля Oracle IDM, что вынуждало заказчика бюджетировать и приобретать два различных дорогих и сложных продукта. Это чисто организационное ограничение привело к тому, что несмотря на безусловно полезный функционал, в России до сих пор не известно ни одного примера использования модуля RoleManager от Oracle.

Но со временем ситуация меняется к лучшему и в середине 2013 года наша компания, российский разработчик полнофункционального IDM-решения, представила своим заказчикам аналогичный модуль Avanpost Role Manager&Analytics. Вышеописанная ошибка лицензирования была учтена, и данный модуль поставляется бесплатно в комплекте с лицензиями на модуль Avanpost IDM.

Как же работает автоматическая система формирования ролей?
Классический цикл методически-корректного внедрения IDM-системы выглядит так:

1. Устанавливаем ядро IDM-системы;
2. Осуществляем его интеграцию с кадровой базой и со всеми целевыми ИТ-системами с помощью т. н. «коннекторов» (модулей интеграции).
3. Закладываем в IDM-систему ролевую модель, в случае необходимости проводим работы по ее созданию.
4. Запускаем систему в работу.

При использовании модуля Role Manager порядок действий меняется:

1. Устанавливаем ядро системы IDM со встроенным модулем Role Manager&Analitics;
2. Осуществляем интеграцию IDM с кадровой базой и со всеми целевыми ИТ-системами с помощью коннекторов.
3. Не закладывая в систему ролевую модель, переводим IDM-систему в режим сбора информации об имеющихся в целевых системах реальных правах доступа — и формируем единую базу всех имеющихся учетных записей и их прав доступа.
4. Запускаем аналитическую обработку полученной базы модулем Role Manager&Analitics и формируем базовую ролевую модель и набор исключений имеющих место на практике.
5. Переводим систему в нормальный рабочий режим, на основании созданной ролевой модели.
6. В удобном режиме анализируем все оставленные исключения и, в случае необходимости, дорабатываем базовую ролевую модель.

Самым интересным шагом в рамках данного алгоритма является шаг № 4. Давайте разберемся более подробно, что же подразумевается под «аналитической обработкой базы данных реальных прав доступа».

На шаге № 3 IDM-система «как пылесос» вытащила и собрала в единую базу данных информацию обо всех учетных записях, имеющихся в каждой из информационных систем. Следующий шаг — подтягивание из кадровой системы информации о ФИО и должностях сотрудников и последующее соотнесение собранных учетных записей с конкретными сотрудниками и их фактическими должностями. Далее вступает в работу аналитическая система, которая выявляет корреляцию между правами доступа сотрудников, работающих на одинаковых должностях.

Давайте представим, что в компании «X» работает 7 менеджеров по продажам и имеется 10 ИТ-систем, причем у каждого менеджера имеется свой набор прав доступа к ним. Тогда, проведя описанные выше шаги, мы могли бы получить такую информацию по этим менеджерам:

• 100% менеджеров имеют доступ к 1 и 7 ИТ-системам;
• 90% менеджеров имеют доступ к системе 2;
• 70% менеджеров имеют доступ к системам 4 и 9;
• 50% сотрудников имеют доступ к системе 3.
• И еще у некоторых сотрудников присутствуют отдельные доступы к системам, не упомянутым выше

Последнее что нам остаётся, это задать порог чувствительности. Т. е. определить, что мы будем считать базовой ролью. Например, мы можем указать, что в виде роли надо оформить права, встречающиеся у данной категории сотрудников не реже чем в 70% случаев. В нашем примере это будут ИТ-системы 1,2,4,7 и 9.

С остальными же правами доступа можно поступить двумя способами:

• Отозвать их и посмотреть, за какими правами сотрудники оперативно обратятся. Это послужит подтверждением, что доступ действительно нужен.
• Добавить их в исключение к базовой роли. А позже, когда позволит время, проанализировать эти исключения и устранить те из них, которые не требуются для производственной деятельности.

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

Заключение

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

Вы не одиноки: за последние пару лет все большее число российских компаний серьезно озаботилось наведением порядка в вопросах управления доступом к своим ИТ-ресурсам, и решает их не чисто административными методами, а на основе подходов, описанных в этой статье. Это свидетельствует о несомненном повышении уровня зрелости ИТ- и ИБ-руководства этих организаций. Я уверен, не пройдет и 10 лет, как системы класса IDM станут таким же неотъемлемым элементом ИТ-инфраструктуры любой организации, каким сегодня является антивирусное ПО.

Андрей Конусов, генеральный директор компании Аванпост