Получить консультацию по Solar inRights

Представьте картину. В компании 500 пользователей и 3 информационные системы (далее – ИС), которыми пользуются все (например, CRM, RDP, корпоративная почтовая система). Получается, что на каждого из 500 сотрудников приходится по 3 учетные записи. А на всю компанию их 1500. При этом в каждой из информационных систем у каждого сотрудника свои привилегии. В среднем в современной компании их количество – 5–7. Итого получаем от 7500 до 10 500 назначенных привилегий, которыми нужно управлять, следить за ними. А если количество пользователей вырастет до нескольких тысяч? А если специфика компании предполагает ведение различных внутренних проектов и нерегулярной деятельности? Это, как правило, сопровождается назначением сотрудникам каких-то дополнительных привилегий, прав иди доступов. Их зачастую после завершения проекта никто обратно не отзывает. Получается, сотрудник «обрастает» правами, их количество нарастает подобно снежному кому. Контролировать все это и грамотно управлять учетными записями становится сложнее, особенно вручную (как это реализовано во многих компаниях).

Решение проблемы – внедрение корпоративной системы управления учетными данными, опирающейся на ролевую модель (Role-Based Access Control – RBAC). Именно она лежит в основе решений класса IdM/IAM, которые помогают компаниям выстраивать эффективные и удобные процедуры исполнения регламентов, а также обеспечить профилактику и расследование инцидентов в сфере информационной безопасности (далее – ИБ), связанных с правами доступа и учетными записями.

Суть управления доступом пользователей и учетными записями на основе RBAC и эффекты от внедрения

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

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

Что дает бизнесу создание системы управления учетными записями на основе ролевой модели

Корпоративное управление учетными записями на основе RBAC дает бизнесу следующие преимущества:

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

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

  • Возможность реализации «принципа наименьшей привилегии». Пользователи регистрируются в системе с минимальным набором ролей, предоставляющих им необходимые доступы/права/привилегии.

  • Удобная и простая реализация разделения обязанностей между сотрудниками и предотвращение SOD-конфликтов. RBAC позволяет эффективно выявлять избыточные права и противостоять инцидентам в области ИБ, обусловленные ими (например, когда полномочия на создание и подтверждение платежа предоставляются одному и тому же работнику).

  • Повышение операционной эффективности и ускорение процессов добавления/удаления прав доступа для новых пользователей корпоративных ИС (в том числе и внешних).

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

А что насчет других моделей?

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

Например, при небольшом количестве сотрудников (до 100 человек) и корпоративных ИС с задачами обеспечения безопасного управления учетными записями успешно справляется дискреционная модель (DAC). Подтверждение этому – использование DAC в операционных системах Windows и Linux. Пользователей в них, как правило, не много, и смысла во внедрении более сложных подходов нет.

Мандатную модель (MAC) можно охарактеризовать как электронную реализацию бумажного секретного документооборота. Здесь оперируют уровнями доступа на основе мандатных меток, которые присваиваются объектам информации и субъектам, работающим с ней. Модель также довольно проста в реализации. Но с гибкостью есть проблемы. Ее использование затруднено в сложных разветвленных инфраструктурах с множеством разноплановых подразделений.

Часто компании используют совместно разные модели управления учетными записями и доступом к ресурсам ИС. Причем RBAC может выступать в роли базиса для развертывания систем с элементами MAC или DAC. Однозначно сказать, какой именно из этих вариантов лучше, нельзя. Все зависит от особенностей компании, перед внедрением какой-либо из этих моделей требуется провести тщательный анализ и уже на основе его результатов делать выводы.

ДРУГИЕ СТАТЬИ ПРОДУКТА

Еще больше о наших возможностях

Как создать модель управления доступом, которая соответствует требованиям безопасности и нуждам бизнеса?

Как создать модель управления доступом, которая соответствует требованиям безопасности и нуждам бизнеса?

Узнать больше
Как обеспечить безопасность паролей и как часто нужно их менять?

Как обеспечить безопасность паролей и как часто нужно их менять?

Узнать больше
Регламент предоставления доступа к информационным ресурсам

Регламент предоставления доступа к информационным ресурсам

Узнать больше