Azure giriş bölgesinde Azure Sanal Makineler temel mimarisi

Bu makaledeki mimari, bir Azure giriş bölgesine dağıttığınızda değişiklikleri ve beklentileri gidermek için sanal makine (VM) temel mimarisini genişletir.

Bu makaledeki örnekte bir kuruluş, vm tabanlı bir iş yükünün bir platform ekibinin merkezi olarak yönettiği federasyon kaynaklarını kullanmasını istemektedir. Bu kaynaklar arasında şirket içi bağlantı, kimlik erişim yönetimi ve ilkeler için ağ kaynakları yer alır. Bu örnekte, kuruluşun birden çok iş yükünde tutarlı idare ve maliyet verimliliğini zorlamak için Azure giriş bölgelerini benimsediği varsayılır.

İş yükü sahibi olarak, paylaşılan kaynakların yönetimini merkezi ekiplere devrederek iş yükü geliştirme çalışmalarına odaklanabilirsiniz. Bu makalede iş yükü ekibinin bakış açısı sunulur. Platform ekibine yönelik Öneriler belirtilir.

Makale düzeni

Mimari	Tasarım kararı	Azure İyi Tasarlanmış Çerçeve yaklaşımı
▪ Mimari diyagramı ▪ İş yükü kaynakları ▪ Federasyon kaynakları	▪ Abonelik kurulumu ▪ Ağ gereksinimleri ▪ Ağ tasarımı temelden değişir ▪ Izleme ▪ Düzeltme eki uyumluluğu ▪ Kurumsal idare ▪ Değişiklik yönetimi	▪ Güvenilir -lik ▪ Güvenlik ▪ Maliyet İyileştirme

Mimari

Bu mimarinin bir Visio dosyasını indirin.

Bileşenler

Tüm Azure giriş bölgesi mimarilerinde platform ekibi ile iş yükü ekibi arasında sahiplik ayrımı vardır. Uygulama mimarlarının ve DevOps ekiplerinin, doğrudan etkilerinin veya denetimlerinin altında nelerin olduğunu ve nelerin olmadığını anlamak için bu sorumluluğun bölünmesi konusunda güçlü bir anlayışa sahip olması gerekir.

İş yükü ekibine ait kaynaklar

Aşağıdaki kaynaklar temel mimariden büyük ölçüde değişmeden kalır.

• Azure Sanal Makineler, uygulama platformudur. İşlem kaynakları kullanılabilirlik alanları arasında dağıtılır.

• Azure Load Balancer , trafiği ön uç VM'lerden arka uç VM'lerine özel olarak dengelemek için kullanılır. Yük dengeleyici, trafiği vm'lere bölgeler arasında dağıtır.

• Azure Uygulaması lication Gateway, kullanıcı isteklerini ön uç VM'lere yönlendirmek için ters ara sunucu olarak kullanılır. Seçilen SKU, ön uç VM'leri kötü amaçlı olabilecek trafiklerden korumak için Azure Web Uygulaması Güvenlik Duvarı barındırmak için de kullanılır.

• Azure Key Vault , uygulama gizli dizilerini ve sertifikalarını depolamak için kullanılır.

• Azure İzleyici, Log Analytics ve Uygulama Analizler gözlemlenebilirlik verilerini toplamak, depolamak ve görselleştirmek için kullanılır.

• Azure İlkesi, iş yüküne özgü ilkeleri uygulamak için kullanılır.

İş yükü ekibi aşağıdaki kaynakları ve sorumlulukları korur ve yerine getirir.

• Segmentasyonu korumak ve trafik akışını denetlemek için bu alt ağlara yerleştirilen uç sanal ağ alt ağları ve ağ güvenlik grupları (NSG ).

• Hizmet olarak platform (PaaS) çözümlerine ve bu uç noktalar için gereken özel DNS bölgelerine bağlantının güvenliğini sağlamak için özel uç noktalar.

• Azure Yönetilen Diskler günlük dosyalarını arka uç sunucularında depolar ve vm'ler yeniden başlatıldığında bile veriler korunur. Ön uç sunucularında durum bilgisi olmayan uygulamanızı dağıtmak için kullanabileceğiniz diskler vardır.

Platform ekibine ait kaynaklar

Platform ekibi bu merkezi kaynaklara sahip ve bunların bakımını gerçekleştirmektedir. Bu mimari, bu kaynakların önceden sağlandığını varsayar ve bağımlılıkları dikkate alır.

• Merkez ağındaki Azure Güvenlik Duvarı çıkış trafiğini incelemek ve kısıtlamak için kullanılır. Bu bileşen, İnternet'e giden trafikle ilgili kısıtlamalar sağlamayan temel mimarideki standart yük dengeleyicinin yerini alır.

• Merkez ağındaki Azure Bastion, iş yükü VM'lerine güvenli işletimsel erişim sağlar. Temel mimaride, iş yükü ekibi bu bileşenin sahibidir.

• uç sanal ağı , iş yükünün dağıtıldığı yerdir.

• Kullanıcı tanımlı yollar (UDR) merkez ağına tünel yapmaya zorlamak için kullanılır.

• Azure İlkesi tabanlı idare kısıtlamaları ve DeployIfNotExists (DINE) ilkeleri iş yükü aboneliğinin bir parçasıdır.

Abonelik kurulumu

Giriş bölgesi bağlamında iş yükü ekibinizin platform ekibine kendi gereksinimleri hakkında bilgi vermesi gerekir.

Platform ekibinin gerekli kaynakları ayırabilmesi için iş yükü ekibinizin iş yükünüz için gereken ağ alanı hakkında ayrıntılı bilgi içermesi gerekir. Ekibiniz gereksinimleri belirlerken platform ekibi de sanal ağ içinde ve aboneliğin atandığı yönetim grubunda atanacak IP adreslerini belirler.

Platform ekibi , iş yükünün iş açısından kritikliği ve teknik gereksinimleri (örneğin, bir iş yükünün İnternet'e açık olması) temel alarak uygun bir yönetim grubu atar. Kuruluş bu yönetim gruplarının yapılandırmasını belirler ve platform ekibi bunları uygular.

Örneğin, temel mimari için uygulama senaryolarındaki yönetim grupları dikkate alınır:

• Genellikle Azure giriş bölgelerinin Corp yönetim grubu altında yer alan şirket içi iş kolu uygulamaları veya ticari kullanıma hazır (COTS) çözümleri gibi özel uygulamalar.

• Genel uygulamalar, İnternet'e yönelik uygulamalarda olduğu gibi, genellikle Corp veya Online yönetim grubu altındadır.

Platform ekibi, iş yükü dağıtımı için bir abonelik veya abonelik grubu ayarlamakla da sorumludur.

Aşağıdaki bölümlerde ilk abonelik kurulumuyla ilgili yönergeler sağlanır. Ancak platform ekibi genellikle merkezi hizmetlerde eksik veya değiştirilmiş gereksinimleri karşılamak için değişiklikler yapar. Platform değişiklikleri tüm iş yükü ekiplerini daha geniş bir etkiye sahiptir.

Bu nedenle, platform ekibi tüm VM iş yüklerinin herhangi bir değişiklik için hazır olduğundan emin olmalı ve VM tabanlı çözümün yaşam döngüsünü ve test döngüsünün farkında olmalıdır. Daha fazla bilgi için bkz . Zaman içinde değişiklikleri yönetme.

İş yükü gereksinimleri ve karşılamaları

İş yükü ekibi ve platform ekipleri iki ana sorumluluğu paylaşır: yönetim grubu ataması ve ağ kurulumu. Bu mimari için platform ekibiyle iletişim kurmanız gereken aşağıdaki ağ gereksinimlerini göz önünde bulundurun. Benzer bir mimari uyguladığınızda iki ekip arasındaki tartışmayı ve müzakereyi anlamak için bu noktaları örnek olarak kullanın.

• Uç sanal ağlarının sayısı: Bu mimaride yalnızca bir ayrılmış uç gereklidir. Dağıtılan kaynakların birden çok ağa yayılması gerekmez ve tek bir sanal ağ içinde birlikte bulunur.

• Uç ağının boyutu: operasyonel gereksinimleri ve iş yükünün beklenen büyümesini dikkate alın. Örneğin, mavi/yeşil veya kanarya güncelleştirmeleri uygulamayı planlıyorsanız, yan yana dağıtımlarınızın gerektirdiği alanı en büyük boyut dikkate almalıdır.

  Gelecekteki değişiklikler, geçerli ayırmayla yanlış hizalanabilen daha fazla IP alanı gerektirebilir. Bu alanların tümleştirilmesi fazladan karmaşıklık oluşturabilir. Proaktif olun ve ayrılan alanın gelecekte genişlemeye uygun olduğundan emin olmak için yeterince ağ kaynağı isteyin.

• Dağıtım bölgesi: İş yükünün dağıtılacağı bölgeleri belirtmek önemlidir. Platform ekibi, uç ve merkez sanal ağlarının aynı bölgede sağlandığından emin olmak için bu bilgileri kullanabilir. Farklı bölgelerdeki ağlar, bölgesel sınırları aşan trafik nedeniyle gecikme sorunlarına yol açabilir ve ek bant genişliği maliyetlerine neden olabilir.

• İş yükü özellikleri ve tasarım seçimleri: Tasarım seçimlerinizi, bileşenlerinizi ve özelliklerinizi platform ekibinize iletin. Örneğin, iş yükünüzün İnternet'e çok sayıda eşzamanlı bağlantı (sohbet) oluşturmasını bekliyorsanız, platform ekibi tükenmeyi önlemek için yeterli bağlantı noktası olduğundan emin olmalıdır. Trafiği desteklemek için merkezi güvenlik duvarına IP adresleri ekleyebilir veya trafiği alternatif bir yol üzerinden yönlendirecek bir Ağ Adresi Çevirisi (NAT) ağ geçidi ayarlayabilirler.

  Buna karşılık, iş yükünüzün en az ağ trafiği (arka plan gürültüsü) oluşturmasını bekliyorsanız, platform ekibi kuruluş genelinde kaynakları verimli bir şekilde kullanmalıdır.

  Platform ekibinin bağımlılıkları net bir şekilde anlaması gerekir. Örneğin, iş yükünüz başka bir ekibin sahip olduğu bir veritabanına erişmesi gerekebilir veya iş yükünüz şirket içi trafiğine sahip olabilir. İş yükünüzün Azure dışında bağımlılıkları var mı? Bu tür bilgiler platform ekibinin bilmesi açısından önemlidir.

• Güvenlik duvarı yapılandırması: Platform ekibi uç ağından ayrılan ve merkez ağına tünel oluşturan trafiğin farkında olmalıdır. Hub'daki güvenlik duvarı bu trafiği engelleyemez.

  Örneğin, iş yükünüzün düzeltme eki uygulanmış durumda kalmak için Windows güncelleştirmelerine erişmesi gerekiyorsa, güvenlik duvarı bu güncelleştirmeleri engellememelidir. Benzer şekilde, belirli uç noktalara erişen İzleyici aracıları varsa, iş yükünüz için izleme verilerini kesintiye uğratabileceğinden güvenlik duvarı bu trafiği engellememelidir. Uygulama, üçüncü taraf uç noktalarına erişim gerektirebilir. Ne olursa olsun, beklenen ve yersiz trafiği ayırt etmek için merkezi bir güvenlik duvarı kullanın.

• Operatör erişimi: Operatörlerin Azure Bastion üzerinden VM'lere erişmek için kullandığı Microsoft Entra ID güvenlik grupları varsa platform ekibine bildirin. Azure Bastion genellikle merkezi bir kaynaktır. Güvenlik gruplarının ve VM'lerin güvenli protokolü desteklediğinden emin olmak çok önemlidir.

  Ayrıca, vm'leri içeren IP aralıkları hakkında platform ekibine bilgi verin. Bu bilgiler, merkez ağındaki Azure Bastion çevresindeki NSG'leri yapılandırmak için gereklidir.

• Genel IP'ler: Platform ekibine, beklenen genel IP adresleri de dahil olmak üzere giriş trafik profili hakkında bilgi verin. Bu mimaride, Application Gateway'de yalnızca İnternet kaynaklı trafik genel IP'yi hedefler. Platform ekibi, bu IP'lerin bir Azure DDoS Koruması planı kapsamında olup olmadığını veya iş yükü ekibinin sorumluluğunda olup olmadığını iş yükü ekibine bildirmelidir.

  Bu mimaride, Azure Bastion aracılığıyla operasyonel erişim için başka bir genel IP vardır. Platform ekibi bu genel IP'nin sahibidir ve platform ekibinin de yönettiği DDoS Koruması gibi bir hizmete kaydedilir.

VM tasarım seçenekleri

VM SKU'su ve disk seçimleri temel mimariyle aynı kalır.

Bir kuruluş, iş yükü ekibine belirli VM görüntülerinin kullanılmasını zorunlu hale getiren uyumluluk gereksinimleri uygulayabilir. Bu tür gereksinimler göz önünde bulundurulduğunda platform ekibi, genellikle kuruluş genelinde kullanılmak üzere oluşturulan altın resimler olarak adlandırılan standartlaştırılmış görüntüler kümesini yönetebilir.

Platform ekibi, onaylı işletim sistemi görüntülerini veya iş yükü yapıtlarını depolamak için Azure İşlem Galerisi veya özel bir depo gibi yönetilen bir teklif kullanabilir. VM'ler için bir işletim sistemi görüntüsü seçtiğinizde görüntü kaynakları, güncelleştirme sıklığı ve kullanım beklentileri hakkında platform ekibinize başvurun. Ayrıca görüntülerin iş yükünün yerine getirmesi gereken iş gereksinimlerini karşılayabildiğinden emin olun.

Ağ

Temel mimaride iş yükü tek bir sanal ağda sağlanır. sanal ağı iş yükü ekibi yönetir.

Bu mimaride, ağ topolojisini platform ekibi belirler. Bu mimaride merkez-uç topolojisi varsayılır.

Bu mimarinin bir Visio dosyasını indirin.

• Merkez sanal ağı: Bölgesel merkez, aynı bölgedeki iş yükü kaynaklarıyla iletişim kuran merkezi hizmetler içerir. Daha fazla bilgi için bkz . Platform ekibine ait kaynaklar. Hub'ı bağlantı aboneliğine yerleştirmenizi öneririz.

• Uç sanal ağı: Bu mimaride, temel mimarideki tek sanal ağ uç ağıdır. Merkezi hizmetleri içeren merkez ağıyla eşlenmiştir. Platform ekibi bu uç ağının sahibi ve yönetimidir. Bu ağ iş yükü kaynaklarını içerir. İş yükü ekibi, alt ağları da dahil olmak üzere bu ağdaki kaynaklara sahiptir.

İş yükü gereksinimlerini platform ekibine iletdiğinizden emin olun ve bunları düzenli aralıklarla gözden geçirin.

Sanal ağ alt ağları

Uç sanal ağında iş yükü ekibi alt ağları oluşturur ve ayırır. Alt ağlara gelen ve giden trafiği kısıtlamak için denetimler yerleştirmek, segmentlere ayırma sağlamaya yardımcı olur. Bu mimari, Application Gateway, ön uç VM'ler, yük dengeleyici, arka uç VM'ler ve özel uç noktalar için ayrılmış alt ağlara sahip temel mimariyle aynı alt ağ topolojisini kullanır.

İş yükünüzü bir Azure giriş bölgesine dağıttığınızda ağ denetimlerini uygulamanız gerekir. Kuruluşlar, veri sızdırmaya karşı koruma sağlamak ve merkezi güvenlik operasyonları merkezi (SOC) ve BT ağ ekibi için görünürlük sağlamak için kısıtlamalar uygulayabilir.

Bu yaklaşımla platform ekibi, kuruluş genelinde her iş yükü için yedekli güvenlik denetimleri dağıtmak yerine merkezi hizmetleri kullanarak genel kuruluş harcamalarını iyileştirebilir. Bu mimaride Azure Güvenlik Duvarı bir merkezi hizmet örneğidir. Her iş yükü ekibinin kendi güvenlik duvarı örneğini yönetmesi uygun maliyetli veya pratik değildir. Güvenlik duvarı yönetimine merkezi bir yaklaşım öneririz.

Giriş trafiği

Giriş trafiği akışı temel mimariyle aynı kalır.

İş yükü sahibi, iş yükünüzdeki genel İnternet girişiyle ilgili tüm kaynaklarda sorumludur. Örneğin, bu mimaride Application Gateway ve genel IP'leri merkez ağına değil uç ağına yerleştirilir. Bazı kuruluşlar, merkezi bir sivilleştirilmiş (DMZ) uygulaması kullanarak giriş trafiğine sahip kaynakları bağlantı aboneliğine yerleştirebilir. Söz konusu topolojiyle tümleştirme, bu makalenin kapsamı dışındadır.

Çıkış trafiği

Temel mimaride iş yükü sanal makine ölçek kümeleri Azure Load Balancer aracılığıyla genel İnternet'e erişir, ancak bu trafik kısıtlanmaz.

Bu mimaride bu tasarım farklıdır. Uç sanal ağından ayrılan tüm trafik, eşlenmiş merkez ağı üzerinden çıkış güvenlik duvarı üzerinden yönlendirilir. Uç ağındaki tüm olası alt ağlara, yerel sanal ağda (0.0.0.0/0) bulunmayan IP'ler için tüm trafiği hub'ın Azure Güvenlik Duvarı yönlendiren bir yol eklenir.

Bu mimarinin bir Visio dosyasını indirin.

Key Vault erişimi için özel uç noktayla iş yükü iletişimi temel mimariyle aynı kalır. Bu yol, önceki diyagramda kısalık için atlanır.

İş yükü ekibinin altyapı ve iş yükü işlemleri için gerekli tüm giden trafik akışlarını tanımlaması, belgelemesi ve iletmesi gerekir. Platform ekibi gerekli trafiğe izin verir ve tüm yaygın olmayan çıkış trafiği reddedilir.

Çıkış trafiğini denetlemek, beklenen trafiğe izin verildiğinden emin olmaktan daha fazlasıdır. Ayrıca yalnızca beklenen trafiğe izin verilmelidir. Yaygın olmayan çıkış trafiği varsayılan olarak reddedilir, ancak trafiğin düzgün şekilde yönlendirildiğinden emin olmak iş yükünün en iyi güvenlik çıkarıdır.

Benzersiz çıkış trafiği gereksinimlerini platform ekibine iletin. Örneğin, iş yükünüz dış ağ uç noktalarına çok sayıda eşzamanlı bağlantı kuruyorsa platform ekibine bildirin. Ardından platform ekibi uygun bir Azure NAT Gateway uygulaması sağlayabilir veya azaltma için bölgesel güvenlik duvarına daha fazla genel IP ekleyebilir.

Kuruluşunuzun çıkış için iş yüküne ait genel IP'leri kullanan mimari desenlerinin kullanılmasını engelleyen gereksinimleri olabilir. Bu durumda, vm ağ arabirim kartlarındaki (NIC' ler) genel IP'leri ve iyi bilinen giriş noktalarınız dışındaki diğer genel IP'leri reddetmek için Azure İlkesi kullanabilirsiniz.

Özel DNS bölgeleri

Özel uç noktaları kullanan mimarilerin DNS sağlayıcısıyla çalışması için özel DNS bölgeleri gerekir. İş yükü ekibinin, platform ekibinin sağladığı abonelikteki özel DNS bölgelerinin gereksinimlerini ve yönetimini net bir şekilde anlamış olması gerekir. Özel DNS bölgeleri genellikle Azure Güvenlik Duvarı güvenilir bir DNS proxy'si olarak çalışmasını ve tam etki alanı adı (FQDN) ağ kurallarını desteklemesini sağlayan DINE ilkeleriyle büyük ölçekte yönetilir.

Bu mimaride platform ekibi, özel bağlantı uç noktaları için güvenilir özel DNS çözümlemesi sağlar. Beklentilerini anlamak için platform ekibinizle işbirliği yapın.

Bağlan üretkenlik testi

VM tabanlı mimariler için ağ görüş çizgisi, yönlendirme ve DNS sorunlarını belirlemeye yardımcı olabilecek çeşitli test araçları vardır. , nslookupveya tcpinggibi netstatgeleneksel sorun giderme araçlarını kullanabilirsiniz. Ayrıca, ağ bağdaştırıcısının Dinamik Ana Bilgisayar Yapılandırma Protokolü (DHCP) ve DNS ayarlarını inceleyebilirsiniz. NIC'ler varsa, Azure Ağ İzleyicisi kullanarak bağlantı denetimleri gerçekleştirmenizi sağlayan daha fazla sorun giderme özelliğine sahip olursunuz.

