Требование 8 PCI DSS описывает весь жизненный цикл доступа человека к системам среды держателей карт: как учётные записи заводятся, как проверяются, как блокируются и как прекращаются. Большинство его мер предполагает то, чего у устройства самообслуживания нет, — доступный в момент входа каталог, который умеет заблокировать идентификатор, завершить сессию и отрезать доступ, как только человек уволился.

Банкомат или киоск проверяет инженера, стоящего перед ним, часто без связи. При буквальном чтении часть мер требования 8 там невыполнима.

В PCI DSS 4.0 появился путь, которого не было раньше. Рядом с предписанной мерой у большинства требований указана Customized Approach Objective — цель меры. Организация вправе достичь этой цели собственными мерами, не выполняя предписанную дословно.

Формулировки требований ниже приведены в нашем переводе: стандарт издаётся на английском, официального русского текста у него нет — оригинал по ссылке в конце.

Почему это не облегчённый путь

Цену назначает требование 12.3.2:

Для каждого требования PCI DSS, выполняемого через customized approach, проводится целевой анализ рисков, включающий документальные свидетельства по каждому элементу Приложения D, как минимум — контрольную матрицу и анализ рисков.

На каждое требование — задокументированный анализ рисков, контрольная матрица и оценщик, который подтверждает достижение цели. Меньше проверок не становится; меры становятся другими, описанными и обоснованными.

У этого пути есть жёсткая граница: требования без указанной Customized Approach Objective для него недоступны вовсе. У всех мер, разобранных ниже, цель указана, — это стоит проверить в стандарте прежде, чем строить на них аргументацию.

Выполняется дословно, без всякой аргументации

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

8.3.11 Где в качестве факторов аутентификации используются физические или логические токены безопасности, смарт-карты или сертификаты: фактор закрепляется за отдельным пользователем и не разделяется между несколькими; физические и (или) логические меры гарантируют, что использовать фактор для получения доступа может только тот пользователь, которому он предназначен.

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

8.5.1 Системы МФА реализованы так: система не подвержена атакам повторного воспроизведения; МФА не может быть обойдена никем из пользователей, включая администраторов, кроме отдельно задокументированных и утверждённых руководством исключений на ограниченный срок; используются не менее двух разных типов факторов; для предоставления доступа требуется успех всех факторов.

Challenge-response отвечает первому пункту по построению: токен подписывает свежий случайный вызов, устройство проверяет подпись, и перехваченный обмен в следующий раз бесполезен. Владение и знание — два разных типа фактора, и ни один сам по себе сессию не открывает.

Где customized approach окупается

8.3.4 — блокировка. Предписанная мера: заблокировать идентификатор не более чем после 10 неудачных попыток, минимум на 30 минут или до подтверждения личности. Аппаратный токен считает попытки ввода PIN сам и блокируется по своему порогу. Через 30 минут он не разблокируется; на распространённых моделях он не разблокируется по таймеру вовсе — снимать блокировку приходится администратору. То есть предписанная мера не выполнена: нет ни блокировки идентификатора, ни получаса.

Цель 8.3.4 звучит так: «Фактор аутентификации не может быть подобран онлайн-перебором». Счётчик, который не сбрасывается сам, достигает её строже, чем механизм, открывающий дверь через полчаса. Замещающую меру к тому же легко подтвердить: порог попыток — свойство токена, описанное его производителем, а не настройка, которую эксплуатация может тихо ослабить.

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

Цель — «учётные записи уволенных пользователей не могут быть использованы». Оценщику стоит проговорить два свойства прямо. Отзыв точечный: удостоверение одного инженера перестаёт работать, не задевая ничей доступ ни на одном устройстве. И есть окно распространения: пока список не дошёл до конкретного устройства, оно ещё не знает. Окно ограничено частотой рассылки списков и остатком срока действия удостоверения — это ровно тот остаточный риск, который и должен быть посчитан в целевом анализе рисков. По сравнению со сменой общего сервисного пароля на всём парке с подтверждением доставки окно короткое и, что важнее, измеримое.

Чего механизм входа не закрывает

В требовании 8 есть меры, которые механизму входа приписывать незачем.

8.2.8 требует повторной аутентификации после 15 минут простоя. Это свойство настроек сессии и блокировки экрана в операционной системе, а не способа, которым инженер вошёл, и подтверждается отдельно.

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

Одну оговорку о применимости легко прочитать в свою пользу. И у 8.3.4, и у 8.2.8 сказано, что требование «не предназначено для применения к учётным записям пользователей на POS-терминалах, которые имеют доступ к одному номеру карты за раз для проведения единичной операции». Это описание POS-терминала, проводящего платёж. Сервисная сессия инженера на банкомате не POS-терминал и не ограничена одним номером карты — оговорка на неё не распространяется.

Честные границы

PCI DSS оценивает организацию, а не продукт. Границы среды, применимость требований и достижение цели любой замещающей мерой определяет ваш оценщик; никакое средство не бывает «соответствующим PCI» само по себе, а customized approach без целевого анализа рисков и валидации — это не подход, а намерение. Сертификаций PCI у Tessera нет, и мы их не заявляем.

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

Если у вас парк устройств самообслуживания и впереди оценка — напишите нам, разберём, какие из этих доводов применимы к вашей схеме.

Источники