hVosttdimonz80Надо иметь 2 API: внутренний и внешний. Внутренний - для реализации бизнес логики без оглядки на безопасность. Внешний - для пользователей, т/е некоторое представление возможных действий пользователя. Классический случай - MVC. Модель имеет внутренний API. Контроллер - внешний. Где-то в районе контроллера реализуется слой безопасности. Кроме того, внешний API - это то, что надо можно смело тестировать на защиту от дурака.

А ещё можно внедрить ABAC, который позволяет реализовывать бизнес-правила безопасности, а не только на уровне ролей, клеймов, CRUD-матриц у других атрибутов безопасности. И это будет один единственный модуль на все-все случаи.
Круто, спасибо большое, обязательно попробую )))

dimonz80hVosttпропущено...


Поэтому надо убирать «кучу проверок» и внедрять один единственный изолированный модуль безопасности, который будет отвечать можно, или нельзя. И ответ «нельзя», это ответ по умолчанию.

+2

Надо иметь 2 API: внутренний и внешний. Внутренний - для реализации бизнес логики без оглядки на безопасность. Внешний - для пользователей, т/е некоторое представление возможных действий пользователя. Классический случай - MVC. Модель имеет внутренний API. Контроллер - внешний. Где-то в районе контроллера реализуется слой безопасности. Кроме того, внешний API - это то, что надо можно смело тестировать на защиту от дурака.

ТС, поделись хоть технологиями, на который верстаешь свой шыдевр. Может проблема-то уже и решена.
Это чисто на T-SQL )))

alex55555RMagistr2015Проблема - пишем ИС, делаем различные фичи, затем приходится писать в три раза больше что бы запретить пользователям обходить эти фичи или использовать их во вред
Решение - грамотное проектирование. Но вам, конечно же, по прежнему ничего не понятно? Ну что-ж поделаешь - либо вы становитесь грамотным проектировщиком (лет через цать), либо вы находите способ убедить себя в том, что некий кандидат Вася Пупкин и есть тот самый гений (за те самые деньги, которые вам не жалко ему отдать).

Дело было на прошлой работе ))))

RMagistr2015alex55555пропущено...

Решение - грамотное проектирование. Но вам, конечно же, по прежнему ничего не понятно? Ну что-ж поделаешь - либо вы становитесь грамотным проектировщиком (лет через цать), либо вы находите способ убедить себя в том, что некий кандидат Вася Пупкин и есть тот самый гений (за те самые деньги, которые вам не жалко ему отдать).

Дело было на прошлой работе ))))
Не я за это отвечал ))) И слава богу ))

dimonz80hVosttпропущено...

Что значит притягивать? Если не обеспечить прозрачный доступ к атрибутам, то будет трудно работать с безопасностью в любом случае, если захочется иметь централизованную безопасность. А роли/клеймы слишком деревянные и редко когда соответствую реалиям, поэтому начинается жёсткое "внедрение" безопасности прямо в недра кода. Пока что ничего удобнее ABAC, с достаточной гибкостью, не встречал.

Притягивать значит сопоставлять атрибуты объекта и субъекта, чтобы определиться что можно а что нельзя. Атрибутов мильон зачастую особенно у объекта. Кроме того, если наша система атрибутного доступа позволяет дергать атрибуты атрибутов атрибутов, то может лихо просесть по произволительности. А так да - гибкость жуткая. И сложность реализации тоже))


Лично мне думается что система прав доступа должна быть максимально плоской. Например для веба это что-то типа фильтрации по URL например "редактировать документа с id = <id> значить дергать URL /document/<id>/edit".
Если возникает проблема что надо редактировать документ с датой создания не ранее месяца назад (вот он атрибутный доступ, да) то придется расширять пользовательский API и добавлять URL /document/<id>/editLastMonth например и прописывать правила доступа для него. Достаточно "жёсткое "внедрение" безопасности прямо в недра кода"))))


А вообще разделение бизнес логики и системы безопасности - вопрос неоднозначный и где заканчивается одно и начинается другое, определить бывает сложно.

Продукт устаревший - Lexema 5.5 Делфийная приблуда с БД на MS-SQL
В общем-то если там конкретно рассматривать объекты, то это кнопки поля,списки, документы, правила, отработки, отчёты, запросы. Код пишется прям в кнопке и хранится в полях БД, где ему можно спокойно делать Update, выносить в процедуры пробовал, и давать на них права то же, потом устаёшь искать где какой код применён в документе, так как опять же если что-то просят поправить, то это нужно делать быстро и без встроенной системы поиска в самой Lexemа не обойтись, а она не ищет в процедурах, нужно свой инструмент клацать под это. в общем тут сложности
Отсюда и сложность с доступам к объектам, как например нужно что-то совместить среднее с быстрым поиском кода для его правки и централизованным администрированием этих самых правил.

dimonz80hVosttпропущено...


Что значит притягивать? Если не обеспечить прозрачный доступ к атрибутам, то будет трудно работать с безопасностью в любом случае, если захочется иметь централизованную безопасность. А роли/клеймы слишком деревянные и редко когда соответствую реалиям, поэтому начинается жёсткое "внедрение" безопасности прямо в недра кода. Пока что ничего удобнее ABAC, с достаточной гибкостью, не встречал.

Притягивать значит сопоставлять атрибуты объекта и субъекта, чтобы определиться что можно а что нельзя. Атрибутов мильон зачастую особенно у объекта. Кроме того, если наша система атрибутного доступа позволяет дергать атрибуты атрибутов атрибутов, то может лихо просесть по произволительности. А так да - гибкость жуткая. И сложность реализации тоже))


