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

Önerilen küresel olarak dağıtılmış etkin-etkin tasarım yaklaşımı göz önünde bulundurulduğunda ağ, 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 belirgin olarak, 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 Well-Architected 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?

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 gerekli yönlendirme özelliklerini sağlar.

Alternatif olarak, üçüncü taraf küresel yönlendirme teknolojileri de göz önünde bulundurulabilir. Bu seçenekler, Azure'da yerel 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ı tarafından yönlendirme teknolojileri yer alır.

Bu bölümde, azure yönlendirme hizmetlerinin farklı senaryoları iyileştirmek için nasıl kullanılabileceğini tanımlamaya yönelik önemli farklar incelenmektedir.

Tasarım konusunda dikkat edilmesi gerekenler

• Tek bir bölgeye bağlı yönlendirme hizmeti, tek 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 yük boşaltması için sertifika yönetimi ve giriş yolları için uygulama doğrulaması ile 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çekteki 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 kimliği 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, büyük olasılıkla ikincil hizmette de kullanım dışı veya düzeyi düşürülmüş bir hizmet yaşanacaktır.
    • Genel yönlendirme hizmeti hata senaryoları, 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 etkiler. Bir üçüncü taraf teknolojisi kullanılsa bile, temel 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ğlayacağı anlamına gelir.

• Genel yönlendirme hizmeti yedekliliği, genel bir kesintinin etkisinin yönlendirme hizmetiyle sınırlı olduğu çok az sayıda varsayımsal hata senaryosu için azaltma sağlar.

  Genel kesinti senaryolarına daha geniş bir yedeklilik sağlamak için çok bulutlu etkin-etkin dağıtım yaklaşımı göz önünde bulundurulabilir. Çok bulutlu etkin-etkin dağıtım yaklaşımı önemli operasyonel karmaşıklıklar getirir ve bu da 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şturur.

• İ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ımda kullanı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 ederler.
  • 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 elde edilebilir maksimum 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 geçmiş ve ulaşılabilir SLA genellikle %100'ün altındadır.

  • Bu hizmetler, kullanım dışılığa yönelik finansal tazminatlar sağlasa da, insan yaşamının nihai olarak söz konusu 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ça 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 çok 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 gelen her istek 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 özel uç noktaları destekler ve trafiğin doğrudan İnternet'ten Azure sanal ağlarına akmasını sağlar. 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 zaman temelinde çağrılan sistem durumu yoklamalarına ve arka uç sistem durumu uç noktalarına (URL' ler) dayanır. Bir 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 herhangi bir 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, hem yerleşik hem de özel kuralları desteklese de biraz farklı bir özellik kümesi sağlar 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. 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ılabilir olmadığı sürece her zaman birincil arka uca gönderilmesi gereken etkin-pasif kurulumlar için kullanışlıdır.
  • Ağırlıklı: Belirli bir trafik yüzdesinin belirli bir arka uçtan gönderildiği kanarya dağıtımları için geçerlidir. Birden çok arka uç aynı ağırlıklara sahipse gecikmeye dayalı 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 süresi tabanlı yönlendirmeyi 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, 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 belirli bir 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, istemciler DNS TTL'nin süresi dolana ve Traffic Manager hizmetinden yeni bir arka uç uç noktası istenene kadar iyi durumda olmayan arka uçla bağlantı 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ğeri kabul edeceği garanti edilmez, bu nedenle DNS yayma işleminin gerçekleşmesi gerçekten çok daha uzun sürebilir. Bu, trafiğin sürekli bir süre boyunca 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 önemle önerilir.

• İ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ığını uygulayın. Tek hizmet SLA'sı yeterli değilse, ek yedeklilik için iki veya daha fazla genel yönlendirme teknolojisi 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önlendirmeye de dikkat edilmelidir. Bu durum 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 küresel 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ı göz önünde bulundurulmalı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 işletimsel sistem durumunun gösterimleri ile önemli bir operasyonel karmaşıklık sağladığından, çok bulutlu bir yaklaşımın uygulanmaması kesinlikle önerilir. 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.

• 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 gelen kabul edilebilir trafik için Application Gateway için Web Uygulaması Güvenlik Duvarı (WAF) 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 edilemeyen giriş yolları arasında tutarlılık sağlayarak hata senaryosunu büyük ölçüde basitleştirir.
  • Hata senaryosunda kenar ö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 üçüncü taraf cdn sağlayıcısına boşaltmayı göz önünde bulundurun.

