Ежегодно происходят десятки крупных утечек или технических сбоев, приводящих к потере данных. От них страдают производственные предприятия, государственные организации, мессенджеры, рестораны и разработчики программного обеспечения. В начале мая с этой проблемой столкнулась команда ChatGPT, когда из-за бага в open source библиотеке чат-бот стал раскрывать персональные данные пользователей.

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

Сегодня обсудим разные инциденты, связанные с потерей данных: от масштабных и разрушительных до нелепых.

Странные и не очень инциденты

Еще в 2017 году крупная датская компания, специализирующаяся на грузоперевозках по морю, стала жертвой червя NotPetya. Вредонос заблокировал доступ к логистическим данным и системам для управления терминалами. За две недели компания потратила 300 млн долларов на восстановление системы, при этом сотрудникам пришлось «лепить» рабочие инструменты «из того, что было»: погрузкой и движением судов руководили через мессенджеры и соцсети.

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

Что касается ошибок сотрудников, то они принимают разные, иногда весьма причудливые формы. Интернет-издание The Register ведет тематическую рубрику Who, Me?, в рамках которой читатели делятся историями из жизни системных администраторов и разработчиков. Не так давно там публиковали историю о том, как в 90-х сотрудники одной страховой компании обновляли компьютерный парк. Машины отключали в установленной последовательности, чтобы исключить простой. И тут один инженер случайно нажал на кнопку выключения продакшн-сервера, но — к счастью — не отпустил её. В итоге ему пришлось 15 минут простоять «прикованным» к системному блоку, пока другие сотрудники в срочном порядке сохраняли рабочие документы и копировали важные данные.

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

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

Темные паттерны

Многие утечки и сбои происходят не просто по ошибке, а из-за серьезных просчетов и несоблюдения корпоративных регламентов. По некоторым оценкам небрежность становится причиной 90% проблем с данными. В начале 2021 года полиция Далласа потеряла 9 млн записей, фото- и видеофайлов с уликами. Новый сотрудник IT-службы проигнорировал стандартную процедуру и не убедился в наличии копий перед удалением документов. Он решил, что их успели перенести в облако. Всего департамент лишился 23 терабайтов данных, восстановить удалось не более трех.

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

Бэкап-чекап: еще раз коротко о сохранении данных

Мониторим патчи и обновления антивируса

Очевидно, для защиты данных необходимо следить за актуальностью антивирусных систем и исполнением политик безопасности, патчить уязвимости как можно быстрее. К сожалению, у некоторых компаний уходят месяцы на установку критических обновлений. Согласно недавнему исследованию Ponemon Institute, почти 60% организаций не занимаются этим на регулярной основе. С решением таких задач может помочь облачный провайдер. Он берет на себя своевременное обновление программного обеспечения и реализует политики патч-менеджмента. Автоматизированная система мониторит инфраструктурный ландшафт, реагирует на 0-day уязвимости и устанавливает «заплатки» по мере их появления.

Не теряем резервные копии

Если вы работаете с облачным провайдером, обратите внимание на услуги резервного копирования и аварийного восстановления. Такие системы становятся надежным инструментом борьбы с разного рода шифровальщиками. В 2020 году данные Калифорнийского университета оказались зашифрованы зловредом. Хакеры запросили более одного миллиона долларов за расшифровку. Представители вуза решили откупиться, и данные им вернули. Можно сказать, что им повезло — в 92% случаев компании не получают свои файлы назад.

Проверяем качество и целостность бэкапов

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

Действуем по регламенту

Кроме целостности бэкапов, стоит отработать политики аварийного восстановления — иногда такие очевидные вещи упускают из вида даже крупные организации. По оценкам Gartner, 95% утечек происходит из-за неправильно настроенной инфраструктуры. В начале года сотрудник биржи NYSE нарушил процедуру отключения системы disaster recovery. Ошибка повлияла на цены сотен акций и вызвала хаос на рынке. Точная стоимость ущерба неизвестна до сих пор.

Как компания должна работать с резервными копиями, чтобы не потерять данные

1. Разработайте стратегию.

• Начните с анализа критически важных данных и систем. Определите типы данных, их расположение и уровень значимости.
• Оцените требования и приоритеты. Учитывайте такие факторы, как размер данных, частота изменений, целевое время восстановления (RTO), целевое количество точек восстановления (RPO) для различных наборов данных. Этот анализ помогает определить подходящую частоту резервного копирования и сроки хранения для каждой категории данных.
• RPO означает точку, в которой создаются резервные копии ваших данных, веб-сайта или приложений. Как правило, речь может идти о ночных резервных копиях, о резервном копировании каждые два часа (либо в другой период( или о репликации. RPO отвечает на вопрос: сколько данных вы можете позволить себе потерять? Насколько разрушительным было бы потерять последние 10 минут, 30 минут, час или день?
• RTO – это период, в течение которого ваши бизнес-процессы простаивают. Для оценки RTO необходимо понять, насколько компания может позволить себе, например, отключение файлового сервера. Важно проанализировать RTO для каждого приложения, веб-сайта и файла.
• Определите методы резервного копирования: полное, добавочное (только данных, изменившихся с момента последнего резервирования) и дифференциальное (копирование данных, которые изменились с момента последнего полного бэкапа).
• Задокументируйте стратегию.

2. Реализуйте избыточность.

Поддерживайте резервные копии в нескольких местах. Следуйте правилу 3-2-1. Это означает хранение не менее трех копий данных, их хранение на двух разных типах носителей (например, в облаке и на внешних жестких дисках) и хранение одной копии вне офиса (например, в защищенном ЦОДе или в облачном хранилище).

3. Автоматизируйте процессы резервного копирования, чтобы свести к минимуму риски, связанные с человеческим фактором.

Можно воспользоваться оpen source решениями: Duplicati (есть поддержка объектного хранилища), кроссплатформенный Bacula/Bareos, rsnaphot или Wyng.

4. Шифруйте данные.

Убедитесь, что ключи шифрования и пароли надежно хранятся отдельно от данных резервного копирования.

5. Регулярно контролируйте процессы резервного копирования на наличие ошибок или сбоев.

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

В качестве резервной площадки можно использовать облако #CloudMTS.