Разрешить пользователям с правами администратора входить в систему как другие пользователи

11

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

Администраторы запрашивают такую функцию, чтобы попытаться воспроизвести сообщенную проблему или проверить, например, в порядке ли гранты.

security problem-solving

— Дэн МакГрат
источник

9

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

— xmm0

1

+1 Мехрдаду Афшари. Я съеживаюсь каждый раз, когда слышу, как люди говорят об этом админе.

— Дэн МакГрат,

2

@ Mehrdad Afshari и @Dan McG, это все хорошо и верно, но что вы предлагаете делать, когда администратору требуется доступ к учетной записи пользователя в повседневной ситуации? Попросить пользователя ввести свои учетные данные? Очень часто случается, что для проверки или воспроизведения проблемы необходимо проверить настройки конкретного пользователя, особенно когда учетные записи связаны со сложными правами и другими настройками, которые невозможно воспроизвести 1: 1 с нейтральной учетной записью.

— Pekka

4

Вы смотрите на это неправильно. Если администратору необходимо проверить настройки пользователя, нам необходимо разработать более совершенные инструменты для получения этой диагностической информации от пользователя. Например: если ваше приложение в Windows дает сбой, вы хотите, чтобы какой-нибудь администратор MS в Redmond RDPing перешел в вашу учетную запись пользователя, чтобы проверить вещи, или вам нужен высокоавтоматизированный метод отправки необходимой информации обратно (по усмотрению пользователя) ?

— Дэн МакГрат,

2

@ Дан: Клиент может не захотеть платить за это.

15

Нет, совсем нет. Это нарушает разделение обязанностей.

Это также приводит к хаосу при использовании журналов для отображения действий пользователя.

Если вам действительно нужно проверить подобные вещи, у администратора также должна быть фиктивная тестовая учетная запись (и), настроенная как пользователи. Таким образом, они могут сначала подтвердить правильность предоставления прав и т. Д. Для тестового пользователя.

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

Минимизируйте свое воздействие, сводя к минимуму предоставление несоответствующих прав. Это должно включать администраторов, а также ...

— Дэн МакГрат
источник

2

Хотя у вас есть действительные пункты, я не думаю , что ответ совсем так понятно - в некоторых случаях это является лучшим решением.

— Слеське

11

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

Для меня реализация ok должна соответствовать следующим требованиям:

Система регистрирует вас как рассматриваемого пользователя, но обходит аутентификацию по паролю, если вы вошли как администратор.
Система знает через флаг, что это не пользователь x, а администратор, вошедший в систему как пользователь x. Любое средство регистрации будет отражать разницу.
Невозможно «вырваться» из входа пользователя на уровень администратора.

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

— Пекка
источник

8

Как всегда ... это зависит. Простого ответа нет, и обе системы используются на практике (например, Windows: администратор не может войти в систему как пользователь без сброса пароля по сравнению с Linux: администратор может войти в систему как локальный пользователь, используя su).

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

В качестве альтернативы вы можете использовать шаблон, который использует Windows: администратор не может войти в систему как другой пользователь, но администратор может сбросить пароль пользователя. Таким образом, администратор может получить доступ, но пользователь всегда будет знать, что кто-то получил доступ к его учетной записи.

— Heinzi
источник

Nitpick: sudoне регистрирует вас как локального пользователя, он просто запускает один процесс как пользователь (а-ля Window в «Запуск от имени пользователя»). Чтобы войти как локальный пользователь, используйте su. В противном случае я согласен.

— слеске

@Sleske: Конечно, спасибо, что заметили это. Исправлена.

@sleske: не обязательно, посмотрите sudo -i.

— Лиори

Идея «оболочки входа в систему» больше связана с тем, как shведет себя исполняемый файл, чем с тем, какие разрешения предоставляются. su - userи sudo -u user shпредоставить такой же доступ; Разница в том, что shзапускаются разные сценарии запуска.

— jpaugh

3

Что ж, phpBB3 имеет функцию «Проверка прав пользователя» для администраторов, которая действительно полезна. Кроме того, это не позволяет вам вмешиваться в эту учетную запись пользователя, но на самом деле просто получить опыт, который они имеют, основываясь на их разрешениях.

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

— back2dos
источник

1

Да, такая функциональность может быть проблематичной, но иногда нет другого пути, поэтому она может быть необходимой.

Несколько примеров:

В Unix / Linux эта функциональность существует ( su - <username>что дает тот же результат, что и вход в систему от имени этого пользователя, но не требует пароля для пользователя root)
у приложения, над которым я работаю, также есть это, и это важно для устранения проблем с личными настройками пользователя (из которых наше приложение имеет много)

Как уже указывалось, если сложные параметры зависят от пользователя, вошедшего в систему (переменные среды, пути, личные настройки в приложении), часто не существует другого практического способа отладки проблемы пользователя.

Что касается ведения журнала / аудита: использование этой функции, конечно, должно быть зарегистрировано. Кроме этого, вы должны доверять своему администратору, чтобы не злоупотреблять им. Но это действительно для администраторов.

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

— sleske
источник