Exchange Server’da İzin ve Rol Tabanlı Erişim Kontrolü

Yazar:komut.io ekibi Exchange Server Kurulum ve Yönetimi
0 Yorum

Yıllar içinde Exchange ortamlarında yaptığım en büyük hatalardan biri, küçük bir organizasyonda “herkes admin olsun, kolaylaşır” mantığıyla gitmekti. İki ay sonra bir kullanıcı yanlışlıkla tüm şirketin dağıtım gruplarını silmişti. O günden sonra rol tabanlı erişim kontrolü benim için bir tercih değil, zorunluluk haline geldi. Exchange Server’ın RBAC (Role-Based Access Control) modeli doğru kurgulandığında hem güvenliği hem de operasyonel verimliliği ciddi ölçüde artırıyor.

Exchange RBAC Mimarisini Anlamak

Exchange Server 2013 ile birlikte olgunlaşan RBAC modeli, üç temel bileşen üzerine kuruludur: Management Roles, Role Groups ve Role Assignment Policies. Bu üçlüyü anlamadan Exchange izin yönetimine girişmek, sonunda başını ağrıtır.

Management Roles, belirli cmdlet’lerin ve parametrelerin kullanım iznini tanımlar. Örneğin Mail Recipients rolü, posta kutusu oluşturma, değiştirme ve silme işlemlerine izin verir. Exchange’de 70’ten fazla yerleşik management role mevcuttur.

Role Groups, birden fazla Management Role’ü bir araya getiren gruplardır. Bir kullanıcıyı Role Group’a eklediğinizde o gruptaki tüm rollerin izinleri o kullanıcıya atanmış olur. Organization Management, Recipient Management, Help Desk gibi built-in gruplar burada devreye girer.

Role Assignment Policies ise son kullanıcıların kendi posta kutuları üzerinde ne yapabileceklerini belirler. Örneğin kullanıcının kendi telefon numarasını güncelleyip güncelleyemeyeceği, dağıtım grubuna kendiliğinden üye olup olamayacağı bu politikalarla kontrol edilir.

Mevcut rol yapısını görmek için Exchange Management Shell’i açın:

# Tüm Management Role Groups listesi
Get-RoleGroup | Select-Object Name, Description | Format-List

# Belirli bir role grubunun üyelerini görme
Get-RoleGroupMember -Identity "Organization Management"

# Sistemdeki tüm Management Roles
Get-ManagementRole | Select-Object Name, RoleType | Sort-Object Name

Built-in Role Group’ları ve Gerçek Dünya Kullanımları

Exchange’in hazır gelen role gruplarını doğru kullanmak, custom yapılar oluşturmadan önce yapılması gereken ilk adımdır. Çoğu zaman organizasyonların ihtiyaçlarının yüzde seksenini bu yerleşik gruplar karşılar.

Organization Management: En yetkili grup. Exchange ortamının her şeyine erişim sağlar. Buraya sadece Exchange mimarları ve kıdemli yöneticiler girmeli. Günlük operasyon için kullanmayın.

Recipient Management: Posta kutusu yönetimi, dağıtım grubu işlemleri, mail contact işlemleri. Help desk’in üst seviyesi veya Exchange operatörleri için ideal.

Help Desk: Kullanıcı bilgilerini görüntüleme ve sınırlı düzenleme. Tier-1 destek ekibi için tasarlanmış.

View-Only Organization Management: Hiçbir şeyi değiştirme yetkisi olmadan her şeyi okuyabilir. Audit ekipleri, güvenlik analistleri için biçilmiş kaftan.

Records Management: Retention policy, journal kuralları gibi uyumluluk odaklı yapılandırmalar için.

# Bir kullanıcıyı Recipient Management grubuna eklemek
Add-RoleGroupMember -Identity "Recipient Management" -Member "ahmet.yilmaz"

# Kullanıcının hangi role gruplarında olduğunu kontrol etmek
Get-RoleGroup | Where-Object { 
    (Get-RoleGroupMember -Identity $_.Name | 
    Where-Object {$_.Name -eq "ahmet.yilmaz"}) 
} | Select-Object Name

