Azure RBAC, Azure Policy resource lock, Azure’ 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ı katman oluşturuyor.
üç kontrol, Azure’ her biri farklı soruya yanıt veriyor:
- Azure RBAC kimin işlem yapabileceğini belirliyor.
- Azure Policy hangi configuration’ların var olabileceğini belirliyor.
- Resource lock resource’un değiştirilip değiştirilemeyeceğini belirliyor.
Owner rolü bile her şeyi yapamıyor
En geniş yetkiye sahip Owner rolü engellenebiliyor. Owner’ı durdurmuyor. Ancak Azure Policy resource lock’lar, Owner rolündeki kullanıcının request’ini reddedebiliyor.
Üç kontrol aynı resource group’a uygulanıp her biri tetiklendiğinde sonuçlar ortaya çıkıyor:
RequestEngelleyen kontrolHTTP statusError codeReader rolündeki kullanıcı resource oluşturmaya çalışıyorAzure RBAC403 ForbiddenAuthorizationFailedOwner, izin verilmeyen region’ resource oluşturuyorAzure Policy403 ForbiddenRequestDisallowedByPolicyOwner, lock’lu resource group’taki resource’u siliyorResource lock409 ConflictScopeLockedrequest başarısız olduğunda error code, onu hangi kontrolün durdurduğunu 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 update request’lerini engelliyor. Policy assignment yapılmadan önce yasaklı region’ oluşturulmuş storage account silinmiyor, yalnızca noncompliant olarak raporlanıyor. Yeni 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. Birincisi, ReadOnly lock beklenenden fazlasını engelleyebiliyor. Read gibi görünen bazı işlemler aslında POST request olduğu için storage account’un access key’lerini listelemek ya resource group’taki virtual machine’leri başlatmak 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 storage account’un kendisi silinemiyor ama içindeki blob, file, queue table’lar silinebiliyor. Veriyi korumak için RBAC data role’leri, soft delete backup kullanılması gerekiyor.
Öneri: Üçünü birlikte kullanın
RBAC kimin değişiklik yapabileceğini sınırlıyor, Azure Policy değişiklikleri standartlar içinde tutuyor, lock’lar yanlışlıkla asla silinmemesi gereken kritik resource’ları koruyor. Production ortamlarında policy role’lerin tek resource group yerine management group veya subscription scope’unda atanması öneriliyor. Böylece ayarlar inheritance tüm alt resource’lara tutarlı biçimde uygulanıyor.
konuyla ilgili forum tartışmaları- Kullanıcı değişikliği sonrası Azure Devops lisansı ne olur?
- Multi App Kiosk Autologin Sorunu
- Virus Scan Failed
- Intune Win32 uygulaması AzCopy yükleniyor ama 'Committing' aşamasında takılıyor
- Microsoft Azure Ortamında Radius Nasıl Kurulur?
- Lokal DC/AD'yi Microsoft Entrada platformuna taşıma
