Изменения PCI DSS: усиление аутентификации

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

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

Многофакторная аутентификация

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

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

Необходимо отметить и следующие особенности новой версии стандарта.

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

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

Одноразовые пароли или открытые ключи?

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

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

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

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

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

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

Требования к серверу аутентификации

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

Рассмотрим основные требования, которые нужно учитывать при выборе решения.

1. Поддержка большого числа аутентификаторов. В зависимости от критериев критичности, удобства и возможных затрат всегда должен быть выбор. Сейчас наиболее  популярны аппаратные аутентификаторы (с точки зрения безопасности это – оптимальный выбор, так как генерация пароля происходит вне среды функционирования сервисов), программные аутентификаторы (дают возможность применять телефон пользователя как генератор одноразовых паролей), доставка паролей на почту или в виде SMS, графические аутентификаторы (одноразовый пароль генерируется на основе алгоритма, известного только пользователю).
2. Минимальные требования к среде функционирования. Идеальным вариантом будет поддержка архитектуры Multi-Tier Multi-Tenant: на одном экземпляре сервера аутентификации можно развернуть древовидную структуру из нескольких дочерних серверов аутентификации с возможность наследования определенных параметров (например, настроек почты или SMS-шлюза); при этом сервер может существовать автономно.
3. Способность выполнять синхронизацию пользователей из разных источников, таких как Active Directory, LDAP, таблицы баз данных с возможностями отслеживания изменений в хранилище данных пользователей и автоматического назначения аутентификаторов новым субъектам.
4. Умение кастомизировать политики для аутентификаторов (длина одноразового пароля, дополнительная защита PIN-кодом), задавать возможность ограничения доступа по определенным параметрам (день недели, время, доступ из определенного окружения).
5. Решение должно позволять пользователям активировать аутентификаторы «по воздуху». Это обеспечит снижение нагрузки на администраторов систем, возможность автоматизации процесса.
6. Обеспечение механизма аудита действий пользователей и администраторов с возможностью сохранения журналов во внешних системах (доставка отчетов по почте, интеграция с внешними системами аудита – EventViwer, Syslog, SIEM).
7. Решение должно предоставлять портал самообслуживания. Данный функционал позволит снизить нагрузку на администратора системы, поскольку удастся переложить повседневные задачи сопровождения сервера аутентификации на пользователей.

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