Начало 2023 года — подходящее время писать на Хабре о том, как важно делать бэкапы. Как оказывается, оно всегда подходящее, потому что большинство не усвоило простые уроки информационной безопасности. На самом деле, эта статья — крик души разработчика корпоративных систем. Можно смело перефразировать слова Салтыкова-Щедрина: «Если я усну и проснусь через сто лет и меня спросят, что сейчас происходит в России, я отвечу: не делают бэкапы». И не только в России — это удивительно упорная, странная проблема международного масштаба, настоящий символ пофигизма, раздолбайства и пренебрежения к труду, прежде всего к собственному. Так почему? Может, так и надо? :-)

В чёрной-чёрной комнате… Начну со страшилки.

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

Хорошо, это теория. Но вот практический пример из жизни.

Компания занимается деревообработкой: готовые доски, балки, окна и прочая древесина. Имеет небольшую точку продаж на розничном рынке, но большая часть отгрузок — на крупные стройки. Клиентская база — застройщики, которых было чрезвычайно сложно и дорого привлечь на высококонкурентном и не самом «чистом» рынке. База хранится в облачной CRM-системе, с двухфакторной аутентификацией, логированием и проч. Два обиженных по каким-то причинам менеджера с максимальными правами просто забирают базу, уничтожают записи и уходят к конкурентам. Подло, страшно, слабо доказуемо, но главное, что повреждена почти что в ноль дорогостоящая база. Бэкап! Бэкап? Бэкап… Найден, родимый: записи двухлетней давности. Компания распродаёт складские запасы частникам и… нет, не закрывается — у неё есть деньги на перекупку старых клиентов и привлечение новых. Но это опустошает запасы почти до нуля и тянет за собой сложности выживания в кризис, отсутствие роста зарплат и т. д. — то есть новые и новые риски. 

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

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

Почему компании не делают бэкапы?

Я бы выделил пять основных причин, которые побуждают компании забыть о резервном копировании и держать данные беззащитными и уязвимыми.

• Доверие к технике. Некоторые люди безоговорочно доверяют технике: железо, программа, облако никогда не подведут, надёжно сохранят информацию, не сломаются, а если сломаются, то «компьютер всегда можно починить, не бывает безвозвратных поломок» (это самый милый и доверчивый миф). И, как ни странно, эти люди отчасти правы: если грамотно распорядиться железом, софтом и облаком, то можно надёжно застраховать данные, а всё остальное действительно решаемо. Но в их картине мира существует только первая часть, про неизбежную надёжность. Увы, это ловушка: единственное место хранения информации обязательно рано или поздно подведёт.

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

• Жадность. Резервное копирование стоит денег. Иногда это небольшая сумма (например, десктопная CRM на своём сервере + облако для маленьких компаний), иногда значительная (системы резервирования, управления бэкапами, свои и арендованные сервера, дополнительные меры защиты информации, вплоть до воздушного зазора), но без затрат точно не обойтись. Некоторые руководители полагают, что стоимость «обслуживания» данных — идеальная статья для снижения издержек. Пожалуй, это худший способ экономии. 

• Раздолбайство. Самая распространённая причина потери данных и компрометации систем информационной безопасности. Это самое раздолбайство принимает разнообразные формы: «да что там сотрудникам рассказывать, сами разберутся», «да дай ты всем админские права, чай, свои люди», «ой, мне тут странное письмо пришло, а сейчас BI-система не запускается», «да кому мы нужны», «ты эти страшилки мне не рассказывай, кто сюда сунется, у нас антивирус есть». Важнейшим процессам в компании просто не уделяется внимание — увы, иногда даже инциденты ничему не учат. Как ни странно, раздолбайство поражает и недалёких, и очень умных, и продвинутых, и самоуверенных, но самая отвратительная его черта — высокая стоимость ошибки и её устранения. Вот серьёзные затраты, бьющие по бюджету компании, отрезвляют. В особо тяжёлых случаях — ненадолго.

• Уверенность в безопасности — опасная ловушка. Вроде всё настроено, права разграничены, политики прописаны, сети защищены, но не тут-то было — неожиданно происходит утечка, инцидент, кража и т. д. Начинаются поиски причин инцидента, проводится всесторонний анализ и выясняется, что в системе безопасности всё есть, но не интегрировано, не работает как единая защита, что-то не обновлялось, что-то утрачено, что-то отключили шустрые пользователи и проч. Конечно, лучший выход в такой ситуации — обратиться к профессионалам и попросить настроить и протестировать систему безопасности. Но это опять же очень дорого. Если нет такой возможности, нужно самостоятельно спроектировать простой и надёжный контур безопасности, который должен постоянно мониториться и обновляться. В принципе, это по силам даже среднему системному администратору, и особенно актуально для маленьких компаний (большие работают со специализированными системами и компаниями, правда, тоже не всегда).

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

