В прошлой статье мы разобрали, какие меры доступа ГОСТ Р 57580.1 требует на банкоматах и как их проходить с оценщиком. Но у серии есть продолжение, о котором говорят реже: ГОСТ Р 57580.3-2022 об управлении риском информационных угроз и ГОСТ Р 57580.4-2022 об операционной надёжности. Это уже не про «защитить информацию», а про «пережить инцидент и уложиться в допустимое время простоя» — и требования к доступу инженеров здесь звучат жёстче, чем в первой части.

Формально оба стандарта — рекомендации, но опираются они на обязательные требования Банка России: положение № 716-П об управлении операционным риском и № 787-П об операционной надёжности. Сроки Банк России тоже назвал — в методических рекомендациях № 7-МР от 21.03.2024: крупнейшим банкам, с активами от 500 млрд рублей, — усиленный уровень обоих стандартов до конца 2025 года, остальным — до конца 2026-го. Первый из этих сроков уже наступил.

Инженер подрядчика — внутренний нарушитель

Первая неожиданность — терминологическая. Внутренний нарушитель по ГОСТ Р 57580.3 — это не только собственный сотрудник банка: определение прямо включает «работника поставщика услуг», реализующего угрозы «с использованием легально предоставленных им прав доступа» (пункт 3.25). Несанкционированные действия людей, у которых полномочия доступа есть, стандарт относит к отдельной категории источников риска — «действия персонала», и управлять ею требует иначе, чем внешними атаками.

Для банкоматного парка это значит: тысячи инженеров подрядных организаций с ключами и паролями от сервисных зон — не периферия, а именная категория риска. ГОСТ Р 57580.4 отводит ей целый процесс с мерами РВН: от договорных требований к работникам поставщика до обязанности поставщика уведомлять банк об увольнении или смене обязанностей работников с привилегированным доступом.

И вот здесь типовая схема с общей сервисной учётной записью ломается об арифметику. Уведомление об увольнении пришло — а отреагировать нечем: у уволенного нет своей учётной записи, которую можно заблокировать, есть общий пароль на весь парк. Честная реакция — смена пароля на тысячах устройств — превращается в объезд. Вход по личному удостоверению меняет и саму реакцию: отзыв одного сертификата, без выезда к устройствам. Список отзыва добирается до офлайн-устройств тоже с появлением связи — поэтому окно риска дополнительно ограничено коротким сроком действия самого удостоверения: оно истекает независимо от того, доехало обновление или нет.

Обслуживание требует аутентификации — теперь дословно

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

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

Вход инженера — часть контура восстановления

Главное, что добавляет 57580.4, — взгляд со стороны простоя. Стандарт требует установить для каждого процесса целевые показатели: целевое время восстановления, допустимое время простоя — и контролировать их (приложение с составом показателей обязательное). А теперь простая последовательность: банкомат встал, связи нет — возможно, инцидент её и уронил, — и первым к устройству приезжает инженер. Если вход на банкомат завязан на центральный каталог или сейф паролей, то чем серьёзнее авария, тем меньше шансов, что инженер вообще сможет войти и начать восстановление. Время простоя растёт не из-за поломки — из-за схемы доступа.

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

Как эти меры реализует Tessera

МераТребованиеЧто делает Tessera
ВПУ.12.1Аутентификация и регистрация операций при техническом обслуживанииВход по удостоверению на аппаратном токене; каждый вход, выход и действие с ролью — в журнале с именем инженера
РВН.6.2Реакция на увольнение работника поставщикаУведомление от подрядчика превращается в отзыв удостоверения без объезда парка; окно до доставки списка отзыва ограничено сроком действия удостоверения
ВРВ.1Выявление неправомерного использования доступа поставщиками услугЖурнал каждого устройства даёт свидетельства: кто, когда и с каким результатом входил — по каждому инженеру каждого подрядчика
ВРВ.28Регистрация действий при восстановлении после инцидентаВходы, выходы и действия с ролью фиксируются на самом устройстве — даже пока оно без связи
РОН.4Отказоустойчивость самих средств защитыПроверка входа локальная: в пути входа нет центрального компонента, который нужно резервировать

Смежная тема — стандарты конфигурирования: 57580.4 требует контролировать несанкционированные изменения конфигураций, прямо включая «разрешения и полномочия в отношении учётных записей» (меры УИ). Это задача Census — нашего инструмента, который сверяет фактические права на устройствах с эталоном; мы анонсировали его в первой части разбора.

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

ГОСТ Р 57580.3 — управленческий стандарт: политики, три линии защиты, база событий риска, показатели уровня риска. Никакой продукт его не «закрывает» — это работа банка, и мы на неё не претендуем. Для технических мер из таблицы выше действует та же оговорка, что и в первой части: средство защиты поддерживает их реализацию, а соответствие стандарту показывает банк. Методики оценки соответствия для третьей и четвёртой частей — аналога ГОСТ Р 57580.2 — пока не опубликовано, так что спрашивать за операционную надёжность будут не баллами, а надзором по 787-П. И ещё деталь: в самих стандартах положения Банка России по номерам не названы — они описаны через полномочия, на основании которых приняты; 716-П и 787-П — общепринятое прочтение этих ссылок.

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

Источники