Azure'da görev açısından kritik iş yükleri için ağ ve bağlantı

Ağ, önerilen küresel olarak dağıtılmış etkin-etkin tasarım yaklaşımı göz önünde bulundurulduğunda, görev açısından kritik bir uygulama için temel bir alandır.

Bu tasarım alanı, gerekli bağlantı ve yedekli trafik yönetimi göz önünde bulundurularak uygulama düzeyinde çeşitli ağ topolojisi konularını inceler. Daha ayrıntılı olarak belirtmek gerekirse, görev açısından kritik bir uygulama için güvenli ve ölçeklenebilir bir küresel ağ topolojisinin tasarımını bilgilendirmeye yönelik önemli konuları ve önerileri vurgular.

Önemli

Bu makale, Azure İyi Tasarlanmış görev açısından kritik iş yükü serisinin bir parçasıdır. Bu seriyi bilmiyorsanız görev açısından kritik iş yükü nedir? ile başlamanızı öneririz.

Genel trafik yönlendirme

Birden çok etkin bölgesel dağıtım damgasının kullanılması, trafiği her etkin damgaya dağıtmak için genel bir yönlendirme hizmeti gerektirir.

Azure Front Door, Azure Traffic Manager ve Azure Standart Load Balancer, çok bölgeli bir uygulama genelinde genel trafiği yönetmek için gereken yönlendirme özelliklerini sağlar.

Alternatif olarak, üçüncü taraf küresel yönlendirme teknolojileri de göz önünde bulundurulabilir. Bu seçenekler, Azure'a özel genel yönlendirme hizmetlerinin kullanımını değiştirmek veya genişletmek için neredeyse sorunsuz bir şekilde değiştirilebilir. Popüler seçenekler arasında CDN sağlayıcılarına göre yönlendirme teknolojileri yer alır.

Bu bölümde, farklı senaryoları iyileştirmek için her birinin nasıl kullanılabileceğini tanımlamak için Azure yönlendirme hizmetlerindeki önemli farklar incelenmektedir.

Tasarımla ilgili dikkat edilecek noktalar

• Tek bir bölgeye bağlı yönlendirme hizmeti, tek bir hata noktasını ve bölgesel kesintilerle ilgili önemli bir riski temsil eder.

• Uygulama iş yükü, mobil veya masaüstü istemci uygulamaları gibi istemci denetimini kapsıyorsa, istemci yönlendirme mantığı içinde hizmet yedekliliği sağlamak mümkündür.

  • Azure Front Door ve Azure Traffic Manager gibi birden çok genel yönlendirme teknolojisi yedeklilik için paralel olarak değerlendirilebilir ve istemciler belirli hata koşulları karşılandığında alternatif bir teknolojiye yük devretmek üzere yapılandırılır. Birden çok genel yönlendirme hizmetine giriş, uç önbelleğe alma ve Web Uygulaması Güvenlik Duvarı özellikleri ile SSL boşaltma ve giriş yolları için uygulama doğrulaması için sertifika yönetimiyle ilgili önemli karmaşıklıklar sunar.
  • Üçüncü taraf teknolojileri de göz önünde bulundurularak Azure platformu hatalarının tüm düzeylerine genel yönlendirme dayanıklılığı sağlanır.

• Azure Front Door ile Traffic Manager arasındaki yetenek ayrılığı, iki teknolojinin yedeklilik için birlikte konumlandırılması durumunda tutarlı ve kabul edilebilir bir hizmet düzeyinin korunması için farklı bir giriş yolu veya tasarım değişikliği gerekeceği anlamına gelir.

• Azure Front Door ve Azure Traffic Manager, yerleşik çok bölgeli yedeklilik ve kullanılabilirlik özelliklerine sahip genel olarak dağıtılmış hizmetlerdir.

  • Bu dayanıklı yönlendirme hizmetlerinin genel kullanılabilirliğini tehdit edecek kadar büyük bir ölçeğin varsayımsal hata senaryoları, basamaklı ve bağıntılı hatalar açısından uygulama için daha geniş bir risk sunar.
    • Bu ölçeğin hata senaryolarına yalnızca azure DNS veya Microsoft Entra id gibi neredeyse tüm Azure hizmetleri için genel platform bağımlılıkları görevi gören paylaşılan temel hizmetler neden olur. Yedekli bir Azure teknolojisi uygulanırsa, ikincil hizmette de kullanım dışı veya hizmet düzeyi düşürülmüş olabilir.
    • Genel yönlendirme hizmeti hata senaryolarının, hizmetler arası bağımlılıklar aracılığıyla önemli uygulama bileşenleri için kullanılan diğer birçok hizmeti önemli ölçüde etkileme olasılığı yüksektir. Üçüncü taraf bir teknoloji kullanılsa bile, temel alınan sorunun daha geniş kapsamlı etkisi nedeniyle uygulama büyük olasılıkla iyi durumda olmayacaktır; bu da Azure'daki uygulama uç noktalarına yönlendirmenin yine de çok az değer sağladığı anlamına gelir.

• Genel yönlendirme hizmeti yedekliliği, genel bir kesintinin etkisinin yönlendirme hizmetinin kendisine kısıtlandığı çok az sayıda varsayımsal hata senaryosu için azaltma sağlar.

  Genel kesinti senaryolarına daha fazla yedeklilik sağlamak için çoklu bulut etkin-etkin dağıtım yaklaşımı göz önünde bulundurulabilir. Çok bulutlu etkin-aktif dağıtım yaklaşımı, büyük olasılıkla küresel bir kesintinin varsayımsal risklerinden çok daha ağır basan önemli dayanıklılık riskleri oluşturan önemli operasyonel karmaşıklıklar getirir.

• İstemci denetiminin mümkün olmadığı senaryolarda, tüm etkin dağıtım bölgeleri için birleşik bir giriş noktası sağlamak üzere tek bir genel yönlendirme hizmetinde bir bağımlılık alınmalıdır.

  • Yalıtıldığında, yerleşik çok bölgeli yedeklilik ve kullanılabilirlik sağlansa bile genel bağımlılıklar nedeniyle hizmet düzeyinde tek hata noktasını temsil eder.
  • Seçilen genel yönlendirme hizmeti tarafından sağlanan SLA, kaç dağıtım bölgesi dikkate alındığından bağımsız olarak en yüksek ulaşılabilir bileşik SLA'yı temsil eder.

• İstemci denetimi mümkün olmadığında, genel bir kesinti birincil hizmeti devre dışı bırakırsa ikincil bir genel yönlendirme hizmetine geçiş işlemi tanımlamak için işlem azaltmaları göz önünde bulundurulabilir. Bir genel yönlendirme hizmetinden diğerine geçiş genellikle, özellikle DNS yayma işleminin dikkate alındığı birkaç saat süren uzun bir işlemdir.

• Bazı üçüncü taraf genel yönlendirme hizmetleri %100 SLA sağlar. Ancak bu hizmetler tarafından sağlanan tarihi ve ulaşılabilir SLA genellikle %100'ün altındadır.

  • Bu hizmetler kullanılamazlık için finansal tazminatlar sağlasa da, insan hayatının nihai olarak risk altında olduğu güvenlik açısından kritik senaryolarda olduğu gibi, kullanılamazlığın etkisinin önemli olduğu durumlarda çok az önem taşır. Bu nedenle, tanıtılan yasal SLA %100 olduğunda bile teknoloji yedekliliği veya yeterli operasyonel risk azaltmaları dikkate alınmalıdır.

Azure Front Door

• Azure Front Door, Microsoft genel omurga ağından yararlanmak için bölünmüş TCP ile Anycast protokolünün kullanıldığı genel HTTP/S yük dengeleme ve iyileştirilmiş bağlantı sağlar.

  • Arka uç uç noktalarının her biri için bir dizi bağlantı korunur.
  • Gelen istemci istekleri ilk olarak kaynak istemciye en yakın kenar düğümünde sonlandırılır.
  • Gerekli trafik incelemelerinden sonra istekler, mevcut bağlantılar kullanılarak Microsoft omurgası üzerinden uygun arka uçtan iletilir veya bir kenar düğümünün iç önbelleğinden sunulur.
  • Bu yaklaşım, yüksek trafik hacimlerini arka uç bağlantılarına yayma konusunda etkilidir.

• Uç düğümlerden statik içerik sunan yerleşik bir önbellek sağlar. Birçok kullanım örneğinde bu, ayrılmış bir Content Delivery Network (CDN) gereksinimini de ortadan kaldırabilir.

• Azure Web Uygulaması Güvenlik Duvarı (WAF) Azure Front Door'da kullanılabilir ve dünyanın dört bir yanındaki Azure ağ uç konumlarına dağıtıldığından, Front Door tarafından gönderilen tüm gelen istekler ağ kenarında incelenir.

• Azure Front Door, Azure DDoS koruması Temel'i kullanarak uygulama uç noktalarını DDoS saldırılarına karşı korur. Azure DDoS Standard ek ve daha gelişmiş koruma ve algılama özellikleri sağlar ve Azure Front Door'a ek katman olarak eklenebilir.

• Azure Front Door tam olarak yönetilen bir sertifika hizmeti sunar. Sertifika yaşam döngüsünü yönetmek zorunda kalmadan uç noktalar için TLS bağlantı güvenliğini etkinleştirir.

• Azure Front Door Premium, trafiğin doğrudan İnternet'ten Azure sanal ağlarına akmasını sağlayan özel uç noktaları destekler. Bu, arka uçları Azure Front Door Premium aracılığıyla erişilebilir hale getirmek için sanal ağda genel IP'leri kullanma gereksinimini ortadan kaldırır.

• Azure Front Door, arka ucun normal şekilde çalıştığını ve http 200 (Tamam) yanıtının iyi durumda olduğunu yansıtan bir HTTP durum kodu döndürmek için aralık temelinde çağrılan sistem durumu yoklamalarına ve arka uç sistem durumu uç noktalarına (URL' ler) dayanır. Arka uç, belirli bir kenar düğümü açısından iyi durumda olmayan bir durumu yansıtır yansıtmaz, bu kenar düğümü istek göndermeyi durdurur. Bu nedenle iyi durumda olmayan arka uçlar, gecikme olmadan trafik dolaşımından saydam bir şekilde kaldırılır.

• Yalnızca HTTP/S protokollerini destekler.

• Azure Front Door WAF ve Application Gateway WAF biraz farklı bir özellik kümesi sağlar, ancak hem yerleşik hem de özel kuralları destekler ve algılama modunda veya önleme modunda çalışacak şekilde ayarlanabilir.

• Front Door arka uç IP alanı değişebilir, ancak Microsoft Azure IP Aralıkları ve Hizmet Etiketleri ile tümleştirmeyi güvence altına alır. Tüm değişiklikler veya güncelleştirmeler hakkında bildirim almak için Azure IP Aralıkları ve Hizmet Etiketlerine abone olabilirsiniz.

• Azure Front Door çeşitli yük dağıtım yapılandırmalarını destekler:

  • Gecikme süresi tabanlı: trafiği istemciden "en yakın" arka uca yönlendiren varsayılan ayar; istek gecikme süresine göre.
  • Öncelik tabanlı: Trafiğin kullanılamadığı sürece her zaman birincil arka uca gönderilmesi gereken etkin-pasif kurulumlar için kullanışlıdır.
  • Ağırlıklı: Belirli bir arka uçtan belirli bir trafik yüzdesinin gönderildiği kanarya dağıtımları için geçerlidir. Birden çok arka uç aynı ağırlıklara sahipse gecikme süresi tabanlı yönlendirme kullanılır.

• Varsayılan olarak Azure Front Door, istemcilerin nereden geldiğine bağlı olarak bazı arka uçların diğerlerinden çok daha fazla gelen trafik aldığı durumlara yol açabilen gecikme tabanlı yönlendirme kullanır.

• Bir dizi istemci isteğinin aynı arka uç tarafından işlenmesi gerekiyorsa, Oturum Benzimliği ön uçta yapılandırılabilir. Arka ucun hala kullanılabilir olması koşuluyla, sonraki istekleri ilk istekle aynı arka uca göndermek için istemci tarafı tanımlama bilgisi kullanır.

Azure Traffic Manager

• Azure Traffic Manager bir DNS yeniden yönlendirme hizmetidir.

  • Gerçek istek yükü işlenmez, ancak Traffic Manager bunun yerine seçilen trafik yönlendirme yöntemi için yapılandırılmış kurallara göre havuzun arka uçlarından birinin DNS adını döndürür.
  • Arka uç DNS adı daha sonra doğrudan istemci tarafından çağrılan son IP adresine çözümlenir.

• DNS yanıtı istemci tarafından belirtilen Yaşam Süresi (TTL) dönemi için önbelleğe alınır ve yeniden kullanılır ve bu süre boyunca yapılan istekler Traffic Manager etkileşimi olmadan doğrudan arka uç uç noktasına gider. Front Door ile karşılaştırıldığında maliyet avantajları sağlayan ek bağlantı adımını ortadan kaldırır.

• İstek doğrudan istemciden arka uç hizmetine yapıldığından, arka uç tarafından desteklenen tüm protokollerden yararlanılabilir.

• Azure Front Door'a benzer şekilde Azure Traffic Manager da arka ucun iyi durumda olup olmadığını ve normal şekilde çalıştığını anlamak için sistem durumu yoklamalarına dayanır. Başka bir değer döndürülürse veya hiçbir şey döndürülmezse, yönlendirme hizmeti devam eden sorunları tanır ve istekleri bu belirli arka uçtan yönlendirmeyi durdurur.

  • Ancak Azure Front Door'dan farklı olarak, istemcilerin DNS TTL'nin süresi dolana ve Traffic Manager hizmetinden yeni bir arka uç uç istenene kadar iyi durumda olmayan arka uçlara bağlantılar oluşturmaya devam edeceğinden, iyi durumda olmayan arka uçların kaldırılması anlık değildir.
  • Buna ek olarak, TTL'nin süresi dolsa bile, genel DNS sunucularının bu değere uyacağının garantisi yoktur, bu nedenle DNS yayma işleminin gerçekleşmesi çok daha uzun sürebilir. Bu, trafiğin sürekli bir süre için iyi durumda olmayan uç noktaya gönderilmeye devam edilebileceği anlamına gelir.

Azure Standart Load Balancer

Önemli

Bölgeler Arası Standart Load Balancer teknik sınırlamalarla önizlemede sunulur. Görev açısından kritik iş yükleri için bu seçenek önerilmez.

Tasarım önerileri

• HTTP/S senaryoları için birincil genel trafik yönlendirme hizmeti olarak Azure Front Door kullanın. Azure Front Door, iyileştirilmiş trafik yönlendirme, saydam yük devretme, özel arka uç uç uç noktaları (Premium SKU ile), uç önbelleğe alma ve Web Uygulaması Güvenlik Duvarı (WAF) ile tümleştirme sağladığından HTTP/S iş yükleri için şiddetle destekleniyor.

• İstemci denetiminin mümkün olduğu uygulama senaryolarında, birincil genel yönlendirme teknolojisinin başarısız olduğu yük devretme senaryolarını göz önünde bulundurmak için istemci tarafı yönlendirme mantığı uygulayın. Tek hizmet SLA'sı yeterli değilse, iki veya daha fazla genel yönlendirme teknolojisi ek yedeklilik için paralel olarak konumlandırılmalıdır. Genel hizmet hatası durumunda yedekli teknolojiye yönlendirmek için istemci mantığı gereklidir.

  • Bir yük devretme için genel sertifika yönetimi deneyimini ve yönlendirme mantığını basitleştirmek için farklı genel yönlendirme hizmetlerinin her birine uygulanan iki farklı URL kullanılmalıdır.
  • İkincil yük devretme hizmeti olarak üçüncü taraf yönlendirme teknolojilerinin kullanımına öncelik verin, çünkü bu durum en fazla sayıda genel hata senaryosunu azaltır ve endüstri lideri CDN sağlayıcıları tarafından sunulan özellikler tutarlı bir tasarım yaklaşımı sağlar.
  • Ayrıca ayrı bir yönlendirme hizmeti yerine doğrudan tek bir bölgesel damgaya yönlendirme konusuna da dikkat edilmelidir. Bu, hizmet düzeyinin düşmesine neden olsa da, çok daha basit bir tasarım yaklaşımını temsil eder.

Bu görüntüde, birincil genel yük dengeleyici olarak Azure Front Door kullanılarak istemci yük devretmesi ile yedekli genel yük dengeleyici yapılandırması gösterilmektedir.

Önemli

Azure platformunda genel hata riskini gerçekten azaltmak için, iki veya daha fazla bulut sağlayıcısında barındırılan etkin dağıtım damgaları ve genel yönlendirme için kullanılan yedekli üçüncü taraf yönlendirme teknolojileri ile çok bulutlu etkin-etkin dağıtım yaklaşımı dikkate alınmalıdır.

Azure, diğer bulut platformlarıyla etkili bir şekilde tümleştirilebilir. Ancak, farklı bulut platformlarında farklı dağıtım damgası tanımları ve operasyonel durum gösterimleri ile önemli bir operasyonel karmaşıklık sağladığından çok bulutlu bir yaklaşım uygulamamanızı kesinlikle öneririz. Bu karmaşıklık, uygulamanın normal çalışmasında çok sayıda dayanıklılık riski getirir ve bu da küresel bir platform kesintisinin varsayımsal risklerinden çok daha ağır basıyor.

• Önerilmiyor olsa da Azure Front Door'a genel yönlendirme yedekliliği için Azure Traffic Manager kullanan HTTP(ler) iş yükleri için, Azure Front Door üzerinden akan kabul edilebilir trafik için Web Uygulaması Güvenlik Duvarı (WAF) Application Gateway'e boşaltmayı göz önünde bulundurun.
  • Bu, standart giriş yoluna ek bir hata noktası, yönetmek ve ölçeklendirmek için ek bir kritik yol bileşeni sağlar ve ayrıca genel yüksek kullanılabilirliği sağlamak için ek maliyetler doğuracaktır. Bununla birlikte, Azure Front Door ve Azure Traffic Manager aracılığıyla hem WAF yürütmesi hem de özel uygulama uç noktaları açısından kabul edilebilir ve kabul edilemez giriş yolları arasında tutarlılık sağlayarak hata senaryosunu büyük ölçüde basitleştirir.
  • Hata senaryosunda uç önbelleğe alma kaybının genel performansı etkilemesi ve bunun kabul edilebilir bir hizmet düzeyi veya azaltıcı tasarım yaklaşımıyla uyumlu olması gerekir. Tutarlı bir hizmet düzeyi sağlamak için uç önbelleğini her iki yol için de bir üçüncü taraf CDN sağlayıcısına boşaltmayı göz önünde bulundurun.

İki Azure genel yönlendirme hizmeti yerine üçüncü taraf genel yönlendirme hizmetini göz önünde bulundurmanız önerilir. Bu, endüstri lideri CDN sağlayıcılarının çoğu Azure Front Door tarafından sunulan özelliklerle büyük ölçüde tutarlı uç özellikler sunduğundan en yüksek hata azaltma düzeyini ve daha basit bir tasarım yaklaşımını sağlar.

Azure Front Door

• TLS bağlantılarını etkinleştirmek ve sertifika yaşam döngülerini yönetme gereksinimini ortadan kaldırmak için Azure Front Door yönetilen sertifika hizmetini kullanın.

• Uçta SQL ekleme gibi yaygın web açıklarına ve güvenlik açıklarına karşı koruma sağlamak için Azure Front Door Web Uygulaması Güvenlik Duvarı (WAF) kullanın.

• Uç düğümlerden statik içerik sunmak için Azure Front Door yerleşik önbelleğini kullanın.

  • Çoğu durumda bu, ayrılmış bir Content Delivery Network (CDN) gereksinimini de ortadan kaldırır.

• Tüm trafiğin yapılandırılmış Front Door örneğinden akmasını sağlamak için X-Azure-FDID kullanarak üst bilgi tabanlı filtreleme aracılığıyla gelen istekleri doğrulamak için uygulama platformu giriş noktalarını yapılandırın. Trafiğin Azure Front Door arka uç IP adresi alanından ve Azure altyapı hizmetlerinden geldiğini doğrulamak için Front Door Hizmet Etiketlerini kullanarak IP ALING'i yapılandırmayı da göz önünde bulundurun. Bu, Azure Front Door üzerinden hizmet düzeyinde trafik akışını sağlar, ancak yapılandırılmış bir Front Door örneğinin kullanımından emin olmak için üst bilgi tabanlı filtreleme gerekli olmaya devam eder.

• Temel başvuru uygulaması tarafından sağlanan örnekte Azure Cosmos DB gibi veri platformu çoğaltmaları da dahil olmak üzere bölgesel dağıtım damgası içindeki kritik aşağı akış bağımlılıklarını doğrulamak için özel bir TCP sistem durumu uç noktası tanımlayın. Bir veya daha fazla bağımlılık iyi durumda değilse sistem durumu yoklaması, bölgesel damganın tamamının dolaşımdan çıkarılabilmesi için döndürülen yanıta bunu yansıtmalıdır.

• Sistem durumu yoklama yanıtlarının günlüğe kaydedildiğinden ve Azure Front Door tarafından kullanıma sunulan tüm işletimsel verilerin genel Log Analytics çalışma alanına alındığından emin olun. Bu sayede uygulamanın tamamında birleşik bir veri havuzu ve tek işlemsel görünüm kolaylaştırabilirsiniz.

• İş yükü son derece gecikme süresine duyarlı olmadığı sürece, dağıtılan kaynakları en etkili şekilde kullanmak için trafiği tüm kabul edilen bölgesel damgalara eşit olarak dağıtın.

  • Bunu başarmak için "Gecikme Süresi Duyarlılığı (Ek Gecikme)" parametresini arka uçların farklı bölgeleri arasındaki gecikme süresi farklarını karşılayacak kadar yüksek bir değere ayarlayın. Genel istemci isteği gecikme süresiyle ilgili olarak uygulama iş yükü için kabul edilebilir bir tolerans sağlayın.

• Trafik dağılımının dengesini olumsuz etkileyebileceğinden, uygulama tarafından gerekli olmadıkça Oturum Benzimi'ni etkinleştirmeyin. Tam durum bilgisi olmayan bir uygulamayla, önerilen görev açısından kritik uygulama tasarım yaklaşımına uyulursa, tüm istekler bölgesel dağıtımlardan herhangi biri tarafından işlenebilir.

Azure Traffic Manager

• Azure Front Door'un yerine HTTP/S olmayan senaryolar için Traffic Manager'ı kullanın. Yetenek farklılıkları, önbellek ve WAF özellikleri ve TLS sertifika yönetimi için farklı tasarım kararları alınmasını sağlar.

• Azure Uygulaması lication Gateway kullanılarak Traffic Manager giriş yolu için her bölgede WAF özellikleri dikkate alınmalıdır.

• Arka ucun iyi durumda olması durumunda iyi durumda olmayan bir arka uç uç noktasının dolaşımdan kaldırılması için gereken süreyi iyileştirmek için uygun bir düşük TTL değeri yapılandırın.

• Azure Front Door'a benzer şekilde, bölgesel dağıtım damgası içindeki kritik aşağı akış bağımlılıklarını doğrulamak için özel bir TCP sistem durumu uç noktası tanımlanmalıdır ve bu durum uç noktaları tarafından sağlanan yanıta yansıtılmalıdır.

  Ancak Traffic Manager için hizmet düzeyi bölgesel yük devretmeye ek dikkat edilmelidir. özellikle DNS kayıtları için düşük bir TTL ayarlamak mümkün değilse, bağımlılık hataları nedeniyle iyi durumda olmayan bir arka ucun kaldırılmasıyla ilişkili olası gecikmeyi azaltmak için 'köpek etiketlemesi' gibi.

• Azure Traffic Manager'ı birincil genel yönlendirme hizmeti olarak kullanırken uç önbelleğe alma elde etmek için üçüncü taraf CDN sağlayıcılarına dikkat edilmelidir. Uç WAF özelliklerinin üçüncü taraf hizmet tarafından da sunulduğu durumlarda, giriş yolunu basitleştirmek ve Application Gateway gereksinimini ortadan kaldırmak için dikkate alınması gerekir.

Uygulama teslim hizmetleri

Görev açısından kritik bir uygulamanın ağ giriş yolu, güvenli, güvenilir ve ölçeklenebilir giriş trafiği sağlamak için uygulama teslim hizmetlerini de dikkate almalıdır.

Bu bölüm, Azure Standart Load Balancer, Azure Uygulaması lication Gateway ve Azure API Management gibi ilgili hizmetleri göz önünde bulundurarak temel uygulama teslim özelliklerini inceleyerek genel yönlendirme önerilerini temel alır.

Tasarımla ilgili dikkat edilecek noktalar

• TLS şifrelemesi, görev açısından kritik bir uygulamaya gelen kullanıcı trafiğinin bütünlüğünü sağlamak için kritik öneme sahiptir ve TLS Boşaltma yalnızca gelen trafiğin şifresini çözmek için damga pulu giriş noktasına uygulanır. TLS Boşaltma Trafiğin şifresini çözmek için TLS sertifikasının özel anahtarını gerektirir.

• Web Uygulaması Güvenlik Duvarı, SQL ekleme veya siteler arası betik oluşturma gibi yaygın web açıklarına ve güvenlik açıklarına karşı koruma sağlar ve görev açısından kritik bir uygulamanın maksimum güvenilirlik hedeflerine ulaşmak için gereklidir.

• Azure WAF, yönetilen kural kümelerini kullanarak ilk 10 OWASP güvenlik açığına karşı kullanıma açık koruma sağlar.

  • Yönetilen kural kümesini genişletmek için özel kurallar da eklenebilir.
  • Azure WAF, Azure Front Door, Azure Uygulaması lication Gateway veya Azure CDN (şu anda genel önizleme aşamasındadır) içinde etkinleştirilebilir.
    • Hizmetlerin her birinde sunulan özellikler biraz farklılık gösterir. Örneğin, Azure Front Door WAF henüz Application Gateway WAF içinde sunulmayan hız sınırlama, coğrafi filtreleme ve bot koruması sağlar. Ancak bunların tümü hem yerleşik hem de özel kuralları destekler ve algılama modunda veya önleme modunda çalışacak şekilde ayarlanabilir.
    • Azure WAF yol haritası, tüm hizmet tümleştirmelerinde tutarlı bir WAF özellik kümesinin sağlanmasını sağlar.

• Kubernetes içindeki NVA'lar ve gelişmiş giriş denetleyicileri gibi üçüncü taraf WAF teknolojileri de gerekli güvenlik açığı koruması sağlamak için göz önünde bulundurulabilir.

• En uygun WAF yapılandırması, kullanılan teknolojiden bağımsız olarak genellikle ince ayar gerektirir.

  Azure Front Door

• Azure Front Door yalnızca HTTP ve HTTPS trafiğini kabul eder ve yalnızca bilinen Host üst bilgi içeren istekleri işler. Bu protokol engelleme, protokollere ve bağlantı noktalarına yayılan hacimli saldırıların ve DNS amplifikasyon ve TCP zehirleme saldırılarının azaltılmasına yardımcı olur.

• Azure Front Door genel bir Azure kaynağı olduğundan yapılandırma tüm uç konumlara genel olarak dağıtılır.

  • Kaynak yapılandırması, saniyede yüz binlerce isteği işlemek için büyük ölçekte dağıtılabilir.
  • Yollar ve arka uç havuzları dahil olmak üzere yapılandırmaya Güncelleştirmeler sorunsuz olur ve dağıtım sırasında kapalı kalma süresine neden olmaz.

• Azure Front Door, istemciye yönelik SSL sertifikaları için hem tam olarak yönetilen bir sertifika hizmeti hem de kendi sertifikanızı getirme yöntemi sağlar. Tam olarak yönetilen sertifika hizmeti basitleştirilmiş bir işlem yaklaşımı sağlar ve çözümün tek bir alanında sertifika yönetimi gerçekleştirerek genel tasarımdaki karmaşıklığı azaltmaya yardımcı olur.

• Azure Front Door, süresi dolan sertifika risklerine karşı koruma sağlamak için "Yönetilen" sertifikaları sertifika süresi dolmadan en az 60 gün önce otomatik olarak döndürür. Kendi kendine yönetilen sertifikalar kullanılıyorsa, güncelleştirilmiş sertifikaların mevcut sertifikanın süresi dolmadan en geç 24 saat önce dağıtılması gerekir, aksi takdirde istemciler süresi dolmuş sertifika hataları alabilir.

• Sertifika güncelleştirmeleri yalnızca Azure Front Door "Yönetilen" ile "Kendi Sertifikanızı Kullanın" arasında geçiş yapılırsa kapalı kalma süresiyle sonuçlanır.

• Azure Front Door, varsayılan olarak Front Door ile tümleştirilmiş olan Azure DDoS Protection Basic ile korunur. Bu, her zaman açık trafik izleme, gerçek zamanlı azaltma sağlar ve ayrıca yaygın Katman 7 DNS sorgusu taşmalarına veya Katman 3/4 hacimli saldırılara karşı savunma sağlar.

  • Bu korumalar, DDoS saldırısıyla karşılaşıldığında bile Azure Front Door kullanılabilirliğini korumaya yardımcı olur. Dağıtılmış Hizmet Reddi (DDoS) saldırıları, hedeflenen bir kaynağı gayrimeşru trafikle bunaltarak kullanılamaz duruma getirebilir.

• Azure Front Door ayrıca küresel trafik düzeyinde WAF özellikleri sağlarken Application Gateway WAF'nin her bölgesel dağıtım damgası içinde sağlanması gerekir. Özellikler arasında yaygın saldırılara, coğrafi filtrelemeye, adres engellemeye, hız sınırlamaya ve imza eşleştirmeye karşı korunmaya yönelik güvenlik duvarı kural kümeleri bulunur.

  Azure Load Balancer

• Azure Basic Load Balancer SKU'su bir SLA tarafından desteklenmez ve Standart SKU ile karşılaştırıldığında çeşitli yetenek kısıtlamalarına sahiptir.

Tasarım önerileri

• Sertifika yönetimi yaşam döngüsünü basitleştirirken güvenliği korumak için TLS Boşaltma işlemini mümkün olduğunca az yerde gerçekleştirin.

• TLS boşaltma işleminin gerçekleştiği noktadan gerçek uygulama arka uçlarına şifrelenmiş bağlantılar (örneğin HTTPS) kullanın. Uygulama uç noktaları son kullanıcılar tarafından görülmeyeceği için veya cloudapp.netgibi azurewebsites.net Azure tarafından yönetilen etki alanları yönetilen sertifikalarla kullanılabilir.

• HTTP(S) trafiği için, genel kullanıma sunulan tüm uç noktalar için giriş yolunda WAF özelliklerinin uygulandığından emin olun.

• Azure Front Door ile genel olarak veya Azure Uygulaması lication Gateway ile bölgesel olarak WAF özelliklerini tek bir hizmet konumunda etkinleştirin, çünkü bu yapılandırma ince ayarını basitleştirir ve performansı ve maliyeti iyileştirir.

  WaF'yi Önleme modunda saldırıları doğrudan engelleyecek şekilde yapılandırın. Önleme modunun performans cezası çok yüksek olduğunda WAF'yi yalnızca Algılama modunda kullanın (yalnızca günlüğe kaydetme ancak şüpheli istekleri engellememe). Zımni ek risk tamamen anlaşılmalı ve iş yükü senaryosunun belirli gereksinimlerine uygun olmalıdır.

• En zengin Azure yerel özellik kümesini sağladığından ve genel tasarımı basitleştiren ve daha fazla verimlilik sağlayan genel uçta korumalar uyguladığından Azure Front Door WAF'nin kullanımına öncelik verme.

• Azure API Management'ı yalnızca çok sayıda API'yi dış istemcilere veya farklı uygulama ekiplerine sunarken kullanın.

• Mikro hizmet iş yükleri içindeki tüm iç trafik dağıtım senaryoları için Azure Standart Load Balancer SKU'yu kullanın.

  • Kullanılabilirlik Alanları dağıtıldığında %99,99 SLA sağlar.
  • Tanılama veya giden kuralları gibi kritik özellikler sağlar.

• Her uygulama sanal ağında barındırılan genel uç noktaların korunmasına yardımcı olmak için Azure DDoS Ağ Koruması kullanın.

Önbelleğe Alma ve statik içerik teslimi

Görüntüler, JavaScript, CSS ve diğer dosyalar gibi statik içeriğin özel olarak işlenmesi, genel kullanıcı deneyimi ve çözümün genel maliyeti üzerinde önemli bir etkiye sahip olabilir. Uçtaki statik içerik Önbelleğe Alma istemci yükleme sürelerini hızlandırarak daha iyi bir kullanıcı deneyimine neden olabilir ve ayrıca trafik, okuma işlemleri ve arka uç hizmetlerindeki işlem gücü maliyetlerini düşürebilir.

Tasarımla ilgili dikkat edilecek noktalar

• Bir çözümün İnternet üzerinden kullanılabilir hale getirdiği tüm içerik dinamik olarak oluşturulmaz. Uygulamalar hem statik varlıklara (görüntüler, JavaScript, CSS, yerelleştirme dosyaları vb.) hem de dinamik içeriğe hizmet eder.
• Sık erişilen statik içeriğe sahip iş yükleri, arka uç hizmetlerindeki yükü azalttığı ve son kullanıcılar için içerik erişim gecikme süresini azalttığı için önbelleğe alma özelliğinden büyük ölçüde yararlanır.
• Önbelleğe Alma, Azure Front Door veya Azure Content Delivery Network (CDN) kullanılarak Azure içinde yerel olarak uygulanabilir.
  • Azure Front Door , statik ve dinamik içeriği bölmek için Azure'a özel uç önbelleğe alma özellikleri ve yönlendirme özellikleri sağlar.
    • Azure Front Door'da uygun yönlendirme kuralları oluşturularak trafik /static/* saydam bir şekilde statik içeriğe yönlendirilebilir.
  • Azure CDN hizmeti kullanılarak, önemli statik içerik hacimleri için tam teşekküllü bir içerik teslim ağı oluşturmak üzere daha karmaşık önbelleğe alma senaryoları uygulanabilir.
    • Azure CDN hizmeti büyük olasılıkla daha uygun maliyetli olacaktır, ancak uygulama tasarımının diğer alanları için önerilen gelişmiş yönlendirme ve Web Uygulaması Güvenlik Duvarı (WAF) özelliklerini sağlamaz. Ancak, Akamai ve Verizon gibi üçüncü taraf çözümlerinin benzer hizmetleriyle tümleştirme esnekliği sunar.
  • Azure Front Door ve Azure CDN hizmetleri karşılaştırılırken aşağıdaki karar faktörleri araştırılmalıdır:
    • Gerekli önbelleğe alma kuralları, kural altyapısı kullanılarak gerçekleştirilebilir.
    • Depolanan içeriğin boyutu ve ilişkili maliyet.
    • Kural altyapısının yürütülmesi için aylık fiyat (Azure Front Door'ta istek başına ücretlendirilir).
    • Giden trafik gereksinimleri (fiyat hedefe göre farklılık gösterir).

Tasarım önerileri

• Hiçbir zaman veya yalnızca nadiren değişen görüntü dosyalarının boyutlandırılmış kopyaları gibi oluşturulan statik içerik de önbelleğe alma avantajından yararlanabilir. Önbelleğe Alma, URL parametrelerine göre ve değişen önbelleğe alma süresiyle yapılandırılabilir.
• Arka uç hizmetlerindeki yükü azaltmak için statik ve dinamik içeriğin kullanıcılara teslimini ayırın ve ilgili içeriği önbellekten teslim edin ve son kullanıcılar için performansı iyileştirin.
• Azure Front Door'un genel yönlendirme ve Web Uygulaması Güvenlik Duvarı (WAF) amacıyla kullanılmasına yönelik güçlü öneri (Ağ ve bağlantı tasarım alanı) göz önünde bulundurulduğunda, boşluklar olmadığı sürece Azure Front Door önbelleğe alma özelliklerinin kullanımına öncelik verilmesi önerilir.

Sanal ağ tümleştirmesi

Görev açısından kritik bir uygulama genellikle Azure'da, başka bir genel bulutta veya şirket içi veri merkezlerinde barındırılabilen diğer uygulamalar veya bağımlı sistemlerle tümleştirme gereksinimlerini kapsar. Bu uygulama tümleştirmesi, genel kullanıma yönelik uç noktalar ve İnternet ya da ağ düzeyinde tümleştirme aracılığıyla özel ağlar kullanılarak gerçekleştirilebilir. Sonuç olarak, uygulama tümleştirmesinin elde edilen yöntemi çözümün güvenliği, performansı ve güvenilirliği üzerinde önemli bir etkiye sahip olacak ve diğer tasarım alanlarındaki tasarım kararlarını güçlü bir şekilde etkileyecektir.

Görev açısından kritik bir uygulama, uygulama tümleştirmesinin ağ düzeyinde nasıl gerçekleşebileceğini belirleyen üç ağ yapılandırmasından birinde dağıtılabilir.

1. Kurumsal ağ bağlantısı olmayan genel uygulama.
2. Kurumsal ağ bağlantısı olan genel uygulama.
3. Kurumsal ağ bağlantısı olan özel uygulama.

Dikkat

Azure giriş bölgesi içinde dağıtım yaparken yapılandırma 1. bir Çevrimiçi Giriş Bölgesi içinde dağıtılırken, hem 2) hem de 3) ağ düzeyinde tümleştirmeyi kolaylaştırmak için Corp. Bağlan ed Landing Zone içinde dağıtılmalıdır.

Bu bölümde, tümleştirme gereksinimlerinin en uygun şekilde karşılandığından emin olmak için Azure Sanal Ağ ve çevresindeki Azure ağ hizmetlerinin uygun kullanımına yönelik katmanlama, bu ağ tümleştirme senaryoları incelenmektedir.

Tasarım Konusunda Dikkat Edilmesi Gerekenler

Sanal ağ yok

• En basit tasarım yaklaşımı, uygulamayı bir sanal ağ içinde dağıtmamaktır.

  • Kabul edilen tüm Azure hizmetleri arasındaki Bağlan üretkenliği tamamen genel uç noktalar ve Microsoft Azure omurgası aracılığıyla sağlanacaktır. Azure'da barındırılan genel uç noktalar arasındaki Bağlan yalnızca Microsoft omurgasını geçer ve genel İnternet üzerinden gitmez.
  • Azure dışındaki tüm dış sistemlere Bağlan üretkenlik, genel İnternet tarafından sağlanacaktır.

• Bu tasarım yaklaşımı, çeşitli hizmet bileşenleriyle bağımlı çözüm arasında erişim denetimi sağlamak için "güvenlik çevresi olarak kimlik" yaklaşımını benimser. Bu, güvenliğe daha az duyarlı senaryolar için kabul edilebilir bir çözüm olabilir. Tüm uygulama hizmetleri ve bağımlılıklarına genel bir uç nokta üzerinden erişilebilir olması, yetkisiz erişim elde etme konusunda yönlendirilen ek saldırı vektörlerine karşı savunmasız bırakır.

• Aks gibi birçok hizmetin temel alınan bir sanal ağ için zor bir gereksinimi olduğundan, bu tasarım yaklaşımı tüm Azure hizmetleri için de geçerli değildir.

Yalıtılmış sanal ağlar

• Gereksiz genel uç noktalarla ilişkili riskleri azaltmak için, uygulama diğer ağlara bağlı olmayan tek başına bir ağ içinde dağıtılabilir.

• Gelen istemci istekleri yine de genel bir uç noktanın İnternet'e açık olmasını gerektirir, ancak sonraki tüm iletişimler özel uç noktalar kullanılarak sanal ağ içinde olabilir. Azure Front Door Premium kullanırken, uç düğümlerden özel uygulama uç noktalarına doğrudan yönlendirmek mümkündür.

• Uygulama bileşenleri arasındaki özel bağlantı sanal ağlar üzerinden gerçekleşse de, dış bağımlılıklara sahip tüm bağlantılar yine de genel uç noktalara dayanır.

  • Destekleniyorsa Özel Uç Noktalar ile Azure platform hizmetlerine Bağlan üretkenlik oluşturulabilir. Azure'da başka bir aşağı akış uygulaması gibi başka dış bağımlılıklar varsa genel uç noktalar ve Microsoft Azure omurgası üzerinden bağlantı sağlanır.
  • Azure dışındaki tüm dış sistemlere Bağlan üretkenliği genel İnternet tarafından sağlanacaktır.

