Рекомендации по безопасности Azure Service Fabric

Дополнительные сведения см. в статье Контрольный список безопасности Service Fabric.

Развертывание приложения в Azure — быстрое, удобное и экономичное. Прежде чем развертывать облачное приложение в рабочей среде, ознакомьтесь с нашим списком важных рекомендаций по реализации защищенных кластеров в приложении.

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

Для каждой рекомендации будет предоставлено объяснение следующих аспектов:

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

Сейчас предлагаются следующие рекомендации по обеспечению безопасности в Azure Service Fabric.

• Используйте шаблоны Azure Resource Manager и модуль PowerShell для Service Fabric для создания защищенных кластеров.
• Используйте сертификаты X.509.
• настройке политик безопасности;
• Реализуйте конфигурацию безопасности на основе Reliable Actors.
• Настройте TLS для Azure Service Fabric.
• Обеспечьте изоляцию и безопасность сетей с помощью Azure Service Fabric.
• Настройте интеграцию с Azure Key Vault для повышения безопасности.
• Назначайте пользователей для ролей.
• Что следует учитывать при размещении ненадежных приложений в кластере Service Fabric.

Рекомендации по обеспечению безопасности кластеров

Всегда используйте защищенный кластер:

• реализуйте защиту кластера с помощью сертификатов;
• Предоставьте клиентский доступ (администратор и только для чтения) с помощью идентификатора Microsoft Entra.

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

• Используйте сценарии для создания, развертывания и обновления секретов.
• Сохраните секреты в Azure Key Vault и используйте идентификатор Microsoft Entra для всех других клиентских доступа.
• Требуйте прохождения аутентификации для доступа пользователей к секретам.

Кроме того, учтите следующие особенности конфигурации:

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

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

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

• Безопасность обмена данными между узлами. В этом сценарии обеспечивается защита взаимодействия виртуальных машин и компьютеров в кластере. Такая разновидность защиты гарантирует, что размещать приложения и службы в кластере смогут только пользователи тех компьютеров, которые прошли авторизацию для подключения к кластеру. В этом сценарии кластеры, работающие в Azure, или автономные кластеры, работающие под управлением Windows, могут использовать безопасность на основе сертификатов или систему безопасности Windows для компьютеров Windows Server.
• Безопасность обмена данными между клиентами и узлами. В этом сценарии обеспечивается защита взаимодействия клиента Service Fabric и отдельных узлов в кластере.
• Управление доступом на основе ролей Service Fabric (Service Fabric RBAC): в этом сценарии используются отдельные удостоверения (сертификаты, идентификатор Microsoft Entra ID и т. д.) для каждой роли администратора и клиента пользователя, которая обращается к кластеру. Идентификаторы ролей указываются при создании кластера.

Сведения о настройке автономного кластера Windows см. в статье Параметры конфигурации для автономного кластера Windows.

Используйте шаблоны Azure Resource Manager и модуль PowerShell для Service Fabric для создания защищенного кластера. Пошаговые инструкции по созданию кластера Service Fabric с помощью шаблонов Azure Resource Manager см. в статье Создание кластера Service Fabric в Azure с помощью Azure Resource Manager.

Используйте шаблон Azure Resource Manager:

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

Рассматривайте конфигурацию кластера как код:

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

Многие аспекты жизненного цикла приложения Service Fabric можно автоматизировать. Модуль PowerShell для Service Fabric автоматизирует типовые задачи по развертыванию, обновлению, удалению и тестированию приложений Azure Service Fabric. Также доступны управляемые интерфейсы API и API HTTP для управления приложениями.

Использование сертификата X.509.

Рекомендуется: всегда защищать кластеры с помощью сертификатов X.509 или безопасности Windows. Сведения. Безопасность настраивается только во время создания кластера. Включить защиту после создания кластера невозможно.

Чтобы указать сертификат кластера, задайте для свойства ClusterCredentialType значение X509. Чтобы указать сертификат сервера для внешних подключений, задайте для свойства ServerCredentialType значение X509.

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

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

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

Дополнительные сведения об использовании сертификатов X.509 см. в статье Добавление и удаление сертификатов для кластера Service Fabric в Azure.

Настройка политик безопасности.

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

• Используйте группу или пользователя домена Active Directory. Запустите службу с использованием учетных данных для учетной записи пользователя или группы Active Directory. Не забудьте использовать локально развернутый Active Directory в вашем домене вместо Microsoft Entra ID. Обращайтесь к другим ресурсам в домене, для которых предоставлены разрешения на доступ, с помощью пользователя или группы домена. Например, это могут быть общедоступные файловые ресурсы.

• Назначьте политику безопасности доступа для конечных точек HTTP и HTTPS: укажите свойство SecurityAccessPolicy, чтобы применить политику запуска от имени к службе, когда манифест службы объявляет ресурсы конечной точки с помощью протокола HTTP. Порты, выделенные для конечных точек HTTP, правильно настроены с помощью списков управления доступом для учетной записи пользователя RunAs, под которой выполняется служба. Если политика безопасности не настроена, http.sys не имеет доступа к службе, и вызовы клиента могут заканчиваться ошибками.

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

Реализация конфигурации безопасности на основе Reliable Actors

Реализуемые в Service Fabric Reliable Actors соответствуют паттерну проектирования акторов. Как и в случае с любым другим шаблоном проектирования программного обеспечения, решение о выборе того или иного шаблона зависит от того, соответствует ли он задаче программного обеспечения.

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

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

В Service Fabric акторы реализуются в фреймворке приложения Reliable Actors. Эта платформа основана на актерной модели и построена поверх Service Fabric Reliable Services. Каждая созданная вами служба Reliable Actor представляет собой секционированную надежную службу с отслеживанием состояния.

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

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

Настройка TLS для Azure Service Fabric

Процесс аутентификации сервера аутентифицирует конечные точки управления кластера в клиенте управления. Затем клиент управления определяет, что он взаимодействует с реальным кластером. Кроме того, этот сертификат предоставляет поддержку TLS для HTTPS-интерфейса API управления и для Service Fabric Explorer при подключении по протоколу HTTPS. Необходимо получить имя личного домена для кластера. При запросе сертификата из центра сертификации имя субъекта сертификата должно совпадать с именем личного домена, используемого для кластера.

Чтобы настроить протокол TLS для приложения, сначала нужно получить TLS/SSL-сертификат, подписанный центром сертификации. Центром сертификации называется доверенная третья сторона, которая выдает сертификаты для обеспечения безопасности TLS. Если у вас еще нет TLS/SSL-сертификата, нужно получить его в компании, продающей TLS/SSL-сертификаты.

Для TLS/SSL-сертификатов в Azure действуют следующие требования:

• Сертификат должен содержать закрытый ключ.

• Сертификат должен быть создан для обмена ключами, которые можно экспортировать в файл обмена личной информацией (PFX-файл).

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

  • Получите имя личного домена для доступа к облачной службе.
  • Запросите в центре сертификации сертификат с именем субъекта, соответствующим имени пользовательского домена вашей службы. Например, если ваше пользовательское доменное имя contoso.com, то имя субъекта сертификата из ЦС должно быть .contoso.com или www.contoso.com.

  Примечание.

  Вы не сможете получить от центра сертификации TLS/SSL-сертификат для домена cloudapp.net.

• Сертификат должен использовать как минимум 2048-разрядное шифрование.

Протокол HTTP является небезопасным и подвержен атакам перехвата. Данные, передаваемые по протоколу HTTP, отправляются как обычный текст из веб-браузера на веб-сервер или между другими конечными точками. Злоумышленники могут перехватывать и просматривать конфиденциальные данные, отправленные по протоколу HTTP, такие как сведения о кредитной карте и учетные данные. При отправке или публикации данных с помощью браузера по протоколу HTTPS протокол SSL обеспечивает шифрование конфиденциальной информации и ее защиту от перехвата.

Дополнительные сведения о TLS/SSL-сертификатах см. в статье Настройка TLS для приложения в Azure.

Обеспечение изоляции и безопасности сетей с помощью Azure Service Fabric

Рекомендуется настроить безопасный кластер с сетевой изоляцией. Сведения. Использование шаблонов Azure Resource Manager для настройки защищенного кластера с 3 типами узлов. Для контроля входящего и исходящего сетевого трафика используйте шаблон и группы безопасности сети.

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

Дополнительные сведения см. в разделе Общие сценарии сетевого взаимодействия в Azure Service Fabric.

Настройка Azure Key Vault для обеспечения безопасности

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

Сертификат устанавливает связь между Azure Key Vault, кластером Service Fabric и поставщиком ресурсов, который использует сертификаты. При создании кластера сведения о связи сертификата сохраняются в хранилище ключей.

Существуют два основных действия по настройке хранилища ключей.

1. Создайте группу ресурсов специально для хранилища ключей.

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

2. Создайте хранилище ключей в новой группе ресурсов.

   Хранилище ключей должно быть включено для развертывания. В этом случае поставщик вычислительных ресурсов сможет получить сертификаты из хранилища и установить их на экземплярах виртуальных машин.

Дополнительные сведения о настройке хранилища ключей см. в статье о том, что такое Azure Key Vault?

Назначение пользователей ролям

Рекомендуется назначить пользователей ролям, поддерживаемым Service Fabric. Подробные сведения. После создания приложений для представления кластера назначьте пользователей ролям только для чтения и администратора. Эти роли можно назначить с помощью портала Azure.

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

Что следует учитывать при размещении ненадежных приложений в кластере Service Fabric

См. Размещение недоверенных приложений в кластере Service Fabric.

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

• Контрольный список по безопасности Service Fabric
• Настройка среды разработки Service Fabric.
• Узнайте о вариантах поддержки Service Fabric.