Эх, раз, ещё раз о бэкапах
Начало 2023 года — подходящее время писать на Хабре о том, как важно делать бэкапы. Как оказывается, оно всегда подходящее, потому что большинство не усвоило простые уроки информационной безопасности. На самом деле, эта статья — крик души разработчика корпоративных систем. Можно смело перефразировать слова Салтыкова-Щедрина: «Если я усну и проснусь через сто лет и меня спросят, что сейчас происходит в России, я отвечу: не делают бэкапы». И не только в России — это удивительно упорная, странная проблема международного масштаба, настоящий символ пофигизма, раздолбайства и пренебрежения к труду, прежде всего к собственному. Так почему? Может, так и надо? :-)
В чёрной-чёрной комнате… Начну со страшилки.
Представьте, что весь ваш коллектив из 30 сотрудников работает в течение нескольких лет в единой информационной системе, в которой за это время накоплены огромные данные: сведения о клиентах, переговорах, контактные данные, счета и отгрузки, планы, задачи, расчеты и проектная документация. Всё, что создавали ваши сотрудники за эти годы. А теперь представьте, что вы словили обычный вирус. Вирус побил базу. Вы вызываете вашего сисадмина и просите его восстановить базу из бэкапа. А тот нежно закатывает глазки и, сосредоточенно ковыряя пальцем в зубах, заявляет, что бэкапа то у нас и нет… и что теперь делать? Как восстановить утраченные данные? Как преодолеть панику в коллективе? Сколько месяцев и нервов уйдет на реабилитацию бизнеса и не приведёт ли это к серьёзным последствиям? Просто из-за того, что не делались бэкапы.
Хорошо, это теория. Но вот практический пример из жизни.
Компания занимается деревообработкой: готовые доски, балки, окна и прочая древесина. Имеет небольшую точку продаж на розничном рынке, но большая часть отгрузок — на крупные стройки. Клиентская база — застройщики, которых было чрезвычайно сложно и дорого привлечь на высококонкурентном и не самом «чистом» рынке. База хранится в облачной CRM-системе, с двухфакторной аутентификацией, логированием и проч. Два обиженных по каким-то причинам менеджера с максимальными правами просто забирают базу, уничтожают записи и уходят к конкурентам. Подло, страшно, слабо доказуемо, но главное, что повреждена почти что в ноль дорогостоящая база. Бэкап! Бэкап? Бэкап… Найден, родимый: записи двухлетней давности. Компания распродаёт складские запасы частникам и… нет, не закрывается — у неё есть деньги на перекупку старых клиентов и привлечение новых. Но это опустошает запасы почти до нуля и тянет за собой сложности выживания в кризис, отсутствие роста зарплат и т. д. — то есть новые и новые риски.
Конечно, проблемы в описанных историях системные: ненадёжные системы безопасности, минимальное внимание к сотрудникам, сложности в управлении рисками, никчёмная IT-инфраструктура, которая не организована в принципе (ни бэкапов, ни управления правами доступа, ни защиты от дурака) и которая привела к самым высоким по стоимости потерям. И вот таких компаний, с менее или более трагичными судьбами, много. А ещё больше — ленивых аутсорсеров и сисадминов, которые думают, что в компании на 10–50 сотрудников никаких неприятностей не произойдёт: ведь все на виду, все на доверии.
Теперь будем говорить о главном и, если у вас всё хорошо с безопасностью и резервным копированием, можете сразу переходить к комментариям и рассказать жуткие истории из опыта в назидание тем, кто до сих пор недооценивает правила инфобеза.
Почему компании не делают бэкапы?
Я бы выделил пять основных причин, которые побуждают компании забыть о резервном копировании и держать данные беззащитными и уязвимыми.
Доверие к технике. Некоторые люди безоговорочно доверяют технике: железо, программа, облако никогда не подведут, надёжно сохранят информацию, не сломаются, а если сломаются, то «компьютер всегда можно починить, не бывает безвозвратных поломок» (это самый милый и доверчивый миф). И, как ни странно, эти люди отчасти правы: если грамотно распорядиться железом, софтом и облаком, то можно надёжно застраховать данные, а всё остальное действительно решаемо. Но в их картине мира существует только первая часть, про неизбежную надёжность. Увы, это ловушка: единственное место хранения информации обязательно рано или поздно подведёт.
Недоверие к технике. Обратная ситуация: полное недоверие к любой технике и на его фоне фатальная безалаберность по отношению к данным вместо стремления снизить риски. Зачем что-то копировать, хранить, обновлять, если глупая машина всё потеряет! Лучше писать в блокнотах или делать распечатки — ну юристы же держат печатные материалы, чем мы-то хуже. Подход ужасный, потому что в конечном итоге приводит к отрицанию автоматизации и отказу от сокращения рутины и наращивания продуктивности. Настоящее мучение для сотрудников.
Жадность. Резервное копирование стоит денег. Иногда это небольшая сумма (например, десктопная CRM на своём сервере + облако для маленьких компаний), иногда значительная (системы резервирования, управления бэкапами, свои и арендованные сервера, дополнительные меры защиты информации, вплоть до воздушного зазора), но без затрат точно не обойтись. Некоторые руководители полагают, что стоимость «обслуживания» данных — идеальная статья для снижения издержек. Пожалуй, это худший способ экономии.
Раздолбайство. Самая распространённая причина потери данных и компрометации систем информационной безопасности. Это самое раздолбайство принимает разнообразные формы: «да что там сотрудникам рассказывать, сами разберутся», «да дай ты всем админские права, чай, свои люди», «ой, мне тут странное письмо пришло, а сейчас BI-система не запускается», «да кому мы нужны», «ты эти страшилки мне не рассказывай, кто сюда сунется, у нас антивирус есть». Важнейшим процессам в компании просто не уделяется внимание — увы, иногда даже инциденты ничему не учат. Как ни странно, раздолбайство поражает и недалёких, и очень умных, и продвинутых, и самоуверенных, но самая отвратительная его черта — высокая стоимость ошибки и её устранения. Вот серьёзные затраты, бьющие по бюджету компании, отрезвляют. В особо тяжёлых случаях — ненадолго.
Уверенность в безопасности — опасная ловушка. Вроде всё настроено, права разграничены, политики прописаны, сети защищены, но не тут-то было — неожиданно происходит утечка, инцидент, кража и т. д. Начинаются поиски причин инцидента, проводится всесторонний анализ и выясняется, что в системе безопасности всё есть, но не интегрировано, не работает как единая защита, что-то не обновлялось, что-то утрачено, что-то отключили шустрые пользователи и проч. Конечно, лучший выход в такой ситуации — обратиться к профессионалам и попросить настроить и протестировать систему безопасности. Но это опять же очень дорого. Если нет такой возможности, нужно самостоятельно спроектировать простой и надёжный контур безопасности, который должен постоянно мониториться и обновляться. В принципе, это по силам даже среднему системному администратору, и особенно актуально для маленьких компаний (большие работают со специализированными системами и компаниями, правда, тоже не всегда).
А иногда компании не делают бэкапы, потому что о них просто не знают, экономят на сисадмине и аутсорсе, забывают об этой задаче, живут «на авось» до первой глобальной проблемы. Причин много, следствий не меньше: паника, затраты, простои, потеря репутации и даже бизнеса.
А что может угрожать?
В наше время любой компании может угрожать любой инцидент: можно попасть как под целевую атаку, так и в случайную цепочку неприятностей, не будучи объектом атаки. Есть несколько направлений угроз, которым наиболее подвержен малый (и чуть меньше — средний) бизнес.
Фишинг и социальная инженерия — кратчайший путь к данным через компьютеры и смартфоны сотрудников. Если не отслеживать все «новинки» мошеннических схем и не доносить эту информацию до сотрудников максимально оперативно, такие случаи произойдут практически с гарантией. Если в компании нет драконовских ограничений доступа в интернет, сотрудники непременно будут сидеть в интернет-магазинах, заказывать роллы и пиццу, переписываться в чатах и т. д., а значит, они могут стать жертвой очередной новой схемы. Последствия разные: от проблем с банковскими картами сотрудников до полного доступа к рабочей почте и даже к корпоративным сетям. Дальнейший исход зависит от потребностей мошенников и их ума: может, обойдётся блокировкой карты и разблокировкой рабочего ПК, а может, закончится утечкой базы, иногда чисто из спортивного интереса.
Опасность со стороны сотрудников: в компании всегда может найтись менеджер или специалист, готовый уйти к конкурентам на заманчивую заработную плату вместе с клиентской базой или её частью. Самое удивительное, что компании, имея в руках массу правовых инструментов, боятся сообщить об инциденте, провести расследование и наказать нарушителя, несут убытки и пытаются разобраться самостоятельно.
Ошибка или проблема третьей стороны — серьёзная угроза современных IT-инфраструктур. Например, вы выбрали облачный софт, компания поставляет аддоны третьей стороны или размещает базы клиентов у какого-то хостинг-провайдера. В случае возникновения проблем у разработчика аддонов или хостера может пострадать ваша компания, поскольку клиентская база и вся критическая информация «где-то там». То есть фактически вы разделяете риски мошенничества, форс-мажора, отказа в обслуживании и проч. даже не по доброй воле, а скорее по необходимости.
Фактор вендора. Есть два основных варианта приобретения корпоративного ПО: on-premise, когда купленные лицензии переходят в полное распоряжение клиента, и SaaS (сервис как услуга, аренда) — случай, в котором клиент арендует ПО и платит за него абонентскую плату (как за сотовую связь), при этом ПО остаётся полной собственностью разработчика (поставщика). Соответственно, если вендор решит изменить ПО, перепрофилировать его, закрыть бизнес, отказать в обслуживании (2022 подарил нам десятки примеров) и т. д., клиент фактически теряет базу. Конечно, как правило (!) вендор предупреждает клиентов о грядущих изменениях и позволяет забрать базу и бэкапы (если они хранились тоже у него), но последние несколько лет в IT бывала и чертовщина: так, отдельные вендоры предлагали скачать базу за деньги, бэкапы — за деньги побольше, а некоторые просто отказали в обслуживании и передаче баз. А были бы бэкапы по всем правилам, можно было не метаться, не платить деньги, не сходить с ума, а купить новую CRM/ERP/PM, мигрировать базу и показать бывшему поставщику
