При эксплуатации или построении решения, существуют ситуации, когда администратору требуется детально разобраться в причинах недостатка прав на объект по ролевой, дискреционной модели или понять причины неожиданного вычисления ролей. Ведь кто знает, как и что там вычисляется под капотом, быть может это ошибка платформы или следствие неверных настроек?
В таких ситуациях на помощь приходит дополнительное логирование, в которое попадает отладочная информация о проверке безопасности.
Данные попадают в лог Storage Server. В этой статье расскажу, как включить логирование и как воспользоваться результатами.

Для вĸлючения лога с отладкой проверки безопасности потребуется соблюдение двух пунктов:

• Выполнить изменения на уровне базы данных
• Произвести настройку в реестре

Включение.

Выключение.

• Выполните SQL запрос на используемой базе данных Docsvision :
  MS SQL:
  delete from dvsys_settings where [Name] = N'RoleModelTrace‘
  PostgreSQL:
  delete from dvsys_settings where "Name" = 'RoleModelTrace';
• Удалите созданный ранее ĸлюч TraceLevel.

Затем перезапустите службу StorageServer, если используется и IIS, чтобы применить изменения. Файл лога сервера, после перезапусĸа, должен автоматичесĸи создаться заново, с отметкой даты, времени и идентификатора процесса w3wp.exe в названии лога. Ориентируйтесь на новые файлы, чтобы увидеть в них дополнительную информацию.

Откройте карточку в клиентском приложении или попробуйте включить ролевой фильтр в конструкторе ролей с указанием необходимого сотрудника и карточки, права на которую проверяете, зафиксируйте время.

Дискреционная безопасность.

В новом созданном файле увидите записи определения прав дискреционной безопасности на объект, с указанием сессии, пользователя, карточки и список операций:

Granted — разрешенные;
Denied — запрещенные;

AccessCheckInfo for session '29a1b414-a57c-ee11-80d2-00155d380101', 
SECURE_CARD '9171d1e2-2083-4004-86c4-f730112022fd' and employee 
'dc658e07-6198-435c-b0bf-9cdc9897424b': AccessCheckInfo: 
[SecureObject: [Type: SECURE_CARD, ObjectId: {9171d1e2-2083-4004-86c4-f730112022fd}, 
LocationId: {00000000-0000-0000-0000-000000000000}, 
TypeId: {b9f7bfd7-7429-455e-a3f1-94ffb569c794}], 
Processed: [True], Granted: [WRITE_DATA, DELETE_CHILD, COPY, 
IMPLICIT_POWERUSER_RIGHTS, WRITE_ATTRIB, DELETE], 
Denied: [None], Error: [0]].<br>Granted: [WRITE_DATA, DELETE_CHILD, COPY, 
IMPLICIT_POWERUSER_RIGHTS, WRITE_ATTRIB, DELETE], Denied: [None]
Total 4 ms elapsed.

Ролевая модель.

Следующим этапом отрабатывает проверка ролевой модели, это сопровождается длинным содержимым, с фиксированием:

• идентификатора сессии;
• карточки, на которую осуществляется проверка прав;
• сотрудника, открывающего карточку;
• типа карточки;
• вида карточки;
• состояния карточки;
• результата вычисления;

Пример отображения данных ниже:

StorageServerRuntime Information: 0 : 
Starting GetOperationsAccessInfo method execution for session '29a1b414-a57c-ee11-80d2-00155d380101', card '9171d1e2-2083-4004-86c4-f730112022fd' and employee 'dc658e07-6198-435c-b0bf-9cdc9897424b' ...
    Initializing database connection and change subscriptions ...
    Done in 0 ms.
    Reading card type info for 1 cards ...
    Done in 1 ms.
    Getting AccessInfo for card '9171d1e2-2083-4004-86c4-f730112022fd' type 'b9f7bfd7-7429-455e-a3f1-94ffb569c794' kind '66be699c-3b68-42ca-91ef-02b2e2203ab0' state '73694870-d533-47d0-ab90-0b221b83a812' employee dc658e07-6198-435c-b0bf-9cdc9897424b ...
        Creating kind cache ...
            Loading card kinds info ...
            Done in 1 ms.
            Loading kind states ...
            Done in 0 ms.
            Loading kind operations ...
            Done in 2 ms.
            Loading kind state machine branches ...
            Done in 6 ms.
            Reading cards timestamp
            Done in 1 ms.
        Done in 78 ms.
        Checking role Системная для WF ...
            Checking condition 'I' ...
            Condition "'I' Equals 'Group_{23157425-6bca-44fc-905e-ab1ccfbc07b6}'" for the card '9171d1e2-2083-4004-86c4-f730112022fd' and employee 'dc658e07-6198-435c-b0bf-9cdc9897424b' is 'True'.
            Done in 1 ms.
            Role "Системная для WF" for the card '9171d1e2-2083-4004-86c4-f730112022fd' and employee 'dc658e07-6198-435c-b0bf-9cdc9897424b' is 'True'.
        Done in 7 ms.
        ......
        ......

В рассматриваемом случае прошла проверка условий для общей роли «Системная для WF», а точнее проверка на присутствие сотрудника в группе.

Результат вычисления условия — значение True, так как других условий для этой роли нет, то сотруднику будет присвоена роль. Это подтверждается строчкой:

Role "Системная для WF" for the card '9171d1e2-2083-4004-86c4-f730112022fd' 
and employee 'dc658e07-6198-435c-b0bf-9cdc9897424b' is 'True'.

И как бонус, фиксируется время вычисления данной роли — 7ms.
Зная время вычисления возможно локализовать проблемы производительности, связанные с долгим вычислением прав. Информация укажет, условия каких ролей настроены не лучшим образом и требуют оптимизации.

Таким же образом в логе будет содержаться информация по проверке остальных ролей и условий.
Насколько понял, проверка условий, в рамках одной роли происходит до первой положительной проверки, например, если присутствует два условия, объединенные по «ИЛИ» и первая проверка завершилась с результатом «True», то второе условие проверяться не будет, так как это не имеет смысла.

Операции.

Последним этапом отображается список разрешенных и запрещенных операций, в соответствии с произведенной проверкой прав по ролями.

Фиксируется это следующим образом:

AccessInfo for card '9171d1e2-2083-4004-86c4-f730112022fd' type 
'b9f7bfd7-7429-455e-a3f1-94ffb569c794' kind '66be699c-3b68-42ca-91ef-02b2e2203ab0' 
state '73694870-d533-47d0-ab90-0b221b83a812' employee 
dc658e07-6198-435c-b0bf-9cdc9897424b: <AccessInfo><Operations><
Operation ID="639e6d8f-1bcd-470e-9218-ee432c816673" Name="Edit main file" 
Status="Allowed" /><Operation ID="2b379fbe-151d-4987-a364-52b9981ffd0c" 
Name="Ответ" Status="Allowed" /><Operation 
ID="e98dfabf-f0ff-4ce7-bc98-6755a8bfe3f8" Name="Lock main file" Status="Allowed" 
/><Operation ID="cefc5dca-b299-4a9b-a1bd-34a9ea47775b" 
Name="Open Reconciliation" Status="Allowed" />...

Здесь видно идентификатор каждой операции, ее название и статус разрешения.

Вывод.

Какие сделаем выводы : логирование операций проверки безопасности на объекты полезная настройка. Можно детально разобраться в причинах избыточного доступа или наоборот недостатка прав. Здесь стоит отметить, что ролевая модель не работает для справочников, поэтому здесь придется обходиться только дискреционной моделью. К этому, дополнительно, получаем информацию о затраченном времени вычисления, что полезно при анализе причин замедления, при работе с объектами системы.
Рассмотрим и обратную сторону. Операция логирования тяжелая и может сильно нагружать дисковую подсистему. В реалиях промышленной эксплуатации, представьте ситуацию, когда 1000 пользователей одновременно работают с карточками, файл лога растет с невероятной скоростью, поэтому использовать данную функциональность следует осознанно и в нужное время.