Создание библиотеки безопасности, я думаю, что я перестраиваю ее

Итак, я создаю специальную библиотеку безопасности, которая взаимодействует с нашей базой данных. Он должен обеспечивать базовый контроль доступа для внутренних приложений: одни пользователи могут использовать X, другие - нет. Мои потребности на данный момент довольно простые, но в конечном итоге библиотека будет использоваться несколькими приложениями и контролировать множество защищаемых объектов.

Моя базовая объектная модель состоит в том, что пользователь является членом нуля или более групп. Эти группы предоставляют ноль или более разрешений. На самом деле все это будет один ко многим, но я не хочу ссылаться на это. Разрешения предоставляются только для предоставления (если никакая группа не предоставляет вам разрешение, у вас его нет, но нет «Запретить», который отменяет предоставленное разрешение, как в Windows RBS), и группы могут быть вложенными (пользователь уровня 2 имеет права Tier 1 плюс несколько новых). При попытке получить доступ к защищаемой области программы приложение обязательно подтвердит, что у пользователя есть необходимое разрешение, путем изучения иерархии его групп.

Однако, Я хочу, чтобы в библиотеке было несколько уровней избыточности. Особенно важно то, что пользователь, у которого нет разрешения на изменение настроек безопасности, не должен иметь такой возможности. Итак, я хочу сделать эту иерархию безопасности доступной только для чтения в большинстве случаев, поэтому необходимое, но запрещенное разрешение не может быть добавлено в память. Только когда пользователь доказал, что у него есть разрешение на изменение настроек безопасности, предоставив пользователю только для чтения с этим разрешением, свойства станут настраиваемыми даже на уровне кода.

Вот где я думаю, что я перестроил это. Чтобы сделать это, домен развил раздвоение личности; две копии каждого объекта, одна только для чтения, другая - нет. Версия только для чтения создается по умолчанию; любая операция, которая создаст версию с возможностью записи, требует, чтобы у текущего вошедшего в систему пользователя было разрешение на внесение изменений в систему безопасности. Это приводит к появлению двух пользователей (User и ConfigurableUser), двух групп, двух разрешений, каждый с двумя интерфейсами (настраиваемый, полученный из readonly) ... вы поняли.

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

. ] Помогите мне сделать это разумным. Есть ли другой образец, которому я должен следовать? Правильно ли я не доверяю другим разработчикам? Я предпочитаю не интегрироваться с системой безопасности Windows, но этот вариант уже обсуждался; главный недостаток будет заключаться в том, что права доступа будут поддерживаться в Active Directory для всей компании, и менеджер пользователей этого приложения не должен иметь такого доступа к общей безопасности системы.

РЕДАКТИРОВАТЬ: Несколько хороших комментариев и ответов от всех. AD или другая интегрированная система безопасности не совсем исключена, но мы обсуждали ее до того, как я начал разработку, и обнаружили некоторые недостатки. Итак, вот еще несколько моих / наших мыслей о том, почему мы даже решили использовать «индивидуальную» настройку безопасности:

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

• Несмотря на это, если пользователь когда-либо получит свой пароль Windows фишингом, взломом или кейлоггером, злоумышленник получит серьезный доступ к данным клиента через приложение. "бесплатно", если приложение использует встроенную безопасность вместо традиционного входа в систему. Отдельный уровень безопасности для приложения обеспечивает как минимум возможность резервирования; им придется взломать два набора учетных данных вместо одного, и этот второй набор учетных данных заблокирован за еще одним уровнем безопасности базы данных, к которому у взломанного пользователя не будет свободного доступа.

• Использование Active Directory или другой интегрированной безопасности имеет несколько проблем с точки зрения разработки / администрирования.

  1. Во-первых, сотрудники отдела довольно часто «меняют местами столы» и делают что-то на компьютерах друг друга. Интеграция с безопасностью Windows требует, чтобы пользователи полностью выходили из ОС, чтобы изменить текущего пользователя, вошедшего в приложение, вместо того, чтобы просто закрывать, повторно открывать и входить в приложение как другой пользователь.
  2. Во-вторых, менеджер отдела, который будет использовать программное обеспечение, является логическим лицом для обработки разрешений безопасности в приложении, но НЕ логическим человеком, которому следует предоставить доступ администратора AD. Балансировка, которая потребует дополнительного уровня ролей в AD, чтобы обеспечить «субадминистратора», который мог бы получить доступ к AD, но только предоставить определенные права определенным людям. Существует также задокументированное требование, чтобы управление безопасностью было интегрировано в приложение, что IMO делает невозможной интеграцию AD.
  3. Наконец, интегрированная безопасность Windows, как я понимаю, не имеет этого уровня «разрешений». Вместо того чтобы утверждать, что у пользователя есть заявленное разрешение на что-либо, вы утверждаете, что пользователь находится в определенной роли, из чего следует, что эта роль имеет разрешение на продолжение. Таким образом, я могу разработать систему, требующую, чтобы у AD была роль для каждого конкретного защищаемого объекта в приложении, вложенная в логические роли, которые будут иметь пользователи (административный кошмар, который я ' я уверен, что администратор сети будет бороться за то, чтобы держаться подальше от своего уровня безопасности), или мы определяем широкий спектр функций, которые принадлежат известной роли, вкладываем роли для создания «пользовательских уровней», и если пользователю когда-либо понадобится доступ к одному элементу функциональности на следующем уровне, они должны получить весь уровень (или AD И мое приложение должны быть изменены, чтобы выделить эту функциональность в конкретную назначаемую роль).

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

РЕДАКТИРОВАТЬ 2: В качестве эпилога к этому вопросу я в конечном итоге пришел к решению сохранить мою изменяемую иерархию объектов, но затем создать простой интерфейс IAuthUser с членами только для чтения для пользователя ' s основная информация и разрешения. Пользователи IAuthUsers создаются только в одном месте - во время входа в систему - путем копирования пользователя, полученного с использованием учетных данных, в частный класс, реализующий общедоступный интерфейс. Они используются для всей аутентификации и авторизации путем опроса содержащегося списка разрешений, спроецированных на основе членства пользователя в группе при запуске. Они никогда не превращаются обратно в изменяемых пользователей и, следовательно, никогда не сохраняются обратно в БД. Между тем, изменяемые пользователи не могут быть превращены в пользователей IAuthUsers вне процесса входа в систему, поэтому они бесполезны для авторизации, и они не могут быть сохранены обратно в БД без предоставления IAuthUser, у которого есть разрешение на внесение изменений, обнаруженных в объекте (путем сравнения его с версией, находящейся в настоящее время в БД)