Бизнес-правила включают читаемые машинами базы данных, помогающие системе принимать решения и производить сложные расчеты во время автономного функционирования. Правила группируются в наборы правил. Все наборы правил полностью независимы друг от друга. Каждый набор включает одно и более правил, работающих в определенном порядке (см. Типы наборов правил).
Каждый набор правил может принимать определенные параметры, и его обработка всегда имеет результатом один объект (любого типа, т.е. число, строка или дата).
Компоненты правил
Каждое правило в наборе состоит из цели, выражения и условия. Кажде правило либо возвращает результат всего набора правил, либо (заново) определяет единую переменную среды, действительную до конца обработки набора правил. Также возможно добавлять комментарии к отдельным правилам.
Цель правил
Цель определяет, как обрабатывается результат набора правил. Если цель правила — это Финальный результат набора правил, это правило прекращает обработку набора правил и возвращает результат всего набора правил. В других случаях цель определяет название переменной среды, которое будет определяться, когда закончится обработка правил. На эту переменную можно сослаться из выражений и условий других правил.
Ошибка начинающих кондитеров ☺️
Выражение правил
- Возвращается как результат всего набора правил, если Цель правила — это Финальный результат набора правил.
- Хранится как переменная внутренней среды набора правил, переписывая значение этой переменной, если оно уже было определено другими правилами. Эта переменная среды будет действительна во время цикла обработки текущего набора правил.
Выражения правил могут ссылаться на результаты других правил из этого набора через ссылки .
Условие правил
Условие Правил — это выражение AggreGate, которое имеет результатом булевое значение. Если это значение false, обработка правила будет пропущена, и будут обрабатываться другие правила в соответствии с типом набора правил.
Обратите внимание, что незаполненные условия или условия, возвращающие NULL, будут иметь значение true .
Условия правил могут ссылаться на результаты других правил из этого набора через ссылки .
Условия правил опциональны.
Пример набора правил
Этот пример описывает простой последовательный набор правил, рассчитывающий нагрузку процессора хоста сети независимо от типа хоста и операционной системы.
Этот набор правил используется относительной моделью, прикрепленной к каждому хосту сети, и, таким образом, контекстом по умолчанию выражения и условия правил является контекст сетевого устройства, к которому он прикреплен.
Цель
Выражение
Условие
Комментарий
Результат финального набора правил
Источник: aggregate.digital
Как разграничить права доступа в корпоративной системе бюджетирования?
В программном комплексе «Форсайт. Аналитическая платформа» внедрен и поддерживается новый подход к контролю доступа под названием 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» атрибуты приняли следующие значения:
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 позволяет более гибко решать сложные задачи администрирования, используя весь арсенал доступных атрибутов.
Источник: www.fsight.ru
Decision-making
О парадоксах в менеджменте, в финансах, в математике, в физике, в жизни. . создано произволом творчества.
воскресенье, 17 мая 2020 г.
Бизнес-правила
Бизнес-правила описывают операции, определения и ограничения, которые применимы в организации. Бизнес-правила могут применяться к людям, процессам, корпоративному поведению, к вычислительным системам.
Бизнес-правило определяет элементы (можно сказать, аспекты) бизнес-процесса.
«Определяет» можно отождествить с определением области допустимых значений и условий выполнения, поэтому бизнес-правила ограничивает некоторые аспекты бизнес-процесса.
Бизнес-правило может быть структурировано так:
В противном случае
То есть, на выходе бизнес-правила булевое значение: истина или ложь.
Бизнес-правила описывают способ преобразования стратегии в действия и мероприятия. Поэтому сами по себе бизнес-правила не могут квалифицироваться как операционные или стратегические. Бизнес-правила — это просто директивы,
«Проверка кредита не должна выполняться для постоянных клиентов».
Или в формальной записи:
Нужно ли выполнять проверку кредита: Если клиент не относится к категории постоянных клиентов, то «TRUE», иначе «FALSE».
Бизнес-правила могут быть формальными или неформальными, задокументированными или н задокументированными.
В определенных условиях процесс описания и документирования бизнес-правил значим и важен для организации. А именно, если соблюдение бизнес-правил способствует достижению целей организаций, устраняет препятствия, уменьшает дорогостоящие и не очень дорогостоящие ошибки, улучшает коммуникацию, способствует росту рынка, то ценность описания и внедрения бизнес-правил несомненна.
Организации могут заблаговременно описать свои методы и способы ведения бизнеса и создать базу данных бизнес-правил. Хотя эта деятельность может быть полезной, но она может также быть дорогой и трудоемкой. И последнее — серьезное препятствия для документирования бизнес-правил.
- Бизнес-правил может извлекать бизнес-аналитик или консультант. Правила могут извлекаться из ИТ документации (как прецеденты, спецификации или код системы). Могут проводиться семинары и интервью с экспертами в соответствующих областях деятельности.
- Сбор правил могут ускорить программные технологии, разработанные для сбора бизнес-правил посредством анализа программного кода или фактического поведения пользователя.
Осознав недостатки практики сбора бизнес правила, эксперты по бизнес-анализу выдвинули методологию создания бизнес правил ((https://en.wikipedia.org/wiki/Business_rules_approach)
Кое-что о методологии создания бизнес-правил
Методология создания бизнес-правил определяет процесс идентификации и описания бизнес-правил на естественном языке проверяемым и понятным способом. Такой процесс не сложен в освоении, его можно выполнять в режиме реального времени, и он дает заинтересованным сторонам возможность согласованно управлять своими собственными бизнес-правилами.
В рамках данной методологии фигурируют следующие концептуальные объекты:
- Типы бизнес-правил.
- Категории бизнес-правил.
- Отношения бизнес-правил.
- Структурные предположения. Описания структуры, где и посредством которой регистрируются факты о предприятии, которые в последствии используются для принятия решений.
- Предположения о деятельности. Ограничения и условия, которым подчиняется или контролируется бизнес.
- Деривация или извлечение знаний. Дополнительные знания, которые вытекают из первичных знаний о бизнесе.
- Правила координации. Правила, обеспечивающие деятельность без непроизводительных остановок.
- Правила квалификации/дисквалификации. Эти правила используются для определения того, что должно быть вовлечено в деятельность, а что нет. Это может быть тождественно работе фильтров.
- Правила принятия решения.
- Определения бизнес-терминов
- Отношения фактов
Например, сказать, что клиент может сделать заказ, это НЕ бизнес-правило, а факт.
Факты могут быть задокументированы как предложения на естественном языке. Могут быть представлены графическими моделями как отношения, атрибуты и структуры обобщения.
- Ограничения (также называемые «действиями»)
- Правила преобразования знаний
Пакеты программ
Пакеты программ автоматизируют бизнес-правила, используя бизнес-логику.
Термин бизнес-правило иногда используется взаимозаменяемо с термином бизнес-логика; однако последний термин ассоциируется с практикой — инженерная или деловой.
В ходе сбора правил организация может столкнуться с проблемой существования коллективных знаний, которые представляют собой «недокументированную» информацию, процессы и правила, которые существуют только в умах определенных сотрудников. Наличие таких бизнес-правил может привести разрывам связей и несовместимости с производством, с процессами, качеством и опытом работы.
Формальные спецификации описания бизнес-правил
Бизнес-правила могут быть выражены с использованием подходов моделирования, таких как
- унифицированный язык моделирования (UML),
- язык выполнения бизнес-процессов (BPEL),
- нотация моделирования бизнес-процессов (BPMN),
- модель принятия решений и нотация (DMN),
- семантика бизнес-словаря и Деловые правила (SBVR),
- нотация Z.
Бизнес-правила, закодированные в компьютерном коде в операционной программе, называются бизнес-логикой.
Программные системы управления бизнес-правилами
BRMS или система управления бизнес-правилами включает в себя политики, требования и условные операторы, которые используются для определения действий, выполняемых в приложениях и системах.
- Репозиторий, предназначенный для ведения логики бизнес-правил, и соответственно, логики принятия решений.
- Инструменты, позволяющие как техническим разработчикам, так и бизнес-экспертам определять бизнес-правила и управлят ими.
- Среду выполнения, позволяющая приложениям вызывать логику принятия решений, управляемую BRMS, а также выполнять бизнес-правила.
Стоит упомянуть от встроенной в продукты SAP системы управления бизнес-правила — BRFplus. Что в некоторых случаях существенно облегачает кастомизацию конкретного решения.
Источник: lumpov.blogspot.com