# Bir kullanıcıyı role grubundan çıkarmak
Remove-RoleGroupMember -Identity "Help Desk" -Member "mehmet.kaya" -Confirm:$false

Özel Role Group Oluşturma

Şimdi işlerin gerçekten ilginçleştiği yere geldik. Bir müşterimde şöyle bir senaryo vardı: IT departmanının içinde sadece Office 365 migration’ından sorumlu iki kişi vardı. Bu kişilerin posta kutusu taşıma işlemleri yapabilmesi gerekiyordu ama posta kutusu silme veya organizasyon ayarlarını değiştirme yetkileri olmamalıydı. Built-in grupların hiçbiri tam olarak buna uymuyordu.

# Yeni custom role group oluşturma
New-RoleGroup -Name "Migration Operators" `
    -Description "Sadece posta kutusu migration islemleri icin yetki" `
    -Roles "Mailbox Import Export", "Move Mailboxes", "Mail Recipients" `
    -Members "ali.demir", "selin.arslan"

# Oluşturulan grubun detaylarını doğrulama
Get-RoleGroup -Identity "Migration Operators" | Format-List
Get-RoleGroupMember -Identity "Migration Operators"

Bir diğer yaygın senaryo: İnsan kaynakları departmanının sadece kendi OU’larındaki kullanıcıların posta kutularını yönetebilmesi. Burada Management Role Scope devreye giriyor. Scope, bir rolün etki alanını sınırlar.

# Belirli bir OU için custom scope oluşturma
New-ManagementScope -Name "HR Department Scope" `
    -RecipientRestrictionFilter {RecipientType -eq "UserMailbox" -and 
    Department -eq "Human Resources"}

# Bu scope ile role assignment oluşturma
New-ManagementRoleAssignment `
    -Name "HR-RecipientManagement" `
    -SecurityGroup "HR Admins" `
    -Role "Mail Recipients" `
    -CustomRecipientWriteScope "HR Department Scope"

Role Assignment Policy ile Son Kullanıcı İzinleri

Çoğu sysadmin’in gözden kaçırdığı alan burası. Son kullanıcılar kendi posta kutuları üzerinde bazı şeyleri yapabilmeli ama bazılarını yapmamalı. Bunu Role Assignment Policy ile yönetiyoruz.

Varsayılan olarak her posta kutusuna Default Role Assignment Policy atanır. Bu politika içinde MyBaseOptions, MyContactInformation, MyProfileInformation gibi self-service roller bulunur.

Bir bankacılık müşterisinde şöyle bir gereksinim geldi: Kullanıcılar kendi OOO (Out of Office) mesajlarını ayarlayabilmeli ama posta kutusu boyut limitlerini ve forwarding kurallarını kesinlikle değiştirememelidir.

# Mevcut default policy içeriğini görme
Get-RoleAssignmentPolicy "Default Role Assignment Policy" | 
    Select-Object -ExpandProperty AssignedRoles

# Kısıtlı kullanıcılar için yeni policy oluşturma
New-RoleAssignmentPolicy -Name "Restricted User Policy" `
    -Roles "MyBaseOptions", "MyProfileInformation"

# Belirli bir kullanıcıya bu policy'yi atama
Set-Mailbox -Identity "[email protected]" `
    -RoleAssignmentPolicy "Restricted User Policy"

# Toplu atama - belirli bir departmandaki herkese uygulama
Get-Mailbox -Filter {Department -eq "Call Center"} | 
    Set-Mailbox -RoleAssignmentPolicy "Restricted User Policy"

Split Permission Modeli

Büyük kurumsal ortamlarda, özellikle Active Directory ekibi ile Exchange ekibinin ayrı olduğu yapılarda, Split Permission modeli tercih edilir. Bu modelde Exchange adminleri AD objeleri üzerinde tam kontrol sahibi değildir; kullanıcı hesabı oluşturma ve silme işlemleri yine AD ekibine kalır.

Exchange’de iki tür split permission vardır: RBAC Split Permission ve Active Directory Split Permission. AD Split Permission daha kısıtlayıcıdır ve geri alması zahmetlidir, bu yüzden çoğu ortamda RBAC split permission tercih edilir.

