Віддалений консультант адміністратора Linux - найкраща практика [закрито]

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

Яка найкраща практика для надання віддаленому консультанту такої роботи, щоб ми були захищені від будь-якої злоякісної діяльності?

Заздалегідь спасибі.

Не варто . Крім того , ви в такий же небезпеки бездарності як злість від того, що я бачив звичайним способом компанії впоратися з цим.

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

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

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

Тепер, коли я вирішив "невмілість" його частини,

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

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

Як вже було сказано, не робіть цього.

Єдиний спосіб захистити себе - це зробити щось подібне:

1. Наполягайте, щоб консультант використовував систему керування конфігурацією на ваш вибір.
2. Консультант запише маніфести управління конфігурацією для дій, які потрібно виконати.
3. Консультант перевірить маніфести на тестовій системі.
4. Після готовності консультант здійснить конфігурацію в сховищі коду.
5. Усі зміни переглядає або член вашого персоналу, або іншим консультантом, який абсолютно не має відношення до першого, і не має можливості контактувати з ними.
6. Після підписання змін вони застосовуються до сервера вами або членом вашого персоналу. Оригінальний консультант не повинен мати доступу до жодної вашої системи.

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

Однак, як я рекомендував, вам набагато краще найняти відому, довірену особу.

Яка найкраща практика для надання віддаленому консультанту такої роботи, щоб ми були захищені від будь-якої злоякісної діяльності?

З юридичної точки зору: попередня ретельність та суворі штрафи за порушення договору.

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

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

І палиця : порушуйте умови вашого трудового / службового договору, і ми захворімо наших адвокатів на вас і залишимо вас банкрутом!

На жаль, і вищезгадане стає все складніше при перетині кордонів та часових поясів.

Як тільки ви вирішите найняти когось:

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

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

Існує один системний метод захисту себе, який спадає на думку, про який я не бачив.

Розмістіть ваші екземпляри Linux як VM на гіпервізорі віртуалізації (VMware, Xenserver, Hyper-V тощо).

НЕ надайте віддаленому адміністратору адміністративний доступ до гіпервізора. Віддалений адміністратор отримав би лише корінний доступ до самих VM.

DO Впровадити систему резервного копіювання на основі гіпервізора (Unitrends, Veeam, vSphere Data Data Protection тощо)

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

НЕ надайте віддаленому адміністратору запису на доступ до резервних сховищ.

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

Це не буде доказом проти нападу бічного каналу гіпервізора, який потенційно може бути встановлений з VM, до якого зловмисник має кореневий доступ.

Якщо ваші резервні копії не піде досить далеко назад у часі, це не захистить вас.

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

Якщо ви робите це у хмарі (AWS, Azure тощо), деталі реалізації будуть відрізнятися, але загальна концепція була б однаковою.

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

Дайте йому власний обліковий запис користувача. Тоді з’ясуйте, до чого саме він потребує доступу, і надайте саме цей доступ, але нічого іншого. Наприклад, якщо йому потрібно переконфігурувати веб-сервер Apache, використовуйте ACL, щоб надати йому доступ до записів до файлів конфігурації Apache та налаштувати sudoйого, щоб він перезапустив службу Apache, але не виконував жодних інших команд як root. Як завжди, зберігайте резервні копії всього, до чого ви надаєте йому доступ (у цьому випадку ваші файли конфігурації Apache).