Azure giriş bölgeleri için test yaklaşımı

Not

Bu makale yalnızca Microsoft Azure için geçerlidir ve Microsoft 365 veya Microsoft Dynamics 365 gibi diğer Microsoft Bulut teklifleri için geçerli değildir.

Bazı kuruluşlar, Azure giriş bölgeleri platform dağıtımının Azure İlkesi tanımlarını ve atamalarını, rol tabanlı erişim denetimi (RBAC) özel rollerini ve atamalarını vb. test etmek isteyebilir. Testler, Azure Resource Manager şablonları (ARM şablonları), Terraform, Bicep kullanılarak otomasyon aracılığıyla veya Azure portalı üzerinden el ile tamamlanabilir. Bu kılavuz, değişiklikleri ve bunların Azure giriş bölgeleri platform dağıtımı üzerindeki etkilerini test etmek için kullanılabilecek bir yaklaşım sağlar.

Bu makale, PlatformOps ve Merkezi işlev ekipleri ve görevleriyle ilgili olarak Platform otomasyonu ve DevOps kritik tasarım alanı kılavuzuyla da kullanılabilir. Ayrıca, Azure iniş bölgeleri dağıtımında ilke değişikliklerini dağıtma teknikleri için ilke odaklı kılavuzları benimseme kılavuzuyla birleştirilebilir.

Bu kılavuz en çok, üretim yönetimi grubu hiyerarşisinde yapılan değişiklikleri yöneten güçlü değişiklik yönetimi süreçlerine sahip kuruluşlar için uygundur. Kanarya yönetim grubu hiyerarşisi, dağıtımları üretim ortamına dağıtmadan önce yazmak ve test etmek için bağımsız olarak kullanılabilir.

Not

Kanarya terimi, geliştirme ortamlarıyla veya test ortamlarıyla karışıklığı önlemek için kullanılır. Bu ad yalnızca çizim amacıyla kullanılır. Kanarya Azure giriş bölgeleri ortamınız için uygun gördüğünüz herhangi bir adı tanımlayabilirsiniz.

Benzer şekilde, bu kılavuzda üretim ortamı/hiyerarşisi terimi, kuruluşunuzun iş yükleriniz için Azure aboneliklerini ve kaynaklarını içeren Azure giriş bölgeleri yönetim grubu hiyerarşisine başvurmak için kullanılır.

Platform tanımı

Önemli

Bu kılavuz giriş bölgeleri, iş yükleri, uygulamalar veya hizmetler olarak bilinen uygulama veya hizmet sahipleri tarafından kullanılacak geliştirme ortamlarına veya test ortamlarına yönelik değildir. Bunlar, üretim ortamındaki Azure giriş bölgeleri yönetim grubu hiyerarşisine ve ilişkili yönetime (RBAC ve Azure İlkesi) yerleştirilir ve işlenir.

Uygulama iş yükleri ve ekipleri için geliştirme, test, kullanıcı kabul testi (UAT) ve üretim ortamları hakkında rehberlik için bkz. Azure giriş bölgelerinde uygulama geliştirme ortamlarını yönetme.

Bu kılavuz yalnızca azure giriş bölgeleri bağlamında platform düzeyinde test ve değişiklikler içindir.

Azure giriş bölgeleri, giriş bölgelerini büyük ölçekte oluşturmanızı ve kullanıma hazır hale getirmenizi sağlamak için gerekli Azure platformu bileşenlerini tasarlamanıza ve dağıtmanıza yardımcı olur.

Bu makalenin kapsamındaki platform kaynakları ve bu test yaklaşımı şunlardır:

Ürün veya hizmet	Kaynak sağlayıcısı ve türü
Yönetim grupları	Microsoft.Management/managementGroups
Aboneliklerin yönetim gruplarıyla ilişkilendirilmesi	Microsoft.Management/managementGroups/subscriptions
İlke tanımları	Microsoft.Authorization/policyDefinitions
İlke girişimi tanımları veya ilke kümesi tanımları	Microsoft.Authorization/policySetDefinitions
Politika atamaları	Microsoft.Authorization/policyAssignments
RBAC rol tanımları	Microsoft.Authorization/roleDefinitions
RBAC rol atamaları	Microsoft.Authorization/roleAssignments
Abonelikler	Microsoft.Subscription/aliases

Örnek senaryolar ve sonuçlar

