Если вам есть, что сказать сообществу профессионалов ИБ и ИТ – заведите здесь свой блог
Михаил Рожнов, технический директор компании Tessis
Стандарт безопасности данных в индустрии платежных карт (PCI DSS) продолжает развиваться, адаптируясь к новым технологиям и тенденциям в сфере информационной безопасности. Очередная версия стандарта зафиксировала не только изменения в терминологии, но и увеличение требований к ряду механизмов защиты.
Срок действия стандарта PCI DSS 3.1 заканчивается 31 октября 2017 г., а новые нормативные требования, определенные в спецификации PCI DSS 3.2, вступают в силу с 1 февраля 2018 г. Мы рассмотрим изменения стандарта, касающиеся усиления функции аутентификации, а также возможные способы решения задач, связанных с проверкой подлинности идентификатора и обеспечением соответствия PCI DSS.
Многофакторная аутентификация
Первое, на что стоит обратить внимание, – тот сегмент ИТ-инфраструктуры, на который нацелены требования к усилению механизмов аутентификации (использованию двухфакторной аутентификации). Сначала эти требования предъявлялись лишь при организации удаленного доступа к сети пользователей, администраторов и представителей сторонних компаний, осуществляющих ее поддержку. Теперь многофакторную аутентификацию необходимо использовать при неконсольном доступе администраторов, а также при любом удаленном доступе к среде сведений о держателях карт.
Под многофакторной аутентификацией в документе подразумевается применение минимум двух из трех факторов аутентификации, а именно факторов знания (например, пароля или парольной фразы), владения (например, токена или смарт-карты), свойства (например, биометрических данных). При этом сделано очень важное замечание (которое некоторые специалисты почему-то игнорируют): использование одного фактора дважды (например, двух отдельных паролей) не является многофакторной аутентификацией. А вот классическая модель двухфакторной аутентификации, подразумевающая применение факторов знания и наличия, полностью удовлетворяет требованию стандарта.
Необходимо отметить и следующие особенности новой версии стандарта.
Изменения механизмов аутентификации, связанные с организацией неконсольного (а точнее – удаленного) входа администраторов, обусловлены перенаправлением активности подразделения информационной безопасности на усиление функции аутентификации рядового удаленного пользователя. При этом не рассматриваются потенциальные риски при аутентификации пользователей с высоким уровнем привилегий – даже в условиях контролируемого периметра.
Одноразовые пароли или открытые ключи?
Исходя из требований стандарта, можно определить два пути решения задачи.
Первый вариант – использование двухфакторной аутентификации на основе инфраструктуры открытых ключей (PKI-инфраструктуры). В случае применения данного подхода необходимо развернуть внутри компании удостоверяющий центр, приложение для управления жизненным циклом ключей и смарт-карт, наконец, убедиться в возможности интеграции механизма аутентификации по сертификатам с требуемым сервисом. Первые два пункта мы опустим, поскольку они вполне решаемы, хотя в процессе их реализации и могут возникнуть сложности. А вот вопрос интеграции – достаточно острый.
Скорее всего, интеграция электронных ключей (если она вообще возможна) будет осуществляться через протокол PCSK11. Он реализован во многих системах, но требует ювелирного совпадения версий библиотек и окружения. С этим часто приходится сталкиваться при организации двухфакторной аутентификации при входе в операционную систему. На платформе Microsoft все проходит гладко, но как только возникает потребность в организации аутентификации в Linux/UNIX/BSD-системах, начинаются проблемы.
Дальше встает вопрос о возможности использования токенов и смарт-карт на рабочем устройстве – не каждое из них оборудовано картридером или имеет USB-разъем, к которому может быть подключен токен. Да и с точки зрения безопасности этот вопрос важен: невозможность использования USB-разъема снимает проблему несанкционированного копирования информации на внешние устройства. Таким образом, строгая аутентификация остается строгой, но накладывает ряд ограничений, которые не всегда можно реализовать в компаниях.
Второй вариант состоит в применении бесконтактных аутентификаторов, работающих на основе одноразовых паролей. Интеграция бесконтактных аутентификаторов в 90% случаев не привязана к среде, а опирается на стандартные протоколы, такие как RADIUS и SAML 2.0. В этом случае сервис выступает в роли фронт-энда, за которым скрыт механизм аутентификации на основе стандартного протокола. Некритично, если требуется интегрировать двухфакторную аутентификацию в продукт собственной разработки. Несколько строк кода позволяют внедрить в сервис RADIUS-клиент (сейчас доступны реализации RADIUS-клиента на всех популярных языках программирования), который, в свою очередь, обеспечит аутентификацию пользователей с применением одноразовых паролей.
Итак, мы выяснили, что внедрить технологию одноразовых паролей гораздо проще, чем аутентификацию по сертификатам. Осталось решить вопрос с самим сервером аутентификации.
Требования к серверу аутентификации
В отличие от инфраструктуры открытых ключей наличие удостоверяющего центра при использовании одноразовых паролей не требуется, что автоматически снижает трудоемкость эксплуатации сервера аутентификации. Сейчас на рынке – достаточно много игроков, которые являются разработчиками серверов аутентификации с применением бесконтактных токенов. Однако при выборе решения стоит в большей мере уделять внимание не собственно аутентификации (все эти серверы умеют проводить ее по одноразовому паролю), а функционалу, который обеспечивает скорость аутентификации, ее эффективность (несколько дней эксплуатации не приведут к отказу пользователей от одноразовых паролей), а главное, минимальные затраты на внедрение и эксплуатацию.
Рассмотрим основные требования, которые нужно учитывать при выборе решения.
Наличие данных возможностей позволит легко и быстро внедрить двухфакторную аутентификацию как для рядовых пользователей, так и для администраторов систем. Использование одноразового пароля упростит процедуру аутентификации и снизит риски, присущие статическому паролю. При необходимости список сервисов, подразумевающих применение одноразовых паролей, можно будет расширить за счет стандартных протоколов аутентификации RADIUS и SAML. Автоматизация и механизмы аудита позволят бесшовно внедрить усиленную аутентификацию, обеспечив усиление системы безопасности и соответствие новым требованиям стандарта PCI DSS.