Версия сайта для слабовидящих
Сегодня в рамках обучения администраторов 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 в Москве:
Источники
