ssl vpn что такое
Пробрасываем толстый клиент через SSL туннель с шифрованием по ГОСТ
Привет, Хабровчане! 
Сегодня мы хотим рассказать о преимуществах технологии SSL VPN и о практике работы со шлюзом Stonesoft SSL. В статье будет описана настройка данного решения для проброса толстого клиента (на примере хорошо знакомой многим 1С Бухгалтерии) через протокол HTTPS с применением ГОСТовых алгоритмов шифрования. Это позволит нашему любимому главному бухгалтеру удаленно работать с базой 1С по зашифрованному каналу прямо с дачи, нам – быстро подключить к системе пару сотен разбросанных по стране небольших офисов, а нашей организации – выполнить требования законодательства по защите, например, персональных данных.
В статье описывается способ безопасной публикации клиент-серверных приложений через Веб, руководствуясь которым, можно организовать удаленный доступ практически к любому корпоративному ресурсу.
Что такое SSL VPN
Итак, давайте посмотрим, как SSL VPN может облегчить нам жизнь и сэкономить время и нервы. Описывать технологию смысла не вижу, чтобы не докучать сухой технической информацией продвинутому читателю. Освежить знания по SSL VPN можно здесь. Мы же остановимся на практике использования и подумаем, чем же так хорош SSL VPN в сравнении с классическим IPSec VPN.
Суть технологии SSL VPN состоит в следующем: клиент подключается по 443 порту к шлюзу, который в свою очередь инициирует соединение с удаленным сервером (в нашем случае – это 1С), как прокси-сервер.
Во-первых, это удобно. Можно организовать доступ к любому сервису/ресурсу с любого пользовательского устройства из любого места, где есть Интернет. Не надо устанавливать никаких VPN-клиентов, настраивать их, как в случае использования IPSec VPN, достаточно в браузере ввести адрес, аутентифицироваться и работать. Пользователь сможет получить удаленный доступ к корпоративному ресурсу даже через публичный или гостевой Wi-Fi, т.к. 443 порт открыт почти во всех сетях.
Во-вторых, это просто. Просто для всех. Вам не придется объяснять тетеньке-бухгалтеру пользователю, что для получения доступа к какому-то ресурсу ему надо в трее найти иконку VPN-клиента, нажать на ней правой кнопкой мыши, из списка выбрать адрес шлюза, нажать «Connect», ввести логин и пароль (снова привет IPSec VPN). Просто для администраторов, т.к. не надо выдавать пользователю рабочий ноутбук для командировок с установленным и настроенным VPN-клиентом, антивирусом и другим корпоративным ПО.
В-третьих, это безопасно. Есть много механизмов защиты, которые шлюз SSL VPN может применять к клиенту. Два главных механизма – это аутентификация и шифрование. Методы и средства аутентификации можно выбрать самые различные: по логину/паролю, RADIUS, сертификаты, одноразовые пароли, интеграция с Active Directory и многие другие, в зависимости от выбранного решения SSL VPN.
Также можно выделить такие интересные механизмы защиты, как проверка конечного устройства пользователя на соответствие политике безопасности и удаление следов сессии по окончании соединения (cookies, история URL, данные из кэша и временные файлы).
Что имеем и что хотим
Задача стоит следующая: организовать защищенный доступ к серверу 1С по протоколу HTTPS с использованием ГОСТового шифрования с ноутбука бухгалтера, который любит отдыхать и работать на даче. По сути, мы будем прокидывать толстый клиент 1С, который работает по «своим» портам (1540 TCP, 1560-1591 TCP), через порт 443 TCP.
и настроен NAT на интерфейс шлюза SSL VPN.
Как видно из схемы и правил на МЭ, доступа извне к серверу 1С нет (безопасность прежде всего!).
Настраиваем SSL VPN
Описывать процесс установки прошивки с поддержкой ГОСТ на шлюз SSL VPN и его первоначальной настройки не буду, все это можно найти в Интернетах и гайдах. Так что условимся, что у нас есть чистый Stonesoft SSL с установленными криптобиблиотеками КритоПро CSP, сгенерированными ключами, импортированными сертификатами шлюза и доверенного Удостоверяющего центра.
Ниже приведены сертификаты шлюза Stonesoft SSL и пользователя, выпущенные на тестовом Удостоверяющем центре.
Сертификат шлюза SSL VPN:
Сертификат пользователя:
Настройка аутентификации пользователей
Сначала настроим аутентификацию пользователей. Мы выбрали следующую схему: аутентификация по сертификатам, выданным только доверенным УЦ без привязки к какому-либо хранилищу пользователей. Т.е. если у пользователя есть сертификат, выданный УЦ, который шлюз считает доверенным, то пользователь может аутентифицироваться. Итак, заходим на https://10.30.0.213:8443/ и попадаем на консоль администрирования шлюза Stonesoft SSL.
Идем на вкладку Manage System – Authentication Methods.
Добавляем новый метод – жмем Add Authentication Method…, выбираем тип User Certificate, задаем имя методу и выбираем УЦ, который будет использоваться для данного типа аутентификации.
По умолчанию аутентифицироваться может не любой пользователь, а только тот, чья учетная запись известна шлюзу. Для нашей схемы нужно добавить новый атрибут для созданного метода аутентификации: жмем Add Extended Property…, выбираем атрибут Allow user not listed in Any User Storage и выставляем значение атрибута true.
Все, новый метод аутентификации готов, для применения изменений жмем кнопку Publish. Это, наверное, самая важная кнопка при работе с Stonesoft SSL, не забывайте жать ее каждый раз, когда что-то меняете.
Публикация ресурса. Вариант №1
Теперь надо опубликовать ресурс, чтобы он был доступен пользователю на портале приложений шлюза SSL VPN. Сначала рассмотрим Вариант №1: 1С-клиент подключается к серверу 1С и работает с базой в СУБД.
Теперь нужно создать элемент на портале приложений. Идем на вкладку Manage Resource Access – Tunnel Sets, жмем Add Tunnel Set и заполняем имя, выбираем иконку, которая будет видна пользователю (можно выбрать из готовых или загрузить свою), в поле Link Text пишем текст, который будет отображаться под иконкой.
На следующем шаге мы должны указать шлюзу SSL VPN, какой трафик заворачивать в SSL, для этого добавляем динамический туннель, для чего жмем Add Dynamic Tunnel to the Set… и из выпадающего списка в поле Resource выбираем хост с сервером 1С. Все остальные поля заполняются автоматически в соответствии со свойствами ресурса, который мы выбрали.
Теперь самый ответственный момент, необходимо правильно написать команду, которая будет выполняться на клиентском ПК, автоматически запуская клиент 1С с требуемыми параметрами подключения к серверу. У меня она выглядит следующим образом: «C:\Program Files\1cv8\8.3.1.531\bin\1cv8c.exe» /S«10.30.0.238\1c». Стоит помнить о том, что если пользователей несколько, то у всех путь к исполняемому файлу должен быть одинаковым. Если это по каким-то причинам невозможно, то можно поле Startup Command оставить пустым, тогда клиент 1С придется запускать вручную и указывать все параметры после открытия ресурса на портале приложений.
После всех проделанных действий жмем Publish.
Теперь можем проверить, что у нас вышло. Запускаем браузер, пишем в адресной строке https://ssl.sglab.ru/ и видим окно с выбором сертификата.
После аутентификации попадаем на портал приложений.
Жмем на 1С и видим, как загружается Access Client, запускается команда, которую мы писали в свойствах Tunnel Set и в итоге стартует клиент 1С: Предприятие и подключается к серверу.
В момент подключения можно посмотреть логи на МЭ и убедиться, что все работает через HTTPS.
Публикация ресурса. Вариант №2
Теперь настроим другой сценарий – пользователь жмет на иконке 1С на портале приложений и получает доступ к папке с базой на сервере 1С.
Заходим на консоль администрирования шлюза, идем на вкладку Manage Resource Access – Standard Resources – File Sharing Resources – Microsoft Windows File Share и жмем Add this Standard Resource.
Заполняем имя ресурса, IP-адрес сервера 1С, имя папки с базой, к которой открыт общий доступ, выбираем иконку для портала приложений и пишем отображаемое имя.
Собственно, все. Не забываем опубликовать изменения на портале.
Теперь с клиентского ПК снова заходим на https://ssl.sglab.ru/ и жмем на созданной иконке База 1С.
После чего мы видим папку с базой 1С.
Далее все просто и понятно – добавляем в клиенте 1С новую информационную базу, указываем путь \\10.30.0.238\1cbase и работаем с ней по защищенному каналу через HTTPS.
Заключение
Таким образом, мы настроили шлюз SSL VPN для удаленной работы с сервером 1С в двух вариантах по зашифрованному ГОСТовыми алгоритмами каналу и позволили нашим пользователям безопасно работать с корпоративными ресурсами через толстые клиенты.
Это далеко не все, на что способен Stonesoft SSL VPN. Приведенную конфигурацию несложно будет «оттюнинговать» под свои потребности.
Надеемся, эта статья будет вам полезна. В дальнейшем мы планируем продолжить делиться с хабражителями нашим опытом в области информационной безопасности. Будем рады вопросам и пожеланиям в комментах.
SSL VPN – шаг вперед в технологии VPN сетей
VPN сети вошли в нашу жизнь очень серьезно, и я думаю, надолго. Данная технология используется как в организациях для объединения офисов в единую подсеть или для обеспечения доступа к внутренней информации мобильных пользователей, так и дома при выходе в интернет через провайдера. Можно с уверенностью сказать, что каждый из администраторов обязательно занимался настройкой VPN, как и каждый пользователь компьютера с выходом в интернет использовал данную технологию.
Фактически, в настоящий момент, очень сильно распространена технология IPSec VPN. Про нее написано много различных статей как технических, так и обзорно-аналитических. Но сравнительно недавно появилась технология SSL VPN, которая сейчас очень популярна в западных компаниях, но в России на нее пока не обратили пристального внимания. В этой статье я постараюсь описать, чем отличается IPSec VPN от SSL VPN и какие преимущества дает применение SSL VPN в рамках организации.
И действительно, в случае доверенных узлов применение IPsec VPN – это наиболее экономичный путь. Например, для соединения сетей удаленных офисов в единую корпоративную сеть не требуется прокладка или аренда выделенных линий, а используется сеть Интернет. В результате построения защищенных туннелей между доверяемыми сетями образуется единое IP-пространство.
А вот при организации удаленного доступа сотрудников IPsec-решения используются для ограниченного количества только доверенных устройств, например для ноутбуков корпоративных пользователей. Для применения IPsec VPN ИТ-служба должна установить и настроить на каждое доверенное устройство (с которого требуется обеспечить удаленный доступ) VPN-клиент, и поддерживать работу этого приложения. При инсталляции IPsec-решений необходимо учитывать их «скрытую» стоимость, связанную с поддержкой и сопровождением, так как для каждого типа мобильного клиента (ноутбук, PDA и др.) и каждого типа сетевого окружения (доступ через интернет-провайдера, доступ из сети компании-клиента, доступ с использованием адресной трансляции) требуется оригинальная конфигурация IPsec-клиента.
Помимо поддержки есть несколько очень важных проблем:
Таких проблем не возникает при использовании SSL VPN.
SSL VPN – алгоритм работы пользователя
Чтобы нете хническому специалисту было интересно читать дальше, опишу процесс использования SSL VPN обычным пользователем.
Предположим, вы находитесь в командировке, в вашей компании вам не смогли предоставить на время командировки ноутбук. Но вам необходимо:
У вас под рукой в лучшем случае компьютер в сети организации, куда вы приехали в командировку, с доступом в Интернет только по протоколу http/https, в худшем случае – обычное Интернет-кафе в вашей гостинице.
SSL VPN успешно решает все эти задачи, причем уровень обеспечения безопасности будет достаточным, для работы с критичной информацией из Интернет кафе…
Фактически вы выполняете следующие действия:
Таким образом, применение SSL VPN решает несколько задач:
SSL VPN – производители и возможности
На рынке SSL VPN доминируют аппаратные решения. Среди поставщиков решений SSL VPN – все известные производители активного сетевого оборудования:
Среди программных реализаций специалисты компании «Алатус» выделяют решение на базе SSL Explorer компании 3SP Ltd, которое наиболее точно соответствует требованиям заказчиков.
Так же хотелось бы привести таблицу сравнения возможностей IPSec VPN и SSL VPN:
SSL VPN
Juniper, NetApp,
Fortinet, Extreme,
Check Point
SSL VPN
SSL VPN — это такой чудо-девайс для организации удаленного доступа в какую-нибудь внутреннюю сеть безо всяких Remote-VPN-клиентов, их установки, настройки, L2TP over IPSec, правки виндового реестра и прочих кошмаров сисадмина. Вернее, SSL VPN — это технология, а девайс по-джуниперовски называется Secure Access. Но мы же, в конце концов, не зоологи, чтобы париться классификацией, поэтому в околоджуниперовском обиходе термины Secure Access и SSL VPN — это почти синонимы.
Итак, идея в следующем.
Сначала вы заходите любым браузером хоть с blackbery, хоть с телефона через интернет, как обычно, почти как я на Яндекс, на веб-морду этого чудо-девайса (см. картинку в начале поста) и логинитесь при помощи какого-нибудь из способов. Способов дофигища: логин-пароль, пользовательский сертификат, разного рода SecureID, всяческие их комбинации. Да, конечно, это отлично интегрируется с Active Directory, RADIUS, LDAP и еще миллионом видов серверов аутенитификации. Естественно, через интернет все передается в виде SSL, то есть надежно, безопасно и не больно.
Как до, так и после аутентификации вас могут проверить на предмет End Point Security. То есть выяснить, той ли системы у вас гранаты какая у вас ОС, установлен ли антивирус, давно ли у него обновлялась база, не запущен ли какой-нибудь известный кейлогер, или даже просто, есть ли у вас на компьютере файл в нужном месте с нужной чексуммой или процесс (тоже с ческуммой). Файл, если есть желание, можно попробовать удалить, а процесс прибить/запустить. Это называется Host Checker. Работает при помощи ActiveX, если оного нету, или у вас Linux, то при помощи Java. Все, кстати, кросплатформенно до жути — все скриншотики делались как раз из-под Линукса.
Логично возмутиться, дескать, как же это — будут тут еще всякие на моем компьютере файлы проверять. Опять же, в каком-нибудь интернет-кафе — кто же это там даст-то их проверять? Ответ: ну и не надо. Не дали проверить, значит проверку не прошли. Значит компьютеру пользователя доверять мы можем только частично. Значит сделаем оргвыводы и дадим ему доступ только туда, куда не очень страшно. А на служебном ноутбуке — можно и файлы проверить, и антивирус и еще капслоком поморгать, и тогда уж ходи куда хошь.
На основе всех этих проверок и аутентификационных данных вас авторизуют с присвоением роли (профайла): ну там, бухгалтерия, начальство, дворники, программеры и пр. Причем роли могут пересекаться, то есть бухгалтеру никто не мешает быть еще программистом. По крайне мере с точки зрения удаленного доступа.
После всего этого вы попадаете к себе «домой»:
Дома есть несколько инструментов доступа. Каких именно — определяется администратором исходя из вашей роли. Что позволено бухгалтеру не позволено программеру.
Первый инструмент — это доступ к внутренним веб-ресурсам. Веб-интерфейс к веб-интерфейсу. Ваш браузер через SSL общается с внешним IP-интерфейсом SA, а SA — своим внутренним IP-интерфейсом разговаривает с внутренними же корпоративными веб-сервисами. Уже без всякого SSL (ну или тоже с SSL, если очень надо).
Красивые картинки в данном случае никакого отношения к SSL VPN не имеют. Это всего лишь морда cacti — рисовалки графиков со сбором данных по SNMP и не только — типа MRTG, но круче и мудренее. К SSL VPN имеет отношение лишь панелька с логотипом Juniper Networks в левом верхнем углу. Это ее Secure Access пририсовал: вернуться «домой», добавить текущую страницу в закладки и пр. Все остальное — как бы обычная веб-страница.
Технически SA для достижения такого уровня мировой гармонии лезет в HTML-код и меняет там все внутренние ссылки на нечто вида https://sslvpn.domain.ru/dana-na/internal-page-id и в таком виде скармливает код вашему браузеру. Причем эти page-id можно сохранять в виде внутренних URL, а можно — наоборот превращать в абракадабру, чтоб враги не догадались. Делает он это весьма эдвансно, так что работают даже смены window.location в JavaScript. Для эстетов есть специальные rewrite policy, позволяющие тонко управлять процессом.
Разумеется, есть возможность не давать пользователю самостоятельно серфить весь внутренний веб, а разрешить ему ходить только по предопределеным админским закладкам. Создавать пользователям свои закладки тоже можно как запретить, так и разрешить. Естественно, помимо всего этого есть еще и access-листы, которые могут разрешить/запретить все что угодно на основе каких угодно критериев.
Дальше у нас есть веб-морда к сетевой файловой системе SAMBA/CIFS и NFS (последнее — это для тех, кто знает, что это такое). Вебморда довольно крутая, кстати. Удобнее многих стандартных файловых менеджеров.
SA логинится на samba-сервер, конечно, с использованием уже введенных данных аутентификации пользователя (это называется модным словом Single Sign On — SSO). То есть сто раз вводить логин-пароль не надо. Хотя, если админу очень хочется, можно и это сделать. Кстати, в случае с веб-ресурсами всякие NTLM, разумеется, тоже поддерживаются.
Можно скачивать несколько файлов в виде единого архива. Архивация, разумеется, онлайн.
Можно и наоборот — закачивать архив, а на сервер положится его содержимое. Правда, есть ограничение. Закачивать файлы больше 500 мегов нельзя. Но в этом виноват TLS (это такой стандарт транспорта данных поверх SSL), а не Juniper.
Следующим по списку у нас идет т. н. терминальный доступ. Во-первых это Telnet- и SSH-клиенты, реализованные в виде Java-апплетов, во-вторых — способ запуска виндового RDP-клиента с туннелированием его трафика. Последнее работает только у тех, у кого этот стандартный виндовый RDP-клиент есть. То есть под Linux’ом не работает. Разумеется, в Secure Access есть масса других способов прокидывания RDP, просто этот — самый быстрый для виндовых пользователей.
Вот так выглядит telnet-сессия:
Не сказать, что самый удобный в мире терминал, но когда надо, пользоваться можно.
Дальше еще интереснее.
Для начала самое простое. То есть полноценный IP-доступ, которого вам, конечно же, очень хочется (зачем-то). Ну, хочется, так хочется — нет проблем.
Это java-апплет с горыдм названием Network Connect (далее NC). Соответственно, на компьютере пользователя нужна java-машина. Впрочем, на ПК, хоть под виндой, хоть под чем, это давно не проблема. На КПК и мобилках — по-разному.
Поскольку речь идет о полноценном IP, на компьютере нужно создать виртуальный интерфейс и вмешаться в роутинг — следовательно, программке нужны соответствующие права. Не все время, а только однажды: при первом запуске NC устанавливается на манер обычной программы, и даже появляется пункт в меню «Пуск». Если дело обстоит под Линуксом — sudo спросит рутовый пароль, если под виндой — никто ничего не спросит, но без админских прав просто не уставливается. Как под MacOS X — нам пока неизвестно за неимением оной в арсенале, но как-то, должно быть, похожим образом. Для второго и последующих запусков никаких админских прав уже не нужно.
Для работы под Linux нужен драйвер tun (универсальный туннельный интерфейс) — в большинстве дистрибутивов предустановленное ядро включает соответствующий модуль, так что все работает out of box без всяких выкрутасов. Проверено на Slackware, Debian Lenny, Centos и RHEL.
NC — это, меж тем, наирасчудесный VPN-клиент. Несмотря на серый цвет и вообще всю внешнюю неприглядность, умеет побольше иных standalone-творений криворуких разработчиков.
— Установка полностью автоматическая. Пользователю нужно только нажать кнопку Start в личном аккаунте (по воле админа можно и этого не делать — после входа сам запустится). Впрочем, желающие могут также скачать инсталлятор из админского интерфейса SA и раздавать его пользователям как отдельный файл с помощью одного из централизованных механизмов массового осчастливливания.
— NC не нужно настраивать. То есть нужно, но один раз для всех пользователей. Все настройки пользователь засасывает с Secure Access и ничего руками не делает. Если что, NC умеет и логи для траблшутинга тоже скидывать на SA.
— NC может работать как поверх ESP (как IPsec, что несколько веселее с точки зрения производительности), так и через SSL с автоматическим переключением с первого на второе, если вдруг с ESP не сложилось. SSL в отличии от ESP без труда пролазит через все файрволы, наты и т. д. Что до производительности, то при сколько-нибудь нормальном интернете через SSL вполне приемлемо работает даже VoIP. Был опыт разговора по такой штуке с Москвой из Лондона, из Эйндховена и из Читы. Внутри Москвы мы и вовсе регулярно пользуемся (например, чтобы из дома за счет конторы по межгороду звонить. Шутка).
— Поддержка технологии GINA. То есть он умеет запускаться до виндового приглашения в систему и используя логин-пароль от домена AD, коннектиться к SA, создавать туннель, и пользователь, логинясь в систему, попадает сразу уже в домен со всеми его настройками, правами и сетевыми папками, будто никуда и не уходил из офиса.
— Поддержка мультикаста, умение копировать DiffSerf-метки из верхнего пакета в нижний и прочие приятные мелочи.
Разумеется, для разных ролей можно настраивать разные маршруты, можно объединять правила для нескольких ролей, и конечно же, как и все остальные виды доступа, все это хозяйство прикрывается access-листами.
Кроме того, каждой роли адреса выдаются из своего пула, и трафик, помимо всего прочего, можно ограничивать отдельным файрволом внутри сети. Кстати, сделать каждой роли свой внутренний IP-адрес можно и при «не full IP»-доступе. Бухгалтеры и программеры будут обращаться к файловому серверу с разных source IP даже из веб-интерфейса (см. описание предыдущих методов доступа).
Дальше еще веселее. Штука под названием Secure Application Manager (SAM). Зверская и непонятная простому человеку вещь.
Бывает двух видов. JSAM (от слова Java) и WSAM (от слова Windows). Вот как выглядит аплет JSAM.
Правда ведь, ничего непонятно?
JSAM вешается на loopback-интерфейс компьютера пользователя (стандартный 127.0.0.1 или создает еще один адрес из 127.0.0.0/8) и слушает на нем какой-то заранее определенный TCP-порт. Программа пользователя обращается к 127.0.0.1 по этому порту, JSAM ловит пакеты, заворачивает их в SSL-туннель и отправляет на ту сторону. Там, соответственно, трафик разворачивается и отправляется какому-то (к какому мы настроили) серверу.
Понятно, что ни один нормальный пользователь в здравом уме не станет обращаться ни к какому loopback-интерфейсу, благо, он не знает, что это такое. Для этого JSAM умеет записывать в файл hosts строчки вида
То есть пользователь просто обращается к доменному имени, а попадает на сервер на обратной стороне SSL-туннеля. Полезно для тех, кто ездит с ноутбуком. Один раз написали доменное имя почтового сервера в аутлуке и что в офисе, что на Канарах — все одно. Да, конечно, JSAM’у для этого нужны права на запись в hosts. Админские права ни для установки, ни для работы не нужны.
Работает это все только с простым TCP. То есть всякие FTP active mode таким способом сделать не получится.
WSAM, несмотря на похожее название, делает все совсем иначе. Он подкладывает под конкретное приложение свой API сокетов, перехватывает с его помощью трафик и потом упаковывает его таким же способом. Разница в том, что все это работает не только для TCP и можно (нужно) указать конкретную программу, трафик которой мы собираемся туннелировать. Разумеется, работает WSAM только под виндой.
Зачем нужен SAM? Как и все остальные «не full IP»-методы — для ограничения возможностей несанкционированного доступа. За неимением IP внутри сети, к компьютеру пользователя нельзя обратиться. Пользователь — тоже не может ни пинговать, что ни попадя, ни сканить порты, ни распространять и получать всякую заразу и т. п. В зависимости от типа рабочего места (служебный ноутбук, домашний комп, мобильное устройство, интернет-кафе и пр.) все эти ограничения могут быть совсем не лишними. Да и зачем, скажите, пользователю из интернет-кафе получать полноценный IP-доступ во внутренню сеть? Даже если вам все равно — админам кафе не все равно.
Разумеется, это не все возможности Secure Access. Он еще умеет давать SSL-интерфейс к почте; умеет чистить кэш браузера и ОС после завершения сеанса; умеет делать на время сеанса виртуальные рабочие пространства с удалением всех файлов и всего чего только можно после завершения, чтобы пользователь, поработав с чужого компьютера, при всем желании не мог забыть на рабочем столе какой-нибудь не тот файл.
Кроме того, есть замечательная функция Secure Meeting. Это нечто вроде Microsoft NetMeeting, только web based. Пользователи могут расшаривать свой рабочий стол, давать другим пользователям порулить им и пр. В совокупности с фичей support meeting (юзеру не надо иметь постоянного логина-пароля) бывает очень полезно, чтобы, скажем, протраблшутить клиентское устройство, к которому доступ есть только через консоль. Словом, весьма полезная для техподдержки вещь. Но про это и про админский интерфейс, пожалуй, как-нибудь в другой раз.
Ну и да, пользовательский интерфейс можно кастомизировать:
У нас, кстати, есть свой Secure Access, и мы им сами регулярно пользуемся. И на нем есть роль demo для тех, кто хочет потрогать руками. Ну и отдельный SA2500, чтобы давать клиентам поиграть, у нас тоже есть. Если что — звоните, пишите.