Azure yönetim grupları nedir?What are Azure management groups?

Kuruluşunuzda birden fazla abonelik varsa bu abonelikler için verimli bir şekilde erişim, ilke ve uyumluluk yönetimi gerçekleştirmek isteyebilirsiniz.If your organization has many subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Azure yönetim grupları aboneliklerin üzerinde bir kapsam düzeyi sağlar.Azure management groups provide a level of scope above subscriptions. Abonelikleri "yönetim grupları" adlı kapsayıcılarla düzenler ve idare koşullarınızı bu yönetim gruplarına uygularsınız.You organize subscriptions into containers called "management groups" and apply your governance conditions to the management groups. Bir yönetim grubu içindeki aboneliklerin tümü otomatik olarak yönetim grubuna uygulanmış olan koşulları devralır.All subscriptions within a management group automatically inherit the conditions applied to the management group. Yönetim grupları, sahip olabileceğiniz abonelik türüne bakılmaksızın kurumsal düzeyde yönetimi büyük ölçekte sunar.Management groups give you enterprise-grade management at a large scale no matter what type of subscriptions you might have. Tek bir yönetim grubu içindeki tüm abonelikler aynı Azure Active Directory kiracısına güvenmelidir.All subscriptions within a single management group must trust the same Azure Active Directory tenant.

Örneğin, sanal makine (VM) oluşturma işlemi için kullanılabilir olan bölgeleri sınırlayan bir yönetim grubuna ilkeleri uygulayabilirsiniz.For example, you can apply policies to a management group that limits the regions available for virtual machine (VM) creation. Bu ilke, yalnızca o bölgede VM oluşturulmasına izin vererek söz konusu yönetim grubu altındaki tüm yönetim gruplarına, aboneliklere ve kaynaklara uygulanır.This policy would be applied to all management groups, subscriptions, and resources under that management group by only allowing VMs to be created in that region.

Yönetim grupları ve abonelikler hiyerarşisiHierarchy of management groups and subscriptions

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.You can build a flexible structure of management groups and subscriptions to organize your resources into a hierarchy for unified policy and access management. Aşağıdaki diyagramda, yönetim grupları kullanılarak idare amaçlı bir hiyerarşi oluşturma örneği gösterilmektedir.The following diagram shows an example of creating a hierarchy for governance using management groups.

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

Yönetim gruplarını ve abonelikleri tutan bir kök yönetim grubunun diyagramı.Diagram of a root management group holding both management groups and subscriptions. Bazı alt yönetim grupları Yönetim gruplarını, bazı ayrı tutulan abonelikleri ve her ikisini de tutar.Some child management groups hold management groups, some hold subscriptions, and some hold both. Örnek hiyerarşisindeki örneklerden biri, alt düzeyi tüm aboneliklerde olan dört yönetim grubu düzeyidir.One of the examples in the sample hierarchy is four levels of management groups with the child level being all subscriptions.

İlke uygulayan bir hiyerarşi oluşturabilirsiniz. Örneğin bu, “Üretim” adlı grupta VM konumlarını ABD Batı Bölgesiyle sınırlayan bir ilke olabilir.You can create a hierarchy that applies a policy, for example, which limits VM locations to the US West Region in the group called "Production". Bu ilke, o yönetim grubunun alt öğeleri olan her iki Kurumsal Anlaşma (EA) aboneliğine devredilir ve o abonelikler altındaki tüm VM’ler için geçerli olur.This policy will inherit onto all the Enterprise Agreement (EA) subscriptions that are descendants of that management group and will apply to all VMs under those subscriptions. Bu güvenlik ilkesi kaynak veya abonelik sahibi tarafından değiştirilemez ve bu da idarenin geliştirilmesine olanak tanır.This security policy cannot be altered by the resource or subscription owner allowing for improved governance.

