Пост, который вы сейчас читаете, – продолжение статьи о том, как правильно выстроить в крупной компании ролевую модель управления доступом пользователей к различным системам. Напомним: построение ролевой модели – это скорее процесс, чем результат, и первую часть нашей дилогии мы посвятили подготовке к «строительству». В ней мы рассказали, как создать функциональную модель каждого подразделения и должности, провести аудит ИТ-систем и расставить их по приоритетам, создать бизнес-ориентированное описание прав пользователей и о других важных подготовительных шагах. Сегодня же поговорим о способах построения ролевой модели, ролевых матрицах, чем здесь поможет внедрение автоматизированных систем управления доступом (IdM/IGA), и что вы получите на выходе.
Для построения ролевой модели в информационной системе есть два способа.
Роли разрабатываются на основании функциональной модели. Этот подход возможен, когда в организации есть специальное подразделение технологов, назовём его «Организационно технологический отдел (ОТО)». У нас в банке такой отдел был в составе ИТ-департамента. Отдел будет переводить потребности бизнеса, описанные в функциональной модели, на язык ИТ: язык прав/опций/полномочий, которые нужно предоставить в системе для выполнения конкретного функционала.
Также этот подход хорош, когда вводится в эксплуатацию новая система и ролевые модели формируются с нуля. Для начала нужно разобраться вместе с ИТ–менеджером системы, каким образом предоставляются права, есть ли какие-то внутренние роли или группы в системе. Затем совместно с руководителями бизнес-подразделений и технологами ОТО нужно разработать роли, включив в них необходимые права. Затем созданные роли необходимо согласовать с владельцем системы от бизнеса, т.к. он отвечает за выполнение бизнес-процессов, с подразделением внутреннего контроля для исключения кросс-системных конфликтов и с подразделением безопасности, чтобы не нарушалась утверждённая политика безопасности компании. После этого систему можно вводить в эксплуатацию и назначать права в соответствии с утверждённой ролевой моделью.
Роли формируются из действующих прав, уже предоставленных сотрудникам. В большинстве случаев требуется сделать именно это, т.к. системы эксплуатируются достаточно давно и нужно разобраться с тем бардаком в правах пользователей, который накопился за много лет эксплуатации. Здесь есть свои особенности.
Если система не очень большая и в ней немного разнообразных прав, то выделить общие совпадающие права у сотрудников одной должности несложно. Из них можно составить роль, а затем направить её на согласование и утверждение руководителю, владельцу ресурса и далее по цепочке, как в первом случае. Если же в системе очень много прав (полномочий), и ее использует большое число сотрудников из разных подразделений, то задача усложняется. В этом случае на помощь приходят специализированные утилиты, именуемые Role mining, которые облегчают задачу. Они собирают совпадающие права для определённой должности в стандартную роль, которая анализируется и утверждается заинтересованными сторонами.
В нашей крупной финансовой компании мы строили ролевую модель по второму подходу, чтобы навести порядок в уже работающих системах. По тем из них, в которых пользователи имели немного прав, мы взяли очищенную выборку (только активных пользователей). Разработали шаблон заполнения ролевой матрицы для каждой системы: напомним, ролевая матрица – это роли (набор прав) в привязке к подразделениям компании и должностям в них. Шаблон направили владельцам этих систем для заполнения. Те в свою очередь собрали информацию с подразделений, в которых использовалась система, и вернули уже заполненный шаблон для дальнейшего согласования со службами ИБ и внутреннего контроля. Заполненный шаблон, а именно ролевая матрица затем используется в предоставлении доступа на основе ролей, а также включения в будущий проект автоматизации.
К сожалению, не бывает таких матриц и таких систем, где все права могут быть однозначно разбиты по ролям и роли привязаны к должностям. Поскольку в этом случае вы либо получите немного довольно универсальных ролей, где часть прав будет избыточна. Либо, наоборот, слишком много ролей, и это будет уже не ролевой, а персональный доступ на основе дискреционного метода, о котором мы писали в первой части. Часто в крупных организациях роли могут быть необходимы не для должности, а для конкретного функционала. Например, несколько сотрудников могут занимать одну и ту же должность, но выполнять разные функции. Поэтому имеет смысл часть одинакового функционала вносить в базовые роли, которые будут присваиваться по умолчанию. А часть уникальных функций сотрудника оставлять для оформления прав по отдельным запросам, которые направляются на согласование в установленном в компании порядке.
Наш шаблон выглядел так. На первом листе слева (по вертикали) были перечислены должности и подразделения, а сверху (по горизонтали) – роли. На пересечении необходимо было установить маркер, указав, для какого подразделения необходима какая роль/роли. Цветной заливкой мы отмечали: зелёным – роли, которые должны быть предоставлены по умолчанию, при назначении на должность; жёлтым – роли, которые могут быть запрошены для конкретной должности или подразделения по отдельной дополнительной заявке.
На втором листе мы разместили справочник, который показывал наполнение ролей отдельными правами (полномочиями).
На третьем листе – матрицу SOD-конфликтов (запрета на возможное сочетание ролей).
Сразу скажу, что к теме SOD-конфликтов мы подошли в первом приближении, т.к. это отдельная большая активность со своим собственным процессом. Запрет на сочетание определенных полномочий может устанавливаться как в рамках отдельной роли, так и между ролями, и в кроссистемных взаимодействиях. Кроме того, важна настройка процесса работы с SOD- конфликтами и разработка сценариев реагирования на них. Это тема для отдельного рассмотрения.
Для тех систем, в которых много пользователей и структура прав довольно разнообразная, составить матрицу в ручном режиме очень непросто. Мы использовали для этих целей специализированные инструменты построения ролевой модели Role mining. Инструменты эти могут сильно отличаться логикой работы, стоимостью, удобством использования и другими характеристиками. Но принцип работы и цели у них общие — это сбор информации о текущих правах сотрудника в информационных системах, анализ повторяемости этих прав для сотрудников с одинаковыми атрибутами, объединение этих прав в роли и, в конечном итоге, построение некой базовой ролевой модели, которая отражает текущее положение дел.
Сейчас, по прошествии времени и работая в компании, которая разрабатывает ПО для управления доступом, я понимаю, что есть и более эффективные методы построения ролевых моделей в крупных системах. Чем раньше организация придет к использованию автоматизированных средств для наведения порядка, тем более гладко и безболезненно пройдёт процесс построения ролевых моделей. В этом случае автоматизированная система будет помощником или подспорьем в построении ролей. Внедрение автоматизированных систем управления доступом (IdM/IGA) нужно начинать с подключения кадровых источников и целевых систем для выгрузки данных и их мапинга и анализа. Используя специализированные инструменты, встроенные в решения по управлению доступом, можно с самого начала достаточно эффективно выстроить нужные процессы на основе автоматизации. Это значительно сократит трудозатраты и исключит шоковую терапию в будущем. Например, гораздо быстрее и эффективнее пройдёт процесс работы с учётными записями, а именно на первом этапе:
А уже на втором этапе использование автоматизированных систем управления доступом позволяет повысить эффективность работы с правами пользователей и построить ролевую модель, в частности:
Мы добрались до того момента, когда в компании можно начинать жить по новому регламенту управления доступом: предоставлять доступ, изменять и аннулировать с учетом его новой структуры. Что должно быть в этом регламенте:
Ролевая модель не может быть статичной. Она, как живой организм, должна адаптироваться под происходящие в организации изменения. Что служит поводом для её корректировки?
Первое – это изменение организационно-штатной структуры. В крупных организациях, в этом я убедилась на собственном опыте, такие изменения могут происходить практически ежедневно. Часто изменения связаны с переименованием подразделений и должностей. При этом функционал остаётся прежним, но, тем не менее, эти изменения должны отражаться в ролевой модели и все корректировки должны вноситься своевременно. Когда же происходит слияние подразделений или, наоборот, деление на отдельные группы/отделы, то изменения более глобальны. Они затрагивают функционал работников, который нужно пересмотреть, актуализировать функциональную модель и на её основе внести изменения в существующие роли. Или же разработать и внедрить новые роли в ролевую модель.
Второе – это изменение бизнес-процессов компании. Бизнес не может быть статичным: внедряются новые процессы и механизмы, которые позволяют совершенствовать работу каждого подразделения. Это улучшает обслуживание клиентов, повышает продажи, помогает достичь стратегических целей. Внедрение каждого нового бизнес-процесса должно учитываться в ролевой модели. Появятся новые роли, или же придется доработать имеющиеся, – и в них нужно будет включить новые опции и права.
Третье – это изменение системной архитектуры. На предприятиях периодически происходит вывод из эксплуатации старых систем и ввод в эксплуатацию новых. Допустим, старая система выводится из эксплуатации и функционал, который в ней выполняли сотрудники, должен быть переведён в новую систему. Для этого придётся провести ревизию всех ролей старой системы и их актуальности, проанализировать созданные роли новой системы и сделать матрицу сопоставления старых и новых ролей. Вполне возможно, что на какой-то переходный период эти роли будут существовать параллельно, пока весь нужный функционал не перенесут в новую систему и ролевая модель не будет доработана. Затем использование ролей старой системы можно будет прекратить, доступ пользователей аннулировать, а данные старой системы отправить в архив.
Все рассмотренные изменения говорят о том, что для поддержания актуальности ролевой модели нужен отдельный процесс. В нем следует учесть все активности организации, связанные с доступом к информационным ресурсам. Он должен включать процедуру обновления ролевой модели, которая планируется заранее, чтобы все необходимые изменения были сделаны вовремя. Это и инициирование заявки на изменение роли/ролей в автоматическом или ручном режиме, и согласование, и утверждение изменений и их ввод в эксплуатацию с актуализацией смежных процессов. Всё это должно быть зафиксировано в регламенте по ведению и обновлению ролевой модели, где также необходимо указать ответственных за каждый шаг процесса.
Помимо изменений в ролевой модели на основании вышеописанных причин нужен систематический плановый пересмотр прав. В частности, для финансовых компаний таких регулярных пересмотров требуют надзорные органы. Пересмотры позволяют выявлять недочёты в существующей модели прав и повышать контроль за полномочиями пользователей. Решение этой задачи значительно упрощают IGA/IdM-системы, которые позволяют автоматизировать процесс пересмотра (ресертификации) с заданной периодичностью.
Управление доступом с использованием ролевой модели повышает уровень информационной безопасности компании, т.к. доступ становится более прозрачным, управляемым и контролируемым. А также снижает нагрузку на подразделение ИТ в части его администрирования. Что станет делать проще с помощью ролевого управления доступом?
Однако одним лишь построением ролевой модели не решить вопрос качественного и эффективного управления доступом в большой компании – это только один из шагов. Если построить ролевую модель и на этом успокоиться, через какое-то время она устареет, и грандиозная проделанная работа окажется абсолютно бесполезной. Почему?
Все перечисленные причины говорят о том, что важен именно комплекс мероприятий по управлению доступом. Нужны средства автоматизации, работающие процессы и механизмы, их поддержка, развитие, обновление и масштабирование в соответствии с жизненным циклом компании.
Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights
Для построения ролевой модели в информационной системе есть два способа.
Первый подход
Роли разрабатываются на основании функциональной модели. Этот подход возможен, когда в организации есть специальное подразделение технологов, назовём его «Организационно технологический отдел (ОТО)». У нас в банке такой отдел был в составе ИТ-департамента. Отдел будет переводить потребности бизнеса, описанные в функциональной модели, на язык ИТ: язык прав/опций/полномочий, которые нужно предоставить в системе для выполнения конкретного функционала.
Также этот подход хорош, когда вводится в эксплуатацию новая система и ролевые модели формируются с нуля. Для начала нужно разобраться вместе с ИТ–менеджером системы, каким образом предоставляются права, есть ли какие-то внутренние роли или группы в системе. Затем совместно с руководителями бизнес-подразделений и технологами ОТО нужно разработать роли, включив в них необходимые права. Затем созданные роли необходимо согласовать с владельцем системы от бизнеса, т.к. он отвечает за выполнение бизнес-процессов, с подразделением внутреннего контроля для исключения кросс-системных конфликтов и с подразделением безопасности, чтобы не нарушалась утверждённая политика безопасности компании. После этого систему можно вводить в эксплуатацию и назначать права в соответствии с утверждённой ролевой моделью.
Второй подход
Роли формируются из действующих прав, уже предоставленных сотрудникам. В большинстве случаев требуется сделать именно это, т.к. системы эксплуатируются достаточно давно и нужно разобраться с тем бардаком в правах пользователей, который накопился за много лет эксплуатации. Здесь есть свои особенности.
Если система не очень большая и в ней немного разнообразных прав, то выделить общие совпадающие права у сотрудников одной должности несложно. Из них можно составить роль, а затем направить её на согласование и утверждение руководителю, владельцу ресурса и далее по цепочке, как в первом случае. Если же в системе очень много прав (полномочий), и ее использует большое число сотрудников из разных подразделений, то задача усложняется. В этом случае на помощь приходят специализированные утилиты, именуемые Role mining, которые облегчают задачу. Они собирают совпадающие права для определённой должности в стандартную роль, которая анализируется и утверждается заинтересованными сторонами.
Строим ролевую модель по второму подходу
В нашей крупной финансовой компании мы строили ролевую модель по второму подходу, чтобы навести порядок в уже работающих системах. По тем из них, в которых пользователи имели немного прав, мы взяли очищенную выборку (только активных пользователей). Разработали шаблон заполнения ролевой матрицы для каждой системы: напомним, ролевая матрица – это роли (набор прав) в привязке к подразделениям компании и должностям в них. Шаблон направили владельцам этих систем для заполнения. Те в свою очередь собрали информацию с подразделений, в которых использовалась система, и вернули уже заполненный шаблон для дальнейшего согласования со службами ИБ и внутреннего контроля. Заполненный шаблон, а именно ролевая матрица затем используется в предоставлении доступа на основе ролей, а также включения в будущий проект автоматизации.
К сожалению, не бывает таких матриц и таких систем, где все права могут быть однозначно разбиты по ролям и роли привязаны к должностям. Поскольку в этом случае вы либо получите немного довольно универсальных ролей, где часть прав будет избыточна. Либо, наоборот, слишком много ролей, и это будет уже не ролевой, а персональный доступ на основе дискреционного метода, о котором мы писали в первой части. Часто в крупных организациях роли могут быть необходимы не для должности, а для конкретного функционала. Например, несколько сотрудников могут занимать одну и ту же должность, но выполнять разные функции. Поэтому имеет смысл часть одинакового функционала вносить в базовые роли, которые будут присваиваться по умолчанию. А часть уникальных функций сотрудника оставлять для оформления прав по отдельным запросам, которые направляются на согласование в установленном в компании порядке.
Пример шаблона для заполнения ролевых матриц
Наш шаблон выглядел так. На первом листе слева (по вертикали) были перечислены должности и подразделения, а сверху (по горизонтали) – роли. На пересечении необходимо было установить маркер, указав, для какого подразделения необходима какая роль/роли. Цветной заливкой мы отмечали: зелёным – роли, которые должны быть предоставлены по умолчанию, при назначении на должность; жёлтым – роли, которые могут быть запрошены для конкретной должности или подразделения по отдельной дополнительной заявке.
На втором листе мы разместили справочник, который показывал наполнение ролей отдельными правами (полномочиями).
На третьем листе – матрицу SOD-конфликтов (запрета на возможное сочетание ролей).
Сразу скажу, что к теме SOD-конфликтов мы подошли в первом приближении, т.к. это отдельная большая активность со своим собственным процессом. Запрет на сочетание определенных полномочий может устанавливаться как в рамках отдельной роли, так и между ролями, и в кроссистемных взаимодействиях. Кроме того, важна настройка процесса работы с SOD- конфликтами и разработка сценариев реагирования на них. Это тема для отдельного рассмотрения.
Для тех систем, в которых много пользователей и структура прав довольно разнообразная, составить матрицу в ручном режиме очень непросто. Мы использовали для этих целей специализированные инструменты построения ролевой модели Role mining. Инструменты эти могут сильно отличаться логикой работы, стоимостью, удобством использования и другими характеристиками. Но принцип работы и цели у них общие — это сбор информации о текущих правах сотрудника в информационных системах, анализ повторяемости этих прав для сотрудников с одинаковыми атрибутами, объединение этих прав в роли и, в конечном итоге, построение некой базовой ролевой модели, которая отражает текущее положение дел.
Сейчас, по прошествии времени и работая в компании, которая разрабатывает ПО для управления доступом, я понимаю, что есть и более эффективные методы построения ролевых моделей в крупных системах. Чем раньше организация придет к использованию автоматизированных средств для наведения порядка, тем более гладко и безболезненно пройдёт процесс построения ролевых моделей. В этом случае автоматизированная система будет помощником или подспорьем в построении ролей. Внедрение автоматизированных систем управления доступом (IdM/IGA) нужно начинать с подключения кадровых источников и целевых систем для выгрузки данных и их мапинга и анализа. Используя специализированные инструменты, встроенные в решения по управлению доступом, можно с самого начала достаточно эффективно выстроить нужные процессы на основе автоматизации. Это значительно сократит трудозатраты и исключит шоковую терапию в будущем. Например, гораздо быстрее и эффективнее пройдёт процесс работы с учётными записями, а именно на первом этапе:
- блокировка найденных нелегитимных учётных записей,
- выявление бесхозных учёток,
- выявление и регистрация учётных записей внешних сотрудников и т.п.
- автоматизация создания учётных записей при приёме сотрудника на работу и блокировка учётных записей при увольнении.
А уже на втором этапе использование автоматизированных систем управления доступом позволяет повысить эффективность работы с правами пользователей и построить ролевую модель, в частности:
- применить различные методики сравнения прав у разных пользователей,
- осуществлять автоматизированный Role mining и выявление совпадающих прав для отдельных категорий пользователей с последующим анализом и согласованием. Так гораздо быстрее и проще создаются необходимые матрицы прав доступа.
Претворяем в жизнь новый регламент прав доступа
Мы добрались до того момента, когда в компании можно начинать жить по новому регламенту управления доступом: предоставлять доступ, изменять и аннулировать с учетом его новой структуры. Что должно быть в этом регламенте:
- Права доступа определяются наличием / отсутствием ролевой модели по конкретной информационной системе. Как говорилось выше, выстроить ролевые матрицы сразу по всем ИС просто невозможно, нужно действовать постепенно, в соответствии с утверждённым планом.
- Если утверждённой ролевой модели пока в системе нет, то права, как минимум, должны быть согласованы с руководителем подразделения и владельцем ресурса.
- Если ролевая модель разработана и утверждена, то права назначаются/изменяются на её основе.
- Должен быть определён порядок согласования, предоставления и аннулирования нестандартных прав.
В любом процессе есть исключения и ограничения. Поэтому необходимо учесть взаимозаменяемость сотрудников в период отсутствия, незаполненные вакансии, а также отдельные функциональные роли, которые предоставляются по запросам.
Однако и в случае с исключениями необходим строгий порядок и контроль персональной авторизации. Во-первых, она должна быть обоснована и согласована в соответствии с утверждённым регламентом.
Во-вторых, по тем правам, которые предоставляются на время, должна быть разработана процедура их своевременного отзыва. Здесь также очень помогут IdM/IGA-системы, которые позволяют заложить и автоматизировать маршруты согласования нестандартных прав, реализовать процедуру автоматического прекращения доступа по истечение заданного срока. А отчётность, которую можно настроить в системе, позволит регулярно анализировать и оценивать ситуацию с персональными правами. Если таких прав становится слишком много, то есть повод пересмотреть подход совместно с владельцем ресурса и доработать стандартные роли. Ведь судя по всему, они перестали обеспечивать потребности сотрудников, и их необходимо дополнить нужными правами для выполнения функционала в полном объеме. - В регламенте нужно закрепить порядок предоставления и аннулирования доступа к информационным системам внешним сотрудникам. По таким категориям сотрудников надо вести отдельный контроль, т.к. они отсутствуют в кадровом источнике и информация о них, как правило, фиксируется в отдельных списках чуть ли не вручную или не фиксируется вообще. Если же в компании уже применяется автоматизированная система управления доступом, то она является общим справочником по всем работникам, использующим ресурсы компании. В этом случае внешние сотрудники просто не смогут получить доступ к ресурсам компании в обход нее. Кроме того, по истечении договора подряда доступ будет своевременно заблокирован в автоматическом режиме.
Актуализация ролевой модели
Ролевая модель не может быть статичной. Она, как живой организм, должна адаптироваться под происходящие в организации изменения. Что служит поводом для её корректировки?
Первое – это изменение организационно-штатной структуры. В крупных организациях, в этом я убедилась на собственном опыте, такие изменения могут происходить практически ежедневно. Часто изменения связаны с переименованием подразделений и должностей. При этом функционал остаётся прежним, но, тем не менее, эти изменения должны отражаться в ролевой модели и все корректировки должны вноситься своевременно. Когда же происходит слияние подразделений или, наоборот, деление на отдельные группы/отделы, то изменения более глобальны. Они затрагивают функционал работников, который нужно пересмотреть, актуализировать функциональную модель и на её основе внести изменения в существующие роли. Или же разработать и внедрить новые роли в ролевую модель.
Второе – это изменение бизнес-процессов компании. Бизнес не может быть статичным: внедряются новые процессы и механизмы, которые позволяют совершенствовать работу каждого подразделения. Это улучшает обслуживание клиентов, повышает продажи, помогает достичь стратегических целей. Внедрение каждого нового бизнес-процесса должно учитываться в ролевой модели. Появятся новые роли, или же придется доработать имеющиеся, – и в них нужно будет включить новые опции и права.
Третье – это изменение системной архитектуры. На предприятиях периодически происходит вывод из эксплуатации старых систем и ввод в эксплуатацию новых. Допустим, старая система выводится из эксплуатации и функционал, который в ней выполняли сотрудники, должен быть переведён в новую систему. Для этого придётся провести ревизию всех ролей старой системы и их актуальности, проанализировать созданные роли новой системы и сделать матрицу сопоставления старых и новых ролей. Вполне возможно, что на какой-то переходный период эти роли будут существовать параллельно, пока весь нужный функционал не перенесут в новую систему и ролевая модель не будет доработана. Затем использование ролей старой системы можно будет прекратить, доступ пользователей аннулировать, а данные старой системы отправить в архив.
Все рассмотренные изменения говорят о том, что для поддержания актуальности ролевой модели нужен отдельный процесс. В нем следует учесть все активности организации, связанные с доступом к информационным ресурсам. Он должен включать процедуру обновления ролевой модели, которая планируется заранее, чтобы все необходимые изменения были сделаны вовремя. Это и инициирование заявки на изменение роли/ролей в автоматическом или ручном режиме, и согласование, и утверждение изменений и их ввод в эксплуатацию с актуализацией смежных процессов. Всё это должно быть зафиксировано в регламенте по ведению и обновлению ролевой модели, где также необходимо указать ответственных за каждый шаг процесса.
Помимо изменений в ролевой модели на основании вышеописанных причин нужен систематический плановый пересмотр прав. В частности, для финансовых компаний таких регулярных пересмотров требуют надзорные органы. Пересмотры позволяют выявлять недочёты в существующей модели прав и повышать контроль за полномочиями пользователей. Решение этой задачи значительно упрощают IGA/IdM-системы, которые позволяют автоматизировать процесс пересмотра (ресертификации) с заданной периодичностью.
Подведём итоги
Управление доступом с использованием ролевой модели повышает уровень информационной безопасности компании, т.к. доступ становится более прозрачным, управляемым и контролируемым. А также снижает нагрузку на подразделение ИТ в части его администрирования. Что станет делать проще с помощью ролевого управления доступом?
- Вы сможете предоставлять одинаковые права многим сотрудникам, занимающим одинаковую должность или работающим в одном подразделении. Достаточно предоставить им одну и туже роль.
- Вы сможете менять права для сотрудников одной должности быстро, в несколько кликов. Достаточно добавить или удалить права в составе общей роли.
- Вы сможете строить иерархию ролей и устанавливать правила наследования полномочий, что упрощает структуру доступа.
- Вы сможете вводить разграничения полномочий (SOD) – запрет на сочетание одной роли с другой.
Однако одним лишь построением ролевой модели не решить вопрос качественного и эффективного управления доступом в большой компании – это только один из шагов. Если построить ролевую модель и на этом успокоиться, через какое-то время она устареет, и грандиозная проделанная работа окажется абсолютно бесполезной. Почему?
- Права по-прежнему будут выдаваться и аннулироваться в ручном режиме, отнимая много времени и ресурсов, а ошибки из-за человеческого фактора никуда не уйдут.
- Бизнес-подразделения будут простаивать в ожидании доступа, упуская часть бизнес-возможностей.
- Аудиты доступа в ручном режиме будут отнимать много времени и их эффективность будет крайне низкой.
- Cогласование заявок будет трудозатратным.
- Статичная ролевая модель, существующая на бумаге или в отдельном файле, быстро потеряет актуальность, появится накопление излишних прав и несанкционированный доступ.
- Поиск информации и расследование инцидентов будут непосильной задачей.
Все перечисленные причины говорят о том, что важен именно комплекс мероприятий по управлению доступом. Нужны средства автоматизации, работающие процессы и механизмы, их поддержка, развитие, обновление и масштабирование в соответствии с жизненным циклом компании.
Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights
