Журнал "Системы Безопасности" № 3‘2018

Думаю, мысль понятна. Прежде чем что-то внед- рять, тем более систему IdM, стоит четко опре- делить цели, которые необходимо достигнуть. Существует такое понятие, как смарт-цели – кон- кретные и измеримые. Именно такие и необхо- димо ставить при внедрении IdM. Скоуп проекта Следующий этап – содержание проекта. Какие системы нужно включать в проект по IdM, то есть в каких системах через IdM будут предо- ставляться права доступа? Однозначно одна из них – кадровая система, из которой нужно забирать данные. Далее нужно сразу подумать об источнике данных о внештат- ных сотрудниках. И затем стоит еще одна нема- ловажная задача – определиться с тем: l для каких систем будут запрашиваться дан- ные через IdM; l в каких системах через IdM будут автомати- чески назначаться права доступа. Последний пункт наиболее сложный, так как существуют два варианта реализации: 1. Идеальный вариант: сотрудник запрашивает в системе IdM права доступа, эта заявка согла- совывается в установленном порядке, после чего IdM в автоматическом режиме заводит учетную запись пользователя в системе и назна- чает ему права доступа. 2. Наиболее распространенный вариант: заво- дится заявка в IdM, она проходит нужное согла- сование, после чего выгружается задача на администратора либо на сервис-деск и дальше права доступа предоставляются администрато- ром системы. Не уверен, что при внедрении системы IdM надо полностью отказаться от того варианта, когда права предоставляются автоматически, но следует максимально сузить число таких систем. Это резко упростит реализацию проекта по внедрению IdM-системы. Формирование функциональных требований Чем тщательнее и грамотнее подойти к форми- рованию функциональных требований, тем легче будет проходить этап внедрения и тем меньше грабель будет собрано на этапе внед- рения и эксплуатации. Вот только некоторые из функциональных тре- бований: 1. Наличие готовых коннекторов к эксплуатируе- мым АС. Большинство вендров заявляют, что у них 300, 500 и больше готовых коннекторов к каким-то определенным системам. Стоит сразу посмотреть, насколько этот список покрывает то, что реально эксплуатируется в инфраструктуре. 2. Наличие порталов самообслуживания. Тоже очень важный элемент, где есть выбор: l вообще не пользоваться порталом само- обслуживания и действовать по варианту, когда IdM прописывает данные в автоматиче- ском режиме в определенные системы; l пользоваться порталом самообслуживания IdM, и тогда к этому вопросу нужно подойти очень серьезно, потому что им будут пользо- ваться все сотрудники организации. Как минимум необходим быстрый и понятный интерфейс. Хорошо, если он будет похож на те, которыми уже пользуются сотрудники. l не использовать то, что предлагает вендор, и реализовать портал самообслуживания на собственных системах (например, на корпо- ративном портале, интегрируя его с выбран- ной платформой IdM). Стоит обратить внимание и на другие функцио- нальные требования: l управление жизненным циклом учетных записей; l реализация основных процедур, связанных с персоналом: прием на работу, увольнение, перемещение и т.д.; l гибкая реализация логики согласования прав доступа; l развитая отчетность, наличие построителя отчетов и т.д. Критерии выбора IdM Приведу критерии, которые мы определили в 2010 г. при внедрении проекта и которые при желании можно расширить, углубить и улуч- шить: l соответствие сформированным функциональ- но-техническим требованиям; l политика лицензирования и стоимость лицен- зий; l стоимость внедрения и владения; l наличие готовых коннекторов к эксплуатируе- мым АС; l наличие успешных внедрений (прежде всего в России); l наличие русскоязычного интерфейса и тех- поддержки; l оценка рейтинговых агентств; l заявленные сроки внедрения. l требования к аппаратной платформе; l удобство использования. Для формирования ролевой модели нужен перечень информационных активов с точки зрения информационной безопасности с понят- ным описанием (что там хранится, кому это нужно и т.д.). Чтобы реализовать технологию, при которой автоматизированная система не входит непо- средственно в скоуп (то есть IdM не предостав- ляет автоматизированной системе автоматиче- ски права доступа), важно иметь реализован- ные ИТ-процессы по управлению изменениями и управлению инцидентами. Как минимум дол- жен быть сервис-деск, на который можно отбрасывать заявки с IdM и который будет их распределять в соответствии с инструкциями. Если этого нет, то в целом вся схема будет рабо- тать очень криво и требовать много внимания. Особое внимание хотел бы обратить на нали- чие ролевых моделей. Что такое ролевая модель? Ролевая модель формируется для группы сотрудников, имеющих примерно оди- наковый функционал. Соответственно, пропи- сываются права для этой группы во всех АС, входящих в проект. Задача очень сложная и нетривиальная. По факту оказывается, что даже у сотрудников в одном отделе отличающиеся права доступа. При этом организация – это живой организм, постоянно происходят какие- то изменения. Я бы настоятельно не рекомендовал реализо- вывать проекты по IdM, когда компания не находится в относительно стабильном состоя- нии. Например, если идет бурный рост органи- зации, организационные штатные мероприятия по сокращению и оптимизации, смена про- граммно-аппаратной платформы и т.д., не сле- дует начинать процессы по внедрению IdM. Лучше закончить начатое и затем в более спо- койной обстановке приступать к внедрению IdM-системы. Иначе не получится нормально реализовать ролевую модель, а без нее IdM – это просто система по учету заявок на предо- ставление доступа и ничего более. О чем стоит подумать заранее? Основные функциональные требования доста- точно просто сформировать или найти в научно-популярных статьях. Но все же стоит подумать и об огромном количестве сопут- ствующих вещей. Это те грабли, на которые мы наступили в процессе эксплуатации. И сейчас, по прошествии шести лет, я понимаю, что об этом нужно было подумать до того, как мы начали внедрять IdM-систему. Остановимся на некоторых из них. 1. Сразу стоит оценить объем доработок в при- кладных системах. Их стоимость в нашем про- екте была сопоставима со стоимостью внедре- ния IdM. www.secuteck.ru июнь – июль 2018 УПРАВЛЕНИЕИДЕНТИФИКАЦИЕЙ w w w . a l l - o v e r - i p . r u n С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 141 Рис. 1. Цикл Деминга, или цикл PDCA