Azure giriş bölgeleri için test yaklaşımı
Dekont
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 İlkesi tanımları ve atamaları, rol tabanlı erişim denetimi (RBAC) özel rolleri ve atamaları vb. için Azure giriş bölgeleri platform dağıtımını test etmek isteyebilir. Testler, Azure Resource Manager şablonları (ARM şablonları), AzOps, Terraform, Bicep kullanılarak otomasyon aracılığıyla veya Azure portalı üzerinden el ile tamamlanabilir. Bu kılavuz, azure giriş bölgeleri platform dağıtımındaki değişiklikleri ve bunların 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.
Bu kılavuz en çok, üretim ortamı yönetim 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.
Dekont
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, üretim ortamı terimi bu kılavuz boyunca kuruluşunuzun iş yükleriniz için Azure aboneliklerini ve kaynaklarını içeren 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ı yönetim grubu hiyerarşisine ve ilişkili idareye (RBAC ve Azure İlkesi) yerleştirilir ve işlenir.
Bu kılavuz yalnızca azure giriş bölgeleri bağlamında platform düzeyinde test ve değişiklikler içindir.
Kurumsal ölçek, 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 |
| Yönetim grupları abonelik ilişkilendirmesi | Microsoft.Management/managementGroups/subscriptions |
| İlke tanımları | Microsoft.Authorization/policyDefinitions |
| İlke girişimi tanımları veya ilke kümesi tanımları | Microsoft.Authorization/policySetDefinitions |
| İlke atamaları | Microsoft.Authorization/policyAssignments |
| RBAC rol tanımları | Microsoft.Authorization/roleDefinitions |
| RBAC rol atamaları | Microsoft.Authorization/roleAssignments |
| Abonelikler | Microsoft.Subscription/diğer adlar |
Ö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 düzeni değildir. Azure giriş bölgeleri dağıtımları için zorunlu değildir.
Şekil 1: Kanarya yönetim grubu hiyerarşisi.
Diyagramda gösterildiği gibi, Tüm Azure giriş bölgeleri üretim ortamı yönetim grubu hiyerarşisi altında Tenant Root Groupçoğaltılır. Kanarya adı, yönetim grubu görünen adlarının ve kimliklerinin sonuna eklenir. Kimlikler tek bir Microsoft Entra kiracısı içinde benzersiz olmalıdır.
Dekont
Kanarya ortamı yönetim grubu görünen adları, üretim ortamı 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.
Ardından, aşağıdaki kaynak türlerinin testini basitleştirmek için kanarya ortamı yönetim grubu hiyerarşisi 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
Tüm kanarya ortamı yönetim grubu hiyerarşisini dağıtmak istemiyorsanız ne olur?
Kanarya ortamı yönetim grubu hiyerarşisinin tamamını dağıtmak istemiyorsanız, diyagramda gösterildiği gibi korumalı alan aboneliklerini kullanarak üretim ortamı hiyerarşisindeki platform kaynaklarını test edebilirsiniz.
Şekil 2: Kurumsal ölçekli yönetim grubu hiyerarşisi vurgulama korumalı alanları.
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ı ve atamaları 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 testin 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ıyla test yapmanızı sağlar.
Tek bir Microsoft Entra kiracısı kullanma
Tek bir Microsoft Entra kiracısı kullanırken dikkat edilmesi gereken noktalar şunlardır:
- Microsoft Entra kiracıları için Kurumsal ölçekli tasarım önerilerini izler.
- Bulut Benimseme Çerçevesi Azure en iyi yöntemlerine göre, tek bir dizin ve kimlik kılavuzunda standart hale getirme, tek bir Microsoft Entra kiracısı çoğu için en iyi yöntemdir.
- Tek bir Microsoft Entra kiracısında, hem üretim ortamları hem de kanarya Azure giriş bölgeleri ortamları için aynı kullanıcılarla aynı Microsoft Entra kiracısı içindeki ilgili yönetim grubu hiyerarşisine atanmış farklı Microsoft Entra gruplarını kullanabilirsiniz.
- Farklı Microsoft Entra kiracılarındaki birden çok kimlik nedeniyle Microsoft Entra Id lisanslama maliyetleri artırıldı veya çoğaltıldı.
- Bu nokta özellikle Microsoft Entra ID P1 veya P2 özelliklerini kullanan müşteriler için geçerlidir.
- RBAC değişiklikleri hem kanarya ortamlarında hem de üretim ortamlarında daha karmaşık olacaktır çünkü kullanıcıların ve grupların her iki Microsoft Entra kiracısında da aynı olma olasılığı vardır.
- Ayrıca kullanıcılar ve grup kimlikleri, genel olarak benzersiz olduklarından Microsoft Entra kiracılarında aynı olmayacaktır.
- 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, kanarya ortamında değişiklik yapmak yerine üretim ortamında yanlışlıkla değişiklikler yapabilir ve bunun tersi de geçerlidir.
- 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.
Uygulama kılavuzu
Aşağıda, üretim ortamı 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 giriş bölgeleri ortamınızı bugün dağıtmak ve yönetmek için portalı kullanıyorsanız, hem üretim ortamlarının hem de kanarya ortamlarının sık sık eşitlemeden çıkma ve dolayısıyla çoğaltma benzeri bir hiyerarşi ve üretim ortamı sağlamama riski yüksek olduğundan 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ı 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.
- İlgili üretim ortamı veya kanarya ortamı yönetim grubu hiyerarşisi üzerinde izin verilen ayrı Microsoft Entra hizmet sorumlularını (SPN) veya Yönetilen Hizmet Kimliklerini (MSI) kullanın.
- Bu kılavuz en az ayrıcalık ilkesine (PoLP) uyar
- Üretim ortamı ve kanarya ortamı Azure giriş bölgeleri dağıtımları için Kod Olarak Altyapı'yı 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) veya Yönetilen Hizmet Kimliklerini (MSI) kullanma.
- Ü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.
- 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.
- Ayrı bir EA departmanı ve hesabı altında, gerektiğinde kanarya yönetim grubu hiyerarşisinde taşınabilecek bir dizi kanarya aboneliğine sahip olun.
- Bir kaynak kümesinin her zaman kanarya ortamı aboneliklerine dağıtılması yararlı olabilir.
- Kanarya ortamındaki değişikliklerin doğrulanmasına olanak tanıyan bir kaynak kümesi oluşturan ARM şablonları, Bicep veya Terraform gibi Kod Olarak Altyapı şablonlarının olması yararlı olabilir.
- 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.
Bahşiş
Üretimde dağıtılmış Azure giriş bölgeleriniz varsa ve şimdi bir kanarya ortamı eklemek istiyorsanız. Üretim ortamı hiyerarşisinin geçerli dağıtımını kopyalamayı ve kaynakların adlarını değiştirerek kanarya adlandırma düzeninizin ön ekini eklemeyi göz önünde bulundurun.
Bu, kanarya ortamını etkinleştirmek için dağıttığınız ortamın başlangıçtan itibaren üretimle eşitlendiğinden emin olmaktır. Bu, git deposuyla birlikte Kod Olarak Altyapı aracı kullanılırken kolayca elde edilir.
Sonraki adımlar
Giriş bölgesi korumalı alan ortamlarını uygulamayı öğrenin.