İki Azure genel yönlendirme hizmetinin yerine üçüncü taraf genel yönlendirme hizmetini göz önünde bulundurmak önerilir. Bu, endüstri lideri CDN sağlayıcılarının çoğu Azure Front Door tarafından sunulan uç özelliklerle büyük ölçüde tutarlı ö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 kaynaklandığını doğrulamak için Front Door Hizmet Etiketlerini kullanarak IP ACL'sini yapılandırmayı da göz önünde bulundurun. Bu, Azure Front Door üzerinden hizmet düzeyinde trafik akışının gerçekleştirilmesini sağlar, ancak yapılandırılmış bir Front Door örneğinin kullanılmasını sağlamak 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 olmazsa, sistem durumu araştırması bunu döndürülen yanıta yansıtmalıdır, böylece bölgesel damganın tamamı dolaşımdan çıkarılabilir.

• 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 bir işletimsel görünüm elde edilir.

• İş 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 damga pullarına 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ğıtımının dengesini olumsuz etkileyebileceğinden, uygulama tarafından gerekli kılınmadığı sürece Oturum Benzimi'ni etkinleştirmeyin. Tam olarak durum bilgisi olmayan bir uygulamayla, önerilen görev açısından kritik uygulama tasarımı yaklaşımı izlenirse, tüm istekler bölgesel dağıtımlardan herhangi biri tarafından işlenebilir.

Azure Traffic Manager

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

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

• Arka ucun iyi durumda olmadığında 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 şekilde düşük bir 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, sistem durumu 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ği 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 Application Gateway ve Azure API Management gibi ilgili hizmetleri göz önünde bulundurarak önemli uygulama teslim özelliklerini inceleyerek genel yönlendirme önerilerini temel alır.

Tasarım konusunda dikkat edilmesi gerekenler

• TLS şifrelemesi, görev açısından kritik bir uygulamaya gelen kullanıcı trafiğinin bütünlüğünü güvence altına almak 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 en yüksek 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 Application Gateway veya Azure CDN (şu anda genel önizlemede) 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, hepsi 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 düşünülebilir.

• En uygun WAF yapılandırması genellikle kullanılan teknolojiden bağımsız olarak 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, protokoller ve bağlantı noktaları arasında yayılan hacim tabanlı 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ç konumlarına genel olarak dağıtılır.

  • Kaynak yapılandırması, saniyede yüz binlerce isteği işlemek için çok büyük bir ö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şletimsel 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 mevcut sertifikanın süresinin dolmasından en geç 24 saat önce dağıtılmalıdır, 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ştirilen Azure DDoS Koruması Temel 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ğı gayri meşru trafikle bunaltarak kullanılamaz duruma gelebilir.

• Azure Front Door ayrıca küresel trafik düzeyinde WAF özellikleri sağlarken, her bölgesel dağıtım damgasında Application Gateway WAF 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şı korumaya 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 mümkün olduğunca az yerde TLS Boşaltması gerçekleştirin.

• TLS boşaltmasının 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 küresel olarak veya Azure Application 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). Örtük ek risk tam olarak 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 küresel 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 kullanıma 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ı'ni 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ı deneyiminin yanı sıra çözümün genel maliyeti üzerinde önemli bir etkiye sahip olabilir. Uçta statik içerikleri önbelleğe almak, istemci yükleme sürelerini hızlandırarak daha iyi bir kullanıcı deneyimine neden olabilir ve ayrıca trafik, okuma işlemleri ve ilgili arka uç hizmetlerindeki işlem gücü maliyetlerini azaltabilir.

Tasarım konusunda dikkat edilmesi gerekenler

• Bir çözümün İnternet üzerinden kullanıma sunması gereken 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 fayda sağlar.
• Ö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'da yerel 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ümlerden gelen benzer hizmetlerle tümleştirme konusunda daha fazla esneklik 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 farklı ö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, son kullanıcılar için performansı iyileştirir.
• Azure Front Door'u genel yönlendirme ve Web Uygulaması Güvenlik Duvarı (WAF) amacıyla kullanmaya 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 veya 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 üç kapsamlı ağ yapılandırmasından birinde dağıtılabilir.

1. Kurumsal ağ bağlantısı olmayangenel uygulama.
2. Kurumsal ağ bağlantısı olangenel 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ğlı Giriş Bölgesi içinde dağıtılmalıdır.

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

Tasarımda Dikkat Edilmesi Gerekenler

Sanal ağ yok

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

  • Göz önünde bulundurulan tüm Azure hizmetleri arasındaki bağlantı tamamen genel uç noktalar ve Microsoft Azure omurgası üzerinden sağlanacaktır. Azure'da barındırılan genel uç noktalar arasındaki bağlantı yalnızca Microsoft omurgasını geçer ve genel İnternet üzerinden gitmez.
  • Azure dışındaki tüm dış sistemlere bağlantı genel İnternet tarafından sağlanı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ç noktaları kullanır.

  • Destekleniyorsa Özel Uç Noktalarla Azure platform hizmetlerine bağlantı kurulabilir. 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ı aracılığıyla bağlantı sağlanır.
  • Azure dışındaki tüm dış sistemlere bağlantı genel İnternet tarafından sağlanabilir.

• 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ıtlamaları yoktur.

• Azure Bastion, sanal ağa dağıtılabilir 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 aracılığıyla bağlandığınızda sanal makinelerin genel IP adresine ihtiyacı yoktur.

• Uygulama dağıtımlarını kolaylaştırmak için özel ağlarda barındırılan kaynaklara hem veri düzlemi hem de denetim düzlemi erişimi gerektiğinden, uygulama sanal ağlarının kullanımı 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ı içinde dağıtılabilir.

Bağlı sanal ağlar

• Dış ağ tümleştirme gereksinimleri olan senaryolarda, 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 ş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ınırsa büyük çekişmelere neden olur.

  • 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 ve uygulama sanal ağları ve kapsadığı alt ağlar için uygun boyutlar belirlenirken dikkate alınması gerekir.
  • 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 adresleri boşa harcayacak 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 gerekli 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

• Gereksiz genel uç noktaların kaldırılması mümkün olduğunda Azure sanal ağlarında 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 çıkaracak şekilde 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, veri sızdırma risklerinin kabul edilebilir olması veya alternatif denetimler aracılığıyla azaltılması koşuluyla göz önünde bulundurulabilir.

• 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 ağlarına veya şirket içi ağlara bağlanırken, sanal ağ eşlemesi ve sanal ağ geçidi kaynaklarıyla ilgili önemli komplikasyonlar oluşturduğundan uygulama sanal ağları kısa ömürlü olarak değerlendirilmemelidir. 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, sanal ağ içindeki tüm ilgili uygulama kaynakları 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 İnternet (RFC 1918) için yalnızca adres ayırmadaki IP adreslerinin kullanılması kesinlikle önerilir.
    • Özel IP adreslerinin sınırlı kullanılabilirliğine sahip ortamlar için (RFC 1918), 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 kullanmaya öncelik belirleyin.

  • Uygulamayı kısıtlanmış bir adres alanına sığdırmak için kullanılabilir IP adresleri sınırlı olan 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 segmentlere ayırma 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'u kullanmaya öncelik sağlayın.

  • Express Route veya VPN'ye 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ısı mekanizması olarak VPN kullanımı gibi ek yedeklilik sağlamak için birden çok ağ yolu göz önünde bulundurulmalıdır.

• Bu yolların ve ilişkili bileşenin yönetiminin merkezi BT ekiplerinden oluşan uygulama ekibi tarafından sağlanıp sağlanmadığına bakılmaksızın, kritik ağ yollarındaki tüm bileşenlerin 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 özel bağlantılarını kullanın.

İnternet çıkışı

İnternet çıkışı, görev açısından kritik bir uygulamanın aşağıdakiler bağlamında dış iletişimi kolaylaştırmaya yönelik temel bir 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örev açısından kritik bir bağlamda önerilen hizmetler için temel çıkış gereksinimlerini vurgulayarak güvenlik, güvenilirlik ve sürdürülebilir performansın korunması sağlanırken İnternet çıkışının nasıl sağlandığı incelenmektedir.

Tasarımda 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, sanal makineler veya bir sanal ağdaki 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.

• Bir sanal ağın içinden İnternet'e giden trafik olduğunda, Ağ Adresi Çevirisi (NAT) gerçekleşmelidir. Bu, ağ yığınında gerçekleşen ve bu nedenle sistem performansını etkileyebilecek bir işlem işlemidir.

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

• Azure App Service gibi çok kiracılı bir ortamda her örnek için sınırlı sayıda giden bağlantı noktası kullanılabilir. Bu bağlantı noktaları tükenirse yeni giden bağlantı başlatılamaz. Bu sorun, özel/genel kenar 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 miktarlarda İnternet çıkışı , veri aktarımı ücretlerine neden olur.

Azure NAT Gateway

• 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ğere 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ğ ilgili bölgesel NAT ağ geçitleriyle hizalanmalıdır.

Tasarım önerileri

