@
k@DElpherА где-нибудь есть хорошая аргументация и сравнение всех подходов?
Вот тут только общее представление (
Application Architecture Guide v2 ):
АутентификацияПроектирование эффективной стратегии аутентификации для бизнес-слоя имеет большое значение с точки зрения обеспечения безопасности и надежности приложения, в противном случае, оно будет уязвимым для атак с подделкой пакетов, атак перебором по словарю, перехватом сеансов и других типов атак. При проектировании стратегии аутентификации руководствуйтесь следующими рекомендациями:
Избегайте аутентификации в бизнес-слое, если она будет использоваться только слоем представления или слоем сервисов, располагающимися на том же уровне в пределах границы доверия.
Передавайте удостоверение вызывающего в бизнес-слой, только если требуется проводить аутентификацию или авторизацию на основании ID исходной вызывающей стороны .
Если предполагается разделять бизнес-слой между многими приложениями, использующими разные хранилища пользователей, рассмотрите возможность применения механизма единой регистрации. Избегайте создания собственных механизмов аутентификации, по возможности пользуйтесь встроенными механизмами платформы.
Если слой представления и бизнес-слой развернуты на одном компьютере и требуется выполнять доступ к ресурсам на основании разрешений Списка управления доступом (access control list, ACL) исходного вызывающего, рассмотрите возможность использования олицетворения. Если слой представления и бизнес-слой развернуты на разных компьютерах и требуется выполнять доступ к ресурсам на основании разрешений ACL исходного вызывающего, рассмотрите возможность использования делегирования. Однако делегирование обусловливает более интенсивное использование ресурсов и, кроме того, не поддерживается многими средами, поэтому должно применяться только в случае крайней необходимости. Если требования безопасности позволяют, выполняйте аутентификацию пользователя на границе и реализуйте обращения к нижним слоям с помощью доверенной подсистемы. В качестве альтернативы предлагается подход обеспечения безопасности на основании утверждений (особенно для приложений на базе сервисов), который использует преимущества механизмов интегрированной идентификации и обеспечивает возможность целевой системе проводить аутентификацию утверждений пользователя.
АвторизацияПроектирование эффективной стратегии авторизации для бизнес-слоя имеет большое значение с точки зрения обеспечения безопасности и надежности приложения, в противном случае, оно будет уязвимым для разглашения данных, повреждения или подделки данных и несанкционированного получения прав доступа. При проектировании стратегии авторизации руководствуйтесь следующими рекомендациями:
Защитите ресурсы, применяя авторизацию на основании удостоверений, учетных групп, ролей или других контекстных данных вызывающей стороны. Максимально сократите дробление на роли, чтобы уменьшить число необходимых сочетаний разрешений.
Применяйте авторизацию на основании ролей для бизнес-решений , авторизацию на базе ресурсов для аудита системы и авторизацию на основании утверждений, если требуется поддерживать интегрированную авторизацию по совокупности данных, таких как удостоверение, роль, разрешения, права и другие факторы.
По возможности избегайте применения олицетворения и делегирования, потому что это может существенно повлиять на производительность и возможности масштабирования. Как правило, олицетворение клиента при вызове требует больших ресурсов, чем вызов напрямую.
Не смешивайте код авторизации и код обработки бизнес-задач в одном компоненте.
Поскольку, как правило, авторизация охватывает все приложение, обеспечьте, чтобы инфраструктура авторизации не создавала существенные издержки производительности.
Итого, какие можно сделать выводы. Осуществлять безопасность средствами СУБД плохо хотя бы с той точки зрения, что это немасштабируемо. Во-вторых, нужно писать свой слой доступа в виде модуля и т.п., что перечит рекомендации "пользуйтесь встроенными механизмами платформы". В-третьих, если потом нужно будет разделять бизнес-слой между многими приложениями, использующими разные хранилища пользователей (механизм единой регистрации, SSO), то мы будем завязаны под первую БД, в которую изначально зашили безопасность. То есть, никакой изоляции (слабосвязанности). В четвертых, невозможна миграция на другие виды СУБД, так как у каждого хранилища принципиально своя реализация безопасности. В случае же встроенных в ASP.NET инструментов мне достаточно будет переключить просто провайдер (допустим с сиквельного на оракловый) и моя безопасность снова в действии. Заметьте, я не говорю про бизнес-данные (они могут располагаться где угодно), я говорю о расположении безопасности.
P.S. И в заключении - скрин. Посмотрите в руководстве, безопасность вынесена в отдельный слой. И никакого отношения к СУБД она не имеет.
