Безопасное RDP подключение к серверу в Google Cloud

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов для системных администраторов Pyatilistnik. В прошлый раз мы с вами разобрали функциональность библиотеки vcruntime140.dll и пробежались по ситуациям, что будет если она вдруг будет отсутствовать в вашей системе. Идем дальше и в сегодняшней публикации я вам хочу рассказать интересный опыт, который я получил при работе с виртуальными серверами в Google Cloud, а именно научу безопасно производить подключение к серверу в Google Cloud по RDP через NAT с максимальной встроенной безопасностью. Поехали.

Описание задачи

Сейчас уже никого не удивишь слово облако, которое применяется в области IT, все привыкли использовать онлайн сервисы, приложения, это удобно. Многие компании свои сервера перенесли на гипервизоры разных вендоров, таких как Vmware, AWS Amazon и Google тут не исключение, он давно мечтал потягаться на данном поле игры и создал весьма успешную площадку Google Cloud.

В Google Cloud вы вольны создавать проекты исходя из территориального расположения и в рамках него уже создавать виртуальные машины. У меня это как раз есть такая удаленная площадка в тихоокеанском регионе. Далее у вас встает вопрос, как вы будите предоставлять безопасный доступ для сотрудником на данные сервера. Тут всегда все определяется рамками вашего бюджета и требованиями бизнеса. Если бюджет позволяет, то вы легко поднимаете VPN между проектом в Google Cloud и присоединяете сервера к Active Directory, организовываете доступ по сертификатам и можно не светить ваш RDP доступ во вне.

Но если пока проект не совсем большой и бюджет не позволяет городить дополнительную инфраструктуру, то вам приходится в классическом варианте иметь на серверах белый IP-адрес, выставлять его на ружу и производить подключение по нему, единственное вы можете настроить правила фильтрации встроенным брандмауэром Windows на разрешение доступа с определенных сетей, я изначально так и сделал, но правда на брандмауэре коммутаторе в Google проекте. Бесплатно и просто, но появилась проблема, в том, что я разрешил только московские сети головного офиса, и получилась ситуация, что люди живущие в тихоокеанском регионе, сначала через клиента Cisco Connect подключаются к московскому RDS серверу, а уже с него идут на сервера в Google Cloud.

Получает двойной трафик и задержки при работе, выйти из этого я попытался попросив купить людям статические IP-адреса на домашнем интернете, но не вышло, пришлось искать варианты. Мой коллега исходя из такой задачи нашел еще более безопасное и гениальное решение для таких ситуаций, да еще и используя встроенную учетную запись gmail. У моей компании есть купленный пакет G-Sute и мы давно отказались от Exchange и перевели все по возможности в облака Google. Исходя из этого у каждого сотрудника есть корпоративная почта в Google и ее как раз таки можно использовать для подключения и подтверждения личности, ниже покажу схему.

Удаленный доступ на виртуальные машины Windows в Compute Engine

Чтобы помочь решить эту дилемму, Google представляет новый инструмент с открытым исходным кодом, который поможет пользователям и администраторам Windows удобно и безопасно получать доступ к виртуальным машинам Windows, работающим в Compute Engine, и управлять ими.

IAP Desktop - это приложение для Windows, которое позволяет управлять несколькими подключениями по протоколу удаленного рабочего стола (RDP) к экземплярам Windows VM, запущенным в Google Cloud. IAP Desktop основан на существующей службе Identity-Aware Proxy, которая может помочь вам контролировать доступ к вашим приложениям и виртуальным машинам, работающим в Google Cloud. IAP работает, проверяя личность пользователя и контекст запроса, чтобы определить, следует ли этому пользователю разрешить доступ к приложению или виртуальной машине. Все подключения RDP автоматически шифруются и туннелируются через IAP, поэтому вы можете получить доступ к экземплярам виртуальных машин, которые не предоставляют RDP публично или даже не имеют общедоступного IP-адреса. В частности, IAP Desktop использует пересылку IAP TCP для туннелирования подключений RDP.

Но IAP Desktop - это больше, чем просто клиент удаленного рабочего стола: он также обеспечивает обзор и быстрый доступ ко всем вашим экземплярам виртуальных машин в ваших проектах Google Cloud. Вы также можете получить доступ к общим функциям, таким как создание учетных данных Windows или просмотр журналов, одним щелчком мыши.

Принцип работы Identity-Aware Proxy

Функция пересылки TCP IAP ( Identity-Aware Proxy) позволяет вам контролировать, кто может получить доступ к административным службам, таким как SSH и RDP, на ваших серверных модулях из общедоступного Интернета. Функция пересылки TCP предотвращает открытый доступ этих служб к Интернету. Вместо этого запросы к вашим службам должны пройти проверку аутентификации и авторизации, прежде чем они попадут на свой целевой ресурс.

Предоставление административных услуг напрямую через Интернет при выполнении рабочих нагрузок в облаке сопряжено с риском. Перенаправление TCP-трафика с помощью IAP позволяет снизить этот риск, гарантируя, что только авторизованные пользователи получат доступ к этим конфиденциальным службам. Поскольку эта функция специально предназначена для административных служб, цели с балансировкой нагрузки не поддерживаются.

Функция пересылки TCP  Identity-Aware Proxy позволяет пользователям подключаться к произвольным портам TCP на экземплярах Compute Engine. Для общего TCP-трафика IAP создает порт прослушивания на локальном хосте, который перенаправляет весь трафик на указанный экземпляр. Затем IAP оборачивает весь трафик от клиента в HTTPS. Пользователи получают доступ к интерфейсу и порту, если они проходят проверку подлинности и авторизации в соответствии с политикой управления идентификацией и доступом (IAM) целевого ресурса.

Особый случай - установление SSH-соединения с использованием gcloud compute ssh обертывания SSH-соединения внутри HTTPS и его перенаправления на удаленный экземпляр без необходимости прослушивания порта на локальном хосте. Включение IAP для ресурса администратора не блокирует автоматически прямые запросы к ресурсу.  Identity-Aware Proxy блокирует только TCP-запросы, которые не поступают от IP-адресов переадресации TCP IAP к соответствующим службам на ресурсе. Для пересылки TCP с IAP не требуется назначенный вашему ресурсу общедоступный маршрутизируемый IP-адрес. Вместо этого он использует внутренние IP-адреса.

Выдача прав на использование  Identity-Aware Proxy

Чтобы разрешить IAP подключаться к вашим экземплярам виртуальной машины, создайте правило брандмауэра, которое:

• применяется ко всем экземплярам виртуальных машин, к которым вы хотите получить доступ с помощью IAP.
• разрешает входящий трафик из диапазона IP 35.235.240.0/20. Этот диапазон содержит все IP-адреса, которые IAP использует для пересылки TCP.
• позволяет подключаться ко всем портам, которые должны быть доступны с помощью перенаправления TCP IAP, например, порт 22для SSH и порт 3389для RDP.

Чтобы разрешить RDP и SSH доступ ко всем экземплярам виртуальных машин в вашей сети, сделайте следующее:

• Откройте страницу «Правила брандмауэра» и нажмите "Создать правило брандмауэра"
• Настройте следующие параметры:
  • Имя :allow-ingress-from-iap
  • Direction of traffic : Ingress
  • Target : All instances in the network
  • Source filter : IP ranges
  • Source IP ranges :35.235.240.0/20
  • Протоколы и порты : выберите TCP и введите, 22,3389чтобы разрешить использование RDP и SSH.
• Щелкните " Создать" .

Предоставление прав на использование TCP  Identity-Aware Proxy

Чтобы контролировать, каким пользователям и группам разрешено использовать пересылку TCP IAP и к каким экземплярам виртуальных машин им разрешено подключаться, настройте разрешения управления идентификацией и доступом (IAM).

Google рекомендует предоставить все следующие роли доверенным администраторам:

• roles/iap.tunnelResourceAccessor (проект или ВМ)
• roles/compute.instanceAdmin.v1 (проект)
• roles/iam.serviceAccountUser (проект)

Вы можете предоставить пользователю или группе доступ ко всем экземплярам виртуальных машин в проекте, настроив разрешения IAM на уровне проекта:

Вас перекинет на управление доступом вашего проекта. Через кнопку "Add" добавьте права для нового пользователя, чтобы он просто имел возможность видеть виртуальные машины в данном проекте и использовать подключение  Identity-Aware Proxy, вам необходимо дать ему права:

• Computer Viewer
• IAP-secured Tunnel User

В итоге у меня получилось вот так, права Owner это для админа.

Установка IAP Desktop

Теперь когда все права на подключение выданы вы можете попробовать установить клиента для подключения к виртуальным серверам вашего проекта.

Запускаем дистрибутив IapDesktop.msi. На первом шаге просто нажмите "Next".

Далее примите лицензионное соглашение.

Далее в мастере установки  Identity-Aware Proxy просто нажмите "Install"

Заканчиваем инсталляцию IAP и запускаем его.

Далее вам необходимо авторизоваться используя Google учетную запись.

Если у вас несколько аккаунтов, то указываем нужный.

Разрешаем доступ к аккаунту для IAP Desktop.

Если все нормально, то вам покажут, что можно закрыть вкладку браузера.

Теперь перейдите в IAP Desktop, у вас должны отобразиться все ваши проекты. Выберите нужный проект в Google Cloud.

В моем проекте есть три виртуальных машины, щелкаем по нужной правым кликом и выбираем из контекстного меню "Connect"

Настраиваем учетную запись, нажмите "Configure credentials".

Интерфейс программы очень похож на mRemoteNG

На этом все, как видите это очень удобный и простой метод доступа к внутренним виртуальным машинам в проекте Google Cloud. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.