Обмежте, хто може дістатися до RDP, залишайте Network Level Authentication увімкненим там, де це підтримується, використовуйте індивідуальні надійні облікові дані та мінімізуйте адміністративні привілеї. Перевірте другу сесію та доступ для відновлення, перш ніж закрити поточне з'єднання.
Ставтеся до робочого столу як до адміністративної межі
Сесія RDP забезпечує інтерактивний доступ до віддаленої системи, тому обліковий запис, який для неї використовується, може стати цінною ціллю. Почніть із визначення, кому потрібен доступ і яку роботу вони повинні виконувати. Спільний вхід адміністратора зручний, доки вам не потрібно видалити доступ однієї особи або зрозуміти зміну конфігурації. Індивідуальні облікові записи роблять ці операційні завдання зрозумілішими.
Відокремте рутинну діяльність від привілейованих змін там, де це дозволяє програмне забезпечення. Користувач, якому потрібен бізнес-застосунок, не обов'язково потребує необмеженого системного адміністрування. Підтримуйте також кінцеву точку адміністратора: захист віддаленої машини не захищає облікові дані, введені з інфікованого чи спільного локального пристрою. Розгляньте обидва кінці сесії в дизайні доступу.
Обмежте доступність, перш ніж покладатися на захист входу
Вирішіть, які мережі або авторизовані пристрої повинні мати змогу дістатися до хоста сесії. Де ваша архітектура це підтримує, використовуйте контрольований VPN або Remote Desktop Gateway, а не широко відкривайте адміністрування. Microsoft документує RD Gateway як маршрут до внутрішніх ресурсів із політиками авторизації з'єднань і ресурсів. Його придатність залежить від середовища; це не включена функція лише тому, що план підтримує RDP.
Обмежте правила брандмауера призначеним шляхом і підтвердьте, як оброблятимуться динамічні адреси клієнтів. Не створюйте обмежувальне правило, яке негайно відключає єдиного адміністратора без варіанта відновлення. Тримайте наявну сесію відкритою, перевірте новий шлях з іншої сесії та задокументуйте авторизований механізм відновлення, перш ніж видаляти старіший маршрут доступу.
Тримайте автентифікацію та довіру явними
Microsoft рекомендує Network Level Authentication для більшості підтримуваних середовищ. NLA вимагає автентифікації перед встановленням повної віддаленої сесії, додаючи захист на цьому етапі. Вона не замінює брандмауер, політику облікових записів чи оновлення системи. Перевірте сумісність клієнта та усуньте проблеми автентифікації, а не послаблюйте конфігурацію назавжди як першу реакцію.
Використовуйте унікальні облікові дані та другий фактор через підтримувану архітектуру доступу, де це можливо. Перевірте очікувану поведінку віддаленої ідентичності та сертифіката, особливо після перебудови чи зміни імені хоста. Попередження про сертифікат заслуговує на розслідування; повторне прийняття неочікуваних ідентичностей перетворює корисну перевірку довіри на ігнорований діалог. Тримайте облікові дані відновлення в затвердженому приватному сховищі.
| Шар | Рішення | Перевірка |
|---|---|---|
| Мережа | Які клієнти можуть дістатися до хоста? | Неочікувані джерела не можуть підключитися |
| Автентифікація | Який обліковий запис і фактори потрібні? | Дозволена друга сесія успішна |
| Привілей | Які завдання потребують адміністрування? | Рутинні користувачі не можуть змінювати системні налаштування |
| Відновлення | Як відновлюється доступ після помилки? | Задокументований шлях відновлення доступний |
Зменште те, що може нести сесія
Перевірте функції перенаправлення буфера обміну, диска, принтера та інших ресурсів відповідно до фактичного робочого процесу. Адміністратору може не знадобитися доступ до кожного локального ресурсу на віддаленому хості. І навпаки, вимкнення необхідного шляху передачі без альтернативи може спонукати до небезпечних обхідних дій. Задокументуйте дозволений метод переміщення файлів і не зберігайте секрети у звичайних нотатках на робочому столі чи спільних каталогах завантажень.
Для відповідних доменних середовищ Microsoft надає Remote Credential Guard, щоб зменшити розкриття облікових даних під час з'єднань RDP. Він вимагає сумісних клієнтів і автентифікації Kerberos та підтримує прямі з'єднання з цільовою машиною; з'єднання через Remote Desktop Gateway або Connection Broker не підтримуються. Перевірте вимоги для вашого фактичного шляху доступу, а не розглядайте його як універсальний захист для окремих розміщених машин Windows.
Підтримуйте машину та потрібні вам докази
Плануйте оновлення операційної системи та програм, включаючи навмисний процес перезавантаження. Перевірте, чи вимагає оновлення перезавантаження, і після цього перевірте роботу служби. Встановіть розумні політики сеансів для роботи без нагляду або у від'єднаному стані, але враховуйте програми, які мають продовжувати працювати. Політика тайм-ауту повинна відповідати на потребу в безпеці чи експлуатації, а не просто копіювати довільне число з іншого середовища.
Зберігайте корисну інформацію про доступ та інциденти відповідно до задокументованої політики. Відстежуйте повторювані збої автентифікації та неочікувану адміністративну активність, не збираючи зайвий вміст. Обмежте коло осіб, які можуть читати діагностичні записи, і визначте, як довго вони потрібні. Точна політика журналювання є більш значущою, ніж як зберігання всього безстроково, так і обіцянка, що жоден операційний запис ніколи не може існувати.
Безпечна послідовність першої сесії
Після доставки перевірте очікувану систему, змініть тимчасові облікові дані через затверджений процес і встановіть індивідуальний доступ. Підтвердьте маршрут брандмауера та відновлення, потім перевірте друге з'єднання. Застосуйте оновлення, перегляньте перенаправлення та встановіть потрібну програму. Створіть резервну копію та попрактикуйтеся у відновленні важливих налаштувань, перш ніж покладатися на робочий стіл у щоденній роботі.
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. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо.