Ограничение доступа к объектам в приложении

Вы изучали модель Безопасность доступа кода, которую Microsoft создала для платформы .NET? Я сам смотрел на него лишь несколько раз, но суть в том, что вы можете заблокировать определенные объекты и методы, чтобы только пользователи из внутренних сетей могли вызывать этот код. Или аналогично, метод, который выполняет обслуживание, может быть вызван только с самой машины, на которой установлен код, что не позволяет третьей стороне взломать процедуру обслуживания.

Википедия дает хорошее резюме CAS:

Code Access Security (CAS), in the Microsoft .NET framework, is Microsoft's solution to prevent untrusted code from performing privileged actions. When the CLR loads an assembly it will obtain evidence for the assembly and use this to identify the code group that the assembly belongs to. A code group contains a permission set (one or more permissions). Code that performs a privileged action will perform a code access demand which will cause the CLR to walk up the call stack and examine the permission set granted to the assembly of each method in the call stack. The code groups and permission sets are determined by the administrator of the machine who defines the security policy.

эта статья из 15 Seconds дает хороший и быстрый обзор того, как начать работу.

Я несколько раз бился головой об эту стену.

Лучшее решение, к которому я пришел, - это моделировать все в древовидной иерархии, где каждый доменный класс является ветвью в дереве, а экземпляры - листьями этой ветки. Листья могут иметь прожилки, если вам нужно обезопасить части экземпляров. Каждой ветви назначены собственные действия (такие как «Чтение», «Запись», «Удалить», «Публикация»). Используйте ту же иерархию для безопасности, но затем корень становится пользователем или группой. В итоге вы получите такую ​​структуру:

<domain> Project
|- <class> Person
| |- <instance> John
| |- <instance> Mary
|- <class> FormX
| |- <instance> John's Leave Form
...

и для применения безопасности у вас может быть группа с именем «Администраторы», которая может делать что-то с людьми:

<group> Administrators
|- <class> Person: actions (Read, Create, Update, Suspend)

и администратор офиса, который может обрабатывать формы и создавать новых людей:

<group> Office Administrator
|- <class> Person: actions (Create)
|- <class> FormX: actions (Approve, Deny)

а затем Джон может делать что угодно со своим профилем:

<user> John
|- <class> Person
| |- <instance> John: actions (Edit)

Когда я реализовал эту структуру, она использовала C# и SQL Server 2000, поэтому я мог использовать тип данных схемы XML и выполнять запросы безопасности к базе данных или [что чаще бывает] объединять профиль безопасности человека в единое дерево для определения какие права у кого-то есть на экземпляр, класс или другое (у меня были <group>, а не группы безопасности, в домене выше класса для простоты обслуживания).

Также важно включить - хотя я не проиллюстрировал это - что каждое действие было разрешением, а не логическим, где значениями разрешения были { Allow, None, Deny } с Разрешить предоставление доступа к этому глаголу, кроме случаев явного отказа, Нет, ни разрешающих, ни запрещающих, и Запрещенных. предотвращение доступа несмотря ни на что.

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

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