İşleç erişimi

Temel mimaride olduğu gibi Azure Bastion üzerinden operasyonel erişim de bu mimaride desteklenir.

Ancak temel mimari, Azure Bastion'ı iş yükünün bir parçası olarak dağıtır. Azure giriş bölgelerini benimseyen tipik bir kuruluş için, azure Bastion'ı her bölge için merkezi kaynaklar olarak dağıtır. Platform ekibi Azure Bastion'ın sahibidir ve bakımını sağlar ve kuruluştaki tüm iş yükleri bunu paylaşır. Bu mimarideki kullanım örneğini göstermek için Azure Bastion, bağlantı aboneliğindeki merkez ağındadır.

İşleç kimliği

Bu mimari, temel mimariyle aynı kimlik doğrulama uzantısını kullanır.

Her zaman uzun süreli erişim yerine bir göreve en az ayrıcalıklı ve ayrıntılı erişim ilkesiyle başlayın. Giriş bölgesi bağlamında platform ekibinin yönettiği tam zamanında (JIT) desteklerinden yararlanın.

Düzeltme eki uyumluluğu ve işletim sistemi yükseltmeleri

Temel mimari , düzeltme eki uygulama ve yükseltme işlemlerine yönelik otonom bir yaklaşımı açıklar. İş yükü giriş bölgeleriyle tümleştirildiğinde bu yaklaşım değişebilir. Platform ekibi, tüm iş yüklerinin kuruluş gereksinimleriyle uyumlu olması için düzeltme eki uygulama işlemlerini dikte edebilir.

Düzeltme eki uygulama işleminin mimariye eklediğiniz tüm bileşenleri içerdiğinden emin olun. Örneğin, uygulamaların dağıtımını, ölçeklendirmesini ve yönetimini otomatikleştirmek için derleme aracısı VM'leri eklemeyi seçerseniz, bu VM'lerin platform gereksinimlerine uyması gerekir.

İzleme

Azure giriş bölgesi platformu, yönetim aboneliğinin bir parçası olarak paylaşılan gözlemlenebilirlik kaynakları sağlar. Ancak, iş yükünün sahiplik sorumluluklarını kolaylaştırmak için kendi izleme kaynaklarınızı sağlamanızı öneririz. Bu yaklaşım temel mimariyle tutarlıdır.

İş yükü ekibi, aşağıdakiler dahil izleme kaynaklarını sağlar:

• Uygulama, iş yükü ekibi için uygulama performansı izleme (APM) hizmeti olarak Analizler.

• İş yüküne ait Azure kaynaklarından ve uygulama kodundan toplanan tüm günlükler ve ölçümler için birleşik havuz olarak Log Analytics çalışma alanı.

Bu mimarinin bir Visio dosyasını indirin.

Temele benzer şekilde, tüm kaynaklar iş yükü ekibinin kaynakların kod olarak altyapı (IaC) dağıtımı kapsamında sağladığı Log Analytics çalışma alanına Azure Tanılama günlükleri gönderecek şekilde yapılandırılır. Günlükleri merkezi bir Log Analytics çalışma alanına da göndermeniz gerekebilir. Azure giriş bölgelerinde bu çalışma alanı yönetim aboneliğindedir.

Platform ekibi, merkezi yönetim aboneliklerine günlük göndermek üzere Tanılamayı yapılandırmak için kullanabileceği DINE ilkelerine de sahip olabilir. Uygulamanızın ek günlük akışlarını kısıtlamadığından emin olmak önemlidir.

Birden çok havuza ait verileri ilişkilendirme

İş yükünün günlükleri, ölçümleri ve altyapı bileşenleri iş yükünün Log Analytics çalışma alanında depolanır. Ancak Azure Güvenlik Duvarı, Microsoft Entra ID ve Azure Bastion gibi merkezi hizmetlerin oluşturduğu günlükler ve ölçümler merkezi bir Log Analytics çalışma alanında depolanır. Birden çok havuza ait verileri ilişkilendirmek karmaşık bir görev olabilir.

Bağıntılı veriler genellikle olay yanıtı sırasında kullanılır. Birden çok havuzdaki verileri ilişkilendirmeyle ilgili bir sorun varsa, bu mimarinin önceliklendirme runbook'unun sorunu çözdiğinden ve sorun iş yükü kaynaklarının ötesine geçerse kuruluş iletişim noktalarını içerdiğinden emin olun. İş yükü yöneticileri, kurumsal ağ, güvenlik veya diğer platform hizmetlerinden günlük girdilerini ilişkilendirmek için platform yöneticilerinden yardım isteyebilir.

Azure İlkesi

Platform ekibi büyük olasılıkla iş yükü dağıtımını etkileyen ilkeler uygular. Genellikle bir uygulama giriş bölgesi aboneliğine otomatik dağıtımları işlemek için DINE ilkeleri uygular. DINE ilkeleri iş yükü kaynaklarını değiştirebilir veya dağıtımınıza kaynak ekleyebilir; bu da iş yükü şablonu aracılığıyla bildirim temelli olarak dağıtılan kaynaklar ile işleme isteklerinin gerçekten kullandığı kaynaklar arasında tutarsızlıklara neden olabilir. Tipik bir çözüm, bu değişiklikleri ideal olmayan kesinlik temelli yaklaşımlarla düzeltmektir.

Bu tutarsızlığı önlemek için platform tarafından başlatılan değişiklikleri IaC şablonlarınıza önceden dahil edin ve test edin. Platform ekibi, uygulamanın gereksinimleriyle çakışan Azure ilkeleri kullanıyorsa platform ekibiyle bir çözüm anlaşması yapabilirsiniz.

Zaman içindeki değişiklikleri yönetme

Platform tarafından sağlanan hizmetler ve işlemler bu mimaride dış bağımlılıklar olarak kabul edilir. Platform ekibi değişiklikleri uygulamaya, kullanıcıları eklemeye ve maliyet denetimlerini uygulamaya devam eder. Kuruluşa hizmet veren platform ekibi, tek tek iş yüklerine öncelik vermeyebilir. İster altın resim değişiklikleri, ister güvenlik duvarı değişiklikleri, otomatik düzeltme eki uygulama veya kural değişiklikleri olsun, bu bağımlılıklarda yapılan değişiklikler birden çok iş yükünü etkileyebilir.

