Управление безопасностью приложений и ПО промежуточного слоя

  • 9 мин

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

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

Целью обеспечения безопасности приложений в HDInsight является предоставление способов безопасной проверки подлинности множества пользователей в HDInsight с ограничением их прав доступа к данным минимальными разрешениями, необходимыми для выполнения рабочих задач. Кроме того, в журналах должны регистрироваться события, имеющие значение с точки зрения безопасности, такие как вход в систему, попытка выполнить привилегированное действие или изменение важной записи.

Проверка подлинности

Проверка подлинности — это процесс удостоверения подлинности пользователя. Кластеры HDInsight в рабочих сценариях обычно должны давать широкому спектру пользователей из разных бизнес-групп возможность проходить проверку подлинности для выполнения таких действий, как настройка, отправка, запуск и мониторинг рабочих нагрузок. Включение функции "Корпоративный пакет безопасности" (ESP) во время создания кластера HDInsight позволяет присоединить его к домену, после чего пользователи домена могут использовать свои учетные данные домена для прохождения проверки подлинности в кластере. Группы Active Directory можно использовать для создания групп отдельных пользователей, представляющих какую-либо функцию или отдел в организации. Несколько таких групп можно синхронизировать с кластером во время его создания. В кластере должны быть администратор кластера домена и одна или несколько групп пользователей с ограниченным доступом. Ниже представлена схема компонентов и сторон, участвующих в процессе проверки подлинности в HDInsight.

Процесс проверки подлинности в HDInsight

В процессе настройки и проверки подлинности в кластере ESP участвуют перечисленные ниже компоненты домена корпоративной идентификации.

  • Windows Server Active Directory: в локальном контроллере домена хранится имя субъекта-пользователя (UPN) (например, user@Contoso.com) и соответствующие пароли домена.
  • Active Directory Connect (AD Connect): средство Майкрософт, предназначенное для настройки гибридной идентификации. Для настройки ESP в HDInsight крайне важны такие функциональные возможности, как синхронизация хэшей паролей.
  • Каталог действий Azure (Идентификатор Microsoft Entra): служба управления удостоверениями и доступом в Microsoft Azure.
  • Доменные службы Microsoft Entra (Доменные службы Microsoft Entra): предоставляет управляемые доменные службы , такие как присоединение к домену, групповая политика, протокол LDAP и проверка подлинности Kerberos/NTLM, полностью совместимая с Windows Server Active Directory. Вы можете использовать эти доменные службы без необходимости развертывать и исправлять контроллеры домена в облаке, или управлять ими. Доменные службы Microsoft Entra интегрируются с существующим клиентом Microsoft Entra, что позволяет пользователям входить с помощью имеющихся учетных данных. Вы также можете использовать существующие группы и учетные записи пользователей для защиты доступа к ресурсам, что позволит более плавно переместить локальных ресурсы в Azure.

HDInsight поддерживает два сценария проверки подлинности.

  • Когда хэши паролей синхронизируются с идентификатором Microsoft Entra.
  • Хэши паролей хранятся в локальных контроллерах домена. Обратите внимание, что пользователь может создать кластер HDInsight с Windows Azure Storage Blob (WASB) или хранилищем ADLS 2-го поколения, при этом процесс проверки подлинности немного различается. Хотя все этапы процесса проверки подлинности выполняются автоматически и абстрагируются для пользователя, полезно в общих чертах понимать последовательность событий, которые происходят при проверке подлинности пользователя.

Проверка подлинности: при синхронизации хэшей паролей с идентификатором Microsoft Entra

Проверка подлинности: при синхронизации хэшей паролей с идентификатором Microsoft Entra

  1. Пользователь Иван Петров проходит проверку подлинности в службе HDInsight (например, Ambari, SSH, Zeppelin и т. д.) с учетными данными домена user@contoso.onmicrosoft.com (то есть именем субъекта-пользователя или UPN) и паролем. Имя пользователя и пароль хранятся в шлюзе.
  2. Шлюз HDInsight отправляет имя участника-пользователя и пароль, предоставленные пользователем, в идентификатор Microsoft Entra с помощью потока учетных данных владельца ресурса (ROPC) и запрашивает запрос на доступ OAuth. Идентификатор Microsoft Entra подтверждает удостоверение пользователя и выдает маркер обновления, сохраненный в службе учетных данных, которая выполняется на головном узле. В кластерах с учетными записями в хранилище ADLS 2-го поколения драйверы хранилища взаимодействуют со службой учетных данных для получения маркера OAuth с целью сквозной проверки подлинности в ADLS.
  3. Затем шлюз проходит проверку подлинности пользователя с помощью доменных служб Microsoft Entra и получает билет Kerberos. Затем шлюз передает билет Kerberos в головные узлы и выполняет проверку подлинности пользователя в кластере.

Проверка подлинности MFA: если хэши паролей не синхронизируются с идентификатором Microsoft Entra

Примечание.

Эта конфигурация также называется Брокером удостоверений HDInsight (HIB) и поддерживает многофакторную проверку подлинности (MFA). Если хэши паролей не синхронизируются с идентификатором Microsoft Entra, пользователь по-прежнему может пройти проверку подлинности в шлюзе.

