События последнего времени, связанные с несанкционированным доступом к данным, утечками информации, у всех на слуху. Достаточно вспомнить, например, историю с растратой €4,9 млрд. трейдером банка Сосьете Женераль Жеромом Кервьелем, ставшей возможной (по одной из версий) благодаря недостаточно четкому разделению полномочий. Примеры утечек персональных данных клиентов из разнообразных организаций и государственных органов можно найти еще ближе к нам - базы данных с номерами сотовых телефонов, паспортными данными, номерами автомашин и персональной информацией об их владельцах и даже с информацией о доходах физических и юридических лиц можно купить почти в любом подземном переходе.

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

Сейчас, когда по данным аналитического центра Perimetrix 100% организаций имеют антивирусную защиту и межсетевые экраны, но лишь 24% имеют защиту от утечек, задача защиты от инсайдерских угроз выходит для многих компаний на передний план.

Одним из способов борьбы с несанкционированным доступом является внедрение ролевой модели доступа к данным и информационным системам. А средством для внедрения этой модели являются продукты класса IdM (Identity Management).

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

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

Но уменьшением вероятности инсайдерской угрозы польза от внедрения решения IdM на предприятии не ограничивается.

Выгоды от внедрения решения такого класса хорошо известны, это:
 • Сокращение дорогостоящего времени, которое вынуждены тратить сотрудники ИТ отделов на:
   - создание учетных записей и выдачу им соответствующих прав в разнообразных ИТ системах при приеме сотрудников на работу, 
   - изменение прав сотрудников при переводе их на другую должность или изменение должностных обязанностей
   - блокировку учетных записей при уходе сотрудника в отпуск (к слову сказать, во многих организациях выполнение этого элементарного действия до сих пор не стало нормой)
   - удаление или блокировку учетных записей сотрудника в случае его увольнения
   - восстановление забытых паролей (есть данные, что в больших организациях с жесткими требованиями к регулярности смены паролей, на восстановление забытых паролей тратится до 60% времени местных администраторов).
• Сокращение вынужденных простоев сотрудников при приеме на работу и переходе из должности в должность. Вспомните, как вы сами по нескольку дней (а самые невезучие и по нескольку недель) ждали, пока занятые админы создадут вам учетную запись для захода на рабочую станцию и в корпоративную сеть, логин в почту, электронный пропуск в здание или на этаж, номер служебного телефона и т.д. А ведь все эти действия можно было бы выполнить за один шаг автоматически при приеме сотрудника на работу, если бы на предприятии было внедрено решение класса IdM.
• Сокращение времени простоя сотрудников при смене пароля. Процедура смены пароля вообще является чувствительным местом в работе крупных компаний – она отнимает много времени у админов, о чем мы упомянули в первом пункте нашего перечисления. Но для компании это оборачивается двойным убытком, потому что плохо отражается и на пользователях. Я вспоминаю, как в некой организации один сотрудник два дня скучал перед отключенным компьютером, поскольку после бурно проведенных выходных он напрочь забыл пароль, заданный им в пятницу накануне. А у занятых админов не было времени добраться до этого пользователя, потому что он, по всей видимости, был не единственным, кто в ту пятницу в соответствии с корпоративной политикой сменил пароль.
• Сокращение времени, в течение которого уволенный сотрудник может нанести непоправимый ущерб информационным активам предприятия (удаление или блокировка учетных записей сотрудника во всех ИТ системах может быть осуществлена за один шаг).
• Исключение возможности, что злоумышленник воспользуется «черным входом» в виде учетной записи, оставшейся после давно уволившегося сотрудника. Мы не обладаем данными по российским компаниям, но исследования проведенные среди американских предприятий несколько лет назад, показали, что на некоторых крупных предприятиях до 80% всех учетных записей составляют «мертвые души» - учетные записи давно уволенных сотрудников.
• Минимизация усилий и сокращение времени на интеграцию в корпоративную среду новых приложений.

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

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

PROS
Достоинства централизованного подхода достаточно очевидны. На первом месте стоит Универсальность политик безопасности.

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

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

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

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

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

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

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

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

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