• Dış bağımlılıklar için ağ tümleştirme gereksinimlerinin olmadığı senaryolarda, çözümü yalıtılmış bir ağ ortamında dağıtmak en yüksek tasarım esnekliğini sağlar. Daha geniş ağ tümleştirmesiyle ilişkili adresleme ve yönlendirme kısıtlaması yok.

• Azure Bastion, bir sanal ağa dağıtılabilen ve Azure VM'lerine güvenli RDP/SSH bağlantısı sağlayan, tam olarak platform tarafından yönetilen bir PaaS hizmetidir. Azure Bastion üzerinden bağlandığınızda sanal makinelerin genel IP adresine ihtiyacı yoktur.

• Uygulama sanal ağlarının kullanımı, uygulama dağıtımlarını kolaylaştırmak için hem veri düzlemi hem de özel ağlarda barındırılan kaynaklara denetim düzlemi erişimi gerektiğinden CI/CD işlem hatlarında önemli dağıtım karmaşıklıkları getirir.

  • CI/CD araçlarının gerekli eylemleri gerçekleştirmesine izin vermek için güvenli özel ağ yolu oluşturulmalıdır.
  • Özel derleme aracıları, sanal ağ tarafından güvenli hale getirilen kaynaklara ara sunucu erişimi sağlamak için uygulama sanal ağlarında dağıtılabilir.

Bağlan sanal ağlar

• Dış ağ tümleştirme gereksinimleri olan senaryolar için, uygulama sanal ağları çeşitli bağlantı seçenekleri kullanılarak Azure'daki diğer sanal ağlara, başka bir bulut sağlayıcısına veya şirket içi ağlara bağlanabilir. Örneğin, bazı uygulama senaryoları şirket içi bir şirket ağı içinde özel olarak barındırılan diğer iş kolu uygulamalarıyla uygulama düzeyinde tümleştirmeyi göz önünde bulundurabilir.

• Uygulama ağ tasarımı, özellikle adresleme ve yönlendirme gibi konularla ilgili olarak daha geniş ağ mimarisiyle uyumlu olmalıdır.

• Azure bölgeleri veya şirket içi ağlar arasında çakışan IP adresi alanları, ağ tümleştirmesi dikkate alındığında büyük çekişmeler oluşturur.

  • Bir sanal ağ kaynağı ek adres alanını dikkate alacak şekilde güncelleştirilebilir, ancak eşlenmiş bir ağın sanal ağ adres alanı değiştiğinde eşleme bağlantısında eşitleme gerekir ve bu da eşlemeyi geçici olarak devre dışı bırakır.
  • Azure, her alt ağ içinde beş IP adresi ayırır. Bu adres, uygulama sanal ağları ve kapsadığı alt ağlar için uygun boyutları belirlerken dikkate alınmalıdır.
  • Bazı Azure hizmetleri için Azure Bastion, Azure Güvenlik Duvarı veya Azure Sanal Ağ Gateway gibi ayrılmış alt ağlar gerekir. Bu hizmet alt ağlarının boyutu çok önemlidir, çünkü gelecekteki ölçek gereksinimlerini göz önünde bulundurarak hizmetin tüm geçerli örneklerini destekleyecek kadar büyük olmaları gerekir, ancak gereksiz yere atık adreslerine kadar büyük olmamalıdır.

• Şirket içi veya bulutlar arası ağ tümleştirmesi gerektiğinde, Azure güvenli bir bağlantı kurmak için iki farklı çözüm sunar.

  • ExpressRoute bağlantı hattı, 100 Gb/sn'ye kadar bant genişliği sağlayacak şekilde boyutlandırılabilir.
  • Sanal Özel Ağ (VPN), merkez-uç ağlarında 10 Gb/sn'ye kadar ve Azure Sanal WAN'de 20 Gb/sn'ye kadar toplu bant genişliği sağlayacak şekilde boyutlandırılabilir.

Not

Azure giriş bölgesi içinde dağıtım yaparken, şirket içi ağlara gereken tüm bağlantıların giriş bölgesi uygulaması tarafından sağlanması gerektiğini unutmayın. Tasarım, Sanal WAN veya merkez-uç ağ tasarımı kullanarak ExpressRoute'u ve Azure'daki diğer sanal ağları kullanabilir.

• Ek ağ yollarının ve kaynakların dahil edilmesi, uygulamanın sistem durumunun korunmasını sağlamak için ek güvenilirlik ve operasyonel konulara neden oluyor.

Tasarım önerileri

• Azure sanal ağlarında gereksiz genel uç noktaların kaldırılması mümkün olduğunda görev açısından kritik çözümlerin dağıtılması önerilir ve bu da uygulama saldırı yüzeyini güvenlik ve güvenilirliği en üst düzeye çıkarmak için sınırlandırır.

  • Azure platform hizmetlerine bağlantı için Özel Uç Noktaları kullanın. Hizmet Uç Noktaları, Özel Bağlantı desteklemeyen hizmetler için göz önünde bulundurulabilir, veri sızdırma riskleri kabul edilebilir veya alternatif denetimlerle giderilebilir.

• Kurumsal ağ bağlantısı gerektirmeyen uygulama senaryolarında, tüm sanal ağları yeni bir bölgesel dağıtım gerçekleştirildiğinde değiştirilen kısa ömürlü kaynaklar olarak değerlendirin.

• Diğer Azure veya şirket içi ağlara bağlanırken, sanal ağ eşlemesi ve sanal ağ geçidi kaynaklarının ilgili olduğu önemli komplikasyonlar oluşturduğundan, uygulama sanal ağları kısa ömürlü olarak değerlendirilmemelidir. Sanal ağ içindeki tüm ilgili uygulama kaynakları, güncelleştirilmiş bölgesel dağıtım damgalarının mavi-yeşil dağıtımlarını kolaylaştırmak için kullanılan paralel alt ağlarla kısa ömürlü olmaya devam etmelidir.

• Özel ağlar üzerinden uygulama tümleştirmesini kolaylaştırmak için kurumsal ağ bağlantısının gerekli olduğu senaryolarda, bölgesel uygulama sanal ağları için kullanılan IPv4 adres alanının diğer bağlı ağlarla çakışmadığından ve sanal ağ kaynağını güncelleştirmeye ve kapalı kalma süresine neden olmadan gerekli ölçeği kolaylaştıracak şekilde düzgün boyutlandırıldığına emin olun.

  • Özel internet (RFC 1918) için yalnızca adres ayırmadaki IP adreslerinin kullanılması kesinlikle önerilir.
    • Özel IP adreslerinin (RFC 1918) sınırlı kullanılabilirliğine sahip ortamlar için IPv6 kullanmayı göz önünde bulundurun.
    • Genel IP adresinin kullanılması gerekiyorsa, yalnızca sahip olunan adres bloklarının kullanıldığından emin olun.
  • Uygulama ağı IP adresi alanının şirket içi konumlardaki veya Azure bölgelerindeki diğer ağlarla çakışmadığından emin olmak için Azure'da IP adresleme için kuruluş planlarıyla uyumlu hale getirme.
  • IP adresi alanının boşa harcanmadığından emin olmak için gereksiz büyük uygulama sanal ağları oluşturmayın.

• Daha zengin bir özellik kümesini desteklediğinden AKS ağ tümleştirmesi için Azure CNI'yi kullanma önceliklerini belirleyin.

  • Uygulamayı kısıtlanmış bir adres alanına sığdırmak için kullanılabilir IP adreslerinin sınırlı olduğu senaryolar için Kubenet'i göz önünde bulundurun.

  • AKS ağ tümleştirmesi için Azure CNI ağ eklentisinin kullanımına öncelik ve sınırlı sayıda kullanılabilir IP adresi içeren senaryolar için Kubenet'i göz önünde bulundurun. Daha fazla ayrıntı için bkz . Mikro segmentasyon ve kubernetes ağ ilkeleri .

• Şirket içi ağ tümleştirmesi gerektiren senaryolar için güvenli ve ölçeklenebilir bağlantı sağlamak için Express Route'un kullanımına öncelik sağlayın.

  • Express Route veya VPN'e uygulanan güvenilirlik düzeyinin uygulama gereksinimlerini tam olarak karşıladığından emin olun.
  • Gerektiğinde çapraz bağlı ExpressRoute bağlantı hatları veya yük devretme bağlantı mekanizması olarak VPN kullanımı gibi ek yedeklilik sağlamak için birden çok ağ yolu dikkate alınmalıdır.

• Kritik ağ yollarındaki tüm bileşenlerin, bu yolların ve ilişkili bileşenin yönetiminin merkezi BT ekiplerinden oluşan uygulama ekibi tarafından teslim edilip edilmediğine bakılmaksızın ilişkili kullanıcı akışlarının güvenilirlik ve kullanılabilirlik gereksinimlerine uygun olduğundan emin olun.

  Not

  Azure giriş bölgesi içinde dağıtım yaparken ve daha geniş bir kurumsal ağ topolojisiyle tümleştirildiğinde, temel ağın Microsoft en iyi yöntemleriyle uyumlu olduğundan emin olmak için ağ kılavuzunu göz önünde bulundurun.

• Azure kaynaklarının veri düzlemine erişmek veya yönetim işlemleri gerçekleştirmek için Azure Bastion'ı veya proksied private bağlantılarını kullanın.

İnternet çıkışı

İnternet çıkışı, aşağıdakiler bağlamında dış iletişimi kolaylaştırmak için görev açısından kritik bir uygulamanın temel ağ gereksinimidir:

1. Doğrudan uygulama kullanıcı etkileşimi.
2. Azure dışındaki dış bağımlılıklarla uygulama tümleştirmesi.
3. Uygulama tarafından kullanılan Azure hizmetlerinin gerektirdiği dış bağımlılıklara erişim.

Bu bölümde güvenlik, güvenilirlik ve sürdürülebilir performansın korunması sağlanırken İnternet çıkışının nasıl sağlandığı incelenir ve görev açısından kritik bir bağlamda önerilen hizmetler için temel çıkış gereksinimleri vurgulanır.

Tasarım Konusunda Dikkat Edilmesi Gerekenler

• Birçok Azure hizmeti, çeşitli yönetim ve denetim düzlemi işlevlerinin amaçlandığı gibi çalışması için genel uç noktalara erişim gerektirir.

• Azure, bir sanal ağdaki sanal makineler veya işlem örnekleri için Azure NAT ağ geçidi veya Azure Load Balancer gibi farklı doğrudan İnternet giden bağlantı yöntemleri sağlar.

• Sanal ağın içinden gelen trafik İnternet'e gittiği zaman Ağ Adresi Çevirisi (NAT) gerçekleşmelidir. Bu, ağ yığını içinde gerçekleşen ve bu nedenle sistem performansını etkileyebilecek bir işlem işlemidir.

• NAT küçük ölçekte gerçekleştiğinde performans etkisi göz ardı edilebilir olmalıdır, ancak çok fazla sayıda giden istek varsa ağ sorunları oluşabilir. Bu sorunlar genellikle 'Kaynak NAT (veya SNAT) bağlantı noktası tükenmesi' biçiminde gelir.

• Azure Uygulaması Hizmeti gibi çok kiracılı bir ortamda, her örnek için sınırlı sayıda giden bağlantı noktası vardır. Bu bağlantı noktaları tükenirse yeni giden bağlantı başlatılamaz. Bu sorun, özel/genel uç geçişi sayısı azaltılarak veya Azure NAT Gateway gibi daha ölçeklenebilir bir NAT çözümü kullanılarak azaltılabilir.

• NAT sınırlamalarına ek olarak, giden trafik de gerekli güvenlik denetimlerine tabi olabilir.

  • Azure Güvenlik Duvarı, ağ çıkışını güvenli bir şekilde sağlamak için uygun güvenlik özellikleri sağlar.

  • Azure Güvenlik Duvarı (veya eşdeğer bir NVA), giden trafik akışları üzerinde ayrıntılı denetim sağlayarak Kubernetes çıkış gereksinimlerini güvenli hale getirmek için kullanılabilir.

• Büyük hacimlerde İnternet çıkışı, veri aktarımı ücretlerine neden olur.

Azure NAT Ağ Geçidi

• Azure NAT Gateway, atanan giden IP adresi başına TCP ve UDP için 64.000 bağlantıyı destekler.

  • Tek bir NAT ağ geçidine en fazla 16 IP adresi atanabilir.
  • Varsayılan TCP boşta kalma zaman aşımı 4 dakikadır. Boşta kalma zaman aşımı daha yüksek bir değerle değiştirilirse akışlar daha uzun süre tutulur ve bu da SNAT bağlantı noktası envanteri üzerindeki baskıyı artırır.

• NAT ağ geçidi, kullanıma sunulan bölgesel yalıtım sağlayamaz. Bölgesel yedeklilik elde etmek için, bölgesel kaynakları içeren bir alt ağın ilgili bölgesel NAT ağ geçitleriyle uyumlu olması gerekir.

Tasarım önerileri

• Nat performansını etkileyene kadar giden İnternet bağlantısı sayısını en aza indirin.

  • Çok sayıda İnternet'e bağlı bağlantı gerekiyorsa, giden trafik akışlarını soyutlama amacıyla Azure NAT Gateway'i kullanmayı göz önünde bulundurun.

• Giden İnternet trafiğini denetleme ve inceleme gereksinimlerinin bulunduğu Azure Güvenlik Duvarı kullanın.

  • Azure hizmetleri arasındaki trafiği incelemek için Azure Güvenlik Duvarı kullanılmadığından emin olun.

Not

