Чи погана звичка входити в систему як спільний користувач?

Я працював в організаціях, де замість створення нового користувача Ubuntu на людину, яка хоче увійти в машину, sysadmins просто додає ключ ssh кожного користувача .ssh/authorized_keys, а всі - sshдо машини як ( наприклад ) ubuntu@hostабо ec2-user@host. (Між іншим, я також бачив, як це практикується на спільних Mac minis в лабораторних умовах.) Це прийнята практика чи анти-модель?

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

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

Якщо причиною цієї схеми розподілу uid є просто зменшення адміністративних витрат на створення нових облікових записів та конфігурацію спільного доступу, то, можливо, адміністраторам слід вкласти певний час в систему автоматизації, як Ansible , Chef , Puppet або Salt, яка робить такі речі, як створення користувачів рахунки на декількох машинах надзвичайно прості.

Для початку це мене не шокує, і я працюю в надзвичайно захищеному середовищі. У кожного є власний користувальницький і машинний і ssh ключ, і для роботи на сервері ми входимо, як root, або як інший користувач, через реле журналу, якщо це необхідно. Все, що ми робимо, записується як власник ключа ssh, тому підзвітність нормальна.

Якою була б альтернатива? Багато речей потрібно робити як певний користувач, не кажучи вже про root. Судо? Це нормально для деяких дуже обмежених завдань, але не для систематичного управління машиною.

Однак я не впевнений у твоєму останньому абзаці, ти маєш на увазі, що хтось може підштовхнути git виконувати загальний користувач? Це порушило б підзвітність, а порушення звітності - це погано. Ми робимо git з машини, на якій ми увійшли в систему, і ми підтверджуємо автентифікацію git за допомогою нашого ключа ssh ...

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

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

Але для щоденної роботи, коли хтось помиляється, коли ціла компанія не може працювати, не є хорошою ідеєю.

Усі ці відповіді стосуються занепокоєння підзвітності, що є важливим і реальним питанням, але використання спільного облікового запису також дозволяє здійснити не дуже тонкі атаки на інших користувачів:

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

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

Загалом, обмін одним обліковим записом є поганою ідеєю з наступних причин:

1. Кожна налаштування, зроблена для цього користувача, впливає на всіх, хто входить у систему. (Promt, псевдоніми, ...)
   2. Ви втрачаєте можливість дізнатися, хто що робив (підзвітність)
   3. Одна помилка в конфігурації облікового запису (наприклад, випадкове видалення ssh kay) стосується всіх, хто користується цим обліковим записом користувача (у цьому прикладі блокується).

І напевно впевнені, що є ще більше недоліків ... Але я не хочу вникати в це далі.

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

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

Інструменти аудиту все одно дозволять вам відстежувати, хто що виконав, але все ще ділиться тим самим обліковим записом.