Role based access control что это
Что такое управление доступом на основе ролей в Azure (RBAC)?
Управление доступом к облачным ресурсам является критически важной функцией в любой организации, использующей облако. Управление доступом на основе ролей Azure (RBAC Azure) позволяет управлять доступом пользователей к ресурсам Azure, включая настройку разрешений на выполнение операций с этими ресурсами и определение областей доступа.
RBAC Azure — это система авторизации на основе Azure Resource Manager, которая обеспечивает широкие возможности управления доступом к ресурсам Azure.
В этом видео представлен краткий обзор Azure RBAC.
Какие возможности обеспечивает RBAC Azure?
Вот примеры того, что можно выполнять с помощью RBAC Azure:
Принцип работы RBAC Azure
Для управления доступом к ресурсам с помощью Azure RBAC создаются назначения ролей. Это важнейшее понятие. Именно таким образом предоставляются разрешения. Назначение ролей состоит из трех элементов: субъект безопасности, определение роли и область действия.
Субъект безопасности
Субъект безопасности — это объект, представляющий пользователя, группу, субъект-службу или управляемое удостоверение, которые запрашивают доступ к ресурсам Azure. Любому из этих субъектов безопасности можно назначить роль.
Определение роли
Определение роли представляет собой коллекцию разрешений. Обычно это называется ролью. В определении роли перечисляются действия, которые можно выполнить, например чтение, запись и удаление. Роль может быть общей, например «Владелец», или более конкретной, например «Модуль чтения виртуальной машины».
В Azure есть несколько встроенных ролей. Например, роль Участник виртуальных машин позволяет пользователю создавать виртуальные машины и управлять ими. Если встроенные роли не соответствуют потребностям вашей организации, вы можете создать собственные настраиваемые роли Azure.
В этом видео представлен краткий обзор встроенных и настраиваемых ролей.
Azure предоставляет действия с данными, которые позволяют предоставлять доступ к данным в объекте. Например, если у пользователя есть доступ на чтение данных в учетной записи хранения, это позволяет ему считывать большие двоичные объекты или сообщения в этой учетной записи.
Дополнительные сведения о ролях Azure см. в этой статье.
Область
Область — это набор ресурсов, к которым предоставляется доступ. При назначении роли можно точнее ограничить разрешенные действия, определив их область. Это удобно, если вы хотите привлечь какого-либо пользователя к работе над веб-сайтом, но только для одной группы ресурсов.
В Azure область действия можно задать на четырех уровнях: на уровне группы управления, уровне подписки, группы ресурсов или ресурса. Структура областей строится на отношениях «родитель-потомок». Вы можете назначать роли на любом из этих уровней области действия.
Дополнительные сведения об областях см. в статье Общие сведения об областях для Azure RBAC.
Назначения ролей
Назначение ролей — это процесс связывания определения роли с пользователем, группой, субъектом-службой или управляемым удостоверением в определенной области в целях предоставления доступа. Доступ предоставляется путем создания назначения ролей, а отзывается путем его удаления.
На приведенной ниже схеме показан пример назначения ролей. В этом примере группе «Маркетинг» назначена роль Участник для группы ресурсов «Продажи медицинских препаратов». Это означает, что пользователи из группы «Маркетинг» могут создавать ресурсы Azure в группе ресурсов «Продажи медицинских препаратов» или управлять любыми такими ресурсами. Пользователи в группе «Маркетинг» не имеют доступа к ресурсам за пределами группы ресурсов «Продажи медицинских препаратов», если они не имеют других назначений ролей.
Назначать роли можно с помощью портала Azure, Azure CLI, Azure PowerShell, пакетов SDK Azure или REST API.
Дополнительные сведения см. в статье Шаги по добавлению назначения роли.
Группы
Назначения ролей являются транзитивными для групп. Это означает, что если пользователь является членом группы, а эта группа является членом другой группы, имеющей назначение ролей, то пользователь будет иметь разрешения в назначении ролей.
Несколько назначений ролей
Что произойдет, если у вас будет несколько перекрывающихся назначений ролей? RBAC Azure — это аддитивная модель, поэтому ваши действующие разрешения являются сочетанием назначений ролей. Рассмотрим следующий пример, где пользователю предоставляется роль участника на уровне подписки и роль читателя для группы ресурсов. Сочетание разрешений участника и разрешений читателя, по сути, представляет собой роль участника для подписки. Следовательно, в этом примере назначение роли читателя не играет роли.
Запрет назначений
Раньше RBAC Azure была разрешающей моделью без запретов, но теперь она ограниченно поддерживает запрет назначений. Запрет назначений, как и назначение ролей, связывает набор запрещающих действий с пользователем, группой или субъектом-службой в определенной области для отказа в доступе. Назначение роли определяет набор допустимых действий, а назначение запрета определяет набор недопустимых действий. Другими словами, запрет назначений блокирует выполнение определенных действий пользователями, даже если назначение роли предоставляет им доступ. Запрет назначений имеет приоритет над назначением ролей.
Дополнительные сведения о запретах назначений Azure см. в этой статье.
Как RBAC Azure определяет право доступа пользователя к ресурсу
Ниже перечислены основные действия, выполняемые RBAC Azure для определения того, есть ли у вас доступ к ресурсу. Эти действия относятся к Azure Resource Manager или службам плоскости данных, интегрированным с Azure RBAC. Это полезно, если вы пытаетесь устранить проблему с доступом.
Пользователь A (или директор службы) приобретает токен для Azure Resource Manager.
Токен включает членство в группе пользователей (включая переходные членства в группах).
Пользователь выполняет вызов REST API в Azure Resource Manager с помощью присоединенного токена.
Azure Resource Manager извлекает все назначения ролей и запрет назначений, которые применяются к ресурсу, на котором выполняется действие.
Если применяется запрет назначения, доступ блокируется. В противном случае вычисление продолжается.
Azure Resource Manager сужает назначенные роли, которые применяются к этому пользователю или группе, и определяет, какие роли у пользователя есть для этого ресурса.
Если у пользователя нет роли с действием в запрашиваемой области, доступ не предоставляется. В противном случае оцениваются все условия.
Если назначение роли включает условия, они оцениваются. В противном случае доступ разрешен.
Если условия соблюдены, доступ разрешен. В противном случае доступ запрещен.
На следующей схеме представлены сводные сведения о логике оценки.
Требования лицензий
Эта функция бесплатна и доступна в вашей подписке Azure.
Управление доступом на основе ролей
Содержание
Введение [ ]
Не смотря на то, что Роль является совокупностью прав доступа на объекты компьютерной системы, ролевое управление доступом отнюдь не является частным случаем избирательного управления доступом, так как его правила определяют порядок предоставления доступа субъектам компьютерной системы в зависимости от имеющихся (или отсутствующих) у него ролей в каждый момент времени, что является характерным для систем мандатного управления доступом. С другой стороны, правила ролевого разграничения доступа являются более гибкими, чем при мандатном подходе к разграничению.
Так как привилегии не назначаются пользователям непосредственно, и приобретаются ими только через свою роль (или роли), управление индивидуальными правами пользователя по сути сводится к назначению ему ролей. Это упрощает такие операции, как добавление пользователя или смена подразделения пользователем.
История [ ]
Элементарные формы модели RBAC были осуществлены во множестве специальных форм на многих системах, начиная с 1970-х годов. Контроль доступа на основе ролей, используемый в настоящее время происходит из модели, предложенной Ферраильо ( англ. Ferraiolo ) и Куном ( англ. Kuhn ) (1992) и как образцовая модель позже усовершенствованная Санди ( англ. Sandhu ), Койн, Фейнштейн, и Йоман (1996).
Базовая модель RBAC [ ]
Для определения модели RBAC используются следующие соглашения:
На возможность наследования разрешений от противоположных ролей накладывается ограничительная норма, которая позволяет достичь надлежащего разделения режимов. Например, одному и тому же лицу может быть не позволено создать учетную запись для кого-то, а затем авторизоваться под этой учетной записью.
Используя нотацию теории множеств :
Обозначение: x ≥ y означает, что x наследует разрешения y.
Субъект может иметь множество одновременных сессий с различными разрешениями.
Возможности и применение [ ]
До разработки RBAC, единственными известными моделями управления доступом были MAC и DAC: если модель была не MAC, то она была DAC, и наоборот. Исследования в 90-х показали, что RBAC не попадает ни в ту, ни в другую категорию.
Роли создаются внутри организации для различных рабочих функций. Определенным ролям присваиваются полномочия (permissions) для выполнения тех или иных операций. Штатным сотрудникам (или другим пользователям системы) назначаются фиксированные роли, через которые они получают соответствующие привилегии для выполнения фиксированных системных функций. В отличие от управления доступом на основе контекста ( англ. context-based access control, CBAC ), реализация RBAC в чистом виде не принимает во внимание текущую ситуацию (такую как, например, откуда было установлено соединение).
RBAC отличается от списков контроля доступа ( англ. access control lists, ACL ), используемых в традиционных избирательных системах управления доступом, тем, что может давать привилегии на сложные операции с составными данными, а не только на атомарные операции с низкоуровневыми объектами данных. Например, список контроля доступа может предоставить или лишить права записи в такой-то системный файл, но он не может ограничить то, каким образом этот файл может быть изменен. Система, основанная на RBAC, позволяет создать такую операцию как открытие «кредита» в финансовом приложении или заполнение записи «тест на уровень сахара в крови» в медицинском приложении. Присвоение привилегии на выполнение такой-либо операции многозначно, так как операции являются дробящимися в пределах приложения.
Концепции иерархии ролей и ограничений позволяют создать или смоделировать контроль доступа на основе решетки ( англ. lattice-based access control, LBAC ) средствами RBAC. Таким образом, RBAC может быть основанием и расширением LBAC.
В организациях с разнородной IT-инфраструктурой, содержащих десятки и сотни систем и приложений, помогает использование иерархии ролей и наследования привилегий. Без этого использование RBAC становится крайне запутанным. В статье «Дополнительные роли: практический подход к обслуживанию пользователей предприятия» [5] обсуждаются стратегии, альтернативные большому масштабу присвоения привилегий пользователям.
Современные системы расширяют старую модель NIST [6] ограничениями RBAC для развертывания на больших предприятиях. Существует несколько академических документов и по меньшей мере одна коммерческая система — Beyond NIST.
Для больших систем с сотнями ролей, тысячами пользователей и миллионами разрешений, управление ролями, пользователями, разрешениями и их взаимосвязями является сложной задачей, которую нереально выполнить малой группой администраторов безопасности. Привлекательной возможностью является использование самой RBAC для содействия децентрализованному управлению RBAC.
Примечания [ ]
См. также [ ]
Ссылки [ ]
de:Role Based Access Control en:Role-based access control fr:Contrôle d’accès à base de rôles ja:ロールベースアクセス制御 nl:Role Based Access Control pl:Role-based access control vi:Điều khiển truy cập trên cơ sở vai trò
Строим ролевую модель управления доступом. Часть первая, подготовительная
Сейчас я работаю в компании-вендоре программного обеспечения, в частности решений по управлению доступом. А мой опыт «из прошлой жизни» связан со стороной заказчика – крупной финансовой организацией. Тогда наша группа по контролю доступа в ИБ-департаменте не могла похвастаться большими компетенциями в IdM. Мы многому обучались в процессе, пришлось набить кучу шишек, чтобы выстроить в компании работающий механизм управления правами пользователей в информационных системах. 
Объединив свой выстраданный в заказчике опыт с вендорскими знаниями и компетенциями, я хочу поделиться с вами по сути пошаговой инструкцией: как создать в крупной компании ролевую модель управления доступом, и что это даст на выходе. Моя инструкция состоит из двух частей: первая – готовимся строить модель, вторая – собственно строим. Перед вами часть первая, подготовительная.
N.B. Построение ролевой модели – это, к сожалению, не результат, а процесс. А точнее даже часть процесса созидания в компании экосистемы управления доступом. Так что настройтесь на игру вдолгую.
Сначала определимся – а что же такое управление доступом на основе ролей? Предположим, есть у вас крупный банк с десятками, а то и сотнями тысяч сотрудников (субъектов), у каждого из которых есть десятки прав доступа в сотни внутрибанковских информационных систем (объектов). А теперь умножьте число объектов на число субъектов – именно столько связей минимум вам нужно сначала выстроить, а потом контролировать. Реально это сделать вручную? Конечно нет – для решения этой задачи и появились роли.
Роль – это набор полномочий, который необходим пользователю или группе пользователей для выполнения определённых рабочих задач. Каждый сотрудник может иметь одну или несколько ролей, а каждая роль может содержать от одного до множества полномочий, которые разрешены пользователю в рамках этой роли. Роли могут быть привязаны к определённым должностям, подразделениям или функциональным задачам работников.
Роли обычно создаются из отдельных полномочий сотрудника в каждой информационной системе. Потом из ролей каждой системы формируются глобальные бизнес-роли. Например, бизнес-роль «кредитный менеджер» будет включать в себя несколько отдельных ролей в информационных системах, которые используются в клиентском офисе банка. Скажем, в таких, как основная автоматизированная банковская система, кассовый модуль, система электронного документооборота, сервис-менеджер и других. Бизнес-роли, как правило, привязываются к организационно-штатной структуре – проще говоря, к набору подразделений компании и должностей в них. Так формируется глобальная ролевая матрица (пример привожу в табличке ниже).
Стоит отметить, что построить 100% ролевую модель, обеспечив всеми необходимыми правами сотрудников каждой должности в коммерческой структуре просто невозможно. Да это и не нужно. Ведь ролевая модель не может быть статичной, потому, что она зависит от постоянно меняющегося окружения. И от изменения бизнес-деятельности компании, которое, соответственно, влияет на изменение оргструктуры и функционала. И от отсутствия полного обеспечения ресурсами, и от несоблюдения должностных инструкций, и от стремления к прибыли в ущерб безопасности, и от многих других факторов. Поэтому нужно строить ролевую модель, которая сможет закрыть до 80% потребностей пользователей в необходимых базовых правах при назначении на должность. А остальные 20% они смогут, если нужно, дозапрашивать позже по отдельным заявкам.
Конечно, вы можете спросить: «А что, вообще не бывает 100% ролевых моделей?» Ну почему же, такое встречается, например, в некоммерческих структурах, которые не подвержены частым изменениям, – в каком-нибудь НИИ. Или в организациях ВПК с высоким уровнем защищённости, где безопасность стоит на первом месте. Бывает, и в коммерческой структуре, но в рамках отдельно-взятого подразделения, работа которого является достаточно статичным и предсказуемым процессом.
Главный плюс ролевого управления – это упрощение выдачи прав, потому что количество ролей существенно меньше, чем пользователей информационной системы. Причем это справедливо для любой отрасли.
Возьмем ритейловую компанию: в ней трудятся тысячи продавцов, но набор прав в системе N у них одинаковый, и для них будет создана всего одна роль. Пришёл в компанию новый продавец – ему автоматически назначена нужная роль в системе, в которой уже есть все необходимые полномочия. Так же в один клик можно поменять права для тысячи продавцов разом, например, добавить новую опцию по формированию отчёта. Не нужно делать тысячу операций, привязывая новое право к каждой учётной записи – достаточно внести эту опцию в роль, и она появится у всех продавцов одновременно.
Еще одно преимущество ролевого управления – исключение выдачи несовместимых полномочий. То есть сотрудник, имеющий определённую роль в системе, не может одновременно иметь другую роль, права которой не должны сочетаться с правами в первой. Яркий пример – запрет на совмещение функций ввода и контроля финансовой операции.
Все, кому интересно, как вообще появилось ролевое управление доступом, могут
Если обратиться к истории, то впервые ИТ-сообщество задумалось о методах управления доступом ещё в 70-х годах XX века. Хотя приложения были тогда достаточно простыми, но, как и сейчас, всем очень хотелось удобно управлять доступом к ним. Предоставлять, менять и контролировать права пользователей – просто чтобы легче было понимать, какой доступ есть у каждого из них. Но в то время не существовало никаких общих стандартов, разрабатывались первые системы по управлению доступом, и каждая компания основывалась на свих собственных представлениях и правилах.
Сейчас уже известно много разных моделей управления доступом, но появились они не сразу. Остановимся на тех, которые внесли ощутимый вклад в развитие этого направления.
Первая и, наверное, самая простая модель – Дискреционное (избирательное) управление доступом (DAC – Discretionary access control). Эта модель подразумевает совместное использование прав всеми участниками процесса доступа. Каждый пользователь получает доступ к конкретным объектам или операциям. По сути здесь множество субъектов прав соответствует множеству объектов. Такая модель была признана слишком гибкой и слишком сложной для сопровождения: списки доступа со временем становятся огромными и трудно контролируемыми.
Вторая модель – это Мандатное управление доступом (MAC — Mandatory access control). По этой модели каждый пользователь получает доступ к объекту в соответствии с оформленным допуском к тому или иному уровню конфиденциальности данных. Соответственно объекты должны быть категорированы по уровню конфиденциальности. В отличие от первой гибкой модели, эта, наоборот, оказалась слишком строгой и ограничительной. Её применение не оправдывает себя, когда в компании множество разнообразных информационных ресурсов: чтобы разграничить доступ к разным ресурсам, придётся вводить множество категорий, которые не будут пересекаться.
В связи с очевидным несовершенством этих двух методов ИТ-сообщество продолжило разработку моделей, более гибких и при этом более-менее универсальных для поддержки разных типов организационных политик контроля доступа. И вот тогда появилась третья модель управления доступом на основе ролей! Этот подход оказался самым перспективным, поскольку он требует не только авторизации личности пользователя, но и его рабочих функций в системах.
Первую чётко описанную структуру ролевой модели предложили американские учёные Девид Феррайло и Ричард Кун из Национального института стандартов и технологий США в 1992 году. Тогда впервые появился термин RBAC (Role-based access control). Эти исследования и описания основных компонентов, а также их взаимосвязи легли в основу действующего по сей день стандарта INCITS 359-2012, утвержденного Международным комитетом по стандартам информационных технологий (INCITS).
Стандарт определяет роль как «должностную функцию в контексте организации с некоторой связанной семантикой в отношении полномочий и ответственности, возложенных на пользователя, назначенного на роль». Документ устанавливает основные элементы RBAC – пользователи, сессии, роли, разрешения, операции и объекты, а также отношения и взаимосвязи между ними.
В стандарте дана минимально необходимая структура для построения ролевой модели – объединение прав в роли и затем выдача доступа пользователям через эти роли. Обозначены механизмы составления ролей из объектов и операций, описаны иерархия ролей и наследование полномочий. Ведь в любой компании есть роли, объединяющие элементарные полномочия, которые необходимы всем сотрудникам компании. Это может быть доступ к электронной почте, к СЭД, к корпоративному порталу и т.п. Эти полномочия можно включить в одну общую роль под названием «сотрудник», и не нужно будет в каждой из ролей более высокого уровня перечислять все элементарные права раз за разом. Достаточно просто указать признак наследования роли «сотрудник».
Позже стандарт был дополнен новыми атрибутами доступа, связанными с постоянно меняющимся окружением. Добавилась возможность введения статических и динамических ограничений. Статические подразумевают невозможность совмещения ролей (тот самый ввод и контроль операций, упоминавшийся выше). Динамические ограничения могут определяться меняющимися параметрами, например, временем (рабочие/нерабочие часы или дни), местоположением (офис/дом) и т.п.
Отдельно стоит сказать про управление доступом на основе атрибутов (ABAC — Attribute-based access control). Подход строится на предоставлении доступа с помощью правил совместного использования атрибутов. Эта модель может использоваться отдельно, но довольно часто она активно дополняет классическую ролевую: к определённой роли можно добавлять атрибуты пользователей, ресурсов и устройств, а также времени или местоположения. Это позволяет использовать меньше ролей, вводить дополнительные ограничения и сделать доступ минимально достаточным, а, следовательно, повысить безопасность.
Например, бухгалтеру можно разрешить доступ к счетам, если он работает в определённом регионе. Тогда местоположение специалиста будет сравниваться с определённым эталонным значением. Или можно дать доступ к счетам, только если пользователь авторизуется с устройства, внесённого в реестр разрешённых. Хорошее дополнение к ролевой модели, но самостоятельно используется нечасто из-за необходимости создавать много правил и таблиц разрешений или ограничений.
Приведу пример применения ABAC из моей «прошлой жизни». В нашем банке было несколько филиалов. Сотрудники клиентских офисов в этих филиалах выполняли абсолютно одинаковые операции, но должны были работать в основной системе только со счетами своего региона. Сначала мы начали создавать отдельные роли для каждого региона – и таких ролей с повторяющимся функционалом, но с доступом к разным счетам получилось ну ооочень много! Тогда, использовав атрибут местоположения для пользователя и связав его с конкретным диапазоном счетов для проверки, мы значительно уменьшили количество ролей в системе. В результате остались роли только для одного филиала, которые тиражировались на соответствующие должности во всех остальных территориальных подразделениях банка.
А теперь поговорим о необходимых подготовительных шагах, без которых просто невозможно построить работающую ролевую модель.
Шаг 1. Создаем функциональную модель
Начать стоит с создания функциональной модели – верхнеуровневого документа, в котором подробно описан функционал каждого подразделения и каждой должности. Как правило, информация в него попадает из различных документов: должностных инструкций и положений по отдельным подразделениям – отделам, управлениям, департаментам. Функциональная модель должна быть согласована со всеми заинтересованными подразделениями (бизнес, внутренний контроль, безопасность) и утверждена руководством компании. Для чего нужен этот документ? Для того, чтобы ролевая модель могла на него ссылаться. Например, вы собираетесь строить ролевую модель на основе уже имеющихся прав сотрудников – выгруженных из системы и «приведённых к единому знаменателю». Тогда при согласовании полученных ролей с бизнес-владельцем системы можно сослаться на конкретный пункт функциональной модели, на основании которого в роль включается то или иное право.
Шаг 2. Аудируем ИТ-системы и составляем план приоритизации
На втором этапе следует провести аудит ИТ-систем, чтобы разобраться, как организован доступ в них. Например, в моей финансовой компании эксплуатировалось несколько сотен информационных систем. Во всех системах были некоторые зачатки ролевого управления, в большинстве – какие-то роли, но в основном на бумаге или в справочнике системы – они давно устарели, и доступ в них раздавался по фактическим запросам пользователей. Естественно, построить ролевую модель сразу в нескольких сотнях систем просто невозможно, надо с чего-то начинать. Мы провели углубленный анализ процесса управления доступом, чтобы определить уровень его зрелости. В процессе анализа выработали критерии приоритизации информационных систем – критичность, готовность, планы по выводу из эксплуатации и т.п. С их помощью выстроили очерёдность по разработке/актуализации ролевых моделей для этих систем. А затем – включили ролевые модели в план по интеграции с решением Identity Management, чтобы автоматизировать управление доступом.
Итак, как же определить критичность системы? Ответьте себе на следующие вопросы:
N.B. Крупные компании с развитыми ИТ-процессами наверняка знакомы с процедурой ИТ-аудита – IT general controls (ITGС), который позволяет выявить недостатки в ИТ-процессах и наладить контроль так, чтобы улучшить процессы в соответствии с best practice (ITIL, COBIT, IT Governance и др.) Такой аудит позволяет ИТ и бизнесу лучше понять друг друга и выработать совместную стратегию развития, проанализировать риски, оптимизировать затраты, выработать более эффективные подходы в работе.
Одним из направлений аудита является определение параметров логического и физического доступа к информационным системам. Полученные данные мы взяли за основу для дальнейшего использования при построении ролевой модели. В результате такого аудита у нас появился реестр ИТ-систем, в котором были определены их технические параметры и даны описания. Кроме того, для каждой системы был определён владелец от бизнес-направления, в интересах которого она эксплуатировалась: именно он отвечал за бизнес-процессы, которые эта система обслуживала. Также был назначен менеджер ИТ-службы, ответственный за техническую реализацию потребностей бизнеса в конкретной ИС. Были зафиксированы самые критичные для компании системы и их технические параметры, сроки ввода и вывода из эксплуатации и др. Эти параметры очень помогли в процессе подготовки к построению ролевой модели.
Шаг 3 Создаем методологию
Залог успеха любого дела – правильно выбранный метод. Поэтому и для построения ролевой модели, и для проведения аудита нам нужно создать методологию, в которой мы опишем взаимодействие между подразделениями, закрепим ответственность в регламентах компании и т.п.
Для начала нужно исследовать все имеющиеся документы, которые устанавливают порядок предоставления доступа и прав. По-хорошему, процессы должны быть документированы на нескольких уровнях:
По приказу руководства была создана рабочая группа, в которую вошли представители направлений безопасности, ИТ, бизнеса и внутреннего контроля. В приказе были обозначены цели создания группы, направление деятельности, срок существования и ответственные от каждой стороны. Кроме того, мы разработали методику проведения аудита и порядок построения ролевой модели: их согласовали все ответственные представители направлений и утвердило руководство компании.
Документы, описывающие порядок проведения работ, сроки, ответственность и т.д. – залог того, что на пути к заветной цели, которая вначале не всем очевидна, ни у кого не возникнет вопросов «а для чего мы это делаем, а зачем нам это надо и т.п.» и не будет возможности «соскочить» или затормозить процесс.
Шаг 4. Фиксируем параметры существующей модели управления доступом
Составляем так называемый «паспорт системы» в части управления доступом. По сути, это опросник по конкретной информационной системе, в котором зафиксированы все алгоритмы управления доступом к ней. Компании, которые уже внедряли у себя решения класса IdM, наверняка знакомы с подобным опросником, так как именно с него начинается исследование систем.
Часть параметров о системе и владельцах перетекла в опросник из реестра ИТ (см. шаг 2, аудит), но добавились и новые:
Шаг 5. Создаем бизнес-ориентированное описание полномочий
Ещё один документ, который нам понадобится при построении ролевой модели, – это справочник по всем возможным полномочиям (правам), которые можно предоставить пользователям в информационной системе с подробным описанием бизнес-функции, которая за этим стоит. Часто полномочия в системе зашифрованы определёнными наименованиями, состоящими из букв и цифр, и сотрудники бизнеса не могут разобраться, что кроется за этими символами. Тогда они идут в ИТ-службу, а там… тоже не могут ответить на вопрос, например, по редко используемым правам. Тогда приходится проводить дополнительное тестирование.
Хорошо, если бизнес-описание уже есть или даже есть объединение этих прав в группы и роли. Для некоторых приложений лучшей практикой является создание подобного справочника ещё на этапе их разработки. Но такое встречается нечасто, поэтому опять идём в ИТ-подразделение, чтобы собрать информацию обо всех возможных правах и их описать. Наш справочник в итоге будет содержать следующее:
Шаг 6 Выгружаем из систем данные о пользователях и правах и сопоставляем с кадровым источником
На заключительном этапе подготовки нужно выгрузить данные из информационных систем обо всех пользователях и правах, которые они имеют на текущий момент. Здесь возможны два сценария. Первый: у подразделения безопасности есть доступ напрямую в систему и есть средства выгрузки соответствующих отчётов, что бывает нечасто, но очень удобно. Второй: отправляем запрос в ИТ на получение отчётов в нужном формате. Практика показывает: договориться с ИТ и получить необходимые данные с первого раза не удаётся. Нужно сделать несколько подходов, пока информация будет получена в нужном виде и формате.
Какие данные необходимо выгрузить:
Затем, если у вас в компании нет автоматизированных средств закрытия доступа уволенным сотрудникам (такое нередко встречается) или есть лоскутная автоматизация, которая не всегда корректно срабатывает, нужно выявить все «мёртвые души». Речь об учётных записях уже уволенных сотрудников, права которых по какой-то причине не заблокированы, – их нужно заблокировать. Для этого сопоставляем выгруженные данные с кадровым источником. Кадровую выгрузку тоже нужно предварительно получить у подразделения, ведущего кадровую базу.
Отдельно необходимо отложить учётки, владельцы которых не нашлись в кадровой базе, не закреплённые ни за кем, – то есть бесхозные. По этому списку нам понадобится дата последнего использования: если она довольно свежая, то всё же придётся поискать владельцев. Сюда могут относиться аккаунты внешних подрядчиков или служебные учётки, ни за кем не закреплённые, но связанные с какими-либо процессами. Для выяснения принадлежности учёток можно разослать по всем подразделениям письма с просьбой отозваться. Когда владельцы найдутся, вносим данные о них в систему: таким образом все действующие учётки опознаны, а остальные блокируем.
Как только наши выгрузки очищены от лишних записей и остались одни активные учетки, можно приступать к построению ролевой модели по конкретной информационной системе. Но об этом я расскажу уже в следующей статье.
Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights