• CIS Magazine

Новый стандарт ИТ-безопасности: как соответствовать?

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



Стандарт безопасности данных индустрии платёжных карт PCI DSS, разработанный Советом по стандартам безопасности индустрии платёжных карт, не стоит на месте и продолжает развиваться, адаптируясь к новым технологиям и тенденциям в сфере информационной безопасности.

Так, новая версия стандарта повлекла за собой не только изменения в терминологии, но и усиления требований в ряде механизмов защиты. Срок действия стандарта PCI DSS 3.1 истекает 31 октября 2017 года, а новые нормативные требования, определённые в спецификации PCI DSS 3.2, вступают в силу с 1 февраля 2018 года.


Новые требования

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


Под многофакторной аутентификацией в документе понимается выполнение минимум двух из трёх факторов аутентификации:

  1. фактор знания (например, пароль или парольная фраза);

  2. фактор владения (например, токен или смарт-карта);

  3. фактор свойства (например, биометрические данные).


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

  • В России принято разделять механизмы аутентификации по классам: базовая аутентификация (парольная), усиленная (с использованием одноразовых паролей), строгая (на основе инфраструктуры открытых ключей). В западной литературе усиленная и строгая аутентификация попадают в одну группу – строгая аутентификация (двухфакторная аутентификация, которая требует выполнения минимум двух факторов списка факторов аутентификации, представленного выше). Следовательно, и стандарт PCI DSS не разделяет данные понятия.

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

  • Многофакторная аутентификация может осуществляться на уровне сети, системы/приложений.


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


Способы решения

Исходя из требований стандарта и допущений, можно определить два пути решения задачи.


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


Первые два пункта мы опустим, так как хотя они и представляют некоторые сложности, но решаемы. А вот вопрос с интеграцией стоит достаточно остро. Скорее всего, интеграция электронных ключей будет осуществляться через протокол PKCS11 (если она вообще реализуема), который хоть и реализован во многих системах, но требует ювелирного совпадения версий библиотек и окружения. С этим часто приходится сталкиваться при организации двухфакторной аутентификации при входе в операционную систему. Для платформы Microsoft выглядит всё гладко, но как только возникает потребность в организации аутентификации в системах Linux/UNIX/BSD , вот тут начинается.


Дальше встаёт вопрос о возможности использования токенов и смарт-карт на рабочем устройстве – не каждое устройство оборудовано считывателем смарт-карт или имеет USB-разъём, к которому может быть подключён токен. Да и с точки зрения безопасности – невозможность использования USB-разъёма снимает вопрос о несанкционированном копировании на внешние устройства. Как результат, строгая аутентификация остаётся строгой, но накладывает ряд ограничений, которые не всегда могут быть применимы в компании.


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


Принцип интеграции бесконтактных аутентификаторов в 90 % случаев не привязан к среде, а опирается на стандартные протоколы, такие как RADIUS и SAML 2.0. В этом случае сервис выступает в роли некоего фронтенда, за которым скрыт механизм аутентификации на основе стандартного протокола. Некритично, если требуется интегрировать двухфакторную аутентификацию в продукт собственной разработки. Несколько строк кода позволяют внедрить в сервис RADIUS-клиент (на сегодня в сети доступна реализация RADIUS на клиента на всех популярных языках программирования), который, в свою очередь, предоставит пользователям аутентификацию с использованием одноразовых паролей.


Оптимальное решение

Задача поставлена, выбор сделан – сервер аутентификации на основе одноразовых паролей. Но что и как стоит выбирать?

В качестве объекта исследований мы возьмём решение от компании Gemalto – SafeNet Authentication Service (далее по тексту – SAS). Сразу бросается в глаза особенность в названии продукта – не Server, а Service. И это действительно так – решение представлено на рынке в 2 вариантах исполнения. Первый – сервер аутентификации, который разворачивается внутри компании, второй – сервер аутентификации, который предоставляется поставщиком услуг из своего дата-центра.


Рассмотрим параметры, которые выделяют решение Gemalto на фоне конкурентов. Любое решение по безопасности вносит изменения в привычное функционирование системы для пользователя. И нередко приходится слышать от клиентов, что сервисом становится просто невозможно пользоваться из-за неудобств, с которыми сталкивается клиент. В части аутентификации, с чем приходится иметь дело – это разного рода аутентификаторы (генераторы одноразовых паролей). В продуктовой линейке аутентификаторов можно подобрать генератор, который оптимально подойдёт для использования, исходя из угроз безопасности, удобства эксплуатации и цены. Так, аппаратные генераторы по-прежнему остаются наиболее востребованными для защиты критически важных объектов инфраструктуры (обусловлено это тем, что генерация значения пароля происходит изолированно от среды функционирования самого сервиса). Помимо этого, всегда можно подобрать оптимальный форм-фактор для аутентификатора – начиная от брелока с PIN-кодом для защиты устройства и заканчивая генератором в виде смарт-карты.



Большую популярность стали приобретать программные генераторы одноразовых паролей, которые могут быть установлены на мобильный телефон, тем самым превратив его в аутентификатор. Развитие таких токенов также обусловлено и развитием мобильных технологий в целом. Так, например, в линейке программных аутентификаторов Gemalto представляет приложение MobilePass+, которое поддерживает технологию PUSH OTP (на сегодняшний день данная технология поддерживается только в «облачной» версии SAS). Данная технология состоит в том, что после ввода идентификатора в сервисе, куда необходимо получить доступ, на мобильный телефон приходит PUSH-уведомление. Пользователю необходимо разблокировать мобильное приложение MobilePass+ (используя PIN-код или биометрию) и выбрать одну из кнопок: «DENY» или «APPROVE». При нажатии кнопки «APPROVE» приложение само передаст значение одноразового пароля, не требуя дополнительных действий со стороны пользователя.


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


Ожидаем от читателя вопрос: одноразовые пароли хотя и представляют собой динамические значения, но где же та самая двухфакторная аутентификация? Аутентификатор обеспечивает только то, «что я имею», а где то, что «я знаю»? Решение SAS позволяет для каждого аутентификатора задать свой PIN-код. PIN-код может быть как для защиты самого аутентификатора (например, для формирования значения пароля или разблокировки приложения пользователь должен ввести PIN-код), так и дописываться к значению одноразового пароля при вводе его на сервисе, то есть динамический пароль будет иметь вид «PIN-код + значение одноразового пароля». Данная комбинация позволяет использовать решение SAS как полноценный сервер двухфакторной аутентификации.


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


Отдельно стоит отметить процедуру назначения аутентификаторов пользователям. Процедура не сложнее регистрации в социальных сетях. Администратор SAS или же сама система SAS в случае выполнения правил автоматического назначения аутентификатора отправляет пользователю почтовое сообщение со ссылкой на активацию токена. Пользователю необходимо перейти по ссылке и в случае аппаратного токена – ввести его серийный номер и значение одноразового пароля для синхронизации с сервером, в случае с графическим токеном – задать траекторию, а во всех остальных случаях система всё сделает сама. С учётом времени развёртывания сервера SAS и данной процедуры активации аутентификаторов настройка механизма двухфакторной аутентификации для 20 000 пользователей займёт не более 15 минут.


Архитектура Multi-Tier Multi-Tenant


Особенности сервера

Сервер SAS представляет собой веб-приложение и набор сервисов, функционирующих на платформе Microsoft Windows. Решение легко масштабируемо за счёт простой интеграции отдельных экземпляров SAS в кластер, что позволяет выполнять балансировку нагрузки при большом количестве пользователей системы. Исключительной особенностью решения является то, что оно поддерживает архитектуру Multi-Tier Multi-Tenant – когда на одном экземпляре сервера аутентификации можно развернуть древовидную структуру из нескольких дочерних серверов аутентификации с возможностью наследования определённых параметров (например, настройка почты или SMS-шлюза), но позволив при этом серверу существовать автономно – использовать собственного администратора сервера аутентификации, выполнять синхронизацию пользователей из различных источников, таких как Active Directory, LDAP, таблицы баз данных, а также задавать собственные политики безопасности. Такая архитектура позволяет сделать SAS единой точкой аутентификации пользователя для предприятий различных размеров.


Для любой системы аутентификации очень остро стоит вопрос интеграции с внешними сервисами. Можно говорить, что в 90 % случаев SAS интегрируется «из коробки». SAS использует готовые агенты для платформы Microsoft Windows. В список сервисов входят агенты для входа на рабочие станции и серверы (с возможностью работы в автономном режиме без доступа к серверу SAS), Microsoft IIS, Microsoft OWA, Microsoft SharePoint, Microsoft RDP, Microsoft RDWeb Gateway, Microsoft ADFS. Если агенты неприменимы, интеграция с сервисами может быть выполнена через протоколы RADIUS и SAML, которые уже реализованы в решениях, где требуется двухфакторная аутентификация, либо может быть добавлена их поддержка в решения собственной разработки.


Любое решение, связанное с безопасностью, должно предоставлять механизмы аудита. В этом направлении SAS также предоставляет широкую функциональность, которая реализуется двумя способами. Первый из них состоит в возможности формирования по запросу или по расписанию отчётов на основе существующих шаблонов (на текущий момент существует порядка 50 шаблонов) с возможностью их просмотра непосредственно в самой системе или отправки на почту. Второй способ состоит в отправке записей аудита во внешние системы, к которым относятся: файловое хранилище, Microsoft Event Viewer, syslog (включая интеграцию с SIEM-системами).


Что в итоге

Представленные выше функции решения SAS позволят легко и быстро внедрить двухфакторную аутентификацию как для рядовых пользователей, так и для администраторов систем. Использование одноразового пароля позволит упростить процедуру аутентификации, снизив риски, которые были при использовании статического пароля. При необходимости, список сервисов, которые будут требовать использование одноразовых паролей, можно расширить за счёт использования стандартных протоколов аутентификации RADIUS и SAML. Автоматизация и механизмы аудита позволят бесшовно внедрить усиленную аутентификацию, обеспечив тем самым как усиление системы безопасности, так и соответствие новым требованиям стандарта PCI DSS.

_____________________________________


Gemalto

www.safenet.gemalto.com www.gemalto.com


TESSIS – официальный дистрибьютор в России

www.tessis.ru

Просмотров: 188

© 2020, СIS (Современные Информационные Системы).     info@sovinfosystems.ru     Журнал предназначен для лиц старше 16 лет.