независимая выездная проверка сетевой безопасности

независимая выездная проверка сетевой безопасности

Оффлайн-бэкап как “страховой сейф”: копия, которая выживает, когда сеть умерла

Пятница 17:32: Сервер упал. 1С не работает.
В чате летят сообщения от начальства “Бухгалтерия встала, отгрузки встали. Когда вернемся в работу? У нас же есть резервные копии?”
А бэкапы на сервере.

И вот тут становится видно, что “у нас есть бэкапы” — это не факт, что мы восстановимся, а лишь файл для душевного спокойствия. Потому что если бэкапы доступны тем же путём, теми же правами и из той же сети — в реальном инциденте они умирают вместе с продом. Не “иногда”. А достаточно часто, чтобы эта история была вечной..

Оффлайн-бэкап — это не “ещё один NAS” и не “вторая папка”. Это режим, в котором копия в обычный день не достижима из сети. А значит, когда в сети происходит шифрование, массовое удаление или компрометация учёток — у вас остаётся хотя бы один источник восстановления, который не снесли “по пути”.

ЧТО ТАКОЕ “ОФФЛАЙН-БЭКАП”

Нормальный оффлайн-бэкап — это когда выполняются три условия:

1. Нет постоянного сетевого доступа к копии из прода/домена/рабочих админских учёток;
2. Нельзя одним действием (одной учёткой/одной командой/одной ошибкой) уничтожить всю историю;
3. Есть порядок восстановления, чтобы в день Х копию можно было быстро найти, принести и реально поднять из неё 1С/критичные данные.

Если хотя бы одного условия нет — это не страховой сейф вне сети. Это “копия рядом”.

ПРАКТИКА: КАК СДЕЛАТЬ “СТРАХОВОЙ СЕЙФ” ТАК, ЧТОБЫ ОН РЕАЛЬНО ВЫЖИЛ

Шаг 1. Определи, что именно должно “выжить”
Не “данные вообще”, а минимальный набор, который возвращает бизнес в работу. Если это не определено — вы будете копировать “всё”, потом “слишком долго”, потом “не делаем”.

Минимальный набор (почти всегда):

1С:

• база (MDF/PGDATA/1CD — в зависимости от СУБД/версии);
• логи/журналы (если нужны для консистентности);
• ключевые конфиги;
• лицензии/ключи там, где без них не поднимешь,
• “инструкция запуска” (что поднять первым/в каком порядке — хотя бы на 1 страницу).

Критичные файлы: договоры/бухгалтерия/сканы/общие папки, но не “помойку”.

Точки восстановления инфраструктуры (минимум):

• где лежит конфиг гипервизора/VM,
• где сетевые конфиги,
• где учётки/доступы “на чёрный день”.

Проверка на здравый смысл: сейф должен позволять поднять 1С и ключевые файлы, даже если остальное восстанавливается позже.

Шаг 2. Сделай “невозможность массового удаления” (это важнее красоты)
Оффлайн-сейф ломается обычно так: кто-то с админскими правами (или атакующий, который их получил) уничтожает историю. Поэтому правило простое:

Прод и пользовательская среда не должны иметь права “удалить историю бэкапов”.
Ни “случайно”, ни “по инструкции”, ни “потому что так удобнее”.

Что делать практично:

• отдельный аккаунт/контур записи, который умеет только писать (append), но не чистить;
• раздельные ключи: ключи шифрования сейфа не лежат в той же системе, где крутится прод;
• операции удаления/очистки — только через отдельную процедуру и отдельные права (по сути “двухключевой режим”).
• Если этого нет — у вас не сейф на черный день, а “ещё одна папка”.

Шаг 3. Ротация без фанатизма: A/B + “длинная” версия
Не надо строить музей носителей. Нужно убрать самый частый провал: перезаписали чистое заражённым.

Минимальная рабочая схема:

• A/B носители (каждый раз меняются);
• одна “длинная” версия (например, раз в месяц/раз в 2 недели) хранится дольше и не трогается.

Почему это важно: если инцидент заметили не сразу, “последняя копия” может быть уже мусором. Длинная версия — шанс откатиться на “до того”.

Шаг 4. Где хранить “сейф”, чтобы он был реально вне зоны поражения
Самая популярная ошибка: “оффлайн-бэкап” хранится там же, где всё остальное.

