Azure kaynak yönetimiyle ilgili temel bilgiler

Azure kaynaklarına özgü yapıyı ve terimleri anlamak önemlidir. Aşağıdaki görüntüde Azure tarafından sağlanan dört kapsam düzeyi örneği gösterilmektedir:

Terminoloji

Tanımanız gereken terimlerden bazıları şunlardır:

Kaynak: Azure ile kullanılabilen yönetilebilir bir öğedir. Sanal makineler, depolama hesapları, web uygulamaları, veritabanları ve sanal ağlar kaynaklara örnek olarak verilebilir.

Kaynak grubu - Belirli ekipler tarafından yönetim gerektiren sanal makine koleksiyonu, ilişkili sanal ağlar ve yük dengeleyiciler gibi bir Azure çözümü için ilgili kaynakları barındıran kapsayıcı. Kaynak grubu, grup olarak yönetmek istediğiniz kaynakları içerir. Kuruluşunuz açısından en mantıklı duruma göre hangi kaynakların bir kaynak grubuna ait olduğuna siz karar verirsiniz. Kaynak grupları, aynı yaşam süresine sahip tüm kaynakları bir kerede silerek yaşam döngüsü yönetimine yardımcı olmak için de kullanılabilir. Bu yaklaşım, kötüye kullanılabilecek parçalar bırakmayarak da güvenlik avantajı sağlar.

Abonelik - Kuruluş hiyerarşisi açısından bakıldığında abonelik, kaynakların ve kaynak gruplarının faturalama ve yönetim kapsayıcısıdır. Azure aboneliğinin Microsoft Entra ID ile güven ilişkisi vardır. Abonelik Microsoft Entra ID'nin kullanıcıların, hizmetlerin ve cihazların kimliğini doğrulamasına güvenir.

Not

Abonelik yalnızca bir Microsoft Entra kiracısı güvenebilir. Ancak, her kiracı birden çok aboneliğe güvenebilir ve abonelikler kiracılar arasında taşınabilir.

Yönetim grubu - Azure yönetim grupları , aboneliklerin üzerindeki farklı kapsamlarda ilke ve uyumluluk uygulamak için hiyerarşik bir yöntem sağlar. Kiracı kök yönetim grubunda (en yüksek kapsam) veya hiyerarşideki düşük düzeylerde olabilir. Abonelikleri "yönetim grupları" adlı kapsayıcılarla düzenler ve idare koşullarınızı bu yönetim gruplarına uygularsınız. Bir yönetim grubu içindeki aboneliklerin tümü otomatik olarak yönetim grubuna uygulanmış olan koşulları devralır. İlke tanımlarının bir yönetim grubuna veya aboneliğe uygulanabileceğini unutmayın.

Kaynak sağlayıcısı - Azure kaynaklarını sağlayan bir hizmettir. Örneğin, yaygın bir kaynak sağlayıcısı Microsoft'tır. İşlem, sanal makine kaynağını sağlar. Microsoft. Depolama başka bir yaygın kaynak sağlayıcısıdır.

Resource Manager şablonu - Bir kaynak grubuna, aboneliğe, kiracıya veya yönetim grubuna dağıtılacak bir veya daha fazla kaynağı tanımlayan bir JavaScript Nesne Gösterimi (JSON) dosyası. Şablon, kaynakları tutarlı ve sürekli olarak dağıtmak için kullanılabilir. Bkz. Şablon dağıtımına genel bakış. Ayrıca, JSON yerine Bicep dili kullanılabilir.

Azure Kaynak Yönetimi Modeli

Her Azure aboneliği, Azure Resource Manager tarafından kullanılan denetimlerle ilişkilendirilir. Resource Manager, Azure için dağıtım ve yönetim hizmetidir, kuruluşlar için kimlik yönetimi için Microsoft Entra Id ve bireyler için Microsoft Hesabı (MSA) ile güven ilişkisine sahiptir. Resource Manager, Azure aboneliğinizdeki kaynakları oluşturmanızı, güncelleştirmenizi ve silmenizi sağlayan bir yönetim katmanı sağlar. Dağıtımdan sonra kaynaklarınızın güvenliğini sağlamak ve düzenlemek için erişim denetimi, kilitler ve etiketler gibi yönetim özelliklerini kullanırsınız.

Not

ARM'den önce Azure Service Manager (ASM) veya "klasik" adlı başka bir dağıtım modeli vardı. Daha fazla bilgi edinmek için bkz . Azure Resource Manager ile klasik dağıtım karşılaştırması. ORTAMLARı ASM modeliyle yönetmek bu içeriğin kapsamı dışındadır.

Azure Resource Manager, PowerShell, Azure portalı veya kaynakları yönetmek için diğer istemciler tarafından kullanılan REST API'lerini barındıran ön uç hizmetidir. bir istemci belirli bir kaynağı yönetme isteğinde bulunursa, Resource Manager isteği tamamlamak için isteği kaynak sağlayıcısına proxy'ler. Örneğin, bir istemci sanal makine kaynağını yönetme isteğinde bulunursa Resource Manager isteği Microsoft'a proxy'ler. İşlem kaynağı sağlayıcısı. Resource Manager, istemcinin sanal makine kaynağını yönetmek için hem abonelik hem de kaynak grubu için bir tanımlayıcı belirtmesini gerektirir.

Resource Manager tarafından herhangi bir kaynak yönetimi isteği yürütülmeden önce bir denetim kümesi denetlenür.

• Geçerli kullanıcı denetimi - Kaynağı yönetmek isteyen kullanıcının yönetilen kaynağın aboneliğiyle ilişkilendirilmiş Microsoft Entra kiracısında bir hesabı olmalıdır.