Если хэши паролей не синхронизированы с идентификатором Microsoft Entra

  1. Пользователь Иван Петров запускает веб-службу HDInsight, например Ambari или Zeppelin. Страница перенаправляет пользователя на экран интерактивного входа. Клиент перенаправляется на идентификатор Microsoft Entra, чтобы пользователь прошел проверку подлинности с помощью имени участника-пользователя user@contoso.onmicrosoft.com.
  2. При вводе имени субъекта-пользователя клиент перенаправляется на локальный сервер ADFS, где пользователь вводит свой пароль. Теперь выполняется многофакторная проверка подлинности, если она включена. После успешной проверки подлинности клиенту выдается маркер OAuth.
  3. Клиент представляет токен OAuth шлюзу HDInsight.
  4. Шлюз HDInsight использует маркер OAuth для получения билета Kerberos из узла HIB.
  5. Шлюз использует билет Kerberos и регистрирует маркер OAuth в службе учетных данных в головных узлах, а затем выполняет проверку подлинности в кластере.

Примечание.

Если хэши паролей не синхронизированы с идентификатором Microsoft Entra, пользователи домена не могут выполнять ssh на головные узлы. Только локальный пользователь SSH может выполнять действия SSH. Руководство по настройке механизмов проверки подлинности в обоих сценариях приводится в статье Использование Брокера удостоверений для управления учетными данными.

Авторизация

Авторизация в HDInsight служит для определения и применения привилегий пользователей к базовым наборам данных. Детальная авторизация определенных действий и операций доступна в службах HDInsight Hive, HBase и Kafka. Управление ею осуществляется посредством Apache Ranger. Ranger обеспечивает управление доступом на основе ролей, управление доступом на основе атрибутов и централизованный аудит доступа пользователей и действий администрирования. Проверка подлинности в Apache Ranger обычно выполняется с использованием учетных данных домена, принадлежащих администратору кластера. После этого в Ranger настраиваются политики для групп или пользователей с ограниченным доступом. В приведенном ниже примере демонстрируются способы создания политики Ranger с целью применения разрешений к образцу таблицы Hive.

  1. Запустите Apache Ranger по следующему URL-адресу: https://CLUSTERNAME.azurehdinsight.net/Ranger/. Замените CLUSTERNAME именем своего кластера. Для входа используйте имя администратора домена кластера и соответствующий пароль.

    Настройка разрешений с помощью Apache Ranger

  2. Щелкните "Добавить новую политику", чтобы добавить новую политику Ranger.

    Добавление новой политики Ranger

  3. Укажите следующие сведения о политике:

    1. "Имя политики": имя политики.
    2. "База данных": выберите базу данных Hive.
    3. "Таблица": выберите таблицу Hive в выбранной базе данных.
    4. "Столбец Hive": выберите столбец Hive, к которому будет применена политика.
    5. Задайте для параметра "Ведение журнала аудита" значение "Да", чтобы включить ведение журнала всех событий доступа.
    6. Разрешить условия:
      • В разделе "Разрешенные условия" можно применять политики к пользователям или группам домена Active Directory (AD). Если вы хотите применить политику ко всем пользователям в группе AD, добавьте ее в раздел "Выбор группы".
      • Кроме того, если вы хотите, чтобы политика применялась к отдельному пользователю или набору пользователей из разных групп AD, можно добавить в поле "Выбор пользователя" все идентификаторы пользователей домена.
      • В столбце "Разрешения" выберите нужные разрешения, установив флажки.

  4. Прокрутите содержимое вниз и нажмите кнопку "ОК".

    Добавление политики

  5. После настройки это правило будет применяться ко всем пользователям, включенным в политику.

Описание настройки политик Ranger для HBase и Kafka можно найти по соответствующим гиперссылкам.

Аудит

Аудит в HDInsight с точки зрения безопасности представляет собой процесс регистрации и мониторинга запросов проверки подлинности и авторизации, происходящих на протяжении всего существования кластера и даже после его удаления.

Аудит в HDInsight обеспечивается посредством журналов Azure Monitor и может использоваться для представления журналов, критически важных для безопасности кластера. Ниже перечислены некоторые таблицы журналов, содержащих сведения, критически важные для безопасности кластера.

Имя таблицы журнала Характер использования
ranger_audit_logs_CL Журналы аудита из Apache Ranger в кластерах ESP
log_gateway_audit_CL Журналы аудита шлюза, содержащие успешные и неудачные попытки
log_ambari_audit_CL Журналы аудита из Ambari
log_auth_CL Журналы SSH со сведениями об успешных и неудачных попытках

Мониторинг Azure включается на портале Azure несколькими щелчками мыши.

  1. В кластере HDInsight щелкните Azure Monitor в левой колонке. Установите переключатель "Интеграция Azure Monitor" в положение "Включить" и в поле "Выберите рабочую область" выберите предварительно созданную рабочую область Log Analytics из раскрывающегося списка.

    Использование Azure Monitor

  2. Запустите рабочую область Log Analytics и импортируйте решения мониторинга HDInsight, соответствующие типу кластера. Запустите решение и щелкните "Журналы".

    Просмотр журналов

  3. Таблицы журналов, относящиеся к безопасности, можно найти в разделе "Настраиваемые журналы" слева. К ним можно выполнять запросы для извлечения нужных сведений о доступе.

    Просмотр настраиваемых журналов