Bu senaryoya örnek olarak, İlke temelli idare tasarım ilkesine göre tüm giriş bölgelerindeki kaynakları ve ayarları idare etmek için yeni bir Azure İlkesi etkisini ve sonucunu test etmek isteyen bir kuruluş gösteriliyor. Bu değişikliği doğrudan üretim ortamında yapmak istemiyorlar çünkü bu değişikliğin etkisinden endişe duyuyorlar.

Bu platform değişikliğini test etmek için kanarya ortamını kullanmak, kuruluşun Azure İlkesi değişikliğin etkisini ve sonucunu uygulamasına ve gözden geçirmesine olanak tanır. Bu işlem, üretim ortamına Azure İlkesi uygulamadan önce kuruluşun gereksinimlerini karşılamasını sağlayacaktır.

Benzer bir senaryo, Azure RBAC rol atamalarında ve Microsoft Entra grup üyeliklerinde değişiklik olabilir. Üretim ortamında değişiklikler yapılmadan önce bir test biçimi gerekebilir.

Önemli

Bu, çoğu müşteri için yaygın bir dağıtım yaklaşımı veya deseni değildir. Azure iniş alanları dağıtımları için zorunlu değildir.

Şekil 1: Kanarya yönetim grubu hiyerarşisi.

Diyagramda gösterildiği gibi, Azure giriş bölgeleri üretim yönetimi grubu hiyerarşisinin tamamı Tenant Root Group altında çoğaltılır. Yönetim grubu görünen adlarının ve kimliklerinin sonuna Kanarya adı eklenir. Kimlikler tek bir Microsoft Entra kiracısı içinde benzersiz olmalıdır.

Not

Kanarya yönetim grubu görünen adları, üretim yönetim grubu görünen adları ile aynı olabilir. Bu, kullanıcıların kafa karışıklığına neden olabilir. Bu nedenle, görünen adlara ve kimliklerine "kanarya" adını eklemenizi öneririz.

Kanarya yönetim grubu hiyerarşisi daha sonra aşağıdaki kaynak türlerinin testini basitleştirmek için kullanılır:

• Yönetim grupları
  • Abonelik yerleşimi
• RBAC
  • Roller (yerleşik ve özel)
  • Atamalar
• Azure İlkesi
  • Tanımlar (yerleşik ve özel)
  • Küme tanımları olarak da bilinen girişimler
  • Atamalar

Kanarya yönetim grubu hiyerarşisini dağıtmak istemiyorsanız ne olur?

Kanarya yönetim grubu hiyerarşisini dağıtmak istemiyorsanız, diyagramda gösterildiği gibi korumalı alan aboneliklerini kullanarak üretim ortamı hiyerarşisindeki platform kaynaklarını test edebilirsiniz.

Şekil 2: Korumalı alanları vurgulayan Azure iniş bölgeleri yönetim grubu hiyerarşisi.

Bu senaryoda Azure İlkesi ve RBAC'yi test etmek için, testi tamamlamak istediğiniz kimliğe Sahip RBAC rolünün atandığı tek bir Azure aboneliğine (örneğin, Kullanıcı Hesabı, Hizmet Sorumlusu veya Yönetilen Hizmet Kimliği) ihtiyacınız vardır. Bu yapılandırma yalnızca korumalı alan aboneliği kapsamında Azure İlkesi tanımlarını ve atamalarını yazmanıza, atamanıza ve düzeltmenize olanak tanır.

Bu korumalı alan yaklaşımı, örneğin belirli bir kullanım örneğine yönelik izinler vermek üzere yeni bir özel RBAC rolü geliştiriyorsanız abonelik içindeki RBAC testi için de kullanılabilir. Bu testlerin tümü, korumalı alan aboneliğinde yapılabilir ve hiyerarşide daha yüksek roller oluşturup atamadan önce test edilebilir.

Bu yaklaşımın avantajlarından biri, korumalı alan aboneliklerinin gerekli olduğu süre boyunca kullanılabilmesi ve ardından ortamdan silinmesidir.

Ancak bu yaklaşım, yönetim grubu hiyerarşisinden RBAC ve Azure ilkelerinin devralınmasını test etmenize izin vermez.

Uygulama kılavuzu

Aşağıda, üretim ortamı Azure giriş bölgeleri yönetim grubu hiyerarşisinin yanı sıra Azure giriş bölgeleri için kanarya yönetim grubu hiyerarşisini uygulama ve kullanma yönergeleri verilmiştir.

Uyarı

Azure iniş bölgeleri ortamınızı bugün dağıtmak ve yönetmek için portalı kullanıyorsanız, üretim ve kanarya ortamlarının sıkça uyumsuz hale gelmesi ve dolayısıyla, üretimi taklit eden bir hiyerarşi ve ortam sunmama riski nedeniyle, kanarya yaklaşımını verimli bir şekilde benimsemek ve kullanmak zor olabilir.

Bu senaryodaysanız yukarıda listelendiği gibi Azure giriş bölgeleri için Kod Olarak Altyapı (IaC) dağıtım yaklaşımına geçmeyi göz önünde bulundurun. Ya da kanarya ve üretim arasındaki yapılandırma kaymasının olası risklerine dikkat edin ve dikkatli olun. Daha fazla bilgi için bkz. Azure giriş bölgelerini güncelleştirmek için IaC kullanma.

1. İlgili üretim ortamı veya kanarya ortamı Azure giriş bölgeleri yönetim grubu hiyerarşisi üzerinde izin verilen ayrı Microsoft Entra hizmet sorumlularını (SPN) veya Yönetilen Kimlikleri (MI) kullanın.
   • Bu kılavuz en az ayrıcalık ilkesine (PoLP) uyar
2. Üretim ortamı ve kanarya ortamı Azure giriş bölgeleri dağıtımları için IaC'yi tutmak için git deposu, dalları veya depoları içinde ayrı klasörler kullanın.
   • Hangi hiyerarşinin dağıtıldığına bağlı olarak CI/CD işlem hatlarının bir parçası olarak ilgili Microsoft Entra hizmet sorumlularını (SPN' ler) veya Yönetilen Kimlikleri (MI) kullanma.
3. Üretim ortamında olduğu gibi kanarya ortamı için git dal ilkeleri veya güvenliği uygulayın.
   • Onaylayanların sayısını azaltmayı ve kanarya ortamının hızlı başarısız olmasına yönelik denetimleri göz önünde bulundurun.
4. Dağıtılmakta olan hiyerarşiyi değiştirmek için ortam değişkenlerini kullanan Azure Pipelines veya GitHub eylemlerini kullanın. Diğer bir seçenek de işlem hatlarını kopyalamak ve dağıtılmakta olan hiyerarşiyi tanımlamak için sabit kodlanmış ayarları değiştirmektir.
   • Azure Pipelines DevOps şablonlarını veya GitHub Actions İş Akışı Şablonlarını kullanmak, Kendinizi Yineleme (DRY) ilkesine bağlı kalmanıza yardımcı olur.
5. Ayrı bir ödeme hesabı altında, örneğin bir Kurumsal Anlaşma (EA) Hesabı veya Microsoft Müşteri Sözleşmesi (MCA) fatura bölümü gibi, kanarya yönetim grubu hiyerarşisinde gerektiğinde taşınabilecek bir dizi kanarya aboneliğine sahip olun.
   • Kanarya ortamında yapılan değişikliklerin test ve doğrulamasını hızlandırmak için her zaman kanarya ortamı aboneliklerine dağıtılan bir kaynak kümesinin olması yararlı olabilir.
6. Azure İlkesi ve RBAC değişikliklerini test etmek için kanarya ortamındaki kanarya aboneliklerine dağıtabileceğiniz bir dizi örnek uygulama iş yükü mimarisine sahip olun. Bu, değişiklikleri üretim ortamına dağıtmadan ve yükseltmeden önce doğrulamanıza yardımcı olur.
   • Bu örnek iş yükleri, üretim uygulaması iş yüklerini dağıtmak için kullanılan IaC şablonları kullanılarak dağıtılabilir. Bu, kanarya ortamının üretim ortamıyla eşitlendiğinden ve test ettiğiniz değişikliklerin üretim ortamı için geçerli ve uygulanabilir olduğundan emin olmanıza yardımcı olur.
   • Kuruluşunuzdaki en son mimari ve tasarım desenleriyle ilgili ve güncel olduklarından emin olmak için örnek iş yüklerini sürekli gözden geçirip güncelleştirmeniz gerekir.
   • Uygulama ekiplerinize başvuru mimarileri sağlıyorsanız, bunları kanarya ortamına da dağıtmayı göz önünde bulundurun. Bu, değişiklikleri başvuru mimarilerine göre doğrulamanıza ve bunların üretim ortamına uygulanabilir olduğundan emin olmanıza yardımcı olur.
7. Tüm kanarya ortamı abonelikleri dahil olmak üzere tüm Azure abonelikleri için tüm Azure etkinlik günlüklerini, Azure giriş bölgeleri tasarım önerilerine göre üretim ortamı Azure Log Analytics çalışma alanına gönderin.
   • Bu, güvenlik ve operasyon ekiplerinizin üretim ortamında Azure İlkesi ve RBAC değişikliklerinin test edilmesinden kaynaklanabilir değişiklikler veya sorunlar için kanarya ortamını izlemesine yardımcı olur.

İpucu

Üretimde dağıtılmış Azure giriş bölgeleriniz varsa ve şimdi bir kanarya ortamı eklemek istiyorsanız. Üretim ortamı hiyerarşisinin mevcut dağıtımını kopyalamayı ve kaynakların adlarını, kanarya adlandırma düzeninize uygun bir şekilde ön ek ekleyerek değiştirmeyi düşünün.

Başlangıçtan itibaren kanarya ortamını etkinleştirmek için dağıttığınız şeyin, üretim ile uyumlu olduğundan emin olmaktır. Bu, git deposuyla birlikte bir IaC aracı kullanılırken kolayca elde edilir.

Tek bir Microsoft Entra kiracısı kullanma

Tek bir Microsoft Entra kiracısı kullanırken dikkat edilmesi gereken noktalar şunlardır:

• Tek bir kiracı kullanmak, Microsoft Entra kiracıları için Azure giriş bölgeleri tasarım önerilerini izler.
  • Tek bir Microsoft Entra kiracısında, üretim ve kanarya Azure giriş bölgesi ortamları için farklı Microsoft Entra gruplarını kullanabilir ve aynı kullanıcıları, bunların ilgili yönetim grubu hiyerarşisine atayabilirsiniz.
• Farklı Microsoft Entra kiracıları arasında birden çok kimlik bulunması nedeniyle Microsoft Entra ID lisanslama maliyetleri artabilir veya çoğalabilir. Bu özellikle Microsoft Entra ID P1 veya P2 özelliklerini kullanan müşteriler için geçerlidir.
• RBAC değişiklikleri, kullanıcıların ve grupların her iki Microsoft Entra kiracısında da aynı olmama olasılığı nedeniyle hem kanarya hem de üretim ortamlarında daha karmaşıktır.
  • Genel olarak benzersiz olduklarından kullanıcıların ve grup kimliklerinin Microsoft Entra kiracılarında aynı olmayacağına dikkat edin.
• Birden çok Microsoft Entra kiracısını yönetmenin neden olduğu karmaşıklığı ve yönetim yükünü azaltır.
  • Test gerçekleştirmek için ayrı kiracılara erişimi sürdürmesi ve oturum açması gereken ayrıcalıklı kullanıcılar, örnek olarak kanarya ortamı yerine üretim ortamında yanlışlıkla değişiklikler yapabilir.
• Yapılandırma kayması ve dağıtım hatası olasılığını azaltır.
• Ek güvenlik ve cam kırılması veya acil durum erişim süreçlerinin oluşturulmasını gerektirmez.
• Azure giriş bölgeleri dağıtımında değişiklik yapmak için gereken sürtüşme ve süreyi azaltır.

Sonraki adımlar

Bir kanarya ortamına sahip olduktan sonra, Azure İlkesi ve RBAC değişikliklerini üretim Azure giriş bölgeleri yönetim grubu hiyerarşinize dağıtmadan önce test etmeye başlayabilirsiniz.

Kanarya ortamında Azure İlkeleri'nde yapılan değişiklikleri test ettiğinizde, ilke temelli korumaları benimseme kılavuzunda belirtilen yaklaşımı izleyerek bunları üretim ortamına yükseltebilirsiniz. Bu, ilke atamalarının zorlama modu özelliği kullanılarak yapılır. Bu kılavuzda belgelenen yaklaşımı kullanmak, üretim ortamında Azure İlkesi'ni istediğiniz etkiyle zorlamadan önce ek bir test aşamasına geçmenizi sağlar ve bu da yaptığınız Azure İlkesi değişikliklerinde güven oluşturmanıza yardımcı olur.

Ayrıca uygulama ekiplerinizin iş yüklerinin geliştirilmesi ve test edilmesi için kullanabilecekleri korumalı alan ortamlarını da gözden geçirebilirsiniz. Bu, kanarya ortamı için ayrı bir kavramdır ve uygulama ekiplerinin üretime dağıtılmadan önce iş yüklerini geliştirmeleri ve test etmeleri için güvenli bir ortam sağlamak için kullanılır.

İniş alanı sanal ortamlarını uygulama