Чи погано використовувати судо від Дженкінса?

Я використовую плагін Publish Over SSH для розгортання моїх програм Jenkinsу різних середовищах. Деякі завдання розгортання виконують підготовку до середовища та такі дії, як зупинка та перезапуск сервісної системи сервера додатків. Деякі з цих команд вимагають sudo.

Мені просто цікаво, чи може бути поганою практикою безпеки вимагати судо в рамках віддалених публікацій та виконання завдань Дженкінса. Чи слід змінювати політику безпеки на цільовому хості, щоб дозволити виконувати необхідні функції без sudo?

Ні, це насправді дуже хороша практика безпеки, щоб судо, коли потрібні привілеї вищого рівня. Це причина, що більшість дистрибутивів забороняє вхід за замовчуванням і насправді змушує вас sudo suзамість того, щоб просто набирати текст su- вони хочуть заохотити вас використовувати sudo для переваг безпеки. Є кілька причин, чому:

• Аудит. Коли ви судо, система веде облік того, хто судів та команди, яку вони виконували. Це суттєво додає криміналістичну оцінку, коли вам потрібно повернутися назад і з’ясувати, що трапилося - призначити провину, зловити козливі дії або просто з метою усунення несправностей (що в пеклі сталося минулої ночі о 19:00, перш ніж цей сервер пішов AWOL?)

• Судо правила. Тільки тому, що користувачеві потрібно запустити щось із нарощеними привілеями, не означає, що їм потрібно запускати все з ескалаційними привілеями. Використання su або додавання користувача до колеса дозволяє користувачеві робити все . За допомогою sudo, однак, можна вказати, що користувачі можуть, а що не можуть робити, використовуючи Псевдоніми команд, які дозволяють використовувати символи символів, тим самим дозволяючи гнучкі правила, що надають користувачам привілеїв використовувати деякі команди, але не інші.

• Загартовування. Можна відключити root. Як і в усіх цілях і цілях, вона не існує і є корисною / корисною лише в режимі одного користувача - вимагає перезавантаження сервера (і єдиною причиною, для якої це дозволено, є відновлення пароля). sudo suбільше не працює. Це робиться, встановивши оболонку кореня на / bin / nologin. це чудовий спосіб запобігти багатьом вразливості кореневих ескалацій. Це, звичайно, передбачає, що ви правильно використовуєте кулю вище (і ви все одно можете надати певному дозволу адміністратора всі дозволи, хоча це може підірвати вашу безпеку).

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

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

Чи дозволяєте ви віддалений sudoчи віддалений доступ до чогось, що має у SUID rootвас досить схожу поверхню атаки. Я б утримувався sudoв ланцюжку, тому що він дозволяє вам легко обмежувати команди і має журнал, який буде життєво важливим, якщо вам потрібно буде перевірити речі пізніше. sudoтакож має набагато довшу історію виробництва. Якщо робити щось інше, буде менше історії та вищих змін неприємних сюрпризів.

Існує й інше, що можна зробити, щоб зробити це більш безпечним:

• підтягнути ssh
• дозволяти лише команди перезапуску для декількох конкретних користувачів, включаючи одного для jenkins
• дозволяють входити в систему лише для тих конкретних користувачів із усіх внутрішніх IP-адрес або просто джинкінів та IP-адрес для стрибків
• зберігайте журнали на віддалених коробках, щоб їх не можна було вимкнути