Bu nedenle, iş yükü ve platform ekiplerinin tüm dış bağımlılıkları yönetmek için verimli ve zamanında iletişim kurması gerekir. İş yüklerini olumsuz etkilememeleri için değişiklikleri test etmek önemlidir.

İş yükünü etkileyen platform değişiklikleri

Bu mimaride platform ekibi aşağıdaki kaynakları yönetir. Bu kaynaklarda yapılan değişiklikler iş yükünün güvenilirlik, güvenlik, işlemler ve performans hedeflerini etkileyebilir. İş yükünü nasıl etkilediklerini belirlemek için platform ekibi bunları uygulamaya almadan önce bu değişiklikleri değerlendirmek önemlidir.

• Azure ilkeleri: Azure ilkelerinde yapılan değişiklikler iş yükü kaynaklarını ve bağımlılıklarını etkileyebilir. Örneğin, doğrudan ilke değişiklikleri veya giriş bölgesinin yeni bir yönetim grubu hiyerarşisine taşınması olabilir. Yeni bir dağıtım olana kadar bu değişiklikler gözlerden kaldırılmayabilir, bu nedenle bunları kapsamlı bir şekilde test etmek önemlidir.

• Güvenlik duvarı kuralları: Güvenlik duvarı kurallarında yapılan değişiklikler, iş yükünün sanal ağını veya tüm trafikte yaygın olarak geçerli olan kuralları etkileyebilir. Bu değişiklikler, işletim sistemi yamalarının başarısız uygulanması gibi trafiğin engellenmesine ve hatta sessiz işlem hatalarına neden olabilir. Bu olası sorunlar hem çıkış Azure güvenlik duvarı hem de Azure Sanal Ağ Yöneticisi tarafından uygulanan NSG kuralları için geçerlidir.

• Paylaşılan kaynaklar: SKU'da yapılan değişiklikler veya paylaşılan kaynaklardaki özellikler iş yükünü etkileyebilir.

• Merkez ağında yönlendirme: Bir iş yükü diğer sanal ağlara yönlendirmeye bağımlıysa, merkezdeki yönlendirmenin geçişli yapısındaki değişiklikler iş yükü işlevselliğini etkileyebilir.

• Azure Bastion konağı: Azure Bastion konağı kullanılabilirliği veya yapılandırmasındaki değişiklikler iş yükü işlemlerini etkileyebilir. Atlama kutusu erişim düzeni değişikliklerinin etkili rutin, geçici ve acil durum erişimine sahip olduğundan emin olun.

• Sahiplik değişiklikleri: İş yükünün yönetim ve destek isteklerini etkileyebileceği için sahiplik değişiklikleri ve iletişim noktalarındaki değişiklikleri iş yükü ekibine iletin.

Platformu etkileyen iş yükü değişiklikleri

Aşağıdaki örnekler, platform ekibiyle iletişim kurmanız gereken bu mimarideki iş yükü değişiklikleridir. Platform ekibinin, yeni iş yükü ekibi değişiklikleri uygulanmadan önce platform hizmetinin güvenilirlik, güvenlik, operasyon ve performans hedeflerini doğrulaması önemlidir.

• Ağ çıkışı: İş yükünün ağ cihazlarında gürültülü bir komşu olmasını önlemek için ağ çıkışındaki önemli artışları izleyin. Bu sorun, diğer iş yüklerinin performans veya güvenilirlik hedeflerini etkileyebilir.

• Genel erişim: İş yükü bileşenlerine genel erişimdeki değişiklikler daha fazla test gerektirebilir. Platform ekibi iş yükünü farklı bir yönetim grubuna yeniden yerleşebilir.

• İş açısından kritiklik derecelendirmesi: İş yükünün hizmet düzeyi sözleşmelerinde (SLA) değişiklikler varsa, platform ve iş yükü ekipleri arasında yeni bir işbirliği yaklaşımına ihtiyacınız olabilir.

• Sahiplik değişiklikleri: Sahiplik ve iletişim noktalarındaki değişiklikleri platform ekibine iletin.

İş yükü iş gereksinimi değişiklikleri

İş yükünün hizmet düzeyi hedeflerini (SLO) korumak için platform ekibinin iş yükü mimarisi değişikliklerine dahil olması gerekebilir. Bu değişiklikler platform ekibinden değişiklik yönetimi veya mevcut idarenin değişen gereksinimleri desteklediğini doğrulamayı gerektirebilir.

Örneğin, platform ekibinin gerekli trafiği desteklemek için güvenlik duvarına, Sanal Ağ Yöneticisi'ne veya diğer bileşenlere bu akışı ekleyebilmesi için daha önce izin verilmeyen çıkış akışlarında yapılan değişiklikleri iletin. Buna karşılık, önceden izin verilen bir çıkış akışına artık gerek kalmaması durumunda platform ekibinin iş yükünün güvenliğini korumak için bu akışı engellemesi gerekir. Ayrıca, yönlendirmedeki değişiklikleri diğer sanal ağlara veya şirket içi uç noktalara ya da mimari bileşenlerine yapılan değişiklikleri de iletin. Her kaynak ilkelere ve çıkış güvenlik duvarı denetimine tabidir.

Güvenilirlik

Bu mimari, temel mimarideki güvenilirlik garantileriyle uyumlu hale gelir.

Güvenilirlik hedefleri