# Mevcut permission modelini kontrol etme
Get-OrganizationConfig | Select-Object *Permission*

# RBAC Split Permission aktif etmek için
# Organization Management grubundan "Mail Recipient Creation" rolünü kaldır
Remove-ManagementRoleAssignment `
    -Identity "Mail Recipient Creation-Organization Management" `
    -Confirm:$false

# Security Group Creation and Membership rolünü de kaldır
Remove-ManagementRoleAssignment `
    -Identity "Security Group Creation and Membership-Organization Management" `
    -Confirm:$false

# Artık yalnızca bu rollere atanmış ayrı bir grup AD objesi oluşturabilir
New-RoleGroup -Name "AD-Exchange Liaison" `
    -Roles "Mail Recipient Creation", "Security Group Creation and Membership" `
    -Members "exchange.ad.admin"

Audit ve Logging: Kimin Ne Yaptığını İzlemek

İzin yapısını ne kadar iyi kurarsanız kurun, audit olmadan eksik kalır. Bir kullanıcının posta kutusuna kim baktı? Hangi admin hangi ayarı değiştirdi? Bu soruların cevabını Admin Audit Log verir.

# Admin Audit Log'u aktif etme (genellikle varsayılan açıktır)
Set-AdminAuditLogConfig -AdminAuditLogEnabled $true `
    -AdminAuditLogAgeLimit 90.00:00:00

# Son 7 günde yapılan tüm role group değişikliklerini görme
Search-AdminAuditLog `
    -Cmdlets "Add-RoleGroupMember","Remove-RoleGroupMember","New-RoleGroup" `
    -StartDate (Get-Date).AddDays(-7) `
    -EndDate (Get-Date) | 
    Select-Object Caller, CmdletName, RunDate, ObjectModified | 
    Format-List

# Belirli bir kullanıcının audit loglarını sorgulama
Search-AdminAuditLog `
    -Cmdlets "*Mailbox*" `
    -ObjectIds "[email protected]" `
    -StartDate (Get-Date).AddDays(-30) `
    -EndDate (Get-Date)

Mailbox audit logging ise farklı bir konu. Bu özellikle yasal zorunluluklar veya e-keşif süreçleri için kritik önem taşır.

# Tek bir posta kutusu için mailbox audit'i aktif etme
Set-Mailbox -Identity "[email protected]" `
    -AuditEnabled $true `
    -AuditOwner MailboxLogin, HardDelete, SoftDelete `
    -AuditDelegate SendAs, SendOnBehalf, Create, FolderBind `
    -AuditAdmin Copy, MessageBind, Move, SendAs

# Tüm posta kutularında toplu aktifleştirme
Get-Mailbox -ResultSize Unlimited | 
    Set-Mailbox -AuditEnabled $true

# Mailbox audit loglarını sorgulama
Search-MailboxAuditLog `
    -Identity "[email protected]" `
    -LogonTypes Admin, Delegate `
    -StartDate (Get-Date).AddDays(-14) `
    -EndDate (Get-Date) `
    -ResultSize 100 | 
    Select-Object Operation, LogonUserDisplayName, LastAccessed | 
    Format-Table

Sık Yapılan Hatalar ve Pratik Öneriler

Yıllar içinde gördüğüm en yaygın hataları paylaşmak istiyorum çünkü belgelerde bunları bulamazsınız.

Hata 1: Service account’ları Organization Management’a koymak. Bir uygulama Exchange’e bağlanıyor diye o servis hesabına tam admin yetkisi vermek tehlikelidir. Bunun yerine sadece o uygulamanın ihtiyaç duyduğu rolleri içeren bir scope ile custom assignment yapın.

Hata 2: Role Group değişikliklerini test ortamında denemeden production’a uygulamak. Özellikle scope kısıtlamaları bazen beklenmedik sonuçlar doğurabilir.

Hata 3: Distribution Group yönetimini unutmak. Exchange’de dağıtım gruplarının da kendine ait yönetim izinleri vardır.

# Dağıtım grubuna yönetici atama
Set-DistributionGroup -Identity "[email protected]" `
    -ManagedBy "[email protected]"

