Сценарии защиты кластера Service Fabric

Статья
06/01/2023

Кластер Azure Service Fabric — это ресурс, владельцем которого вы являетесь. Вам следует защитить кластеры, чтобы к ним не смогли подключиться неавторизованные пользователи. Защита кластера особенно важна при выполнении на нем производственных рабочих нагрузок. Вы можете создать незащищенный кластер, что позволит анонимным пользователям подключаться к нему (если конечные точки управления им общедоступны через Интернет). Незащищенные кластеры нельзя использовать для выполнения производственных задач.

В этой статье содержится обзор сценариев безопасности для кластеров Azure и изолированных кластеров, а также приведены различные технологии их реализации:

безопасность обмена данными между узлами;
безопасность обмена данными между клиентами и узлами;
Управление доступом на основе ролей Service Fabric

безопасность обмена данными между узлами;

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

Diagram of node-to-node communication

Кластеры, работающие в Azure, и автономные кластеры, работающие под управлением Windows, могут использовать безопасность на основе сертификатов или безопасность Windows для компьютеров Windows Server.

Безопасность обмена данными между узлами на основе сертификатов

Service Fabric использует сертификаты сервера X.509, которые указываются как часть конфигурации типа узла при создании кластера. Безопасность на основе сертификатов можно настроить с помощью портала Azure, шаблона Azure Resource Manager или автономного шаблона JSON. Краткий обзор этих сертификатов и способа их получения или создания приведен в конце этой статьи.

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

Чтобы узнать, как в Azure в кластере настроить безопасность на основе сертификатов, ознакомьтесь со статьей Создание кластера Service Fabric в Azure с помощью Azure Resource Manager.

Чтобы узнать, как в кластере настроить безопасность на основе сертификатов для изолированного кластера Windows Server, ознакомьтесь со статьей Защита автономного кластера под управлением Windows с помощью сертификатов X.509.

Безопасность обмена данными между узлами Windows

Примечание.

Проверка подлинности Windows основана на протоколе Kerberos. NTLM не поддерживается в качестве типа проверки подлинности.

По возможности используйте проверку подлинности сертификата X.509 для кластеров Service Fabric.

Чтобы узнать, как настроить защиту Windows для изолированного кластера Windows Server, ознакомьтесь со статьей Защита изолированного кластера под управлением Windows с помощью системы безопасности Windows.

безопасность обмена данными между клиентами и узлами;

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

Diagram of client-to-node communication

Кластеры, работающие в Azure, и автономные кластеры, работающие в Windows, могут использовать безопасность сертификатов либо Безопасность Windows, хотя при возможности рекомендуется использовать проверку подлинности по сертификату X.509.

Безопасность обмена данными между клиентами и узлами на основе сертификатов

При создании кластера безопасность обмена данными между клиентами и узлами на основе сертификатов можно настроить с помощью портала Azure, шаблона Resource Manager или автономного шаблона JSON. Чтобы создать сертификат, необходимо указать сертификат клиента администратора или пользователя. Мы рекомендуем, чтобы эти сертификаты отличались от основного и дополнительного сертификатов, указанных для защиты обмена данными между узлами. Сертификаты кластера имеют те же права, что и сертификаты администратора клиента. Однако согласно рекомендациям по безопасности они должны использоваться только кластером, а не пользователями с правами администратора.

Клиенты, подключающиеся к кластеру с помощью сертификата администрирования, получают полный доступ к возможностям управления. Клиенты, подключающиеся к кластеру с помощью сертификата клиента только для чтения, получают доступ только для чтения к возможностям управления. Эти сертификаты используются для Service Fabric RBAC, о которых будет сказано дальше.

Безопасность Microsoft Entra на клиенте в Azure

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

Для кластеров, работающих в Azure, можно также использовать идентификатор Microsoft Entra для защиты доступа к конечным точкам управления. Кластеры Service Fabric предлагают несколько точек входа для управления функциями кластеров, включая веб-интерфейс Service Fabric Explorer и Visual Studio. В результате для управления доступом к кластеру создается два приложения Microsoft Entra: одно веб-приложение и одно собственное приложение. Сведения о создании необходимых артефактов Microsoft Entra и их заполнении при создании кластера см. в разделе "Настройка идентификатора Microsoft Entra для проверки подлинности клиентов".

Управление доступом на основе ролей Service Fabric

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

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

