Share via

X.509 Проверка подлинности на основе сертификата в кластерах Service Fabric

  • Статья

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

Темы, рассматриваемые в этой статье:

  • Основы аутентификации на основе сертификата в iOS
  • Удостоверения и соответствующие роли
  • Правила конфигурации сертификата
  • Устранение неполадок и часто задаваемые вопросы

Основы аутентификации на основе сертификата в iOS

Краткое напоминание: в сфере безопасности сертификат — это инструмент, который предназначен для привязки сведений об объекте (теме) к паре асимметричных криптографических ключей, и поэтому представляет собой основную структуру шифрования общедоступных ключей. Ключи, представленные сертификатом, можно использовать для защиты данных или для установления личности владельцев ключей; при использовании в сочетании с системой инфраструктуры общедоступных ключей (PKI) сертификат может представлять дополнительные признаки субъекта, например владение интернет-доменом, или определенные привилегии, предоставленные ему издателем сертификата (его называют центром сертификации, или ЦС). Обычно сертификаты поддерживают криптографический протокол TLS, что обеспечивает безопасную связь по компьютерной сети. В частности, клиент и сервер используют сертификаты для обеспечения конфиденциальности и целостности связи, а также для проведения совместной проверки подлинности.

В Service Fabric базовый уровень кластера (федерации) также строится на основе протокола TLS (а также других протоколов), что обеспечивает надежную и безопасную сеть участвующих узлов. Подключения к кластеру с помощью API клиента Service Fabric также используют TLS для защиты трафика, а также для удостоверений сторон. В частности, если сертификат используется для аутентификации в Service Fabric, его можно использовать для проверки следующих утверждений: а) сторона, представляющая учетные данные сертификата, обладает закрытым ключом сертификата, б) хэш-код SHA-1 сертификата (отпечаток) соответствует объявлению, включенному в определение кластера, или c) различающееся общее имя сертификата соответствует объявлению, включенному в определение кластера, и издатель сертификата известен или является доверенным лицом.

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

В следующих разделах подробно объясняется, как среда выполнения Service Fabric использует и проверяет сертификаты для обеспечения безопасности кластеров.

Удостоверения и соответствующие роли

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

  • Среда выполнения Service Fabric, которая называется "система" — это набор служб, предоставляющих абстракции и функциональные возможности, которые представляют кластер. При ссылке на взаимодействие между экземплярами системы в кластере используется термин "идентификатор кластера". При ссылке на кластер в качестве получателя или цели трафика извне мы будем использовать термин "идентификатор сервера".
  • Ведущие приложения, которые далее называются "приложения", — это код, предоставленный владельцем кластера, который координируется и выполняется в кластере.
  • Клиенты — сущности, которым разрешено подключаться к кластеру и выполнять в нем функции в соответствии с конфигурацией кластера. Мы различаем два уровня привилегий — "пользователь" и "администратор" соответственно. Клиент "пользователь" ограничен в основном операциями с доступом только для чтения (но не всеми функциями, которые доступны только для чтения), в то время как клиент "администратор" имеет неограниченный доступ к функциям кластера. (Дополнительные сведения см. в разделе Роли безопасности в кластере Service Fabric.)
  • (Только в Azure) Службы Service Fabric, которые координируют и предоставляют элементы управления для работы и управления кластерами Service Fabric; они называются просто "службами". В зависимости от среды "служба" может ссылаться на поставщика ресурсов Azure Service Fabric или других поставщиков ресурсов, владельцем и оператором которых является группа Service Fabric.

В безопасном кластере каждую из этих ролей можно настраивать с собственным отдельным идентификатором, заявленным как сопряжение предварительно заданного имени роли и соответствующих учетных данных. Service Fabric поддерживает объявление учетных данных в виде сертификатов или субъект-служб на основе домена. (Удостоверения на основе Windows или Kerberos также поддерживаются, но выходят за рамки область этой статьи; см. сведения о безопасности на основе Windows в кластерах Service Fabric.) В кластерах Azure роли клиентов также могут быть объявлены в качестве удостоверений на основе идентификаторов Microsoft Entra.

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

Правила конфигурации сертификата

Правила проверки

