Как защитить критичные данные в условиях геополитической нестабильности

Почему внешнее облако не должно быть единственной точкой хранения

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

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

Какие данные считать критичными

Критичными считаются данные, потеря или длительная недоступность которых останавливает бизнес-процессы, нарушает обязательства перед клиентами, создает юридические риски или приводит к прямым финансовым потерям. Это могут быть базы 1С, CRM, ERP, документы, договоры, бухгалтерские архивы, клиентские данные, проектная документация, виртуальные машины, почта, конфигурации сервисов, резервные копии и ключевые рабочие файлы.

Для таких данных нужно определить класс важности, владельца, допустимое время простоя, допустимую потерю изменений, требования к шифрованию, срок хранения, правила доступа и место размещения резервных копий. Без этой классификации невозможно корректно выбрать NAS, СХД, backup-софты, сетевую схему и план восстановления.

Как построить стратегию хранения: локально, гибридно, геораспределенно

Практичная стратегия часто строится не на одном решении, а на сочетании нескольких уровней. Локальное хранилище или СХД обеспечивают контроль, скорость и независимость от внешнего провайдера. Облако может использоваться как дополнительная площадка для репликации, архивов или аварийной копии. Геораспределение снижает риск потери данных при инциденте на одной площадке.

Для малого бизнеса это может быть NAS или серверное хранилище с резервным копированием на внешний носитель и в отдельную площадку. Для компании с критичными сервисами — СХД, выделенный backup-репозиторий, репликация, защищенные snapshots, отдельная storage-сеть, мониторинг и регламент восстановления.

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

Backup, RPO и RTO: что нужно рассчитать заранее

Для критичных данных важно заранее определить два показателя. RPO отвечает на вопрос, сколько данных допустимо потерять во времени: час, день, неделю или вообще почти ничего. RTO показывает, за какое время сервис должен быть восстановлен после сбоя. Эти параметры напрямую влияют на частоту backup, тип хранилища, скорость сети, объем резервных копий и стоимость решения.

Backup должен быть регулярным, версионированным, защищенным от удаления, изолированным от основной учетной записи и периодически проверяемым на восстановление. Для важных данных стоит использовать правило 3-2-1: иметь несколько копий, использовать разные носители или площадки и хранить одну копию отдельно от основной инфраструктуры.

Также нужно учитывать скорость восстановления. Быстро сделать копию мало: при аварии важно быстро поднять базу, виртуальную машину, файловую шару или сервис. Поэтому тестовые восстановления должны быть частью регламента, а не разовой проверкой «когда-нибудь потом».

Безопасность хранения: доступы, шифрование и защита от удаления

Защита критичных данных начинается с прав доступа. Пользователь, который работает с файлами, не должен автоматически иметь возможность удалить все резервные копии. Администраторские доступы нужно разделять, включать MFA там, где это возможно, вести аудит действий, ограничивать сетевые порты и изолировать backup-инфраструктуру от обычных рабочих станций.

Для данных, которые хранятся вне основной площадки или передаются во внешние сервисы, важно использовать шифрование. Для backup-копий — защищать репозиторий от перезаписи и удаления. Для СХД и NAS — настраивать snapshots, квоты, права, уведомления, мониторинг свободного места, SMART, состояние RAID, температуру, ошибки дисков и сетевую доступность.

Отдельное внимание нужно уделить шифровальщикам. Если вредоносное ПО получает доступ к сетевой папке и backup-репозиторию, оно может повредить не только рабочие данные, но и копии. Поэтому нужны версии, immutable-подход, отдельные учетные записи и изолированные копии.

Типичные ошибки при защите критичных данных

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

Третья ошибка — не проверять восстановление. Отчет «backup completed» не означает, что база, VM или файловая структура действительно восстановятся в нужный срок. Четвертая ошибка — не считать рост данных и через год столкнуться с нехваткой места, снижением скорости backup и невозможностью хранить нужное число версий.

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

Какие данные подготовить перед подбором NAS, СХД или backup-решения

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

Также полезны технические метрики: текущая емкость, IOPS, задержки, профиль чтения и записи, объем ежедневных изменений, сетевой трафик, длительность backup-окон, размер баз, число виртуальных машин, требования к СХД, NAS-протоколам, гипервизору, ОС и прикладному ПО.