Банкомат обрабатывает карточные данные, поэтому его сеть и окружение входят в среду держателей карт (CDE), и доступ инженеров к нему оценивается по PCI DSS. Версия 4.0 подняла планку аутентификации: многофакторная аутентификация теперь требуется не только администраторам, а для любого доступа в среду — требование 8.4.2, обязательное с 31 марта 2025 года. Инженер с клавиатурой у сервисной панели — тоже доступ.
Чего PCI DSS требует от доступа инженеров
- уникальный идентификатор каждому пользователю до предоставления доступа — 8.2.1; смысл требования стандарт формулирует прямо: каждое действие должно быть атрибутируемо конкретному человеку;
- многофакторная аутентификация: для неконсольного административного доступа — 8.4.1, для любого доступа в среду держателей карт — 8.4.2;
- если используются пароли: минимум 12 символов (8.3.6), а там, где пароль — единственный фактор, смена каждые 90 дней (8.3.9);
- общие учётные записи — только как исключение и на особых условиях (8.2.2, о нём ниже);
- журналирование доступа к системным компонентам и защита журналов от изменения — требование 10.
Почему пароли на банкоматном парке не проходят
Начнём с арифметики требования 8.3.9. Пароль — единственный фактор, значит, смена каждые 90 дней. На парке из тысяч устройств без постоянной связи это означает механизм, который четыре раза в год доставляет новый пароль на каждый банкомат и подтверждает, что пароль дошёл. Такого механизма обычно нет — и на оценке это всплывает как просроченные пароли или как одна «вечная» сервисная учётная запись на весь парк, то есть провал сразу 8.2.1, 8.2.2 и 8.3.9.
МФА добавляет второй тупик: одноразовые коды и push-подтверждения требуют связи в момент входа, которой у банкомата нет. Про это у нас есть отдельный разбор в статье про ГОСТ Р 57580 — вывод одинаковый для обоих стандартов: второй фактор на офлайн-устройстве практически означает криптографию на носителе.
Ключ от верхнего блока банкомата вторым фактором тоже не станет: факторы аутентификации — то, что предъявляется и проверяется при входе, а физическая защита — отдельное требование 9. К тому же замок сервисной зоны редко бывает уникальным даже в пределах парка.
Что меняет беспарольный вход
Tessera заменяет пароль сертификатом X.509 на аппаратном токене: инженер вставляет носитель, вводит PIN, устройство проверяет подпись случайного вызова — целиком локально, без связи с центром.
С точки зрения PCI DSS это не «ещё один пароль, только сложнее», а изменение состава требований:
- 8.3.6 и 8.3.9 уходят из объёма. Требования к длине и ротации применяются к паролям — там, где паролей нет, нечего проверять и нечем провалиться. Ротацию заменяет срок действия сертификата, который истекает сам, в том числе на офлайн-устройстве.
- 8.4.2 выполняется на самом устройстве — и оба фактора настоящие. Владение — токен с неизвлекаемым ключом, знание — PIN, который проверяет сам токен с аппаратным счётчиком попыток. Компрометация одного фактора не раскрывает второй: подсмотренный PIN бесполезен без предмета, украденный токен блокируется, а «продиктовать доступ» коллеге нельзя.
- Секрет не передаётся и не хранится на банкомате. Проверка challenge-response не оставляет на устройстве ни пароля, ни его хеша — перебирать нечего, фишинг и подбор исчезают как класс атак.
- 8.2.1 выполняется буквально. Уникальный идентификатор — субъект сертификата; он подтверждается криптографически до предоставления доступа и попадает в каждую запись журнала.
Общие учётные записи: 8.2.2 на нашей стороне
На устройствах Tessera учётные записи ролевые — и здесь PCI DSS заметно дружелюбнее, чем можно ожидать. Требование 8.2.2 разрешает общие учётные записи при условиях: использование обосновано и одобрено, личность пользователя подтверждена до предоставления доступа, а каждое действие атрибутируемо конкретному человеку.
Два технических условия из этого списка выполняются самой конструкцией входа: без личного сертификата роль не открывается, а имя инженера из сертификата пишется в журнал вместе с каждым входом и выходом. Остаётся оформить обоснование и одобрение — это документы, а не доработки. Для сравнения: в ГОСТ Р 57580 аналогичная мера УЗП.1 сформулирована жёстче, и там маршрут лежит через компенсирующие меры.
Журналы для требования 10
Каждый вход, выход и действие с ролью фиксируется на самом устройстве — с именем инженера, временем и результатом. Журнал выпуска сертификатов ведётся со сцеплением записей: изменение истории задним числом видно. Оценщику это даёт то, что требование 10 называет audit trail: цепочку от конкретного человека к конкретному действию на конкретном банкомате — включая периоды, когда устройство было без связи.
Честные границы
PCI DSS оценивает организацию, а не продукт: границы среды и применимость требований определяет ваш QSA, и никакое средство защиты не делает банк «соответствующим» само по себе. Tessera закрывает техническую часть перечисленных требований на доступе инженеров к устройствам; сегментация сети, защита карточных данных в обработке, управление уязвимостями — отдельные разделы стандарта и отдельные средства. Сертификаций PCI у продукта нет, и мы их не заявляем.
Если у вас банкоматный парк и впереди оценка по PCI DSS — напишите нам: покажем беспарольный вход на стенде и разберём ваш сценарий с оценщиком.
Источники
- PCI DSS v4.0.1, PCI Security Standards Council
- ГОСТ Р 57580 на банкоматах: меры доступа для инженеров — парный разбор для российского стандарта