Политики в Ranger: ключевые понятия

Ranger — это удобный фреймворк, позволяющей управлять доступами и правами для Hadoop и других Big data-систем. Управление доступами для сервисов происходит с помощью политик, о которых рассказывается ниже.

Политика Ranger
Модель политики Ranger
Политика Ranger
Модель политики Ranger

Базовые концепции

Для понимания политик в Ranger следует ознакомиться с основными составляющими политик:

  • Ресурсы. В контексте Ranger ресурсом называется объект, доступ к которому можно ограничить (например, файл, база данных, таблица, столбец и т.д.). Так, у сервиса Solr есть лишь один ресурс — коллекция. Ranger позволяет использовать wildcard, макросы и переменные в именах ресурсов, что позволяет создавать меньшее количество политик для большого объема ресурсов.

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

    ПРИМЕЧАНИЕ
    Эти права следует отличать от прав доступа к модулям Ranger.
  • Правообладатели. В Ranger существует три вида правообладателей:

    • Пользователь. Индивидуальная сущность, которая может быть частью группы. Например, hdfs — пользователь, созданный для сервиса HDFS.

    • Группа. Набор пользователей с общей целью. Например, группа hadoop содержит в себе пользователей, созданных для сервисов Hadoop.

    • Роль. Уровень авторизации, который можно присвоить пользователю. В Ranger Admin существует три системных роли: User (базовые права), Admin (права на все модули, кроме KMS) и Auditor (права на все модули). Вы также можете создать кастомную роль, которая может включать в себя пользователей, группы и другие роли.

    Пользователи и группы обычно импортируются из LDAP/AD/OS с помощью UserSync. При создании политики можно установить разрешение/запрет доступа на несколько правообладателей сразу.

  • Условия доступа. Политики авторизации обычно содержат описание правообладателей, которым разрешен некоторый доступ, но в Ranger также можно указать список пользователей, кому доступ к ресурсу запрещен. Помимо этого можно указать исключения как для списка пользователей, имеющих доступ к ресурсу (например, если доступ выдан группе, но у некоторых пользователей его быть не должно), так и для списка тех, кому доступ запрещен (например, доступ запрещен группе, но некоторым пользователям из этой группы доступ необходимо выдать). Например, в политике ниже у пользователя hbase есть права на чтение, запись и исполнение в директории /hbase/archive.

    Условия доступа для политики HDFS
    Условия доступа для политики HDFS
    Условия доступа для политики HDFS
    Условия доступа для политики HDFS
  • Время актуальности политики. Ranger позволяет сделать политику активной только в какой-то момент времени. Данная функция полезна, если требуется выдать временные права доступа (например, установив срок на неделю) или настроить отложенную выдачу прав.

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

  • Назначенный администратор. Помимо администраторов Ranger, некоторые пользователи/группы/роли также могут управлять политиками авторизации для определенного ресурса. Для достижения такого поведения при создании политики следует установить галочку Delegate admin для соответствующих правообладателей. Например, в политике, представленной ниже, пользователь hdfs является назначенным администратором для всех ресурсов сервиса HDFS, в то время как zeppelin и impala просто имеют права на чтение, запись и исполнение.

    Политика HDFS с назначением администратора
    Политика HDFS с назначением администратора
    Политика HDFS с назначением администратора
    Политика HDFS с назначением администратора

Работа с данными

Маскировка данных

В Ranger можно маскировать отображаемую информацию для некоторых ресурсов. Так, например, в колонке Hive вместо возраста человека можно указывать диапазон возрастов, в который он попадает (30-40 вместо 35). Для этого нужно создать политику маскировки, где указываются пользователи, которые будут видеть исходную информацию, и пользователи, которые будут видеть обфусцированные данные.

Фильтр строк

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

ПРИМЕЧАНИЕ
Политики маскировки и фильтра строк не дают доступа к ресурсам. Если в такой политике указан пользователь, у которого нет доступа к маскируемому ресурсу, то она не будет применена для него.

Разграничение доступа

Механизм контроля доступа строго разграничивает доступ к данным среди сущностей. В Ranger данный механизм строится на условиях доступа, устанавливаемых во время создания политики, и называется разграничением доступа на основе атрибутов (Attribute Based Access Control, ABAC). Это такая модель управления доступом, согласно которой возможность пользователя выполнять операции зависит от правил для атрибутов субъекта (пользователь, группа), объекта (ресурс), операции (создание, чтение и т.д.) и среды (время, локация, устройство и т.д.). ABAC позволяет создавать политики авторизации, не зависящие от специфик ресурсов и пользователей, благодаря чему можно не создавать новые политики при добавлении ресурсов и пользователей. Например, чтобы разрешить пользователям работать с ресурсами, принадлежащим им, следует издать политику с макросом {OWNER} в секции Allow conditions.

Использование макроса {OWNER}
Использование макроса {OWNER}
Использование макроса {OWNER}
Использование макроса {OWNER}

Ниже представлены два подвида разграничения доступа на основе атрибутов.

Разграничение доступа на основе ресурсов

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

Разграничение доступа на основе тегов

Тег представляет собой особую метку, присваиваемую ресурсу, чтобы впоследствии применить к нему определенные политики. Теги позволяют администраторам разделять ресурсы по категориям (персональные медицинские данные, личная информация, данные банковских карт и т.д.). Для безопасной реализации доступа к ресурсам следует хорошо продумать классификацию данных и создать инструменты для определения конфиденциальной информации.

Большим плюсом создания политик для классификаций, а не для ресурсов, является свойство таких политик применяться к классификациям по мере их добавления, удаления и обновления. Также можно создать лишь одну политику на основе тега для авторизации доступа к ресурсу сразу нескольким сервисам, таким как Hive, HBase, Kafka. Данная функция позволяет значительно упростить управление политиками авторизации.

Для лучшей расширяемости следует использовать подход на основе тегов вместе с авторизацией на основе ролей.

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней