Мой первый вопрос, так что будьте осторожны :)
У меня есть клиент, который настаивает на том, чтобы их сторонний поставщик поддерживал доступ к этому серверу непосредственно из Интернета через RDP.
Наша политика не разрешает прямой доступ к инфраструктуре извне центра обработки данных для администрирования, за исключением утвержденного VPN-соединения, а затем виртуального рабочего стола на серверах.
Я сейчас в ситуации, когда я должен привести веские причины, почему опасно использовать RDP в общедоступном Интернете.
любая помощь будет оценена
заранее спасибо
Стюарт
Не забывайте, что злоумышленник, который скомпрометирует этот сервер, может также использовать его в качестве плацдарма для атаки на объекты других клиентов за межсетевым экраном. Таким образом, угроза безопасности не ограничивается только активами первого клиента.
Получите от поставщика обоснование того, почему они не могут использовать VPN. Если действительно нет альтернативы RDP-подключению напрямую к серверу, они должны взять на себя ответственность за любые нарушения безопасности через это соединение. Имейте в виду, что поставщик только что признал недостатки безопасности в архитектуре своего приложения, заявив, что в приложении есть что-то, что препятствует использованию VPN.
Сделайте доступ условным при подписании ими соглашения, возмещающего вам любой ущерб, причиненный нарушением безопасности через соединение RDP. Кроме того, вы должны потребовать от них получения соответствующей профессиональной компенсации или покрытия ответственности или предоставить доказательство существующего покрытия с условиями, которые охватывают эту ситуацию.
Короче говоря, заставьте продавца доказать, что он может позволить себе оплатить любой ущерб, и сделайте свой доступ зависимым от договорного обязательства сделать это.
Большинство людей, у которых есть проблема с разрешением RDP напрямую из Интернета, имеют определенный набор проблем, связанных с идеей, что злоумышленники напрямую запрашивают ваш каталог / SAM для аутентификации. Без надлежащего аудита это часто остается незамеченным. После того, как они успешно получат одну пару для входа, они получат неограниченный доступ к вашей среде. Ответом Microsoft на это стала Windows 2008 в виде TS-Gateway. Службы TS-Gateway создают точку туннеля, что не очень похоже на создание туннеля SSL VPN. Служба TS-Gateway, пока она использует тот же каталог или SAM для аутентификации, предоставляет отдельный набор правил авторизации, которых раньше не было. Можно установить правила как на уровне пользователя, так и на уровне компьютера, чтобы контролировать, какие ресурсы вам доступны после аутентификации на шлюзе TS. Итак, 1 вам не нужно настраивать внешние сопоставления имен DNS для всех ваших внутренних серверов, а 2 вы можете ограничить определенных пользователей (группы пользователей) определенными системами.
Я также выполнил реализации, в которых пользователи доступа к TS-Gateway представляют собой отдельную учетную запись от тех, кто имеет доступ к внутренним серверам. С гораздо более длительным сроком действия пароля и блокировкой учетных записей TS-Gateway. Это дает еще один уровень для тех, кто параноиков насчет прямого прохода через авторизацию. Он также хорошо работает для групп с определенной бизнес-политикой в отношении того, что системы DMZ являются членами внутреннего домена.
Моя самая большая проблема (как и с другими) с TS-Gateway до сих пор - это отсутствие поддержки двухфакторных опций аутентификации для начального подключения к шлюзу. Вторым по значимости является отсутствие клиентской поддержки TS-Gateway.
Однако в вашем случае, если ваш внешний поставщик соглашается использовать клиента RDP, совместимого с 6.1, и вы позаботитесь о настройке надлежащего сервера TS-Gateway, не должно быть особых причин, по которым запрос должен представлять угрозу.
Я слышал, что есть новая технология только для Windows 2008 R2, которая называется «Прямой доступ». По сути, это встроенная в ОС VPN через SSL, я думаю, что для нее требуются Windows 2008 R2 и Windows 7 в качестве клиента, но это другое вариант и может быть дешевле, чем инвестировать в другое решение, такое как F5 или Cisco.
Я знаю, что на этот вопрос есть ответ, но вот некоторые рекомендации, если вам необходимо выполнить его. Во-первых, если у вас есть возможность, рассмотрите возможность использования шлюза TS. Информация здесь, в этой статье базы знаний:
Подключение к удаленному рабочему столу (клиент служб терминалов 6.0)
Другой вариант - сопоставить порт с помощью вашего брандмауэра, чтобы это не TCP / 3389, хорошо известный порт. Вы хотите избежать хорошо известных портов, которые будут поражены типичным сканированием.
Как изменить порт прослушивания для удаленного рабочего стола
Даже если RDP настроен на использование шифрования, вы все равно разрешаете прямой доступ к вашему серверу. Если у вас есть брандмауэр и вы разрешаете подключаться к порту RDP только IP вашего поставщика, это может быть нормально, но если вы оставите его открытым с любого IP-адреса, это опасно, если в RDP в день возникает проблема безопасности.
Я рекомендую использовать шлюз VPN, например Cisco ASA, с доступом через WEB SSL VPN. Затем веб-портал позволяет перенаправить порт на удаленный сервер, или, что еще лучше, вы можете запустить апплет RDP (directx или java) на портале. Это решение более безопасно и работает без какого-либо клиента vpn, установленного на компьютере поставщика. Просто нужен браузер, поддерживающий SSL и Java или DirectX.
Поскольку вы используете как минимум RDP 6.0, я не вижу в этом ничего плохого. Некоторые из моих серверов TS открыто доступны из Интернета, но обеспечивают безопасность только версии 6.0+ (с TLS также и в XP).