Token Security uzmanları tarafından gerçekleştirilen kapsamlı bir araştırma, Microsoft Azure’un Role-Based Access Control (RBAC) mimarisinde kritik güvenlik zayıflıklarını ortaya çıkardı. Azure’un yetki yönetiminin omurgasını oluşturan RBAC sisteminde tespit edilen iki ana zafiyet – aşırı yetkili yerleşik roller ve VPN pre-shared key (PSK) sızdıran API tasarım hatası – kurumsal ağları ciddi riske atıyor. 10 adet yerleşik rolün */read yetkisiyle 9.618 farklı Azure aksiyonuna erişim sağladığı ve basit okuma yetkisiyle VPN anahtarlarının çalınabildiği keşfedildi. Microsoft, VPN açığını “Önemli” olarak sınıflandırıp düzeltirken, aşırı yetkili rolleri “düşük öncelikli” kabul ederek sadece dokümantasyon güncellemesiyle yetindi.
Azure RBAC Mimarisi ve Temel Sorun
RBAC Temelleri
Azure Role-Based Access Control, bulut platformunda yetki yönetiminin temelini oluşturur. Sistem, kullanıcılara, gruplara veya service principal’lara önceden tanımlanmış yetkiler içeren roller atanmasına olanak tanır. Bu roller farklı scope’larda uygulanabilir:
- Management Group Level: En geniş kapsam
- Subscription Level: Abonelik genelinde
- Resource Group Level: Kaynak grubu seviyesinde
- Resource Level: Spesifik kaynak bazında
Aşırı Yetkili Roller Problemi
Araştırma, hizmet-spesifik sınırlı erişim sağlaması beklenen 10 yerleşik rolün, aslında */read yetkisiyle donatıldığını ortaya koydu. Bu roller şunları içeriyor:
- Managed Applications Reader
- Log Analytics Reader
- Monitoring Reader
- Application Insights Component Contributor
- Application Insights Snapshot Debugger
- Monitoring Contributor
- Monitoring Metrics Publisher
- Workbook Contributor
- Workbook Reader
- Azure Connected Machine Resource Administrator
Teknik Analiz: */read Yetkisinin Kapsamı
*/read yetkisi, Azure’daki tüm kaynak türlerinde okuma erişimi sağlar. Bu, şu anlama gelir:
{
"Name": "Problematic Role Example",
"Actions": [
"*/read"
],
"NotActions": [],
"DataActions": [],
"NotDataActions": []
}
Bu basit tanım, 9.618 farklı Azure aksiyonuna erişim sağlar ve şunları kapsar:
- Storage Accounts: Tüm blob, queue, table metadata’sı
- Key Vaults: Vault yapılandırmaları (anahtarlar değil, ama yapı bilgisi)
- Virtual Machines: Konfigürasyonlar, network ayarları
- Databases: Connection string’ler, backup konfigürasyonları
- Automation Accounts: Runbook içerikleri, değişkenler
- App Services: Uygulama ayarları, deployment slot’ları
VPN Pre-Shared Key Sızdırma Zafiyeti
API Tasarım Hatası
Azure API’sinde tespit edilen ikinci kritik zafiyet, VPN Gateway pre-shared key’lerinin basit okuma yetkisiyle alınabilmesine olanak tanıyor. Normal şartlarda Azure, hassas operasyonları şu şekilde ayırır:
- GET İstekleri: Sadece okuma operasyonları için
- POST İstekleri: Hassas veri alımı ve değişiklik operasyonları için
Ancak VPN connection shared key alımı yanlışlıkla GET endpoint’i olarak implement edilmiş:
GET https://management.azure.com/subscriptions/{subscriptionId}/
resourceGroups/{resourceGroupName}/providers/Microsoft.Network/
connections/{connectionName}/sharedkey?api-version=2023-09-01
Authorization: Bearer {access_token}
Exploit Mekanizması
- Keşif Aşaması: Aşırı yetkili roller kullanılarak VPN Gateway’ler listelenir
- Connection Enumeration: Site-to-Site VPN bağlantıları tespit edilir
- Key Extraction: GET isteği ile PSK çalınır
- Rogue Connection: Çalınan PSK ile sahte VPN bağlantısı kurulur
Saldırı Zinciri ve Etki Analizi
Hibrit Ortam Saldırı Senaryosu
Token araştırmacıları, bu zafiyetlerin kombinasyonunun hibrit cloud ortamlarında nasıl kullanılabileceğini gösterdi:
graph TD
A[Compromised Identity] --> B[Over-Privileged Role Assignment]
B --> C[Azure Resource Enumeration]
C --> D[VPN Gateway Discovery]
D --> E[PSK Extraction via API]
E --> F[Rogue S2S VPN Connection]
F --> G[Access to VPC/On-Premises]
G --> H[Lateral Movement]
Gerçek Dünya Etkileri
1. Credential Harvesting
# Automation Account'lardan credential çalma örneği
$automationAccounts = Get-AzAutomationAccount
foreach ($account in $automationAccounts) {
$runbooks = Get-AzAutomationRunbook -AutomationAccountName $account.Name
# Runbook içeriklerinde hardcoded credential arama
}
2. Network Mapping
# Azure network yapısını haritalama
az network vnet list --query "[].{Name:name, Subnets:subnets[].name, AddressSpace:addressSpace.addressPrefixes}"
3. Backup Vault Reconnaissance
# Backup vault'ları ve içeriklerini listeleme
az backup vault list --query "[].{Name:name, Location:location}"
Tespit ve Önleme Stratejileri
Immediate Remediation Steps
1. Role Audit Script
# Aşırı yetkili rolleri tespit etme
$problematicRoles = @(
"Managed Applications Reader",
"Log Analytics Reader",
"Monitoring Reader"
# ... diğer roller
)
$assignments = Get-AzRoleAssignment | Where-Object {
$problematicRoles -contains $_.RoleDefinitionName
}
$assignments | Export-Csv -Path "risky_role_assignments.csv"
2. Custom Role Creation
{
"Name": "Limited Log Analytics Reader",
"Description": "Read-only access to Log Analytics workspaces only",
"Actions": [
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/read"
],
"NotActions": [],
"AssignableScopes": [
"/subscriptions/{subscription-id}/resourceGroups/{resource-group}"
]
}
3. VPN Key Access Monitoring
// Azure Activity Log KQL sorgusu
AzureActivity
| where OperationNameValue contains "Microsoft.Network/connections/sharedkey/read"
| project TimeGenerated, Caller, Resource, SubscriptionId
| order by TimeGenerated desc
Uzun Vadeli Güvenlik Stratejileri
1. Least Privilege Implementation
Her servis için minimal yetki prensibini uygulayın:
# Örnek: Log Analytics için özel rol
$role = New-Object Microsoft.Azure.Commands.Resources.Models.Authorization.PSRoleDefinition
$role.Name = "Custom-LogAnalytics-Reader"
$role.Description = "Minimal read access for Log Analytics"
$role.Actions = @(
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/*/read"
)
$role.AssignableScopes = @("/subscriptions/$subscriptionId/resourceGroups/$rgName")
New-AzRoleDefinition -Role $role
2. Scope Limitation
Rolleri mümkün olan en dar scope’ta atayın:
# Kötü Pratik - Subscription seviyesinde
az role assignment create --assignee user@company.com \
--role "Log Analytics Reader" \
--scope /subscriptions/{subscription-id}
# İyi Pratik - Resource seviyesinde
az role assignment create --assignee user@company.com \
--role "Custom-LogAnalytics-Reader" \
--scope /subscriptions/{id}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspace}
3. Continuous Monitoring
Azure Policy ile sürekli kontrol:
{
"mode": "All",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Authorization/roleAssignments"
},
{
"field": "Microsoft.Authorization/roleAssignments/roleDefinitionId",
"in": "[parameters('problematicRoleIds')]"
}
]
},
"then": {
"effect": "audit"
}
}
}
Microsoft’un Yanıtı ve Değerlendirme
Güvenlik Önceliklendirmesi
Microsoft’un yanıtı iki farklı yaklaşım sergiledi:
VPN PSK Sızdırma (CVE Atanmadı)
- Önem Derecesi: Important
- Çözüm: Özel yetki gereksinimi eklendi (
Microsoft.Network/connections/sharedKey/action) - Bug Bounty: $7,500
Aşırı Yetkili Roller
- Önem Derecesi: Low
- Çözüm: Sadece dokümantasyon güncellemesi
- Bug Bounty: Yok
Kritik Değerlendirme
Bu farklılaşmış yaklaşım, cloud güvenliğinde “by design” sorunların ciddiye alınmaması problemini gösteriyor. Aşırı yetkili roller:
- Reconnaissance için kritik bilgi sağlıyor
- Lateral movement için yol haritası sunuyor
- Privilege escalation için fırsat yaratıyor
Best Practices ve Gelecek Öneriler
Organizasyonel Seviye
1. Zero Trust Identity Model
├── Conditional Access Policies
├── Privileged Identity Management (PIM)
├── Just-In-Time (JIT) Access
└── Regular Access Reviews
2. Defense in Depth
- Network segmentation
- Private endpoints kullanımı
- Azure Firewall/NSG katmanları
- Application Gateway/WAF
3. Monitoring ve Detection
// Anormal rol ataması tespiti
let baseline = AzureActivity
| where TimeGenerated > ago(30d) and TimeGenerated < ago(1d)
| where OperationNameValue == "Microsoft.Authorization/roleAssignments/write"
| summarize BaselineCount = count() by Caller;
AzureActivity
| where TimeGenerated > ago(1d)
| where OperationNameValue == "Microsoft.Authorization/roleAssignments/write"
| join kind=leftouter baseline on Caller
| where BaselineCount < 5 or isempty(BaselineCount)
| project TimeGenerated, Caller, Properties_d
Teknik Seviye
1. Infrastructure as Code (IaC) Validation
# Azure Policy as Code örneği
- task: AzureCLI@2
inputs:
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
# Role assignment validation
az policy assignment create \
--name 'audit-problematic-roles' \
--policy '/providers/Microsoft.Authorization/policyDefinitions/{policy-id}' \
--scope '/subscriptions/{subscription-id}'
2. Automated Remediation
# Python ile otomatik düzeltme
from azure.mgmt.authorization import AuthorizationManagementClient
from azure.identity import DefaultAzureCredential
def remediate_overprivileged_roles(subscription_id):
credential = DefaultAzureCredential()
auth_client = AuthorizationManagementClient(credential, subscription_id)
problematic_roles = [
"Managed Applications Reader",
"Log Analytics Reader"
]
for assignment in auth_client.role_assignments.list():
role_def = auth_client.role_definitions.get_by_id(
assignment.role_definition_id
)
if role_def.role_name in problematic_roles:
# Log ve alert
print(f"Found problematic assignment: {assignment.principal_id}")
# Otomatik düzeltme veya onay süreci başlat
Sonuç
Azure RBAC sistemindeki bu güvenlik açıkları, cloud platformlarında “güvenli varsayılan” prensibinin ne kadar kritik olduğunu gösteriyor. Aşırı yetkili roller ve API tasarım hataları kombinasyonu, saldırganlar için kapsamlı bir saldırı yüzeyi yaratıyor.
Network güvenlik profesyonelleri için önemli çıkarımlar:
- Vendor güvenlik modellerine körü körüne güvenmeyin – Yerleşik roller bile aşırı yetki içerebilir
- Defense in depth – Tek bir güvenlik katmanı asla yeterli değildir
- Continuous audit – Yetki atamaları sürekli gözden geçirilmeli
- Custom controls – Organizasyon ihtiyaçlarına özel güvenlik kontrolleri geliştirilmeli
Cloud güvenliği paylaşımlı sorumluluk modelinde, bu olay müşteri tarafının da aktif güvenlik önlemleri alması gerektiğini bir kez daha kanıtlıyor. Microsoft’un farklılaştırılmış yanıtı, organizasyonların kendi güvenlik posture’larını sürekli değerlendirmelerinin önemini vurguluyor.
About the Author