Задайте клиентские роли администратора и клиента во время создания кластера. Назначение ролей путем предоставления отдельных удостоверений (например, с помощью сертификатов или идентификатора Microsoft Entra) для каждого типа роли. Дополнительные сведения о параметрах управления доступом по умолчанию и их изменении см. в статье Контроль доступа на основе ролей Service Fabric для клиентов Service Fabric.

Сертификаты X.509 и Service Fabric

Цифровые сертификаты X.509 обычно используются для проверки подлинности клиентов и серверов, а также для шифрования и цифровой подписи сообщений. Service Fabric использует сертификаты X.509 для защиты кластера и обеспечения функций безопасности приложений. Дополнительные сведения о цифровых сертификатах X.509 см. в статье Работа с сертификатами. Key Vault используется для управления сертификатами кластеров Service Fabric в Azure.

Необходимо учитывать следующие важные моменты.

Чтобы создать сертификаты для кластеров, выполняющих производственные рабочие нагрузки, используйте правильно настроенную службу сертификации Windows Server или службу из утвержденного центра сертификации (ЦС).
Никогда не используйте в рабочей среде какие-либо временные или тестовые сертификаты, созданные с помощью таких инструментов, как MakeCert.exe.
Самозаверяющий сертификат вы можете использовать только в тестовом кластере. Не используйте его в рабочей среде.
При создании отпечатка сертификата обязательно создайте отпечаток SHA1. SHA1 используется при настройке отпечатков сертификатов клиента и кластера.

Сертификат кластера и сервера (обязательно)

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

Аутентификация в кластере позволяет аутентифицировать обмен данными между узлами для федерации кластера. Только узлы, которые могут подтвердить свою подлинность с помощью этого сертификата, могут присоединиться к кластеру. Аутентификация сервера позволяет аутентифицировать конечные точки управления кластером в клиенте управления, чтобы он "знал", что обращается к настоящему кластеру, а не к "незаконному посреднику". Кроме того, этот сертификат предоставляет поддержку TLS для HTTPS-интерфейса API управления и для Service Fabric Explorer при подключении по протоколу HTTPS. Одна из начальных проверок при проверке подлинности узла — сопоставление значения общего имени в поле Субъект. В списке разрешенных общих имен должно быть это общее имя или одно из альтернативных имен субъекта сертификатов.

Сертификат должен отвечать приведенным ниже требованиям.

Сертификат должен содержать закрытый ключ. Эти сертификаты обычно имеют расширения PFX или PEM.
Сертификат должен быть создан для обмена ключами, которые можно экспортировать в файл обмена личной информацией (PFX-файл).
Имя субъекта сертификата должно совпадать с доменным именем, которое используется для получения доступа к кластеру Service Fabric. Это необходимо, чтобы предоставить TLS-протокол конечной точке управления HTTPS в кластере и Service Fabric Explorer. Не удается получить TLS/SSL-сертификат от центра сертификации (ЦС) в домене *.cloudapp.azure.com. Необходимо получить имя личного домена для кластера. При запросе сертификата из ЦС имя субъекта сертификата должно совпадать с именем личного домена, используемого для кластера.

Необходимо учитывать также следующие факторы.

Поле Субъект может содержать несколько значений, каждое из которых содержит сокращение в виде префикса, определяющее тип значения. Обычно для сокращения используется префикс CN (для общего имени), например CN = www.contoso.com.
Поле Субъект может быть пустым.
Если необязательное поле Альтернативное имя субъекта заполнено, его значение должно содержать общее имя сертификата и альтернативное имя субъекта. Эти имена вводятся как значения DNS-имени. Чтобы узнать о создании сертификатов с альтернативными именами субъектов, ознакомьтесь со статьей Как добавить дополнительное имя субъекта сертификата безопасного LDAP.
Поле Назначения для сертификата должно содержать соответствующее значение, например Проверка подлинности сервера или Проверка подлинности клиента.

Сертификаты приложения (необязательно)

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

шифрование и расшифровка значений конфигурации приложений;
шифрование данных между узлами во время репликации.

Концепция создания безопасного кластер в Linux или Windows ничем не отличается.

Сертификаты проверки подлинности клиента (необязательно)

Для клиентских операций со стороны пользователя или администратора может быть указано любое количество дополнительных сертификатов. Клиент может использовать такие сертификаты, когда требуется взаимная проверка подлинности. Как правило, сертификаты клиентов не выдаются сторонними центрами сертификации. В свою очередь, личное хранилище текущего местоположения пользователя обычно содержит сертификаты клиентов, размещенные там корневым центром. Сертификат должен иметь значение предполагаемой области примененияАутентификация клиента.

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