Service Fabric kümelerinde X.509 Sertifika tabanlı kimlik doğrulaması

  • Makale

Bu makale, Service Fabric kümesi güvenliğine giriş işlemini tamamlar ve Service Fabric kümelerinde sertifika tabanlı kimlik doğrulamasının ayrıntılarına gider. Okuyucunun temel güvenlik kavramlarını ve ayrıca Service Fabric'in bir kümenin güvenliğini denetlemek için kullanıma sunduğumuz denetimleri bildiğini varsayıyoruz.

Bu başlık altında ele alınan konular:

  • Sertifika tabanlı kimlik doğrulamasıyla ilgili temel bilgiler
  • Kimlikler ve ilgili rolleri
  • Sertifika yapılandırma kuralları
  • Sorun Giderme ve Sık Sorulan Sorular

Sertifika tabanlı kimlik doğrulamasıyla ilgili temel bilgiler

Kısa bir yenileme olarak, güvenlikte sertifika, bir varlıkla (özne) ilgili bilgileri bir çift asimetrik şifreleme anahtarına sahip olmalarına bağlamak için kullanılan bir araçtır ve bu nedenle ortak anahtar şifrelemesinin temel yapısını oluşturur. Sertifika tarafından temsil edilen anahtarlar, verilerin korunması veya anahtar sahiplerinin kimliğinin kanıtlanması için kullanılabilir; Bir sertifika, Ortak Anahtar Altyapısı (PKI) sistemiyle birlikte kullanıldığında, bir internet etki alanının sahipliği veya sertifikayı veren (Sertifika Yetkilisi veya CA olarak bilinir) tarafından verilen belirli ayrıcalıklar gibi konusunun ek özelliklerini temsil edebilir. Sertifikaların yaygın bir uygulaması Aktarım Katmanı Güvenliği (TLS) şifreleme protokolünün desteklenmesidir ve bir bilgisayar ağı üzerinden güvenli iletişimlere olanak tanır. Özellikle, istemci ve sunucu, iletişimlerinin gizliliğini ve bütünlüğünü sağlamak ve karşılıklı kimlik doğrulaması gerçekleştirmek için sertifikaları kullanır.

Service Fabric'te, bir kümenin (Federasyon) temel katmanı, katılımcı düğümlerden oluşan güvenilir ve güvenli bir ağ elde etmek için TLS (diğer protokoller arasında) üzerinde de derleniyor. Service Fabric İstemci API'leri aracılığıyla kümeye Bağlan, trafiği korumak ve ayrıca tarafların kimliklerini oluşturmak için TLS kullanır. Özellikle, Service Fabric'te kimlik doğrulaması için kullanıldığında, aşağıdaki talepleri kanıtlamak için bir sertifika kullanılabilir: a) sertifika kimlik bilgisinin sunucusu sertifikanın özel anahtarına sahip b) sertifikanın SHA-1 karması ('parmak izi') küme tanımına dahil edilen bir bildirimle eşleşir veya c) sertifikanın ayırt edici Konu Ortak Adı küme tanımında yer alan bir bildirimle eşleşir, ve sertifikayı veren bilinir veya güvenilirdir.

Yukarıdaki listede ,'b' birlikte 'parmak izi sabitleme' olarak bilinir; bu durumda, bildirim belirli bir sertifikayı ifade eder ve kimlik doğrulama düzeninin gücü, diğer tüm açılardan geçerli, iyi biçimlendirilmiş bir nesne olmakla birlikte, başka bir sertifikayla aynı karma değeri üreten bir sertifikayı oluşturmanın işlem açısından mümkün olmadığını ifade eder. 'c' öğesi, düzenin gücünün sertifikanın konusuyla veren yetkilinin birleşimine dayandığı alternatif bir sertifika bildirimi biçimini temsil eder. Bu durumda, bildirim bir sertifika sınıfına başvurur - aynı özelliklere sahip iki sertifika tam olarak eşdeğer kabul edilir.

Aşağıdaki bölümlerde Service Fabric çalışma zamanının küme güvenliğini sağlamak için sertifikaları nasıl kullandığı ve doğruladığı ayrıntılı bir şekilde açıklanmaktadır.

Kimlikler ve ilgili rolleri

Kimlik doğrulaması veya iletişim kanallarının güvenliğini sağlama ayrıntılarını gözden geçirmeden önce, katılımcı aktörleri ve bir kümede oynadıkları ilgili rolleri listelemek önemlidir:

  • 'system' olarak adlandırılan Service Fabric çalışma zamanı: kümeyi temsil eden soyutlamaları ve işlevleri sağlayan hizmet kümesi. Sistem örnekleri arasındaki küme içi iletişime başvururken 'küme kimliği' terimini kullanacağız; kümeyi, küme dışından gelen trafiğin alıcısı/hedefi olarak adlandırırken 'sunucu kimliği' terimini kullanacağız.
  • 'applications' olarak adlandırılan barındırılan uygulamalar: kümenin sahibi tarafından sağlanan ve kümede düzenlenen ve yürütülen kod
  • istemcileri: Küme yapılandırmasına göre kümeye bağlanmasına ve kümede işlevselliği yürütmesine izin verilen varlıklar. İki ayrıcalık düzeyi arasında ayrım yapıyoruz: sırasıyla 'user' ve 'admin'. Bir 'kullanıcı' istemcisi öncelikli olarak salt okunur işlemlerle (ancak tüm salt okunur işlevlerle değil) kısıtlanırken, 'yönetici' istemcisinin kümenin işlevselliğine sınırsız erişimi vardır. (Daha fazla ayrıntı için bkz. Service Fabric kümesindeki güvenlik rolleri.)
  • (Yalnızca Azure) Service Fabric kümelerinin çalışması ve yönetimi için denetimleri düzenleyen ve kullanıma sunan Service Fabric hizmetleri, kısaca "hizmet" olarak adlandırılır. Ortama bağlı olarak, 'hizmet' Azure Service Fabric Kaynak Sağlayıcısı'na veya Service Fabric ekibinin sahip olduğu ve işlettiği diğer Kaynak Sağlayıcılarına başvurabilir.

Güvenli bir kümede, bu rollerin her biri önceden tanımlanmış bir rol adı ve buna karşılık gelen kimlik bilgilerinin eşlenmesi olarak bildirilen kendi benzersiz kimlikleriyle yapılandırılabilir. Service Fabric, kimlik bilgilerinin sertifika veya etki alanı tabanlı hizmet sorumlusu olarak bildirilmesine destek sağlar. (Windows/Kerberos tabanlı kimlikler de desteklenir, ancak bu makalenin kapsamı dışındadır; bkz.Service Fabric kümelerinde Windows tabanlı güvenlik.) Azure kümelerinde istemci rolleri, Microsoft Entra ID tabanlı kimlikler olarak da bildirilebilir.

Yukarıda belirtildiği gibi, Service Fabric çalışma zamanı bir kümede iki ayrıcalık düzeyi tanımlar: 'admin' ve 'user'. Yönetici istemcisi ve 'sistem' bileşeni hem 'yönetici' ayrıcalıklarıyla çalışır hem de birbirinden ayırt edilemez. Kümede/kümeye bağlantı kurulduktan sonra, Service Fabric çalışma zamanı tarafından sonraki yetkilendirme için temel olarak iki rolden biri olarak kimliği doğrulanmış bir çağıran verilir. Kimlik doğrulamasını aşağıdaki bölümlerde ayrıntılı olarak inceleyeceğiz.

Sertifika yapılandırma kuralları

Doğrulama kuralları

Service Fabric kümesinin güvenlik ayarları, ilke olarak aşağıdaki yönleri açıklar:

  • kimlik doğrulama türü; Bu, kümenin oluşturma zamanı ve sabit bir özelliğidir. Bu tür ayarlara örnek olarak 'ClusterCredentialType', 'ServerCredentialType' verilebilir ve izin verilen değerler 'none', 'x509' veya 'windows' şeklindedir. Bu makalede x509 türü kimlik doğrulamasına odaklanmaktadır.
  • (kimlik doğrulaması) doğrulama kuralları; bu ayarlar küme sahibi tarafından ayarlanır ve belirli bir rol için hangi kimlik bilgilerinin kabul edilmesi gerektiğini açıklar. Örnekler hemen aşağıda ayrıntılı olarak incelenecektir.
  • kimlik doğrulamasının sonucunu değiştirmek veya değiştirmek için kullanılan ayarlar; Buradaki örnekler arasında sertifika iptal listelerinin uygulanmasını kısıtlayan veya kısıtlamayan bayraklar vb. yer alır.

Dekont

Aşağıda sağlanan küme yapılandırma örnekleri, bu makalede açıklanan Service Fabric işlevselliğini doğrudan destekleyen en özetlenmiş biçim olarak, küme bildiriminden XML biçimindeki alıntılardır. Aynı ayarlar, tek başına json kümesi bildirimi veya Azure Kaynak Yönetimi şablonu olsun, küme tanımının JSON gösterimlerinde doğrudan ifade edilebilir.

Sertifika doğrulama kuralı aşağıdaki öğeleri içerir:

  • karşılık gelen rol: istemci, yönetici istemcisi (ayrıcalıklı rol)
  • rol için kabul edilen kimlik bilgisi, parmak izi veya konu ortak adıyla bildirilir

Parmak izi tabanlı sertifika doğrulama bildirimleri

Parmak izi tabanlı doğrulama kuralları söz konusu olduğunda, kümeye/kümeye bağlantı isteyen bir arayan tarafından sunulan kimlik bilgileri aşağıdaki gibi doğrulanır:

  • kimlik bilgisi geçerli, iyi biçimlendirilmiş bir sertifikadır: zinciri oluşturulabilir, imzalar eşleşir
  • sertifika geçerli zaman (NotBefore <= now < NotAfter)
  • Sertifikanın SHA-1 karması, tüm boşluklar hariç büyük/küçük harfe duyarlı olmayan dize karşılaştırması olarak bildirimle eşleşir

Zincir oluşturma veya doğrulama sırasında karşılaşılan tüm güven hataları, süresi dolan sertifikalar dışında parmak izi tabanlı bildirimler için gizlenir; ancak bu durumda da sağlamalar vardır. Özellikle, iptal durumunun bilinmemesi veya çevrimdışı olması, güvenilmeyen kök, geçersiz anahtar kullanımı, kısmi zincir ile ilgili hatalar önemli olmayan hatalar olarak kabul edilir; bu durumda şirket, sertifikanın yalnızca anahtar çifti için bir zarf olmasıdır; güvenlik, küme sahibinin özel anahtarı korumak için yer ölçüsünü ayarlamış olmasıdır.

Bir küme bildiriminden aşağıdaki alıntı, parmak izi tabanlı doğrulama kuralları kümesinin örneğini gösterir:

<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>

Yukarıdaki girdilerin her biri daha önce açıklandığı gibi belirli bir kimliğe başvurur; her girdi, virgülle ayrılmış dize listesi olarak birden çok değer belirtmeye de olanak tanır. Bu örnekte, gelen kimlik bilgileri başarıyla doğrulandıktan sonra SHA-1 parmak izi 'd5ec... olan bir sertifikanın sunucusu... 4264'e 'yönetici' rolü verilecektir; buna karşılık, '7c8f sertifikasıyla kimlik doğrulayan bir arayan... 01b0' öğesine birincil olarak salt okunur işlemle sınırlı bir 'kullanıcı' rolü verilir. Parmak izi 'abcd... olan bir sertifika sunan gelen arayan... 1234' veya 'ef01... 5678', kümede eş düğüm olarak kabul edilir. Son olarak, kümenin yönetim uç noktasına bağlanan bir istemci, sunucu sertifikasının parmak izinin 'ef01... olmasını bekler. 5678'.

Daha önce belirtildiği gibi, Service Fabric süresi dolan sertifikaları kabul etmek için sağlamalar yapar; Bunun nedeni sertifikaların sınırlı bir ömrü olması ve parmak iziyle bildirildiğinde (belirli bir sertifika örneğine başvuruda bulunur), bir sertifikanın süresinin dolmasına izin vermenin kümeye bağlanılamamasına veya kümenin doğrudan çökmesine neden olmasıdır. Parmak iziyle sabitlenmiş bir sertifikayı döndürmeyi unutmak veya ihmal etmek çok kolaydır ve ne yazık ki böyle bir durumdan kurtarma zordur.

Bu amaçla, küme sahibi parmak izi tarafından bildirilen otomatik olarak imzalanan sertifikaların geçerli kabul edileceğini açıkça belirtebilir:

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

Bu davranış CA tarafından verilen sertifikalara genişletilmez; böyle bir durum söz konusuysa, ca'nın sertifika iptal listesinde yer almaz iptal edilmiş, güvenliği aşılması bilinen süresi dolmuş bir sertifika 'geçerli' hale gelebilir ve bu nedenle bir güvenlik riski oluşturur. Otomatik olarak imzalanan sertifikalarda, küme sahibi sertifikanın özel anahtarını korumakla sorumlu olan tek taraf olarak kabul edilir ve ca tarafından verilen sertifikalarda böyle bir durum söz konusu değildir. Küme sahibi sertifikanın gizliliğinin nasıl veya ne zaman ihlal edildiğinin farkında olmayabilir.

Ortak ad tabanlı sertifika doğrulama bildirimleri

Ortak ad tabanlı bildirimler aşağıdaki formlardan birini alır:

  • konu ortak adı (yalnızca)
  • veren sabitleme ile konu ortak adı

İlk olarak her iki bildirim stilini de uygulayan bir küme bildiriminden alıntıyı ele alalım:

    <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>

Bildirimler sırasıyla sunucu ve küme kimliklerine başvurur; CN tabanlı bildirimlerin, küme bildiriminde standart 'Güvenlik'ten ayrı kendi bölümleri olduğunu unutmayın. Her iki bildirimde de ,'Ad', sertifikanın ayırt edici konu ortak adını temsil eder ve 'Değer' alanı beklenen vereni aşağıda gösterildiği gibi temsil eder:

  • ilk durumda bildirim, sunucu sertifikasının ayırt edici konusunun ortak ad öğesinin "server.demo.system.servicefabric.azure-int" dizesiyle eşleşmesinin beklendiğini belirtir; boş 'Değer' alanı, sunucu sertifikasının doğrulandığı düğümde/makinede sertifika zincirinin köküne güvenildiği beklentisini belirtir; Bu, sertifikanın 'Güvenilen Kök CA' deposunda yüklü sertifikalardan herhangi birine zincirlenebileceği anlamına gelir;
  • ikinci durumda bildirim, sertifikanın ortak adı "cluster.demo.system.servicefabric.azure-int" dizesiyle eşleşiyorsa ve sertifikayı doğrudan verenin parmak izi 'Değer' alanındaki virgülle ayrılmış girdilerden biriyle eşleşiyorsa, sertifikanın sunucusu kümede eş düğüm olarak kabul edilir. (Bu kural türü ortak olarak 'veren sabitlemeli ortak ad' olarak bilinir.)

Her iki durumda da sertifikanın zinciri oluşturulur ve hatasız olması beklenir; yani iptal hataları, kısmi zincir veya zaman geçersiz güven hataları önemli kabul edilir ve sertifika doğrulaması başarısız olur. Verenlerin sabitlenmesi , 'güvenilmeyen kök' durumunun önemli olmayan bir hata olarak düşünülerek sonuçlanır; bu, küme sahibinin yetkili/kabul edilen verenler kümesini kendi PKI'larıyla sınırlamasına izin verdiğinden, bu daha katı bir doğrulama biçimidir.

Sertifika zinciri oluşturulduktan sonra, belirtilen konu uzak adıyla standart bir TLS/SSL ilkesine göre doğrulanır; bir sertifika, konu ortak adı veya konu diğer adlarından herhangi biri küme bildirimindeki CN bildirimiyle eşleşiyorsa eşleşme olarak kabul edilir. Joker karakterler bu durumda desteklenir ve dize eşleştirme büyük/küçük harfe duyarlı değildir.

(Yukarıda açıklanan sıranın sertifika tarafından bildirilen her anahtar kullanımı türü için yürütülebileceğini açıklığa kavuşturmalıyız; sertifika istemci kimlik doğrulama anahtarı kullanımını belirtiyorsa, zincir ilk olarak bir istemci rolü için oluşturulur ve değerlendirilir. Başarılı olması durumunda değerlendirme tamamlanır ve doğrulama başarılı olur. Sertifikada istemci kimlik doğrulaması kullanımı yoksa veya doğrulama başarısız olduysa, Service Fabric çalışma zamanı sunucu kimlik doğrulaması için zinciri derleyip değerlendirir.)

Örneği tamamlamak için aşağıdaki alıntıda istemci sertifikalarının ortak ada göre bildirilmesi gösterilmektedir:

    <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>

Yukarıdaki bildirimler sırasıyla yönetici ve kullanıcı kimliklerine karşılık gelir; bu şekilde bildirilen sertifikaların doğrulanması, küme ve sunucu sertifikalarının önceki örnekleri için tam olarak açıklandığı gibidir.

Dekont

Yaygın ad tabanlı bildirimler, döndürmeyi ve genel olarak küme sertifikalarının yönetimini basitleştirmeye yöneliktir. Ancak, kümenin sürekli kullanılabilirliğini ve güvenliğini sağlamak için aşağıdaki önerilere uyulması önerilir:

  • güvenilen köklere bağlı olarak vereni sabitlemeyi tercih edin
  • farklı PKI'lerden verenleri karıştırmaktan kaçının
  • tüm beklenen verenlerin sertifika bildiriminde listelenmiş olduğundan emin olun; Eşleşmeyen bir veren, doğrulamanın başarısız olmasına neden olur
  • PKI'nın sertifika ilkesi uç noktalarının bulunabilir, kullanılabilir ve erişilebilir olduğundan emin olun. Bu, AIA, CRL veya OCSP uç noktalarının yaprak sertifikada bildirilmesi ve sertifika zinciri oluşturma işleminin tamamlanabilmesi için erişilebilir oldukları anlamına gelir.

X.509 sertifikaları ile güvenliği sağlanan bir kümede bağlantı isteği aldıktan sonra, Service Fabric çalışma zamanı yukarıda açıklandığı gibi uzak tarafın kimlik bilgilerini doğrulamak için kümenin güvenlik ayarlarını kullanır; başarılı olursa, arayan/uzak tarafın kimliğinin doğrulanmış olduğu kabul edilir. Kimlik bilgisi birden çok doğrulama kuralıyla eşleşiyorsa, çalışma zamanı çağırana eşleşen kurallardan herhangi birinin en yüksek ayrıcalıklı rolünü verir.

Sunu kuralları

Önceki bölümde, kimlik doğrulamasının sertifika güvenli bir kümede nasıl çalıştığı açıklanmıştır; Bu bölümde Service Fabric çalışma zamanının küme içi iletişim için kullandığı sertifikaları nasıl bulup yükleyeceği açıklanır; bunlara "sunu" kuralları diyoruz.

Doğrulama kurallarında olduğu gibi, sunu kuralları da parmak izi veya ortak adla ifade edilen bir rol ve ilişkili kimlik bilgisi bildirimini belirtir. Doğrulama kurallarından farklı olarak, yaygın ad tabanlı bildirimlerin veren sabitleme için sağlamaları yoktur; bu, hem daha fazla esneklik hem de gelişmiş performans sağlar. Sunu kuralları, her ayrı düğüm türü için küme bildiriminin 'NodeType' bölümlerinde bildirilir; ayarlar, her düğüm türünün tek bir bölümde tam yapılandırmasına sahip olmasına izin vermek için kümenin Güvenlik bölümlerinden ayrılır. Azure Service Fabric kümelerinde düğüm türü sertifika bildirimleri varsayılan olarak küme tanımının Güvenlik bölümünde karşılık gelen ayarlarına ayarlanır.

Parmak izi tabanlı sertifika sunu bildirimleri

Daha önce açıklandığı gibi Service Fabric çalışma zamanı, kümedeki diğer düğümlerin eş rolü ile küme yönetimi işlemleri için sunucu arasında ayrım gerçekleştirir. Prensipte, bu ayarlar ayrı ayrı yapılandırılabilir, ancak pratikte hizalanırlar. Bu makalenin geri kalanında, ayarların basitlik için uygun olduğunu varsayacağız.

Bir küme bildiriminden aşağıdaki alıntıyı ele alalım:

  <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' öğesi, isteğe bağlı parametreler ('X509FindValueSecondary') veya uygun varsayılan değerlere ('X509StoreName') sahip olanlar dahil olmak üzere tam şemayı gösterir; diğer bildirimlerde kısaltılmış bir form gösterilir. Yukarıdaki küme sertifikası bildirimi, 'nt1vm' türündeki düğümlerin güvenlik ayarlarının 'cc71.. sertifikasıyla başlatıldığını belirtir. 1984' birincil ve '49e2.. İkincil olarak 19d6' sertifikası; her iki sertifikanın da LocalMachine'My' sertifika deposunda (veya Linux eşdeğer yolu, var/lib/sfcerts) bulunması beklenir.

Ortak ad tabanlı sertifika sunu bildirimleri

Düğüm türü sertifikaları, aşağıda gösterildiği gibi konu ortak adıyla da bildirilebilir:

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

Her iki bildirim türünde de Service Fabric düğümü başlangıçta yapılandırmayı okur, belirtilen sertifikaları bulup yükler ve notBefore özniteliğinin azalan düzende sıralar; süresi dolan sertifikalar yoksayılır ve listenin ilk öğesi bu düğüm tarafından denenen herhangi bir Service Fabric bağlantısı için istemci kimlik bilgisi olarak seçilir. (Aslında, Service Fabric en son verilen sertifikayı tercih eder.)

Dekont

7.2.445 (7.2 CU4) sürümünden önce Service Fabric en uzak süre sonu sertifikasını (en uzak 'NotAfter' özelliğine sahip sertifika) seçti

Ortak ad tabanlı sunu bildirimleri için, büyük/küçük harfe duyarlı, tam dize karşılaştırması olarak sertifikanın konu ortak adı bildirimin X509FindValue (veya X509FindValueSecondary) alanına eşitse, sertifikanın eşleşme olarak kabul edildiğini unutmayın. Bu, joker karakter eşleştirmeyi ve büyük/küçük harfe duyarlı olmayan dize karşılaştırmalarını destekleyen doğrulama kurallarının aksinedir.

Çeşitli sertifika yapılandırma ayarları

Daha önce bir Service Fabric kümesinin güvenlik ayarlarının, kimlik doğrulama kodunun davranışını altta değiştirmeye de izin vermekte olduğu belirtildi. Service Fabric küme ayarları makalesi kapsamlı ve en güncel ayarlar listesini temsil ederken, sertifika tabanlı kimlik doğrulamasında tam kullanıma sunma işlemini tamamlamak için buradaki güvenlik ayarlarından birkaçının anlamını genişleteceğiz. Her ayar için amacı, varsayılan değeri/davranışı, kimlik doğrulamasını nasıl etkilediğini ve hangi değerlerin kabul edilebilir olduğunu açıklayacağız.

Belirtildiği gibi, sertifika doğrulaması her zaman sertifika zincirinin oluşturulmasını ve değerlendirilmesi anlamına gelir. CA tarafından verilen sertifikalar için, bu görünüşte basit işletim sistemi API çağrısı genellikle veren PKI'nın çeşitli uç noktalarına çeşitli giden çağrılar, yanıtların önbelleğe alınmasını vb. gerektirir. Service Fabric kümesindeki sertifika doğrulama çağrılarının yaygınlığı göz önüne alındığında, PKI uç noktalarındaki sorunlar kümenin kullanılabilirliğinin azalmasına veya doğrudan döküme neden olabilir. Giden çağrılar gizlenemez (bununla ilgili daha fazla bilgi için aşağıdaki SSS bölümüne bakın), başarısız CRL çağrılarının neden olduğu doğrulama hatalarını maskelamak için aşağıdaki ayarlar kullanılabilir.

  • CrlCheckingFlag - "Güvenlik" bölümünün altında dize UINT'ye dönüştürülür. Bu ayarın değeri Service Fabric tarafından zincir oluşturma davranışını değiştirerek sertifika zinciri durum hatalarını maskeleme amacıyla kullanılır; Win32 CryptoAPI CertGetCertificateChain çağrısına 'dwFlags' parametresi olarak geçirilir ve işlev tarafından kabul edilen geçerli herhangi bir bayrak bileşimine ayarlanabilir. 0 değeri Service Fabric çalışma zamanını güven durumu hatalarını yoksaymaya zorlar; kullanımı önemli bir güvenlik açıklığı oluşturacağı için bu önerilmez. Varsayılan değer 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

Ne zaman kullanılır: Yerel test için, otomatik olarak imzalanan sertifikalarla veya tam olarak biçimlendirilmemiş/sertifikaları desteklemek için uygun bir ortak anahtar altyapısına sahip olmayan geliştirici sertifikalarıyla. AYRıCA, PKI'ler arasında geçiş sırasında hava ile eşlenen ortamlarda risk azaltma olarak da kullanılabilir.

Nasıl kullanılır: İptal denetimini yalnızca önbelleğe alınmış URL'lere erişmeye zorlayan bir örnek alacağız. Varsay -arak:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

ardından küme bildirimindeki bildirim şöyle olur:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError - "Güvenlik" bölümünün altında varsayılan değeri 'false' olan boole değeri. 'İptal çevrimdışı' zincir oluşturma hata durumunu (veya sonraki zincir ilkesi doğrulama hata durumunu) gizlemeye yönelik bir kısayolu temsil eder.

Ne zaman kullanılır: yerel test veya uygun bir PKI tarafından desteklenmeyen geliştirici sertifikaları ile. Havayla kaplı ortamlarda veya PKI'nın erişilemez olduğu bilindiğinde azaltma olarak kullanın.

Nasıl kullanılır:

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

Diğer önemli ayarlar (tümü "Güvenlik" bölümü altında):

  • AcceptExpiredPinnedClusterCertificate - parmak izi tabanlı sertifika doğrulamasına ayrılmış bölümünde ele alınmaktadır; süresi dolan otomatik olarak imzalanan küme sertifikalarının kabul edilmesini sağlar.
  • CertificateExpiry Kasa tyMargin - aralık, sertifikanın NotAfter zaman damgasından birkaç dakika önce ifade edilir ve bu süre boyunca sertifikanın süre sonu riski altında olduğu kabul edilir. Service Fabric küme sertifikalarını izler ve kalan kullanılabilirlik durum raporlarını düzenli aralıklarla yayar. 'Güvenlik' aralığı içinde, bu sistem durumu raporları 'uyarı' durumuna yükseltilir. Varsayılan değer 30 gündür.
  • CertificateHealthReportingInterval - Küme sertifikalarının kalan süre geçerliliğiyle ilgili sistem durumu raporlarının sıklığını denetler. Raporlar bu aralık başına yalnızca bir kez yayınlanır. Değer, varsayılan olarak 8 saat olacak şekilde saniye cinsinden ifade edilir.
  • EnforcePrevalidationOnSecurityChanges - boolean, güvenlik ayarlarındaki değişiklikleri algılayarak küme yükseltme davranışını denetler. 'true' olarak ayarlanırsa, küme yükseltmesi sunu kurallarından herhangi biriyle eşleşen sertifikalardan en az birinin karşılık gelen bir doğrulama kuralı geçirebilmesini sağlamaya çalışır. Ön doğrulama, yeni ayarlar herhangi bir düğüme uygulanmadan önce yürütülür, ancak yükseltmeyi başlatırken yalnızca Küme Yöneticisi hizmetinin birincil çoğaltmasını barındıran düğümde çalışır. Bu yazıdan itibaren, ayar varsayılan olarak 'false' değerine sahiptir ve çalışma zamanı sürümü 7.1 ile başlayan yeni Azure Service Fabric kümeleri için 'true' olarak ayarlanır.

Uçtan uca senaryo (örnekler)

Sunu kurallarını, doğrulama kurallarını ve ince ayar bayraklarını inceledik, ancak bunların hepsi birlikte nasıl çalışır? Bu bölümde, güvenli küme yükseltmeleri için güvenlik ayarlarının nasıl kullanılabilmesini gösteren iki uçtan uca örnek üzerinden çalışacağız. Bunun Service Fabric'te uygun sertifika yönetimiyle ilgili kapsamlı bir tez olması amaçlanmadığını unutmayın. Bu konuda yardımcı bir makale arayın.

Sunu ve doğrulama kurallarının ayrılması, ayrışıp ayrılamayacağı ve sonuçlarının ne olacağı konusunda belirgin bir soruyu (veya endişeyi) oluşturur. Bir düğümün kimlik doğrulama sertifikası seçiminin başka bir düğümün doğrulama kurallarını geçirmesi mümkündür. Aslında bu tutarsızlık, kimlik doğrulamasıyla ilgili olayların birincil nedenidir. Aynı zamanda, bu kuralların ayrılması, kümenin güvenlik ayarlarını değiştiren bir yükseltme sırasında kümenin çalışmaya devam etmesini sağlar. İlk olarak doğrulama kurallarını ilk adım olarak genişleterek, geçerli kimlik bilgilerini kullanmaya devam ederken kümenin tüm düğümlerinin yeni ayarlarda yakınsanacağını düşünün.

Service Fabric kümesinde yükseltme işleminin 'yükseltme etki alanları' veya UD'ler üzerinden (5'e kadar) ilerlediğini hatırlayın. Yalnızca geçerli UD'deki düğümler belirli bir zamanda yükseltiliyor/değiştiriliyor ve yükseltme yalnızca kümenin kullanılabilirliğine izin veriyorsa sonraki UD'ye geçecektir. (Bkz. Daha fazla ayrıntı için Service Fabric kümesi yükseltmeleri ve aynı konudaki diğer makaleler.) Sertifika/güvenlik değişiklikleri özellikle risklidir, çünkü düğümleri kümeden yalıtabilir veya kümeyi çekirdek kaybı sınırında bırakabilirler.

Bir düğümün güvenlik ayarlarını açıklamak için aşağıdaki gösterimi kullanacağız:

Nk: {P:{TP=A}, V:{TP=A}}, burada:

  • 'Nk', k yükseltme etki alanındaki bir düğümü temsil eder
  • 'P' düğümün geçerli sunu kurallarını temsil eder (yalnızca küme sertifikalarına başvurduğunu varsayarsak);
  • 'V' düğümün geçerli doğrulama kurallarını temsil eder (yalnızca küme sertifikası)
  • 'TP=A', parmak izi tabanlı bir bildirimi (TP) temsil eder ve 'A' sertifika parmak izidir
  • 'CN=B' ortak ad tabanlı bildirimi (CN) temsil eder ve 'B' sertifikanın konu ortak adıdır

Parmak izi tarafından bildirilen bir küme sertifikasını döndürme

Aşağıdaki dizide, parmak iziyle bildirilen ikincil bir küme sertifikasını güvenli bir şekilde tanıtmak için 2 aşamalı yükseltmenin nasıl kullanılabileceğini açıklar; birinci aşama, doğrulama kurallarında yeni sertifika bildirimini tanıtır ve ikinci aşama bunu sunu kurallarında tanıtır:

  • başlangıç durumu: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} - küme bekleyen durumda, tüm düğümler ortak bir yapılandırmayı paylaşıyor
  • yükseltme etki alanı 0 tamamlandıktan sonra: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} - UD0'daki düğümler A sertifikası sunar ve A veya B sertifikalarını kabul eder; diğer tüm düğümler var ve yalnızca A sertifikalarını kabul ediyorum
  • son yükseltme etki alanı tamamlandıktan sonra: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} - tüm düğümler A sertifikası sunar; tüm düğümler A veya B sertifikalarını kabul eder

Bu noktada küme yine dengededir ve yükseltme/değiştirme güvenlik ayarlarının ikinci aşaması başlayabilir:

  • yükseltme etki alanı 0 tamamlandıktan sonra: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} - UD0'daki düğümler, kümedeki diğer düğümler tarafından kabul edilen B'yi sunmaya başlar.
  • son yükseltme etki alanı tamamlandıktan sonra: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} - tüm düğümler B sertifikası sunmaya geçti. Sertifika A artık sonraki bir yükseltme kümesiyle devre dışı bırakılabilir/küme tanımından kaldırılabilir.

Bir kümeyi parmak izinden ortak ad tabanlı sertifika bildirimlerine dönüştürme

Benzer şekilde, sertifika bildiriminin türünü değiştirmek (parmak izinden ortak ada) yukarıdakiyle aynı deseni izler. Doğrulama kurallarının, belirli bir rolün sertifikalarını aynı küme tanımında hem parmak izi hem de ortak adla bildirmeye izin verdiğini unutmayın. Buna karşılık, sunu kuralları yalnızca bir bildirim biçimine izin verir. Bu arada, bir küme sertifikasını parmak izinden ortak ada dönüştürmenin güvenli yaklaşımı, hedef sertifikayı önce parmak iziyle tanıtmak ve ardından bu bildirimi ortak bir ad tabanlı sertifikayla değiştirmektir. Aşağıdaki örnekte, 'A' parmak izi ve 'B' konu ortak adının aynı sertifikaya başvurduğunu varsayacağız.

  • başlangıç durumu: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} - küme bekleyen durumda, tüm düğümler ortak bir yapılandırmayı paylaşıyor ve A birincil sertifika parmak izi oluyor
  • yükseltme etki alanı 0 tamamlandıktan sonra: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} - UD0'daki düğümler A sertifikası sunar ve A parmak izi A veya ortak adı B olan sertifikaları kabul eder; diğer tüm düğümler var ve yalnızca A sertifikalarını kabul ediyorum
  • son yükseltme etki alanı tamamlandıktan sonra: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - tüm düğümler A sertifikası sunar; tüm düğümler A (TP) veya B (CN) sertifikalarını kabul eder

Bu noktada sonraki bir yükseltmeyle sunu kurallarını değiştirmeye devam edebiliriz:

  • yükseltme etki alanı 0 tamamlandıktan sonra: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - UD0'daki düğümler CN tarafından bulunan B sertifikalarını sunar ve A parmak izi A veya ortak adı B olan sertifikaları kabul eder; diğer tüm düğümler mevcut ve yalnızca A sertifikalarını kabul et, parmak iziyle seçili
  • son yükseltme etki alanı tamamlandıktan sonra: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{CN=B}, V:{TP=A, CN=B}} - tüm düğümler CN tarafından bulunan B sertifikalarını sunar, tüm düğümler A (TP) veya B (CN) sertifikalarını kabul eder

2. aşamanın tamamlanması, kümenin ortak ad tabanlı sertifikalara dönüştürülmesi de işaret eder; parmak izi tabanlı doğrulama bildirimleri sonraki bir küme yükseltmesinde kaldırılabilir.

Dekont

Azure Service Fabric kümelerinde, yukarıda sunulan iş akışları Service Fabric Kaynak Sağlayıcısı tarafından düzenlenir; küme sahibi, belirtilen kurallara (sunu veya doğrulama) göre kümeye sertifika sağlamakla hala sorumludur ve birden çok adımda değişiklik yapması teşvik edilir.

Ayrı bir makalede, Service Fabric kümesinde sertifikaları yönetme ve sağlama konusu ele alınacaktır.

Sorun Giderme ve Sık Sorulan Sorular

Service Fabric kümelerinde kimlik doğrulamasıyla ilgili sorunlarda hata ayıklamak kolay olmasa da, aşağıdaki ipuçları ve ipuçlarının yardımcı olabileceğini umuyoruz. Araştırmalara başlamanın en kolay yolu, kümenin düğümlerindeki Service Fabric olay günlüklerini incelemektir; yalnızca belirtileri gösterenleri değil, aynı zamanda çalışır durumda olan ancak komşularından birine bağlanamayan düğümleri de incelemektir. Windows'da anlam olayları genellikle sırasıyla 'Uygulamalar ve Hizmetler Günlükleri\Microsoft-ServiceFabric\Yönetici' veya 'Operasyonel' kanalları altında günlüğe kaydedilir. Bazen SERTIFIKA doğrulaması, CRL/CTL'nin alınması vb. ile ilgili daha fazla ayrıntı yakalamak için CAPI2 günlüğünü etkinleştirmek yararlı olabilir(Yeniden oluşturmayı tamamladıktan sonra devre dışı bırakmayı unutmayın, oldukça ayrıntılı olabilir.)

Kimlik doğrulaması sorunları yaşayan bir kümede kendilerini gösteren tipik belirtiler şunlardır:

  • düğümler çalışmıyor/döngüleniyor
  • bağlantı girişimleri reddedildi
  • bağlantı girişimleri zaman aşımına uğradı

Belirtilerin her biri farklı sorunlardan kaynaklanabilir ve aynı kök neden farklı belirtiler gösterebilir; bu nedenle, tipik sorunların küçük bir örneğini listeleyeceğiz ve bunları düzeltmek için öneriler sağlayacağız.

  • Düğümler ileti alışverişi yapabilir ancak bağlanamaz. Bağlantı girişimlerinin sonlandırılma nedenlerinden biri 'sertifika eşleşmedi' hatasıdır. Service Fabric'e Doku bağlantısındaki taraflardan biri, alıcının doğrulama kurallarını başarısız olan bir sertifika sunuyor. Aşağıdaki hatalardan biri eşlik edebilir:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    Daha fazla tanılamak/araştırmak için: Bağlantıyı deneyen düğümlerin her birinde hangi sertifikanın sunulduğunu belirleyin; sertifikayı inceleyin ve doğrulama kurallarını öykünmeye çalışın (parmak izi veya ortak ad eşitliğini denetleyin, belirtilirse veren parmak izlerini denetleyin).

    Bir diğer yaygın hata kodu da şu olabilir:

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    Bu durumda, sertifika ortak adla bildirilir ve aşağıdakilerden biri geçerlidir:

    • verenler sabitlenmez ve kök sertifikaya güvenilmez veya
    • verenler sabitlendi, ancak bildirim bu sertifikanın doğrudan verenin parmak izini içermiyor

  • Bir düğüm çalışır durumda ancak diğer düğümlere bağlanamıyor; diğer düğümler, başarısız olan düğümden gelen trafiği almaz. Bu durumda sertifika yükleme işlemi yerel düğümde başarısız olabilir. Aşağıdaki hataları arayın:

    • sertifika bulunamadı - Sunu kurallarında bildirilen sertifikaların LocalMachine\My (veya belirtildiği gibi) sertifika deposunun içeriği tarafından çözümlenediğinden emin olun. Hatanın olası nedenleri şunlar olabilir:

      • parmak izi bildiriminde geçersiz karakterler
      • sertifika yüklü değil
      • sertifikanın süresi doldu
      • ortak ad bildirimi 'CN=' ön ekini içerir
      • bildirimi bir joker karakter belirtir ve sertifika deposunda tam eşleşme yoktur (bildirim: CN=*.mydomain.com, gerçek sertifika: CN=server.mydomain.com)

    • bilinmeyen kimlik bilgileri - genellikle hata koduyla birlikte sertifikaya karşılık gelen eksik bir özel anahtarı gösterir:

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Düzeltmek için özel anahtarın varlığını kontrol edin; SF Yönetici s'e özel anahtara 'okuma|yürütme' erişimi verildiğini doğrulayın.

    • hatalı sağlayıcı türü - Bir Şifreleme Yeni Nesil (CNG) sertifikasını ("Microsoft Yazılım Anahtarı Depolama Sağlayıcısı") gösterir; şu anda Service Fabric yalnızca CAPI1 sertifikalarını destekler. Genellikle hata koduyla birlikte:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Sorunu gidermek için, bir CAPI1 (örneğin, "Microsoft Gelişmiş RSA ve AES Şifreleme Sağlayıcısı") sağlayıcısını kullanarak küme sertifikasını yeniden oluşturun. Şifreleme sağlayıcıları hakkında daha fazla bilgi için bkz. Şifreleme Sağlayıcılarını Anlama