Azure’da RBAC, Policy ve Resource Lock Farkı: Üç Kontrol Birbirinin Yerine Geçmiyor
Azure RBAC, Azure Policy ve resource lock, Azure’da değişiklikleri engelleyebilen üç temel governance aracı. Benzer sonuçlar ürettikleri için sık sık birbirine karıştırılıyorlar. Oysa üçü birbirinin alternatifi değil. Her biri farklı bir katman oluşturuyor.
Bu üç kontrol, Azure’da her biri farklı bir soruya yanıt veriyor:
- Azure RBAC kimin işlem yapabileceğini belirliyor.
- Azure Policy hangi configuration’ların var olabileceğini belirliyor.
- Resource lock bir resource’un değiştirilip değiştirilemeyeceğini belirliyor.
Owner rolü bile her şeyi yapamıyor
En geniş yetkiye sahip Owner rolü de engellenebiliyor. RBAC, Owner’ı durdurmuyor. Ancak Azure Policy ve resource lock’lar, Owner rolündeki bir kullanıcının request’ini de reddedebiliyor.
Üç kontrol aynı resource group’a uygulanıp her biri tetiklendiğinde şu sonuçlar ortaya çıkıyor:
| Request | Engelleyen kontrol | HTTP status | Error code |
|---|---|---|---|
| Reader rolündeki kullanıcı resource oluşturmaya çalışıyor | Azure RBAC | 403 Forbidden | AuthorizationFailed |
| Owner, izin verilmeyen region’da resource oluşturuyor | Azure Policy | 403 Forbidden | RequestDisallowedByPolicy |
| Owner, lock’lu resource group’taki bir resource’u siliyor | Resource lock | 409 Conflict | ScopeLocked |
Bir request başarısız olduğunda error code, onu hangi kontrolün durdurduğunu ve neyin değiştirilmesi gerektiğini doğrudan gösteriyor. Azure PowerShell yalnızca HTTP status’u raporladığı için error code’u görmek için error details’in incelenmesi gerekiyor. Azure CLI ise error code’u doğrudan gösteriyor.
Policy mevcut resource’ları silmiyor
Azure Policy’deki Deny effect yalnızca yeni create ve update request’lerini engelliyor. Policy assignment yapılmadan önce yasaklı region’da oluşturulmuş bir storage account silinmiyor, yalnızca noncompliant olarak raporlanıyor. Yeni bir policy assignment’ın devreye girmesi yaklaşık beş dakika, role assignment’ların devreye girmesi ise 10 dakikaya kadar sürebiliyor.
Lock’lar veriyi korumuyor
Resource lock’larla ilgili iki önemli nokta var. Birincisi, ReadOnly lock beklenenden fazlasını engelleyebiliyor. Read gibi görünen bazı işlemler aslında POST request olduğu için bir storage account’un access key’lerini listelemek ya da resource group’taki virtual machine’leri başlatmak da engelleniyor. İkincisi, lock’lar yalnızca Azure Resource Manager üzerinden geçen control plane işlemlerini kapsıyor, data plane işlemlerini kapsamıyor. Lock’lu bir storage account’un kendisi silinemiyor ama içindeki blob, file, queue ve table’lar silinebiliyor. Veriyi korumak için RBAC data role’leri, soft delete ve backup kullanılması gerekiyor.
Öneri: Üçünü birlikte kullanın
RBAC kimin değişiklik yapabileceğini sınırlıyor, Azure Policy bu değişiklikleri standartlar içinde tutuyor, lock’lar da yanlışlıkla asla silinmemesi gereken kritik resource’ları koruyor. Production ortamlarında policy ve role’lerin tek bir resource group yerine management group veya subscription scope’unda atanması öneriliyor. Böylece bu ayarlar inheritance ile tüm alt resource’lara tutarlı biçimde uygulanıyor.