Минимум, который реально меняет картину:

• физически другой объект/шкаф/сейф/место хранения;
• доступ — не “у всех админов по привычке”, а лучше вообще у собственника бизнеса;
• учёт выдачи/возврата носителя.

Критичный момент: оффлайн-бэкап должен пережить не только шифрование, но и сценарии типа “железо увезли” или “серверная недоступна”.

Шаг 5. Учёт, который не раздражает, но спасает
Учёт часто игнорят, потому что “бюрократия”. Но в день Х без него вы просто не знаете, что доставать.

Достаточно одной строки на носитель:

• Носитель: A / B / Long
• Дата записи
• Что внутри (1С + файловый набор + прочее)
• Контроль 1: “проверено чтение: да/нет”
• Контроль 2: “проверена восстанавливаемость: да/нет”
• Кто делал

Это делается хоть в Google Sheet, хоть в блокноте — важно, чтобы оно было живое и актуальное.

Шаг 6. Минимальный тест восстановления (чтобы не жить в теории)
Тест восстановления “по-настоящему” — это не всегда поднятие всего предприятия. Но проверка должна быть достаточно реальной, чтобы поймать типовые провалы.

Минимальный тест раз в квартал:

• развернуть 1С из сейфа на тестовом контуре;
• открыть базу, сделать пару операций;
• зафиксировать время “от сейфа до логина в 1С”.

Что фиксировать в протоколе (5 строк):

1. дата, версия носителя;
2. сколько заняло доставание/подключение;
3. сколько заняло восстановление 1С;
4. что сломалось (если сломалось);
5. что правим до следующего теста.

Это убирает “надежду” и превращает сейф в инструмент.

БЫСТРЫЙ САМОТЕСТ: УМЕНЯ СТРАХОВОЙ СЕЙФ ИЛИ НАВЕСНОЙ ЗАМОК?
Если хотя бы на 2 вопроса ответ “не знаю/наверное” — это значит, что сейф пока стоит с открытой дверью:

1. Можно ли уничтожить историю бэкапов одной админской учёткой?
2. Есть ли версия, до которой нельзя дотянуться из сети (вообще)?
3. Есть ли A/B и “длинная” версия?
4. Кто кроме одного человека знает, где сейф и как его использовать?
5. Когда последний раз поднимали 1С из сейфа на тесте?

КАК ОФФЛАЙН-СЕЙФ ОБЫЧНО “УМИРАЕТ” (ЧТОБЫ НЕ НАСТУПИТЬ)

1. Носитель “оффлайн” постоянно подключён.
2. Нет ротации — перезаписали чистое заражённым.
3. Хранение “там же” — умерло вместе с зоной.
4. Нет учёта — в день “Х” начинается поиск “кто видел диск”.
5. Нет теста — “файл есть, восстановление миф”.
6. Всё держится на одном человеке.

И кстати, если руки не доходят — это нормально, а не “стыдно не знать и не делать”

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

Если нужна помощь — можно пойти двумя путями:

• быстрая консультация/второе мнение по вашей схеме: что у вас уже есть, где “дыра”, что поправить минимальными движениями;
• либо услуга оффлайн-бэкап под ключ: запись на специализированные зашифрованные носители, хранение вне сети, и если случается инцидент — восстановление нашими силами с гарантией восстановления до 48 часов.

Что это даёт? Спокойствие без магии, антидепрессантов и без “авось пронесет”. В критический день у вас есть рабочая копия, понятный порядок действий и предсказуемый срок, когда 1С и ключевые данные снова будут жить.

Лучше 1 раз проверить, чем разгребать последствия

А если руки не доходят и совет нужен уже сейчас, запишись на 1 бесплатную проверку бизнеса на восстановление

Владимир Конечный,
Основатель, SEO, 20 лет в кибер-расследованиях

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

Ещё больше статей простыми словами для собственников бизнеса и ИТ-специалистов

СВЯЗАТЬСЯ С НАМИ

Адрес: г.Новосибирск, Октябрьская магистраль 2, оф 510

НПП "Рекорд" © 2011-2025

ИП Конечный В.С.
ИНН 540698195996
ОГРНИП 315547600055806