Дозволити користувачам адміністратора входити в систему як інші користувачі

11

Як ви вважаєте, це вдала практика впровадити можливість дозволити користувачеві-адміністратору увійти як інший користувач, передаючи пароль? Це може бути реалізовано головним паролем або функцією всередині адміністрації користувача "Увійти як цей користувач".

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

security problem-solving

— Ден МакГрат
джерело

9

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

— xmm0

1

+1 Мехрдаду Афшарі. Я плачу кожного разу, коли чую, як люди говорять про адміністратора, як це.

— Ден МакГрат

2

@Mehrdad Afshari та @Dan McG, це все добре і правда, але що ви пропонуєте робити, коли адміністратору потрібен доступ до облікового запису користувача у повсякденній ситуації? Попросити користувача ввести свої облікові дані? Дуже часто трапляється, що для підтвердження або відтворення проблеми потрібно перевірити налаштування конкретного користувача, особливо коли облікові записи прив’язані до складних прав та інших налаштувань, які не можуть бути відтворені 1: 1 з нейтральним обліковим записом.

— Pekka

4

Ви дивитесь на це неправильно. Якщо адміністратору потрібно перевірити налаштування користувачів, нам потрібно розробити кращі інструменти для отримання цієї діагностичної інформації від користувача. Наприклад: Якщо ваш додаток у Windows виходить з ладу, чи хочете ви, щоб якийсь адміністратор MS перейшов у Redmond RDPing у ваш обліковий запис користувача, щоб перевірити речі, чи ви хочете високоавтоматизований спосіб надсилання необхідної інформації назад до них (на розсуд користувача) ?

— Ден МакГрат

2

@Dan: Замовник може не бажати платити за це.

15

Ні, зовсім ні. Це порушує поділ обов'язку.

Це також викликає хаос, покладаючись на журнали, щоб показувати дії користувача.

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

Крім того, користувачам адміністратора не завжди слід надавати всі права, які має користувач. Наприклад, у користувача можуть бути поважні причини перегляду номерів кредитних карток у системі. Адміністратор не повинен; ці дані не є частиною їх роботи. Знову це зводиться до сегрегації обов'язків.

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

— Ден МакГрат
джерело

2

Хоча у вас є дійсні пункти, я не думаю , що відповідь зовсім так зрозуміло - в деяких випадках це є найкращим рішенням.

— sleske

11

З точки зору принципів безпеки та чистого програмування, це не дуже гарна ідея. Але це може бути величезною зручністю в повсякденній роботі для адміністратора, саме тому я за це, якщо добре впроваджений.

Для мене, нормальна реалізація повинна відповідати таким вимогам:

Система зареєструє вас як відповідний користувач, але обходить аутентифікацію пароля, якщо ви ввійшли як адміністратор.
Система через прапор усвідомлює, що це не користувач x, а адміністратор, який увійшов як користувач x. Будь-який об'єкт лісозаготівлі відображав би різницю.
Немає способу "вирватися" з входу користувача назад на рівень адміністратора.

Це насправді може покращити безпеку, оскільки адміністратору не потрібно шукати та використовувати облікові дані користувачів, що насправді часто трапляється з причин, про які йдеться в ОП: Щось потрібно перевірити, протестувати тощо ... на акаунті користувача .

— Пекка
джерело

8

Як завжди ... це залежить. Відповіді немає простого, і обидві системи використовуються на практиці (наприклад, Windows: Адміністратор не може увійти як користувач без скидання пароля проти Linux: Адміністратор може увійти як локальний користувач su).

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

Крім того, ви можете використовувати шаблон, який використовує Windows: Адміністратор не може увійти як інший користувач, але адміністратор може скинути пароль користувача. Таким чином адміністратор може отримати доступ, але користувач завжди буде знати, що хтось отримав доступ до його акаунта.

— Хайнці
джерело

Nitpick: sudoне входить у систему як локальний користувач, він просто запускає один процес як користувач (a la Window "Запустити як користувач"). Щоб увійти як локальний користувач, використовуйте su. В іншому випадку я згоден.

— sleske

@sleske: Звичайно, дякую, що помітили це. Виправлено.

@sleske: не обов’язково, дивіться sudo -i.

— liori

Ідея "оболонки для входу" більше пов'язана з тим, як shповодиться виконуваний файл, ніж з тим, які дозволи надаються. su - userі sudo -u user shнадавати однаковий доступ; Різниця полягає в тому, що вони shвиконують різні сценарії запуску.

— jpaugh

3

Ну, phpBB3 має функцію "Тестування дозволів користувача" для адміністраторів, що дуже корисно. Крім того, це не дозволяє вам втручатися в цей обліковий запис користувачів, але дійсно просто отримуєте досвід, який вони мають, виходячи з їх дозволів.

Але насправді вхід у систему як хтось інший виникає з низкою проблем, як згадували інші.

— back2dos
джерело

1

Так, такий функціонал може бути проблематичним, але іноді іншого шляху немає, тому це може знадобитися.

Деякі приклади:

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

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

Що стосується реєстрації / аудиту: Використання цієї функції, звичайно, має бути зареєстровано. Крім цього, вам доведеться довіряти своєму адміністратору, щоб не зловживати ним. Але це справедливо для адміністраторів загалом.

Якщо вам потрібно більше обмежувати своїх адміністраторів, вам потрібна якась система MAC (обов'язковий контроль доступу), без "справжнього" адміністратора. Це можливо, але набагато складніше, тому це компроміс.

— sleske
джерело