Регламент обеспечения целостности ИСПДн

Утечка данных — не единственный сценарий вреда для субъекта персональных данных. Если в системе исказится дата рождения клиента, диагноз в медицинской карте или сумма задолженности, это тоже нарушение, даже если посторонние к данным доступа не получили. Целостность отвечает именно за это: данные должны оставаться точными, полными и неизменными без надлежащего основания.

Мера входит в обязательный состав технических мер, необходимость применения которых следует из статьи 19 закона 152-ФЗ, и её конкретный объём зависит от уровня защищённости ИСПДн, определяемого по Постановлению Правительства РФ № 1119 от 01.11.2012.

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

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

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

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

Последний пункт часто упускают: резервная копия, которую никогда не пробовали восстановить, может оказаться повреждённой или неполной именно в момент, когда она нужна.

Стоит также решить, где физически хранятся копии: в том же месте, что и основная система, или в отдельном, географически разнесённом хранилище. Если оба комплекта данных находятся на одном оборудовании, авария или отказ этого оборудования уничтожит одновременно и рабочие данные, и резервную копию, что сводит смысл резервирования к нулю.

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

1. Ответственный сотрудник фиксирует факт повреждения и принимает решение о восстановлении из резервной копии;
2. сотрудник, отвечающий за инфраструктуру, технически выполняет восстановление;
3. оценивается объём данных, утраченных с момента последнего резервного копирования;
4. пользователи системы информируются о временной недоступности и о возможных потерях данных.

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

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

Там, где данные хранятся на собственных серверах, ответственность за резервное копирование и контроль целостности стоит закрепить за конкретным сотрудником приказом, а не оставлять «на усмотрение того, у кого дойдут руки» — это одна из самых частых причин, по которой резервные копии в реальности не делаются, несмотря на то что регламент формально существует.

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