Общие сведения и рекомендации по корпоративной безопасности в Azure HDInsight

При развертывании безопасного кластера HDInsight существуют некоторые рекомендации, которые упрощают развертывание и управление кластерами. Здесь рассматриваются некоторые общие сведения и рекомендации.

Использование защищенного кластера

  • Кластер будет использоваться несколькими пользователями одновременно.
  • Пользователи имеют разные уровни доступа к одинаковым данным.

Необязательно

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

Использование локальной учетной записи

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

Рейнджер

Политики

  • По умолчанию Ranger использует запрет в качестве политики.

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

    • При вызове подключаемого модуля авторизации Ranger ему передается контекст запроса.
    • Ranger применяет политики, настроенные для сервиса. Если политики Ranger завершаются ошибкой, проверка доступа откладывается в файловую систему. Некоторые службы, такие как MapReduce, проверяют, принадлежит ли файл или папка тому же пользователю, который отправляет запрос. Такие службы, как Hive, проверяют соответствие владения или соответствующие разрешения файловой системы (rwx).

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

  • Политики можно применять к группам (предпочтительнее) вместо отдельных лиц.

  • Авторизатор Ranger будет оценивать все политики Ranger для этой службы для каждого запроса. Эта оценка может повлиять на время принятия задания или запроса.

Доступ к хранилищу

  • Если тип хранилища — WASB, то не используется маркер OAuth.
  • Если Ranger выполнил авторизацию, доступ к хранилищу происходит с помощью управляемого удостоверения.
  • Если Ranger не выполнил никакой авторизации, доступ к хранилищу происходит с помощью токена OAuth пользователя.

Иерархическое пространство имен

Если иерархическое пространство имен не включено:

  • Наследуемые разрешения отсутствуют.
  • Только разрешение файловой системы, которое работает, — это роль Azure Storage Data XXXX, назначаемая пользователю напрямую через портал Azure.

Разрешения HDFS по умолчанию

  • По умолчанию у пользователей нет доступа к / папке в HDFS (они должны находиться в роли владельца BLOB-объектов хранилища для успешного доступа).
  • Для промежуточного каталога для mapreduce и других создается каталог, специфичный для пользователя, и предоставляются соответствующие sticky _wx разрешения. Пользователи могут создавать файлы и папки под ним, но не могут просматривать другие элементы.

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

Если включена проверка подлинности URL-адреса:

  • Конфигурация будет содержать префиксы, которые охватываются в аутентификации URL (например, adl://).
  • Если доступ указан для этого URL-адреса, Ranger проверяет, находится ли пользователь в списке разрешений.
  • Ranger не будет проверять политики с высокой степенью детализации.

Управление журналами аудита Ranger

Чтобы предотвратить потребление слишком большого количества дискового пространства на головном узле hn0 из-за аудиторских журналов Ranger, вы можете изменить количество дней их сохранения.

  1. Войдите в пользовательский интерфейс Ambari.
  2. Перейдите к службам>RangerConfigs>AdvancedAdvanced ranger-solr-configuration>.
  3. Измените значение "Максимальные дни хранения" на 7 дней или меньше.
  4. Выберите "Сохранить и перезапустить затронутые компоненты", чтобы изменения вступили в силу.

Использование пользовательской базы данных Ranger

Мы рекомендуем развернуть внешнюю базу данных Ranger для использования с кластером ESP для обеспечения высокой доступности метаданных Ranger, что гарантирует доступность политик, даже если кластер недоступен. Так как внешняя база данных управляется клиентом, вы также сможете настроить размер базы данных и предоставить общий доступ к базе данных в нескольких кластерах ESP. Вы можете указать внешнюю базу данных Ranger DB во время процесса создания кластера ESP с помощью портала Azure, Azure Resource Manager, Azure CLI и т. д.

Настройте синхронизацию пользователей Ranger на ежедневное выполнение.

Кластеры HDInsight ESP настраиваются для Ranger для автоматической синхронизации пользователей AD каждый час. Синхронизация Ranger — это синхронизация пользователей и может вызвать дополнительную нагрузку на экземпляр AD. По этой причине рекомендуется изменить интервал синхронизации пользователя Ranger на 24 часа.

  1. Войдите в пользовательский интерфейс Ambari.
  2. Перейдите к Службам>Ranger>Configs>Advanced>ranger-ugsync-site
  3. Задайте для свойства ranger.usersync.sleeptimeinmillisbetweensynccycle значение 864000000 (24h в миллисекундах).
  4. Выберите "Сохранить и перезапустить затронутые компоненты", чтобы изменения вступили в силу.

Группы ресурсов

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

Группы безопасности сети, брандмауэры и внутренний шлюз

  • Используйте группы безопасности сети (NSG) для блокировки виртуальных сетей.
  • Используйте брандмауэр для обработки политик исходящего доступа.
  • Используйте внутренний шлюз, который не открыт для общедоступного Интернета.

Microsoft Entra ID

Microsoft Entra ID — это облачная служба управления идентификацией и доступом Microsoft.

Политики

  • Отключите политику условного доступа с помощью политики на основе IP-адресов. Для этого требуется включить конечные точки службы в виртуальных сетях, где развернуты кластеры. Если вы используете внешнюю службу для MFA (что-то другое, отличное от идентификатора Microsoft Entra), политика на основе IP-адресов не будет работать.

  • AllowCloudPasswordValidation политика необходима для федеративных пользователей. Так как HDInsight использует имя пользователя и пароль непосредственно для получения маркеров из идентификатора Microsoft Entra, эта политика должна быть включена для всех федеративных пользователей.

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

Группы

  • Всегда разворачивайте кластеры с группой.
  • Используйте идентификатор Microsoft Entra для управления членством в группах (проще, чем пытаться управлять отдельными службами в кластере).

Учетные записи пользователей

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

доменные службы Microsoft Entra

Доменные службы Microsoft Entra предоставляют управляемые доменные службы, такие как присоединение к домену, групповая политика, протокол LDAP и проверка подлинности Kerberos / NTLM, полностью совместимая с Windows Server Active Directory.

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

Выбор правильного номера SKU доменных служб Microsoft Entra

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

Экземпляр доменных служб Microsoft Entra

  • Создайте экземпляр с помощью .onmicrosoft.com domain. Таким образом, не будет нескольких DNS-серверов, обслуживающих домен.
  • Создайте самозаверяющий сертификат для LDAPS и отправьте его в доменные службы Microsoft Entra.
  • Используйте пиринговую виртуальную сеть для развертывания кластеров (если у вас есть несколько команд, развертывающих кластеры HDInsight ESP, это будет полезно). Это гарантирует, что вам не нужно открывать порты (NSG) в виртуальной сети с контроллером домена.
  • Настройте DNS для виртуальной сети правильно (доменное имя доменных служб Microsoft Entra должно разрешаться без записей файлов узлов).
  • Если вы ограничиваете исходящий трафик, убедитесь, что вы ознакомились с поддержкой брандмауэра в HDInsight.

Рассмотрите наборы реплик доменных служб Microsoft Entra

При создании управляемого домена доменных служб Microsoft Entra определяется уникальное пространство имен, а затем развертываются два контроллера домена в выбранном регионе Azure. Такое развертывание контроллеров домена называется набором реплик. Добавление дополнительных наборов реплик обеспечит устойчивость и обеспечит доступность служб проверки подлинности, критически важных для кластеров Azure HDInsight.

Настройка синхронизации пользователей и групп с ограниченным охватом

При включении доменных служб Microsoft Entra для кластера ESP можно синхронизировать всех пользователей и групп из идентификатора Microsoft Entra или групп с областью действия и их участников. Мы рекомендуем выбрать "Ограниченную" синхронизацию для оптимальной производительности.

Синхронизацию в пределах области можно изменить с различными выбранными группами или преобразовать для всех пользователей и групп, если это необходимо. Вы не можете изменить тип синхронизации с "All" на "Scoped", если только вы не удалите и повторно создадите экземпляр доменных служб Microsoft Entra.

Свойства, синхронизированные с идентификатором Microsoft Entra с доменными службами Microsoft Entra

  • Microsoft Entra Connect синхронизируется из локальной среды с идентификатором Microsoft Entra.
  • Доменные службы Microsoft Entra синхронизируются с идентификатором Microsoft Entra.

Доменные службы Microsoft Entra периодически синхронизируют объекты из идентификатора Microsoft Entra. В колонке доменных служб Microsoft Entra на портале Azure отображается состояние синхронизации. Во время каждого этапа синхронизации уникальные свойства могут входить в конфликт и подвергаться переименованию. Обратите внимание на сопоставление свойств из идентификатора Microsoft Entra с доменными службами Microsoft Entra.

Для получения дополнительной информации см. заполнение UserPrincipalName в Microsoft Entra и как работает синхронизация доменных служб Microsoft Entra.

Синхронизация хэша паролей

  • Пароли синхронизируются по-разному от других типов объектов. В Microsoft Entra ID и доменных службах Microsoft Entra синхронизируются только необратимые хэши паролей.
  • Локальный идентификатор Microsoft Entra должен быть включен с помощью AD Connect
  • Синхронизация Microsoft Entra ID с доменными службами Microsoft Entra происходит автоматически (задержки менее 20 минут).
  • Хэши паролей синхронизируются только при изменении пароля. При включении синхронизации хэша паролей все существующие пароли не синхронизируются автоматически, так как они хранятся необратимо. При изменении пароля хэши паролей синхронизируются.

Настроить ежедневный запуск синхронизации LDAP Ambari

Процесс синхронизации новых пользователей LDAP с Ambari автоматически настраивается для выполнения каждый час. Запуск этого задания каждый час может привести к избыточной нагрузке на головные узлы кластера и экземпляр AD. Для повышения производительности рекомендуется изменить скрипт /opt/startup_scripts/start_ambari_ldap_sync.py, который запускает синхронизацию LDAP Ambari один раз в день. Этот скрипт выполняется с помощью задания crontab, и он хранится в каталоге "/etc/cron.hourly/" в головном кластере.

Чтобы запускать его один раз в день, выполните следующие шаги.

  1. ssh до hn0
  2. Переместите скрипт в папку cron daily: sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync
  3. Примените изменение в задании crontab: sudo service cron reload
  4. ssh на hn1 и повторите шаги с 1 по 3

При необходимости можно использовать REST API Ambari для немедленной синхронизации новых пользователей и групп .

Расположение объектов компьютера

Каждый кластер связан с одной организационной единицей. Внутренний пользователь создается в организационной единице. Все узлы присоединены к одной организационной единице.

Средства администрирования Active Directory

Дополнительные сведения см. в разделе "Установка средств управления".

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

Создание кластера постоянно завершается сбоем.

Наиболее распространенные причины:

  • Конфигурация DNS некорректна, узлы кластера не удается присоединить к домену.
  • Группы безопасности сети слишком строги, предотвращая присоединение к домену.
  • Управляемое удостоверение не имеет достаточных разрешений.
  • Имя кластера не является уникальным для первых шести символов (либо с другим динамическим кластером, либо с удаленным кластером).

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

Имя пользователя (UPN)

  • Используйте строчные буквы для всех служб - УЗИ не учитывают регистр в кластерах ESP, но
  • Префикс UPN должен соответствовать как имени участника SAMAccountName, так и в службах домена Microsoft Entra. Сопоставление с полем почты не требуется.

Свойства LDAP в конфигурации Ambari

Полный список свойств Ambari, влияющих на конфигурацию кластера HDInsight, см. в статье Ambari LDAP Authentication Setup.

Создайте keytab(ы) пользователя домена

Все служебные кейтабы создаются автоматически для вас во время процесса создания кластера ESP. Чтобы обеспечить безопасную связь между кластером и другими службами и /или заданиями, которым требуется проверка подлинности, можно создать ключ для имени пользователя домена.

Используйте утилиту ktutil на одной из виртуальных машин кластера, чтобы создать файл ключтаб для Kerberos.


ktutil
ktutil: addent -password -p <username>@<DOMAIN.COM> -k 1 -e aes256-cts-hmac-sha1-96
Password for <username>@<DOMAIN.COM>: <password>
ktutil: wkt <username>.keytab
ktutil: q

Если имя клиента и доменное имя отличаются, необходимо добавить значение SALT с помощью параметра -s. Проверьте страницу часто задаваемых вопросов HDInsight, чтобы определить правильное значение SALT при создании ключтаб Kerberos.

Продление сертификата LDAP

HDInsight автоматически продлевает сертификаты для управляемых удостоверений, используемых для кластеров с корпоративным пакетом безопасности (ESP). Однако существует ограничение при использовании разных управляемых удостоверений для доменных служб Microsoft Entra и ADLS второго поколения, которое может вызвать сбой процедуры обновления. Следуйте приведенным ниже рекомендациям, чтобы убедиться, что мы можем успешно обновить сертификаты:

  • Если вы используете разные управляемые удостоверения для кластеров ADLS Gen2 и доменных служб Microsoft Entra, то каждому из них должны быть назначены роли владельца данных BLOB-объектов хранилища и участника доменных служб HDInsight.
  • Для кластеров HDInsight требуются общедоступные IP-адреса для обновлений сертификатов и другого обслуживания, поэтому все политики, которые запрещают общедоступный IP-адрес в кластере, должны быть удалены.

Дальнейшие действия

  • Last updated on