Azure giriş bölgesi mimarisini gereksinimleri karşılayacak şekilde uyarlama

Azure giriş bölgesi kılavuzunun bir parçası olarak çeşitli başvuru uygulama seçenekleri sağlanır:

• Azure Sanal WAN ile Azure giriş bölgesi
• Geleneksel merkez ve uç ile Azure giriş bölgesi
• Azure giriş bölgesi temeli
• Küçük kuruluşlar için Azure giriş bölgesi

Bu seçenekler, azure giriş bölgesi kavramsal mimarisini ve tasarım alanlarındaki en iyi yöntemleri sunan yapılandırmaları kullanarak kuruluşunuzun hızlı bir şekilde çalışmaya başlamasına yardımcı olabilir.

Başvuru uygulamaları, Microsoft ekiplerinin müşterilerle ve iş ortaklarıyla etkileşimlerden elde eden en iyi uygulamaları ve öğrenmelerini temel alır. Bu bilgi, 80/20 kuralının "80" tarafını temsil eder. Çeşitli uygulamalar, mimari tasarım sürecinin bir parçası olan teknik kararlar üzerinde pozisyon alır.

Tüm kullanım örnekleri aynı olmadığından, tüm kuruluşlar tam olarak amaçlanan şekilde bir uygulama yaklaşımı kullanamaz. Bir uyarlama gereksinimi belirlendiğinde dikkat edilmesi gereken noktaları anlamanız gerekir.

Azure giriş bölgelerinde giriş bölgesi arketipi nedir?

Giriş bölgesi arketipi, giriş bölgesinin (Azure aboneliği) belirli bir kapsamda beklenen ortam ve uyumluluk gereksinimlerini karşıladığından emin olmak için neyin doğru olması gerektiğini açıklar. Örnekler şunları içerir:

• atamaları Azure İlkesi.
• Rol tabanlı erişim denetimi (RBAC) atamaları.
• Ağ gibi merkezi olarak yönetilen kaynaklar.

İlke devralma işleminin Azure'da çalışma şekli nedeniyle kaynak hiyerarşisindeki her yönetim grubunu son giriş bölgesi arketip çıkışına katkıda bulunmak olarak düşünün. Alt düzeyleri tasarlarken kaynak hiyerarşisindeki üst düzeylerde nelerin uygulandığını düşünün.

Yönetim grupları ve giriş bölgesi arketipleri arasında yakın bir ilişki vardır, ancak yalnızca bir yönetim grubu giriş bölgesi arketipi değildir. Bunun yerine, ortamınızdaki giriş bölgesi arketiplerinin her birini uygulamak için kullanılan çerçevenin bir parçasını oluşturur.

Bu ilişkiyi Azure giriş bölgesi kavramsal mimarisinde görebilirsiniz. İlke atamaları, tüm iş yüklerine uygulanması gereken ayarlar için contoso gibi ara kök yönetim grubunda oluşturulur. Daha belirli gereksinimler için hiyerarşinin alt düzeylerinde daha fazla ilke ataması oluşturulur.

Yönetim grubu hiyerarşisi içindeki abonelik yerleşimi, belirli bir giriş bölgesine (Azure aboneliği) devralınan, uygulanan ve uygulanan Azure İlkesi ve erişim denetimi (IAM) atamalarının sonuç kümesini belirler.

Giriş bölgesinin gerekli merkezi olarak yönetilen kaynaklara sahip olduğundan emin olmak için daha fazla işlem ve araç gerekebilir. Bazı Örnekler:

• Etkinlik günlüğü verilerini Log Analytics çalışma alanına göndermek için tanılama ayarları.
• Bulut için Microsoft Defender için sürekli dışarı aktarma ayarları.
• Uygulama iş yükleri için yönetilen IP adresi alanları olan sanal ağ.
• Sanal ağların dağıtılmış hizmet reddi (DDoS) Ağ Koruması'na bağlanması.

Not

Azure giriş bölgesi başvuru uygulamalarında, önceki kaynaklardan bazılarının dağıtımını DeployIfNotExists gerçekleştirmek için ve Modifyetkilerine sahip Azure ilkeleri kullanılır. İlke temelli idare tasarım ilkesini izlerler.

Daha fazla bilgi için bkz . İlke temelli korumaları benimseme.

Azure giriş bölgesi kavramsal mimarisi için yerleşik arketipler

