Обзор SafeNet Trusted Access, облачной платформы управления доступом

1. Введение
2. Функциональные возможности SafeNet Trusted Access
   1. 2.1. Общие положения
   2. 2.2. Консоль управления доступом STA
   3. 2.3. Портал для пользователей STA
3. Архитектура SafeNet Trusted Access
4. Системные требования SafeNet Trusted Access
5. Сценарии использования SafeNet Trusted Access
   1. 5.1. Использование единой точки доступа (SSO) к различным приложениям
   2. 5.2. Проверка работы контекстнозависимого доступа
6. Выводы

Введение

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

Также, помимо удалённой работы в условиях пандемии, организации должны выполнять требования нормативных документов, которые предписывают защищать информацию с применением систем IAM, а также использовать двухфакторную аутентификацию персонала (в том числе административного) как при удалённой работе, так и при обычной. Например, такими документами являются приказ ФСТЭК России № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», приказ ФСТЭК России № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных», методический документ ФСТЭК России «Меры защиты информации в государственных информационных системах», ГОСТ Р 57580.1 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер». Приказы ФСТЭК России распространяются на государственный сектор, а ГОСТ Р 57580.1 устанавливает требования по обеспечению защиты информации для финансовых организаций. К последним применимы и положения стандарта безопасности данных индустрии платёжных карт (PCI DSS).

И если крупные организации в большинстве своём уже применяют различные средства защиты информации, то для средних и малых компаний вопрос управления учётными данными и доступом, а также обеспечения безопасности (в том числе при удалённой работе) сейчас является весьма проблемным.

Ещё одним насущным вопросом в настоящее время является необходимость работы пользователя со значительным количеством приложений (с соответствующей реализацией управления доступом), в то время как применить доменную политику не всегда возможно технически. Таким образом, у пользователя появляется необходимость запоминать логины и пароли для доступа, и, как это часто бывает, работники начинают записывать свои аутентификационные данные на стикеры и клеить их на мониторы, что является грубейшим нарушением основ инфобезопасности. Если же в компании используется ещё и многофакторная аутентификация, то к этому прибавляется связка токенов.

Но современные технологии не стоят на месте. В описанном случае можно использовать метод единой точки входа (Single Sign-On, SSO), когда сотрудник проходит авторизацию один раз и получает доступ ко всем разрешённым ему приложениям без необходимости повторного ввода аутентификационных данных.

Решения от компании Thales, такие как SafeNet Authentication Service и SafeNet Trusted Access, позволяют снять упомянутые выше проблемы. Первое из них обеспечивает реализацию многофакторной аутентификации и управление токенами в организации, а второе дополняет его механизмами управления доступом, идентификации пользователей и создания единой точки доступа к приложениям. При этом SafeNet Authentication Service является программным комплексом, который устанавливается на оборудование заказчика, а SafeNet Trusted Access — облачной платформой, к которой организация подключается.

Обзор системы SafeNet Authentication Service мы уже проводили ранее, а сегодня речь пойдёт о SafeNet Trusted Access (STA) — продукте, позволяющем реализовать управление доступом и аутентификацию корпоративного класса. Он включает в себя функциональные возможности сразу трёх классов решений: IAM, SSO и MFA. SafeNet Trusted Access обеспечивает централизованное управление доступом и аутентификацией применительно к различным приложениям, включая облачные, локальные и интегрированные с помощью SAML, OpenID Connect (OIDC) или RADIUS. Также предусмотрена возможность интеграции на основе агентов для конкретных локальных приложений с применением API, например с целью передачи журналов в SIEM-систему.

Платформа SafeNet Trusted Access полностью размещается в облаке; внутри периметра потребуется разместить только локальные агенты для управления Windows и другими внутренними активами. Применение облачного решения будет интересно организациям, которые ограничены в бюджете на информационные технологии и информационную безопасность, поскольку позволяет обойтись без закупки оборудования и ПО. Впрочем, следует помнить, что при этом учётные данные пользователей передаются за пределы периметра, пусть и в защищённом виде.

