Применение детальной защиты к существующему приложению

Question

Я унаследовал достаточно большое и сложное веб-приложение ASP.NET MVC3, используя EF Code First на SQL Server. Он использует роли членства ASP.NET с аутентификацией базы данных. Действия контроллера защищены атрибутами, производными от AuthorizeAttribute, которые сопоставляют роли с действиями. Существуют методы расширения для более тонких точек, такие как отображение определенного виджета для определенных ролей. Это прекрасно работает, и я хорошо понимаю текущую модель безопасности.

Меня попросили обеспечить более детальную безопасность на уровне данных. Например, пользователь «Заказчик» может видеть только данные (по всей базе данных), связанные с самими собой, а не с другими Заказчиками. Проблема в том, что «Клиент» - это только 1 из 5 различных типов со своими собственными специфическими ограничениями (каждая из 9 ролей является одним из этих 5 типов).

Лучшее, что я могу придумать, - это пройти через все хранилища данных и дополнить каждый оператор / запрос LINQ фильтром для каждого типа пользователя. Даже если бы у меня было на это время, это не самый элегантный способ.

Есть предложения? Я действительно не знаю, с чего начать, поэтому все может быть полезным.

Большое спасибо.

Answer 1

Безопасность на основе данных должна выполняться в запросах. Добавление этого на последнем этапе проекта действительно занимает много времени. Не из-за программирования, а из-за тестирования. Если у руководства есть это требование, оно должно просто принять его.

Вы можете начать с рефакторинга некоторых базовых запросов. Каждый запрос должен иметь доступ к некоторому DbSet, поэтому вместо доступа к DbSet необходимо обращаться к некоторому вспомогательному методу, применяющему защиту для этого набора. Вы можете поиграть с DbSet s в вашем производном контексте или даже попытаться получить свои собственные DbSet s и повторно реализовать IQueryalbe.Expression (явная реализация), чтобы добавить свою логику фильтрации непосредственно в набор.

Реальные осложнения начались в ленивой и энергичной нагрузке. EF не позволяет фильтровать загруженные данные. С хорошо спроектированными агрегатами вам не нужно перегружать клиента ленивой загрузкой и энергичной загрузкой. Если вам это нужно, вам придется реорганизовать эту часть кода, чтобы она работала правильно (речь идет не только о добавлении некоторого условия в запрос).