Yönetim gruplarını kullanacağınız başka bir senaryo ise birden fazla aboneliğe kullanıcı erişimi sağlamaktır.Another scenario where you would use management groups is to provide user access to multiple subscriptions. Bu yönetim grubunun altına birden çok abonelik taşıyarak, yönetim grubunda, tüm aboneliklerle erişimi devralacak bir Azure rol ataması oluşturabilirsiniz.By moving multiple subscriptions under that management group, you can create one Azure role assignment on the management group, which will inherit that access to all the subscriptions. Yönetim grubundaki bir atama, kullanıcıların Azure RBAC 'yi farklı abonelikler üzerinde komut dosyası oluşturmak yerine, ihtiyaç duydukları her şeye erişmesini sağlayabilir.One assignment on the management group can enable users to have access to everything they need instead of scripting Azure RBAC over different subscriptions.

Yönetim gruplarıyla ilgili önemli olgularImportant facts about management groups

  • Tek bir dizinde 10.000 yönetim grubu desteklenebilir.10,000 management groups can be supported in a single directory.
  • Bir yönetim grubu en fazla altı derinlik düzeyini destekleyebilir.A management group tree can support up to six levels of depth.
    • Bu sınır, Kök düzeyini veya abonelik düzeyini içermez.This limit doesn't include the Root level or the subscription level.
  • Her yönetim grubu ve abonelik yalnızca bir üst öğeyi destekler.Each management group and subscription can only support one parent.
  • Her yönetim grubunun birçok alt öğesi olabilir.Each management group can have many children.
  • Tüm abonelikler ve yönetim grupları, her bir dizindeki tek bir hiyerarşi içinde yer alır.All subscriptions and management groups are within a single hierarchy in each directory. Bkz. Kök yönetim grubu hakkında önemli bilgiler.See Important facts about the Root management group.

Her dizin için kök yönetim grubuRoot management group for each directory

Her dizinde "Kök" yönetim grubu olarak adlandırılan tek bir üst düzey yönetim grubu bulunur.Each directory is given a single top-level management group called the "Root" management group. Diğer tüm yönetim grupları ve abonelikler hiyerarşide en üstte yer alan bu kök yönetim grubunun altındadır.This root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. Bu kök yönetim grubu, genel ilkelerin ve Azure rol atamalarının dizin düzeyinde uygulanmasını sağlar.This root management group allows for global policies and Azure role assignments to be applied at the directory level. Başlangıçta Azure AD Genel Yöneticisinin bu kök grubunun Kullanıcı Erişimi Yönetici rolüne kendisini yükseltmesi gerekir.The Azure AD Global Administrator needs to elevate themselves to the User Access Administrator role of this root group initially. Erişim yükseltildikten sonra, yönetici, hiyerarşiyi yönetmek için diğer dizin kullanıcılarına veya gruplarına herhangi bir Azure rolü atayabilir.After elevating access, the administrator can assign any Azure role to other directory users or groups to manage the hierarchy. Yönetici olarak, kendi hesabınızı kök yönetim grubunun sahibi olarak atayabilirsiniz.As administrator, you can assign your own account as owner of the root management group.

Kök yönetim grubu hakkında önemli bilgilerImportant facts about the Root management group

  • Varsayılan olarak, kök yönetim grubunun görünen adı Kiracı kök grubu olur.By default, the root management group's display name is Tenant root group. Kimlik, Azure Active Directory Kimliği’dir.The ID is the Azure Active Directory ID.
  • Görünen adı değiştirmek için hesabınızın, kök yönetim grubunun Sahip veya Katkıda Bulunan rolüne atanması gerekir.To change the display name, your account must be assigned the Owner or Contributor role on the root management group. Bir yönetim grubunun adını güncelleştirmek için bir yönetim grubunun adını değiştirme konusuna bakın.See Change the name of a management group to update the name of a management group.
  • Diğer yönetim gruplarının aksine kök yönetim grubu taşınamaz veya silinemez.The root management group can't be moved or deleted, unlike other management groups.
  • Tüm abonelikler ve yönetim grupları, dizinin içindeki bir kök yönetim grubu altında birleşir.All subscriptions and management groups fold up to the one root management group within the directory.
    • Dizindeki tüm kaynaklar, genel yönetim için kök yönetim grubu altında birleşir.All resources in the directory fold up to the root management group for global management.
    • Yeni abonelikler, oluşturulduğunda kök yönetim grubuna otomatik olarak eklenir.New subscriptions are automatically defaulted to the root management group when created.
  • 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.All Azure customers can see the root management group, but not all customers have access to manage that root management group.
    • Bir aboneliğe erişimi olan herkes bu aboneliğin hiyerarşide bulunduğu bağlamı görebilir.Everyone who has access to a subscription can see the context of where that subscription is in the hierarchy.
    • Kök yönetim grubuna hiç kimsenin varsayılan erişimi yoktur.No one is given default access to the root management group. Erişim kazanmak için yalnızca Azure AD Genel Yöneticileri kendi rollerini yükseltebilir.Azure AD Global Administrators are the only users that can elevate themselves to gain access. Kök yönetim grubuna erişim izni olduktan sonra, genel Yöneticiler yönetmek için diğer kullanıcılara herhangi bir Azure rolü atayabilirOnce they have access to the root management group, the global administrators can assign any Azure role to other users to manage
      içerdiği.it.
  • SDK 'da kök yönetim grubu veya ' kiracı kökü ' bir yönetim grubu olarak çalışır.In SDK, the root management group, or 'Tenant Root', operates as a management group.

Önemli

Kök yönetim grubu grubunda yapılan herhangi bir kullanıcı erişimi ataması veya ilke ataması, dizin içindeki tüm kaynaklara uygulanır.Any assignment of user access or policy assignment on the root management group applies to all resources within the directory. Bu nedenle, tüm müşterilerin bu kapsamda tanımlanmış öğelere sahip olma gereksinimini değerlendirmesi gerekir.Because of this, all customers should evaluate the need to have items defined on this scope. Kullanıcı erişimi ve ilke atamalarının "olması gerekir" olması gerekirUser access and policy assignments should be "Must Have" only at this
kapsam.scope.

Yönetim gruplarının ilk ayarıInitial setup of management groups

Herhangi bir kullanıcı yönetim gruplarını kullanmaya başladığında gerçekleştirilen bir ilk ayar işlemi vardır.When any user starts using management groups, there's an initial setup process that happens. İlk adım, dizinde kök yönetim grubunun oluşturulmasıdır.The first step is the root management group is created in the directory. Bu grup oluşturulduktan sonra dizinde mevcut olan tüm abonelikler, kök yönetim grubunun alt öğesi yapılır.Once this group is created, all existing subscriptions that exist in the directory are made children of the root management group. 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.The reason for this process is to make sure there's only one management group hierarchy within a directory. 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.The single hierarchy within the directory allows administrative customers to apply global access and policies that other customers within the directory can't bypass. Kökte atanan her şey hiyerarşinin tamamına uygulanır. Buna söz konusu Azure AD Kiracısı içindeki tüm yönetim grupları, abonelikler, kaynak grupları ve kaynaklar dahildir.Anything assigned on the root will apply to the entire hierarchy, which includes all management groups, subscriptions, resource groups, and resources within that Azure AD Tenant.

Tüm abonelikler görüntülenirken oluşan sorunTrouble seeing all subscriptions

25 Haziran 2018’den önce, önizlemenin ilk aşamasında yönetim gruplarını kullanmaya başlayan birkaç dizin, tüm aboneliklerin hiyerarşi içinde yer almamasıyla ilgili bir hatayla karşılaşabiliyordu.A few directories that started using management groups early in the preview before June 25 2018 could see an issue where not all the subscriptions were within the hierarchy. Tüm abonelikleri hiyerarşiye almaya yönelik işlem, dizindeki kök yönetim grubunda bir rol veya ilke ataması yapıldıktan sonra gerçekleştiriliyordu.The process to have all subscriptions in the hierarchy was put in place after a role or policy assignment was done on the root management group in the directory.

Sorunu çözmeHow to resolve the issue

Bu sorunu çözmek için kullanabileceğiniz iki seçenek vardır.There are two options you can do to resolve this issue.

  • Kök yönetim grubundan tüm Rol ve İlke atamalarını kaldırmaRemove all Role and Policy assignments from the root management group
    • Kök yönetim grubundan herhangi bir ilke ve rol ataması kaldırılarak, hizmet tüm abonelikleri sonraki gece ömrü boyunca hiyerarşiye doldurur.By removing any policy and role assignments from the root management group, the service backfills all subscriptions into the hierarchy the next overnight cycle. Bu işlemde, tüm kiracı aboneliklerine yanlışlıkla erişim verilmediğinden ve ilke ataması yapılmadığından emin olunur.This process is so there's no accidental access given or policy assignment to all of the tenants subscriptions.
    • Hizmetlerinizi etkilemeden bu işlemi yapmanın en iyi yolu, rolü veya ilke atamasını Kök yönetim grubunun bir alt düzeyine uygulamaktır.The best way to do this process without impacting your services is to apply the role or policy assignments one level below the Root management group. Daha sonra tüm atamaları kök kapsamından çıkarabilirsiniz.Then you can remove all assignments from the root scope.
  • Geriye dönük doldurma işlemini başlatmak için doğrudan API’yi çağırınCall the API directly to start the backfill process
    • Dizindeki herhangi bir müşteri TenantBackfillStatusRequest veya StartTenantBackfillRequest API’lerini çağırabilir.Any customer in the directory can call the TenantBackfillStatusRequest or StartTenantBackfillRequest APIs. StartTenantBackfillRequest API’si çağrıldığında tüm abonelikleri hiyerarşiye taşımanın ilk kurulum işlemini başlatır.When the StartTenantBackfillRequest API is called, it kicks off the initial setup process of moving all the subscriptions into the hierarchy. Ayrıca bu işlem, tüm yeni abonelikleri kök yönetim grubunun alt öğesi olmaya zorlama işlemini de başlatır.This process also starts the enforcement of all new subscription to be a child of the root management group. Bu işlem, kök düzeyde hiçbir atama değiştirilmeden yapılabilir.This process can be done without changing any assignments on the root level. API'yi çağırarak, kökteki her ilke veya erişim atamasının tüm aboneliklere uygulanmasının sorun olmadığını belirtmiş olursunuz.By calling the API, you're saying it's okay that any policy or access assignment on the root can be applied to all subscriptions.

Bu geriye dönük doldurma işlemi hakkında sorularınız varsa şu adresten bize ulaşın: managementgroups@microsoft.comIf you have questions on this backfill process, contact: managementgroups@microsoft.com

Yönetim grubu erişimiManagement group access

Azure Yönetim grupları tüm kaynak erişimleri ve rol tanımları için Azure rol tabanlı erişim denetimi 'ni (Azure RBAC) destekler.Azure management groups support Azure role-based access control (Azure RBAC) for all resource accesses and role definitions. Bu izinler, hiyerarşide mevcut olan alt kaynaklara devredilir.These permissions are inherited to child resources that exist in the hierarchy. Herhangi bir Azure rolü, hiyerarşiyi kaynaklara devralacak bir yönetim grubuna atanabilir.Any Azure role can be assigned to a management group that will inherit down the hierarchy to the resources. Örneğin, Azure rolü sanal makine katılımcısı bir yönetim grubuna atanabilir.For example, the Azure role VM contributor can be assigned to a management group. Bu rolün yönetim grubu üzerinde herhangi bir eylemi yoktur ancak o yönetim grubu altındaki tüm VM’lere devredilir.This role has no action on the management group, but will inherit to all VMs under that management group.

Aşağıdaki grafikte rollerin listesi ve yönetim gruplarında desteklenen eylemler gösterilmektedir.The following chart shows the list of roles and the supported actions on management groups.

Azure rolü adıAzure Role Name OluşturCreate RenameRename Geçiş**Move** SilDelete Erişim AtaAssign Access İlke AtaAssign Policy OkumaRead
SahipOwner XX XX XX XX XX XX XX
KatılımcıContributor XX XX XX XX XX
MG Katılımcısı*MG Contributor* XX XX XX XX XX
OkuyucuReader XX
MG okuyucusu*MG Reader* XX
Kaynak İlkesine Katkıda BulunanResource Policy Contributor XX
Kullanıcı Erişimi YöneticisiUser Access Administrator XX XX

*: MG katkıda bulunan ve MG Reader yalnızca kullanıcıların yönetim grubu kapsamında bu eylemleri yapmasına izin verir.*: MG Contributor and MG Reader only allow users to do those actions on the management group scope.
**: Kök yönetim grubundaki rol atamaları, bir aboneliği veya yönetim grubunu bu gruba taşımak için gerekli değildir.**: Role Assignments on the Root management group aren't required to move a subscription or management group to and from it. Hiyerarşi içindeki öğeleri taşımayla ilgili ayrıntılar için bkz. Kaynaklarınızı yönetim gruplarıyla yönetme.See Manage your resources with management groups for details on moving items within the hierarchy.

Azure özel rol tanımı ve atamasıAzure custom role definition and assignment

Yönetim grupları için Azure özel rol desteği şu anda bazı kısıtlamalarla önizlemededir.Azure custom role support for management groups is currently in preview with some limitations. Rol Tanımının atanabilir kapsamında yönetim grubu kapsamını tanımlayabilirsiniz.You can define the management group scope in the Role Definition's assignable scope. Daha sonra bu Azure özel rolü bu yönetim grubu ve bu yönetim grubu, abonelik, kaynak grubu veya kaynak üzerinde atanmak üzere kullanılabilir olacaktır.That Azure custom role will then be available for assignment on that management group and any management group, subscription, resource group, or resource under it. Bu özel rol, herhangi bir yerleşik rol gibi hiyerarşide aşağıya doğru devralınır.This custom role will inherit down the hierarchy like any built-in role.

Örnek tanımExample definition

Özel bir rol tanımlama ve oluşturma , yönetim gruplarının eklenmesine göre değişmez.Defining and creating a custom role doesn't change with the inclusion of management groups. Yönetim grubu /providers/Microsoft.Management/managementgroups/{GroupID} tanımlamak için tam yolu kullanın.Use the full path to define the management group /providers/Microsoft.Management/managementgroups/{groupId}.

Yönetim grubunun görünen adını değil, yönetim grubunun KIMLIĞINI kullanın.Use the management group's ID and not the management group's display name. Bu ortak hata, her ikisi de bir yönetim grubu oluştururken özel tanımlanmış alanlar olduğundan oluşur.This common error happens since both are custom-defined fields when creating a management group.

...
{
  "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/managementgroup/write",
    "Microsoft.Management/managementgroup/subscriptions/delete",
    "Microsoft.Management/managementgroup/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 bozan sorunlarIssues with breaking the role definition and assignment hierarchy path

Rol tanımları, yönetim grubu hiyerarşisi içinde herhangi bir yerde atanabilir kapsamdadır.Role definitions are assignable scope anywhere within the management group hierarchy. Alt abonelikte gerçek rol ataması varken, bir üst yönetim grubunda rol tanımı tanımlanabilir.A role definition can be defined on a parent management group while the actual role assignment exists on the child subscription. İki öğe arasında bir ilişki olduğundan, atamayı tanımdan ayırmaya çalışırken bir hata alacaksınız.Since there's a relationship between the two items, you'll receive an error when trying to separate the assignment from its definition.

Örneğin, bir görselin hiyerarşinin küçük bir bölümüne bakalım.For example, let's look at a small section of a hierarchy for a visual.

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

Diyagram, alt I T ve pazarlama yönetimi gruplarıyla kök yönetim grubuna odaklanır.The diagram focuses on the root management group with child I T and Marketing management groups. I T yönetim grubunun üretim adlı tek bir alt yönetim grubu vardır, ancak pazarlama yönetim grubunun iki ücretsiz deneme alt aboneliği vardır.The I T management group has a single child management group named Production while the Marketing management group has two Free Trial child subscriptions.

Pazarlama Yönetimi grubunda tanımlanmış özel bir rol olduğunu varsayalım.Let's say there's a custom role defined on the Marketing management group. Bu özel rol daha sonra iki ücretsiz deneme aboneliğine atanır.That custom role is then assigned on the two free trial subscriptions.

Bu aboneliklerden birini üretim yönetim grubunun bir alt öğesi olacak şekilde taşımaya çalışırsam, bu taşıma, abonelik rolü atamasından pazarlama yönetim grubu rolü tanımına kadar olan yolu keser.If we try to move one of those subscriptions to be a child of the Production management group, this move would break the path from subscription role assignment to the Marketing management group role definition. Bu senaryoda, bu ilişkiyi bozduğundan beri taşımaya izin verilmediğini belirten bir hata alırsınız.In this scenario, you'll receive an error saying the move isn't allowed since it will break this relationship.

Bu senaryoyu gidermeye yönelik birkaç farklı seçenek vardır:There are a couple different options to fix this scenario:

  • Aboneliği yeni bir üst MG öğesine taşımadan önce rol atamasını abonelikten kaldırın.Remove the role assignment from the subscription before moving the subscription to a new parent MG.
  • Aboneliği rol tanımının atanabilir kapsamına ekleyin.Add the subscription to the Role Definition's assignable scope.
  • Rol tanımı içindeki atanabilir kapsamı değiştirin.Change the assignable scope within the role definition. Yukarıdaki örnekte, bir şekilde atanabilir kapsamları, hiyerarşinin her iki dalı tarafından ulaşılabilmesi için, bir pazarlama üzerinden kök yönetim grubuna güncelleştirebilirsiniz.In the above example, you can update the assignable scopes from Marketing to Root Management Group so that the definition can be reached by both branches of the hierarchy.
  • Diğer dalda tanımlanmış başka bir özel rol oluşturun.Create another Custom Role that is defined in the other branch. Bu yeni rol, rol atamasının abonelik üzerinde de değiştirilmesini gerektirir.This new role requires the role assignment to be changed on the subscription also.

SınırlamalarLimitations

Yönetim gruplarında özel roller kullanılırken var olan sınırlamalar vardır.There are limitations that exist when using custom roles on management groups.

  • Yalnızca bir yönetim grubunu, yeni bir rolün atanabilir kapsamlarında tanımlayabilirsiniz.You can only define one management group in the assignable scopes of a new role. Bu sınırlama, rol tanımlarının ve rol atamalarının kesilmediği durumların sayısını azaltmak için kullanılır.This limitation is in place to reduce the number of situations where role definitions and role assignments are disconnected. Bu durum, rol atamasının bulunduğu bir abonelik veya yönetim grubu, rol tanımına sahip olmayan farklı bir üst öğeye taşınırsa meydana gelir.This situation happens when a subscription or management group with a role assignment moves to a different parent that doesn't have the role definition.
  • Kaynak sağlayıcısı veri düzlemi eylemleri yönetim grubu özel rollerinde tanımlanamaz.Resource provider data plane actions can't be defined in management group custom roles. Bu kısıtlama, veri düzlemi kaynak sağlayıcılarının güncelleştirilmesiyle ilgili bir gecikme sorunu olduğu için gerçekleştirilir.This restriction is in place as there's a latency issue with updating the data plane resource providers. Bu gecikme sorunu üzerinde çalışıyor ve tüm riskleri azaltmak için bu eylemler rol tanımından devre dışı bırakılacak.This latency issue is being worked on and these actions will be disabled from the role definition to reduce any risks.
  • Azure Resource Manager, rol tanımının atanabilir kapsamındaki yönetim grubunun varlığını doğrulamaz.The Azure Resource Manager doesn't validate the management group's existence in the role definition's assignable scope. Bir yazım hatası veya yanlış bir yönetim grubu kimliği listeleniyorsa, rol tanımı yine de oluşturulur.If there's a typo or an incorrect management group ID listed, the role definition is still created.
  • Dataactions içeren bir rol için rol ataması desteklenmez.Role assignment for a role with dataActions aren't supported. Bunun yerine abonelik kapsamında rol ataması oluşturun.Create the role assignment at the subscription scope instead.

Önemli

' Ye bir yönetim grubu eklemek AssignableScopes Şu anda önizlemededir.Adding a management group to AssignableScopes is currently in preview. Önizleme sürümü bir hizmet düzeyi sözleşmesi olmadan sağlanır ve üretim iş yüklerinde kullanılması önerilmez.This preview version is provided without a service level agreement, and it's not recommended for production workloads. Bazı özellikler desteklenmiyor olabileceği gibi özellikleri sınırlandırılmış da olabilir.Certain features might not be supported or might have constrained capabilities. Daha fazla bilgi için bkz. Microsoft Azure Önizlemeleri için Ek Kullanım Koşulları.For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

Yönetim gruplarını ve abonelikleri taşımaMoving management groups and subscriptions

Bir yönetim grubunu veya aboneliğini başka bir yönetim grubunun alt öğesi olacak şekilde taşımak için, üç kuralın doğru olarak değerlendirilmesi gerekir.To move a management group or subscription to be a child of another management group, three rules need to be evaluated as true.

Taşıma eylemini gerçekleştiriyorsanız şunlar gerekir:If you're doing the move action, you need:

  • Alt abonelik veya yönetim grubundaki yönetim grubu yazma ve rol atama yazma izinleri.Management group write and Role Assignment write permissions on the child subscription or management group.
    • Yerleşik rol örneği sahibiBuilt-in role example Owner
  • Hedef üst yönetim grubunda yönetim grubu yazma erişimi.Management group write access on the target parent management group.
    • Yerleşik rol örneği: sahip, katkıda bulunan, Yönetim grubu katılımcısıBuilt-in role example: Owner, Contributor, Management Group Contributor
  • Yönetim grubu var olan üst yönetim grubu üzerinde yazma erişimi.Management group write access on the existing parent management group.
    • Yerleşik rol örneği: sahip, katkıda bulunan, Yönetim grubu katılımcısıBuilt-in role example: Owner, Contributor, Management Group Contributor

Özel durum: hedef veya var olan üst yönetim grubu kök yönetim grubinise, izin gereksinimleri geçerli değildir.Exception: If the target or the existing parent management group is the Root management group, the permissions requirements don't apply. Kök yönetim grubu tüm yeni yönetim grupları ve abonelikler için varsayılan giriş noktası olduğundan, bir öğeyi taşımak için üzerinde izinleriniz olması gerekmez.Since the Root management group is the default landing spot for all new management groups and subscriptions, you don't need permissions on it to move an item.

Abonelikte sahip rolü geçerli yönetim grubundan devralınmışsa, taşıma hedefleriniz sınırlıdır.If the Owner role on the subscription is inherited from the current management group, your move targets are limited. Aboneliği yalnızca sahip rolüne sahip olduğunuz başka bir yönetim grubuna taşıyabilirsiniz.You can only move the subscription to another management group where you have the Owner role. Aboneliğin sahipliğini kaybedeceinizden katılımcı olduğunuz bir yönetim grubuna taşıyamazsınız.You can't move it to a management group where you're a contributor because you would lose ownership of the subscription. Abonelik için (yönetim grubundan devralınmaz) sahip rolüne doğrudan atandıysanız, katılımcısı olduğunuz herhangi bir yönetim grubuna taşıyabilirsiniz.If you're directly assigned to the Owner role for the subscription (not inherited from the management group), you can move it to any management group where you're a contributor.

Etkinlik günlüklerini kullanarak yönetim gruplarını denetlemeAudit management groups using activity logs

Yönetim grupları Azure Etkinlik Günlüğü'nde desteklenir.Management groups are supported within Azure Activity Log. Yönetim grubunda gerçekleşen tüm olayları, diğer Azure kaynaklarıyla aynı merkezi konumda arayabilirsiniz.You can search all events that happen to a management group in the same central location as other Azure resources. Örneğin, belirli bir yönetim grubunda yapılan tüm Rol Atamalarını veya İlke Ataması değişikliklerini görebilirsiniz.For example, you can see all Role Assignments or Policy Assignment changes made to a particular management group.

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

Azure portalının dışında Yönetim Gruplarını sorgulamak istediğinizde, yönetim gruplarının hedef kapsamı "/providers/Microsoft.Management/managementGroups/{yourMgID}" gibi görünür.When looking to query on Management Groups outside of the Azure portal, the target scope for management groups looks like "/providers/Microsoft.Management/managementGroups/{yourMgID}".

Sonraki adımlarNext steps

Yönetim grupları hakkında daha fazla bilgi almak için bkz.:To learn more about management groups, see: