Azure RBAC ile Erişim Kontrolü: Rol Tabanlı Yetkilendirme Rehberi

Tarafındankomut
0 Comments

Bir Azure ortamında herkesin her şeye erişebildiği bir yapı düşünün. Geliştirici yanlışlıkla production veritabanını siliyor, stajyer kritik network ayarlarını değiştiriyor, muhasebeci subscription’daki tüm VM’leri kapatıyor. Bu kabus senaryosu, Azure RBAC (Role-Based Access Control) olmadan gerçekleşebilir. Bugün bu sistemi derinlemesine inceleyeceğiz ve gerçek dünya senaryolarıyla nasıl doğru yapılandıracağınızı göreceğiz.

Azure RBAC Nedir ve Neden Önemlidir

Azure RBAC, kiminin neye erişebileceğini granüler düzeyde kontrol etmenizi sağlayan bir yetkilendirme sistemidir. En az ayrıcalık prensibi (Principle of Least Privilege) üzerine kurulmuştur: bir kullanıcıya veya servise yalnızca işini yapması için gereken minimum yetki verilmelidir.

Klasik bir sysadmin hikayesi: Ekibinize yeni bir junior developer katıldı. “Geçici olarak” ona Contributor erişimi verdiniz. Altı ay sonra hala o yetkiyle dolaşıyor ve bir gün production resource group’undaki tüm diskleri yanlış betikle siliyor. RBAC’ı doğru yapılandırsaydınız bu olmayacaktı.

Azure RBAC üç temel kavram üzerine kuruludur:

  • Security Principal: Kimin erişeceği (kullanıcı, grup, service principal, managed identity)
  • Role Definition: Ne yapabileceği (izinler kümesi)
  • Scope: Nerede yapabileceği (management group, subscription, resource group, resource)

Azure RBAC’ın Mimarisi

Scope Hiyerarşisi

Azure’da scope hiyerarşisi yukarıdan aşağıya doğru miras alınır. Üst seviyede verilen bir rol, alt seviyelerde de geçerli olur:

  • Management Group: Birden fazla subscription’ı yönetmek için
  • Subscription: Tüm bir Azure aboneliği
  • Resource Group: Belirli bir kaynak grubu
  • Resource: Tek bir kaynak (VM, Storage Account vs.)

Bu hiyerarşiyi anlamak kritik önem taşır. Birinin Subscription seviyesinde Contributor olması, o subscription altındaki tüm resource group ve resource’larda da Contributor olduğu anlamına gelir.

Yerleşik Roller

Azure, yüzlerce yerleşik rol sunar. En sık kullanılanları:

  • Owner: Tam erişim ve başkalarına rol atama yetkisi
  • Contributor: Kaynak oluşturma ve yönetme, rol atama yok
  • Reader: Sadece okuma
  • User Access Administrator: Rol atama yönetimi, kaynak yönetimi yok
  • Virtual Machine Contributor: Sadece VM yönetimi
  • Storage Blob Data Contributor: Blob storage okuma/yazma/silme
  • Key Vault Secrets User: Key Vault’tan secret okuma

Temel Rol Atama İşlemleri

Azure CLI ile Rol Atama

En çok kullandığım yöntem Azure CLI. Hızlı, scriptable ve audit log’lar için ideal:

# Önce mevcut rol atamalarını listeleyelim
az role assignment list --all --output table

# Belirli bir kullanıcının rol atamalarını görüntüle
az role assignment list 
  --assignee "[email protected]" 
  --all 
  --output table

# Kullanıcıya resource group seviyesinde Reader rolü ata
az role assignment create 
  --assignee "[email protected]" 
  --role "Reader" 
  --scope "/subscriptions/{subscription-id}/resourceGroups/production-rg"

# Bir gruba Contributor rolü atama
az role assignment create 
  --assignee-object-id "group-object-id" 
  --assignee-principal-type Group 
  --role "Contributor" 
  --scope "/subscriptions/{subscription-id}/resourceGroups/dev-rg"

Mevcut Rolleri Keşfetme

# Tüm yerleşik rolleri listele
az role definition list --output table

# Belirli bir rol hakkında detaylı bilgi
az role definition list 
  --name "Virtual Machine Contributor" 
  --output json

# Belirli bir kaynak üzerindeki izinleri sorgula
az role definition list 
  --query "[?contains(roleName, 'Storage')]" 
  --output table

# Bir rolün tam izin listesini gör
az role definition list 
  --name "Contributor" 
  --query "[0].permissions[0].actions" 
  --output tsv

PowerShell ile Rol Yönetimi

Bazı ortamlarda PowerShell tercih ediliyor, özellikle Windows-heavy shop’larda:

# Az module ile bağlan
Connect-AzAccount

# Mevcut rol atamalarını listele
Get-AzRoleAssignment | Format-Table -AutoSize

# Belirli bir kullanıcının rollerini bul
Get-AzRoleAssignment -SignInName "[email protected]" | 
  Select-Object RoleDefinitionName, Scope

# Resource Group seviyesinde rol ata
New-AzRoleAssignment `
  -SignInName "[email protected]" `
  -RoleDefinitionName "Virtual Machine Contributor" `
  -ResourceGroupName "development-rg"

# Rol atamasını kaldır
Remove-AzRoleAssignment `
  -SignInName "[email protected]" `
  -RoleDefinitionName "Contributor" `
  -ResourceGroupName "production-rg"

Özel Rol Tanımları Oluşturma

Yerleşik roller çoğu zaman ya çok geniş ya da çok dar kalır. Gerçek dünyada genellikle özel roller oluşturmanız gerekir. Benim en sevdiğim konu bu, çünkü burada gerçek sysadmin yaratıcılığı devreye giriyor.

Senaryo: Database Operatörleri İçin Özel Rol

Diyelim ki bir ekibiniz var, sadece Azure SQL veritabanlarını yönetmesi gerekiyor ama başka hiçbir şeye dokunmamalı:

# Özel rol JSON dosyası oluştur
cat > db-operator-role.json << 'EOF'
{
  "Name": "Database Operator",
  "Description": "Azure SQL veritabanlarını yönetebilir, başka kaynaklara erişemez",
  "IsCustom": true,
  "Actions": [
    "Microsoft.Sql/servers/read",
    "Microsoft.Sql/servers/databases/read",
    "Microsoft.Sql/servers/databases/write",
    "Microsoft.Sql/servers/databases/delete",
    "Microsoft.Sql/servers/databases/backupLongTermRetentionPolicies/read",
    "Microsoft.Sql/servers/databases/backupLongTermRetentionPolicies/write",
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [
    "Microsoft.Sql/servers/databases/delete"
  ],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}"
  ]
}
EOF

# Özel rolü oluştur
az role definition create --role-definition db-operator-role.json

# Rolü doğrula
az role definition list --name "Database Operator" --output json

Senaryo: Read-Only Network Operatörü

Ağ ekibiniz var, sadece network kaynaklarını görmesi gerekiyor ama değişiklik yapmamalı:

cat > network-reader-role.json << 'EOF'
{
  "Name": "Network Reader Custom",
  "Description": "Tüm network kaynaklarını okuyabilir, değiştiremez",
  "IsCustom": true,
  "Actions": [
    "Microsoft.Network/*/read",
    "Microsoft.Resources/subscriptions/resourceGroups/read",
    "Microsoft.Resources/deployments/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}"
  ]
}
EOF

az role definition create --role-definition network-reader-role.json

# Özel rolü bir gruba ata
az role assignment create 
  --assignee-object-id "network-team-group-id" 
  --assignee-principal-type Group 
  --role "Network Reader Custom" 
  --scope "/subscriptions/{subscription-id}"

Service Principal ve Managed Identity ile RBAC

Modern cloud uygulamalarında en kritik nokta burasıdır. İnsan kullanıcılar kadar, uygulamaların ve servislerin erişim kontrolü de önemlidir.

Service Principal için Rol Atama

CI/CD pipeline’larınız için service principal kullanıyorsanız:

# Service principal oluştur
az ad sp create-for-rbac 
  --name "github-actions-sp" 
  --role "Contributor" 
  --scopes "/subscriptions/{subscription-id}/resourceGroups/staging-rg" 
  --sdk-auth

# Mevcut service principal'a ek rol ver
SP_OBJECT_ID=$(az ad sp show 
  --id "app-id-burada" 
  --query "id" 
  --output tsv)

az role assignment create 
  --assignee-object-id "$SP_OBJECT_ID" 
  --assignee-principal-type ServicePrincipal 
  --role "Storage Blob Data Contributor" 
  --scope "/subscriptions/{subscription-id}/resourceGroups/prod-rg/providers/Microsoft.Storage/storageAccounts/prodstorage001"

# Service principal'ın rol atamalarını kontrol et
az role assignment list 
  --assignee "app-id-burada" 
  --all 
  --output table

Managed Identity ile RBAC

Managed Identity, credential yönetimi derdini ortadan kaldırır. Bir VM’in Key Vault’a erişmesi gerekiyorsa:

# VM için System-assigned Managed Identity'yi etkinleştir
az vm identity assign 
  --name "production-vm-01" 
  --resource-group "production-rg"

# Managed Identity'nin object ID'sini al
IDENTITY_ID=$(az vm identity show 
  --name "production-vm-01" 
  --resource-group "production-rg" 
  --query "principalId" 
  --output tsv)

# Key Vault Secrets User rolünü ata
az role assignment create 
  --assignee-object-id "$IDENTITY_ID" 
  --assignee-principal-type ServicePrincipal 
  --role "Key Vault Secrets User" 
  --scope "/subscriptions/{subscription-id}/resourceGroups/production-rg/providers/Microsoft.KeyVault/vaults/prod-keyvault-01"

echo "Managed Identity Object ID: $IDENTITY_ID"
echo "Key Vault erişimi başarıyla yapılandırıldı"

Gerçek Dünya Senaryosu: Çok Katmanlı Organizasyon Yapısı

Orta ölçekli bir şirkette tipik bir yapıyı inceleyelim. Üç farklı ekibiniz var: geliştirme, test ve operasyon:

#!/bin/bash
# Organizasyon RBAC yapısını otomatik yapılandır

SUBSCRIPTION_ID="your-subscription-id"
SUBSCRIPTION_SCOPE="/subscriptions/$SUBSCRIPTION_ID"

# Resource Group'ları oluştur
az group create --name "rg-development" --location "westeurope"
az group create --name "rg-staging" --location "westeurope"  
az group create --name "rg-production" --location "westeurope"

# Development ekibi: Kendi RG'larında Contributor
az role assignment create 
  --assignee-object-id "dev-team-group-id" 
  --assignee-principal-type Group 
  --role "Contributor" 
  --scope "$SUBSCRIPTION_SCOPE/resourceGroups/rg-development"

# Development ekibi: Staging'de sadece Reader
az role assignment create 
  --assignee-object-id "dev-team-group-id" 
  --assignee-principal-type Group 
  --role "Reader" 
  --scope "$SUBSCRIPTION_SCOPE/resourceGroups/rg-staging"

# QA ekibi: Staging'de Contributor, Production'da Reader
az role assignment create 
  --assignee-object-id "qa-team-group-id" 
  --assignee-principal-type Group 
  --role "Contributor" 
  --scope "$SUBSCRIPTION_SCOPE/resourceGroups/rg-staging"

az role assignment create 
  --assignee-object-id "qa-team-group-id" 
  --assignee-principal-type Group 
  --role "Reader" 
  --scope "$SUBSCRIPTION_SCOPE/resourceGroups/rg-production"

# Ops ekibi: Production'da Contributor
az role assignment create 
  --assignee-object-id "ops-team-group-id" 
  --assignee-principal-type Group 
  --role "Contributor" 
  --scope "$SUBSCRIPTION_SCOPE/resourceGroups/rg-production"

