История вопроса: в настоящее время мы управляем нашими серверами через IP KVM, но мы медленно переход на VMWare ESXi. Интерфейс KVM неуклюж, а управление пользователями немного громоздко, и я бы хотел, чтобы люди подальше от консоли VIC, если это возможно. RDP не разрешен в нашей сети, поскольку весь трафик должен проходить через VIC или KVM, которые имеют сертификаты от внутреннего центра сертификации.
Вопрос: Я использую этот переход, чтобы подтолкнуть к RDP для внутреннего управления серверами. Я хотел бы привести доводы в пользу RDP, но безопасность (даже если эти серверы не выходят в Интернет) по-прежнему вызывает беспокойство. Я посмотрел на TS Gateway, но похоже, что он предназначен для Интернета на удаленный сервер, а не от внутреннего клиента к внутреннему серверу. Я знаю, что это довольно широко, и, пожалуйста, не стесняйтесь спрашивать разъяснения, но каков наилучший способ безопасного внедрения RDP на внутренних серверах.
Как и в случае с любой технологией - ограничивайте площадь поверхности. Не оставьте простой Джейн RDP открытым для мира. Требуется VPN или какой-либо другой вид сквозной аутентификации от надежного поставщика (шлюз web-ssl и т. Д.).
Для внутреннего использования - должны быть в наличии стандартные политики управления паролями с настроенной блокировкой. Настройте RDP для использования наивысшего уровня безопасности (принудительное использование RDP 128-битного шифрования через GPO). RDP - это по крайней мере так же безопасно, как VIC или большинство KVM. Миллионы людей ежедневно используют Citrix или Terminal Services. VIC и KVM просто не имеют такого количества установленных устройств или людей, пытающихся их использовать. Учитывая две конкурирующие зрелые технологии без известных эксплойтов, Я бы посчитал тот, у которого много значений установленной базы, более безопасным, чем тот, у кого ограниченная база установки, как правило, скрытая внутри частной сети с помощью проприетарных инструментов от одного производителя.
Для внешних клиентов я бы рассмотрел сторонний безопасный шлюз SSLVPN с аутентификацией сертификата клиента, если вам нужен такой уровень безопасности.
Если вы серьезно не доверяете RDP, но доверяете, скажем, SSH ... существует коммерческое приложение RDP через SSH под названием WiSSH который может реализовать двухфакторную аутентификацию вместе с двумя отдельными уровнями безопасности.
RDP был опцией при каждой установке Windows XP Professional и Windows Server с 2000 года. то инструмент управления удаленным доступом для серверов Windows, и за последние 9 лет обнаружил очень мало уязвимостей. Четный WindowsSecurity.comСписок предложений банален по своей сложности и отражает лучшие практики любой другой системы управления.
Большая часть этого уже упоминалась, но я подумал, что могу прояснить несколько вещей. NLA поддерживается (под другим именем) для RDP, по крайней мере, с одного из пакетов обновления Windows 2003. Запуск RDP в конфигурации с «высоким уровнем безопасности» в сочетании с запуском RDP через TLS, вероятно, в равной степени безопасен для большинства альтернативных решений для удаленного управления доступно для окон. Я защищал свои сеансы RDP через TLS в течение многих лет, и клиент XP определенно поддерживал подключение к RDP через TLS в течение столь же многих лет.
Я также использовал TS-Gateway как способ дальнейшего безопасного доступа между офисными сетями и внутренними сетями серверов. Обычно для этого требуются правила брандмауэра / маршрутизации между двумя сетями, но если вы хотите еще больше защитить свою среду, добавив дополнительные требования аутентификации и туннелированную точку входа, TS-Gateway может быть очень полезен. Но в отличие от RDP через TLS, поддержка TS-Gateway очень ограничена с точки зрения клиента.
Что касается использования самого RDP, вы в значительной степени ограничены тем, что поддерживает клиент и сервер, и существует всего несколько версий. С Win2008, Windows 7, Vista (и, по-видимому, теперь и с XP SP3) http://technet.microsoft.com/en-us/library/cc732713.aspxаутентификация на сетевом уровне улучшила безопасность RDP, но что касается защиты самого протокола, ваш единственный вариант - требовать NLA как на клиенте, так и на сервере.
Выйдя за пределы самого RDP, вы используете свою сетевую архитектуру для ограничения доступа к своим серверам. Поместите свои серверы в отдельную подсеть, поместите административные компьютеры в другую, а обычных пользователей - в еще одну. Разрешите только подсети администратора получить доступ к подсети сервера через RDP на вашем брандмауэре / маршрутизаторе и разрешите подсети обычного пользователя получать доступ к подсети сервера только через необходимые порты (или все, кроме RDP). В любом случае рекомендуется иметь серверы в отдельной подсети, чтобы ограничить перекрестные помехи широковещательной рассылки между клиентами и серверами.