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

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

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

Рабочая группа Cloud Security Alliance (CSA), занимающаяся изучением проблем безопасности Больших Данных, недавно подготовила документ, в котором перечислила инструменты для защиты систем Больших Данных, распределив их по четырем группам (см. рисунок): инфраструктурная безопасность; защита данных; управление данными; реактивная безопасность.

Рекомендации Cloud Security Alliance
Рекомендации Cloud Security Alliance

 

Инфраструктурная безопасность

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

Для защиты инфраструктуры эксперты CSA рекомендуют решить следующие задачи: обеспечить безопасность среды программирования и использовать передовой опыт защиты нереляционных баз данных, составляющих основу технологического стека Больших Данных [1]. В частности, для обеспечения целостности среды программирования необходимо принять меры, препятствующие нарушению функционирования каждого отдельного узла распределенной сети, вмешательству в коммуникационную среду и добавлению фальшивых узлов или других посторонних элементов, которые могут оказать существенное влияние на результат вычислений. Если говорить о защите нереляционных баз данных, то создателям систем обработки Больших Данных как минимум придется предусмотреть механизмы обеспечения транзакционной целостности данных и их консистентности, надежной аутентификации и защиты от инъекции посторонних данных.

Защита данных

Ценность в Больших Данных представляют, как правило, уже обработанные сведения, сосредоточенные в статистике и итоговых результатах, — именно они и должны защищаться по классическим методикам с соблюдением правил доступа и конфиденциальности. Поисковые системы публикуют статистику, однако она максимально деперсонализирована — в открытом доступе нет сведений о конкретных страницах и сайтах, доступ к которым могут получить только владельцы соответствующих ресурсов. К тому же статистические данные часто используются и на этапе обработки в качестве статистических коэффициентов в правилах. Например, такие величины, как Page Rank (используются в Google для определения числа ссылок на страницу) или аналогичный показатель «Яндекса» (тематический индекс цитирования), являются результатом статистического анализа всех данных, но они же участвуют и в оценке каждой отдельной ссылки и сайта.

Эксперты CSA рекомендуют обеспечить сохранность результатов обработки с помощью средств защиты от утечек, гибкого контроля доступа и максимально возможного использования шифрования. Все это достаточно известные и отработанные механизмы, однако они должны быть модифицированы применительно к Большим Данным. В частности, контроль доступа должен настраиваться очень точно, чтобы не блокировать доступ к результатам вычислений аналитиков и не мешать распространению данных, одновременно обеспечивая сохранность наиболее ценных данных. Шифрование также должно быть не повсеместным, а минимально необходимым для защиты самой важной информации. Это же правило разумной достаточности должно выполняться и в системе защиты от утечек данных (Data Leak Protection, DLP), которую нужно настраивать на фильтрацию обработанных данных, а также при защите от атак. Выделять необходимо только актуальные угрозы для распределенной системы.

Управление данными

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

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

Реактивная безопасность

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

Чтобы исключить возможность изменения среды распределенных вычислений и инфраструктуры системы, необходимо обеспечить контроль ее целостности, построив для этого альтернативную систему мониторинга безопасности и производительности. Это позволит выявить неэффективные действия администраторов, вызванные их ошибками либо намеренными попытками вмешательства с недобрыми целями. Так как система распределенная, для ее контроля нужно собирать большое количество событий и анализировать их [3]. Для этого можно использовать традиционные системы класса SIEM (Security Information and Event Management) управления ресурсами или защиты от мошенничества.

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

Если же говорить о защите каждого отдельного элемента системы, то специалисты CSA рекомендуют начинать с инструментов, применяемых для защиты элементов традиционных систем. Связано это с тем, что рядовые хакеры обычно не атакуют систему как единое целое, а пытаются захватить контроль над отдельными серверами или сервисами. Кроме того, в CSA считают, что технологии для Больших Данных пока еще очень сложны и разработать для их взлома вредоносный код просто нерентабельно. В большинстве случаев нужно обеспечить защиту от массовых атак с помощью классических инструментов, не позволяющих вмешиваться в работу отдельных элементов системы. Для этого годятся традиционные средства защиты периметра, прикрывающие элементы распределенной системы и связывающие их воедино, — например, шифрованные каналы VPN. Отдельно стоит обратить внимание на защиту от DDoS-атак, которая для распределенных систем обработки Больших Данных жизненно необходима. Сегодня наблюдается активизация хакеров по созданию проблем для крупных ЦОД, а так как технологии из стека работы с Большими Данными сами по себе ресурсоемки, вывести их из строя может оказаться достаточно просто. К тому же в качестве компонентов сегодня часто используются доступные каждому инструменты с открытыми исходными кодами [1].

***

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

Литература

  1. Дмитрий Семынин. Стек для Больших Данных // Открытые системы.СУБД. — 2014. — № 01. — С. 42–43. URL: http://www.osp.ru/os/2012/09/13032513 (дата обращения: 11.03.2014).
  2. Кристина Алкарас, Шерали Зидалли. Защита критически важных систем управления // Открытые системы.СУБД. — 2014. — № 01. — С. 30–35. URL: http://www.osp.ru/os/2014/01/13039680 (дата обращения: 11.03.2014).
  3. Наталья Дубова. Большие Данные для управления ИТ // Открытые системы.СУБД. — 2014. — № 01. — С. 16–19. URL: http://www.osp.ru/os/2014/01/13039647 (дата обращения: 11.03.2014).

Валерий Коржов (osmag@osp.ru) — обозреватель, «Computerworld Россия» (Москва).