Правовой статус резервных копий с персональными данными
Резервная копия базы данных, содержащей персональные данные, является такой же информационной системой персональных данных (ИСПДн) в понимании ФЗ-152, что и основная база. Это значит, что на резервные копии распространяются те же требования закона: локализация по статье 18.1, техническая защита по статье 19, ограничение доступа, соблюдение сроков хранения по статье 5. Это нередко упускают из виду: компания переносит основную базу на российский сервер, но резервные копии продолжает хранить в AWS S3 или Google Cloud — и нарушение локализации сохраняется.
Статья 18.1 ФЗ-152 не делает исключений для резервных копий: при сборе персональных данных оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение, извлечение персональных данных граждан РФ с использованием баз данных, находящихся на территории Российской Федерации. Резервная копия является формой хранения данных.
Где можно и где нельзя хранить резервные копии с ПДн
| Сервис хранения | Серверы в РФ | Статус для бэкапов с ПДн | Примечания |
|---|---|---|---|
| Yandex Object Storage | Да | Допустимо | Аналог AWS S3, российская инфраструктура |
| Selectel Object Storage | Да | Допустимо | Дата-центры в Москве и Санкт-Петербурге |
| VK Cloud Storage | Да | Допустимо | Российская облачная платформа |
| МТС Cloud | Да | Допустимо | Инфраструктура МТС на территории РФ |
| Собственный сервер в России | Да | Допустимо | Требует надлежащей технической защиты |
| AWS S3 (регион eu-west, us-east) | Нет | Недопустимо | Серверы за пределами РФ |
| Google Cloud Storage | Нет | Недопустимо | Серверы за пределами РФ, нет российского региона |
| Microsoft Azure | Нет | Недопустимо | Нет дата-центров на территории РФ |
| Dropbox Business | Нет | Недопустимо | Серверы в США |
| iCloud | Нет | Недопустимо | Серверы Apple за пределами РФ |
| Backblaze B2 | Нет | Недопустимо | Серверы только в США и ЕС |
Сроки хранения резервных копий: принцип ограничения хранения
Статья 5 ФЗ-152 устанавливает принцип ограничения хранения: персональные данные не должны храниться дольше, чем необходимо для достижения целей их обработки. Это требование распространяется на резервные копии в полном объёме. Срок хранения резервных копий не может превышать срок хранения основных данных.
Как правильно настроить ротацию резервных копий
Если в политике конфиденциальности указан срок хранения данных клиентов 3 года, резервные копии с этими данными не могут храниться дольше 3 лет. Типичные схемы ротации:
- Ежедневные бэкапы — хранение 7-14 дней, затем автоматическое удаление
- Еженедельные бэкапы — хранение 4-8 недель
- Ежемесячные бэкапы — хранение не более срока хранения основных данных
- Полные архивные бэкапы — срок определяется политикой хранения данных
Ротацию следует настроить автоматически через скрипты или встроенные возможности сервисов резервного копирования, чтобы устаревшие резервные копии удалялись без ручного вмешательства.
Удаление по запросу субъекта
По статье 21 ФЗ-152 при удалении персональных данных по требованию субъекта оператор обязан обеспечить удаление данных и из резервных копий в разумный срок. На практике это означает необходимость либо иметь возможность выборочного удаления конкретных записей из резервных копий, либо установить политику: данные из резервных копий будут удалены в плановом порядке при следующей ротации (с указанием конкретного срока).
Шифрование резервных копий: техническое требование
Статья 19 ФЗ-152 и Приказ ФСТЭК N 21 требуют применения технических мер, исключающих несанкционированный доступ к персональным данным. Незашифрованная резервная копия, даже размещённая на российском сервере, не удовлетворяет требованиям закона в части защиты от несанкционированного доступа — если хранилище будет скомпрометировано, данные окажутся доступны злоумышленнику в открытом виде.
Стандарты шифрования для резервных копий
- AES-256 в режиме GCM или CBC — рекомендуемый стандарт для коммерческих систем (УЗ-3, УЗ-4)
- Шифрование должно применяться до передачи резервной копии в хранилище (шифрование на стороне клиента)
- Ключи шифрования должны храниться отдельно от зашифрованных данных (не в том же хранилище, что и бэкапы)
- Ключи шифрования должны иметь ограниченный доступ и ротироваться по расписанию
- Необходимо иметь процедуру восстановления ключей при аварии (key escrow)
Инструменты резервного копирования с поддержкой шифрования
- Restic — open source, шифрование AES-256-CTR, поддержка Yandex Object Storage и других S3-совместимых хранилищ
- Duplicati — open source, шифрование AES-256, веб-интерфейс, поддержка множества хранилищ
- BorgBackup — open source, шифрование AES-256-CTR, дедупликация, высокая скорость
- Veeam Backup — коммерческое решение, поддержка Windows/Linux, встроенное шифрование
- mysqldump + openssl — простой способ для MySQL: создать дамп и немедленно зашифровать через openssl enc -aes-256-cbc
Контроль доступа к резервным копиям
Принцип минимальных привилегий
Доступ к резервным копиям, содержащим персональные данные, должен быть предоставлен только уполномоченным лицам. Список лиц с доступом следует закрепить в приказе о назначении ответственного за обработку персональных данных или в отдельном регламенте. Типичная схема доступа: системный администратор (полный доступ для создания и восстановления бэкапов), ответственный за ПДн (доступ для проверки и аудита), руководитель ИТ (доступ для авторизации нестандартных операций). Рядовые сотрудники, менеджеры, маркетологи — доступа к резервным копиям не имеют.
Журналирование операций с резервными копиями
Все операции с резервными копиями должны фиксироваться в журнале. Журнал должен содержать: дату и время создания резервной копии, объём резервной копии и охватываемый период, имя пользователя или системы, создавшей копию, даты и инициаторов каждого восстановления, факты доступа к резервным копиям (просмотр, скачивание), даты плановых и внеплановых удалений резервных копий. Журнал операций является доказательством надлежащего выполнения требований ФЗ-152 при проверках Роскомнадзора.
Организационные документы для резервных копий с ПДн
Помимо технических мер, необходимы организационные документы:
- Регламент резервного копирования — описывает периодичность, хранилище, ответственных, процедуры проверки и восстановления
- Приказ об ответственном за обработку ПДн — определяет лицо, ответственное за работу с резервными копиями
- Перечень ИСПДн — включает резервные копии как отдельные ИСПДн или компонент основной ИСПДн
- Модель угроз — должна учитывать угрозы безопасности резервных копий
Особые случаи: специальные категории данных в резервных копиях
Если резервная копия содержит специальные категории персональных данных — медицинские сведения, биометрию, сведения о национальности или политических взглядах — требования к её защите существенно возрастают. Такая резервная копия соответствует ИСПДн уровня УЗ-1 или УЗ-2, что означает необходимость более строгого разграничения доступа, расширенного аудита событий и при определённых условиях — аттестации информационной системы. Если ваш сайт собирает специальные категории ПДн (например, медицинская платформа или система верификации личности), рекомендуется проконсультироваться с лицензиатом ФСТЭК при проектировании системы резервного копирования.
Чек-лист: 12 требований к хранению резервных копий с ПДн
- Резервные копии хранятся исключительно на серверах в России (требование ст.18.1 ФЗ-152)
- Используемое хранилище имеет документальное подтверждение размещения в РФ
- Резервные копии зашифрованы с использованием AES-256 или более стойкого алгоритма
- Шифрование выполняется до загрузки в хранилище (шифрование на стороне клиента)
- Ключи шифрования хранятся отдельно от зашифрованных резервных копий
- Настроена автоматическая ротация: устаревшие бэкапы удаляются по расписанию
- Срок хранения резервных копий не превышает срок хранения основных данных
- Доступ к резервным копиям ограничен: список уполномоченных лиц задокументирован
- Ведётся журнал всех операций с резервными копиями
- При удалении ПДн по запросу субъекта — данные удаляются и из резервных копий
- Резервные копии проверяются на возможность восстановления не реже 1 раза в квартал
- Хранилище резервных копий упомянуто в политике конфиденциальности
Практические сценарии: что делать с зарубежными бэкапами прямо сейчас
Если резервные копии персональных данных в настоящее время хранятся в зарубежном облаке (AWS S3, Google Cloud Storage, Azure Blob Storage), необходимо немедленно начать переход. Порядок действий:
- Выберите российское облачное хранилище (Yandex Object Storage, Selectel, VK Cloud)
- Настройте создание новых резервных копий сразу в российское хранилище
- Перенесите последние актуальные резервные копии в российское хранилище
- Удалите резервные копии из зарубежного хранилища
- Прекратите создание новых резервных копий в зарубежном хранилище
- Обновите политику конфиденциальности: укажите новое хранилище резервных копий
Не рекомендуется продолжать хранить бэкапы в обоих хранилищах "для надёжности" — это означает сохранение нарушения требования локализации.
Yandex Object Storage как альтернатива AWS S3
Yandex Object Storage является S3-совместимым сервисом, что означает: большинство инструментов резервного копирования и скриптов, написанных для AWS S3, работают с Yandex Object Storage с минимальными изменениями (только параметры endpoint, access key и secret key). Для перехода с AWS S3 на Yandex Object Storage в инструменте Restic: достаточно изменить переменную среды RESTIC_REPOSITORY, указав endpoint storage.yandexcloud.net. Для rclone: добавить новый remote типа s3 с параметром endpoint = storage.yandexcloud.net.
Проверка резервных копий: обязательная процедура
Создание резервных копий само по себе не гарантирует возможность восстановления данных. Регламент должен предусматривать регулярную проверку работоспособности резервных копий. Минимальная частота проверок: тест восстановления из резервной копии — не реже одного раза в квартал. Проверка включает: восстановление данных на тестовой среде (не на боевой), проверку целостности данных (сравнение контрольных сумм или количества записей), проверку работоспособности расшифровки (если используется шифрование). Результаты проверки фиксируются в журнале.
Уведомление об инцидентах с резервными копиями
Если резервная копия с персональными данными была скомпрометирована (утечка, несанкционированный доступ, кража носителя), оператор обязан уведомить Роскомнадзор. С 1 марта 2023 года действуют сроки: первичное уведомление — в течение 24 часов с момента обнаружения инцидента, уточнённое уведомление с описанием причин и принятых мер — в течение 72 часов. Уведомление направляется через портал Госуслуги или официальный портал РКН. Неуведомление об инциденте является самостоятельным нарушением и влечёт административную ответственность.
Резервные копии в контексте модели угроз
Приказ ФСТЭК N 21 требует разработки модели угроз безопасности для каждой ИСПДн. Резервные копии должны быть рассмотрены в модели угроз как самостоятельный объект защиты. Типичные угрозы безопасности резервных копий: несанкционированный доступ к хранилищу резервных копий, перехват резервной копии при передаче по сети, физическая кража носителя с резервной копией, умышленное уничтожение резервных копий (например, при атаке ransomware), случайное удаление резервной копии. Для каждой угрозы модель угроз должна предусматривать контрмеры.
Стоимость хранения резервных копий в российском облаке
| Хранилище | Цена за ГБ/месяц | Трафик | Минимальный размер объекта |
|---|---|---|---|
| Yandex Object Storage (холодное) | от 0.9 руб. | Входящий бесплатно | Нет ограничений |
| Selectel Object Storage | от 1.2 руб. | Входящий бесплатно | Нет ограничений |
| VK Cloud Storage | от 1.5 руб. | Входящий бесплатно | Нет ограничений |
| AWS S3 (us-east-1, для сравнения) | от 2.3 цента (около 2.1 руб.) | Исходящий тарифицируется | Нет ограничений |
Российские облачные хранилища в пересчёте на рубли нередко оказываются дешевле зарубежных аналогов. Переход с AWS S3 на Yandex Object Storage, таким образом, не только решает правовую задачу локализации, но и может снизить расходы на хранение.
Итог: минимальный набор мер для хранения резервных копий с ПДн
Выполнение следующего минимального набора мер позволяет привести хранение резервных копий в соответствие с требованиями ФЗ-152:
- Перенести резервные копии в российское облачное хранилище или на российский сервер
- Настроить шифрование резервных копий с ключом AES-256 до загрузки в хранилище
- Хранить ключи шифрования отдельно от зашифрованных данных
- Настроить автоматическую ротацию — устаревшие бэкапы удаляются по расписанию
- Ограничить доступ к хранилищу резервных копий по ролям
- Вести журнал операций с резервными копиями
- Раз в квартал проверять возможность восстановления из бэкапа
- Обновить политику конфиденциальности с указанием места хранения резервных копий
Резервные копии и соблюдение сроков хранения: технические решения
Автоматизация удаления устаревших резервных копий является ключевым требованием для соблюдения принципа ограничения хранения. Большинство инструментов резервного копирования поддерживают политики хранения. Пример настройки политики хранения в Restic: флаг —keep-daily 7 сохраняет бэкапы за последние 7 дней, —keep-weekly 4 за последние 4 недели, —keep-monthly 3 за последние 3 месяца. Всё остальное автоматически удаляется. Для MySQL можно автоматизировать ротацию дампов через скрипт с функцией удаления файлов старше N дней: find /backup -name ‘*.sql.gz’ -mtime +90 -delete.
Связь между резервными копиями и правами субъектов данных
Наиболее технически сложный вопрос в теме резервных копий и ФЗ-152 — это выполнение права субъекта на удаление данных при наличии множества резервных копий. Если в основной базе данные удалены, но остаются в 15 резервных копиях разной давности — данные фактически продолжают обрабатываться.
Практические подходы к решению этой проблемы:
- Политика "разумного срока" — в политике конфиденциальности и при ответе на запрос об удалении указывается, что данные будут удалены из резервных копий в рамках плановой ротации в течение N дней (например, 90 дней). Роскомнадзор признаёт этот подход допустимым при его прозрачном документировании.
- Изоляция резервных копий с удалёнными данными — резервные копии, созданные до даты удаления, помечаются как содержащие удалённые данные и уничтожаются по истечении срока хранения в приоритетном порядке
- Псевдонимизация в резервных копиях — персональные данные в резервных копиях хранятся в псевдонимизированном виде; при запросе на удаление удаляется ключ сопоставления, что делает восстановление личности из резервной копии невозможным
Физические носители с резервными копиями
Если резервные копии создаются на физических носителях (внешние жёсткие диски, ленточные накопители), требования ФЗ-152 применяются и к ним. Меры защиты: физические носители с персональными данными должны храниться в запираемом помещении или сейфе, доступ к носителям — только уполномоченные лица, транспортировка носителей за пределы контролируемой зоны — только в зашифрованном виде, уничтожение устаревших носителей — методами, исключающими восстановление данных (физическое уничтожение или многократная перезапись). Хранение незашифрованных физических носителей с персональными данными в обычном офисе без специальной защиты является нарушением ФЗ-152.
Документирование системы резервного копирования для РКН
При проверке Роскомнадзора инспекторы могут запросить документы, подтверждающие соблюдение требований к резервным копиям. Рекомендуется подготовить:
- Регламент резервного копирования (описывает периодичность, хранилище, ответственных, процедуры восстановления)
- Акт о местонахождении системы резервного копирования (подтверждает российские серверы)
- Договор с провайдером облачного хранилища (с указанием российского дата-центра)
- Журнал операций резервного копирования за проверяемый период
- Сведения о применяемом шифровании (алгоритм, длина ключа, место хранения ключей)
Наличие этих документов значительно снижает риски при проверке и демонстрирует системный подход оператора к защите персональных данных.