• Nat performansını etkileyeeceğinden 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 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 denetlemek 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ğına bağımlılık alınırsa, bu kaynağın ve ilişkili ağ yolunun güvenilirlik düzeyi 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 rol tabanlı erişim denetimi aracılığıyla artımlı güvenlik duvarı ilkelerinin uygulama güvenlik ekiplerine devredildiğinden emin olun.

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

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üzeyi düşürülmüş hizmet koşullarında bile farklı bölgeler veya Azure bölgeleri içinde 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 yöntem bu bölümdeki önemli noktalar ve önerilerle incelenecektir.

Tasarımda 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 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 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 yaklaşık 1ms-2ms gecikme süresi ekler, ancak bunun yalnızca hiper hassas iş yükleri için bir yatak olması gerekir.

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

• Bir bölge içindeki bölgeler arasındaki iletişim, GB bant genişliği başına veri aktarımı ücretine neden olabilir.

• Uygulama bileşenleri arasında son derece gevedikli olan uygulama senaryolarında, uygulama katmanlarının bölgelere yayılması önemli gecikme süresine ve artan maliyetlere neden olabilir. Bir dağıtım damgasını tek bir bölgeyle kısıtlayarak ve farklı bölgelere birden çok damga pulu 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ını temel alı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 hizmet iletişimi Ö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ölgeleri arasında yönlendirmeyi kolaylaştırmak amacıyla ş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şlemesi ile 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ı gerektirir ve bu da gecikme ve güvenilirlik risklerine neden olmaktadır. Express Route ve ilişkili ağ geçidi bileşenlerinin Azure/şirket içi 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ölge içindeki ve farklı bölgelerdeki ağları bağlamak için sanal ağ eşlemesini kullanın. Express Route'da saç sabitlemeyi önlemek kesinlikle önerilir.

• Aynı bölgedeki veya bölgeler (Bölge A'daki hizmet B Bölgesindeki hizmetle iletişim kuran hizmet) arasında doğrudan iletişim kurmak için Özel Bağlantı kullanın.

• Bileşenler arasında son derece gevedikli olan uygulama iş yükleri için dağıtım damgasını tek bir bölgeyle kısıtlamayı ve farklı bölgelere birden çok damga pulu dağıtmayı göz önünde bulundurun. Bu sayede bölgesel yedeklilik, tek bir uygulama bileşeni yerine kapsüllenmiş dağıtım damgası düzeyinde korunur.

• 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 sağlamak yerine bölgeler arasında durumu eşitleyin.
  • Hata senaryosunda bile gerekli olmadıkça farklı bölgeler arasındaki '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, genel yönlendirme hizmetlerini ve uçtan uca sistem durumu yoklamalarını kullanarak tek bir kritik bileşen katmanının başarısız olması durumunda tüm damgayı dolaşımdan çıkarın.

• Hiper gecikmeye duyarlı uygulama senaryolarında, giriş yolları için ağ gecikmesini 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 segmentlere ayırma, tek tek uygulama iş yüklerini yalıtmak ve güvenliğini sağlamak için kullanılan bir ağ güvenlik tasarımı desenidir ve Sıfır Güven modeline dayalı olarak iş yükleri arasındaki ağ trafiğini sınırlamak için ilkeler uygulanır. Genellikle ağ saldırı yüzeyini azaltmak, ihlalin engellenmesini iyileştirmek ve ilke temelli uygulama düzeyi ağ denetimleri aracılığıyla 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 Access Control Listeleri (ACL) ve ağ ilkeleri kullanarak uygulama düzeyinde ağ güvenliğini zorunlu kılabilir.

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

Tasarımda Dikkat Edilmesi Gerekenler

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

  • Kubenet ağı: AKS düğümleri mevcut bir sanal ağ ile tümleştirilir, ancak podlar her düğümdeki 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şiktir ve düğümleri, podları ve hizmetleri, küme düğümlerinin bağlı olduğu sanal ağdan IP adresleri alır. Bu, podlardan ve podlarına 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 bir şekilde önceden 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önderileceğ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 zorlamak 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 vermesi gerekir.
  • Ağ ilkesi özelliği yalnızca küme örnekleme zamanında etkinleştirilebilir. Mevcut bir 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 ip ACL'sini sağlamak için tüm dikkate alınan 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ğruladığından, Azure Front Door'da 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 'IP kimlik sahtekarlığı' güvenlik risklerini azaltmak için üst bilgi tabanlı filtreleme gerekli olmaya devam eder.

  • Genel İnternet trafiği, geçerli tüm NSG'ler genelinde 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ı sayıda 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. Dağıtım zamanında seçilir.
    • Azure CNI ağ eklentisi daha sağlam 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