Azure giriş bölgesi içinde dağıtım yaparken temel platform Azure Güvenlik Duvarı kaynağını (veya eşdeğer NVA' yı) kullanmayı göz önünde bulundurun. İnternet çıkışı için merkezi bir platform kaynağında bağımlılık alınırsa, bu kaynağın güvenilirlik düzeyi ve ilişkili ağ yolu uygulama gereksinimleriyle yakından uyumlu olmalıdır. Hata senaryolarında olası operasyonel eylemleri bilgilendirmek için kaynaktan gelen işletimsel veriler de uygulamanın kullanımına sunulmalıdır.

Giden trafikle ilişkili yüksek ölçekli gereksinimler varsa, gürültülü komşu senaryoları gibi merkezi olarak paylaşılan bir kaynak kullanımıyla ilgili riskleri azaltmak amacıyla görev açısından kritik bir uygulama için ayrılmış bir Azure Güvenlik Duvarı kaynağına dikkat edilmelidir.

• Sanal WAN bir ortamda dağıtıldığında, kurumsal güvenlik duruşlarının genel güvenlik duvarı ilkeleri aracılığıyla gözlemlendiğinden emin olmak için ayrılmış uygulama Azure Güvenlik Duvarı örneklerinin merkezi yönetimini sağlamak için Güvenlik Duvarı Yöneticisi'ne dikkat edilmelidir.
• Uygulama ilkesi özerkliğini sağlamak için artımlı güvenlik duvarı ilkelerinin rol tabanlı erişim denetimi aracılığıyla uygulama güvenlik ekiplerine devredildiğinden emin olun.

Bölgeler arası ve bölgeler arası Bağlan

Uygulama tasarımı bağımsız bölgesel dağıtım damgalarını güçlü bir şekilde desteklese de, birçok uygulama senaryosu, yalnızca düşük hizmet koşullarında bile farklı bölgelere veya Azure bölgelerine dağıtılan uygulama bileşenleri arasında ağ tümleştirmesi gerektirebilir. Bölgeler arası ve bölgeler arası iletişimin sağlandığı yöntemin genel performans ve güvenilirlik açısından önemli bir etkisi vardır ve bu konu, bu bölümdeki önemli noktalar ve önerilerle incelenecektir.

Tasarım Konusunda Dikkat Edilmesi Gerekenler

• Görev açısından kritik bir uygulama için uygulama tasarımı yaklaşımı, tek bir bölgedeki tüm bileşen düzeylerinde bölgesel yedeklilik uygulanmış bağımsız bölgesel dağıtımların kullanımını onaylar.

• Kullanılabilirlik Alanı (AZ), bir Azure bölgesi içinde fiziksel olarak ayrı bir veri merkezi konumudur ve tek bir veri merkezi düzeyine kadar fiziksel ve mantıksal hata yalıtımı sağlar.

  Bölgeler arası iletişim için 2 ms'den kısa bir gidiş dönüş gecikme süresi garanti edilir. Bölgeler arasındaki çeşitli mesafeler ve fiber yollar göz önüne alındığında, bölgeler küçük bir gecikme süresi varyansı olacaktır.

• Kullanılabilirlik Alanı bağlantısı bölgesel özelliklere bağlıdır ve bu nedenle bir uç konum üzerinden bölgeye giren trafiğin hedefine ulaşmak için bölgeler arasında yönlendirilmesi gerekebilir. Bu, bölgeler arası yönlendirme ve 'ışık hızı' kısıtlamaları nedeniyle ~1ms-2ms gecikme süresi ekler, ancak bunun yalnızca hiper hassas iş yükleri için bir rulmanı olmalıdır.

• Kullanılabilirlik Alanları tek bir abonelik bağlamında mantıksal varlıklar olarak değerlendirilir, bu nedenle farklı aboneliklerin aynı bölge için farklı bir bölgesel eşlemesi olabilir. Örneğin, A Aboneliği'ndeki bölge 1, B aboneliğindeki bölge 2 ile aynı fiziksel veri merkezine karşılık gelebilir.

• Uygulama bileşenleri arasında son derece sohbet eden uygulama senaryolarında, uygulama katmanlarının bölgelere yayılması önemli gecikme süresine ve artan maliyetlere neden olabilir. Dağıtım damgasını tek bir bölgeyle sınırlandırarak ve farklı bölgelere birden çok damga dağıtarak bunu tasarım içinde azaltmak mümkündür.

• Farklı Azure bölgeleri arasındaki iletişim, GB bant genişliği başına daha büyük bir veri aktarımı ücretine neden olur.

  • Geçerli veri aktarım hızı, göz önünde bulundurulan Azure bölgelerinin kıtasına bağlıdır.
  • Kıtalardan geçen veriler çok daha yüksek bir oranda ücretlendirilir.

• Express Route ve VPN bağlantı yöntemleri, belirli senaryolar ve hatta farklı bulut platformları için farklı Azure bölgelerini doğrudan birbirine bağlamak için de kullanılabilir.

• Hizmetler için iletişim Özel Bağlantı özel uç noktaları kullanarak doğrudan iletişim için kullanılabilir.

• Trafik, bir Azure bölgesindeki sanal ağlar arasında ve aynı coğrafyadaki farklı Azure bölgelerindeki sanal ağlar arasında yönlendirmeyi kolaylaştırmak için şirket içi bağlantı için kullanılan Express Route bağlantı hatları aracılığıyla saça sabitlenebilir.

  • Express Route üzerinden saç sabitleme trafiği, sanal ağ eşlemesiyle ilişkili veri aktarımı maliyetlerini atlar, bu nedenle maliyetleri iyileştirmenin bir yolu olarak kullanılabilir.
  • Bu yaklaşım, Azure'da uygulama tümleştirmesi için ek ağ atlamaları gerektirerek gecikme ve güvenilirlik risklerine neden olur. Azure'dan/şirket içinden Express Route ve ilişkili ağ geçidi bileşenlerinin rolünü, Azure/Azure bağlantısını kapsayacak şekilde genişletir.

• Hizmetler arasında milisaniyenin altında gecikme süresi gerektiğinde, kullanılan hizmetler tarafından desteklendiğinde YakınLık Yerleştirme Grupları kullanılabilir.

Tasarım önerileri

• Bir bölgedeki ve farklı bölgelerdeki ağları bağlamak için sanal ağ eşlemesini kullanın. Express Route içinde saç sabitlemekten kaçınmanız kesinlikle önerilir.

• Özel Bağlantı kullanarak doğrudan aynı bölgedeki veya bölgeler arasında (Bölge A'daki hizmet B Bölgesindeki hizmetle iletişim kuran hizmetler) arasında iletişim kurun.

• Bileşenler arasında son derece sohbet eden uygulama iş yükleri için dağıtım damgasını tek bir bölgeyle sınırlamayı ve farklı bölgelere birden fazla damga dağıtmayı göz önünde bulundurun. Bu, bölgesel yedeklilik tek bir uygulama bileşeni yerine kapsüllenmiş dağıtım damgası düzeyinde tutulmasını sağlar.

• Mümkün olduğunda, her dağıtım damgasını bağımsız ve diğer damga pullarıyla bağlantısı kesilmiş olarak değerlendirin.

  • Veri platformu teknolojilerini kullanarak doğrudan ağ yolları ile uygulama düzeyinde tutarlılık elde etmek yerine bölgeler arasında durumu eşitleyin.
  • Hata senaryosunda bile gerekli olmadıkça farklı bölgeler arasında "köpek etiketleme" trafiğinden kaçının. Tek bir kritik bileşen katmanının başarısız olması durumunda trafiği bu hatalı bileşen düzeyinde başka bir bölgeye yönlendirmek yerine tüm damgayı dolaşımdan çıkarmak için genel yönlendirme hizmetlerini ve uçtan uca sistem durumu yoklamalarını kullanın.

• Hiper gecikme süresine duyarlı uygulama senaryolarında, giriş yolları için ağ gecikme süresini iyileştirmek üzere bölgesel ağ geçitleriyle bölgelerin kullanımına öncelik sağlayın.

Mikro segmentlere ayırma ve Kubernetes ağ ilkeleri

Mikro segmentasyon, tek tek uygulama iş yüklerini yalıtmak ve güvenliğini sağlamak için kullanılan ve bir Sıfır Güven modeline göre iş yükleri arasındaki ağ trafiğini sınırlamak için ilkeler uygulanan bir ağ güvenliği tasarım desenidir. Genellikle, ilke temelli uygulama düzeyinde ağ denetimleri aracılığıyla ağ saldırı yüzeyini azaltmak, ihlalin engellenmesini iyileştirmek ve güvenliği güçlendirmek için uygulanır.

Görev açısından kritik bir uygulama, Azure Kubernetes Service (AKS) kullanırken bir alt ağ veya ağ arabirimi düzeyinde Ağ Güvenlik Grupları (NSG), hizmet Erişim Denetim Listeleri (ACL) ve ağ ilkeleri kullanarak uygulama düzeyinde ağ güvenliğini zorunlu kılabilir.

Bu bölümde, uygulama düzeyinde mikro segmentlere ayırmaya yönelik önemli noktalar ve öneriler sağlayarak bu özelliklerin en uygun kullanımı inceleniyor.

Tasarım Konusunda Dikkat Edilmesi Gerekenler

• AKS iki farklı ağ modelinde dağıtılabilir:

  • Kubenet ağı: AKS düğümleri mevcut bir sanal ağ içinde tümleştirilir, ancak podlar her düğümdeki bir sanal katman ağı içinde bulunur. Farklı düğümlerdeki podlar arasındaki trafik kube-proxy üzerinden yönlendirilir.
  • Azure Container Networking Interface (CNI) ağı: AKS kümesi mevcut bir sanal ağ ile tümleştirilir ve düğümleri, podları ve hizmetleri, küme düğümlerinin bağlı olduğu sanal ağdan IP adresleri alır. Bu, podlardan ve podlara doğrudan bağlantı gerektiren çeşitli ağ senaryoları için geçerlidir. Farklı düğüm havuzları farklı alt ağlara dağıtılabilir.

  Not

  Azure CNI, Kubenet'e kıyasla daha fazla IP adresi alanı gerektirir. Ağın düzgün ön planlanması ve boyutlandırılması gerekir. Daha fazla bilgi için Azure CNI belgelerine bakın.

• Podlar varsayılan olarak yalıtılmamıştır ve herhangi bir kaynaktan gelen trafiği kabul eder ve herhangi bir hedefe trafik gönderebilir; bir pod, belirli bir Kubernetes kümesindeki diğer tüm podlarla iletişim kurabilir; Kubernetes ağ düzeyinde yalıtım sağlamaz ve ad alanlarını küme düzeyinde yalıtmaz.

• Podlar ve Ad Alanları arasındaki iletişim Ağ İlkeleri kullanılarak yalıtılabilir. Ağ İlkesi, Podlar arasındaki iletişim için erişim ilkelerini tanımlayan bir Kubernetes belirtimidir. Ağ İlkeleri kullanılarak, trafiğin nasıl gönderildiğini/alınacağını denetlemek için sıralı bir kural kümesi tanımlanabilir ve bir veya daha fazla etiket seçiciyle eşleşen pod koleksiyonuna uygulanabilir.

  • AKS, Ağ İlkesi uygulayan iki eklentiyi destekler: Azure ve Calico. Her iki eklenti de belirtilen ilkeleri zorunlu kılmak için Linux IPTable'ları kullanır. Daha fazla ayrıntı için bkz . Azure ve Calico ilkeleri arasındaki farklar ve bunların özellikleri.
  • Ağ ilkeleri ekli olduklarından çakışmaz.
  • İki pod arasındaki bir ağ akışına izin verebilmek için hem kaynak poddaki çıkış ilkesinin hem de hedef poddaki giriş ilkesinin trafiğe izin verebilmesi gerekir.
  • Ağ ilkesi özelliği yalnızca küme örnekleme zamanında etkinleştirilebilir. Mevcut aks kümesinde ağ ilkesini etkinleştirmek mümkün değildir.
  • Azure veya Calico kullanılıp kullanılmadığına bakılmaksızın ağ ilkelerinin teslimi tutarlıdır.
  • Calico, windows düğümleri desteği dahil olmak üzere daha zengin bir özellik kümesi sağlar ve Hem Azure CNI'yi hem de Kubenet'i destekler.

• AKS, GPU özellikleri olan ve olmayan düğümler gibi farklı donanım ve yazılım özelliklerine sahip düğümleri kullanarak farklı iş yüklerini ayırmak için farklı düğüm havuzları oluşturulmasını destekler.

  • Düğüm havuzlarının kullanılması ağ düzeyinde yalıtım sağlamaz.
  • Düğüm havuzları aynı sanal ağ içinde farklı alt ağlar kullanabilir. Düğüm havuzları arasında mikro segmentasyon uygulamak için NSG'ler alt ağ düzeyinde uygulanabilir.

Tasarım önerileri

• Giriş yollarının güvenliğini sağlamak ve uygulama bileşenlerini bir Sıfır Güven modeline göre yalıtmak için bir IP ACL'sini sağlamak için, tüm kabul edilen alt ağlarda bir NSG yapılandırın.

  • Trafiğin geçerli bir Azure Front Door arka uç IP adresi alanından kaynaklandığını doğrulayabileceğinden, Azure Front Door içinde tanımlanan uygulama arka uçlarını içeren tüm alt ağlarda NSG'ler içinde Front Door Hizmet Etiketlerini kullanın. Bu, Azure Front Door üzerinden hizmet düzeyinde trafik akışını sağlar, ancak belirli bir Front Door örneğinin kullanılmasını sağlamak ve ayrıca 'IP kimlik sahtekarlığı' güvenlik risklerini azaltmak için üst bilgi tabanlı filtreleme gerekecektir.

  • Genel İnternet trafiği tüm geçerli NSG'lerde RDP ve SSH bağlantı noktalarında devre dışı bırakılmalıdır.

  • Azure CNI ağ eklentisinin kullanımına öncelik verme ve uygulamayı kısıtlanmış bir adres alanına sığdırmak için sınırlı kullanılabilir IP adresi aralığına sahip senaryolar için Kubenet'i göz önünde bulundurun.

    • AKS hem Azure CNI hem de Kubenet kullanımını destekler. Bu ağ seçimi dağıtım zamanında seçilir.
    • Azure CNI ağ eklentisi daha güçlü ve ölçeklenebilir bir ağ eklentisidir ve çoğu senaryo için önerilir.
    • Kubenet daha basit bir ağ eklentisidir ve sınırlı sayıda kullanılabilir IP adresi olan senaryolar için önerilir.
    • Diğer ayrıntılar için bkz . Azure CNI .

• Kubernetes'teki Ağ İlkesi özelliği, kümedeki podlar arasında giriş ve çıkış trafiği kurallarını tanımlamak için kullanılmalıdır. Podlar arası iletişimi kısıtlamak ve sınırlamak için ayrıntılı Ağ İlkeleri tanımlayın.

  • Dağıtım zamanında Azure Kubernetes Service için Ağ İlkesi'ni etkinleştirin.
  • Daha geniş bir topluluk benimseme ve desteği ile daha zengin bir özellik kümesi sağladığından Calico'nun kullanımına öncelik verme.

Sonraki adım

Uygulama durumunu ölçmek ve gözlemlemek için dikkat edilmesi gereken noktaları gözden geçirin.

Sistem durumu modelleme ve gözlemlenebilirlik