Лично мне думается что система прав доступа должна быть максимально плоской. Например для веба это что-то типа фильтрации по URL например "редактировать документа с id = <id> значить дергать URL /document/<id>/edit".
Если возникает проблема что надо редактировать документ с датой создания не ранее месяца назад (вот он атрибутный доступ, да) то придется расширять пользовательский API и добавлять URL /document/<id>/editLastMonth например и прописывать правила доступа для него. Достаточно "жёсткое "внедрение" безопасности прямо в недра кода"))))


А вообще разделение бизнес логики и системы безопасности - вопрос неоднозначный и где заканчивается одно и начинается другое, определить бывает сложно.

Но мы немного отошли от темы, вопрос был о том, как предугадать какие действия может совершать пользователь? Как смоделировать его действия? Описать в автоматическом режиме сценарии его поведения...? Есть ли такой софт?

hVosttdimonz80Притягивать значит сопоставлять атрибуты объекта и субъекта, чтобы определиться что можно а что нельзя. Атрибутов мильон зачастую особенно у объекта. Кроме того, если наша система атрибутного доступа позволяет дергать атрибуты атрибутов атрибутов, то может лихо просесть по произволительности. А так да - гибкость жуткая. И сложность реализации тоже))

Всё верно, серебряной пули не существует. Поэтому применяются такие решения, как кеширование, индексирование атрибутов, схлопывание и компиляция политик. Я не говорю, что это просто. Но, как говорится, простое сделать сложно, и сложное сделать просто.


dimonz80Лично мне думается что система прав доступа должна быть максимально плоской. Например для веба это что-то типа фильтрации по URL например "редактировать документа с id = <id> значить дергать URL /document/<id>/edit".
Если возникает проблема что надо редактировать документ с датой создания не ранее месяца назад (вот он атрибутный доступ, да) то придется расширять пользовательский API и добавлять URL /document/<id>/editLastMonth например и прописывать правила доступа для него. Достаточно "жёсткое "внедрение" безопасности прямо в недра кода"))))

Представь, что:

1) самых разных политик много
2) политики меняются почти каждый день, это естественный жизненный цикл
3) политики могут быть очень сложные, накладываться друг на друга, одни политики могут исключать или дополнять другие
4) периодически надо совершенно определённо сказать, что можно и что нельзя
5) ещё часто надо сказать, а на каком основании вот это можно или нельзя, кто так решил? почему? когда?

Теперь соотнеси это с безопасностью, описанной в коде. Для несложной системы подойдут роли, для системы по-сложнее подойдут клеймы, для CRUD-приложений подойдут матрицы безопасности. Но все эти модели деревянные и не решают ни один из приведённых мною пунктов.

dimonz80А вообще разделение бизнес логики и системы безопасности - вопрос неоднозначный и где заканчивается одно и начинается другое, определить бывает сложно.

Поэтому мы отказались от затеи разделять правила бизнес-логики и системы безопасности. Всё одно.
Мы то же пробовали отказаться от такого разделения, в итоге пришли к каше ))) Где все вместе валяется и непонятно когда всё это закончится, а самое главное,как в этом разобраться. Это конечно хорошо, программер всегда трудоустроен, но вот надо же как-то разбирать этот бардак, а то так недолго и с работы вылететь за несвоевременное выполнение обязанностей, как например - вспомнить что где лежит, кто это придумал, а потом передумал в самом далёком отделе, в самом удалённом кустке системы 3-и года тому назад? И ответ чтоб был через 5-ть минут, потому как тут инвесторы приехали, и им надо знать сейчас же... Как быть?

[quot dimonz80]RMagistr2015Если не хотите переделывать как положено, то можно использовать автокликеры, например такие
Вы уже пробовали использовать эти автокликеры? Настраивать их что-то с ними делать? Как-то разрабатывать их?

hVosttRMagistr2015Но мы немного отошли от темы, вопрос был о том, как предугадать какие действия может совершать пользователь? Как смоделировать его действия? Описать в автоматическом режиме сценарии его поведения...? Есть ли такой софт?

Есть такое понятие, как «тестирование». Садишь команду тестировщиков и они ищут баги, дыры, проверяют все возможные сценарии использования. Интеграционные тесты пишутся вручную и проверяются конкретные кейсы, искусственного интеллекта для тестирования пока не разработали.

А вообще каие нейронные сети можно натаскать на подобного рода задачи?
Какого вида эти нейронные сети существуют и какие из них больше всего подходят под решение подобных задач как например автокликанье и проверка всех сценариев пользователя?

dimonz80пропущено...


Пробовали как раз для эмуляции действий пользователей пару лет назад.
Что пробовали? какой результат получился? Поделитесь пожалуйста опытом... )

RMagistr2015dimonz80пропущено...


Пробовали как раз для эмуляции действий пользователей пару лет назад.
Что пробовали? какой результат получился? Поделитесь пожалуйста опытом... )
Госпада, не жадничайте знаниями, помните, что чем больше вы отдаёте знаний во время обсуждений,тем больше истины приходит к вам, потому как идёт проверка на неадекватность Ваших же знаний, а в итоге расширяются горизонты, и вы сможете узнать, понять, а в итоге и предложить как специолист гораздо больше )))))
Так что не жадничайте знаниями )))) Делитесь опытом ))) И бродите по планете ))))

RMagistr2015dimonz80пропущено...

Пробовали как раз для эмуляции действий пользователей пару лет назад.
Что пробовали? какой результат получился? Поделитесь пожалуйста опытом... )

Так же для особо жадных на знания хочу напомнить, что любая Ваша мысль высказаная другим человеком вперёд Вас, Вам уже не принадлежит, а соответственно, не вы будете принимать участие в её реализации )))) Так что прежде чем смолчать, всегда подумайте ))) А стоит ли это того ))))))))))