Kavramsal mimari, corp ve online gibi uygulama iş yükleri için örnek giriş bölgesi arketiplerini içerir. Bu arketipler kuruluşunuz için geçerli olabilir ve gereksinimlerinizi karşılayabilir. Bu arketiplerde değişiklik yapmak veya yenilerini oluşturmak isteyebilirsiniz. Kararınız kuruluşunuzun gereksinimlerine ve gereksinimlerine bağlıdır.

İpucu

Azure giriş bölgesi hızlandırıcısında giriş bölgesi arketiplerini gözden geçirmek için bkz . Azure giriş bölgesi hızlandırıcısında yönetim grupları.

Kaynak hiyerarşisinde başka bir yerde de değişiklik oluşturmak isteyebilirsiniz. Kuruluşunuz için Azure giriş bölgeleri uygulamanız için hiyerarşiyi planlarken, tasarım alanlarındaki yönergeleri izleyin.

Kavramsal mimariden alınan aşağıdaki giriş bölgesi arketipi örnekleri, amaçlarını ve amaçlanan kullanımlarını anlamanıza yardımcı olur:

Giriş bölgesi arketipi (yönetim grubu)	Amaç veya kullanım
Corp	Kurumsal giriş bölgeleri için ayrılmış yönetim grubu. Bu grup, bağlantı aboneliğindeki hub üzerinden şirket ağıyla bağlantı veya karma bağlantı gerektiren iş yüklerine yöneliktir.
Çevrimiçi	Çevrimiçi giriş bölgeleri için ayrılmış yönetim grubu. Bu grup, doğrudan İnternet'e gelen/giden bağlantı gerektirebilecek iş yükleri veya sanal ağ gerektirmeyen iş yükleri içindir.
Korumalı alan	Yalnızca bir kuruluş tarafından test ve araştırma için kullanılacak abonelikler için ayrılmış yönetim grubu. Bu aboneliklerin kurumsal ve çevrimiçi giriş bölgeleriyle bağlantısı güvenli bir şekilde kesilir. Korumalı alanlar ayrıca Azure hizmetlerinin testini, keşfini ve yapılandırmasını etkinleştirmek için daha az kısıtlayıcı bir ilke kümesine de atanır.

Özelleştirmenin gerekebileceği senaryolar

Belirtildiği gibi, Azure giriş bölgesi kavramsal mimarisinde ortak giriş bölgesi arketipleri sağlarız. Şirket içi ve çevrimiçidirler. Bu arketipler sabit değildir ve uygulama iş yükleri için izin verilen tek giriş bölgesi arketipleri değildir. Giriş bölgesi arketiplerini ihtiyaçlarınıza ve gereksinimlerinize uyacak şekilde uyarlamanız gerekebilir.

Giriş bölgesi arketiplerini uyarlamadan önce kavramları anlamanız ve hiyerarşinin özelleştirmenizi önerdiğimiz alanını görselleştirmeniz önemlidir. Aşağıdaki diyagramda Azure giriş bölgesi kavramsal mimarisinin varsayılan hiyerarşisi gösterilmektedir.

Hiyerarşinin iki alanı vurgulanır. Biri Giriş Bölgeleri'nin altında, diğeri platform'un altındadır.

Uygulama giriş bölgesi arketiplerini uyarla

Giriş Bölgeleri yönetim grubunun altında mavi renkle vurgulanan alana dikkat edin. Mevcut hiyerarşi kullanılarak mevcut bir arketipe daha fazla ilke ataması olarak eklenmeyecek yeni veya daha fazla gereksinimi karşılamak için daha fazla arketip eklemek hiyerarşideki en yaygın ve en güvenli yerdir .

Örneğin, ödeme kartı sektörü (PCI) uyumluluk gereksinimlerini karşılaması gereken bir dizi uygulama iş yükünü barındırmak için yeni bir gereksiniminiz olabilir. Ancak bu yeni gereksinimin tüm varlığınızdaki tüm iş yükleri için geçerli olması gerekmez.

Bu yeni gereksinimi karşılamanın basit ve güvenli bir yolu vardır. Hiyerarşideki Giriş Bölgeleri yönetim grubunun altında PCI adlı yeni bir yönetim grubu oluşturun. YENI PCI yönetim grubuna PCI v3.2.1:2018 için Bulut için Microsoft Defender mevzuat uyumluluğu ilkesi girişimi gibi daha fazla ilke atayabilirsiniz. Bu eylem yeni bir arketip oluşturur.

Artık gerekli ilkeleri devralmak ve yeni arketipi oluşturmak için yeni Azure aboneliklerini yeni PCI yönetim grubuna yerleştirebilir veya taşıyabilirsiniz.

Bir diğer örnek de gizli işlem için yönetim grupları ekleyen ve düzenlemeye tabi sektörlerde kullanılmak üzere hizalanan Egemenlik için Microsoft Bulut'tır. Egemenlik için Microsoft Bulut, uygun egemenlik denetimleriyle genel bulutu benimsemeye yönelik araçlar, rehberlik ve korumalar sağlar.

İpucu

Azure aboneliklerini RBAC ve Azure İlkesi göre yönetim grupları arasında taşıdığınızda dikkate almanız gerekenleri ve ne olacağını bilmeniz gerekir. Daha fazla bilgi için bkz . Mevcut Azure ortamlarını Azure giriş bölgesi kavramsal mimarisine geçirme.

Platform giriş bölgesi arketiplerini uyarla

Platform yönetim grubunun altında turuncu renkle vurgulanan alanı da uyarlamak isteyebilirsiniz. Bu alandaki bölgeler platform giriş bölgeleri olarak bilinir.

Örneğin, iş yüklerini barındırmak için kendi arketipini gerektiren özel bir SOC ekibiniz olabilir. Bu iş yüklerinin Yönetim yönetim grubundan farklı Azure İlkesi ve RBAC atama gereksinimlerini karşılaması gerekir.

Hiyerarşideki Platform yönetim grubunun altında yeni bir Güvenlik yönetim grubu oluşturun. Gerekli Azure İlkesi ve RBAC atamalarını buna atayabilirsiniz.

Artık gerekli ilkeleri devralmak ve yeni arketipi oluşturmak için yeni Azure aboneliklerini yeni Güvenlik yönetim grubuna yerleştirebilir veya taşıyabilirsiniz.

Uyarlanmış Azure giriş bölgesi hiyerarşisi örneği

Aşağıdaki diyagramda, uyarlanmış bir Azure giriş bölgesi hiyerarşisi gösterilmektedir. Önceki diyagramdaki örnekleri kullanır.

Dikkat edilmesi gereken noktalar

Hiyerarşide Azure giriş bölgesi arketiplerini uygulamanızı uyarlamayı düşünürken aşağıdaki noktaları göz önünde bulundurun:

• Hiyerarşiyi uyarlamak zorunlu değildir. Sağladığımız varsayılan arketipler ve hiyerarşi çoğu senaryo için uygundur.

• Kuruluş hiyerarşinizi, ekiplerinizi veya departmanlarınızı arketiplerde yeniden oluşturmayın.

• Yeni gereksinimleri karşılamak için her zaman mevcut arketipleri ve hiyerarşiyi oluşturmaya çalışın.

• Yalnızca gerçekten ihtiyaç duyulduğunda yeni arketipler oluşturun.

  Örneğin, uygulama iş yüklerinin yalnızca bir alt kümesi için PCI gibi yeni bir uyumluluk gereksinimi gereklidir ve tüm iş yüklerine uygulanması gerekmez.

• Yalnızca önceki diyagramlarda gösterilen vurgulanan alanlarda yeni arketipler oluşturun.

• Karmaşıklığı ve gereksiz dışlamaları önlemek için dört katmanın hiyerarşi derinliğinin ötesine geçmekten kaçının. Arketipleri hiyerarşide dikey olarak değil yatay olarak genişletin.

• Geliştirme, test ve üretim gibi ortamlar için arketipler oluşturmayın.

  Daha fazla bilgi için bkz. Azure giriş bölgeleri kavramsal mimarisinde geliştirme/test/üretim iş yükü giriş bölgelerini nasıl işleyebiliriz?

• Brownfield ortamından geliyorsanız veya "yalnızca denetim" zorlama modunda ilkelerle Giriş Bölgeleri Yönetim Grubu'nda abonelikleri barındırmak için bir yaklaşım arıyorsanız, Senaryo: Giriş bölgesi yönetim grubunu çoğaltarak ortam geçişi'ni gözden geçirin