Тип: ОРД-артефакт под утверждение (D15 из docs/23 — «регламент бэкапов внутри контура»). Назначение: порядок резервного копирования и восстановления носителя ПДн (Сейфа) так, чтобы бэкап не стал каналом утечки и не покинул контур. Связано: 27 — восстановление двух БД, 33 — ротация соли, deploy/backup-vault.sh (скрипт), 18 §9 — слой «бэкапы».
Принцип: бэкап Сейфа — это копия ПДн. Он хранится внутри контура ИСПДн (или шифруется ГОСТ-средством), ключи никогда не покидают Сейф, доступ — как к самому Сейфу.
- Сейф (`vaultdb`):
vault.user_identity(связь id↔человек) +vault.disclosure_log(журнал) —
носитель ПДн. Отдельно от портала (deploy/backup-vault.sh).
- Портал (`db`): операционные данные без ПДн субъектов — отдельным заданием.
- Ключевой материал (
ANON_SALT, пароли БД) — НЕ в общих бэкапах; хранится в защищённом
хранилище секретов лицензиата.
- Бэкап Сейфа — внутри контура ИСПДн (тот же аттестованный сегмент) ЛИБО зашифрованный
сертифицированным СКЗИ (ГОСТ); ключи шифрования не покидают контур;
- ретенция — ‹N дней/копий›; ротация старых копий — автоматически;
- доступ к бэкапам — только ‹роль/лица›, как к самому Сейфу (журналируется).
- Полный бэкап Сейфа — ‹ежедневно в HH:MM›;
- проверка восстановления (test-restore на изолированном стенде) — ‹ежеквартально›;
- перед ротацией соли и обновлением контура — внеплановый бэкап (см. 33, 26).
Порядок — 27 — восстановление двух БД: портал и Сейф восстанавливаются согласованно (один и тот же ANON_SALT), иначе связка user_id ↔ человек порвётся. После восстановления — проверка раскрытия (DPO) и инварианта метрик.
Резервирование — зона лицензиата (слой 9 матрицы 18). Провайдер IaaS отвечает только за инфраструктуру.
Ответственный: ‹администратор›. Утверждение: ‹приказ № / дата›.