Правило 3-2-1 помогает проверить, не зависит ли вся защита данных от одного места или устройства. Его классическая формулировка проста: три копии данных, два разных типа носителей и как минимум одна копия вне основной площадки. Однако одного подсчёта недостаточно. Нужно понимать, какой сбой может затронуть каждую копию и позволит ли она восстановить работу.
В руководстве CERT в США, три копии включают рабочие данные и две резервные копии. Оно не требует дополнительных трех резервных копий помимо оригинальной. Два типа носителей и резервная копия вне основного объекта снижают зависимость от одной причины сбоя.
Сначала определите данные и ожидаемый результат восстановления
Начните с бизнес-систем, а не с покупки диска. Определите файлы, базы данных, электронную почту и настройки, необходимые для восстановления важных операций. Убедитесь, что включены конфигурации приложений и информация, необходимая для использования данных. Для SaaS, уточните фактическое покрытие объектов, взаимосвязей и доступных операций восстановления.
Назначьте владельца для каждой защищенной системы. Этот владелец подтверждает объем данных и допустимую потерю последних изменений. IT проверяет, как получить рабочий момент восстановления и сколько времени потребуется для восстановления сервиса. Правило размещения не автоматически устанавливает RPO и RTO.
Поймите, что означает каждое число
Все три копии должны оставаться работоспособными
Рабочая копия поддерживает текущую работу. Копии резервного копирования должны обеспечивать возможность возврата к требуемому состоянию в случае потери или повреждения данных. Два папки на одном диске не обеспечивают независитую защиту от отказа этого диска. Несколько имен задач также не доказывают, что существует несколько работоспособных копий.
Проверьте, какие именно действия требуются для восстановления каждой копии. Частичное резервное копирование может зависеть от исходного полного резервного копирования и промежуточных данных. Если отсутствует необходимая часть, то количество файлов не даст ожидаемого результата. Запишите эти зависимости в схеме, даже если программное обеспечение скрывает их в своем интерфейсе.
Использование двух типов хранения снижает общий риск
Классическое правило требует использования разных типов носителей. Современные среды также требуют оценки независимости системы хранения. Отказ, административная ошибка или потеря доступа не должны уничтожать всю систему. Два диска в одном массиве, две папки в одном сервисе или копии под одним незащищенным администратором могут представлять значительный риск.
Выбирайте тип хранения на основе объема, скорости извлечения, управляемости и условий доступа. Локальные носители, отдельное хранилище и облачные копии имеют разные ограничения. Кассеты, облако и внешний диск не являются правильным выбором просто потому, что их так называют. Учитывайте совместимость восстановления, обслуживание оборудования и доступ к необходимым ключам.
Храните одну копию за пределами основного объекта
Копия, хранящаяся вне основного объекта, обеспечивает защиту от потери основного объекта, например, в случае повреждения здания или сбоя инфраструктуры. Соседний шкаф не является другим объектом в этом сценарии. Запишите фактическое местоположение данных и условия доступа к ним.
«Вне объекта» и «офлайн» означают разные вещи. Удаленное хранилище может оставаться постоянно доступным через производственный аккаунт. Отключенные носители могут находиться в одной комнате. Проверьте географическое расположение отдельно от защиты от изменений через общие сети или разрешения.
Не считайте синхронизацию резервным копированием
Различные механизмы решают различные причины потери данных.
|
Механизм |
Что он может обеспечить |
Что следует проверить отдельно |
|---|---|---|
|
Резервное копирование |
Точки, из которых можно восстановить предыдущее состояние |
Охват, версии, независимость и успешное восстановление |
|
Синхронизация |
Поддержание актуальности файлов в разных местах |
Происходит ли удаление или повреждение и распространяется ли оно на все связанные места |
|
Репликация |
Копирование изменений и создание резервной копии |
Как сохраняется необходимая история и что происходит с ошибочными изменениями |
|
Снимок |
Состояние поддерживаемого ресурса на определенный момент |
Зависит ли снимок от одного и того же хранилища, доступа или исходных данных |
|
Резервирование диска |
Защита от определенных аппаратных сбоев |
Защита от удаления, единичного инцидента, повреждений и недоступности системы |
Название облачного хранилища не доказывает, что у вас есть резервная копия. Если удаление или шифрование распространяются на связанную копию, вам необходимо иметь отдельный способ получения предыдущей рабочей версии. Проверьте фактическую конфигурацию и доступный период истории, а не только значок облака.
Составьте карту копий для своих систем
Скопируйте форму отзыва и укажите местоположение, зависимости и методы восстановления для вашей среды. Если существуют отдельные классы данных, создайте диаграмму для каждого важного класса. Используйте конкретные названия систем хранения, а не общие категории, чтобы команда могла проверить каждую строку.
Диаграмма трех копий с полями проверки
|
Копия |
Данные, носители и местоположение |
Зависимости |
Кто отвечает за доступ |
Доказательства удобства использования |
|---|---|---|---|---|
|
Рабочие данные |
[Система, тип хранилища и местоположение] |
[Аутентификация, сеть, приложение] |
[Владелец сервиса] |
[Инвентаризация данных и операции работы] |
|
Резервное копирование для стандартного восстановления |
[Данные, отдельное носитель или тип хранилища, местоположение] |
[Необходимая цепочка, программное обеспечение, ключи] |
[Утвержденные роли] |
[Точка восстановления и результат тестирования] |
|
Резервное копирование вне офиса |
[Тип данных, носителя или хранилища, внешний сайт] |
[Подключение, альтернативный доступ, извлечение данных] |
[Роли и ограничения на удаление] |
[Восстановление без основного сайта] |
После заполнения формы задайте сложный вопрос: что произойдет со всеми записями, если основной аккаунт будет скомпрометирован? Затем проверьте потерю сайта, недоступность сети и случайное удаление. Если каждый сценарий оставляет только надежду на один и тот же сервис и администратора, пересмотрите вопрос независимости.
Также проверьте облако, доступ и изоляцию
Устойчивость облака не заменяет историю восстановления
Распределенная инфраструктура провайдера может помочь справиться с аппаратными сбоями. Однако, доступность платформы не означает сохранение требуемого состояния ваших данных после команды удаления или ошибки приложения. Замените дискуссии о том, устарела ли «правило трех двух одного» в облаке, проверкой конкретных причин потери.
Разные регионы, аккаунты или провайдеры могут предлагать разные уровни изоляции. Ни один из них не гарантирует независимость сам по себе. Проверьте общие разрешения, условия хранения, доступ к ключам, совместимость с целевой средой и возможность восстановления, когда исходный аккаунт недоступен. Не меняйте провайдера только для того, чтобы добавить еще одну строку в таблицу, если фактическая проверка остается невозможной.
Защитите копии и возможность их использования
Ограничьте права на изменение или удаление резервных копий, разделите необходимые административные роли и обеспечьте защищенный доступ к восстановлению. Применяйте установленные меры аутентификации и шифрования. Проверьте, где хранятся ключи, и как авторизованные сотрудники смогут их получить, если нормальная рабочая среда недоступна.
Для физических носителей, учитывайте вопросы хранения, транспортировки, отслеживания и доступа к совместительному оборудованию. Для внешнего сервиса необходимы четкие условия извлечения данных, ограничения на экспорт и зависимости от подключения. Защита должна охватывать не только время, в течение которого копия находится в хранении: включать передачу, восстановление и последующую обработку.
Понимание расширений правила
Расширенные схемы добавляют изолированную или неизменяемую копию и разделяют проверки восстановления. Вариант «три два один ноль» обычно подчеркивает эту дополнительную защиту и подтверждает, что никаких ошибок не обнаружено. Это полезное напоминание, а не доказательство того, что будущие сбои никогда не произойдут. Названия и реализации могут различаться у разных поставщиков.
Неизменяемость ограничивает изменения или удаление в определенных условиях. Копия, находящаяся в автономном режиме, снижает доступность сети. Эти свойства различны и не заменяют надлежащее хранение. Выберите подробные политики блокировки и периоды хранения отдельно. Схема копии должна просто записывать, где применяется защита и кто ее проверил.
Протестируйте восстановление и поддерживайте схему
Проверьте результат работы, а не только статус задачи
Успешное резервное копирование подтверждает завершение в рамках задачи. Чтобы протестировать это, восстановите необходимые данные и выполните согласованное действие. Подтвердите версии, разрешения, целостность и доступность зависимостей. Отдельно протестируйте сценарий, когда основной сайт или обычный администратор недоступны.
CISA рекомендует поддерживать зашифрованные резервные копии критических данных в автономном режиме и регулярно проверять их доступность и целостность при восстановлении. Это дополняет планирование размещения; это не превращает план в гарантию против всех атак.
Объем данных, пропускная способность, скорость извлечения данных и подготовка среды влияют на продолжительность. Стоимость может включать хранение истории, восстановление резервных копий, сетевые подключения и работу команды. Проверьте эти условия заранее. Универсальная скорость передачи или обещание начать любую систему в течение нескольких минут не подходят.
Назначьте ответственного за изменения и исключения.
- Подтвердите объем защищенных данных и их взаимосвязи.
- Проверьте количество действительно используемых копий и причины их сбоев.
- Уточните условия размещения в другом месте и отдельные ограничения доступа.
- Основывайте график на приемлемой потере данных, а не на заранее определенном графике другого лица.
- Сохраняйте результаты восстановления и обнаруженные ошибки.
- Назначьте ответственного за устранение неполадок, установите сроки и проведите повторное тестирование.
- Проверьте схему после увеличения объема данных или изменений в сервисе, на сайте или разрешениях.
Определите правила хранения версий и графики тестирования, соответствующие вашим потребностям и ограничениям. Ежедневное резервное копирование или квартальное тестирование не могут считаться достаточными для любой нагрузки. Также необходимо контролировать большее количество копий: незащищенная копия со старым ключом или неизвестной датой удаления не улучшает план просто своим существованием.
Нужно проверить изоляцию резервных копий и возможность восстановления? Обратитесь в DKs Enterprises по вопросам резервного копирования и аварийного восстановления. Подготовьте схему размещения, список систем и результаты последних тестов, чтобы обсудить необходимые работы.
