Безопасность приложений и служб 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 поддерживает двухфакторную проверку подлинности. Поставщики внешней аутентификации также поддерживаются, поэтому пользователи могут выполнять вход с помощью имеющихся процессов аутентификации от таких поставщиков, как корпорация Майкрософт, Google, Facebook или Twitter.
Авторизация
После аутентификации службы должны предоставить пользователю доступ или определить, какие операции пользователь может выполнять. Этот процесс позволяет службе предоставить интерфейсы 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:
Этот поток состоит из четырех основных шагов.
- Получение сертификата шифрования данных.
- Установка сертификата в кластере.
- Шифрование значений секретов при развертывании приложения с помощью сертификата и их включение в файл конфигурации Settings.xml службы.
- Чтение зашифрованных значений из файла Settings.xml. Для расшифровки используется тот же сертификат шифрования.
В качестве безопасного расположения для хранения сертификатов здесь используется хранилище ключей Azure. С его помощью сертификаты также устанавливаются в кластеры Service Fabric в Azure. Если вы не выполняете развертывание в Azure, то использование хранилища ключей для управления секретами в приложениях Service Fabric не требуется.
Пример доступен в разделе Управление секретами в приложениях 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 running on Service Fabric (Настройка групповой управляемой учетной записи службы для контейнеров Windows).
Защита взаимодействия со службой
Служба Service Fabric, запущенная в кластере 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. Если ваши службы сохраняют данные на подключенный диск данных, вы можете зашифровать этот диск данных, чтобы защитить данные приложения.