Безопасность данных в Apache HBase

курсы HBase администратор списки доступа привилегии права примеры курсы обучение, Apache HBase Hadoop администратор кластера курс, администрирование Apache HBase, NoSQL курсы примеры обучение, Школа Больших Данных Учебный центр Коммерсант

Сегодня в рамках обучения администраторов SQL-on-Hadoop рассмотрим, как защитить данные в кластере Apache HBase от несанкционированного доступа. Аутентификация и авторизация пользователей, операторы управления доступом к таблицам, метки видимости и шифрование данных.

Механизмы защиты данных в Apache HBase

Как и любое хранилище, колоночно-ориентированная мультиверсионная NoSQL-СУБД типа key-value Apache HBase, которая работает поверх HDFS и обеспечивает возможности Google BigTable для Hadoop, имеет механизмы защиты данных. Их можно разделить на следующие категории:

  • аутентификация и авторизация пользователей и сервисов, которые обращаются к этой СУБД;
  • управление доступом на основе ролей (RBAC) определяет, какие пользователи или группы могут читать и записывать ресурс или выполнять конечную точку сопроцессора;
  • метки видимости, которые позволяют вам помечать ячейки и контролировать доступ к помеченным ячейкам, чтобы дополнительно ограничить, кто может читать или записывать определенные подмножества ваших данных. Метки видимости хранятся в виде тегов.
  • шифрование данных в состоянии покоя в базовой файловой системе, как в HFiles, так и в WAL. Это защищает данные в состоянии покоя от злоумышленника, который имеет доступ к базовой файловой системе, без необходимости изменять реализацию клиента. Этот способ также может защитить от утечки данных из-за неправильно расположенных дисков, что может быть важно для соблюдения законодательных и нормативных требований.

Настройка аутентификации

Начнем аутентификации, а именно с протоколов, по которым происходит клиента обращение к серверам HBase. При установке HBase по умолчанию используются небезопасные HTTP-соединения для веб-интерфейсов мастер-сервера и серверов регионов. Чтобы включить безопасные HTTPS-соединения, надо задать для параметра hbase.ssl.enabled значение true в конфигурационном файле hbase-site.xml. Это не меняет порт, используемый веб-интерфейсом. Для изменения порта веб-интерфейса этого компонента, следует настроить параметры hbase.master.info.port и hbase.regionserver.info.port в файле конфигурации hbase-site.xml.

