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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

Answer 2

" Сложность - худший враг безопасности. " - Брюс Шнайер

Для построения очень безопасной системы я бы положился на Active Directory для управления доступом всей компании.Самая важная часть предложенной вами системы безопасности заключается в том, что она не использует неясную функциональность, чтобы обмануть злоумышленников.Вместо этого использование Active Directory означает, что ваша система контроля доступа будет активно поддерживаться Microsoft.К какой платформе вы привязаны.

Это решение не является пуленепробиваемым.Вам все еще нужно беспокоиться о LDAP Injection .

Answer 3

Да, это звучит чрезмерно.

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

Будете ли вы динамически загружать ненадежный код плагина во время выполнения? Почему тогда защита кода просто потребляет вашу библиотеку.

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

Например, Rhino Security . У Айенде есть несколько сообщений в блоге об этом .

В другом блоге тоже есть пара из статей .

Answer 4

На самом деле это звучит правдоподобно.

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

class UserContext
{

    IList<PersistentObject> thingsUserHasChanged;


    public void Commit()
    {
        foreach(PersistentObject pobj in thingsUserHasChanged)
        {
            if(Security.PermitsUserToCommit(currentUser,pobj)) pobj.Commit();
        }
    }
}