В STA используется технология контекстозависимого доступа SSO. Данная технология позволяет настраивать правила управления доступом на основе таких атрибутов, как идентификатор пользователя, местоположение, IP-адрес устройства и другие. При этом такие настройки можно делать для каждого приложения отдельно, что позволяет регулировать работу пользователей с приложениями на основе контекста, т. е. таких критериев, как разрешённое для доступа устройство, соответствие операционной системы, страна доступа и другие. Можно сказать, что к стандартным атрибутам, используемым для управления доступом пользователей, добавляются дополнительные атрибуты для настройки.

Функциональные возможности SafeNet Trusted Access

Общие положения

STA обладает значительным количеством возможностей в части управления доступом пользователей и идентификаторами (токенами). Как уже упоминалось выше, платформа сочетает в себе функциональность сразу трёх типов систем: по управлению доступом и учётными данными пользователей (IAM), организации единой точки доступа (SSO) и обеспечению многофакторной аутентификации с использованием различных токенов (MFA). В последней части продукт повторяет возможности SafeNet Authentication Service.

STA поддерживает следующие методы аутентификации:

• пароли Active Directory (AD),
• Kerberos,
• статические пароли,
• одноразовые пароли (OTP) в пуш-уведомлениях,
• мобильное приложение MobilePASS+,
• SMS,
• аппаратные токены SafeNet OTP,
• графические токены GrIDsure,
• на основе сертификатов.

Взаимодействие со сторонними системами организовано через обычный набор стандартов аутентификации, включая RADIUS, OpenID и SAML.

Для администрирования в STA предусмотрено две консоли:

1. Консоль управления токенами. С её помощью можно распоряжаться не только самими аутентификаторами, но и правилами их выдачи и применения, а также пользователями, операторами и т. д. Она совпадает с консолью SafeNet Authentication Service, рассмотренной в нашем обзоре.
2. Консоль управления доступом. Здесь настраиваются политики доступа к веб-приложениям, а также интеграция и мониторинг работы с последними.

Две консоли связаны между собой через расширенное меню функций. Соответственно, администратор может перемещаться между ними не предоставляя свои учётные данные снова, если он использует один и тот же браузер.

Для пользователей предусмотрен портал самообслуживания, где можно ознакомиться с перечнями доступных приложений и используемых токенов.

Выделим следующие функции STA, не описанные ранее:

• Можно осуществить массовую раздачу токенов — например, когда происходит миграция пользователей из приложений либо встраивание STA в уже функционирующую систему.
• Поддерживаются переинициализация (перепрограммирование) токенов «на лету» и загрузка в них новой секретной величины.
• Имеется возможность изменить внешний вид портала самообслуживания под фирменный стиль организации.
• Доступен широкий набор различных отчётов о событиях. В рассматриваемой версии STA есть 49 типов отчётов и гибкие возможности по их настройке. Можно, например, настроить отправку сводок различным заинтересованным лицам, задав свой тип отчёта для каждого из них.
• Сеанс единого входа (SSO) существует только в контексте экземпляра браузера и запускается тогда, когда пользователь успешно обращается к приложению с помощью STA. Если пользователь работает из нескольких разных сеансов браузера одновременно, то у него будет отдельная сессия единого входа для каждого из них.

Консоль управления доступом STA

Первая вкладка консоли управления доступом — это «Панель мониторинга», где отображается графическое представление общего количества попыток доступа за предыдущие 30 дней (по дням), по настроенным политикам и по приложениям. Визуализация даёт быстрый обзор попыток доступа и позволяет выявить аномальное поведение пользователя.

Общий вид панели приведён на рисунке 1.

Рисунок 1. Панель мониторинга в консоли управления доступом STA

Следующая вкладка — «Пользователи» (Users) — отображает доступные для администрирования учётные записи с основной информацией по ним. Общий вид этой панели показан на рисунке 2.

Рисунок 2. Панель «Users» в консоли управления доступом STA

По каждому пользователю можно просмотреть статистику его аутентификаций, а также то, какие приложения ему назначены для доступа. Пример информации по пользователю приведён на рисунке 3.

Рисунок 3. Панель «Users» в консоли управления доступом STA, информация по пользователю

Следующая вкладка — «Приложения» (Applications) — в соответствии с названием отображает перечень приложений, которые будут доступны (разрешены или необходимы) для использования. Также здесь настраиваются права доступа к этим приложениям и взаимодействие STA с последними. Общий вид панели приведён на рисунке 4.

Рисунок 4. Панель «Applications» в консоли управления доступом STA

В STA уже есть перечень готовых приложений для интеграции, притом значительный и постоянно пополняемый. Общий вид списка приложений изображён на рисунке 5.

Рисунок 5. Общий вид списка приложений на панели «Applications» в консоли управления доступом STA

Следующая панель — «Политики» (Policies) — является одной из основных вкладок консоли. Здесь можно настроить глобальную политику доступа, которая определяет то, как запросы для всех приложений применяются ко всем пользователям. Кроме того, можно добавить политики исключений для определённых групп пользователей и приложений. Общий вид этой панели приведён на рисунке 6.

Рисунок 6. Панель «Policies» в консоли управления доступом STA

В STA выделено два типа политик: глобальные и политики исключений.

Глобальная политика — это своего рода вариант по умолчанию, который применяется только в том случае, если ни одна политика исключений не соответствует области действия запроса на доступ. Область действия глобальной политики охватывает все группы пользователей и приложений, а настройки минимальны. Вы можете сконфигурировать только требования проверки подлинности по умолчанию, которые применяются ко всем пользователям и приложениям. Изначально глобальная политика настроена со следующими требованиями к аутентификации: пароль домена один раз за сеанс и OTP при каждой попытке доступа.

Настройки глобальной политики показаны на рисунке 7.

Рисунок 7. Настройка глобальной политики в STA

После первоначальной настройки глобальной политики STA предлагает сконфигурировать глобальные сценарии, позволяющие задать различные требования к проверке подлинности (предоставляется ли доступ или запрещён, какой метод проверки должен использоваться, с какой частотой пользователи должны её проходить) для определённого набора условий. Сценарий всегда действует в рамках политики и изменяет её требования к доступу, когда выполняются указанные условия контекста. Можно настроить необходимое количество сценариев; состав этих настроек одинаков как для глобальной политики, так и для политик исключений.

Общий вид настроек сценария для глобальной политики приведён на рисунке 8.

Рисунок 8. Общий вид настроек сценария для глобальной политики в STA

Сценарий включает в себя следующие условия (атрибуты) — так называемые настройки контекстозависимого доступа:

1. «Network» — проверяет, локализуется ли попытка доступа внутри или за пределами указанных сетей. При настройке задаются IP-адреса или диапазоны IP-адресов для проверки.
2. «Anonymizer» — проверяет, не происходит ли запрос доступа с использованием анонимайзера (VPN, прокси-сервер или Tor), скрывающего реальный IP-адрес отправителя. В работе этого условия участвует регулярно обновляемая база данных IP Intelligence, которая отслеживает анонимайзеры в общедоступной сети.
3. «Known User Device» — проверяет, происходит ли попытка доступа с известного пользовательского устройства или с нового. Это условие определяет, успешно ли сотрудник прошёл аутентификацию с помощью данного устройства в указанный период.
4. «Domain-Authenticated User Device» — проверяет, прошёл ли пользователь проверку подлинности с тем же устройством в домене Windows в заданный период. STA определяет наличие действительного билета Kerberos на устройстве в настоящее время или в течение указанного периода.
5. «Operating System» — проверяет, включена ли операционная система конкретного устройства в заданный перечень ОС и их версий. Это условие позволяет настроить поведение политики для случаев, когда ваша ИТ-группа поддерживает или не поддерживает определённые операционные системы.
6. «User Location» — проверяет, происходит ли попытка доступа из указанных стран.
7. «Country Change» — проверяет, происходит ли попытка доступа из другой страны по сравнению с предыдущим успешным доступом того же пользователя.

Ещё есть дополнительные настройки, где можно сконфигурировать взаимодействие с применяемыми системами безопасности (по API) и с существующей инфраструктурой аутентификации, использующей PKI, смарт-карты и сертификаты, сделать ребрендинг консоли входа. Также возможно настроить параметры передачи журналов через API (например, в SIEM) и т. д. API в STA применяется в управленческих целях. Действия, выполняемые через консоль управления доступом STA (создание пользователей, назначение приложения, получение журналов из STA и другое) можно реализовать через API, что позволяет достичь более тесной интеграции с уже применяемыми системами безопасности. Окно дополнительной настройки в консоли управления доступом STA изображено на рисунке 9.

Рисунок 9. Окно дополнительной настройки в консоли управления доступом STA

Портал для пользователей STA

В SafeNet Trusted Access есть портал самообслуживания (User Portal), который поможет автоматизировать часть операций и снизить нагрузку на администраторов. На портале самообслуживания пользователь может оставить всю информацию, необходимую для выпуска токена. Администратору останется только подтвердить её и отправить ссылку на формирование токена. Например, если пользователь забыл, какую траекторию он выбрал для механизма графической аутентификации GrIDsure, то он может самостоятельно сбросить её на портале самообслуживания и задать новую.

Общий вид домашней страницы портала самообслуживания приведён на рисунке 10.

Рисунок 10. Домашняя страница портала самообслуживания STA

На рисунке 11 показан общий вид вкладки с приложениями пользователя портала самообслуживания.

Рисунок 11. Приложения пользователя на портале самообслуживания STA

Общий вид вкладки с аутентификаторами (токенами) пользователя портала самообслуживания приведён на рисунке 12.

Рисунок 12. Аутентификаторы (токены) пользователя на портале самообслуживания STA

Архитектура SafeNet Trusted Access

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

Для управления филиальной сетью существует возможность выделить несколько серверов аутентификации и построить из них иерархию. Дополнительной функцией STA является организация совместного использования сервера аутентификации с двумя или более виртуальными серверами — или, другими словами, обеспечение общего доступа и разделение на области (под областью понимается группа виртуальных серверов). Таким образом STA позволяет реализовать схему, где сотрудники конкретного территориального подразделения имеют доступ только к своим приложениям, но одновременно с этим существует выделенная рабочая область, с приложениями из которой могут работать сотрудники как головного офиса, так и филиалов. Это обеспечивается настройками политик каждого сервера аутентификации.

Общее представление распределённой архитектуры STA приведено на рисунке 13.

Рисунок 13. Общее представление распределённой архитектуры STA

Системные требования SafeNet Trusted Access

Платформа STA является полностью облачной. На локальном уровне (внутри периметра) может потребоваться только установка агентов синхронизации, которые упростят заполнение STA данными вкупе с дальнейшим внесением изменений и контролем пользователей.

В качестве основных функциональных возможностей агента синхронизации можно выделить следующие:

• Может использоваться непосредственно с общими пользовательскими репозиториями.
• Может содержать пользовательские схемы для большинства серверов каталогов LDAP и SQL.
• Не записывает данные в пользовательский источник.
• Не требует учётной записи администратора для подключения к пользовательскому источнику данных.
• Может синхронизировать несколько пользовательских источников, таких как серверы каталогов LDAP или SQL.
• Использует шифрование AES при обмене данными с STA.
• Поддерживает SSL-соединения с сервером каталогов LDAP или SQL.
• Поддерживает дополнительную синхронизацию паролей домена из источников пользователей AD.

Системные требования агента синхронизации (SafeNet Synchronization Agent) приведены в таблице 1.

Таблица 1. Системные требования агента синхронизации (SafeNet Synchronization Agent)

Сценарии использования SafeNet Trusted Access

Использование единой точки доступа (SSO) к различным приложениям

Демонстрацию работы с токенами мы уже проводили — в обзоре SafeNet eToken 5300 c SafeNet Authentication Client и обзоре SafeNet Authentication Service. Поэтому здесь рассмотрим более подробно сценарий организации единой точки доступа (SSO) к различным приложениям. Для этого нам понадобятся:

• заведение двух пользователей и назначение им токенов (будем считать, что это уже сделано),
• настройка приложений для реализации взаимодействия с SafeNet Trusted Access через SSO,
• настройка политик доступа пользователей,
• проверка работоспособности входа через SSO.

Все настройки выполняются в консоли управления доступом STA.

Процесс заведения пользователей и выдачи им токенов, а также настройки журналирования подробно описан в документации на систему, поэтому пропустим его и просто скажем, что для одного пользователя был установлен токен GrIDsure, а для второго — MobilePASS+.

Итак, в консоли управления доступом STA на вкладке «Applications» добавляем приложения для входа через единую точку доступа (SSO). Портал самообслуживания там уже есть по умолчанию; в дополнение к нему мы выбрали Zoom и Dropbox, как показано на рисунке 14.

Рисунок 14. Добавление приложений, для которых будет настраиваться доступ через единую точку доступа (SSO), в STA

Для каждого приложения есть раздел «Help Documentation», в котором описывается каждый шаг настройки. Шагов немного, и они просты.

Настройка приложения Zoom и обмен метаданными с ним показаны на рисунке 15.

Рисунок 15. Настройка приложения Zoom в STA

Далее необходимо выполнить настройку STA для Zoom — в частности, указать домен для доступа. Настройки изображены на рисунке 16.

Рисунок 16. Настройка STA для приложения Zoom

На вкладке «Assign» настраивается то, кому будет разрешён доступ. Была выбрана ранее созданная группа пользователей (см. рис. 17).

Рисунок 17. Назначение пользователей для доступа к Zoom

Ещё одним моментом, который указан в документации по настройке приложения, является необходимость установить в его параметрах разрешение на доступ с использованием единой точки (SSO). Соответствующий фрагмент Help Documentation для Zoom приведён на рисунке 18.

Рисунок 18. Фрагмент Help Documentation для Zoom

Те же самые действия выполняются и для приложения Dropbox. 

После этого на вкладке «Users» заходим в данные о пользователе «Ivanov_am» и проверяем доступные ему приложения (см. рис. 19). 

Рисунок 19. Отображение доступных приложений для выбранного пользователя

Всё сделано правильно. Теперь необходимо настроить политики и сценарии доступа.

Настройка глобальной политики STA показана на рисунке 20; глобального сценария — на рисунке 21.

Рисунок 20. Настройка глобальной политики в STA

Рисунок 21. Настройка глобального сценария в STA

Настройка исключений в виде дополнительной политики и сценария показана на рисунках 22 и 23 соответственно.

Рисунок 22. Настройка политики исключений в STA

Рисунок 23. Настройка сценария исключений в STA

После этого проверяем работоспособность выполненных настроек: осуществляем пробный доступ пользователей к порталу самообслуживания, Zoom и Dropbox.

Вход на портал самообслуживания для пользователя Petrov_am проиллюстрирован рисунком 24. Напомним, что эта учётная запись использует графический механизм аутентификации GrIDsure.

Рисунок 24. Вход на портал самообслуживания STA для пользователя Petrov_am

Домашняя страница пользователя видна на рисунке 25.

Рисунок 25. Домашняя страница портала самообслуживания STA для пользователя Petrov_am

На вкладке приложений отображаются доступные данному пользователю программы (см. рис. 26).

Рисунок 26. Приложения пользователя Petrov_am

При нажатии на значок приложения осуществляется переход к Zoom для авторизации через единую точку доступа. В соответствии с настроенной политикой нам предлагается заново ввести данные токена, как показано на рисунке 27.

Рисунок 27. Подтверждение токена пользователя Petrov_am для осуществления входа в Zoom через единую точку доступа

После ввода кода мы попадаем в Zoom. В нашем случае, как видно на рисунке 28, выводится окно с ошибкой, так как провести тесты на корпоративной версии не представляется возможным и пользователь не является доменным. Тем не менее видно, что система управления доступом отработала все установленные настройки.

Рисунок 28. Вход в Zoom пользователя Petrov_am через единую точку доступа выполнен

То же самое проверяем для пользователя Ivanov_am, только доступ будем осуществлять к Dropbox.

Вход на портал самообслуживания для учётной записи Ivanov_am показан на рисунке 29. Этот пользователь применяет мобильный аутентификатор MobilePASS+.

Рисунок 29. Вход на портал самообслуживания STA для пользователя Ivanov_am

Пройдя аутентификацию, открываем вкладку с доступными приложениями и осуществляем переход к Dropbox. Аналогично предыдущему случаю в соответствии с настроенной политикой нам предлагается заново ввести данные токена (рис. 30).

Рисунок 30. Подтверждение токена пользователя Ivanov_am для осуществления входа в Dropbox через единую точку доступа

Снять скриншоты с MobilePASS+ не представляется возможным, так как мобильное приложение защищается от копирования информации на экране. Поэтому опишем принцип работы словесно: в MobilePASS+ приходит запрос на авторизацию, после подтверждения которого необходимо ввести PIN-код. Если все проверки прошли успешно, то пользователь автоматически попадает на портал самообслуживания. То же самое происходит при попытке получения доступа к приложениям.

Вход в Dropbox изображён на рисунке 31.

Рисунок 31. Вход в Dropbox пользователя Ivanov_am через единую точку доступа

Нажимаем кнопку «Продолжить» и переходим к приложению Dropbox. Так же как и в случае с Zoom, у нас нет корпоративной версии сервиса и пользователь не является доменным, поэтому появляется окно с ошибкой (рис. 32). Тем не менее видно, что система управления доступом отработала все установленные настройки.

Рисунок 32. Вход в Dropbox пользователя Ivanov_am через единую точку доступа выполнен

Проверка работы контекстозависимого доступа

Теперь проверим, как работает контекстозависимый доступ. Для начала необходимо произвести настройку сценария. Напомним, что варианты этой настройки включают в себя следующие атрибуты:

1. «Network».
2. «Anonymizer».
3. «Known User Device».
4. «Domain-Authenticated User Device».
5. «Operating System».
6. «User Location».
7. «Country Change».

Для проверки выберем и включим «Anonymizer», а также установим в требованиях запрет на доступ («Denied») при срабатывании данного сценария. В рамках последнего будет проверяться, не происходит ли запрос доступа с использованием анонимайзера (VPN, прокси-сервер или Tor).

Для тестирования будем применять функцию VPN браузера Opera, а также браузер Tor.

Настройки сценария приведены на рисунке 33.

Рисунок 33. Изменение сценария для доступа (контекстозависимый доступ), установка правила запрета на доступ с использованием анонимайзера

Осуществляем попытку доступа пользователя Ivanov_am к User Portal с использованием браузера Tor, как показано на рисунке 34.

Рисунок 34. Доступ пользователя Ivanov_am к User Portal с использованием браузера Tor

На экране отображается надпись о том, что доступ запрещён (см. рис. 35). Соответственно, делаем вывод, что наш сценарий отработал корректно.

Рисунок 35. Доступ пользователя Ivanov_am к User Portal с использованием браузера Tor запрещён

Проверим журнал по этому пользователю в консоли управления доступом STA (рис. 36). Видны записи об отказе в доступе.

Рисунок 36. Журнал действий пользователя Ivanov_am, отображаемый в консоли управления доступом STA

Теперь осуществим попытку доступа пользователя Petrov_am с включённым VPN в браузере Opera. Включение VPN показано на рисунке 37.

Рисунок 37. Включение VPN в браузере Opera

Открываем User Portal от имени пользователя Petrov_am, как показано на рисунке 38.

Рисунок 38. Доступ пользователя Petrov_am к User Portal с включённым VPN в браузере Opera

На экране вновь отображается надпись о том, что доступ запрещён (см. рис. 39). Следовательно, наш сценарий и здесь отработал корректно.

Рисунок 39. Доступ пользователя Petrov_am к User Portal с включённым VPN в браузере Opera запрещён