Нагрузка на каналы связи
Постепенно, по мере улучшения каналов связи в регионах, эта проблема уходит в прошлое. Возможно, через некоторое время, когда до каждого населенного пункта не только в России и ее ближайших соседях, но и по всему миру, проложат широкие каналы доступа, эта проблема перестанет быть актуальной. Глядя на то, с какой скоростью, немыслимой еще каких-нибудь пять лет назад, продвигается дело, веришь, что так оно и будет. Да и сейчас даже при слабых каналах связи проблема актуальна только при передаче больших объемов данных, например, когда идет реконсиляция. При средних объемах передаваемых данных, которые порождаются ежедневными кадровыми изменениями (прием на работу/увольнение с работы/изменение должностных обязанностей), эта проблема теряет свою остроту.

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

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

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

Преимущества гибридного подхода
Наилучшим вариантом нам видится разумное совмещение централизованного и децентрализованного подходов. Есть некоторые вещи, которые удобнее делать из центра. К этим вещам можно причислить:
• Централизованное определение политик безопасности. Например, минимальную длину и сложность пароля для всех ИТ систем правильнее определять из центра, так, чтобы эти правила были едиными для всех регионов.
• Правила транслитерации имен (как преобразовывать кириллицу, которой записаны мена и фамилии сотрудников к латинице).
• Правила создания имен учетных записей. Например, <имя>.<фамилия> или <первая буква имени>_<фамилия>.
• Если на предприятии есть штатное расписание, единое для всех регионов, то уместно определить в центре, какой должности в штатном расписании соответствует какой набор полномочий в ИТ системах (и, соответственно с этим, с помощью членства в каких группах реализуются эти полномочия).
• Электронный документооборот или те его части, в которые вовлечены сотрудники из штаб-квартиры предприятия.

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

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

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

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

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

Что касается не-ценовых критериев выбора, то на наш взгляд можно выделить несколько основных параметров:
1. Количество готовых коннекторов для разнообразных систем. Чем больше коннекторов, тем выше вероятность, что вам в процессе внедрения этого решения не придется столкнуться с большим объемом разработки, что, естественно, ускорит и удешевит процесс разворачивания решения. Особое внимание имеет смысл обратить на наличие готовых коннекторов к доверительным источникам информации. Напомним, что, доверительным источником информации для IdM как правило, является база данных Отдела Кадров. Эта интеграция служит непременным условием внедрения всего решения.

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

3. Возможность использования электронного документооборота (процедуры принятия решения по предоставлению доступа). Желательна возможность использования сложной логики, которая реализует корпоративные правила принятия решения на предоставление доступа к тем или иным ИТ ресурсам.

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

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

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

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

8. Наличие компаний-интеграторов с опытом внедрения. Единичные успешные внедрения могут быть результатом усилий одного или нескольких человек. Но вам нужна именно технология внедрения, которая гарантирует успех внедрения во всех 100% случаев. А наличие такой технологии может гарантировать только развитая сеть партнеров, каждый из которых обладает коллективом с опытом внедрения выбранного продукта.

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

Ведущие аналитики от Forrester Research считают, что Oracle Identity Manager (OIM) удовлетворяет вышеперечисленным критериям.

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

Если у интегрируемых приложений есть возможность предоставлять web-доступ к своей функциональности (у большинства современных приложений такая возможность есть), то эти приложения можно защитить с помощью Access Manager. Преимущества этого подхода следующие: мы получаем возможность контролировать доступ к корпоративной информационной системе на уровне ресурсов, у нас появляется единая безопасная точка доступа, можно реализовать web-SSO (Web Single Sign-On, система, обеспечивающая однократную аутентификацию пользователя через web-интерфейс; не путать с e-SSO, Enterprise Single Sign-On, обеспечивающим возможность прозрачного подключения к любым приложениям, в том числе и не обладающими web-интерфейсом). Удобно эту систему использовать в связке с IdM. В качестве примера здесь можно привести решение на основе продуктов Oracle Identity Manager и Oracle Access Manager.

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

Иван Бакланов,
Ведущий консультант по направлению информационной безопасности, Oracle СНГ