Безпечне керування серверами через AWS Systems Manager
Поки серверів п'ять, доступ до них тримається на статичних SSH-ключах і списку довірених адрес.
Далі починається знайома деградація: ключі копіюються між інженерами, осідають у листуваннях і резервних копіях, не відкликаються після звільнення співробітника, а сам список дозволених підмереж розростається до стану, коли вже ніхто не пам'ятає, навіщо там той чи інший запис. Прямий доступ до сервера перетворюється на некерований канал.
Ціна такої схеми проявляється в момент розбору інциденту. У журналах залишається факт входу за ключем, але не видно, кому він належить, звідки прийшло підключення і що відбувалося всередині сесії; відкликання доступу — це ручний обхід усіх машин, а не одна дія.
Один спільний ключ на команду вирішує питання швидкості, але повністю обнулює аудит дій адміністратора.
AWS Systems Manager прибирає саму причину: підключення йде не до відкритого порту, а через керовану сесію, де права видаються ролями, відкликання — зняттям ролі, а кожна команда пишеться в журнал із прив'язкою до конкретної людини. Керування серверами без SSH перестає бути винятком і стає штатним режимом роботи.
Нижче розбираємо, як це закривається: які права потрібні інженерам, що робити зі списком ключів, що розрісся, і як налаштувати журналювання, щоб слід залишався за кожною дією.
Що змінюється після відмови від прямих SSH-підключень
Відмова від прямих SSH-підключень — це зміна моделі доступу, а не звички: з'єднання ініціює агент на хості, а права перевіряються на боці AWS Systems Manager. Ось що саме змінюється і за якими ознаками це видно вже першого тижня.
- Закриті вхідні порти. Правило для порту адміністрування зникає з периметра: зовнішнє сканування більше не знаходить відкритого сервісу, а підбір ключів зникає зі звітів про спроби входу.
- Єдина точка входу. Замість розсипу адрес і ключів — один інтерфейс із ролями: підключення до будь-якого хоста йде за однією схемою, і нову машину не потрібно окремо «відкривати назовні».
- Повний журнал команд. Кожна сесія записується повністю — хто, коли і що виконував. Розбір інциденту займає хвилини замість відновлення подій з пам'яті.
- Ротація доступів без зупинки робіт. Сесії живуть обмежений час і продовжуються прозоро для інженера, тому загублений пристрій перестає бути проблемою: постійних ключів на ньому немає.
- Жодних довгоживучих секретів на хостах. Ключі та паролі не розповзаються каталогами й середовищами — доступ видається роллю і відкликається централізовано.
- Скорочення класу інцидентів. Зникають цілі категорії: підбір пароля, забутий відкритий порт після налагодження, «тіньові» ключі в підрядників.
Перевірювана метрика переходу — частка хостів без публічно доступного порту адміністрування і повнота запису сесій.
Варіанти доступу до серверів: порівняння режимів
Режими доступу відрізняються не зручністю, а поверхнею атаки. Чим коротше живе обліковий запис і чим менше портів дивиться назовні, тим менше сценаріїв компрометації — тому вибір режиму це насамперед питання обмежень, які команда готова прийняти на супроводі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Постійний SSH-ключ | Невеликий парк серверів, стабільний склад інженерів, немає вимог аудиту | Ключ не ротується сам: витік приватної частини дає доступ назавжди. Немає зведеного журналу «хто і коли заходив», при звільненні інженера ключ відкликають вручну на кожному хості |
| Доступ на вимогу | Є аудит і вимога короткого строку життя доступу | Потрібні випуск сертифікатів і облікова система. При відмові сервісу випуску вхід не видається взагалі — потрібен окремий аварійний шлях, який сам стає ризиком |
| Керований канал доступу | Порт 22 закритий назовні, вхід іде через агент AWS Systems Manager | Потрібен мережевий вихід агента до сервісу керування або приватний ендпоінт. При відмові каналу залишається тільки консоль, а права описуються політиками на рівні ролей, а не файлом ключа |
| Ізольований контур | Регуляторні вимоги, вихідний трафік в інтернет заборонений | Найважчий у супроводі: приватні ендпоінти, внутрішні дзеркала пакетів, окремий маршрут для оновлення агента. Діагностика інженером віддалено складніша |
На практиці режими комбінують: керований канал як основний шлях, доступ на вимогу — для рутинних робіт, постійний ключ — тільки як аварійний вхід усередині ізольованого контуру. Обмеження режиму доступу фіксують до впровадження, інакше аварійний шлях швидко стає основним.
Впровадження Systems Manager: від аудиту до передачі
Роботу ведемо так, щоб жоден сервер не випав з керування і доступ не став ширшим за потрібний. Спочатку фіксуємо поточний стан, потім змінюємо схему доступу і лише після перевірок вимикаємо прямий вхід по SSH. Нижче — порядок впровадження AWS Systems Manager.
- Інвентаризація серверів. Збираємо перелік вузлів із середовищами, тегами й власниками. Окремо позначаємо те, що живе поза загальним контуром: там зазвичай і залишається вхід за ключами.
- Ролі та політики доступу. Описуємо, кому що дозволено: роль сервера, права інженера, журнали, команди. Права прив'язуємо до груп, а не до людей, — при переведенні доступ збирається сам.
- Розгортання службового компонента. Ставимо агент шаблонами й автоматизацією — нові вузли реєструються самі. Мережевий доступ до службових адрес іде приватними маршрутами.
- Перевірка доступу. Проходимо за списком перевірок: чи відкривається сесія, чи працюють команди, чи видно журнали й метрики, чи не залишилося обхідних шляхів повз нову схему.
- Перевірка відмовостійкості. Дивимося, що буде при недоступності служби й відкликанні прав: сесія закривається, інженер отримує зрозумілу помилку. Окремо перевіряємо відновлення доступу до вузла.
- Передача в експлуатацію. Віддаємо регламенти: як видати доступ новому інженеру, як підключити сервер, як діяти при збої, — плюс схеми ролей і контрольні перевірки.
Кожен етап закінчується робочою схемою, тому перемикання йде без вікна простою — не буває парку, де половина вузлів уже під контролем, а половина на старих ключах.
Комплект документів і налаштувань, який ви отримуєте
Документація щодо доступу — не додаток до зданої інфраструктури, а робочий інструмент: за нею розбирають інцидент о третій ночі, не піднімаючи автора останніх змін. Нижче комплект, який залишається у вас після переведення парку серверів на керування через AWS Systems Manager.
- Схема доступу — хто, з яких мереж і через які точки входу потрапляє на сервери, які маршрути закриті повністю, де залишилися єдині дозволені шляхи.
- Матриця ролей — відповідність «команда або роль → група серверів → допустимі дії». Новий інженер отримує потрібний обсяг прав того ж дня, а не після листування в чаті.
- Конфігурації та політики — файли, з яких доступ піднімається на нових інстансах автоматично, без ручного доведення і «забутих» серверів поза контуром.
- Регламент реагування — порядок дій при втраті зв'язку з вузлом, відкликанні доступу у співробітника, що звільнився, підозрі на компрометацію облікових даних і відмові самого каналу керування.
- Інструкція для чергової зміни — покроковий сценарій на одну сторінку: як відкрити доступ, як завершити чужу завислу сесію, до кого йти при відмові, що фіксувати в журналі.
- Документація з інфраструктури — реєстр серверів із тегами, середовищами й власниками: за ним видно, що підпадає під політику, а що залишилося осторонь.
- Журнал аудиту — куди пишуться команди й вивантаження, скільки зберігаються, як вивантажити історію по конкретному вузлу за потрібний період.
Комплект ведемо у вашому репозиторії поруч із кодом і оновлюємо разом зі змінами в інфраструктурі — так, щоб за півроку документ описував реальний стан, а не стан на день здачі.
Кейс: відмова від прямих підключень на парку серверів
Парк замовника — близько 180 серверів: частина в хмарі, частина на власному майданчику. У кожного з 24 інженерів лежав свій SSH-ключ із безстроковим доступом, копії цих ключів жили на ноутбуках, в образах збірки і в робочих листуваннях.
Новій людині доступ видавали за день-два: поки заведуть обліковий запис, розкладуть ключ по всіх хостах і не забудуть жодного.
Керування перевели на AWS Systems Manager. На кожен інстанс став агент, права видали ролі інстанса, а підключення йде не напряму, а сесією за політикою доступу — із записом усіх команд у журнал.
Прямі підключення закрили на рівні мережевих груп, а ключі видалили з хостів і з конфігурації розгортання.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Серверів під керуванням | 180, доступ вручну | 180, єдина політика |
| Людей із постійним доступом | 24 | 4 (чергова зміна) |
| Час видачі доступу | 1-2 дні | 10-15 хвилин |
| Інциденти з ключами за півроку | 3 втрати або витоки ключа | 0 |
| Серверів із журналом сесій | одиниці | усі |
Права перестали бути безстроковими: доступ видається під задачу, з вікном дії та автоматичним відкликанням — відключити людину тепер означає прибрати її з групи, і це застосовується до всіх хостів одразу. Плановий поворот облікових даних більше не окрема кампанія на тиждень, а регулярна фонова операція.
Що робити, якщо SSH-ключі вже розійшлися по команді
Ситуацію, коли постійні ключі вже розійшлися по команді, за один вечір не закрити.
Успадковані ключі лежать в особистих каталогах інженерів, у конфігурації складальних вузлів і на ноутбуках зовнішніх підрядників, тому відкликати їх одразу — означає відрізати доступ тим, хто прямо зараз тримає бойові сервери.
Починаємо з інвентаризації: які ключі існують, де встановлені, хто ними користується і які роботи на них зав'язані.
Далі йде поступовий перехід, а не перемикання рубильником. На серверах розгортаємо агент AWS Systems Manager і описуємо доступ ролями: інженер відкриває сесію через керований канал, а не за файлом, що лежить на диску, і права видаються під задачу.
Старі ключі на перехідний період залишаються робочими — інакше це буде не міграція, а аварія в розпал робочого дня.
Окрема історія — зовнішні підрядники. Для них доступ видається на строк і прив'язується до облікового запису, а не до чужого публічного ключа: коли роботи закінчені, відкликання доступу — це одна дія в правах, а не обхід десятка машин у пошуках копії.
Кожна сесія при цьому потрапляє в журнал з ім'ям того, хто її відкрив, і командою, яка виконувалася.
Перехідний період закриваємо за вимірюваною ознакою: у журналах не залишилося жодного входу за успадкованим ключем. Тоді блокуємо прямий доступ і вичищаємо старі ключі з довірених списків — але не раніше.
Поки лічильник входів не обнулився, у частини команди є страховка, і перехід не перетворюється на гонку зі строками.
Технічні сумніви перед відмовою від прямого доступу
Перед відмовою від прямого доступу інженери ставлять ті самі питання: що буде при збої сервісу керування, як оновлювати службовий компонент на парку машин, як розділити права між командами й підрядниками і чи залишається аварійний вхід. Нижче — відповіді щодо кожного: від них залежить, виявиться схема робочою чи тільки на папері.
Що буде, якщо сервіс керування недоступний?
Запущені процеси на серверах продовжують іти — керуючий контур не стоїть на шляху трафіку, тому AWS Systems Manager не є точкою відмови для робочих навантажень.
Відмовостійкість доступу даємо точками входу в різних зонах доступності, а службовий компонент зберігає останню видану конфігурацію: недоступна тільки видача нових сесій, парк при цьому не падає.
Як оновлюється службовий компонент на парку машин?
Хвилями через цільові групи: спочатку одна машина, потім група-канарейка, потім решта — з автоматичною зупинкою при відхиленні метрик. Версія компонента фіксується централізовано, обходити сервери вручну не потрібно.
Як розмежувати команди й підрядників?
Права видаємо ролями й мітками ресурсів: команда застосунку бачить лише свої сервери, підрядник — конкретний контур і дозволений набір команд. Кілька хмарних облікових записів зводимо через єдиний вхід, тому список доступів живе в одному місці, а не в таблиці на десять людей.
Чи залишається аварійний доступ?
Так — окремий вузол-бастіон із короткоживучими ключами й обов'язковим записом сесії. Він вмикається за регламентом і закривається після інциденту: постійні ключі на руках в адміністраторів більше не потрібні.
Обговоримо задачу і повернемося з оцінкою та планом
Щоб повернутися з оцінкою та планом, а не загальними формулюваннями, нам потрібен зріз інфраструктури. Далі робота йде за фіксованим порядком — від схеми рішення до супроводу, і на кожному кроці видно, що потрібно від вас і що робимо ми.
- Розбір задачі. Уточнюємо, що саме закриваємо: ручну видачу ключів, спільний доступ під одним користувачем, відсутність журналу дій на серверах або вимоги перевірок з боку служби безпеки.
- Вихідні дані з інфраструктури. Перелік серверів і облікових записів, у яких вони живуть, поточні способи доступу, хто видає й відкликає права, обмеження по мережі, чи є вже агент AWS Systems Manager на машинах.
- Схема рішення та склад робіт. Показуємо, як доступ піде через керовані сесії, які ролі та політики потрібні, де осідають журнали; окремо фіксуємо, що закриваємо ми, що залишається на вашому боці і в якому вигляді здаємо результат.
- План впровадження. Розбиваємо на етапи з точками перевірки: пілот на групі серверів, перенесення решти, відключення попередніх способів доступу — з можливістю відкату на будь-якому кроці.
- Порядок передачі. Віддаємо конфігурації, ролі, шаблони політик і документацію, показуємо черговій зміні, як видати й відкликати доступ, як подивитися історію сесій.
- Підтримка після впровадження. Залишаємося на зв'язку щодо інцидентів і змін: нові сервери підключаються за готовим шаблоном, правила доступу правляться без перезбирання схеми.
Достатньо описати задачу й поточну схему доступу — решту зберемо в ході обговорення і повернемося з оцінкою за етапами.