• Kullanıcı izni denetimi - İzinler, rol tabanlı erişim denetimi (RBAC) kullanılarak kullanıcılara atanır. RBAC rolü, bir kullanıcının belirli bir kaynak üzerinde alabileceği izin kümesini belirtir. RBAC, Azure kaynaklarına kimlerin erişimi olduğunu, bu kaynaklarla neler yapabileceklerini ve hangi alanlara erişebileceklerini yönetmenize yardımcı olur.

• Azure ilkesi denetimi - Azure ilkeleri belirli bir kaynak için izin verilen veya açıkça reddedilen işlemleri belirtir. Örneğin, bir ilke kullanıcıların yalnızca belirli bir sanal makine türünü dağıtmasına izin verileceğini (veya izin verilmediğini) belirtebilir.

Aşağıdaki diyagramda, az önce açıkladığımız kaynak modeli özetlemektedir.

Azure Lighthouse - Azure Lighthouse , kiracılar arasında kaynak yönetimi sağlar. Kuruluşlar, abonelik veya kaynak grubu düzeyindeki rolleri başka bir kiracıdaki kimliklere devredebilir.

Azure Lighthouse ile temsilcili kaynak yönetimini etkinleştiren abonelikler, abonelikleri veya kaynak gruplarını yönetebilen kiracı kimliklerini ve kaynak kiracıdaki yerleşik RBAC rolü ile hizmet sağlayıcısı kiracısı kimlikleri arasında eşlemeyi gösteren özniteliklere sahiptir. Çalışma zamanında Azure Resource Manager, hizmet sağlayıcısı kiracısından gelen belirteçleri yetkilendirmek için bu öznitelikleri kullanır.

Azure Lighthouse'un kendisinin bir Azure kaynak sağlayıcısı olarak modellendiğini belirtmek gerekir. Bu, kiracı genelinde temsilci seçme özelliklerinin Azure İlkeleri aracılığıyla hedeflenebileceği anlamına gelir.

Microsoft 365 Lighthouse Microsoft 365 Lighthouse - , Yönetilen Hizmet Sağlayıcılarının (MSP' ler) Microsoft 365 İş Ekstra, Microsoft 365 E3 veya Windows 365 İş kullanan küçük ve orta ölçekli işletme (SMB) müşterileri için cihazları, verileri ve kullanıcıları büyük ölçekte güvenli hale getiren ve yönetmelerine yardımcı olan bir yönetici portalıdır.

Microsoft Entra Id ile Azure kaynak yönetimi

Artık Azure'daki kaynak yönetimi modelini daha iyi anladığınıza göre, Microsoft Entra Id'nin Azure kaynakları için kimlik ve erişim yönetimi sağlayabilen özelliklerinden bazılarını kısaca inceleyelim.

Faturalandırma

Faturalama, kaynak yönetimi için önemlidir çünkü bazı faturalama rolleri kaynaklarla etkileşim kurar veya kaynakları yönetebilir. Faturalama, Microsoft ile yaptığınız sözleşmenin türüne bağlı olarak farklı çalışır.

Azure Kurumsal Anlaşma s

Azure Kurumsal Anlaşma (Azure EA) müşterileri, Microsoft ile ticari sözleşmelerinin yürütülmesi üzerine Azure EA Portal'a eklenir. Eklemeden sonra, bir kimlik "kök" Kuruluş Yöneticisi faturalama rolüyle ilişkilendirilir. Portal bir yönetim işlevleri hiyerarşisi sağlar:

• Departmanlar, maliyetleri mantıksal gruplandırmalar halinde segmentlere ayırmanıza yardımcı olur ve departman düzeyinde bir bütçe veya kota ayarlamanıza olanak tanır.

• Hesaplar, departmanları daha fazla segmentlere ayırmak için kullanılır. Abonelikleri yönetmek ve raporlara erişmek için hesapları kullanabilirsiniz. EA portalı, Microsoft Hesaplarını (MSA) veya Microsoft Entra hesaplarını (portalda "İş veya Okul Hesapları" olarak tanımlanır) yetkileyebilir. EA portalında "Hesap Sahibi" rolüne sahip kimlikler Azure abonelikleri oluşturabilir.

Kurumsal faturalama ve Microsoft Entra kiracıları

Hesap Sahibi kurumsal anlaşma içinde bir Azure aboneliği oluşturduğunda, aboneliğin kimliği ve erişim yönetimi aşağıdaki gibi yapılandırılır:

• Azure aboneliği, Hesap Sahibi'nin aynı Microsoft Entra kiracısıyla ilişkilendirilir.

• Aboneliği oluşturan hesap sahibine Hizmet Yöneticisi ve Hesap Yöneticisi rolleri atanır. (Azure EA Portal, abonelikleri yönetmek için Azure Service Manager (ASM) veya "klasik" roller atar. Daha fazla bilgi edinmek için bkz . Azure Resource Manager ile klasik dağıtım karşılaştırması.)

Kurumsal anlaşma, Azure EA Portal'da "İş veya okul hesabı kiracılar arası" kimlik doğrulama türü ayarlanarak birden çok kiracıyı destekleyecek şekilde yapılandırılabilir. Yukarıdakiler göz önünde bulundurulduğunda, kuruluşlar aşağıdaki diyagramda gösterildiği gibi her kiracı için birden çok hesap ve her hesap için birden çok abonelik ayarlayabilir.

Yukarıda açıklanan varsayılan yapılandırmanın, oluşturdukları aboneliklerdeki kaynakları yönetmek için Azure EA Hesabı Sahibi ayrıcalıkları olduğunu unutmayın. Üretim iş yüklerini barındıran abonelikler için, oluşturulduktan hemen sonra aboneliğin hizmet yöneticisini değiştirerek faturalama ve kaynak yönetimini ayırmayı göz önünde bulundurun.

Hesap sahibinin aboneliğe hizmet yöneticisi erişimini yeniden kazanmasını önlemek ve daha fazla ayrıştırmak için, oluşturulduktan sonra aboneliğin kiracısı değiştirilebilir. Hesap sahibinin aboneliğin taşındığı Microsoft Entra kiracısında bir kullanıcı nesnesi yoksa, hizmet sahibi rolünü yeniden kazanamaz.

Daha fazla bilgi edinmek için Azure rolleri, Microsoft Entra rolleri ve klasik abonelik yöneticisi rolleri'ni ziyaret edin.

Microsoft Müşteri Sözleşmesi

Microsoft Müşteri Sözleşmesi (MCA) ile kaydolan müşterilerin kendi rolleri olan farklı bir faturalama yönetim sistemi vardır.

Microsoft Müşteri Sözleşmesi ödeme hesabı, faturaların ve ödeme yöntemlerinin yönetilmesine olanak sağlayan bir veya daha fazla faturalama profili içerir. Her faturalama profili, faturalama profilinin faturasındaki maliyetleri düzenlemek için bir veya daha fazla fatura bölümü içerir.

Microsoft Müşteri Sözleşmesi faturalama rolleri tek bir Microsoft Entra kiracısından gelir. Birden çok kiracıya abonelik sağlamak için aboneliklerin başlangıçta MCA ile aynı Microsoft Entra kiracısında oluşturulması ve ardından değiştirilmesi gerekir. Aşağıdaki diyagramda, Kurumsal BT üretim öncesi ortamı abonelikleri oluşturulduktan sonra ContosoSandbox kiracısına taşınmıştır.

Azure'da RBAC ve rol atamaları

Microsoft Entra Fundamentals bölümünde, Azure RBAC'nin Azure kaynaklarına ayrıntılı erişim yönetimi sağlayan yetkilendirme sistemi olduğunu ve birçok yerleşik rol içerdiğini öğrendiniz. Özel roller oluşturabilir ve farklı kapsamlarda roller atayabilirsiniz. İzinler, Azure kaynaklarına erişim isteyen nesnelere RBAC rolleri atanarak uygulanır.

Microsoft Entra rolleri, Azure rol tabanlı erişim denetimi gibi kavramlar üzerinde çalışır. Bu iki rol tabanlı erişim denetim sistemi arasındaki fark, Azure RBAC'nin sanal makineler veya depolama gibi Azure kaynaklarına erişimi denetlemek için Azure Kaynak Yönetimi'ni kullanması ve Microsoft Entra rollerinin Office 365 gibi Microsoft Entra kimliğine, uygulamalarına ve Microsoft hizmetleri erişimini denetlemesidir.

Onay iş akışı ve MFA gibi tam zamanında etkinleştirme ilkelerini etkinleştirmek için hem Microsoft Entra rolleri hem de Azure RBAC rolleri Microsoft Entra Privileged Identity Management ile tümleşir.

Azure'da ABAC ve rol atamaları

Öznitelik tabanlı erişim denetimi (ABAC), güvenlik sorumluları, kaynaklar ve ortamla ilişkili özniteliklere göre erişimi tanımlayan bir yetkilendirme sistemidir. ABAC ile, özniteliklere göre bir kaynağa güvenlik sorumlusu erişimi vekleyebilirsiniz. Azure ABAC, Azure için ABAC uygulamasını ifade eder.

Azure ABAC, belirli eylemler bağlamındaki öznitelikleri temel alan rol atama koşulları ekleyerek Azure RBAC üzerinde derleme yapar. Rol atama koşulu, daha ayrıntılı erişim denetimi sağlamak için isteğe bağlı olarak rol atamanıza ekleyebileceğiniz ek bir denetimdir. Bir koşul, rol tanımının ve rol atamasının bir parçası olarak verilen izinleri filtreler. Örneğin, bir nesnenin nesneyi okumak için belirli bir etikete sahip olmasını gerektiren bir koşul ekleyebilirsiniz. Koşulları kullanarak belirli kaynaklara erişimi açıkça reddedemezsiniz.

Koşullu Erişim

Microsoft Entra Koşullu Erişim , Azure yönetim uç noktalarına erişimi yönetmek için kullanılabilir. Koşullu Erişim ilkeleri, Aşağıdakiler gibi Azure kaynak yönetimi uç noktalarını korumak için Windows Azure Hizmet Yönetimi API'sine bulut uygulamasına uygulanabilir:

• Azure Resource Manager Sağlayıcısı (hizmetler)

• Azure Resource Manager API'leri

• Azure PowerShell

• Azure CLI

• Azure portal

Örneğin bir yönetici, kullanıcının Azure portalında yalnızca onaylı konumlardan oturum açmasına olanak tanıyan ve ayrıca çok faktörlü kimlik doğrulaması (MFA) veya karma bir Microsoft Entra etki alanına katılmış cihaz gerektiren bir Koşullu Erişim ilkesi yapılandırabilir.

Azure Yönetilen Kimlikleri

Bulut uygulamaları oluştururken yaygın olarak karşılaşılan bir zorluk, bulut hizmetlerinde kimlik doğrulaması yapmak için kodunuzda bulunan kimlik bilgilerinin yönetimidir. Kimlik bilgilerinin güvenlik altında tutulması önemli bir görevdir. İdeal olan kimlik bilgilerinin geliştirici iş istasyonlarında asla gösterilmemesi ve kaynak denetimine kaydedilmemesidir. Azure kaynakları için yönetilen kimlikler, Azure hizmetlerine Microsoft Entra Id'de otomatik olarak yönetilen bir kimlik sağlar. Kodunuzda herhangi bir kimlik bilgisi olmadan Microsoft Entra kimlik doğrulamasını destekleyen herhangi bir hizmette kimlik doğrulaması yapmak için kimliği kullanabilirsiniz.

İki tür yönetilen kimlik vardır:

• Sistem tarafından atanan yönetilen kimlik doğrudan bir Azure kaynağında etkinleştirilir. Kaynak etkinleştirildiğinde Azure, ilişkili aboneliğin güvenilen Microsoft Entra kiracısında kaynak için bir kimlik oluşturur. Kimlik oluşturulduktan sonra kimlik bilgileri kaynağa sağlanır. Sistem tarafından atanan kimliğin yaşam döngüsü doğrudan Azure kaynağına bağlıdır. Kaynak silinirse Azure, Microsoft Entra Id'de kimlik bilgilerini ve kimliği otomatik olarak temizler.

• Kullanıcı tarafından atanan yönetilen kimlik, tek başına bir Azure kaynağı olarak oluşturulur. Azure, Microsoft Entra kiracısında kaynağın ilişkilendirildiği abonelik tarafından güvenilen bir kimlik oluşturur. Kimlik oluşturulduktan sonra, kimlik bir veya daha fazla Azure kaynağına atanabilir. Kullanıcı tarafından atanan kimliğin yaşam döngüsü, atandığı Azure kaynaklarının yaşam döngüsünden ayrı olarak yönetilir.

Dahili olarak, yönetilen kimlikler yalnızca belirli Azure kaynakları tarafından kullanılmak üzere özel türde hizmet sorumlularıdır. Yönetilen kimlik silindiğinde, ilgili hizmet sorumlusu otomatik olarak kaldırılır. Graph API izinlerinin yetkilendirmesinin yalnızca PowerShell tarafından yapılabilmesine dikkat edin, bu nedenle Yönetilen Kimlik'in tüm özelliklerine Portal kullanıcı arabirimi aracılığıyla erişilemez.

Microsoft Entra Domain Services

Microsoft Entra Domain Services, eski protokolleri kullanarak Azure iş yükleri için kimlik doğrulamasını kolaylaştırmak için yönetilen bir etki alanı sağlar. Desteklenen sunucular şirket içi AD DS ormanından taşınır ve Microsoft Entra Domain Services tarafından yönetilen bir etki alanına katılır ve kimlik doğrulaması için eski protokolleri kullanmaya devam eder (örneğin, Kerberos kimlik doğrulaması).

Azure AD B2C dizinleri ve Azure

Azure AD B2C kiracısı, faturalama ve iletişim amacıyla bir Azure aboneliğine bağlanır. Azure AD B2C kiracıları, azure aboneliğinin Azure RBAC ayrıcalıklı rollerinden bağımsız olarak dizinde kendi kendine yer alan bir rol yapısına sahiptir.

Azure AD B2C kiracısı başlangıçta sağlandığında, B2C kiracısını oluşturan kullanıcının abonelikte katkıda bulunan veya sahip izinlerine sahip olması gerekir. Bu kullanıcı oluşturulduklarında ilk Azure AD B2C kiracısı Genel Yöneticisi olur ve daha sonra başka hesaplar oluşturup bunları dizin rollerine atayabilir.

Bağlantılı Microsoft Entra aboneliğinin sahipleri ve katkıda bulunanlarının abonelik ile dizin arasındaki bağlantıyı kaldırabileceğini ve bunun Azure AD B2C kullanımının devam eden faturalamasını etkileyeceğini unutmayın.

Azure'da IaaS çözümleri için kimlikle ilgili dikkat edilmesi gerekenler

Bu senaryo, kuruluşların Hizmet Olarak Altyapı (IaaS) iş yükleri için sahip olduğu kimlik yalıtımı gereksinimlerini kapsar.

IaaS iş yüklerinin yalıtım yönetimiyle ilgili üç temel seçenek vardır:

• Tek başına Active Directory Etki Alanı Hizmetleri'ne (AD DS) katılmış sanal makineler

• Microsoft Entra Domain Services'a katılmış sanal makineler

• Microsoft Entra kimlik doğrulamasını kullanarak Azure'da sanal makinelerde oturum açma

İlk iki seçenekle ele alınması gereken temel kavramlardan biri, bu senaryolara dahil olan iki kimlik bölgesi olmasıdır.

• Uzak masaüstü protokolü (RDP) aracılığıyla bir Azure Windows Server VM'sinde oturum açtığınızda, genellikle etki alanı kimlik bilgilerinizi kullanarak sunucuda oturum açarsınız ve bu da şirket içi AD DS etki alanı denetleyicisinde veya Microsoft Entra Etki Alanı Hizmetleri'nde Kerberos kimlik doğrulaması gerçekleştirir. Alternatif olarak, sunucu etki alanına katılmamışsa, sanal makinelerde oturum açmak için yerel bir hesap kullanılabilir.

• Vm oluşturmak veya yönetmek için Azure portalında oturum açtığınızda, Microsoft Entra ID (doğru hesapları eşitlediyseniz aynı kimlik bilgilerini kullanıyor olabilirsiniz) kimlik doğrulaması yapmış olursunuz ve bu, Active Directory Federasyon Hizmetleri (AD FS) (AD FS) veya PassThrough Kimlik Doğrulaması kullanıyor olmanız durumunda etki alanı denetleyicilerinizde kimlik doğrulaması yapılmasına neden olabilir.

Tek başına Active Directory Etki Alanı Hizmetlerine katılmış sanal makineler

AD DS, kuruluşların şirket içi kimlik hizmetleri için büyük ölçüde benimsediği Windows Server tabanlı dizin hizmetidir. AD DS, AD DS yöneticileri ve başka bir ormandaki kullanıcılardan kimlik yalıtımı gerektiren IaaS iş yüklerini Azure'a dağıtma gereksinimi olduğunda dağıtılabilir.

Bu senaryoda aşağıdaki önemli noktalara dikkat edilmesi gerekir:

AD DS etki alanı denetleyicileri: Kimlik doğrulama hizmetlerinin yüksek oranda kullanılabilir ve performanslı olduğundan emin olmak için en az iki AD DS etki alanı denetleyicisi dağıtılmalıdır. Daha fazla bilgi için bkz . AD DS Tasarım ve Planlama.

AD DS Tasarım ve Planlama - Aşağıdaki hizmetlerin doğru yapılandırıldığı yeni bir AD DS ormanı oluşturulmalıdır:

• AD DS Etki Alanı Adı Hizmetleri (DNS) - AD DS DNS, ad çözümlemesinin sunucular ve uygulamalar için doğru çalıştığından emin olmak için AD DS içindeki ilgili bölgeler için yapılandırılmalıdır.

• AD DS Siteleri ve Hizmetleri - Bu hizmetler, uygulamaların etki alanı denetleyicilerine düşük gecikme süresi ve yüksek performanslı erişime sahip olduğundan emin olmak için yapılandırılmalıdır. Sunucuların bulunduğu ilgili sanal ağlar, alt ağlar ve veri merkezi konumları sitelerde ve hizmetlerde yapılandırılmalıdır.

• AD DS FSMO'ları - Gerekli Esnek Tek Ana İşlem (FSMO) rolleri gözden geçirilmeli ve uygun AD DS etki alanı denetleyicilerine atanmalıdır.

• AD DS Etki Alanına Katılma - Kimlik doğrulaması, yapılandırma ve yönetim için AD DS gerektiren tüm sunucuların ("sıçrama kutuları hariç") yalıtılmış ormana katılması gerekir.

• AD DS Grup İlkesi (GPO) - AD DS GPO'ları, yapılandırmanın güvenlik gereksinimlerini karşıladığından ve yapılandırmanın orman ve etki alanına katılmış makinelerde standartlaştırıldığından emin olmak için yapılandırılmalıdır.

• AD DS Kuruluş Birimleri (OU) - AD DS kaynaklarının yönetim ve yapılandırma uygulama amacıyla mantıksal yönetim ve yapılandırma silolarına gruplanmasını sağlamak için AD DS OU'ları tanımlanmalıdır.

• Rol tabanlı erişim denetimi - RBAC, yönetim ve bu ormana katılmış kaynaklara erişim için tanımlanmalıdır. Buna aşağıdakiler dahildir:

  • AD DS Grupları - Ad DS kaynaklarına kullanıcılar için uygun izinleri uygulamak için gruplar oluşturulmalıdır.

  • Yönetim hesapları - Bu bölümün başında belirtildiği gibi, bu çözümü yönetmek için gereken iki yönetim hesabı vardır.

    • AD DS ve etki alanına katılmış sunucularda gerekli olan yönetimi gerçekleştirmek için gereken en az ayrıcalıklı erişime sahip bir AD DS yönetim hesabı.

    • Sanal makineleri, sanal ağları, ağ güvenlik gruplarını ve diğer gerekli Azure kaynaklarını bağlamak, yönetmek ve yapılandırmak için Azure portalı erişimi için bir Microsoft Entra yönetim hesabı.

  • AD DS kullanıcı hesapları - Bu çözüm tarafından barındırılan uygulamalara kullanıcı erişimine izin vermek için ilgili kullanıcı hesaplarının sağlanması ve doğru gruplara eklenmesi gerekir.

Sanal ağlar (VNet) - Yapılandırma kılavuzu

• AD DS etki alanı denetleyicisi IP adresi - Etki alanı denetleyicileri işletim sistemi içindeki statik IP adresleriyle yapılandırılmamalıdır. IP adresleri, her zaman aynı kalmalarını ve DC'nin DHCP kullanacak şekilde yapılandırılmasını sağlamak için Azure sanal ağından ayrılmalıdır.

• Sanal Ağ DNS Sunucusu - DNS sunucuları, etki alanı denetleyicilerine işaret etmek için bu yalıtılmış çözümün parçası olan sanal ağlarda yapılandırılmalıdır. Bu, uygulamaların ve sunucuların gerekli AD DS hizmetlerini veya AD DS ormanına katılmış diğer hizmetleri çözümleyebilmesini sağlamak için gereklidir.

• Ağ güvenlik grupları (NSG) - Etki alanı denetleyicileri, yalnızca gerekli sunuculardan (etki alanına katılmış makineler veya sıçrama kutuları) etki alanı denetleyicilerine erişime izin vermek için tanımlanmış NSG'lere sahip kendi sanal ağlarında veya alt ağlarında bulunmalıdır. NSG oluşturmayı ve yönetimini basitleştirmek için sıçrama kutuları bir uygulama güvenlik grubuna (ASG) eklenmelidir.

Zorluklar: Aşağıdaki listede kimlik yalıtımı için bu seçeneğin kullanılmasıyla ilgili önemli zorluklar vurgulanır:

• Yönetim, yönetme ve izleme için ek bir AD DS Ormanı, BT ekibinin daha fazla çalışma yapmasını sağlar.

• Düzeltme eki uygulama ve yazılım dağıtımlarının yönetimi için daha fazla altyapı gerekebilir. Kuruluşlar bu sunucuları yönetmek için Azure Update Management, Grup İlkesi (GPO) veya System Center Configuration Manager (SCCM) dağıtmayı düşünmelidir.

• Kullanıcıların hatırlaması ve kaynaklara erişmek için kullanması için ek kimlik bilgileri.

Önemli

Bu yalıtılmış model için, müşterinin şirket ağından etki alanı denetleyicilerine veya etki alanı denetleyicilerinden bağlantı olmadığı ve diğer ormanlarla yapılandırılmış güven olmadığı varsayılır. AD DS etki alanı denetleyicilerinin yönetilebileceği ve yönetilebileceği bir noktaya izin vermek için bir sıçrama kutusu veya yönetim sunucusu oluşturulmalıdır.

Microsoft Entra Domain Services'a katılmış sanal makineler

Ad DS yöneticilerinden ve başka bir ormandaki kullanıcılardan kimlik yalıtımı gerektiren IaaS iş yüklerini Azure'a dağıtma gereksinimi varsa, Microsoft Entra Domain Services yönetilen etki alanı dağıtılabilir. Microsoft Entra Domain Services, eski protokolleri kullanarak Azure iş yükleri için kimlik doğrulamasını kolaylaştırmak için yönetilen bir etki alanı sağlayan bir hizmettir. Bu, kendi AD DS'nizi oluşturma ve yönetme teknik karmaşıklıkları olmadan yalıtılmış bir etki alanı sağlar. Aşağıdaki konulara dikkat edilmesi gerekir.

Microsoft Entra Domain Services yönetilen etki alanı - Microsoft Entra kiracısı başına yalnızca bir Microsoft Entra Domain Services yönetilen etki alanı dağıtılabilir ve bu tek bir sanal ağa bağlıdır. Bu sanal ağın Microsoft Entra Domain Services kimlik doğrulaması için "hub" oluşturması önerilir. Bu merkezden sunucular ve uygulamalar için eski kimlik doğrulamasına izin vermek için "uçlar" oluşturulabilir ve bağlanabilir. Uçlar, Microsoft Entra Domain Services'a katılmış sunucuların bulunduğu ek sanal ağlardır ve Azure ağ geçitleri veya sanal ağ eşlemesi kullanılarak hub'a bağlanır.

Yönetilen etki alanı konumu - Microsoft Entra Domain Services yönetilen etki alanı dağıtılırken bir konum ayarlanmalıdır. Konum, yönetilen etki alanının dağıtıldığı fiziksel bir bölgedir (veri merkezi). Aşağıdakiler önerilir:

• Microsoft Entra Domain Services hizmetlerini gerektiren sunuculara ve uygulamalara coğrafi olarak kapalı bir konum düşünün.

• Yüksek kullanılabilirlik gereksinimleri için Kullanılabilirlik Alanları özellikleri sağlayan bölgeleri göz önünde bulundurun. Daha fazla bilgi için bkz. Azure'da bölgeler ve Kullanılabilirlik Alanları.

Nesne sağlama - Microsoft Entra Domain Services, Microsoft Entra Domain Services'ın dağıtılacağı abonelikle ilişkili Microsoft Entra Kimliği'nden kimlikleri eşitler. Ayrıca, ilişkili Microsoft Entra Id'de Microsoft Entra Connect (kullanıcı ormanı senaryosu) ile eşitleme ayarlandıysa, bu kimliklerin yaşam döngüsünün Microsoft Entra Domain Services'a da yansıtılabildiğini unutmayın. Bu hizmet, Microsoft Entra Id'den kullanıcı ve grup nesneleri sağlamak için kullanılabilecek iki moda sahiptir.

• Tümü: Tüm kullanıcılar ve gruplar Microsoft Entra Id'den Microsoft Entra Domain Services'a eşitlenir.

• Kapsamlı: Yalnızca bir grup kapsamındaki kullanıcılar Microsoft Entra Id'den Microsoft Entra Domain Services ile eşitlenir.

Microsoft Entra Domain Services'ı ilk kez dağıttığınızda, nesneleri Microsoft Entra Id'den çoğaltmak için otomatik bir tek yönlü eşitleme yapılandırılır. Bu tek yönlü eşitleme, Microsoft Entra Domain Services tarafından yönetilen etki alanını Microsoft Entra Id'deki değişikliklerle güncel tutmak için arka planda çalışmaya devam eder. Microsoft Entra Domain Services'dan Microsoft Entra Kimliği'ne geri eşitleme gerçekleşmez. Daha fazla bilgi için bkz . Microsoft Entra Domain Services yönetilen etki alanında nesneler ve kimlik bilgileri nasıl eşitlenir?

Eşitleme türünü Tümü yerine Kapsamlı (veya tam tersi) olarak değiştirmeniz gerekiyorsa Microsoft Entra Domain Services yönetilen etki alanının silinmesi, yeniden oluşturulması ve yapılandırılması gerektiğini unutmayın. Ayrıca kuruluşlar, kimlikleri yalnızca Microsoft Entra Domain Services kaynaklarına erişmesi gerekenlere indirgemek için "kapsamlı" sağlama kullanımını iyi bir uygulama olarak düşünmelidir.

Grup İlkesi Nesneleri (GPO) - Microsoft Entra Domain Services yönetilen etki alanında GPO yapılandırmak için, Microsoft Entra Domain Services yönetilen etki alanına katılmış bir sunucuda Grup İlkesi Yönetimi araçlarını kullanmanız gerekir. Daha fazla bilgi için bkz . Microsoft Entra Domain Services yönetilen etki alanında Grup İlkesini Yönetme.

Güvenli LDAP - Microsoft Entra Domain Services, bunu gerektiren uygulamalar tarafından kullanılabilecek güvenli bir LDAP hizmeti sağlar. Bu ayar varsayılan olarak devre dışıdır ve güvenli LDAP'yi etkinleştirmek için bir sertifikanın karşıya yüklenmesi gerekir. Buna ek olarak, Microsoft Entra Domain Services'ın dağıtılacağı sanal ağın güvenliğini sağlayan NSG'nin Microsoft Entra Domain Services yönetilen etki alanlarına 636 numaralı bağlantı noktası bağlantısına izin vermesi gerekir. Daha fazla bilgi için bkz . Microsoft Entra Domain Services yönetilen etki alanı için güvenli LDAP yapılandırma.

Yönetim - Microsoft Entra Domain Services'da yönetim görevlerini gerçekleştirmek için (örneğin, etki alanına katılma makineleri veya GPO'ları düzenleme), bu görev için kullanılan hesabın Microsoft Entra DC Administrators grubunun bir parçası olması gerekir. Bu grubun üyesi olan hesaplar, yönetim görevlerini gerçekleştirmek için etki alanı denetleyicilerinde doğrudan oturum açamaz. Bunun yerine, Microsoft Entra Domain Services yönetilen etki alanına katılmış bir yönetim VM'sini oluşturur ve ardından normal AD DS yönetim araçlarınızı yüklersiniz. Daha fazla bilgi için bkz . Microsoft Entra Domain Services'da kullanıcı hesapları, parolalar ve yönetim için yönetim kavramları.

Parola karmaları - Microsoft Entra Domain Services ile kimlik doğrulamasının çalışması için tüm kullanıcıların parola karmalarının NT LAN Manager (NTLM) ve Kerberos kimlik doğrulaması için uygun bir biçimde olması gerekir. Microsoft Entra Domain Services ile kimlik doğrulamasının beklendiği gibi çalıştığından emin olmak için aşağıdaki önkoşulların gerçekleştirilmesi gerekir.

• Microsoft Entra Connect ile eşitlenen kullanıcılar (AD DS'den) - Eski parola karmalarının şirket içi AD DS'den Microsoft Entra Id'ye eşitlenmesi gerekir.

• Microsoft Entra Id ile oluşturulan kullanıcılar - Microsoft Entra Domain Services ile kullanım için oluşturulacak doğru karmalar için parolalarını sıfırlamaları gerekir. Daha fazla bilgi için bkz . Parola karmalarının eşitlenmesini etkinleştirme.

Ağ - Microsoft Entra Domain Services bir Azure sanal ağına dağıtıldığından sunucuların ve uygulamaların güvenliğinin sağlandığından ve yönetilen etki alanına doğru şekilde erişebildiğinden emin olmak için dikkat edilmesi gereken noktalara dikkat edilmesi gerekir. Daha fazla bilgi için bkz. Microsoft Entra Domain Services için sanal ağ tasarımında dikkat edilmesi gerekenler ve yapılandırma seçenekleri.

• Microsoft Entra Domain Services kendi alt aya dağıtılmalıdır: Mevcut bir alt ağı veya ağ geçidi alt alığını kullanmayın.

• Bir ağ güvenlik grubu (NSG) - Microsoft Entra Domain Services yönetilen etki alanının dağıtımı sırasında oluşturulur. Bu ağ güvenlik grubu, doğru hizmet iletişimi için gerekli kuralları içerir. Kendi özel kurallarınızla mevcut bir ağ güvenlik grubu oluşturmayın veya kullanmayın.

• Microsoft Entra Domain Services için 3-5 IP adresi gerekir- Alt ağ IP adresi aralığınızın bu sayıda adres sağlayabildiğinden emin olun. Kullanılabilir IP adreslerinin kısıtlanması, Microsoft Entra Domain Services'ın iki etki alanı denetleyicisini korumasını engelleyebilir.

• Sanal Ağ DNS Sunucusu - Daha önce "merkez-uç" modeli hakkında açıklandığı gibi, Microsoft Entra Domain Services yönetilen etki alanına katılmış sunucuların Microsoft Entra Domain Services yönetilen etki alanını çözümlemek için doğru DNS ayarlarına sahip olduğundan emin olmak için SANAL ağlarda DNS'nin doğru yapılandırılması önemlidir. Her sanal ağın bir IP adresi edindikçe sunuculara geçirilen bir DNS sunucusu girdisi vardır ve bu DNS girdilerinin Microsoft Entra Domain Services yönetilen etki alanının IP adresleri olması gerekir. Daha fazla bilgi için bkz . Azure sanal ağı için DNS ayarlarını güncelleştirme.

Zorluklar - Aşağıdaki listede Kimlik Yalıtımı için bu seçeneğin kullanılmasıyla ilgili önemli zorluklar vurgulanır.

• Bazı Microsoft Entra Domain Services yapılandırması yalnızca Microsoft Entra Domain Services'a katılmış bir sunucudan yönetilebilir.

• Microsoft Entra kiracısı başına yalnızca bir Microsoft Entra Domain Services yönetilen etki alanı dağıtılabilir. Bu bölümde açıklandığı gibi merkez-uç modelinin diğer sanal ağlardaki hizmetlere Microsoft Entra Domain Services kimlik doğrulaması sağlaması önerilir.

• Düzeltme eki uygulama ve yazılım dağıtımlarının yönetimi için daha fazla altyapı gerekebilir. Kuruluşlar bu sunucuları yönetmek için Azure Update Management, Grup İlkesi (GPO) veya System Center Configuration Manager (SCCM) dağıtmayı düşünmelidir.

Bu yalıtılmış modelde, müşterinin şirket ağından Microsoft Entra Domain Services yönetilen etki alanını barındıran sanal ağa bağlantı olmadığı ve diğer ormanlarla yapılandırılmış güven olmadığı varsayılır. Microsoft Entra Domain Services'ın yönetilebileceği ve yönetilebileceği bir noktaya izin vermek için bir sıçrama kutusu veya yönetim sunucusu oluşturulmalıdır.

Microsoft Entra kimlik doğrulamasını kullanarak Azure'da sanal makinelerde oturum açma

Kimlik yalıtımı gerektiren IaaS iş yüklerini Azure'a dağıtma gereksinimi varsa, son seçenek bu senaryoda sunucularda oturum açmak için Microsoft Entra Id kullanmaktır. Bu, Microsoft Entra Id'yi kimlik doğrulaması amacıyla kimlik bölgesi yapma olanağı sağlar ve sunucuları gerekli Microsoft Entra kiracısına bağlı olan ilgili aboneliğe sağlayarak kimlik yalıtımı elde edilebilir. Aşağıdaki konulara dikkat edilmesi gerekir.

Desteklenen işletim sistemleri: Microsoft Entra kimlik doğrulamasını kullanarak Azure'da sanal makinelerde oturum açma şu anda Windows ve Linux'ta desteklenmektedir. Desteklenen işletim sistemleri hakkında daha fazla bilgi için Windows ve Linux belgelerine bakın.

Kimlik bilgileri: Microsoft Entra kimlik doğrulamasını kullanarak Azure'da sanal makinelerde oturum açmanın temel avantajlarından biri, sanal makinede oturum açmak üzere Microsoft Entra hizmetlerine erişmek için normalde kullandığınız federasyon veya yönetilen Microsoft Entra kimlik bilgilerini kullanabilmektir.

Not

Bu senaryoda oturum açmak için kullanılan Microsoft Entra kiracısı, sanal makinenin sağlandığı abonelikle ilişkili Microsoft Entra kiracısıdır. Bu Microsoft Entra kiracısı, şirket içi AD DS'den eşitlenmiş kimliklere sahip bir kiracı olabilir. Kuruluşlar, bu sunucularda oturum açmak için hangi aboneliği ve Microsoft Entra kiracısını kullanmak istediklerini seçerken yalıtım sorumlularıyla uyumlu, bilinçli bir seçim yapmalıdır.

Ağ Gereksinimleri: Bu sanal makinelerin kimlik doğrulaması için Microsoft Entra Id'ye erişmesi gerekir, bu nedenle sanal makinelerin ağ yapılandırmasının 443'te Microsoft Entra uç noktalarına giden erişime izin vermesinden emin olmanız gerekir. Daha fazla bilgi için Windows ve Linux belgelerine bakın.

Rol Tabanlı Erişim Denetimi (RBAC): Bu sanal makinelere uygun erişim düzeyini sağlamak için iki RBAC rolü kullanılabilir. Bu RBAC rolleri Azure portalı veya Azure Cloud Shell Deneyimi aracılığıyla yapılandırılabilir. Daha fazla bilgi için bkz . VM için rol atamalarını yapılandırma.

• Sanal makine yöneticisi oturum açma: Bu role sahip kullanıcılar yönetici ayrıcalıklarıyla bir Azure sanal makinesinde oturum açabilir.

• Sanal makine kullanıcı oturumu açma: Bu role atanmış kullanıcılar, normal kullanıcı ayrıcalıklarıyla bir Azure sanal makinesinde oturum açabilir.

Koşullu Erişim: Azure sanal makinelerinde oturum açmak için Microsoft Entra ID kullanmanın önemli avantajlarından biri, oturum açma işleminin bir parçası olarak Koşullu Erişim'i zorunlu kılma özelliğidir. Bu, kuruluşların sanal makineye erişime izin vermeden önce koşulların karşılanmasını gerektirebilmesini ve güçlü kimlik doğrulaması sağlamak için çok faktörlü kimlik doğrulamasını kullanmasını sağlar. Daha fazla bilgi için bkz . Koşullu Erişimi Kullanma.

Not

Microsoft Entra Id'ye katılmış sanal makinelere uzak bağlantıya yalnızca Microsoft Entra'ya katılmış veya Microsoft Entra karmasının sanal makineyle aynı dizine katılmış olan Windows 10, Windows 11 ve Cloud PC bilgisayarlarından izin verilir.

Zorluklar: Aşağıdaki listede kimlik yalıtımı için bu seçeneğin kullanılmasıyla ilgili önemli zorluklar vurgulanır.

• Sunucuların merkezi yönetimi veya yapılandırması yoktur. Örneğin, bir sunucu grubuna uygulanabilecek bir Grup İlkesi yoktur. Kuruluşlar, bu sunucuların düzeltme eki uygulama ve güncelleştirmelerini yönetmek için Azure'da Güncelleştirme Yönetimi dağıtmayı düşünmelidir.

• Bu sunucular veya hizmetler arasında Windows Tümleşik Kimlik Doğrulaması gibi şirket içi mekanizmalarla kimlik doğrulaması yapma gereksinimleri olan çok katmanlı uygulamalar için uygun değildir. Kuruluş için bu bir gereksinimse, Tek Başına Active Directory Etki Alanı Hizmetleri'ni veya bu bölümde açıklanan Microsoft Entra Domain Services senaryolarını incelemeniz önerilir.

Bu yalıtılmış modelde, müşterinin şirket ağından sanal makineleri barındıran sanal ağa bağlantı olmadığı varsayılır. Bu sunucuların yönetilebileceği ve yönetilebileceği bir noktaya izin vermek için bir sıçrama kutusu veya yönetim sunucusu oluşturulmalıdır.

Sonraki adımlar

• Temsilcili yönetim ve yalıtılmış ortamlara giriş

• Microsoft Entra ile ilgili temel bilgiler

• Tek bir kiracıda kaynak yalıtımı

• Birden çok kiracı ile kaynak yalıtımı

• En iyi uygulamalar