# Herkes tüm subscription'ı okuyabilsin
az role assignment create 
  --assignee-object-id "all-staff-group-id" 
  --assignee-principal-type Group 
  --role "Reader" 
  --scope "$SUBSCRIPTION_SCOPE"

echo "RBAC yapılandırması tamamlandı!"

RBAC Denetimi ve Sorun Giderme

Rol atamalarınızın doğru çalışıp çalışmadığını doğrulamak ve sorunları tespit etmek için:

# Bir kullanıcının belirli bir kaynak üzerindeki etkin izinlerini kontrol et
az role assignment list 
  --assignee "[email protected]" 
  --scope "/subscriptions/{sub-id}/resourceGroups/production-rg" 
  --output table

# "Deny" atamaları kontrol et (bunlar override eder)
az role assignment list 
  --scope "/subscriptions/{sub-id}" 
  --query "[?roleDefinitionName=='deny']" 
  --output table

# Atık kalmış rol atamalarını bul (silinmiş kullanıcılar)
az role assignment list 
  --all 
  --query "[?principalType=='Unknown']" 
  --output table

# Atık atamaları temizle
ORPHANED_ASSIGNMENTS=$(az role assignment list 
  --all 
  --query "[?principalType=='Unknown'].id" 
  --output tsv)

for assignment_id in $ORPHANED_ASSIGNMENTS; do
  echo "Siliniyor: $assignment_id"
  az role assignment delete --ids "$assignment_id"
done

# Activity Log'dan RBAC değişikliklerini izle
az monitor activity-log list 
  --namespace "Microsoft.Authorization" 
  --offset 72h 
  --query "[].{Caller:caller, Operation:operationName.value, Time:eventTimestamp}" 
  --output table

Sık Yapılan Hatalar ve Kaçınılması Gerekenler

Yıllarca Azure ortamları yönetirken gördüğüm en yaygın RBAC hatalarını paylaşayım:

  • Owner yerine Contributor kullanın: Eğer birinin rol atama yetkisine ihtiyacı yoksa Owner vermeyin. Çoğu zaman Contributor yeterlidir.
  • Gruplara atama yapın, bireylere değil: Kullanıcı gelip gidebilir, gruplar kalır. Active Directory gruplarına atama yapmak yönetimi çok kolaylaştırır.
  • Subscription seviyesinde cömert olmayın: Mümkün olduğunca resource group veya resource seviyesinde atama yapın.
  • Inherited rolleri unutmayın: Üst scope’dan gelen roller görünmeyebilir, --all parametresini kullanın.
  • Service principal rollerini periyodik gözden geçirin: CI/CD pipeline service principal’larının yetkilerini altı ayda bir audit edin.
  • Custom rollerde NotActions’ı doğru kullanın: NotActions, Actions’dan çıkarma yapar, tamamen engelleme değildir. Gerçek engelleme için Azure Policy kullanın.

Azure Policy ile RBAC Kombinasyonu

RBAC’ı tek başına kullanmak yeterli değildir. Azure Policy ile birleştirdiğinizde gerçek güvenlik sağlarsınız:

# Belirli lokasyonlarda kaynak oluşturmayı kısıtlayan policy ata
az policy assignment create 
  --name "allowed-locations" 
  --display-name "İzin Verilen Lokasyonlar" 
  --scope "/subscriptions/{subscription-id}" 
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4f" 
  --params '{"listOfAllowedLocations":{"value":["westeurope","northeurope"]}}'

# Tag zorunluluğu policy'si
az policy assignment create 
  --name "require-owner-tag" 
  --display-name "Owner Tag Zorunlu" 
  --scope "/subscriptions/{subscription-id}/resourceGroups/production-rg" 
  --policy "2a0e14a6-b0a6-4fab-991a-187a4f81c498"

# Policy compliance durumunu kontrol et
az policy state list 
  --resource-group "production-rg" 
  --query "[?complianceState=='NonCompliant']" 
  --output table

Privileged Identity Management (PIM) ile RBAC

Üretim ortamlarında sürekli yüksek yetkili rol atamak yerine, PIM ile just-in-time erişim sağlayabilirsiniz. Bu özellikle kritik roller için altın standarttır:

  • Eligible Assignment: Kişi rolü aktive etmesi gerekiyor, her zaman aktif değil
  • Active Assignment: Geleneksel kalıcı atama
  • Time-bound Assignment: Belirli bir süre için atama

PIM’i programatik olarak yönetmek için:

# PIM ile uygun (eligible) rol atama
az rest 
  --method PUT 
  --url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/production-rg/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/{guid}?api-version=2022-04-01-preview" 
  --body '{
    "properties": {
      "principalId": "user-object-id",
      "roleDefinitionId": "/subscriptions/{sub-id}/providers/Microsoft.Authorization/roleDefinitions/{role-definition-id}",
      "requestType": "AdminAssign",
      "scheduleInfo": {
        "expiration": {
          "type": "AfterDuration",
          "duration": "P90D"
        }
      }
    }
  }'

RBAC Audit Script’i

Periyodik audit için kullandığım basit ama etkili bir script:

#!/bin/bash
# azure-rbac-audit.sh
# Aylık RBAC audit raporu oluşturur

REPORT_DATE=$(date +%Y%m%d)
REPORT_FILE="rbac-audit-$REPORT_DATE.txt"

echo "=== Azure RBAC Audit Raporu ===" > "$REPORT_FILE"
echo "Tarih: $(date)" >> "$REPORT_FILE"
echo "" >> "$REPORT_FILE"

echo "## Subscription Seviyesi Rol Atamaları" >> "$REPORT_FILE"
az role assignment list 
  --scope "/subscriptions/{subscription-id}" 
  --query "[].{Principal:principalName, Role:roleDefinitionName, Type:principalType}" 
  --output table >> "$REPORT_FILE"

echo "" >> "$REPORT_FILE"
echo "## Owner Rolüne Sahip Kullanıcılar" >> "$REPORT_FILE"
az role assignment list 
  --all 
  --query "[?roleDefinitionName=='Owner'].{Principal:principalName, Scope:scope}" 
  --output table >> "$REPORT_FILE"

echo "" >> "$REPORT_FILE"
echo "## Silinmiş Principal Atamaları (Orphaned)" >> "$REPORT_FILE"
az role assignment list 
  --all 
  --query "[?principalType=='Unknown'].{AssignmentId:id, Scope:scope}" 
  --output table >> "$REPORT_FILE"

echo "" >> "$REPORT_FILE"
echo "## Özel Rol Tanımları" >> "$REPORT_FILE"
az role definition list 
  --custom-role-only true 
  --query "[].{Name:roleName, Description:description}" 
  --output table >> "$REPORT_FILE"

echo "Audit raporu oluşturuldu: $REPORT_FILE"
cat "$REPORT_FILE"

Sonuç

Azure RBAC, bulut güvenliğinin temel taşıdır. Doğru yapılandırıldığında hem güvenliği sağlar hem de ekibinizin verimliliğini artırır. Yanlış yapılandırıldığında ya ekipler işlerini yapamaz hale gelir ya da güvenlik açıkları oluşur. Her iki durum da sysadmin’in baş ağrısıdır.

Pratik önerim şudur: Her şeyi gruplar üzerinden yönetin, bireysel kullanıcılara doğrudan atama yapmaktan kaçının. Production ortamları için PIM kullanın ve just-in-time erişimi benimseyin. Altı ayda bir RBAC audit script’inizle orphaned atamaları ve gereksiz Owner rollerini temizleyin. Custom roller oluştururken fazla granüler olmaktan kaçının, ama yerleşik rollerin çok geniş kaldığı durumlarda tereddüt etmeden özel rol tanımı yapın.

RBAC bir kez yapıp unutulacak bir şey değildir. Organizasyonunuz büyüdükçe, yeni projeler ekledikçe ve ekip yapısı değiştikçe periyodik olarak gözden geçirilmesi gereken, yaşayan bir sistem olarak düşünülmelidir. Bu anlayışla yaklaştığınızda Azure ortamınız hem güvenli hem de yönetilebilir olmaya devam edecektir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir