Шифрование резервного копирования
Резервные копии нужны везде, но сами резервные копии стали целью преступников. Если в них хранятся персональные данные или финансовая информация, то шифрование резервного копирования превращается из желаемого в необходимое. На практике резервное копирование реализуют неправильно. Резервные копии данных часто остаются без шифрования в общем хранилище с простыми ключами доступа. Когда злоумышленник находит путь к резервным копиям, он получает доступ ко всей базе организации. В случае утечки резервных копий масштаб инцидента намного больше, чем при компрометации основного рабочего сервера.
Открытое сетевое хранилище резервных копий может стать источником утечки, если к нему нет надёжного контроля доступа и шифрования. Для снижения риска ограничивают сетевой доступ, защищают учётные данные и проверяют настройки хранилища.
Ещё один риск — вредоносная программа может зашифровать и рабочие данные, и доступные ей резервные копии. Для снижения риска ограничивают права к хранилищу, хранят отдельную копию и проверяют восстановление.
Незащищённое сетевое хранилище резервных копий повышает риск утечки. Проверьте доступ к нему, парольную политику, шифрование и журналы действий.
Организации полезно вести реестр резервных копий: где они хранятся, кто имеет к ним доступ и когда проверялось восстановление. Без такого учёта копии могут остаться без контроля.
Основные векторы атак на незашифрованные резервные копии
Слабые стандартные пароли на сетевом хранилище облегчают несанкционированный доступ к резервным копиям. Замените такие пароли, ограничьте сетевой доступ и проверьте права учётных записей.
Второй вектор: облачное хранилище S3 с шумным именем, открытое интернету. Резервные копии данных видны в поисковиках, файлы скачиваются без аутентификации. Ошибка в конфигурации доступа — и инцидент с утечкой персональных данных готов произойти.
Третий — внутренний администратор. Он имеет доступ к хранилищу резервных копий локального сервера, но никто не логирует его действия. Пароль к резервным копиям написан в исходном коде скрипта или на бумажке. Скопировать резервные копии на личный диск может любой сотрудник с доступом.
Четвертый: вредоносное ПО на серверах резервного копирования. Вирус скачивает или модифицирует резервные копии, передает данные третьей стороне. Если инциденты с ransomware уже случались в вашей компании, резервные копии в хранилище могут быть скомпрометированы.
Пятый: физический доступ. Жесткий диск с резервными копиями лежит на столе, потом его уносят. Если шифрования резервных копий нет, это готовая копия всей базы данных вашей компании.
Требования регуляторов к защите резервных копий
Статья 32 GDPR предлагает учитывать шифрование как одну из мер безопасности с учётом рисков обработки данных. Выбор конкретных мер зависит от контекста. Для резервных копий полезно оценить необходимость шифрования при хранении и передаче, а также порядок управления ключами.
CCPA (Калифорния): компания обязана защищать личную информацию потребителя с использованием разумных технических мер. Резервные копии без шифрования не соответствуют требованиям CCPA. Штраф: 100-750 долларов за каждого потребителя.
PDPA (Таиланд): требует защиты персональных данных от несанкционированного доступа. В контексте хранилища резервных копий это означает шифрование при хранении резервных копий и контроль доступа.
В России действует Закон о защите персональных данных. Если резервные копии содержат информацию о физических лицах, ответственность лежит на обработчике или контроллере персональных данных. Защита резервных копий конкретно означает: шифрование данных, логирование доступа к хранилищу резервных копий, изолированное хранилище на отдельном сервере.
Почему облачные провайдеры требуют обязательное шифрование
AWS S3: при загрузке резервных копий в облако шифрование включено по умолчанию и не может быть отключено на уровне enterprise-плана. Если попытаться создать политику доступа к хранилищу резервных копий без шифрования, API заблокирует запрос.
Azure Backup: все резервные копии автоматически зашифровываются при загрузке. Нельзя зашифровать резервные копии слабо — используется AES-256 или равноценное по стойкости шифрование.
Google Cloud: шифрование обязательно для всех резервных копий. Можно управлять ключами самостоятельно через Customer-Managed Keys, но базовая защита не отключается никогда.
Облачные провайдеры установили эти требования после серии громких инцидентов с утечками через открытые buckets. Репутационный удар привел к тому, что теперь шифрование резервных копий — это не опция, а требование.
Лучшие практики по защите резервных копий
Управление ключами. Используйте иерархию ключей шифрования. Главный ключ хранится в защищенном хранилище (HSM или Key Vault), рабочие ключи генерируются отдельно для каждой резервной копии или периода. Никогда не используйте один пароль для всех резервных копий — если ключ украден, все резервные копии скомпрометированы сразу.
Контроль доступа и логирование. Логируйте каждый доступ к хранилищу резервных копий: кто заходил, когда, что скачивал. Все это должно идти в SIEM или в систему централизованного логирования. Без логирования нет контроля и нет возможности обнаружить инцидент.
Multi-factor authentication. Для доступа к резервным копиям на локальном сервере или в облаке требуйте второй фактор: TOTP, аппаратный ключ, биометрия. Даже если пароль украден, второй фактор защищает хранилище резервных копий.
Географическое распределение. Не храните все резервные копии в одном дата-центре. Если там случится пожар, наводнение или массовый отказ оборудования, вы потеряете все резервные копии целиком. Разместите резервные копии в разных регионах, используйте разные облачные провайдеры или разные зоны доступности внутри одного провайдера.
Тесты восстановления. Запускайте восстановление данных из резервной копии каждый месяц. Зашифрованная резервная копия, из которой невозможно восстановить данные, — это просто занятое место на диске. Процесс восстановления должен работать быстро и без ошибок.
Изоляция от основных систем. Резервные копии должны храниться на отдельном хранилище, отдельном сервере, в отдельной сети, если возможно. Если основные серверы компании заражены вредоносным ПО, вредонос не должен иметь доступ к резервным копиям.
Практика 3-2-1. Создайте три копии данных, на двух разных типах хранилища (диск и облако, например), одну копию — вне офиса или вне основного дата-центра. Все три копии должны быть зашифрованы с разными ключами шифрования.
Это требует инвестиций времени на настройку и регулярный аудит, но это минимальная база защиты резервных копий. Без этого в момент инцидента вы обнаружите, что резервные копии либо скомпрометированы, либо удалены, либо недоступны для восстановления.