# Grup üyeliğini kimin değiştirebileceğini kontrol etme
Get-DistributionGroup -Identity "[email protected]" | 
    Select-Object Name, ManagedBy, MemberJoinRestriction, MemberDepartRestriction

# Bir kullanıcıya kendi sahip olduğu gruplara üye ekleme/çıkarma yetkisi
# Role Assignment Policy üzerinden MyDistributionGroups rolü eklenmeli
Set-RoleAssignmentPolicy "Default Role Assignment Policy" `
    -Roles @{Add="MyDistributionGroups"}

Hata 4: View-Only rolünün gücünü küçümsemek. Bazı organizasyonlar audit ekiplerine veya ITSM araçlarına gereksiz yazma izni veriyor. View-Only Organization Management çoğu izleme ve raporlama ihtiyacını karşılar.

# View-Only erişim için servis hesabı hazırlama
Add-RoleGroupMember -Identity "View-Only Organization Management" `
    -Member "svc-monitoring"

# Bu hesabın yetkilerini doğrulama
Get-ManagementRoleAssignment -RoleAssignee "svc-monitoring" -GetEffectiveUsers | 
    Select-Object Role, EffectiveUserName | Format-Table

Periyodik İzin Gözden Geçirmesi

En iyi kurgulanmış RBAC modeli bile zamanla çürür. Personel değişir, projeler biter, geçici erişimler kalıcı hale gelir. Bu nedenle en az üç ayda bir yapılması gereken bir permission review süreci oluşturmanızı öneririm.

# Tüm role group üyeliklerini tek bir raporda toplama
$report = @()
Get-RoleGroup | ForEach-Object {
    $groupName = $_.Name
    Get-RoleGroupMember -Identity $groupName | ForEach-Object {
        $report += [PSCustomObject]@{
            RoleGroup = $groupName
            Member    = $_.Name
            RecipientType = $_.RecipientType
        }
    }
}
$report | Export-Csv -Path "C:ReportsRoleGroupMembers_$(Get-Date -Format 'yyyyMMdd').csv" `
    -NoTypeInformation -Encoding UTF8

# Organization Management grubundaki kullanıcıları özellikle vurgula
$report | Where-Object {$_.RoleGroup -eq "Organization Management"} | 
    Format-Table -AutoSize

Bu raporu düzenli olarak alıp önceki dönemle karşılaştırmak, gizli kalmış yetki değişikliklerini gün yüzüne çıkarır. Bir keresinde bu yöntemle, ayrılmış bir çalışanın servis hesabının hâlâ Organization Management grubunda aktif olduğunu tespit ettim. Tam anlamıyla şans eseri bulundu, ama sistematik yapılsaydı çok daha erken fark edilirdi.

Sonuç

Exchange’de RBAC doğru uygulandığında hem güvenlik duruşunu güçlendirir hem de operasyonları kolaylaştırır. “En az ayrıcalık” prensibi burada sadece bir slogan değil, pratik bir zorunluluktur. Her role group üyeliği bilinçli bir kararın sonucu olmalı ve bu kararların audit izi tutulmalıdır.

Şunu net söyleyeyim: Exchange izin yönetimi bir kez yapılıp bırakılan bir konfigürasyon değil, sürekli bakım gerektiren bir süreçtir. Personel değişiklikleri, yeni projeler, organizasyonel yeniden yapılanmalar hepsi izin yapınızı etkiler. Quarterly review alışkanlığı edinin, her rol atamasını belgelendirin ve “geçici” erişimlere mutlaka bir bitiş tarihi koyun.

Role Assignment Policy’lerden split permission modeline, custom scope’lardan audit logging’e kadar anlattığım tüm bu yapılar birbiriyle entegre çalışır. Bunları izole ele almak yerine bütüncül bir erişim yönetimi stratejisinin parçaları olarak düşünün. O zaman hem uyumluluk gereksinimlerini karşılarsınız hem de bir güvenlik olayında neyin ne zaman kim tarafından yapıldığına dair net cevaplar verebilirsiniz.

Bir yanıt yazın

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