А что может угрожать?

В наше время любой компании может угрожать любой инцидент: можно попасть как под целевую атаку, так и в случайную цепочку неприятностей, не будучи объектом атаки. Есть несколько направлений угроз, которым наиболее подвержен малый (и чуть меньше — средний) бизнес.

• Фишинг и социальная инженерия — кратчайший путь к данным через компьютеры и смартфоны сотрудников. Если не отслеживать все «новинки» мошеннических схем и не доносить эту информацию до сотрудников максимально оперативно, такие случаи произойдут практически с гарантией. Если в компании нет драконовских ограничений доступа в интернет, сотрудники непременно будут сидеть в интернет-магазинах, заказывать роллы и пиццу, переписываться в чатах и т. д., а значит, они могут стать жертвой очередной новой схемы. Последствия разные: от проблем с банковскими картами сотрудников до полного доступа к рабочей почте и даже к корпоративным сетям. Дальнейший исход зависит от потребностей мошенников и их ума: может, обойдётся блокировкой карты и разблокировкой рабочего ПК, а может, закончится утечкой базы, иногда чисто из спортивного интереса.

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

• Ошибка или проблема третьей стороны — серьёзная угроза современных IT-инфраструктур. Например, вы выбрали облачный софт, компания поставляет аддоны третьей стороны или размещает базы клиентов у какого-то хостинг-провайдера. В случае возникновения проблем у разработчика аддонов или хостера может пострадать ваша компания, поскольку клиентская база и вся критическая информация «где-то там». То есть фактически вы разделяете риски мошенничества, форс-мажора, отказа в обслуживании и проч. даже не по доброй воле, а скорее по необходимости.

• Фактор вендора. Есть два основных варианта приобретения корпоративного ПО: on-premise, когда купленные лицензии переходят в полное распоряжение клиента, и SaaS (сервис как услуга, аренда) — случай, в котором клиент арендует ПО и платит за него абонентскую плату (как за сотовую связь), при этом ПО остаётся полной собственностью разработчика (поставщика). Соответственно, если вендор решит изменить ПО, перепрофилировать его, закрыть бизнес, отказать в обслуживании (2022 подарил нам десятки примеров) и т. д., клиент фактически теряет базу. Конечно, как правило (!) вендор предупреждает клиентов о грядущих изменениях и позволяет забрать базу и бэкапы (если они хранились тоже у него), но последние несколько лет в IT бывала и чертовщина: так, отдельные вендоры предлагали скачать базу за деньги, бэкапы — за деньги побольше, а некоторые просто отказали в обслуживании и передаче баз. А были бы бэкапы по всем правилам, можно было не метаться, не платить деньги, не сходить с ума, а купить новую CRM/ERP/PM, мигрировать базу и показать бывшему поставщику ????.

Это базовые угрозы, которые могут нанести значительный финансовый и репутационный урон. Более того, любая атака может повлечь серьёзные юридические последствия, и здесь уже извинениями, оправданиями и постмортемом не отделаешься. Если кто-то думает, что это не о нём, то нет — сегодня абсолютно все организации и предприятия подвержены киберугрозам. 

Для самых маленьких: бэкапы — это максимально просто

Известно, что большинство читателей заходят на Хабр из поиска. Я искренне надеюсь, что они прочитают эту статью и обратят внимание руководства и штатного айтишника или IT-службы на проблему — ведь от состояния информационной безопасности в какой-то мере зависит заработная плата каждого из нас (вспомните пример из начала статьи). 

Итак, вот он, необходимый (и не всегда достаточный) минимум для обеспечения безопасности данных.

1. Создать копии всех критических баз данных, касающихся значимых рабочих процессов. Проверить, что копии создались, нормально открываются, нет сбоев в кодировке, форматах, разделителях и проч.

2. Протестировать копию. Есть много способов, самый простой такой: в рабочей базе изменить данные (предварительно записав, что изменили, чтобы в случае чего вернуть вручную), накатить сохранённую копию, проверить, всё ли применилось.

3. Сохранить копии. Помните поговорку про то что нельзя все яйца хранить в одной корзине? Она должна была быть придумана про бэкапы :-) Всё просто: одну и ту же копию храним в разных местах. Всё придумано до нас: есть каноническое правило 3-2-1, то есть для оптимальной защиты нужно сделать три копии, две хранить на разных физических носителях, одна копия должна находиться на географическом удалении (вполне подойдёт облачный сервер). При таком раскладе вероятность что-то потерять резко снижается. В интернете, да и на Хабре, масса инструкций, как лучше реализовать это золотое правило бэкапов.

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

5. Восстановить из копий в случае возникновения такой необходимости.

6. Повторять пункты 1-4 с необходимым интервалом.

Поясню про обновление копий чуть подробнее, чтобы непродвинутые пользователи не запутались. 

Можно сделать полную резервную копию, она даёт самые большие гарантии, но на больших базах отнимает много времени и не подходит для ежедневного обновления. Гораздо быстрее и тоже эффективно работают инкрементные резервные копии, которые сохраняют только данные, которые изменились с момента создания предыдущего бэкапа (но они гораздо медленнее при восстановлении). Ещё более быстрый способ обновления бэкапов — дифференциальное резервное копирование, при котором резервные копии «поверх основной» содержат только изменённые данные. И если при инкрементном резервном копировании обновляются данные, которые обновились с момента предыдущего инкрементного бэкапа, то при дифференциальном — все данные, которые изменились с момента последнего полного резервного копирования. Время восстановления в случае дифференциального резервного копирования меньше, чем в остальных случаях, что может оказаться бесценным для аварийного восстановления сервисов с жёсткими требованиями SLA и высоким аптаймом (те же CRM-системы, системы бронирования, заказов, да, в принципе, всего, от чего люди хотят «всё и сразу»). Если ваши базы небольшие, делайте полную резервную копию, если записей много и процесс резервного копирования занимает время, лучше всего выбрать дифференциальное резервное копирование — при прочих равных это всё-таки лучший вариант.

Я принципиально не советую никакие инструменты для создания резервных копий — их должен выбрать ваш IT-специалист, исходя из своего опыта и параметров IT-инфраструктуры.

Что ещё можно сделать?

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

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

• Не отступайте хотя бы от правила 3-2-1. Это простая и понятная схема, неукоснительное следование которой спасает целые компании и тысячи их сотрудников по всему миру. Не нужно ломать систему, изобретать велосипед, экспериментировать и рисковать — надёжный способ придуман, осталось не сэкономить на облаке и физических носителях (от сервера до флешки).

• Определите ответственных за резервное копирование и восстановление данных, чтобы можно было их задействовать с минимальным простоем. Если пользуетесь услугами аутсорсера, запросите схему резервного копирования и уточните сроки его реагирования на инцидент. Одну физическую копию всё равно держите при себе, имейте все доступы к облаку и связанным с администрированием e-mail. 

• Внимательно относитесь к аренде по модели SaaS и к выбору хостинг-провайдера: читайте договоры, лицензионные соглашения, обговаривайте условия резервного копирования и выгрузки своей базы на этапе выбора поставщика ПО. Логично, что у вас не должно быть никаких ограничений, чтобы забрать свою накопленную информацию. А вот услуги по резервному копированию могут быть платными или осуществляться с помощью платных утилит — это нормально и чаще всего удобно. Например, в случае Regionsoft CRM за автоматические бэкапы с любой периодичностью отвечает сервер сценариев RegionSoft Application Server.

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

• Не бойтесь никого обидеть правилами безопасности: разделяйте права доступа, применяйте политики безопасности, прописывайте условия BYOD, запрещайте раздавать свой Wi-Fi и проч. В этом нет никаких признаков недоверия: вы прежде всего защищаете самих сотрудников от ненужных разбирательств и подозрений.

• Помните, что ваш офис — не несгораемая водонепроницаемая крепость в титановом корпусе. И сейф тоже. Работая с физическим хранением бэкапов, нужно помнить, что может произойти любое ЧП: от потопа (приходилось видеть системники в воде) и пожара до самых необычных проявлений человеческого фактора (уборщица выдернула и обратно воткнула мешающий убираться шнур). Скорее всего, не произойдёт ничего, но тем не менее лучше перестраховаться.

Эту статью я написал под впечатлением от очередных инцидентов, с которыми к нам обратились. Мы, айтишники, многие вещи считаем обыденной рутиной: правильное хранение паролей, своевременное резервное копирование, защиту рабочей среды, различные способы аутентификации… Пользователи и клиенты могут об этом совершенно не задумываться и игнорировать все существующие правила. Просто потому что в их мироустройстве это что-то избыточное, сложное и даже параноидальное. Однако даже самый небольшой объём потерянных критичных данных может выбить почву из-под ног бизнеса. И здесь всё так же, как и со здоровьем: не допустить гораздо полезнее, приятнее, проще и дешевле, чем лечить и восстанавливать. Короче, делайте бэкапы, блин!

???? Полезный сборник статей о CRM

Алексей Суриков

Главный разработчик RegionSoft