Как разграничить права доступа в корпоративной системе бюджетирования?
Внедрение ABAC
В программном комплексе «Форсайт. Аналитическая платформа» внедрен и поддерживается новый подход к контролю доступа под названием ABAC (Attribute-based access control - управление доступом на основе атрибутов).
Необходимость поддержки данного подхода обусловлена все новыми и новыми вызовами как со стороны бизнес-планирования, так и со стороны безопасности работы с информацией, когда традиционных методов и подходов становится недостаточно.
Если сравнивать подходы ABAC и традиционный DAC (Discretionary access control – дискреционное управление доступом), то в последнем управление доступом субъектов к объектам осуществляется на основе списков управления доступом. ABAC же предлагает расширить эти возможности, используя атрибуты (можно рассматривать как метаданные) субъектов, объектов и среды окружения для «тонкой» фильтрации данных и предоставления к ним доступа.
Чтобы было проще понять различие этих двух подходов, приведем пример из реальной жизни.
Если компания небольшая и число сотрудников мало, то, как правило, хватает подхода DAC. Достаточно предоставить субъекту набор разрешений для доступа к объекту. Администратор с такой задачей справится без проблем.
Но компания растет, число сотрудников увеличивается, появляются определенные бизнес-правила и новые задачи для администратора:
- каждый сотрудник должен выполнять только свою определенную работу;
- каждый сотрудник должен видеть только свои данные;
- у каждой задачи должен быть ответственный за ее выполнение сотрудник;
- сотрудник может видеть данные только при выполнении определенных условий.
Если не решать эти проблемы, то компания понесет финансовые и иные потери в связи с утечкой информации, неэффективной работой кадров и администратора и другими нарушениями.
Чтобы решить такие задачи, необходимо четко разграничить доступ и понимать, кто и что хочет сделать и может ли он это сделать в определенных условиях. Подход ABAC как нельзя лучше подходит для этого.
В ABAC разграничение доступа происходит на основе вычисления политик и правил, которые содержат набор условий для проверки атрибутов. В правилах прописываются атрибуты с их значениями, условия и эффект – разрешить или запретить доступ к объекту, действие над ним.
Основное отличие подхода ABAC от подхода DAC в том, что каждая ситуация оценивается не с точки зрения роли пользователя и действия, которое он хочет/может совершить, а с точки зрения атрибутов, которые к ним относятся. А бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям.
Когда используется подход ABAC, то перед совершением пользователем определенного действия система проверяет возможность выполнения этого действия через запрос. Проверка возможности выполнения начинается с получения всех атрибутов, загрузки политик и правил. После проверки вычисляются значения всех атрибутов, указанных в политиках и правилах. Наборы политик фильтруются по значениям атрибутов в зависимости от текущего запроса. В дальнейшем вычисляются только отфильтрованные политики и правила. В результате итогового вычисления политик и правил будет получено решение о предоставлении пользователю доступа к объекту или действию над ним.
В программном комплексе «Форсайт. Аналитическая платформа» атрибутный доступ рассматривается как отдельный вид управления доступом наряду с дискреционным и мандатным.
При реализации данного подхода используются следующие группы атрибутов:
1. Атрибуты объектов (атрибуты, содержащиеся в объектах):
2. Атрибуты субъектов (атрибуты пользователей или групп пользователей):
Также у администратора есть возможность создавать уникальные пользовательские атрибуты в любой из этих двух групп. Выглядеть они могут следующим образом:
или
3. Атрибуты среды окружения:
Все эти атрибуты можно использовать при настройке политик и правил для разграничения доступа по методу ABAC.
Пользовательский интерфейс
В менеджере безопасности имеется раздел «Атрибутный доступ», где происходит создание и настройка ABAC-правил.
Ниже показан интерфейс пользователя в разделе менеджера безопасности «Атрибутный доступ».
В левой части расположено дерево наборов и политик, в правой части расположены правила и инструменты для их настройки.
Порядок работы с разделом следующий:
- сначала создается набор;
- в наборе создается политика;
- в политике создается правило.
Наборов, политик и правил может быть несколько, в зависимости от задачи.
Такая иерархическая структура позволяет разграничить доступ на разных уровнях, либо группировать настройки для удобства использования.
В диалоге-редакторе правил задаются настройки с помощью указания атрибутов и их значений.
Для набора политик, политики и правила задается цель, где может быть указан атрибут в виде простого логического выражения.
Для правила имеется дополнительное поле «Условие», где можно задать более сложное логическое, динамически вычисляемое выражение, которое может быть необходимо для задания каких-либо дополнительных условий на атрибуты. Оно задается с помощью универсального редактора формул.
У каждого правила есть поле «Эффект», которое может принимать значения «Разрешить» или «Запретить». Эффект сработает только в случае положительного вычисления правила. Иными словами, эффект будет применяться только в случае, когда результатом вычисления логического условия в цели и в условии будет «истина».
Пример работы подхода ABAC
В качестве примера приведем кейс в рамках работы с продуктом «Форсайт. Бюджетирование».
Программный продукт «Форсайт. Бюджетирование» предназначен для комплексной автоматизации задач планирования и бюджетирования в компаниях с различной отраслевой направленностью и сложностью организационной структуры. С его помощью формируются, согласуются и утверждаются различные наборы данных на разных уровнях бюджетной модели.
Для моделирования бизнес-процессов и их выполнения используется инструмент «Управление бизнес-процессами». Данный инструмент является расширением платформы и предназначен для визуального моделирования бизнес-процессов, их выполнения и мониторинга.
В определенный момент в компании появляется бизнес-задача: разграничить права пользователей при работе с данными в зависимости от функциональных ролей и с учетом организационных прав пользователей (в зависимости от того, в какую организационную группу входит пользователь: группа компаний, холдинг, юридическое лицо и т.п.). Пользователь должен входить в определенные функциональные группы, которые предоставляют ему права на бизнес-срезы данных (далее «сегменты данных»).
Сегмент данных, представляющий собой срез куба, зафиксированный по нескольким измерениям, является наименьшей информационной единицей, для которой могут быть определены права доступа.
В системе существует класс объектов – «сегмент куба» с заранее созданными атрибутами (отметим сразу, что значения по умолчанию не задаются):
- READ – атрибут, в значении которого указываются группы пользователей, которые получат право на чтение сегмента;
- WRITE – атрибут, в значении которого указываются группы пользователей, которые получат право на запись сегмента.
Более подробно об атрибутах расскажем ниже.
Будем считать, что у пользователя изначально нет прав ни на чтение, ни на запись, он не видит никаких данных в документе.
Чтобы предоставить пользователю права на чтение и запись определенных данных, необходимо создать объект полномочий и ABAC-правило.
Объект полномочий
Объект полномочий используется для выбора пользователей/групп пользователей, типа прав доступа (чтение/чтение и запись) и задания сегмента данных, на которые указанные пользователи будут иметь выбранные права. Кроме того, с помощью объекта полномочий настраиваются права пользователей, действующие в рамках выполнения отдельных шагов процесса.
Настройка объекта полномочий производится следующим образом:
1. Задаются статические и динамические права доступа к информационным объектам.
Статические права доступа к сегменту действуют постоянно на протяжении всего времени работы пользователя с источником данных. Статические права доступа определяются при создании и настройке объектов полномочий и задают статические сегменты данных, которые создаются в контейнере сегментов.
Динамические права доступа к сегменту раздаются только во время выполнения отдельных этапов бизнес-процессов. При этом на время выполнения этапов в контейнере сегментов создаются динамические сегменты данных.
На этом шаге указываются необходимые группы и пользователи, которым необходимо предоставить права на чтение и запись.
2. На втором шаге создания объекта полномочий выделяется сегмент данных, к которому необходимо предоставить доступ. Указывается источник данных и настраивается необходимая отметка.
3. После создания объекта полномочий для источника данных создается контейнер сегментов, в котором будут находиться сегменты, соответствующие отметке объекта полномочий.
Тем самым источник данных разбивается на отдельные информационные единицы – каждая со своим набором прав доступа для выбранных пользователей.
После создания объекта полномочий для каждого сегмента данных (в зависимости от настроек) автоматически задаются значения атрибутов.
Как мы уже говорили, в системе существует класс объектов – сегмент куба, для которого мы определили два атрибута: READ и WRITE. Вот для этих атрибутов объект полномочий и задает значения.
Например, у «Сегмента данных A» атрибуты приняли следующие значения:
READ = Группа 1
WRITE = Группа 4
Это означает, что право на чтение «Сегмента данных A» имеют пользователи из Группы 1, право на запись — пользователи из Группы 4.
ABAC-правило
Далее необходимо создать ABAC-правило для предоставления пользователям прав на чтение и запись данных с учетом атрибутов сегментов.
В правиле должна проводиться проверка атрибутов сегментов и проверка на вхождение пользователя в функциональные группы.
Рассматривая наш пример, получается, что если пользователь входит в какую-либо группу и эта группа прописана в атрибуте сегмента данных, то он получает право на чтение или запись данных в данном сегменте.
ABAC-правило выглядит следующим образом:
В параметрах набора указан атрибут OBJECT.CLASS = 1295.
Это означает, что правило будет применимо только к сегментам кубов (код класса объектов 1295).
В наборе созданы две политики.
1. Политика «Чтение» содержит правило для предоставления права на чтение.
В параметрах политики указан атрибут OPERATION IN 2.
Это означает, что данная политика будет предоставлять пользователю право на чтение (код операции 2).
В политике создано правило, где указано условие и эффект его применения.
Условие ABAC.INTERSECC("NAME",SUBJECT.GROUPS,OBJECT.READ) означает, что происходит проверка пересечения наименования группы пользователя (SUBJECT) с наименованием группы, указанной в атрибутах объектов (OBJECT).
Соответственно, если группа, в которую входит пользователь, указана в атрибуте объекта (сегмента), то пользователь получает право чтения данных в этом определенном сегменте куба.
2. Политика «Запись» содержит правило для предоставления права на запись.
В параметрах политики указан атрибут OPERATION IN 4.
Это означает, что данная политика будет предоставлять пользователю право на запись (код операции 4).
В политике создано правило, где указано условие и эффект его применения.
Условие ABAC.INTERSECC("NAME",SUBJECT.GROUPS,OBJECT.WRITE) означает, что происходит проверка пересечения наименования группы пользователя (SUBJECT) с наименование группы в атрибутах объектов (OBJECT).
Соответственно, если группа, в которую входит пользователь, указана в атрибуте объекта (сегмента), то пользователь получает право на запись данных в этом определенном сегменте куба.
С учетом созданного объекта полномочий и по результатам вычисления ABAC-правил пользователь получает права на чтение или запись в определенном сегменте куба.
Бизнес-процесс
Подобным образом также предоставляются и права на чтение и запись сегментов куба при выполнении этапов бизнес-процесса.
К шагу бизнес-процесса привязывается объект полномочий, который параметризуется параметрами процесса.
При создании такого объекта полномочий указываются динамические права доступа.
В момент выполнения определенного шага система сгенерирует динамический сегмент, который будет описывать срез данных, соответствующий объекту полномочий. Наличие данного сегмента должно обеспечить пользователю кратковременное право на чтение или запись. После завершения шага динамический сегмент будет удален.
Заключение
В рамках продукта «Форсайт. Бюджетирование» используется новый инструментарий сегментов и ABAC-правил, которые интегрированы в бюджетную модель и предоставляют пользователям возможность получать права на чтение и запись вне и в рамках бюджетного процесса с помощью формирования статических и динамических сегментов.
Подход ABAC позволяет более гибко решать сложные задачи администрирования, используя весь арсенал доступных атрибутов.