Параметры безопасности кластера Service Fabric описывают, в принципе, следующие аспекты:

  • Тип проверки подлинности; это неизменяемая характеристика кластера — время создания. Примеры таких параметров: "ClusterCredentialType", "ServerCredentialType"; допустимыми значениями являются "нет", "x509" или "windows". Эта статья посвящена проверке подлинности типа x509.
  • Правила валидации (проверки подлинности); эти параметры настраиваются владельцем кластера и описывают, какие учетные данные будут допускаться для данной роли. Ниже подробно рассматриваются примеры.
  • Параметры, используемые для настройки или простого изменения результатов проверки подлинности; для примера можно привести флажки, которые ограничивают принудительное применение списков отзыва сертификатов и т. д или отменяют это ограничение.

Примечание.

Ниже приведены примеры конфигурации кластера: это фрагменты манифеста кластера в формате XML, который представляет собой наиболее глубоко обработанный формат, непосредственно поддерживающий функции Service Fabric, описанные в этой статье. Эти же параметры могут быть непосредственно выражены в представлениях JSON определения кластера, будь то автономный манифест кластера json или шаблон управления ресурсами Azure.

Правило проверки сертификата включает в себя следующие элементы:

  • соответствующая роль: клиент, клиент администрирования (привилегированная роль);
  • учетные данные, допустимые для роли, объявленные либо по отпечатку, либо по общему имени субъекта;

декларации подтверждения сертификатов на основе отпечатка.

В случае правил проверки на основе отпечатка учетные данные, представленные вызывающей стороной, которая запрашивает подключение к кластеру, проверяются следующим образом:

  • учетные данные — это действительный сертификат с правильным форматом: можно построить цепочку, сигнатуры соответствуют;
  • сертификат с неистекшим сроком действия (не ранее < = теперь < не позднее);
  • хэш-код SHA-1 сертификата соответствует объявлению при сравнении строк без учета регистра и всех пробелов.

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

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

<Section Name="Security">
  <Parameter Name="ClusterCredentialType" Value="X509" />
  <Parameter Name="ServerAuthCredentialType" Value="X509" />
  <Parameter Name="AdminClientCertThumbprints" Value="d5ec...4264" />
  <Parameter Name="ClientCertThumbprints" Value="7c8f...01b0" />
  <Parameter Name="ClusterCertThumbprints" Value="abcd...1234,ef01...5678" />
  <Parameter Name="ServerCertThumbprints" Value="ef01...5678" />
</Section>

Каждая из приведенных выше записей ссылается на определенный идентификатор, как описано выше. Для каждой записи также можно указать несколько значений в виде списка строк, разделенных запятой. В этом примере после успешной проверки входящих учетных данных образец сертификата с отпечатком SHA-1 "d5ec... 4264" получит роль "администратор". Наоборот, вызывающей стороне с сертификатом "7c8f... 01b0" будет предоставлена роль "пользователь", ограниченная в основном операциями с доступом только для чтения. Если вызывающая сторона представляет сертификат с отпечатком "abcd... 1234" или "ef01... 5678", он будет допущен в качестве однорангового узла в кластере. Наконец, клиент, подключающийся к конечной точке управления кластера, будет ожидать, что отпечаток сертификата сервера будет "ef01... 5678".

Как упоминалось выше, Service Fabric устанавливает условия приема сертификатов с истекшим сроком действия. Это связано с тем, что срок действия сертификатов ограничен, а если они объявлены по отпечатку (который относится к определенному экземпляру сертификата), то истечение срока действия сертификата приведет либо к сбою подключения к кластеру, либо к полному свертыванию кластера. Можно забыть повернуть сертификат, закрепленный отпечатком, или не сделать этого по небрежности. К сожалению, восстановление из такой ситуации затруднено.

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

  <Section Name="Security">
    <Parameter Name="AcceptExpiredPinnedClusterCertificate" Value="true" />
  </Section>

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

Декларации подтверждения сертификатов на основе общего имени

Объявления на основе общего имени происходят в одной из следующих форм:

  • (только) общее имя субъекта;
  • общее имя субъекта с закреплением издателя сертификата.

Сначала рассмотрим фрагмент из манифеста кластера, который демонстрирует оба стиля объявления.

    <Section Name="Security/ServerX509Names">
      <Parameter Name="server.demo.system.servicefabric.azure-int" Value="" />
    </Section>
    <Section Name="Security/ClusterX509Names">
      <Parameter Name="cluster.demo.system.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

Объявления ссылаются на удостоверения сервера и кластера соответственно. Обратите внимание, что декларации, основанные на объявлениях общего имени (CN и cn), описаны в отдельных разделах манифеста кластера, отдельно от стандартных объявлений "Безопасность". В обоих объявлениях "имя" представляет собой различаемое общее имя субъекта сертификата, а поле "Значение" представляет ожидаемого издателя сертификата, как показано ниже:

  • в первом случае в объявлении говорится, что ожидается, что элемент общего имени различаемого субъекта сертификата сервера будет соответствовать строке "server.demo.system.servicefabric.azure-int"; пустое поле "Значение" обозначает ожидание того, что корень цепочки сертификатов является доверенным на узле или компьютере, где проверяется сертификат сервера; в Windows это означает, что сертификат может быть связан по цепочке с любым сертификатом, установленным в хранилище доверенных корневых ЦС;
  • во втором случае в объявлении указывается, что тот, кто предоставляет сертификат, принимается в качестве однорангового узла в кластере, если общее имя сертификата совпадает со строкой "cluster.demo.sysTEM. servicefabric. Azure-int", а отпечаток непосредственного издателя сертификата соответствует одной из записей с разделителями-запятыми в поле "Значение". (Этот тип правила называется общим именем с закреплением издателя сертификата).

В обоих случаях построена цепочка сертификатов, и ожидается, что она будет без ошибок. То есть, ошибки отзыва, частичной цепочки или ошибки доверия с недействительным временем считаются неустранимыми, и сертификат не пройдет проверку. Закрепление издателя сертификата приведет к тому, что состояние "неподтвержденного корня" будет считаться некритической ошибкой. Это более строгая форма проверки, хотя она выглядит не так, поскольку она позволяет владельцу кластера ограничить набор авторизованных/допущенных издателей сертификатов собственной инфраструктурой закрытых ключей (PKI).

После того как цепочка сертификатов будет построена, она будет проверена согласно стандартной политике TLS/SSL с объявленным субъектом в качестве удаленного имени. Сертификат будет считаться соответствующим, если общее имя его субъекта или другие имена его субъектов совпадают с объявлением CN из манифеста кластера. В этом случае поддерживаются подстановочные знаки, совпадения строк не зависят от регистра.

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

Для завершения примера на следующем фрагменте показано объявление сертификатов клиентов по общему имени.

    <Section Name="Security/AdminClientX509Names">
      <Parameter Name="admin.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>
    <Section Name="Security/ClientX509Names">
      <Parameter Name="user.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

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

Примечание.

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

  • следует преимущественно закреплять издателей сертификатов, чтобы полагаться на доверенные корневые элементы;
  • избегайте смешивания издателей сертификатов из разных PKI;
  • убедитесь, что в объявлении сертификатов указаны все ожидаемые издатели сертификатов. Один несоответствующий издатель приведет к сбою проверки;
  • убедитесь, что конечные точки политики сертификатов PKI доступны для обнаружения, имеются в наличии и достижимы. Это означает, что конечные точки AIA, CRL или OCSP объявляются в сертификате листового узла и доступны, чтобы можно было завершить создание цепочки сертификатов.

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

Правила презентации

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

Как и в случае с правилами проверки, в правилах презентации указывается роль и связанное с ней объявление учетных данных, либо через отпечаток, либо через общее имя. В отличие от правил проверки, для объявлений на основе общих имен нет условий закрепления издателя сертификата; это обеспечивает большую гибкость и повышение производительности. Правила презентации объявляются в разделе(-ах) "Тип узла" манифеста кластера для каждого отдельного типа узла. Параметры разделены по разделам безопасности кластера, чтобы каждый тип узла мог иметь полную конфигурацию в одном разделе. В кластерах Azure Service Fabric объявления сертификатов типа узла по умолчанию имеют соответствующие настройки в разделе "Безопасность" определения кластера.

Декларации презентации сертификатов на основе отпечатка.

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

Рассмотрим следующий фрагмент из манифеста кластера.

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindByThumbprint" X509FindValue="cc71...1984" X509FindValueSecondary="49e2...19d6" X509StoreName="my" Name="ClusterCertificate" />
        <ServerCertificate X509FindValue="cc71...1984" Name="ServerCertificate" />
        <ClientCertificate X509FindValue="cc71...1984" Name="ClientCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

Элемент ClusterCertificate демонстрирует полную схему, включая необязательные параметры (X509FindValueSecondary) или параметры с соответствующими значениями по умолчанию (X509StoreName); другие объявления имеют сокращенную форму. Приведенное выше объявление сертификата кластера говорит о том, что параметры безопасности узлов типа "nt1vm" инициализированы с сертификатом cc71.. 1984 в качестве основного и сертификатом 49e2..19d6 в качестве дополнительного. Ожидается, что оба сертификата находятся в хранилище сертификатов LocalMachine'My' (или эквивалентный путь в Linux var/lib/sfcerts).

Декларации презентации сертификатов на основе общего имени

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

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindBySubjectName" X509FindValue="demo.cluster.azuredocpr.system.servicefabric.azure-int" Name="ClusterCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

Для любого типа объявления узел Service Fabric будет считывать конфигурацию при запуске, находить и загружать указанные сертификаты и сортировать их в порядке убывания атрибута NotBefore (Не ранее); просроченные сертификаты игнорируются, а первый элемент списка выбирается в качестве учетных данных клиента для любой попытки подключения к Service Fabric, предпринятой этим узлом. (По сути, Service Fabric предпочитает последний выданный сертификат.)

Примечание.

До версии 7.2.445 (7.2 CU4) в среде выполнения Service Fabric выбран самый длительный срок действия сертификата (сертификат с последним свойством NotAfter)

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

Прочие параметры конфигурации сертификата.

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

Как упоминалось, проверка сертификата всегда подразумевает построение и оценку цепочки сертификата. Для сертификатов, выдаваемых ЦС, этот очевидно простой вызов API ОС обычно включает несколько исходящих обращений к различным конечным точкам выдачи PKI, кэширование ответов и так далее. Учитывая распространенность вызовов для проверки сертификата в кластере Service Fabric, любые проблемы в конечных точках PKI могут привести к снижению доступности кластера или полному сбою. Исходящие вызовы невозможно подавить (см. об этом ниже в разделе Часто задаваемые вопросы), но для маскировки ошибок проверки, вызванных сбоем звонков CRL, можно использовать следующие параметры.

  • CrlCheckingFlag — в разделе "Безопасность", строка, преобразованная в UINT. Значение этого параметра используется в Service Fabric для маскировки ошибок состояния цепочки сертификатов путем изменения способа построения цепочки. Он передается в вызов Win32 CryptoAPI CertGetCertificateChain в качестве параметра "dwFlags" и может быть установлен в любом допустимом сочетании флажков, принимаемых функцией. Значение 0 обязывает среду выполнения Service Fabric игнорировать все ошибки статуса доверия — это не рекомендуется, так как использование этого значения может представлять значительную угрозу безопасности. Значение по умолчанию — 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

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

Использование: мы рассмотрим пример, который принудительно вызывает проверку отзыва для доступа только к кэшированным URL-адресам. Предположение:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

тогда объявление в манифесте кластера становится:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError — в разделе "Безопасность" логическое значение по умолчанию "false" (ложное). Представляет собой ярлык для отключения состояния ошибки при построении цепочки "отзыв оффлайн" (или статуса последующей ошибки проверки политики цепочки).

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

Как использовать:

  <Section Name="Security">
    <Parameter Name="IgnoreCrlOfflineError" Value="true" />
  </Section>

другие важные параметры (все в разделе "Безопасность"):

  • AcceptExpiredPinnedClusterCertificate — обсуждается в разделе, посвященном проверке сертификата на основе отпечатков; позволяет принимать просроченные самозаверяющие сертификаты кластеров.
  • CertificateExpirySafetyMargin — интервал, выраженный в минутах до даты окончания срока действия сертификата NotAfter (не позднее), в течение которого считается, что для сертификата существует риск окончания срока действия. Service Fabric отслеживает сертификат(-ы) кластера и периодически издает отчеты о работоспособности и остаточной доступности. В интервале безопасности эти отчеты о состоянии работоспособности имеют более высокий статус "предупреждение". Длительность по умолчанию — 30 дней.
  • CertificateHealthReportingInterval — управляет частотой отчетов о работоспособности, которые касаются остаточного срока действия сертификатов кластера. Отчеты будут издаваться только один раз за этот интервал. Значение выражается в секундах, по умолчанию 8 часов.
  • EnforcePrevalidationOnSecurityChanges — логическое значение, управляет поведением обновления кластера при обнаружении изменений параметров безопасности. Если задано значение true, то при обновлении кластера будет предпринята попытка убедиться, что по крайней мере один из сертификатов, соответствующих любому из правил представления, может передать соответствующее правило проверки. Предварительная проверка выполняется до применения новых параметров к любому узлу, но только на узле, где размещается первичная реплика службы диспетчера кластеров на момент запуска обновления. На момент написания этой статьи значение параметра по умолчанию false (ложный), он будет иметь значение true (истинный) для новых кластеров Azure Service Fabric с версией среды исполнения 7.1 и выше.

Комплексный сценарий (примеры)

Мы рассмотрели правила объявления, правила проверки и настройки флажков, но как все это работает в комплексе? В этом разделе мы рассмотрим два комплексных примера, демонстрирующих использование параметров безопасности для обновления безопасных кластеров. Обратите внимание, что эта статья не является полным справочником по правильному управлению сертификатами в Service Fabric, см. дополнительную статью по этой теме.

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

Помните, что в кластере Service Fabric обновление проходит через несколько (до 5) "доменов обновления" или ДО. В настоящее время обновляются или меняются только узлы в текущем ДО, и обновление будет продвигаться к следующему ДО, только если доступность кластера допускает это. (Подробнее см. статью Модернизация и обновление кластеров Azure Service Fabric и другие статьи по этой теме.) Изменения сертификата и безопасности особенно опасны, так как они могут отделять узлы от кластера или угрожать потере кворума для кластера.

Для описания параметров безопасности узла мы будем использовать следующую нотацию:

Nk: {P:{TP=A}, V:{TP=A}}, где:

  • "NK" представляет узел в домене обновления k
  • "P" представляет текущие правила презентации узла (предполагается, что мы ссылаемся только на сертификаты кластера)
  • "V" представляет текущие правила проверки узла (только сертификат кластера)
  • "TP=A" представляет собой объявление на основе отпечатков (ТР), а "A" — это отпечаток сертификата
  • "CN=B" представляет собой общее объявление на основе имен (CN), а "В" — это общее имя субъекта сертификата.

Поворот сертификата кластера, объявленного по отпечаткам

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

  • начальное состояние: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} — кластер неактивен, все узлы имеют общую конфигурацию
  • после завершения домена обновления 0: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} — узлы в ДО0 будут представлять сертификат A и принимать сертификаты A или B; все остальные узлы представляют и принимают только сертификат A
  • после завершения последнего домена обновления: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} — все узлы имеют сертификат A, все узлы принимают сертификат A или B

На этом этапе кластер снова находится в равновесии, и может начаться второй этап настройки параметров обновления и изменения безопасности:

  • после завершения домена обновления 0: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} — узлы в ДО0 начнут представлять сертификат B, который принимается всеми другими узлами в кластере.
  • после завершения последнего домена обновления: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} — все узлы перешли на представление сертификата B. Сертификатом A теперь можно прекратить пользоваться или удалить его из определения кластера с последующим набором обновлений.

Преобразование кластера от объявления сертификатов на основе отпечатка в объявления сертификатов на основе общих имен

Изменение типа объявления сертификата (от отпечатка к общему имени) будет происходить подобным образом по тому же шаблону, который описан выше. Обратите внимание, что правила проверки позволяют объявлять сертификаты для данной роли как по отпечатку, так и по общему имени в одном и том же определении кластера. Однако правила презентации, напротив, позволяют объявления только в одной форме. К сожалению, безопасный подход к преобразованию сертификата кластера из отпечатка к общему имени — это введение сначала целевого сертификата по отпечатку, а затем изменение способа объявления сертификата на объявление по общему имени. В следующем примере предполагается, что отпечаток "A" и общее имя субъекта "B" относятся к одному и тому же сертификату.

  • начальное состояние: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} — кластер неактивен, все узлы имеют общую конфигурацию; A является первичным отпечатком сертификата.
  • после завершения домена обновления 0: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} — узлы в ДО0 будут представлять сертификат A и принимать сертификаты либо с отпечатком A, либо с общим именем B; все остальные узлы представляют и принимают только сертификат A
  • после завершения последнего домена обновления: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} — все узлы имеют сертификат A, все узлы принимают сертификат A (TP) или B (CN)

На этом этапе можно перейти к изменению правил презентации с последующим обновлением:

  • после завершения домена обновления 0: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} — узлы в ДО0 представляют сертификат B, обнаруженный CN, и принимают сертификаты либо с отпечатком A, либо с общим именем B; все остальные узлы представляют и принимают сертификат A, выбранный по отпечатку
  • после завершения последнего домена обновления: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{CN=B}, V:{TP=A, CN=B}} — все узлы представляют сертификат B, найденный CN, все узлы принимают либо сертификат A (TP), либо сертификат B (CN).

Завершение этапа 2 также означает переход кластера к сертификатам на основе общих имен. При последующем обновлении кластера можно удалить объявления о проверке на основе отпечатков.

Примечание.

В кластерах Azure Service Fabric указанные выше процессы координируются поставщиком ресурсов Service Fabric; владелец кластера по-прежнему отвечает за предоставление сертификатов в кластер в соответствии с указанными правилами (презентацией или проверкой) и может вносить изменения в разные этапы.

В отдельной статье мы обратимся к теме управления сертификатами и их предоставления в кластере Service Fabric.

Устранение неполадок и часто задаваемые вопросы

Устранить проблемы, связанные с проверкой подлинности в кластерах Service Fabric, непросто, но мы надеемся, что вам помогут следующие советы и подсказки. Самый простой способ начать исследование — изучить журналы событий Service Fabric на узлах кластера: не только узлы, которые показывают симптомы, но и узлы, которые работоспособны, но не могут подключиться к одному из своих соседей. На Windows события значимости обычно регистрируются соответственно в каналах "Приложения и службы\Microsoft-ServiceFabric\Админ" или "Рабочие". Иногда может быть полезно включить ведение журнала CAPI2, чтобы получить дополнительные сведения о проверке сертификата, получении списка CRL/CTL и т. д. (Не забудьте отключить его после завершения воспроизведения, он может быть довольно подробным.)

Типичные симптомы, которые проявляются в кластере, где есть проблемы с проверкой подлинности:

  • узлы не работают или циклически перезапускаются;
  • попытки подключения отклоняются;
  • попытки подключения отклоняются из-за истечения времени ожидания.

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

  • Узлы могут обмениваться сообщениями, но не могут подключиться. Возможной причиной прекращения попыток подключения может быть ошибка "Сертификат не совпадает" — одна из сторон соединения Service Fabric-к-Service Fabric представляет сертификат, который не соответствует правилам проверки получателя. Может сопровождаться одной из следующих ошибок:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

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

    Другим сопровождающим распространенным кодом ошибки может быть:

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    В этом случае сертификат объявляется по общему имени, и к сертификату применяется одно из следующих положений:

    • издатели сертификата не закреплены, а корневой сертификат не является доверенным, или
    • издатели сертификата закреплены, но объявление не включает отпечаток прямого издателя этого сертификата.

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

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

      • недопустимые символы в объявлении отпечатка;
      • сертификат не установлен;
      • срок действия сертификата истек;
      • объявление по общему имени содержит префикс CN=;
      • объявление указывает подстановочный знак и отсутствует точное совпадение в хранилище сертификатов (объявление: CN=*.mydomain.com, фактический сертификат: CN=server.mydomain.com);

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

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Чтобы исправить это, проверьте наличие закрытого ключа. Убедитесь, что для SFAdmins предоставлен доступ к закрытому ключу для чтения | исполнения;

    • плохой тип поставщика — означает сертификат нового поколения шифрования (CNG) ("Поставщик хранилища ключей программного обеспечения Майкрософт"); в настоящее время Service Fabric поддерживает только сертификаты CAPI1. Обычно вместе с кодом ошибки:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Чтобы исправить эту проблему, создайте сертификат кластера повторно с помощью поставщика CAPI1 (например, "Расширенный поставщик служб шифрования RSA и AES Microsoft"). Дополнительные сведения о поставщиках служб шифрования см. в статье Общие сведения о поставщиках служб шифрования.