Как защитить данные в «облаке» от потери — руководство на примере ошибки GitLab Статьи редакции

В январе системный администратор сервиса для хранения кода GitLab случайно удалил 300 ГБ данных из базы компании, после чего сервис оказался временно недоступен для пользователей. Глава сервиса для защиты информации в «облаке» Spinbackup Дмитрий Донцов написал колонку, в которой объяснил, из-за чего могла произойти подобная ситуация и как её можно предотвратить. 

Безусловно, данные были утеряны из-за человеческого фактора — банальной усталости или рассеянности персонала, а может и инсайдерской акции. Но винить одного администратора не стоит. В компаниях уровня GitLab должны быть хорошо налажены ежедневные автоматические процессы по защите информации от потери, и влияние человеческого фактора должно сводиться к минимуму. Потеря продуктивности и сбой таких процессов в 39% случаев несут ущерб работе систем кибербезопасности, так что вопрос действительно важный.

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

В данном случае вина лежит на менеджменте, который не позаботился о правильной настройке процессов защиты информации. Это проблема не только GitLab — многие компании пренебрегают вопросами безопасности. По иронии, даже в проектах, которые специализируются на защите данных, случаются критичные ошибки, которые приводят к потерям или утечке информации. Например, в начале февраля утечка произошла у Denuvo. По данным СМИ, конфиденциальная информация компании, защищающей видеоигры от пиратов, появилась в открытом доступе, что может практически похоронить проект. Скорее всего, в этом случае тоже виновато руководство: не обеспечило защиту собственной информации, в том числе от ошибок персонала.

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

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

В случае GitLab главной задачей было максимально быстро и точно восстановить потерянные данные. Раз уж компания заявляет, что ее сервис доступен в режиме 24/7, нужно при любых обстоятельствах обеспечивать круглосуточный доступ. Исходя из этого, выстраиваются необходимые процедуры, в том числе — и резервное хранение данных. Другими словами, компания должна быть готова восстановить удаленные данные в любой момент, и человеческий фактор не является достаточным оправданием потерь. 

Чтобы гарантировать быстрое восстановление удаленных данных, нужно обеспечить необходимое резервирование компонентов инфраструктуры. Для этого достаточно заглянуть в любой набор рекомендаций и лучших практик, например, в ITIL. Кроме того, нужно подготовиться к восстановлению бизнеса после сбоев. В этом поможет Business continuity planning (BCP) — отдельное направление рекомендаций по бизнес-процессам. В BCP можно найти и план восстановления для ИТ-инфраструктуры (Disaster Recovery Plan).

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

Вот примерный план, который поможет наладить эти процессы: 

1. ​Открыть библиотеку — например, ITIL — где подробно описано, как управлять инфраструктурой любой сложности и масштаба. 
2. Сформировать собственный набор процедур резервирования данных и инфраструктуры на основе ITIL. Описать, как с помощью этих процедур можно восстановить ИТ-нфраструктуру. Это будет план восстановления.
   
3. Внедрить набор процедур резервирования и протестировать план восстановления.
   
4. Главное — соблюдать эти правила на регулярной основе и анализировать их выполнение по KPI (специальным метрикам). Это поможет скорректировать дальнейшее выполнение процедур.

Согласно правилам ITIL, важно контролировать процесс управления изменениями. Необходимо сделать так, чтобы администратор не мог удалить данные по ошибке. Для этого применяется «правило двух рук»: на административном уровне устанавливается такой уровень доступа, при котором удалить информацию или внести изменения в критическую систему один сотрудник не может. Администратор только инициирует действие, а далее требуется подтверждение от другого администратора или руководителя. Это же правило стоит применять и для того, чтобы избежать утечек: конфиденциальные данные должны быть защищены от копирования. Кроме того, нужно установить ограничение полномочий: чтобы администратор или рядовой пользователь не мог открыть информацию для публичного доступа, пока не получит подтверждение.

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

В 2016 году, по данным компании в сфере безопасности Infowatch, 18,1% всех утечек в мире пришлись на государственные учреждения, а виновниками стали служащие, которые нарушили правила безопасности, использовали публичные облачные хранилища, переписывались через бесплатные почтовые сервисы. Это доказывает, что чем крупнее структура, тем сложнее контролировать каждого ее сотрудника. Так что защита данных от ошибок и непродуманных действий персонала становится одним из важнейших вопросов кибербезопасности.

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

Согласно статистике Infowatch, в утечке информации чаще всего задействованы офисные сотрудники (54%), затем следуют хакеры (25,8%), неопределенные лица (12,5%), подрядчики (4,2%), менеджеры (1,5%) и сисадмины (1,2%).

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

Каналы, через которые обычно «утекают» данные — похищенные или потерянные устройства, мобильные устройства, съемные накопители, интернет, email-переписка, бумажная документация и личностные коммуникации в офлайне.

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

Традиционно первенство в распространенности утечек в регионе занимают США, далее идут Россия, Великобритания, Канада, Австралия и Германия. Украина, Корея, Новая Зеландия и Япония тоже в зоне риска.

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

• Определить критерии работы сервисов компании и то, как они должны быть восстановлены.
• Описать и согласовать с руководителями ИТ-направлений и бизнес-подразделений план реагирования в кризисных ситуациях, в частности – план восстановления.
  
• Периодически проверять все процедуры плана восстановления. Если во время тестирования определенные процедуры не работают, необходимо внести в них изменения, чтобы обеспечить выполнение всего плана.
  
• Ежемесячно проверять резервные копии данных на доступность и целостность, даже если эти копии хранятся в облаке. 

От потерь и утечек данных не застрахован никто. В 2013 и 2014 году две большие утечки пережил интернет-гигант Yahoo, допустив в общей сложности кражу данных почти 1,5 млрд пользователей. В 2014 году конфиденциальная информация о более чем 5 млн сербских граждан была опубликована на сайте Агентства по приватизации. В 2016 году случился Panama Papers — скандал с утечкой документов юридической компанией Mossack Fonseca.

В 2015 году произошел более чем интересный инцидент с Google. В августе во время грозы молния четырежды ударила в местную электросеть недалеко от одного из центров обработки данных Google в Бельгии. Согласно отчету Google, тогда было потеряно менее 0.000001% постоянного места на диске.

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

Малый бизнес и стартапы не могут позволить себе ограниченный доступ к данным. Так что Azendo повезло, что инцидент был коротким, а команда заранее позаботилась о резервных копиях данных.

Этот инцидент потери данных показал, что даже такой технический гигант, как Google, не может повлиять на стихийные бедствия. Так что регулярные операции резервного копирования и запасные «хранилища» очень важны для поддержания работоспособности бизнеса. Важно не переоценивать себя и всегда иметь план реагирования на случай неприятностей.

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

#Колонка #безопасность #защита_данных #GitLab