Через 30 років після свого впровадження, Secure Shell (SSH) залишається універсальним шлюзом для адміністрування, що робить його основною мішенню для атак методом брутфорса і бокового руху в корпоративних середовищах. Для системних адміністраторів і архітекторів безпеки, які працюють під тиском нормативних документів, таких як SOC2, HIPAA і PCI-DSS, стандартні конфігурації SSH є “відкритими дверима”, що представляє неприпустимий ризик. У результаті, доступність часто обходиться безпекою, допускаючи практики, такі як вхід з root і аутентифікація за паролем, які значно розширюють поверхню атаки. У Canonical ми зосередилися на розробці рішень, які закривають ці прогалини, застосовуючи стратегію “глибокої безпеки”, яка поєднує строгий контроль доступу із централізованим управлінням ідентичністю.

Зв’язування систем ідентичності з SSH

Традиційно аутентифікація Linux покладалася на статичні облікові дані, що зберігаються в /etc/passwd або на неуправлявані SSH-ключі, розкидані по файлах authorized_keys. В умовах підприємства це створює величезний “борг ідентичності”, з осиротілими ключами, які залишаються на серверах навіть після звільнення співробітників, створюючи тіньові шляхи доступу.

Для усунення цієї вразливості SSH має безпосередньо інтегруватися з авторитетними джерелами ідентичності. Для локальних середовищ системи, такі як System Security Services Daemon (SSSD), можуть служити мостом до Active Directory. Коли системи Ubuntu приєднуються до домену, SSSD обробляє обмін аутентифікацією, перевіряючи квитки Kerberos і автоматично створюючи домашні каталоги. Це забезпечує динамічне прив’язування привілеїв доступу до групових членств Active Directory, миттєво відкликаючи доступ, коли користувач деактивується в центральному каталозі.

Як ви можете використовувати IdPs для аутентифікації сеансів SSH?

Для організацій, які переходять на постачальників ідентичності в хмарі (IdPs), таких як Microsoft Entra ID або Google Cloud IAM, ми розробили authd. Ця служба модернізує настільний комп’ютер і сервер Linux, використовуючи модульну архітектуру брокера для полегшення аутентифікації через хмарні IdPs.

Для SSH authd використовує OAuth 2.0 Device Authorization Grant (RFC 8628). Оскільки сеанси SSH часто відбуваються на безголових серверах, що не мають веб-браузера, authd ініціює процес аутентифікації через другий пристрій (наприклад, смартфон або ноутбук) з використанням облікових даних IdP. Ця архітектура дозволяє Ubuntu забезпечувати багатофакторну аутентифікацію (MFA) та політики умовного доступу, визначені на рівні IdP, для кожного входу до SSH. Централізуючи аутентифікацію SSH через authd, ми усуваємо залежність від статичних публічних ключів, гарантуючи, що кожен запит на доступ генерує аудитний слід, пов’язаний з керованою хмарною ідентичністю.

Відповідність вашим вимогам щодо контролю та криптоаналізу

Для сектора, що підлягає жорсткому регулюванню, задоволення вимог контролю відповідності є необов’язковим. Ubuntu Pro, всебічна підписка Canonical для безпеки з відкритим кодом, забезпечує інфраструктуру, необхідну для виконання строгих стандартів, таких як NIST, DISA-STIG і PCI-DSS. Ці рамки вимагають суворих технічних контролів стосовно рівнів впевненості в аутентифікації та управлінню сесіями.

З Ubuntu Pro організації можуть автоматизувати застосування стандартів безпеки та профілів жорсткості по всьому парку. Це гарантує, що криптографічні обміни та протоколи управління ключами, що лежать в основі з’єднань SSH, відповідають підтвердженим стандартам, необхідним для аудитів. Ми надаємо інструменти, щоб гарантувати, що ваша безпека шлюзу є не лише теоретичною, а й відповідною за своєю суттю.

Чи можете ви впроваджувати політики в масштабах?

Визначення безпечної конфігурації є лише половиною битви. Але її реалізація на тисячах вузлів є справжнім викликом. За допомогою Adsys адміністратори можуть поширювати Objects политики групи (GPO) на клієнти Ubuntu.

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

Контрольний список безпеки: посилення SSH

Для зменшення поверхні атаки вашої інфраструктури Ubuntu ми рекомендуємо реалізувати наступні заходи посилення.

• Вимкнути доступ з root: встановіть PermitRootLogin no в sshd_config для примусу до підзвітності користувачів.
• Усунути паролі: встановіть PasswordAuthentication no і вимагайте аутентифікацію з використанням публічного ключа або IdP.
• Впроваджувати MFA: інтегруйте libpam-google-authenticator або використовуйте authd з Entra ID/Google IAM для багатофакторної верифікації.
• Обмежити мережевий доступ: використовуйте брандмауери, щоб дозволити підключення SSH лише з довірених діапазонів IP або VPN.
• Активний моніторинг: налаштуйте Fail2Ban для моніторингу журналів аутентифікації та автоматично забороняйте IP-адреси, які демонструють поведінку брутфорса.
• Змінити стандартні порти: налаштуйте SSH для прослуховування на нестандартному порту (наприклад, 2222), щоб зменшити шум від автоматизованих сканерів.

Читати більше в нашому білому папері про управління ідентичністю

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

Ми надаємо технічний аналіз сучасних парадигм ідентичності, включаючи детальні конфігурації для управління доступом до хмарної та локальної Linux-інфраструктури, а також практичні стратегії для безшовної та безпечної інтеграції з усталеними послугами домену AD. Крім того, у документі пропонується детальний аналіз переваг та етапів впровадження використання сертифікатів SSH для безперешкодної та аудитованої аутентифікації SSH, виходячи за межі простого управління ключами.

Читайте білоруський папір про управління ідентичністю Ubuntu Enterprise.

Додаткова література

• Документація ADSys
• Документація Authd
• Authd для Entra ID на Snapcraft
• Authd для Google IAM на Snapcraft
• Authd для OIDC на Snapcraft