Как тестировали INFRASCOPE от NGR Softlab: архитектура стенда
После определения задач важно было проверить INFRASCOPE не в изолированном сценарии, а в конфигурации, максимально близкой к инфраструктуре, где PAM должен обеспечивать постоянный доступ к различным целевым системам.
Поэтому в пилоте использовалась отказоустойчивая конфигурация на двух зависимых нодах. 🔄
Платформа развертывалась на базе VMware vSphere. Для основной инфраструктуры использовались:
🔹 ixc-infrascope — 12 vCPU, 24 ГБ RAM, 650 ГБ SSD и 1000 ГБ HDD;
🔹 ds-infrascope — 12 vCPU, 24 ГБ RAM, 650 ГБ SSD и 1000 ГБ HDD.
🌐 Для изолированного доступа к веб-приложениям использовалась отдельная ВМ:
🔹 infrascope-docker-rdp — 12 vCPU, 12 ГБ RAM, 300 ГБ SSD.
На ней размещалась инфраструктура для создания Docker-контейнеров пользовательских браузерных сессий.
Два основных узла работали в активном режиме с распределением нагрузки и автоматическим переключением. Для пользователей были предусмотрены две точки входа — pam1 и pam2.
В качестве целевых систем использовались два основных типа инфраструктуры:
1️⃣ терминальный сервер под управлением Linux;
2️⃣ ферма терминальных серверов Windows.
Для подключения использовались разные протоколы:
🟢SSH — удаленное управление терминальным сервером;
🟢SFTP — передача файлов на терминальный сервер;
🟢RDP — подключение к терминальной ферме;
🟢HTTPS — доступ к веб-приложениям.
🌐 Отдельно проверили веб-доступ
Для работы с веб-приложениями использовался модуль изоляции браузера. Он реализован через Docker-контейнеры: для пользовательской сессии создается отдельный контейнер, внутри которого запускается браузер и обеспечивается подключение к разрешенному веб-ресурсу.
После завершения сессии контейнер может быть остановлен и удален. Такой подход позволяет изолировать пользовательские браузерные сессии друг от друга и централизовать доступ к веб-приложениям.
Как строилось подключение?
Пользователь → PAM → целевая система.
При этом PAM становится единой точкой контроля, через которую проходят различные типы подключений.
Для терминальной фермы использовался брокер подключений. Для LinuxTS отдельно настроили SSH и SFTP. Для веб-приложений подключили изолированный браузерный сценарий.
👥 В рамках пилота также была настроена интеграция с LDAP для аутентификации пользователей по доменным учетным записям и распределения их по группам.
➡️Архитектуру собрали. Теперь посмотрим, какие механизмы управления доступом и привилегиями были настроены поверх этой инфраструктуры.
#INFRASCOPE_ОнлантаТехЛаб #PAM #ИнформационнаяБезопасность
👍 Онланта ТехЛаб
🔗 Читать в MAX
После определения задач важно было проверить INFRASCOPE не в изолированном сценарии, а в конфигурации, максимально близкой к инфраструктуре, где PAM должен обеспечивать постоянный доступ к различным целевым системам.
Поэтому в пилоте использовалась отказоустойчивая конфигурация на двух зависимых нодах. 🔄
Платформа развертывалась на базе VMware vSphere. Для основной инфраструктуры использовались:
🔹 ixc-infrascope — 12 vCPU, 24 ГБ RAM, 650 ГБ SSD и 1000 ГБ HDD;
🔹 ds-infrascope — 12 vCPU, 24 ГБ RAM, 650 ГБ SSD и 1000 ГБ HDD.
🌐 Для изолированного доступа к веб-приложениям использовалась отдельная ВМ:
🔹 infrascope-docker-rdp — 12 vCPU, 12 ГБ RAM, 300 ГБ SSD.
На ней размещалась инфраструктура для создания Docker-контейнеров пользовательских браузерных сессий.
Два основных узла работали в активном режиме с распределением нагрузки и автоматическим переключением. Для пользователей были предусмотрены две точки входа — pam1 и pam2.
В качестве целевых систем использовались два основных типа инфраструктуры:
1️⃣ терминальный сервер под управлением Linux;
2️⃣ ферма терминальных серверов Windows.
Для подключения использовались разные протоколы:
🟢SSH — удаленное управление терминальным сервером;
🟢SFTP — передача файлов на терминальный сервер;
🟢RDP — подключение к терминальной ферме;
🟢HTTPS — доступ к веб-приложениям.
🌐 Отдельно проверили веб-доступ
Для работы с веб-приложениями использовался модуль изоляции браузера. Он реализован через Docker-контейнеры: для пользовательской сессии создается отдельный контейнер, внутри которого запускается браузер и обеспечивается подключение к разрешенному веб-ресурсу.
После завершения сессии контейнер может быть остановлен и удален. Такой подход позволяет изолировать пользовательские браузерные сессии друг от друга и централизовать доступ к веб-приложениям.
Как строилось подключение?
Пользователь → PAM → целевая система.
При этом PAM становится единой точкой контроля, через которую проходят различные типы подключений.
Для терминальной фермы использовался брокер подключений. Для LinuxTS отдельно настроили SSH и SFTP. Для веб-приложений подключили изолированный браузерный сценарий.
👥 В рамках пилота также была настроена интеграция с LDAP для аутентификации пользователей по доменным учетным записям и распределения их по группам.
➡️Архитектуру собрали. Теперь посмотрим, какие механизмы управления доступом и привилегиями были настроены поверх этой инфраструктуры.
#INFRASCOPE_ОнлантаТехЛаб #PAM #ИнформационнаяБезопасность
👍 Онланта ТехЛаб
🔗 Читать в MAX