Кредитные организации обязаны подтверждать по ГОСТ Р 57580.2 уровень соответствия защиты информации не ниже четвёртого — это действующее требование Положения Банка России № 851-П, заменившего 683-П; оценку проводит внешняя проверяющая организация не реже одного раза в два года. Системно значимым банкам при этом предписан усиленный — старший — уровень защиты. Оценка охватывает и банкоматный парк: стандарт прямо называет банкоматы среди объектов доступа (пункт 3.8 ГОСТ Р 57580.1), а инженеров, которые их обслуживают, относит к эксплуатационному персоналу — включая сотрудников подрядных организаций. Отдельного режима для устройств без постоянной связи в стандарте нет: меры доступа должны работать и там, где банкомат неделями не видит сеть.
Что стандарт требует от доступа инженеров
Доступ эксплуатационного персонала регулирует процесс 1 «Управление доступом». Для банкоматного парка ключевые меры такие:
- идентификация и многофакторная аутентификация эксплуатационного персонала — РД.4; для стандартного и усиленного уровней защиты это техническая мера, то есть её нужно показать в настройках, а не в регламенте;
- запрет хранения и передачи аутентификационных данных в открытом виде — РД.17, РД.18;
- регистрация входов и действий персонала — РД.40, РД.41, УЗП.22–УЗП.28;
- прекращение доступа и блокирование учётных записей по истечении срока — УЗП.13;
- смена аутентификационных данных при компрометации — РД.29;
- учёт персонализации, выдачи и уничтожения устройств аутентификации — РД.28.
Почему на банкоматах это провисает
Типовая схема обслуживания — сервисная учётная запись с паролем, который знают все инженеры подрядчика. По меркам стандарта здесь проваливается сразу несколько мер: аутентификация однофакторная, пароль передаётся из рук в руки в открытом виде, в журнале одна и та же запись без привязки к человеку, а отзыв доступа у одного уволившегося инженера означает смену пароля на всём парке.
Почему централизованные схемы не спасают
Обычные ответы на эту боль — каталог, централизованная раздача локальных учётных записей или системы хранения паролей. Все три упираются в одно и то же: решение о доступе живёт в центре, а вход происходит на устройстве, которое центр может не видеть без доступа к сети.
Каталог (LDAP, Active Directory). Персональная учётная запись каждому инженеру — мера УЗП.1 «персонифицированные учётные записи» (подробнее о ней ниже) закрыта, но вход требует связи с контроллером домена: нет связи — нет входа. Кэш последнего входа выручает только тех, кто уже входил на это устройство, и держит копию секретов инженера на каждом банкомате. Учётная запись, заблокированная в каталоге, продолжает входить там, куда блокировка не доехала.
Централизованное управление локальными учётными записями. Система создаёт и блокирует персональные учётные записи на самих устройствах. Каждый наём, увольнение и ротация — волна изменений по парку, и доезжает она со скоростью появления связи: новый инженер не войдёт, пока его учётная запись не доставлена, а запись уволенного живёт, пока не доставлена блокировка. Для УЗП.13 окно доступа уволенного равно времени, которое банкомат проводит без связи. И даже когда всё доехало, аутентификация осталась паролем — один фактор, требование РД.4 так и не выполнено.
Сейф паролей (password vault, PAM-бастионы). Учётная запись на устройстве общая, пароль инженер получает в центральной консоли перед выездом, после сессии система пароль меняет. На офлайн-парке смена упирается в ту же связь: пока банкомат не в сети, пароль общий и долгоживущий. В журнале устройства — общая учётная запись; кто входил, восстанавливается косвенно, по журналу выдачи паролей, и доказуемость такой привязки слабая. Многофакторность здесь есть — но на входе в сейф: банкомат по-прежнему принимает голый пароль, на самом устройстве фактор один. А аварийные конверты с паролями на случай недоступности сейфа возвращают парк к исходной точке.
Второй фактор без сети
РД.4 требует многофакторной аутентификации персонала, и на офлайн-устройстве выбор второго фактора жёстко ограничен. СМС, push и серверная проверка одноразовых кодов требуют связи. Одноразовые коды с проверкой на самом устройстве означают хранить секреты всех инженеров на каждом банкомате и полагаться на точность его часов. Остаётся криптографический носитель: единственный секрет — неизвлекаемый ключ у инженера, устройство отправляет носителю случайный вызов и проверяет подпись, целиком офлайн. К этой схеме приходит любое решение для офлайн-парка — независимо от того, чьё оно.
И одна оговорка, которую стоит снять заранее: механический ключ от сервисной зоны вторым фактором не считается. Система входа его не проверяет, на парке он обычно один на сотни устройств, а физический доступ стандарт учитывает отдельным подпроцессом — ФД, со своими мерами вплоть до видеофиксации. Замок сервисной зоны сужает круг тех, кто дотянется до консоли, но в счётчик факторов РД.4 не попадает.
Как эти меры реализует Tessera
Tessera — модуль входа для Linux-устройств. Инженер входит по личному удостоверению — сертификату X.509 на носителе; проверка выполняется целиком на устройстве, сеть для входа не нужна.
| Мера | Требование | Что делает Tessera |
|---|---|---|
| РД.4 | Многофакторная аутентификация | Вход по удостоверению на аппаратном токене: закрытый ключ не покидает носитель, доступ к нему открывает PIN. Фактор владения плюс фактор знания |
| РД.17, РД.18 | Никаких секретов в открытом виде | Проверка challenge-response: пароль не хранится на устройстве и не передаётся по каналам |
| РД.11 | Блокировка после неудачных попыток | Ограничение числа попыток входа в модуле |
| РД.40, РД.41, УЗП.22–УЗП.28 | Регистрация входов и действий | Каждый вход, выход и действие с ролью фиксируется локально — с именем инженера из удостоверения |
| УЗП.13 | Прекращение доступа по сроку | Срок действия зашит в удостоверение: доступ гаснет сам, в том числе на офлайн-устройстве |
| РД.29 | Отзыв при компрометации | Отзыв удостоверения через список отзыва — без выезда к устройству |
| РД.28 | Учёт выдачи средств аутентификации | Журнал выпуска удостоверений со сцепленными записями: изменение истории задним числом видно |
Про РД.4 — точнее: оба фактора здесь настоящие. Владение — аппаратный токен PKCS#11 с неизвлекаемым ключом, знание — PIN, который проверяет сам токен и после нескольких ошибок блокируется аппаратно. Факторы независимы: подсмотренный PIN бесполезен без предмета, украденный токен — без PIN, а скопировать ключ с него нельзя. Файл с ключом на обычной флешке этих свойств не даёт — файл незаметно копируется, а пароль к нему перебирается офлайн, — поэтому такую комплектацию мы многофакторной аутентификацией не называем.
Честно про УЗП.1
Мера УЗП.1 требует, чтобы персонал входил под персонифицированными учётными записями, — и это техническая мера на всех трёх уровнях защиты. Заводить на каждом из тысяч офлайн-банкоматов учётную запись каждому инженеру — тупик: любой наём и увольнение превращаются в объезд парка.
В Tessera учётные записи на устройстве ролевые, а личность инженера — в его удостоверении. Это расхождение с буквой меры, и мы его не прячем. Стандарт предусматривает выход: пункт 6.4 разрешает компенсирующие меры, когда техническая реализация невозможна или экономически нецелесообразна, а методика оценки учитывает их наравне с базовыми. Обоснование здесь прямое: цель персонификации — знать, кто действовал. Вход по личному удостоверению с записью имени в журнал даёт эту атрибуцию строже, чем персональная учётная запись, пароль от которой можно продиктовать коллеге.
Что увидит оценщик
По методике ГОСТ Р 57580.2 каждая мера оценивается на 0, 0,5 или 1, а свидетельствами для технических мер служат параметры конфигураций и электронные журналы. Tessera отдаёт свидетельства в готовом виде: конфигурацию модуля входа, журнал событий с составом полей по пункту 7.1.5 стандарта — кто, когда, с каким результатом и к какому объекту, — и журнал выпуска удостоверений. Для банка это означает меньше ручной работы при каждой двухлетней оценке.
Дальше — права
Вход — не весь процесс 1. Стандарт требует также хранить эталон предоставленных прав и сверять с ним фактические права на устройствах — УЗП.8 и УЗП.9, технические меры для стандартного и усиленного уровней. Для этой задачи мы готовим отдельный продукт — Census: декларативное описание ролевых учётных записей, групп и sudoers с проверкой фактического состояния устройства по декларации. Расскажем о нём отдельно.
Что остаётся на стороне банка
Ни один продукт не «соответствует ГОСТ Р 57580» сам по себе: оценку проходит организация, а средство защиты поддерживает реализацию конкретных мер. За банком остаются организационная часть процесса — правила предоставления доступа, распорядители, пересмотр прав, — и остальные процессы стандарта: сети, вредоносный код, инциденты, виртуализация.
Если у вас парк банкоматов или другой офлайн-парк и впереди оценка по 57580.2 — напишите нам: покажем меры вживую на стенде.