Безопасность приложений и служб Service Fabric

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

Монолитное приложение, как правило, запускается на одном или нескольких серверах в сети, и в этом случае проще определить открытые порты, интерфейсы API и IP-адрес. Часто существует один периметр или граница, а также одна база данных для защиты. Если эта система скомпрометирована из-за нарушения безопасности или атаки, скорее всего, все в системе будет доступно злоумышленнику. При использовании микрослужб система усложняется. Службы децентрализованы и распределены между несколькими узлами. Они также могут перемещаться с одного узла на другой. При правильной системе безопасности ограничиваются как возможности злоумышленника для получения привилегий, так и объем данных, доступных для отдельной атаки, нарушающей безопасность одной службы. Связь не является внутренней, но происходит через сеть, и существует множество доступных портов и взаимодействий между службами. Знать, как именно и когда взаимодействуют службы, крайне важно для безопасности приложений.

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

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

Часто необходимо, чтобы доступ к ресурсам и API, предоставляемым службой, ограничивался только определенными доверенными пользователями или клиентами. Аутентификация — это процесс надежной проверки подлинности пользователя. Авторизация — это процесс, который позволяет делать интерфейсы API или службы доступными для одних аутентифицированных пользователей, но не для других.

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

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

Если к службам можно получить доступ напрямую, служба проверки подлинности, например Идентификатор Microsoft Entra, или выделенная микрослужба проверки подлинности, выступающая в качестве службы маркеров безопасности (STS), может использоваться для проверки подлинности пользователей. Решения о доверии передаются между службами с помощью маркеров безопасности или файлов cookie.

Для ASP.NET Core основным механизмом аутентификации пользователей является система членства в ASP.NET Core Identity. В ASP.NET Core Identity в хранилище данных, настроенном разработчиком, хранятся сведения о пользователях (включая данные для входа, роли и утверждений). ASP.NET Core Identity поддерживает двухфакторную проверку подлинности. Кроме того, поддерживаются внешние поставщики проверки подлинности, поэтому пользователи могут выполнять вход с помощью существующих процессов проверки подлинности от таких поставщиков, как Microsoft, Google, Facebook или X.

Авторизация

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

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

Ограничение и защита доступа с помощью шлюза API

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

В Service Fabric в качестве шлюза может выступать любая служба без отслеживания состояния, например приложение ASP.NET Core, или другая служба, предназначенная для обработки входящего трафика, например Traefik, Центры событий, Центр Интернета вещей или Управление API Azure.

Служба управления API непосредственно интегрируется с Service Fabric. Это позволяет публиковать интерфейсы API с широким набором правил маршрутизации к внутренним службам Service Fabric. Можно защитить доступ к внутренним службам, предотвращать DOS-атаки с помощью регулирования или проверять ключи API, токены JWT, сертификаты и другие учетные данные. Чтобы узнать больше, прочитайте раздел Общие сведения о Service Fabric со службой управления API Azure.

Управление секретами приложений

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

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

На этой схеме показаны основные этапы процесса управления секретами в приложении Service Fabric:

обзор управления секретами

Этот поток состоит из четырех основных шагов.

  1. Получение сертификата шифрования данных.
  2. Установка сертификата в кластере.
  3. Шифрование значений секретов при развертывании приложения с помощью сертификата и их включение в файл конфигурации Settings.xml службы.
  4. Чтение зашифрованных значений из файла Settings.xml. Для расшифровки используется тот же сертификат шифрования.

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

Пример доступен в разделе Управление секретами приложений.

Защита среды размещения

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

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

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

По умолчанию приложения Service Fabric выполняются под учетной записью, используемой процессом Fabric.exe. Платформа также позволяет запускать приложения под учетной записью локального пользователя или локальной системы, указанной в манифесте приложения. Дополнительные сведения см. в разделе Запуск службы с использованием учетной записи локального пользователя или локальной системы. Можно также выполнить сценарий запуска службы с использованием локальной или системной учетной записи.

При запуске Service Fabric в изолированном кластере Windows службу можно запустить с помощью учетных записей домена Active Directory или групповых управляемых учетных записей службы.

Безопасные контейнеры

Service Fabric предоставляет для служб в контейнере механизм, который обеспечивает доступ к сертификату, установленному на узлах кластера Windows или Linux (версии 5.7 или выше). Этот PFX-файл сертификата можно использовать для аутентификации приложения или службы, а также для безопасного обмена данными с другими службами. Для получения дополнительной информации см. Импорт сертификата в контейнер.

Кроме того, Service Fabric поддерживает групповые управляемые учетные записи службы (gMSA) для контейнеров Windows. Дополнительные сведения см. в разделе Set up gMSA for Windows containers.

Защита взаимодействия со службой

В Service Fabric служба запускается где-то в кластере и обычно распределяется между несколькими виртуальными машинами. Service Fabric предоставляет несколько вариантов защиты взаимодействия со службой.

Можно включить конечные точки HTTPS в веб-службах ASP.NET Core или Java.

Можно установить безопасное подключение между обратным прокси-сервером и службами, которое будет использоваться в качестве защищенного сквозного канала. Подключение к защищенным службам поддерживается, только если обратный прокси-сервер настроен для прослушивания по протоколу HTTPS. Сведения о настройке обратного прокси-сервера см. в статье Обратный прокси-сервер в Azure Service Fabric. В разделе Подключение к защищенной службе с помощью обратного прокси-сервера описывается установление безопасного подключения между обратным прокси-сервером и службами.

Платформа приложений Reliable Services предоставляет несколько готовых стеков взаимодействия и средств, которыми можно воспользоваться для повышения безопасности. Узнайте, как повысить безопасность при использовании удаленного взаимодействия со службой (используя язык C# или Java) либо при использовании WCF.

Включение сертификата конечной точки в приложения Service Fabric

Чтобы настроить сертификат конечной точки приложения, добавьте сертификат, добавив элемент EndpointCertificate вместе с элементом User для основной учетной записи в манифест приложения. По умолчанию основной учетной записью является NetworkService. Это обеспечит управление ACL закрытого ключа сертификата приложения для указанного субъекта.

<ApplicationManifest … >
  ...
  <Principals>
    <Users>
      <User Name="Service1" AccountType="NetworkService" />
    </Users>
  </Principals>
  <Certificates>
    <EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
  </Certificates>
</ApplicationManifest>

Шифрование неактивных данных приложения

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

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

  • Last updated on