> Питання 1: контрольна машина
У Userify (повне розкриття: ми фактично пропонуємо програмне забезпечення для управління ключами ssh), ми постійно працюємо з цим, оскільки ми також запускаємо найбільший склад ключів SSH. Ми, як правило, рекомендуємо локальну установку, а не використання хмарних, оскільки ви збільшили контроль, зменшили площу поверхні, ви можете дійсно заблокувати її до лише відомих надійних мереж.
Важливо пам’ятати, що в правильно складеній такій системі насправді не повинно бути жодних суттєвих секретів, які можуть просочитися до нападника. Якщо хтось заїжджає навантажувачем у ваш центр обробки даних та йде з вашим сервером, він не отримає цілу партію, за винятком деяких сильно хешованих паролів, можливо, деяких сильно зашифрованих файлів та деяких відкритих ключів без відповідних приватних ключів. Іншими словами, не так вже й багато.
Як ви зазначаєте, реальні вектори загроз тут - це те , що відбувається, якщо зловмисник отримає контроль над цією машиною і використовує її для розгортання власних облікових записів користувачів та (відкритих) ключів. Це ризик практично для кожної хмарної платформи (наприклад: Linode). Вам слід сильніше зосередитись на тому, щоб не допустити доступу до контрольної площини, що означає мінімізацію поверхні атаки (лише оголення декількох портів та максимально фіксацію цих портів) та бажано використовувати програмне забезпечення, яке посилено проти ескалації привілеїв та різних атак ( Введення SQL, XSS, CSRF тощо) Дозвольте 2FA / MFA отримати доступ до контрольної площини та зосередитись на тому, щоб максимально заблокувати цю контрольну площину.
Тож чи краще мати в центрі обробки даних спеціалізовану машину управління або машину дистанційного керування (як-от мій ноутбук, віддалено підключений до центру обробки даних)?
Це , безумовно , краще мати спеціальний контрольний апарат в безпечному центрі обробки даних, тому що ви можете ізолювати його і заблокувати його , щоб запобігти / мінімізувати ризик крадіжки або несанкціонованого доступу.
Якщо найкраща практика використовувати свій ноутбук (який може бути вкрадений, звичайно, але я міг би мати мої відкриті ключі надійно збережені в Інтернеті в хмарі або в автономному режимі на переносному зашифроване пристрій), що , якщо мені потрібно використовувати деякі веби - інтерфейси з Відповіді, як Ansible Tower, Semaphore, Rundeck або Foreman, які потрібно встановити на централізовану машину в центр обробки даних?
Вам не потрібно запускати будь-який веб-інтерфейс або вторинну площину управління, щоб керувати своїми ключами (навіть Userify), поки ви не отримаєте достатньо великих розмірів, щоб почати вступати в проблеми управління через більшу кількість користувачів та різний рівень авторизації на серверах або не потрібні додаткові тримання рук для ваших користувачів, які можуть не мати знань або доступу до Ansible для оновлення ключів. Спочатку Userify був не набагато більше, ніж купа скриптів оболонок (сьогодні, мабуть, вони будуть відповіді!), І в цьому немає нічого поганого, поки ви не почнете потребувати додаткового контролю управління та простих способів управління людьми / поворотом їх власні ключі. (Звичайно, будь ласка, подивіться на Userify, якщо ви дістанетесь до цього моменту!)
Як убезпечити його та уникнути, щоб він став "єдиною точкою нападу"?
Ну, звичайно, ознайомтеся з усіма ресурсами в мережі, щоб заблокувати речі, але найголовніше почніть з безпечної основи:
1. Архітектуйте своє рішення з урахуванням безпеки з самого початку. Виберіть технологію (наприклад, базу даних чи мови), у яких традиційно виникало менше проблем, а потім кодуйте із захистом на очах. Очистити всі вхідні дані, навіть від надійних користувачів. Параноїя - чеснота.
2. Врешті-решт все зламається. Мінімізуйте шкоду, коли це відбувається: як ви вже вказували, намагайтеся мінімізувати поводження з секретними матеріалами.
3. Нехай це буде просто. Не робіть найновіші екзотичні речі, якщо ви не впевнені, що це помітно і доказово підвищить вашу безпеку. Наприклад, ми вибрали X25519 / NaCl (libsodium) над AES для нашого шару шифрування (ми шифруємо все, в спокої та в русі), оскільки він спочатку був розроблений та написаний ким-то, кому ми довіряли (DJB та ін.), І його переглянув світ -відомі дослідники, такі як Schneier та команда безпеки Google. Використовуйте речі, що мають тенденцію до простоти, якщо вони новіші, оскільки простота ускладнює приховування глибоких помилок.
4. Відповідати стандартам безпеки. Навіть якщо ви не потрапляєте в режим безпеки на зразок PCI або правила безпеки HIPAA, ознайомтеся з цими стандартами і з’ясуйте, як їх виконати або, принаймні, дуже сильний компенсаційний контроль. Це допоможе гарантувати, що ви справді зустрічаєтеся з «найкращими методами».
5. Запровадьте тестування на зовнішнє / незалежне проникнення і запустіть баунті, щоб переконатися, що ви дотримуєтеся цих кращих практик на постійній основі. Все виглядає чудово, доки ти не знайдеш розумних та високомотивованих людей, що стукають по ньому ... як тільки це закінчиться, ти матимеш велику впевненість у своєму рішенні.
Запитання 2: ключі SSH. Найкращий вибір: нехай Ansible використовує кореневий користувач (його відкритий ключ збережений у ~/.ssh/authorized_keys/ дозволь користувачеві Ansible запускати всі команди за допомогою sudo із зазначенням пароля (який унікальний повинен знати кожен sysadmin) який використовує Ansible для управління цими серверами)
Намагайтеся уникати використання паролів на серверах, навіть для sudo. Це стосується таємниць і в кінцевому підсумку підірве вашу безпеку (ви дійсно не можете дуже легко змінювати цей пароль на sudo між машинами, вам доведеться його зберігати десь; пароль означає, що ви не можете дійсно зробити автоматизацію сервер-сервер, яка є про те, про що йдеться. Крім того, якщо ви залишаєте SSH за його типовими налаштуваннями, ці паролі можуть бути жорстокими, що робить ключі дещо безглуздими, а також уникайте використання root користувача з будь-якою метою, а особливо віддаленого входу.
Створіть непривілейованого користувача, призначеного для Ansible з доступом до sudo / дозвольте користувачеві Ansible виконувати всі команди через sudo, не вказуючи пароль
Саме так. Непривілейований користувач, якого ви можете перевірити до ансибілу, з ролями sudo. В ідеалі створіть стандартного користувача, присвяченого комунікації сервер-сервер / ансібіл з доступом до sudo (без пароля).
... Зверніть увагу: якщо ви використовували Userify, я б запропонував зробити це шляхом створення користувача Userify для ansible (ви також можете розбити це за проектом чи навіть групою серверів, якщо у вас є кілька автовідповідальних машин управління), генеруйте ключ SSH на сервері управління та надайте його відкритий ключ на своїй сторінці профілів Userify. (Це текстове поле по суті стає /home/ansible/.ssh/authorized_keys). Вам слід тримати окремий обліковий запис відповідальної системи від інших облікових записів систем-сервер, таких як віддалений обліковий запис резервного копіювання, секретне управління тощо. Потім запросіть людей, і вони також зможуть створювати та керувати власними ключами, і все залишається відокремленим. Але, як і при блокуванні сервера управління Ansible, спробуйте заблокувати сервер Userify (або будь-яке рішення, яке ви розгортаєте) таким же чином.
будь-які інші підказки?
Я думаю, що ти обов'язково підеш про це правильним шляхом і задаєш правильні запитання. Якщо ви хочете обговорити подібні речі, надішліть мені електронну пошту (ім'я та прізвище на userify), і я буду радий поспілкуватися незалежно від того, в якому напрямку ви рухаєтесь. Удачі!