Aracılığıyla paylaş


Birden çok kiracıda Azure giriş bölgelerini otomatikleştirme

Kuruluşunuzun her birinde bir veya birden çok kez Azure giriş bölgeleri (ALZ) bulunan birden çok Microsoft Entra kiracısı varsa otomasyon önemlidir. Otomasyon, ALZ dağıtımını tüm kiracılar genelinde büyük ölçekte başarıyla çalıştırmaya ve sürdürmeye yardımcı olur. Birden çok kiracıda ALZ dağıtımlarını otomatikleştirmeye yönelik birçok yaklaşım vardır. Yaklaşımınız, kuruluşunuzun birden çok Microsoft Entra kiracısı olmasının nedenlerine bağlıdır.

Örneğin, bağımsız bir yazılım satıcısıysanız birden çok Microsoft Entra kiracınız olabilir. Şirket ve SaaS çözümlerinizi Microsoft Entra kiracılarını ayrı tutmak isteyebilirsiniz. bir işlemin veya dağıtımın, amaçlanan veya yanlışlıkla diğer kiracıyı etkileme riski azalır.

Aşağıdaki bölümlerde, gerçekleştirebileceğiniz yaklaşımlar hakkında diyagramlar ve yönergeler sağlanır. Birden çok Microsoft Entra kiracısını işlerken Azure giriş bölgeleri dağıtımlarınızı otomatikleştirmeye yönelik gereksinimlerinize, dikkate alınacak noktalara ve önerilere göre sizin için en uygun yaklaşımı seçin.

Yaklaşım

Azure giriş bölgelerinin birden çok Microsoft Entra kiracısı arasında dağıtımını otomatikleştirmeye yönelik iki yaklaşım vardır.

Yaklaşım 1 – Tam yalıtım , çok kiracılı senaryolarda en yaygın yaklaşımdır. Bu yaklaşım, çok kiracılı bir yaklaşım kullanılırken en yaygın gereksinim olan Microsoft Entra kiracıları arasında gerekli ayrımı ve yalıtımı korur.

Yaklaşım 2 – Birden çok hizmet sorumlusuna sahip paylaşılan uygulama kaydı (çok kiracılı), Yönetilen Hizmet Sağlayıcısı (MSP) senaryolarında yaygın olarak kullanılır. Bu yaklaşımda, büyük ölçekte birden çok kiracıda neredeyse aynı mimarinin dağıtımını otomatikleştirmek için dağıtım damgaları deseni kullanılabilir.

Bu yaklaşımların her ikisi de örnek ve ilham olarak sağlanır. Kuruluşunuzun gereksinimlerine göre dağıtımlarınızdaki yaklaşımları karıştırabilir ve eşleştirebilirsiniz.

Önemli

Bu makale, azure giriş bölgelerinin kuruluşunuzun sahip olduğu her Microsoft Entra kiracısında platform olarak dağıtımını ve çalışmasını otomatikleştirmeyi kapsar. Bu makaledeki yaklaşımlar, öneriler ve dikkat edilmesi gerekenler, hizmetlerini ve uygulamalarını giriş bölgelerine (abonelikler) dağıtan ve çalıştıran uygulama ekipleri tarafından kullanılmaya yönelik değildir . Farklı giriş bölgesi türleri hakkında daha fazla bilgi için bkz . Platform ve uygulama giriş bölgeleri.

Yaklaşım 1 – Tam yalıtım

Bu yaklaşımda birincil amaç, aşağıdakiler gibi tüm otomasyon bileşenlerinde her Microsoft Entra kiracısını birbirinden yalıtılmış tutmaktır:

  • Git deposu.
  • GitHub Actions veya Azure Pipelines (kullanılıyorsa, şirket içinde barındırılan çalıştırıcılar dahil).
  • Şirket içinde barındırılan çalıştırıcılara atanan yönetilen kimlikler, hizmet asıl adları (SPN'ler), kullanıcılar veya yöneticiler gibi otomasyondan görevleri gerçekleştirmek için kullanılan kimlikler.

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed using the complete isolation automation approach.

Bu yaklaşımda, bir Microsoft Entra kiracısı başına çoğaltılan, yönetilmesi gereken daha fazla bileşen vardır. Bazı kuruluşlarda bu tür ayrım ve yalıtım gerektiren mevzuat uyumluluğu denetimleri zorunlu kılınabilir.

Dekont

Kuruluşunuz yalnızca platform otomasyonu için yönetilen kimliklerin kullanılmasına izin veriyorsa, bu yaklaşımı veya her kiracıda ayrı ayrı oturum açan bir yaklaşımı kullanmanız gerekir. Yönetilen kimlikler kiracılar arası senaryoları desteklemez. Daha fazla bilgi için bu SSS bölümüne bakın.

Platform yöneticileri ve geliştiriciler için kimlikler - Yaklaşım 1

Bu yaklaşımda kimlikler de her Microsoft Entra kiracısında yalıtılmalıdır. Bu, her platform yöneticisinin veya geliştiricisinin bu kiracıda işlem gerçekleştirmek için her kiracı içinde ayrı bir kullanıcı hesabı gerektirdiği anlamına gelir. Bu hesaplar, kiracıların her biri için GitHub veya Azure DevOps gibi geliştirici araçlarına erişmek için de kullanılır. Bu yaklaşımı izleyerek yönetici ve geliştirici üretkenliğinin etkilerini dikkatle göz önünde bulundurun.

Microsoft Entra B2B ve/veya Azure Lighthouse kullanılabilir, ancak bu seçenek ayrı Microsoft Entra kiracılarına sahip olma nedenini sorgulamaz.

Yaklaşım 2 – Birden çok hizmet sorumlusuyla paylaşılan uygulama kaydı (çok kiracılı)

Bu yaklaşımda, yönetim Microsoft Entra kiracısında bir uygulama kaydı oluşturulur. Yönetmek istediğiniz her Microsoft Entra kiracısında, uygulama kaydına bağlı olarak bu kiracıda bir hizmet asıl adı (SPN) oluşturulur. Bu eylem, işlem hattı görevlerini ve adımlarını çalıştıran çalışanların tek bir kimlik bilgileri kümesiyle Microsoft Entra kiracılarından herhangi birinde oturum açmasına olanak tanır.

Bahşiş

Uygulama kayıtları ve kurumsal uygulamalar (hizmet ilkeleri) arasındaki ilişki hakkında bilgi için bkz . Microsoft Entra Id'de uygulama ve hizmet sorumlusu nesneleri.

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed using the shared application registration (multi-tenant) with multiple service principals automation approach.

Önemli

Bu yaklaşımda, tek uygulama kaydı ve ilişkili kurumsal uygulamalar (hizmet sorumluları), yüksek ayrıcalıklı bir hesap olduğundan güvenlik bilgileri ve olay yönetimi (SIEM) araçlarınızdaki anormal etkinlikler için izlenmelidir. Uyarı göndermeli ve uyarı önem derecesine bağlı olarak otomatik olarak işlem gerçekleştirmelidir.

Önceki örnekte, tek bir uygulama kaydı Microsoft Entra kiracısındadır contoso.onmicrosoft.com ve bir kurumsal uygulama, uygulama kaydına bağlı Microsoft Entra kiracılarının her birinde yer alır. Bu kurulum, bir işlem hattının tek uygulama kaydını kullanarak tüm Microsoft Entra kiracılarının kimliğini doğrulamasını ve yetkilendirmesini sağlar. Daha fazla bilgi için bkz . Uygulamanızı çok kiracılı hale getirme.

Merkezi bir işlem hattı kullandığınızda, Microsoft Entra kiracılarıyla ortam, ilişkili abonelikler, kuruluş adı ve kimlik nesnesi kimliği gibi diğer meta verilerle ilişkili verileri içeren küçük bir eşleme tablosu oluşturmanız gerekebilir. Bu veriler, hangi Microsoft Entra kiracısına dağıtıldığını ve hangi kimliklerle dağıtıldığını denetlemek için bazı mantık ve koşullar kullanan bir adımda işlem hattının çalıştırılması sırasında çağrılabilir. Veriler Azure Cosmos DB veya Azure Tablo depolama gibi hizmetlerde depolanabilir.

Geliştirme, test veya üretim gibi birden çok ortamı işlediğinizde, bunlar işlem hatları ile aynı veya ayrı uygulama kayıtları ve kurumsal uygulamalar kullanılarak aynı şekilde denetlenebilir.

Her Microsoft Entra kiracısı için ayrı işlem hatları kullanmaya veya tek bir işlem hattı kullanmaya karar vekleyebilirsiniz. Tercih, gereksinimlerinize göre sizindir.

Dekont

Azure Lighthouse bu yaklaşıma benzer şekilde çalışır, ancak Azure Lighthouse RBAC sahibinin, kullanıcı erişim yöneticisinin ve DataActions izinlerine sahip rollerin atanmasına izin vermez. Daha fazla bilgi için bkz . Azure Lighthouse için rol desteği.

Sahip ve kullanıcı erişim rolleri genellikle tüm Azure giriş bölgesi dağıtım senaryolarında gereklidir. Bu gereksinim, Azure giriş bölgelerinin platform otomasyonu dağıtım yönünün tamamı için bir seçenek olarak Azure Lighthouse'ı kaldırır, ancak bazı senaryolarda hala yararlıdır. Daha fazla bilgi için bkz . ALZ çok kiracılı azure lighthouse kullanımı.

Platform yöneticileri ve geliştiriciler için kimlikler - Yaklaşım 2

Bu yaklaşımda platform yöneticilerinin ve geliştiricilerin genellikle yalnızca yöneten Microsoft Entra kiracısına erişmesi gerekir. Bu erişim, gitHub veya Azure DevOps gibi tüm kiracıların dağıtılıp çalıştırılacağı geliştirici araçlarına erişim verir.

Microsoft Entra B2B veya Azure Lighthouse aracılığıyla diğer Microsoft Entra kiracılarına erişebilirler. Yönetim kiracısından aynı hesapları kullanırlar veya ilk yaklaşımdaki örnekte olduğu gibi ayrı hesapları olabilir.

Sonraki adımlar