# Безпечне адміністрування Windows RDP без втрати доступу | SwissOctet Insights https://swissoctet.com/uk/insights/secure-windows-rdp-administration/ SwissOctet / Аналітика / Операції другого дня Операції другого дня Застосовано · 6 хв читання Безпечне адміністрування Windows RDP без втрати доступу Розділіть мережеву доступність, автентифікацію та привілеї, а потім перевірте шлях відновлення, перш ніж посилювати віддалений доступ. Автор: SwissOctet Editorial Зберегти посібник Копіювати посилання НА ЦІЙ СТОРІНЦІ 01 Ставтеся до робочого столу як до адміністративної межі 02 Обмежте доступність, перш ніж покладатися на захист входу 03 Тримайте автентифікацію та довіру явними 04 Зменште те, що може нести сесія 05 Підтримуйте машину та потрібні вам докази 06 Безпечна послідовність першої сесії Ваш практичний контрольний список Джерела та додаткове читання Назад до бібліотеки ПРЯМА ВІДПОВІДЬ Обмежте, хто може дістатися до RDP, залишайте Network Level Authentication увімкненим там, де це підтримується, використовуйте індивідуальні надійні облікові дані та мінімізуйте адміністративні привілеї. Перевірте другу сесію та доступ для відновлення, перш ніж закрити поточне з'єднання. 01 Ставтеся до робочого столу як до адміністративної межі Сесія RDP забезпечує інтерактивний доступ до віддаленої системи, тому обліковий запис, який для неї використовується, може стати цінною ціллю. Почніть із визначення, кому потрібен доступ і яку роботу вони повинні виконувати. Спільний вхід адміністратора зручний, доки вам не потрібно видалити доступ однієї особи або зрозуміти зміну конфігурації. Індивідуальні облікові записи роблять ці операційні завдання зрозумілішими. Відокремте рутинну діяльність від привілейованих змін там, де це дозволяє програмне забезпечення. Користувач, якому потрібен бізнес-застосунок, не обов'язково потребує необмеженого системного адміністрування. Підтримуйте також кінцеву точку адміністратора: захист віддаленої машини не захищає облікові дані, введені з інфікованого чи спільного локального пристрою. Розгляньте обидва кінці сесії в дизайні доступу. 02 Обмежте доступність, перш ніж покладатися на захист входу Вирішіть, які мережі або авторизовані пристрої повинні мати змогу дістатися до хоста сесії. Де ваша архітектура це підтримує, використовуйте контрольований VPN або Remote Desktop Gateway, а не широко відкривайте адміністрування. Microsoft документує RD Gateway як маршрут до внутрішніх ресурсів із політиками авторизації з'єднань і ресурсів. Його придатність залежить від середовища; це не включена функція лише тому, що план підтримує RDP. Обмежте правила брандмауера призначеним шляхом і підтвердьте, як оброблятимуться динамічні адреси клієнтів. Не створюйте обмежувальне правило, яке негайно відключає єдиного адміністратора без варіанта відновлення. Тримайте наявну сесію відкритою, перевірте новий шлях з іншої сесії та задокументуйте авторизований механізм відновлення, перш ніж видаляти старіший маршрут доступу. 03 Тримайте автентифікацію та довіру явними Microsoft рекомендує Network Level Authentication для більшості підтримуваних середовищ. NLA вимагає автентифікації перед встановленням повної віддаленої сесії, додаючи захист на цьому етапі. Вона не замінює брандмауер, політику облікових записів чи оновлення системи. Перевірте сумісність клієнта та усуньте проблеми автентифікації, а не послаблюйте конфігурацію назавжди як першу реакцію. Використовуйте унікальні облікові дані та другий фактор через підтримувану архітектуру доступу, де це можливо. Перевірте очікувану поведінку віддаленої ідентичності та сертифіката, особливо після перебудови чи зміни імені хоста. Попередження про сертифікат заслуговує на розслідування; повторне прийняття неочікуваних ідентичностей перетворює корисну перевірку довіри на ігнорований діалог. Тримайте облікові дані відновлення в затвердженому приватному сховищі. Шар Рішення Перевірка Мережа Які клієнти можуть дістатися до хоста? Неочікувані джерела не можуть підключитися Автентифікація Який обліковий запис і фактори потрібні? Дозволена друга сесія успішна Привілей Які завдання потребують адміністрування? Рутинні користувачі не можуть змінювати системні налаштування Відновлення Як відновлюється доступ після помилки? Задокументований шлях відновлення доступний 04 Зменште те, що може нести сесія Перевірте функції перенаправлення буфера обміну, диска, принтера та інших ресурсів відповідно до фактичного робочого процесу. Адміністратору може не знадобитися доступ до кожного локального ресурсу на віддаленому хості. І навпаки, вимкнення необхідного шляху передачі без альтернативи може спонукати до небезпечних обхідних дій. Задокументуйте дозволений метод переміщення файлів і не зберігайте секрети у звичайних нотатках на робочому столі чи спільних каталогах завантажень. Для відповідних доменних середовищ Microsoft надає Remote Credential Guard, щоб зменшити розкриття облікових даних під час з'єднань RDP. Він вимагає сумісних клієнтів і автентифікації Kerberos та підтримує прямі з'єднання з цільовою машиною; з'єднання через Remote Desktop Gateway або Connection Broker не підтримуються. Перевірте вимоги для вашого фактичного шляху доступу, а не розглядайте його як універсальний захист для окремих розміщених машин Windows. 05 Підтримуйте машину та потрібні вам докази Плануйте оновлення операційної системи та програм, включаючи навмисний процес перезавантаження. Перевірте, чи вимагає оновлення перезавантаження, і після цього перевірте роботу служби. Встановіть розумні політики сеансів для роботи без нагляду або у від'єднаному стані, але враховуйте програми, які мають продовжувати працювати. Політика тайм-ауту повинна відповідати на потребу в безпеці чи експлуатації, а не просто копіювати довільне число з іншого середовища. Зберігайте корисну інформацію про доступ та інциденти відповідно до задокументованої політики. Відстежуйте повторювані збої автентифікації та неочікувану адміністративну активність, не збираючи зайвий вміст. Обмежте коло осіб, які можуть читати діагностичні записи, і визначте, як довго вони потрібні. Точна політика журналювання є більш значущою, ніж як зберігання всього безстроково, так і обіцянка, що жоден операційний запис ніколи не може існувати. 06 Безпечна послідовність першої сесії Після доставки перевірте очікувану систему, змініть тимчасові облікові дані через затверджений процес і встановіть індивідуальний доступ. Підтвердьте маршрут брандмауера та відновлення, потім перевірте друге з'єднання. Застосуйте оновлення, перегляньте перенаправлення та встановіть потрібну програму. Створіть резервну копію та попрактикуйтеся у відновленні важливих налаштувань, перш ніж покладатися на робочий стіл у щоденній роботі. DeskLink RDP та окремі виділені конфігурації пропонують варіанти, пов'язані з Windows, у каталозі SwissOctet. Підтвердьте операційну систему, ліцензування, привілеї облікового запису та обов'язки з управління для вашого замовлення. Підтримуване підключення до робочого столу — це лише початок плану адміністрування; елементи керування, які ви налаштовуєте та перевіряєте, визначають, як використовується цей доступ. ПЕРЕТВОРІТЬ ЦЕ НА ДІЮ Ваш практичний контрольний список. ✓ Використовуйте індивідуальні облікові записи та відповідні привілеї. ✓ Обмежте призначений шлях доступу RDP. ✓ Залишайте NLA увімкненим на сумісних системах. ✓ Перевірте другий сеанс, перш ніж закрити поточний доступ. ✓ Перегляньте перенаправлення, оновлення та політику сеансів. ✓ Підтвердьте ліцензування та процедуру відновлення. Завантажити контрольний список ПОШИРЕНІ ЗАПИТАННЯ Деталі, які мають значення. Чи робить NLA відкритий хост RDP повністю безпечним? + Ні. NLA — це один елемент керування автентифікацією. Доступність, облікові дані, оновлення та привілеї все ще потребують уваги. Чи можу я використовувати Remote Credential Guard на кожному сервері Windows? + Ні. Клієнт, хост і середовище автентифікації повинні відповідати вимогам Microsoft, включаючи відповідну конфігурацію Kerberos. Що мені робити перед посиленням брандмауера? + Перевірте маршрут відновлення, збережіть робочий сеанс і перевірте новий дозволений шлях через друге з'єднання. ОСНОВНІ ДЖЕРЕЛА Перейдіть до джерела. Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи. Microsoft: Увімкнення віддаленого робочого столу та мережевої автентифікації learn.microsoft.com Microsoft: Доступ через Remote Desktop Gateway learn.microsoft.com Microsoft: Remote Credential Guard learn.microsoft.com Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо. ПОЄДНАЙТЕ ЗНАННЯ Пов'язана інфраструктура. DeskLink RDP Швейцарія Metal Atlas Швейцарія Metal EPYC Швейцарія ЗБЕРІГАЙТЕ НИТКУ Ваші наступні польові нотатки. Дослідити всі посібники ПОЛЬОВА НОТАТКА / 01 + Операції другого дня Прикладний Створіть резервну копію, яку справді можна відновити Виберіть ціль відновлення, захистіть незалежну копію та попрактикуйте відновлення, перш ніж інцидент змусить вас це зробити. 4 хв читання Читати посібник ПОЛЬОВА НОТАТКА / 02 + Операції другого дня Прикладний Практична модель загроз для вашого розміщеного проєкту Опишіть активи та межі довіри, виберіть кілька реалістичних сценаріїв збоїв і перетворіть їх на засоби контролю, які можна перевірити. 6 хв читання Читати посібник ПОЛЬОВА НОТАТКА / 03 + Операції другого дня Прикладний Базовий рівень зміцнення Linux VPS, який ви можете підтримувати Забезпечте безпечне адміністрування, відкривайте лише потрібні сервіси та налаштуйте оновлення й відновлення, не заблокувавши себе. 6 хв читання Читати посібник