Аудит ИСПДН для торговой сети: незашифрованные бэкапы и роли без разграничений

В начале года РКН заметно прибавил в активности - проверок стало больше, протоколы по статье 13.11 КоАП идут плотнее, чем в 2018-м. Один из клиентов, торговая сеть с региональным присутствием, обратился с запросом на технический аудит ИСПДН сразу после того, как партнёры по отрасли получили протоколы от регулятора. Захотели понять, что у них самих за порядок, до того как это выяснит РКН.

Спойлер: порядок оказался неплохим на организационном уровне - политики есть, согласия на обработку оформлены, реестр операторов в наличии. Техническая картина была другой.

Контекст: что проверяет РКН в 2019

Формально Роскомнадзор проверяет соответствие 152-ФЗ в широком смысле. Но в части технической защиты требования конкретизированы Приказом ФСТЭК №21 - «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных». Уровень защищённости ИСПДН (УЗ1-УЗ4) определяет, какие конкретно меры обязательны.

У клиента - розница с программой лояльности, интернет-магазин, CRM. Данные клиентов: ФИО, контакты, история покупок, платёжные данные в части, которую они хранят на своей стороне. По модели угроз и категории данных - УЗ3, что означает вполне конкретный набор обязательных мер.

Что нашли: незашифрованные резервные копии

Первая находка была классической и неприятной. Резервные копии базы CRM и базы интернет-магазина хранились на выделенном NAS в серверной. Доступ к NAS - через SMB-шару с широкими правами: любой пользователь в корпоративном домене мог примонтировать и прочитать. Шифрования бэкапов - никакого. Дамп базы с ФИО, телефонами и email клиентов лежал как обычный файл.

Это нарушение сразу нескольких мер из Приказа №21: и по управлению доступом (ИАФ, УПД), и по защите машинных носителей (ЗНИ). Резервные копии ИСПДН - часть информационной системы персональных данных, они обязаны защищаться с теми же требованиями, что и основная система. Часто это упускают: бэкапы делаются «для себя», воспринимаются как техническая копия, а не как хранилище данных.

Исторически бэкапы настраивали давно, задача ставилась как «чтобы было», без проработки модели угроз. Никто специально не хотел оставить данные открытыми - просто не задавались вопросом.

Что нашли: отсутствие ролевого разграничения

Вторая история - права доступа в CRM. Система самописная, на PHP, поставлялась внешним подрядчиком несколько лет назад. Внутри - две роли: «администратор» и «пользователь». Администраторская роль выдана примерно двадцати сотрудникам, включая тех, кто занимается аналитикой и отчётами. Причина - некоторые отчёты были доступны только в административном разделе, и проще было выдать всем роль «администратор», чем разбираться с правами.

По факту это означало: два десятка человек имели полный доступ к базе клиентов, включая возможность экспорта, редактирования, удаления. Операторы call-центра, которым нужна только карточка клиента и история заказов - тоже с административными правами.

Приказ №21 в части управления привилегиями (УПД.5, УПД.6) требует разграничения по принципу минимальных привилегий. Это не просто методическая рекомендация - это обязательная мера для ИСПДН любого уровня.

Здесь работа сложнее, чем с бэкапами: нужно садиться и переделывать логику ролей в приложении. Быстрого патча нет.

Что ещё попало в акт

Помимо двух основных находок, аудит вскрыл несколько менее критичных, но документируемых нарушений:

• Журналирование действий пользователей в CRM отсутствовало. Кто и когда открывал карточку клиента, выгружал данные - не фиксировалось никак. По Приказу №21 (РСБ.1-РСБ.3) регистрация событий обязательна.
• Антивирусная защита на рабочих станциях была, но централизованного управления не было - обновления баз на части машин не проводились месяцами. Формально мера выполнена, фактически - нет.
• Документация по модели угроз оказалась двухлетней давности и не отражала изменения инфраструктуры: добавился интернет-магазин, поменялся хостинг.

Как фиксировать и что делать дальше

По результатам аудита подготовили акт с приоритизацией по степени риска и срокам устранения. Шифрование резервных копий - первый приоритет, технически несложно, закрывается за несколько дней. Бэкапы идут через стандартные инструменты, шифрование можно добавить на уровне скриптов резервного копирования с хранением ключей отдельно.

Переработка ролевой модели в CRM - это проект на несколько недель с участием разработчика. Нужно инвентаризировать, какие функции реально нужны каждой группе пользователей, и только потом двигаться к коду. Забегать вперёд и сразу переписывать права без этой работы - значит переделывать дважды.

Журналирование в большинстве случаев добавляется на уровне middleware без переписывания логики - но только если архитектура это позволяет. В данном случае позволяла, хотя потребовала нескольких часов работы с кодом.

Конкретные сроки устранения каждого пункта - в плане, который клиент сейчас согласует внутри. Если проверка РКН придёт до полного закрытия - наличие акта аудита и плана устранений формально улучшает позицию, хотя от протокола не защищает.

Если коротко: организационный порядок с документами не заменяет технической защиты ИСПДН. Регулятор становится конкретнее в вопросах именно технических мер - и аудит соответствия Приказу №21 сейчас актуальнее, чем был год назад.