Aracılığıyla paylaş


Azure yönetim grupları nedir?

Kuruluşunuzun birçok Azure aboneliği varsa, bu abonelikler için erişimi, ilkeleri ve uyumluluğu verimli bir şekilde yönetmek için bir yönteme ihtiyacınız olabilir. Yönetim grupları aboneliklerin üzerinde bir idare kapsamı sağlar. Abonelikleri yönetim grupları halinde düzenlerken, uyguladığınız idare koşulları ilişkili tüm aboneliklere devralma yoluyla art arda gelir.

Yönetim grupları, sahip olabileceğiniz abonelik türleri ne olursa olsun kurumsal düzeyde yönetim sağlar. Ancak, tek bir yönetim grubundaki tüm aboneliklerin aynı Microsoft Entra kiracıya güvenmesi gerekir.

Örneğin, sanal makine (VM) oluşturma için kullanılabilir bölgeleri sınırlayan bir yönetim grubuna ilke uygulayabilirsiniz. Bu ilke, yalnızca yetkili bölgelerde VM oluşturulmasına izin vermek için tüm iç içe yönetim gruplarına, aboneliklere ve kaynaklara uygulanır.

Yönetim grupları ve abonelikler hiyerarşisi

Birleşik ilke ve erişim yönetimi için kaynaklarınızı bir hiyerarşi altında düzenlemek amacıyla yönetim grupları ve aboneliklerden oluşan esnek bir yapı inşa edebilirsiniz. Aşağıdaki diyagramda yönetim grupları kullanılarak idare hiyerarşisi oluşturma örneği gösterilir.

Örnek yönetim grubu hiyerarşisinin diyagramı.

Hem yönetim gruplarını hem de abonelikleri barındıran bir kök yönetim grubunun diyagramı. Bazı alt yönetim grupları yönetim gruplarını, bazıları abonelikleri tutarken bazıları her ikisini de barındırabilir. Örnek hiyerarşisindeki örneklerden biri, tüm aboneliklerin alt düzeyde olduğu dört yönetim grubu düzeyidir.

Örneğin, ŞIRKET adlı yönetim grubunda VM konumlarını Batı ABD bölgesiyle sınırlayan bir ilke uygulayan bir hiyerarşi oluşturabilirsiniz. Bu ilke, söz konusu yönetim grubunun alt öğesi olan tüm Kurumsal Anlaşma (EA) aboneliklerini devralır ve bu abonelikler altındaki tüm VM'lere uygulanır. Kaynak veya abonelik sahibi, daha iyi idare sağlamak için bu güvenlik ilkesini değiştiremez.

Not

Yönetim grupları şu anda Microsoft Müşteri Sözleşmesi (MCA) abonelikleri için maliyet yönetimi özelliklerinde desteklenmemektedir.

Yönetim gruplarını kullanacağınız başka bir senaryo ise birden fazla aboneliğe kullanıcı erişimi sağlamaktır. Birden çok aboneliği bir yönetim grubu altına taşıyarak, yönetim grubunda bir Azure rol ataması oluşturabilirsiniz. Rol, bu erişimi tüm aboneliklere devralır. Yönetim grubundaki bir atama, kullanıcıların farklı abonelikler üzerinde Azure rol tabanlı erişim denetimi (RBAC) betiği uygulamak yerine ihtiyaç duydukları her şeye erişmesini sağlayabilir.

Yönetim gruplarıyla ilgili önemli olgular

  • Tek bir dizin 10.000 yönetim grubunu destekleyebilir.

  • Bir yönetim grubu en fazla altı derinlik düzeyini destekleyebilir.

    Bu sınır, kök düzeyi veya abonelik düzeyini içermez.

  • Her yönetim grubu ve abonelik tek bir üst öğeyi destekleyebilir.

  • Her yönetim grubunun birçok alt öğesi olabilir.

  • Tüm abonelikler ve yönetim grupları, her bir dizindeki tek bir hiyerarşi içinde yer alır. Daha fazla bilgi için bu makalenin devamında yer alan Kök yönetim grubu hakkında önemli bilgiler bölümüne bakın.

Her dizin için kök yönetim grubu

Her dizinin kök yönetim grubu adlı tek bir üst düzey yönetim grubu vardır. Kök yönetim grubu, tüm yönetim gruplarının ve aboneliklerin buna katlanmış olması için hiyerarşide yerleşiktir.

Kök yönetim grubu, genel ilkelerin ve Azure rol atamalarının dizin düzeyinde uygulanmasına olanak tanır. Başlangıçta, Microsoft Entra Genel Yöneticisinin kendisini bu kök grubun Kullanıcı Erişim Yöneticisi rolüne yükseltmesi gerekir. Yönetici, erişimi yükseltdikten sonra hiyerarşiyi yönetmek için diğer dizin kullanıcılarına veya gruplarına herhangi bir Azure rolü atayabilir. Yönetici olarak hesabınızı kök yönetim grubunun sahibi olarak atayabilirsiniz.

Kök yönetim grubu hakkında önemli bilgiler

  • Varsayılan olarak, kök yönetim grubunun görünen adı Kiracı kök grubudur ve kendisini bir yönetim grubu olarak çalıştırır. Kimlik, Microsoft Entra kiracı kimliğiyle aynı değerdir.
  • Görünen adı değiştirmek için hesabınızın kök yönetim grubunda Sahip veya Katkıda Bulunan rolü olmalıdır. Daha fazla bilgi için bkz . Yönetim grubunun adını değiştirme.
  • Diğer yönetim gruplarının aksine kök yönetim grubu taşınamaz veya silinemez.
  • Tüm abonelikler ve yönetim grupları dizindeki tek bir kök yönetim grubuna katlanır.
    • Dizindeki tüm kaynaklar, genel yönetim için kök yönetim grubu altında birleşir.
    • Yeni abonelikler, oluşturulduklarında otomatik olarak kök yönetim grubuna varsayılan olarak eklenir.
  • Tüm Azure müşterileri kök yönetim grubunu görebilir ancak tüm müşteriler o kök yönetim grubunu yönetmek için erişime sahip değildir.
    • Bir aboneliğe erişimi olan herkes bu aboneliğin hiyerarşide bulunduğu bağlamı görebilir.
    • Kök yönetim grubuna kimsenin varsayılan erişimi yoktur. Microsoft Entra Genel Yöneticileri, erişim kazanmak için kendilerini yükseltebilen tek kullanıcılardır. Kök yönetim grubuna erişim elde ettikten sonra, grubu yönetmek için diğer kullanıcılara herhangi bir Azure rolü atayabilirler.

Önemli

Kök yönetim grubundaki kullanıcı erişimi veya ilke atamaları, dizindeki tüm kaynaklar için geçerlidir. Bu erişim düzeyi nedeniyle tüm müşterilerin bu kapsamda tanımlanmış öğelere sahip olması gerektiğini değerlendirmesi gerekir. Kullanıcı erişimi ve ilke atamaları yalnızca bu kapsamda "olmalıdır" olmalıdır.

Yönetim gruplarının ilk ayarı

Herhangi bir kullanıcı yönetim gruplarını kullanmaya başladığında, ilk kurulum işlemi gerçekleşir. İlk adım, dizinde kök yönetim grubunun oluşturulmasıdır. Ardından dizinde bulunan tüm mevcut abonelikler kök yönetim grubunun alt öğeleri olur.

Bu işlemin yapılmasının nedeni, bir dizin içinde yalnızca bir yönetim grubu hiyerarşisi olmasını sağlamaktır. Dizin içinde tek hiyerarşi olması, yönetim müşterilerinin dizindeki diğer müşteriler tarafından atlanamayacak genel erişim ve ilkeler uygulamasına olanak tanır.

Kökte atanan her şey hiyerarşinin tamamı için geçerlidir. Diğer bir ifadeyle, söz konusu Microsoft Entra kiracısı içindeki tüm yönetim grupları, abonelikler, kaynak grupları ve kaynaklar için geçerlidir.

Yönetim grubu erişimi

Azure yönetim grupları, tüm kaynak erişimi ve rol tanımları için Azure RBAC'i destekler. Hiyerarşide var olan alt kaynaklar bu izinleri devralır. Herhangi bir Azure rolü, hiyerarşiyi kaynaklara devralacak bir yönetim grubuna atanabilir.

Örneğin, Azure rolü VM Katkıda Bulunanı'nı bir yönetim grubuna atayabilirsiniz. Bu rolün yönetim grubunda hiçbir eylemi yoktur, ancak bu yönetim grubu altındaki tüm VM'lere devralınır.

Aşağıdaki grafikte rollerin listesi ve yönetim gruplarında desteklenen eylemler gösterilmektedir.

Azure rol adı Oluşturma Yeniden Adlandır Taşı** Sil Erişim atama İlke ata Okundu
Sahip X X X X X X X
Katılımcı X X X X X
Yönetim Grubu Katkıda Bulunanı* X X X X X
Okuyucu X
Yönetim Grubu Okuyucusu* X
Kaynak İlkesine Katkıda Bulunan X
Kullanıcı Erişimi Yöneticisi X X

*: Bu roller kullanıcıların yalnızca yönetim grubu kapsamında belirtilen eylemleri gerçekleştirmesine olanak tanır.

**: Kök yönetim grubundaki rol atamalarının aboneliği veya yönetim grubunu bu gruba taşımak için gerekli değildir.

Hiyerarşi içindeki öğeleri taşıma hakkında ayrıntılı bilgi için bkz . Kaynaklarınızı yönetim gruplarıyla yönetme.

Azure özel rol tanımı ve ataması

Bir yönetim grubunu Azure özel rol tanımında atanabilir kapsam olarak tanımlayabilirsiniz. Azure özel rolü daha sonra bu yönetim grubuna ve altındaki herhangi bir yönetim grubuna, aboneliğe, kaynak grubuna veya kaynağa atanabilir. Özel rol, herhangi bir yerleşik rol gibi hiyerarşiyi devralır.

Özel roller ve yönetim gruplarıyla ilgili sınırlamalar hakkında bilgi için bu makalenin devamında yer alan Sınırlamalar bölümüne bakın.

Örnek tanım

Özel rol tanımlama ve oluşturma, yönetim gruplarının eklenmesiyle birlikte değişmez. Yönetim grubunu tanımlamak için tam yolu kullanın: /providers/Microsoft.Management/managementgroups/{_groupId_}.

Yönetim grubunun görünen adını değil yönetim grubunun kimliğini kullanın. Bu yaygın hatanın nedeni, her ikisinin de yönetim grubu oluşturmada özel tanımlı alanlar olmasıdır.

...
{
  "Name": "MG Test Custom Role",
  "Id": "id",
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementGroups/delete",
    "Microsoft.Management/managementGroups/read",
    "Microsoft.Management/managementGroups/write",
    "Microsoft.Management/managementGroups/subscriptions/delete",
    "Microsoft.Management/managementGroups/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

Rol tanımı ve atama hiyerarşisi yolunu bozmayla ilgili sorunlar

Rol tanımları, yönetim grubu hiyerarşisinin herhangi bir yerinde atanabilir kapsamlardır. Rol tanımı üst yönetim grubunda olabilirken, gerçek rol ataması alt abonelikte bulunur. İki öğe arasında bir ilişki olduğundan, atamayı tanımından ayırmaya çalışırsanız bir hata alırsınız.

Örneğin, hiyerarşinin küçük bir bölümünün aşağıdaki örneğini göz önünde bulundurun.

Örnek yönetim grubu hiyerarşisinin bir alt kümesinin diyagramı.

Diyagram, alt giriş bölgeleri ve korumalı alan yönetim gruplarıyla kök yönetim grubuna odaklanır. Giriş bölgelerinin yönetim grubunda Corp ve Online adlı iki alt yönetim grubu bulunurken, korumalı alan yönetim grubunun iki alt aboneliği vardır.

Korumalı alan yönetim grubunda özel bir rol tanımlandığını varsayalım. Bu özel rol daha sonra iki korumalı alan aboneliğine atanır.

Bu aboneliklerden birini Corp yönetim grubunun alt öğesi olacak şekilde taşımaya çalışırsanız, abonelik rolü atamasından korumalı alan yönetim grubunun rol tanımına giden yolu kesmiş olursunuz. Bu senaryoda, bu ilişkiyi bozacağından taşımaya izin verilmediğini belirten bir hata alırsınız.

Bu senaryoyı düzeltmek için şu seçeneklere sahipsiniz:

  • Aboneliği yeni bir üst yönetim grubuna taşımadan önce abonelikten rol atamasını kaldırın.
  • Aboneliği rol tanımının atanabilir kapsamına ekleyin.
  • Rol tanımı içinde atanabilir kapsamı değiştirin. Bu örnekte, hiyerarşinin her iki dalının da tanıma ulaşabilmesi için korumalı alan yönetim grubundan atanabilir kapsamları kök yönetim grubuna güncelleştirebilirsiniz.
  • Diğer dalda tanımlanan başka bir özel rol oluşturun. Bu yeni rol, abonelikte rolü değiştirmenizi de gerektirir.

Sınırlamalar

Yönetim gruplarında özel roller kullanmanın sınırlamaları vardır:

  • Yeni rolün atanabilir kapsamlarında yalnızca bir yönetim grubu tanımlayabilirsiniz. Bu sınırlama, rol tanımlarının ve rol atamalarının bağlantısının kesildiği durumların sayısını azaltmak için geçerlidir. Bu tür bir durum, rol ataması olan bir abonelik veya yönetim grubu rol tanımına sahip olmayan farklı bir üst öğeye geçtiğinde ortaya çıkar.
  • DataActions içeren özel roller yönetim grubu kapsamında atanamaz. Daha fazla bilgi için bkz . Özel rol sınırları.
  • Azure Resource Manager, rol tanımının atanabilir kapsamında yönetim grubunun varlığını doğrulamaz. Yazım hatası veya yanlış bir yönetim grubu kimliği varsa rol tanımı oluşturulmaya devam edilir.

Yönetim gruplarını ve abonelikleri taşıma

Bir yönetim grubunu veya aboneliği başka bir yönetim grubunun alt öğesi olarak taşımak için şunlar gerekir:

  • Yönetim grubu yazma izinleri ve rol ataması yazma izinleri alt abonelik veya yönetim grubu üzerinde.
    • Yerleşik rol örneği: Sahip
  • Yönetim grubu yazma erişimi hedef üst yönetim grubunda.
    • Yerleşik rol örneği: Sahip, Katkıda Bulunan, Yönetim Grubu Katkıda Bulunanı
  • Mevcut üst yönetim grubunda yönetim grubu yazma erişimi.
    • Yerleşik rol örneği: Sahip, Katkıda Bulunan, Yönetim Grubu Katkıda Bulunanı

Bir özel durum vardır: hedef veya mevcut üst yönetim grubu kök yönetim grubuysa, izin gereksinimleri geçerli değildir. Kök yönetim grubu tüm yeni yönetim grupları ve abonelikler için varsayılan giriş noktası olduğundan, öğeyi taşımak için bu grupta izinlere ihtiyacınız yoktur.

Abonelikte Sahip rolü geçerli yönetim grubundan devralındıysa taşıma hedefleriniz sınırlıdır. Aboneliği yalnızca Sahip rolüne sahip olduğunuz başka bir yönetim grubuna taşıyabilirsiniz. Aboneliğin sahipliğini kaybedeceğiniz için aboneliği yalnızca Katkıda Bulunan olduğunuz bir yönetim grubuna taşıyamazsınız. Aboneliğin Sahip rolüne doğrudan atandıysanız, bunu Katkıda Bulunan rolüne sahip olduğunuz herhangi bir yönetim grubuna taşıyabilirsiniz.

Önemli

Azure Resource Manager, yönetim grubu hiyerarşisinin ayrıntılarını 30 dakikaya kadar önbelleğe alır. Sonuç olarak, Azure portalında bir yönetim grubunu taşıdığınız hemen gösterilmeyebilir.

Etkinlik günlüklerini kullanarak yönetim gruplarını denetleme

Yönetim grupları Azure İzleyici etkinlik günlüklerinde desteklenir. Bir yönetim grubuna gerçekleşen tüm olayları diğer Azure kaynaklarıyla aynı merkezi konumda sorgulayabilirsiniz. Örneğin, belirli bir yönetim grubunda yapılan tüm rol atamalarını veya ilke atama değişikliklerini görebilirsiniz.

Seçili bir yönetim grubuyla ilgili etkinlik günlüklerinin ve işlemlerin ekran görüntüsü.

Azure portalı dışındaki yönetim gruplarını sorgulamak istediğinizde, yönetim gruplarının hedef kapsamı gibi "/providers/Microsoft.Management/managementGroups/{management-group-id}"görünür.

Not

Azure Resource Manager REST API'sini kullanarak bir yönetim grubunda tanılama ayarlarını etkinleştirerek ilgili Azure İzleyici etkinlik günlüğü girdilerini Log Analytics çalışma alanına, Azure Depolama'ya veya Azure Event Hubs'a gönderebilirsiniz. Daha fazla bilgi için bkz . Yönetim grubu tanılama ayarları: Oluşturma veya güncelleştirme.

Yönetim grupları hakkında daha fazla bilgi almak için bkz.: