Цитата:
Сообщение от
driller
А в отношении возможности жонглирования с createdBy, считаю что это дыра в безопасности системы
Отчего же? Если у кода есть возможность создавать записи через AOS и менять системные поля за счет доступности разрешения OverwriteSystemfieldsPermission, то с таким же успехом этот код может получить разрешение SqlStatementExecutePermission и изменить данные прямым SQL-запросом, минуя все аудиторские следы, журналы БД и проч.
Цитата:
Сообщение от
driller
как можно верить аудиторскому следу, если с этим полем можно играть, как вздумается даже на уровне приложения,
и просто не могу представить
Аудиторский след отражает действия
пользователя, а не программного кода, который пользователь выполняет. Для полноты ощущений там еще вроде есть возможность подписывать "следы" с помощью ЭЦП, что в общем случае одной подменой системного поля не обойдешь. А уж что программисты в приложении наворотили, это совсем другое дело. Может, при нажатии на безобидную кнопку где-нить в закрытых периодах проводки меняются или новые создаются в обход всех проверок стандартного приложения... Пользователь может об этом не знать, но это ведь не значит, что он из-за этого не должен фигурировать в авторах создания/изменения записей.
Цитата:
Сообщение от
driller
для каких благих целей это можно использовать
Пример "подмены" значений системных полей можно найти в логировании входа пользователей в систему: там дата/время создания записей журнала работы пользователей немного корректируется. Аналогично, подмена автора создания записи может использоваться для "логирования" того, что действие произведено "в интересах" того или иного, а не текущего, пользователя, хотя это, конечно, какой-то нереалистичный сценарий. В любом случае, насколько я знаю, ядро не позволяет штатными средствами изменить системные поля с автором/датой/временем создания
уже существующих записей - это намного важнее с точки зрения безопасности.
В целом, насколько я могу судить, в той же 4.0/2009 изменения с т.з Trustworthy Computing были продиктованы примерно такими соображениями:
- Dynamics AX все больше становится интегрирована с внешними приложениями, подчас даже написанными сторонними разработчиками, не относящимися напрямую к организации, внедрившей у себя Dynamics AX;
- если взаимодействие ограничивается обменом данными, то тут хватает обычной бизнес-логики для их проверки, и ничего дополнительно делать не нужно;
- если взаимодействие идет, скажем, через Business Connector, то выполняемая бизнес-логика разделяется на две части: та, которая есть в приложении Dynamics AX, и та, которой в этом приложении нет, потому что она "зашита" в программу, дергающую Business Connector, а его можно "науськать" выполнить что угодно, в обход всех существующих в приложении Dynamics AX проверок.
- из предыдущего пункта следует, что в общем случае "доверять" можно лишь коду, выполняемому на сервере, потому что сервер выполняет код приложения Dynamics AX, написанный "в интересах" организации и удовлетворяющий ее требованиям по безопасности и разного рода проверкам и ограничениям; если же на сервере нужно выполнить сторонний код (через COM/DLL/.NET), то на это опять же явно нужно запросить разрешение и в приложении указать, что разработчик отдает себе отчет в том, что он делает.
Именно исходя из таких соображений, по-моему:
- все проверки и запросы разрешений, связанные с Code Access Security, актуальны только для серверного кода;
- часть разрешений в принципе не может быть получена клиентским кодом (OverwriteSystemfieldsPermission, SqlStatementExecutePermission, SkipAOSValidationPermission, Uncheck::TableSecurityPermission и т.д.), и, соотв., определенный функционал не может выполняться на клиенте;
- доступ к ряду таблиц принудительно проверяется на AOS'е с помощью методов aosValidateXX(), в т.ч. доступ на чтение данных.
Т.е. в ядре были реализованы механизмы для принудительного выноса части бизнес-логики на сервер с тем, чтобы эта логика была реализована в приложении Dynamics AX. Никому и в голову не приходило, что может понадобиться защищать систему на базе Dynamics AX от ее же собственного приложения, в котором кто-то что-то может наворотить полухакерскими методами. Для этого предназначен "ручной" контроль (просмотр) модификаций, поднимаемых на рабочее приложение, если эти модификации разработаны сторонними подрядчиками, а также проверка людей при приеме на работу, если модификации разрабатываются штатными сотрудниками.