Проверяем журнал доступа для пользователя, как показано на рисунке 40.

Рисунок 40. Журнал действий пользователя Petrov_am, отображаемый в консоли управления доступом STA

Таким образом, проверка контекстозависимого доступа прошла успешно.

Выводы

Вопрос обеспечения информационной безопасности при управлении доступом был и остаётся до сих пор одним из основных. При этом с каждым годом развитие информационных технологий заставляет производителей совершенствовать средства защиты, а регуляторов — устанавливать требования по усилению мер борьбы с угрозами. Растёт количество приложений, которые необходимы пользователям для работы, что требует соответствующей реализации управления доступом к ним. При этом применить доменную политику не всегда возможно технически.

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

SafeNet Trusted Access от компании Thales представляет собой облачную платформу, обеспечивающую управление доступом и аутентификацией корпоративного класса и включающую в себя функциональность сразу трёх типов решений: IAM, SSO и MFA. При этом облачная реализация STA является как достоинством, так и недостатком: организации не придётся тратиться на ИТ-инфраструктуру для развёртывания решения и на её сопровождение, понадобится просто подключиться к облаку, но при этом учётные данные пользователей будут передаваться наружу, пусть и в защищённом виде. Конечно, боязнь облака можно отнести к разряду скептицизма, но всё же *aaS-сценарий создаёт дополнительные риски, такие как вероятность потери доступа к платформе, находящейся под управлением провайдера услуги, возможная недостаточность обеспечения информационной безопасности на стороне провайдера и, конечно, человеческий фактор.

STA обеспечивает централизованное управление доступом и аутентификацией применительно к различным приложениям, включая облачные, локальные и интегрированные с помощью SAML, OpenID Connect (OIDC) и RADIUS. Также предусмотрена возможность интеграции на основе агентов для конкретных локальных приложений с применением API, например с целью передачи журналов в SIEM-систему. Возможно интегрироваться с уже развёрнутой AD, а также использовать уже существующую инфраструктуру аутентификации через PKI, смарт-карты и сертификаты.

Интересной функциональной возможностью STA является настройка правил контекстозависимого доступа по SSO на основе таких атрибутов, как идентификатор пользователя, местоположение, IP-адрес устройства и другие.

Таким образом, платформа SafeNet Trusted Access обладает значительным набором возможностей по управлению доступом и аутентификацией, а также по интеграции с уже существующими информационными системами. Платформа будет интересна средним и крупным организациям с развитой инфраструктурой и большим количеством пользователей. При надлежащей настройке применение SafeNet Trusted Access позволит реализовать ряд нормативных требований: например, финансовые организации смогут выполнить предписания первого процесса ГОСТ Р 57580.1 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер», а также стандарта PCI DSS. В то же время следует отметить, что SafeNet Trusted Access не сертифицирована ФСТЭК России.

Достоинства:

• Облачная реализация, позволяющая избежать затрат на ИТ-инфраструктуру при внедрении и сопровождении, с возможностью создавать независимые полноценные серверы аутентификации.
• Интеграция через RADIUS, OpenID и SAML, взаимодействие с AD; наличие API, позволяющего передавать события по безопасности в SIEM-систему или организовать работу с любым другим информационным комплексом (например, подключиться к кадровой системе для заведения пользователей и блокировки учётных записей).
• Вход пользователей в разные приложения через единую точку (SSO) с возможностью настройки контекстозависимого доступа.
• Гибкие настройки политик доступа к приложениям.
• Большое количество настраиваемых отчётов.
• Возможность реализации требований основных российских регуляторов в части обеспечения защиты информации при управлении доступом пользователей.
• Использование уже существующей инфраструктуры аутентификации через PKI, смарт-карты и сертификаты.
• Мобильное приложение для аутентификации MobilePASS+.

Недостатки:

• Отсутствие русифицированного интерфейса, который упростил бы задачи по настройке или аудиту.
• Общие проблемы и ограничения облачных платформ, связанные с передачей данных вовне и необходимостью доверять внешнему поставщику услуг.