Как правильно строить защиту Big Data и виды проблем безопасности.
Информационная безопасность Информационная безопасность

Как правильно строить защиту больших данных? Какие ИБ-проблемы есть у Hadoop? Существует ли универсальная пилюля от всех уязвимостей Big Data?

Информационная безопасность Тема номера

Защита Big Data

Дата публикации:
31.07.2020
Посетителей:
3264
Просмотров:
3564
Время просмотра:
2.3

Авторы

Автор
Андрей Черных В прошлом - руководитель отдела систем мониторинга ИБ и защиты приложений центра информационной безопасности «Инфосистемы Джет»

Как правильно строить защиту больших данных?

 

Какие ИБ-проблемы есть у Hadoop?

 

Существует ли универсальная пилюля от всех уязвимостей Big Data?

 

 

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

 

Hadoop — одно из самых распространенных и активно развивающихся решений для работы с Big Data. Это платформа с открытым исходным кодом, в основе которой лежит распределенная файловая система. Поверх нее функционируют различные сервисы для обработки информации. Hadoop позволяет реализовывать распределенные вычисления и хранение данных. На действительно больших объемах информации — десятках и сотнях терабайт — платформа работает эффективнее классических реляционных БД.

 

У большинства крупных заказчиков решение Hadoop либо уже есть, либо скоро появится. В основном используются сборки от трех вендоров: американской компании Cloudera, вошедшего в ее состав разработчика Hortonworks и российского производителя Arenadata.

 

ИБ-проблемы Hadoop и методы их решения

 

По умолчанию в Hadoop отключена аутентификация пользователей. Сегодня поисковик Shodan выдает около 900 публично доступных сервисов HDFS (распределенная файловая система Hadoop) без какой-либо аутентификации. Среди результатов поиска можно найти даже такие примеры, как почти 500 ТБ общедоступных данных (см. рис. 1).

Авторы

Теги

На первый взгляд может показаться, что разграничение прав все-таки присутствует и получить доступ к данным мы не можем (см. рис. 2).

 

Но это ограничение можно легко обойти, если представиться системным пользователем (см. рис. 3).

Рисунок 1. Пример результатов поискового запроса в Shodan
Рисунок 2. Обращение к WebHDFS без указания конкретного пользователя
Рисунок 3. Обращение к WebHDFS с указанием конкретного пользователя

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

 

Многие сервисы Hadoop по умолчанию работают без SSL. Проблема особенно актуальна, когда данные выходят за пределы защищенного контура компании (если он вообще существует). Решается она очевидным образом — включением SSL для каждого сервиса.

 

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

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

 

Вопрос прав доступа часто вскрывает в компании большой пласт проблем, напрямую не связанных с Big Data. Это непонимание бизнес-задач подразделений и перечня данных, к которым им действительно необходим доступ; отсутствие или плохая работа механизмов классификации и обезличивания информации; нехватка контроля действий администраторов. Решить все эти проблемы исключительно средствами Hadoop или только за счет наложенных средств защиты не удастся. Нужно менять либо создавать определенные процессы внутри организации (как минимум реализовать классификацию данных).

 

Универсальной «пилюли», способной решить все ИБ-проблемы Hadoop, к сожалению, не существует. Нужно использовать и встроенные, и наложенные средства защиты.

Кейс

 

Проблема

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

 

Решение

Мы рекомендовали выделить тестовый кластер в отдельный VLAN и использовать механизмы обезличивания данных как в тестовых системах-источниках, так и в самом Hadoop.

Безопасность Big Data

Начинаем с инфраструктуры

01

Формируем защищенный контур с помощью межсетевого экрана.

02

Организуем доступ пользователей к сервисам Hadoop через Apache KNOX. Это встроенное средство защиты, обеспечивающее единый прокси для сервисов платформы.

03

Сканируем инфраструктуру и установленное на серверах ПО при помощи сканеров уязвимостей.

04

Контролируем доступ и действия администраторов на уровне операционной системы через решения класса PIM/PUM/PAM. Как минимум, целесообразно записывать сессию администратора.

Движемся к защите данных

01

Шифруем данные на уровне распределенной файловой системы встроенными средствами защиты Hadoop.

02

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

03

Проводим мониторинг активности пользователей Hadoop при обращении к данным. Можно сделать это и средствами Apache Ranger, но в нем достаточно топорная отчетность (всего один вариант отчета без каких-либо глубоких настроек). Еще хуже обстоит ситуация с интеграцией с системами мониторинга событий ИБ и отправкой уведомлений: штатные средства интеграции фактически отсутствуют. Гораздо более удачный вариант — решения класса Database Activity Monitoring (DAM). Среди их преимуществ можно отметить более гибкую отчетность, возможности интеграции с другими системами и интерфейс управления политиками безопасности.

04

Маркируем и тегируем данные средствами Apache Atlas. В дальнейшем теги можно использовать в политиках Ranger, что существенно упрощает процесс разграничения доступа. Вместо нескольких сотен и даже тысяч объектов мы получаем считанное число тегов. Инструмент не предполагает какой-либо встроенной автоматизации, но у него есть API. Так, на одном промышленном предприятии мы размечали объекты в Excel (благо их было не слишком много) и передавали результаты в Atlas по API. Это позволило сократить число ручных операций в Atlas.

05

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

Если собрать все средства защиты вместе, выглядеть это будет примерно так (см. рис. 4).

Рисунок 4. Средства защиты Big Data

Уведомления об обновлении тем – в вашей почте

Маленькая «серебряная пуля»

Данные – новая валюта бизнеса. Пожалуй, многие согласятся с таким утверждением

Анализ Big Data в ML-проектах

Почему традиционные СУБД не подходят для анализа Big Data? Что дает использование Cloudera Data Platform? Подробности создания Data Lake для Группы НЛМК

«Большая вода»… «Большая руда»… Большие Данные!

Термин "Big Data" родился 4 сентября 2008 года с лёгкой руки журнала "Nature" и его редактора Клиффорда Линча (Clifford Lynch). В этот день вышел номер журнала "Nature" с темой номера "Большие Данные. Наука петабайтной эры" ("Science in the Petabyte era").

Матрица: эволюция

В первой «Матрице» есть эпизод, в котором оператор в режиме реального времени мониторит многочисленные показатели системы и дает Нео совет: «Информации, получаемой из Матрицы, гораздо больше, чем ты можешь расшифровать. Нужно адаптироваться к этому»

Как не утопить ваши данные в болоте

Практика говорит: все больше и больше заказчиков приходит с идей построить единое хранилище, да еще на новых технологиях.

В омут с головой? Что может дать «озеро данных» бизнесу

Методология data lake при правильном использовании позволяет справиться с обработкой и хранением увеличивающихся объемов данных/

Анализируй это, или Тренды рынка BI

Как Артур Конан Дойл описал ожидания от работы BI за 100 лет до его появления.

Современный ритейлер трансформируется в цифровую компанию

Руководитель направления “Стратегия и инновации” ИТ-дирекции X5 Retail Group Виталий Порубов рассказал нам об особенностях цифровой трансформации одного из крупнейших отечественных ритейлеров в условиях, когда инновации стали важным способом оптимизации бизнеса.

«Этим можно заниматься бесконечно»: переход на data-driven в «СИБУРе»

Почему не стоит создавать цифрового двойника для отдельного участка производства? Зачем нужен «спецназ» по работе с данными? Почему заводы «СИБУРа» пока не смогут работать без людей?

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня