Yönetilen kimlikler için en iyi yöntem önerileri
Azure kaynakları için yönetilen kimlikler, Microsoft Entra Id'nin bir özelliğidir. Azure kaynakları için yönetilen kimlikleri destekleyen Azure hizmetlerinin her biri kendi zaman çizelgesine tabidir. Başlamadan önce kaynağınıza yönelik yönetilen kimliklerin kullanılabilirlik durumunu ve bilinen sorunları gözden geçirdiğinizden emin olun.
Sistem veya kullanıcı tarafından atanan yönetilen kimlikleri seçme
Kullanıcı tarafından atanan yönetilen kimlikler, sistem tarafından atanan yönetilen kimliklere göre daha geniş bir senaryo aralığında daha verimlidir. Bazı senaryolar ve kullanıcı tarafından atanan veya sistem tarafından atanan öneriler için aşağıdaki tabloya bakın.
Kullanıcı tarafından atanan kimlikler birden çok kaynak tarafından kullanılabilir ve yaşam döngüleri, kaynakların ilişkili oldukları yaşam döngülerinden ayrılmıştır. Yönetilen kimlikleri destekleyen kaynakları okuyun.
Bu yaşam döngüsü, kaynak oluşturma ve kimlik yönetimi sorumluluklarınızı ayırmanıza olanak tanır. Kullanıcı tarafından atanan kimlikler ve rol atamaları, bunları gerektiren kaynaklardan önce yapılandırılabilir. Kaynakları oluşturan kullanıcılar, yeni kimlikler veya rol atamaları oluşturmaya gerek kalmadan yalnızca kullanıcı tarafından atanan bir kimlik atama erişimine ihtiyaç duyar.
Sistem tarafından atanan kimlikler kaynakla birlikte oluşturulup silindikçe rol atamaları önceden oluşturulamaz. Kaynağı oluşturan kullanıcının da rol atamaları oluşturma erişimi yoksa, bu dizi altyapı dağıtılırken hatalara neden olabilir.
Altyapınız birden çok kaynağın aynı kaynaklara erişmesini gerektiriyorsa, bunlara tek bir kullanıcı tarafından atanan kimlik atanabilir. Yönetilecek daha az farklı kimlik ve rol ataması olduğundan yönetim yükü azaltılacaktır.
Her kaynağın kendi kimliğine sahip olmasını veya benzersiz bir izin kümesi gerektiren kaynaklarınız olmasını ve kaynak silindikçe kimliğin silinmesini istiyorsanız, sistem tarafından atanan bir kimlik kullanmalısınız.
| Senaryo | Öneri | Notlar |
|---|---|---|
| Yönetilen kimliklerle kaynakların hızlı bir şekilde oluşturulması (örneğin kısa ömürlü bilgi işlem) | Kullanıcı tarafından atanan kimlik | Kısa bir süre içinde birden çok yönetilen kimlik oluşturmayı denerseniz (örneğin, her biri kendi sistem tarafından atanan kimlikleriyle birden çok sanal makine dağıtma) Microsoft Entra nesnesi oluşturma hız sınırını aşabilir ve istek HTTP 429 hatasıyla başarısız olur. Kaynaklar hızla oluşturuluyor veya siliniyorsa, sistem tarafından atanan kimlikleri kullanıyorsanız Microsoft Entra Id'deki kaynak sayısı sınırını da aşabilirsiniz. Sistem tarafından atanan silinmiş bir kimliğe artık herhangi bir kaynak tarafından erişilemiyor olsa da, 30 gün sonra tamamen temizlenene kadar sınırınıza kadar sayılır. Kullanıcı tarafından atanan tek bir kimlikle ilişkili kaynakların dağıtılması için Microsoft Entra Id'de yalnızca bir Hizmet Sorumlusu oluşturulması gerekir ve hız sınırından kaçınılır. Önceden oluşturulan tek bir kimliğin kullanılması, her biri kendi kimliğine sahip birden çok kaynak oluşturulursa oluşabilecek çoğaltma gecikmesi riskini de azaltır. Azure aboneliği hizmet sınırları hakkında daha fazla bilgi edinin. |
| Çoğaltılan kaynaklar/uygulamalar | Kullanıcı tarafından atanan kimlik | Aynı görevi yerine getiren kaynaklar (örneğin, yinelenen web sunucuları veya bir uygulama hizmetinde ve sanal makinedeki bir uygulamada çalışan aynı işlevler) genellikle aynı izinleri gerektirir. Aynı kullanıcı tarafından atanan kimlik kullanıldığında, yönetim ek yükünü azaltan daha az rol ataması gerekir. Kaynakların aynı türde olması gerekmez. |
| Uyumluluk | Kullanıcı tarafından atanan kimlik | Kuruluşunuz tüm kimlik oluşturma işlemlerinin bir onay işleminden geçmesi gerekiyorsa, birden çok kaynakta kullanıcı tarafından atanan tek bir kimlik kullanmak, yeni kaynaklar oluşturulduktan sonra oluşturulan sistem tarafından atanan Kimliklerden daha az onay gerektirir. |
| Kaynak dağıtılmadan önce erişim gerekiyor | Kullanıcı tarafından atanan kimlik | Bazı kaynaklar, dağıtımlarının bir parçası olarak belirli Azure kaynaklarına erişim gerektirebilir. Bu durumda, sistem tarafından atanan bir kimlik zamanında oluşturulamayabilir, bu nedenle önceden var olan bir kullanıcı tarafından atanan kimlik kullanılmalıdır. |
| Denetim Günlüğü | Sistem tarafından atanan kimlik | Hangi kaynağın hangi kimlik yerine eylem gerçekleştirdiğini günlüğe kaydetmeniz gerekiyorsa sistem tarafından atanan bir kimlik kullanın. |
| İzinler Yaşam Döngüsü Yönetimi | Sistem tarafından atanan kimlik | Kaynakla birlikte bir kaynağın izinlerinin de kaldırılmasını istiyorsanız, sistem tarafından atanan bir kimlik kullanın. |
Yönetimi azaltmak için kullanıcı tarafından atanan kimlikleri kullanma
Diyagramlar, birkaç sanal makinenin iki depolama hesabına erişmesine izin vermek için kullanıldığında sistem tarafından atanan ve kullanıcı tarafından atanan kimlikler arasındaki farkı gösterir.
Diyagramda sistem tarafından atanan kimliklere sahip dört sanal makine gösterilir. Her sanal makine, iki depolama hesabına erişim veren aynı rol atamalarına sahiptir.
Kullanıcı tarafından atanan bir kimlik dört sanal makineyle ilişkilendirildiğinde, sistem tarafından atanan kimliklerle sekize kıyasla yalnızca iki rol ataması gerekir. Sanal makinelerin kimliği daha fazla rol ataması gerektiriyorsa, bu kimlikle ilişkili tüm kaynaklara verilir.
Güvenlik grupları, gerekli rol atamalarının sayısını azaltmak için de kullanılabilir. Bu diyagramda, bir güvenlik grubuna eklenen sistem tarafından atanan kimliklere sahip dört sanal makine gösterilir ve rol atamaları sistem tarafından atanan kimlikler yerine gruba eklenir. Sonuç benzer olsa da, bu yapılandırma kullanıcı tarafından atanan kimliklerle aynı Resource Manager şablonu özelliklerini sunmaz.
Birden çok yönetilen kimlik
Yönetilen kimlikleri destekleyen kaynaklar hem sistem tarafından atanan bir kimliğe hem de kullanıcı tarafından atanan bir veya daha fazla kimliğe sahip olabilir.
Bu model hem paylaşılan kullanıcı tarafından atanan kimliği kullanma hem de gerektiğinde ayrıntılı izinler uygulama esnekliği sağlar.
Aşağıdaki örnekte, "Virtual Machine 3" ve "Virtual Machine 4", kimlik doğrulaması sırasında hangi kullanıcı tarafından atanan kimliği kullandıklarına bağlı olarak hem depolama hesaplarına hem de anahtar kasalarına erişebilir.
Aşağıdaki örnekte "Virtual Machine 4", kimlik doğrulaması sırasında kullanılan kimliğe bağlı olarak hem depolama hesaplarına hem de anahtar kasalarına erişim sağlayan kullanıcı tarafından atanan bir kimliğe sahiptir. Sistem tarafından atanan kimliğin rol atamaları bu sanal makineye özeldir.
Sınırlar
Yönetilen kimliklerin ve özel roller ile rol atamalarının sınırlarını görüntüleyin.
Erişim izni verirken en az ayrıcalık ilkesini izleyin
Yönetilen kimlik de dahil olmak üzere herhangi bir kimliğe hizmetlere erişim izinleri verildiğinde, istenen eylemleri gerçekleştirmek için her zaman gereken en düşük izinleri verin. Örneğin, yönetilen kimlik bir depolama hesabından verileri okumak için kullanılıyorsa, bu kimlik izinlerinin depolama hesabına veri yazmasına da izin vermeniz gerekmez. Örneğin, yönetilen kimliği gerekli olmadığında Azure aboneliğinde katkıda bulunan yapmak gibi ek izinler vermek, kimlikle ilişkili güvenlik patlama yarıçapını artırır. Kimlik güvenliğinin tehlikeye atılabilmesi için güvenlik patlama yarıçapını her zaman en aza indirmesi gerekir.
Yönetilen kimlikleri Azure kaynaklarına atamanın ve/veya kullanıcıya atama izinleri vermenin etkisini göz önünde bulundurun
Azure Logic App, Azure işlevi veya Sanal Makine gibi bir Azure kaynağı vb. yönetilen kimlik atanır, yönetilen kimliğe verilen tüm izinler artık Azure kaynağı tarafından kullanılabilir. Bu önemlidir çünkü kullanıcının bu kaynağa kod yükleme veya yürütme erişimi varsa, kullanıcının Azure kaynağıyla atanan/ilişkili tüm kimliklere erişimi olur. Yönetilen kimliğin amacı, geliştiricilerin söz konusu erişimi elde etmek için kimlik bilgilerini doğrudan işlemesine veya koda yerleştirmesine gerek kalmadan azure kaynağında çalışan kodlara diğer kaynaklara erişim vermektir.
Örneğin, yönetilen bir Kimliğe (ClientId = 1234) StorageAccount7755'e okuma/yazma erişimi verilmişse ve LogicApp3388'e atanmışsa, depolama hesabına doğrudan erişimi olmayan ancak LogicApp3388 içinde kod yürütme iznine sahip olan Alice, yönetilen kimliği kullanan kodu yürüterek StorageAccount7755'e de veri okuyabilir/yazabilir.
Benzer şekilde, Alice'in yönetilen kimliği kendisi atama izinleri varsa, bunu farklı bir Azure kaynağına atayabilir ve yönetilen kimlik için kullanılabilen tüm izinlere erişebilir.
Genel olarak, bir kullanıcıya kod yürütebilen (Mantıksal Uygulama gibi) ve yönetilen kimliğe sahip bir kaynağa yönetici erişimi verilirken, kullanıcıya atanan rolün kaynağa kod yükleyip yükleyebileceğini veya çalıştırabileceğini ve evet ise yalnızca kullanıcının gerçekten ihtiyacı varsa bu rolü atayın.
Bakım
Sistem tarafından atanan kimlikler, kaynak silindiğinde otomatik olarak silinirken, kullanıcı tarafından atanan kimliğin yaşam döngüsü ilişkili olduğu tüm kaynaklardan bağımsızdır.
Kullanıcı tarafından atanan bir kimliği artık gerekli olmadığında, kaynak ilişkilendirilmemiş olsa bile el ile silmeniz gerekir.
Sistem tarafından atanan veya kullanıcı tarafından atanan yönetilen kimlikler silindiğinde rol atamaları otomatik olarak silinmez. Abonelik başına rol ataması sınırının aşılmaması için bu rol atamaları el ile silinmelidir.
Silinen yönetilen kimliklerle ilişkili rol atamaları portalda görüntülendiğinde "Kimlik bulunamadı" ile görüntülenir. Daha fazla bilgi edinin.
Artık bir kullanıcı veya hizmet sorumlusuyla ilişkilendirilmemiş rol atamaları değeriyle ObjectType Unknowngörüntülenir. Bunları kaldırmak için, önce tüm rol atamalarını almak, yalnızca değeri Unknown olanlara ObjectType filtre uygulamak ve ardından bu rol atamalarını Azure'dan kaldırmak için çeşitli Azure PowerShell komutlarını bir araya getirebilirsiniz.
Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment
Yetkilendirme için yönetilen kimlikleri kullanma sınırlaması
Hizmetlere erişim vermek için Microsoft Entra ID gruplarını kullanmak, yetkilendirme sürecini basitleştirmenin harika bir yoludur. Bu basit bir fikirdir; bir gruba izinler verin ve aynı izinleri devralmaları için gruba kimlikler ekleyin. Bu, çeşitli şirket içi sistemlerden iyi oluşturulmuş bir desendir ve kimlikler kullanıcıları temsil ettiğinde iyi çalışır. Microsoft Entra Id'de yetkilendirmeyi denetlemek için bir diğer seçenek de, bir uygulamaya özgü rolleri (dizinde genel bir kavram olan gruplar yerine) bildirmenizi sağlayan Uygulama Rolleri'ni kullanmaktır. Daha sonra yönetilen kimliklere (kullanıcılar veya grupların yanı sıra) uygulama rolleri atayabilirsiniz.
Her iki durumda da, Microsoft Entra Uygulamaları ve Yönetilen kimlikler gibi insan olmayan kimlikler için, bu yetkilendirme bilgilerinin uygulamaya nasıl sunulduğuna ilişkin tam mekanizma bugün ideal değildir. Bugün Microsoft Entra Kimliği ve Azure Rol Tabanlı Erişim Denetimi (Azure RBAC) ile yapılan uygulamada, her kimliğin kimlik doğrulaması için Microsoft Entra Id tarafından verilen erişim belirteçleri kullanılır. Kimlik bir gruba veya role eklenirse, bu, Microsoft Entra Id tarafından verilen erişim belirtecinde talepler olarak ifade edilir. Azure RBAC, erişime izin vermek veya erişimi reddetmek için yetkilendirme kurallarını daha fazla değerlendirmek için bu talepleri kullanır.
Kimliğin grupları ve rolleri erişim belirtecindeki talepler olduğundan, belirteç yenilenene kadar yetkilendirme değişiklikleri geçerli olmaz. Genellikle sorun olmayan bir kullanıcı için, kullanıcı oturumu kapatıp tekrar açarak (veya belirteç ömrünün süresinin dolabilmesini beklediğinden ( varsayılan olarak 1 saattir) yeni bir erişim belirteci alabilir. Öte yandan yönetilen kimlik belirteçleri performans ve dayanıklılık amacıyla temel alınan Azure altyapısı tarafından önbelleğe alınır: yönetilen kimlikler için arka uç hizmetleri yaklaşık 24 saat boyunca kaynak URI'sine göre önbellek tutar. Bu, yönetilen kimliğin grubundaki veya rol üyeliğindeki değişikliklerin etkili olması birkaç saat sürebileceği anlamına gelir. Bugün, yönetilen kimliğin belirtecini süresi dolmadan önce yenilenmeye zorlamak mümkün değildir. İzin eklemek veya kaldırmak için yönetilen kimliğin grup veya rol üyeliğini değiştirirseniz, bu nedenle kimliği kullanan Azure kaynağının doğru erişime sahip olması için birkaç saat beklemeniz gerekebilir.
Bu gecikme gereksinimleriniz için kabul edilebilir değilse, belirteçte grupları veya rolleri kullanma alternatiflerini göz önünde bulundurun. Yönetilen kimliklere yönelik izinlerde yapılan değişikliklerin hızlı bir şekilde etkili olmasını sağlamak için, izinlere sahip bir Microsoft Entra grubuna ekleme veya kaldırma yerine, kullanıcı tarafından atanan yönetilen kimliği kullanarak Azure kaynaklarını doğrudan kimliğe uygulanan izinlerle gruplandırmanızı öneririz. Kullanıcı tarafından atanan yönetilen kimlik, kullanmak üzere bir veya daha fazla Azure kaynağına atanabildiğinden grup gibi kullanılabilir. Atama işlemi Yönetilen kimlik katkıda bulunanı ve Yönetilen kimlik işleci rolü kullanılarak denetlenebilir.