Поделиться через

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

  • Статья

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

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

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

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

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

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

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

Ranger

Политики

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

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

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

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

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

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

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

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

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

Иерархическое пространство имен не используется в указанных ниже случаях.

  • Наследуемые разрешения отсутствуют.
  • Единственное действующее разрешение файловой системы — роль Данные хранилища XXXX, назначается пользователю непосредственно на портале Azure.

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

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

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

Если включена проверка подлинности URL-адреса, предусмотрено следующее.

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

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

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

  1. Войдите в пользовательский интерфейс Ambari.
  2. Перейдите к службам>Ranger Configs>Advanced>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 (Идентификатор Microsoft Entra) — это облачная служба управления удостоверениями и доступом Майкрософт.

Политики

  • Отключите политику условного доступа с помощью политики 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). Так обеспечивается отсутствие необходимости открывать порты (группы безопасности сети) в виртуальной сети с контроллером домена.
  • Настройте 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 и доменных службах Microsoft Entra
  • Локальный идентификатор Microsoft Entra должен быть включен с помощью AD Connect
  • Идентификатор Microsoft Entra в службу синхронизации доменных служб 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)

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

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

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

Создание ключей пользователя домена

Все ключи службы создаются автоматически во время процесса создания кластера 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 2-го поколения используются разные управляемые удостоверения, которые могут привести к сбою процесса продления. Следуйте приведенным ниже рекомендациям, чтобы убедиться, что мы можем успешно обновить сертификаты:

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

Следующие шаги