При включенном HTTPS, клиенты должны избегать использования незащищенного соединения HTTP и подключаться к HBase, указывая нужный протокол в URL-адресе (https://). Клиенты, использующие URL-адрес http://, получат HTTP-ответ 200, но не получат никаких данных. Также будет зарегистрировано следующее исключение:

javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

Это исключение вызвано тем, что один и тот же порт используется для HTTP и HTTPS. HBase использует написанный на Java веб-сервер и контейнер сервлетов Jetty для веб-интерфейса. Без изменения самого Jetty его нельзя настроить для перенаправления одного порта на другой на одном и том же хосте.

Простой пользовательский доступ не является безопасным методом работы, поскольку не предотвращает злонамеренных действий или попыток взлома. Тем не менее, его можно использовать для имитации управления доступом в контуре разработки без необходимости настройки защищенного протокола Kerberos, о чем мы поговорим далее. Для этого нужно внести изменения в конфигурационные файлы hbase-site.xml на каждом сервере в кластере, полностью отключить и перезапустить HBase, а также изменить конфигурации на клиентах. Если значения параметра hbase.security.authentication в файлах hbase-site.xml на клиентах и на серверах не совпадают, клиент не сможет взаимодействовать с кластером.

Чтобы взаимодействовать с HBase через REST API, необходимо настроить REST Gateway на стороне клиента, т.к. REST-шлюз будет аутентифицироваться, используя предоставленные учетные данные. Однако, сам шлюз REST не будет выполнять аутентификацию: весь клиентский доступ через него лишь использует его учетные данные и привилегии. Поэтому необходимо настроить доступ пользователю REST API, что можно сделать с помощью команды предоставления привилегий:

grant ‘rest_server’, ‘RWCA’

где R — представляет привилегию чтения, W – записи, X – выполнения, C – создания, а A – дает права администратора.

Версии Apache HBase старше 0.92 поддерживают дополнительную аутентификацию клиентов SASL (Simple Authentication and Security Layer). Для каждого соединения SASL позволяет выполнять аутентификацию, согласование шифрования и/или проверку целостности сообщения, а также возможность вызывать процедуры на удаленном сервере (RPC).

Помимо простого типа аутентификации, REST-шлюз поддерживает протокол защищенный kerberos. Также можно реализовать пользовательскую аутентификацию, внедрив Hadoop AuthenticationHandler, а затем указав полное имя класса в качестве значения параметра hbase.rest.authentication.type.

Возвращаясь к широко используемому для аутентификации сетевому протоколу Kerberos, отметим его высокую надежность для клиент-серверных приложений за счет криптографии с секретным ключом. Чтобы помочь клиенту подтвердить свою личность серверу, и наоборот, через небезопасное сетевое соединение, протокол Kerberos использует алгоритмы AES, 3DES и пр. Клиент и сервер также могут шифровать все свои сообщения, чтобы обеспечить конфиденциальность и целостность данных. Сперва клиент HBase аутентифицирует себя на сервере аутентификации Kerberos. После этого он получает билет на предоставление билетов (TGT). Затем с сервера выдачи билетов клиент запрашивает билет службы. Если клиентский TGT, отправленный с запросом, действителен, он выдает билет и ключ сеанса. Для аутентификации клиент использует сам сервисный билет на сервер, который предоставляет услугу, которую использует клиент, например, HDFS или HBase.

Чтобы запустить RPC с надежной проверкой подлинности, необходимо установить для hbase.security.authentication значение kerberos в файле core-site.xml. Иначе придется использовать строгую аутентификацию для HBase, но не для базовой файловой системы HDFS. Для этого следует проверить значение параметра security.prerequisites базовой конфигурации HDFS в файла hbase-site.xml на каждом сервере в кластере и клиентах.

Клиентская среда должна быть зарегистрирована в Kerberos из KDC или keytab с помощью команды kinit, прежде чем станет возможной связь с кластером HBase. Если значения параметров hbase.security.authentication в конфигурациях клиента и сервера не совпадают, клиент не сможет взаимодействовать с кластером. После настройки СУБД для безопасного RPC можно дополнительно настроить зашифрованную связь, внеся изменения в файл hbase-site.xml на каждом клиенте.

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

ACL-списки и команды управления привилегиями для авторизации

Начиная с версии 0.92 (CDH4), в Apache HBase поддерживаются списки управления доступом (ACL), которые позволяют определить политику авторизации (чтение/запись/создание/администрирование) с точностью до таблицы, семейства или классификатора для указанного пользователя.

При этом безопасность этого NoSQL-хранилища опирается на безопасность HDFS и ZooKeeper, от которых зависит это NoSQL-СУБД. Поэтому для связи с HDFS и ZooKeeper серверам СУБД необходимо создать безопасный сеанс службы. Более того, поскольку фактически файлы данных хранятся в файловой системе HDFS, при управлении доступом следует учитывать права HDFS, основанные на пользователях, группах и разрешениях, как и в Unix-системах.

На каждом узле сервиса синхронизации метаданных ZooKeeper есть ACL-список, который разрешает пользователям доступ для чтения/записи на основе пользовательской информации аналогично HDFS. ZooKeeper имеет подключаемый механизм аутентификации, позволяющий клиентам получать доступ с помощью различных методов. ZooKeeper позволяет одновременно работать с аутентифицированными и неаутентифицированными клиентами. Доступ к узлам можно ограничить, предоставив ACL-списки для каждого узла. ACL состоит из двух компонентов: метода аутентификации и принципала. Важно, что ACL-списки не применяются иерархически.

Чтобы разрешить или ограничить доступ аутентифицированного пользователя к определенной таблице HBase, т.е. предоставить ему права авторизации, следует включить сопроцессор контроллера доступа. Для этого надо добавить его в конфигурационный файл hbase-site.xml в классах сопроцессора мастер-сервера и серверов регионов.

Системные службы (демоны) NoSQL-хранилища аутентифицируются в ZooKeeper через SASL и Kerberos. HBase настраивает списки управления доступом znode таким образом, что только пользователь и настроенный суперпользователь (hbase.superuser) могут получать доступ и изменять данные. Суперпользователь — это участник, указанный в файле конфигурации, который имеет такой же доступ к этой СУБД, как и пользователь root в производной системе UNIX. Обычно это принципал, в качестве которого аутентифицируются сами процессы хранилища. Хотя HBase может поддерживать несколько суперпользователей, привилегия суперпользователя всегда будет включать принципала, используемого для запуска процесса HMaster. Только суперпользователь может создавать таблицы, включать и выключать балансировщик или выполнять другие действия с глобальными последствиями. Кроме того, суперпользователь имеет неявное предоставление всех разрешений на все ресурсы.

Когда ZooKeeper используется для обнаружения службы или обмена состоянием с клиентом, созданные СУБД узлы znodes также позволят любому пользователю (независимо от аутентификации) читать их метаданные (clusterId, главный адрес, мета-местоположение и пр.), но только пользователь HBase может изменить их.

Все управляемые данные хранятся в корневом каталоге HDFS (hbase.rootdir). Доступ к данным и файлам WAL в файловой системе должен быть ограничен, чтобы пользователи не могли обойти уровень хранилища и просмотреть базовые файлы данных из файловой системы. NoSQL-СУБД предполагает, что используемая файловая система (HDFS или другая) применяет разрешения иерархически. Если не обеспечена достаточная защита со стороны файловой системы (авторизация и аутентификация), управление авторизацией на уровне HBase (ACL, метки видимости и пр.) не имеет смысла, поскольку пользователь всегда может получить доступ к данным из файловой системы.

HBase применяет posix-подобные разрешения 700 (rwx——) для своего корневого каталога. Это означает, что только пользователь этой СУБД может читать или записывать файлы в файловую систему. Поведение по умолчанию можно изменить, настроив параметр hbase.rootdir.perms в hbase-site.xml. Чтобы применить эти разрешения, следует перезапустить активный мастер-узел.

В безопасном режиме SecureBulkLoadEndpoint следует настроить и использовать для правильной передачи пользовательских файлов, созданных из заданий MapReduce, демонам и пользователям HBase. Промежуточный каталог в распределенной файловой системе, используемой для массовой загрузки (hbase.bulkload.staging.dir, по умолчанию /tmp/hbase-staging), должен иметь режим 711 или rwx—x—x, чтобы пользователи могли получить доступ к промежуточному каталогу, поскольку каталог, созданный в этом родительском каталоге, но не может выполнять никакие другие операции.

В заключение отметим команды, которые позволяют управлять доступом к таблицам и семейству столбцов:

  • grant — предоставляет определенные права, такие как чтение, запись, выполнение и администрирование таблицы определенному пользователю
grant <user> <permissions> [<table> [<column family> [<column; qualifier>]]
  • revoke – отзывает права доступа пользователя к таблице
revoke <user>
  • user_permission – выводит список всех разрешений для конкретной таблицы
user_permission <table>

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

Узнайте больше подробностей про администрирование и эксплуатацию Apache Hive и других компонентов экосистемы Hadoop для хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://www.vskills.in/certification/tutorial/hbase-security/
  2. https://data-flair.training/blog/hbase-security/
  3. https://svn.apache.org/repos/asf/hbase/hbase.apache.org/trunk/0.94/book/hbase.accesscontrol.configuration.html
Контакты авторизированного учебного центра
«Школа Больших Данных»
Адрес:
127576, г. Москва, м. Алтуфьево, Илимская ул. 5 корпус 2, офис 319, БЦ «Бизнес-Депо»
Часы работы:
Понедельник - Пятница: 09.00 – 18.00
Остались вопросы?
Звоните нам +7 (495) 414-11-21 или отправьте сообщение через контактную форму. Также вы можете найти ответы на ваши вопросы в нашем сборнике часто задаваемых вопросов.
Оставьте сообщение, и мы перезвоним вам в течение рабочего дня
Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.
Или напишите нам в соц.сетях
Поиск по сайту