Çıkış ağ denetimi gibi bileşenler nedeniyle mümkün olan maksimum bileşik SLO, temel bileşik SLO'dan daha düşüktür. Giriş bölgesi ortamlarında yaygın olarak kullanılan bu bileşenler bu mimariye özgü değildir. İş yükü ekibi bu Azure hizmetlerini doğrudan denetlerse SLO da benzer şekilde azalır.

Mümkün olan en düşük SLO'ya rağmen en önemli güvenilirlik yönü, iş yükü bileşenlerinin işlevsel ekipler arasında bölünmesidir. Bu yöntemle iş yükü ekibi, bu iş yükünün ve diğer iş yüklerinin kullandığı kritik altyapıyı çalıştırmaya odaklanan özel bir ekipten yararlanır.

Daha fazla bilgi için bkz. Güvenilirlik hedeflerini tanımlamak için Öneriler.

Kritik bağımlılıklar

İş yükünün platform ve uygulama giriş bölgesinde bağımlılık olarak gerçekleştirdiği tüm işlevleri görüntüleyin. Olay yanıtı planları, iş yükü ekibinin bu bağımlılıklar için iletişim bilgilerinin noktası ve yönteminin farkında olmasını gerektirir. Ayrıca bu bağımlılıkları iş yükünün hata modu analizine (FMA) dahil edin.

Bu mimari için aşağıdaki bağımlılıkları göz önünde bulundurun:

• Çıkış güvenlik duvarı: Birden çok iş yükü tarafından paylaşılan merkezi çıkış güvenlik duvarı, iş yüküyle ilgili olmayan değişikliklerden geçer.

• Ağ bağlantı noktası tükenmesi: Ağ cihazını paylaşan tüm iş yüklerinin kullanımında ani artışlar çıkış güvenlik duvarında ağ doygunluğuna veya bağlantı noktası tükenmesine neden olabilir.

• DINE ilkeleri: Azure DNS özel DNS bölgeleri (veya platform tarafından sağlanan diğer bağımlılıklar) için DINE ilkeleri, yürütmede SLA olmadan en iyi çabayı gösterir. DNS yapılandırmasındaki bir gecikme, uygulamanın trafiği işlemeye hazır olma süresinde gecikmelere neden olabilir.

• Yönetim grubu ilkeleri: Ortamlar arasında tutarlı ilkeler güvenilirlik açısından önemlidir. Doğru test sağlamak ve bir dağıtımı veya ölçeği engelleyebilecek ortama özgü sapmaları önlemek için üretim öncesi ortamların üretim ortamlarına benzediğinden emin olun. Daha fazla bilgi için bkz . Azure giriş bölgelerinde uygulama geliştirme ortamlarını yönetme.

Bu konuların çoğu Azure giriş bölgeleri olmadan mevcut olabilir, ancak iş yükü ve platform ekiplerinin ihtiyaçların karşılandığından emin olmak için bu sorunları işbirliğiyle ele alması gerekir.

Daha fazla bilgi için bkz. hata modu analizini gerçekleştirmek için Öneriler.

Güvenlik

Bu mimariye ilişkin güvenlik konuları temel mimariden devralınıyor. Aşağıdaki bölümlerde yer alan öneriler, İyi Tasarlanmış Çerçeve'deki güvenlik tasarımı gözden geçirme denetim listesini temel alır.

Ağ denetimleri

İş yükünüzün güvenli olduğundan emin olmak için ağ denetimlerini düzgün yapılandırın.

Giriş trafiği

Alt ağlarınızdaki NSG'ler veya bölgesel merkezdeki geçişsiz doğa veya denetimler aracılığıyla iş yükünüzü kuruluşunuzdaki diğer iş yükü uçlarından yalıtabilirsiniz. Uygulamanızın ve altyapınızın yalnızca gelen ağ gereksinimlerine izin veren kapsamlı NSG'ler oluşturun. Güvenlik için yalnızca merkez ağının geçici olmayan yapısına güvenmemenizi öneririz.

Platform ekibi, Application Gateway'in Web Uygulaması Güvenlik Duvarı reddetme moduna ayarlandığından emin olmak, aboneliğiniz için kullanılabilir genel IP sayısını ve diğer denetimleri kısıtlamak için büyük olasılıkla Azure ilkeleri uygular. Bu ilkelere ek olarak, iş yükü ekibinin giriş güvenlik duruşunu pekiştiren iş yükü merkezli ilkeleri dağıtma sorumluluğuna sahip olması gerekir.

Aşağıdaki tabloda bu mimarideki giriş denetimlerinin örnekleri gösterilmektedir.

Kaynak	Purpose	İş yükü denetimi	Platform denetimi
İnternet	Kullanıcı trafiği akışları	Genel trafiğin ön uç VM'lere giren özel trafiğe geçişine izin vermeden önce NSG, Web Uygulaması Güvenlik Duvarı ve yönlendirme kuralları aracılığıyla tüm istekleri huniler	Hiçbiri
Azure Bastion	VM'lere işleç erişimi	Sanal makine alt ağlarında NSG, platformun belirlenen Azure Bastion alt ağından kaynaklanmadığı sürece uzaktan erişim bağlantı noktalarına yönelik tüm trafiği engeller	Hiçbiri
Diğer uçlar	Hiçbiri	NSG kuralları aracılığıyla engellendi	Azure Sanal WAN güvenli hub'ında geçişsiz yönlendirme veya Azure Güvenlik Duvarı kuralları

Çıkış trafiği

