Может ли безопасность не быть сквозной проблемой?

Question

Я работаю над проектом с очень подробными требованиями безопасности.Честно говоря, я бы не удивился, если бы предложенная модель была такой же сложной, как и для любого разведывательного / охранного агентства.Теперь я прочитал, что объединение безопасности с бизнес-логикой - это сочетание проблем и, следовательно, практики, которой следует избегать.

Однако все попытки абстрагировать безопасность либо провалились, либо создали «абстракции», такие же грязные, как и раньше.Возможно ли, чтобы безопасность была настолько специфичной, что становится частью бизнес-правил?В некоторых ситуациях, нарушающих безопасность, маскируются только данные, тогда как в других ситуациях сеанс прерывается, а в другое время запускаются значения по умолчанию, которые будут использоваться вместо этого.Существует множество требований, отвечающих привилегиям безопасности.

Мой фундаментальный вопрос: могу ли я быть в исключительном случае (то есть, когда включение безопасности является обоснованным) или я не понимаю чего-то фундаментального в абстрагировании безопасности?

---

Редактировать:

tl; dr (из ответов, которые я понимаю): аутентификация (кто вы) очень важна и должна быть абстрактнойтогда как авторизация (что вы можете сделать) - это бизнес-логика.Отсутствие этого словаря и наличие только термина «безопасность» (или, возможно, неспособность оценить разницу между этими двумя понятиями) приводит к моей путанице.

Answer 1

Безопасность делится на две части;аутентификация и авторизация.Аутентификация - это довольно специфический вариант использования.Как вы определяете, что пользователь является доверенным из набора ненадежных пользователей.Я думаю, что это сквозной;вам нужно не допускать неаутентифицированных пользователей в вашу систему или ее часть.

Авторизация (может ли пользователь что-то сделать) является бизнес-правилом.Это может (и часто бывает) очень специфично и отличается для каждого варианта использования.Кто определяет, какие роли могут делать что?Ну, бизнес делает.Никто не может ответить за вас.

В среде Csla.Net 4 именно так обрабатывается авторизация;как специализированное бизнес-правило.Вы даже не ограничены «пользователь в роли» или «у пользователя есть разрешение».Вы можете сделать более сложные правила: «Пользователь может редактировать это поле, если шаг рабочего процесса не прошел этот конкретный шаг».

Answer 2

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

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

Авторизация будет отделена от той, в которой мы определяем роль пользователя и какие привилегии определяются этой ролью.

Типичным примером может быть то, что аутентификация возвращает объект пользователя и сохраняет его всессия.Пользователь имеет от 1 до многих ролей.Роль может иметь от 1 до многих привилегий.Методом бизнес-логики может быть sendEmail.Этот метод запрашивает у объекта User определенную привилегию, если он существует, что-то делать, если не делать что-то еще.

РЕДАКТИРОВАТЬ: Безопасность, на мой взгляд, всегда должна быть сквозной проблемой, когда речь идет о пользователе, однакоесли ваша бизнес-логика включает свойства объектов, которые не являются пользователем, CRUD этих объектов или администрирование других пользователей, то она соответствует вашим бизнес-требованиям и, таким образом, является бизнес-логикой.