Çözümünüzün gerekli giden bağlantı gereksinimlerini ifade eden ve diğer her şeyi reddeden NSG kurallarını uygulayın. Yalnızca hub ağ denetimlerine güvenmeyin. bir iş yükü operatörü olarak, istenmeyen çıkış trafiğini kaynağa uygun şekilde yakın bir şekilde durdurma sorumluluğunuz vardır.

Sanal ağ içinde alt ağınızın sahibi sizken platform ekibinin, yakalanan gereksinimlerinizi abonelik aracı sürecinizin bir parçası olarak özellikle temsil eden güvenlik duvarı kuralları oluşturduğunu unutmayın. Mimarinizin ömrü boyunca alt ağlardaki ve kaynak yerleşimindeki değişikliklerin özgün isteğinizle uyumlu olduğundan emin olun. Ya da ağ ekibinizle birlikte çalışarak en az erişimli çıkış denetiminin sürekliliğini sağlayabilirsiniz.

Aşağıdaki tabloda bu mimarideki çıkış örnekleri gösterilmektedir.

Uç nokta	Purpose	İş yükü (NSG) denetimi	Platform (hub) denetimi
ntp.ubuntu.com	Linux VM'leri için Ağ Zamanı Protokolü (NTP)	Udp/123 ile ön uç VM alt ağı üzerinden İnternet'e (çıkış güvenlik duvarı bu geniş açılım daraltılır)	İş yükü denetimiyle aynı güvenlik duvarı ağ kuralı izni
Windows Update uç noktaları	Microsoft sunucularından Windows Update işlevselliği	Arka uç VM alt ağındaki İnternet'e TCP/443 ve TCP/80 (çıkış güvenlik duvarı bu geniş açılım kapsamını daraltıyor)	FQDN etiketiyle güvenlik duvarı izin kuralı WindowsUpdate
Aracı uç noktalarını izleme	VM'lerde İzleyici uzantısı için gerekli trafik	her iki VM alt ak üzerinde İnternet'e TCP/443 (çıkış güvenlik duvarı bu geniş açılım kapsamını daraltıyor)	TCP/443 üzerindeki tüm belirli FQDN'ler için gerekli güvenlik duvarı uygulama kuralı izinleri
nginx.org	Nginx'i (örnek bir uygulama bileşeni) doğrudan satıcıdan yüklemek için	Tcp/443 ön uç VM alt ağı üzerinde İnternet'e (çıkış güvenlik duvarı bu geniş açılım daraltılır)	TCP/443'te nginx.org için gerekli güvenlik duvarı uygulama kuralı izni
Key Vault	Application Gateway ve VM'lerde TLS sertifikalarını içeri aktarmak için (Aktarım Katmanı Güvenliği)	- HER iki VM alt ağından özel uç nokta alt ağından özel uç nokta alt ağından TCP/443'e - Application Gateway alt ağından özel uç nokta alt ağından TCP/443'e - Gerekli bir uygulama güvenlik grubu (ASG) ataması ve Application Gateway alt ağı ile etiketlenmiş VM'lerden TCP/443	Hiçbiri

DDOS Koruması

Çözümünüzün tüm genel IP'lerini kapsayan DDoS Koruması planını uygulamaktan kimin sorumlu olduğunu belirleyin. Platform ekibi IP koruma planlarını kullanabilir, hatta sanal ağ koruma planlarını zorunlu kılmak için Azure İlkesi kullanabilir. İnternet'ten giriş için genel IP içerdiğinden bu mimarinin kapsamı olmalıdır.

Daha fazla bilgi için bkz. ağ ve bağlantı için Öneriler.

Gizli dizi yönetimi

Gizli dizi yönetimi için bu mimari temel mimariyi izler.

İş yükü ekibi olarak gizli dizilerinizi Key Vault örneğinizde tutmaya devam edin. Uygulama ve altyapı işlemlerinizi desteklemek için gerektiğinde daha fazla örnek dağıtın.

Daha fazla bilgi için bkz. Uygulama gizli dizilerini korumak için Öneriler.

Maliyet iyileştirme

İş yükü kaynakları için, temel mimarideki maliyet iyileştirme stratejileri de bu mimari için geçerlidir.

Bu mimari, Azure giriş bölgesi platform kaynaklarından büyük ölçüde yararlanır. Bu kaynakları bir geri ödeme modeli aracılığıyla kullansanız bile, eklenen güvenlik ve şirket içi bağlantılar, bu kaynakları kendi kendine yönetmekten daha uygun maliyetlidir.

Platform ekibi bu mimaride aşağıdaki kaynakları yönetir. Bu kaynaklar genellikle tüketim tabanlı (geri ödeme) veya iş yükü ekibi için ücretsiz olabilir.

• Azure Güvenlik Duvarı
• Güvenlik bilgileri ve olay yönetimi (SIEM)
• Azure Bastion konakları
• ExpressRoute gibi şirket içi bağlantılar

Bu avantajları SLO, kurtarma süresi hedefi (RTO) veya kurtarma noktası hedefinden (RPO) ödün vermeden iş yükünüz için genişletmek için platform ekibinizin diğer merkezi tekliflerinden yararlanın.

Daha fazla bilgi için bkz. Maliyet verilerini toplamak ve gözden geçirmek için Öneriler.

Bu senaryoyu dağıtın

GitHub’da bu başvuru mimarisine yönelik bir dağıtıma ulaşılabilir.

Sonraki adım

İş yükü ekibiyle platform ekipleri arasında paylaşılan işbirliği ve teknik ayrıntıları gözden geçirin.

Abonelik otomatları