Microsoft Purview Portal ve Yetkilendirme, veri güvenliği ve uyum çalışmalarında kimlerin hangi işlemleri yapabileceğini belirleyen temel konulardan biridir. Bir politikanın yapılandırılması, bir iletişimin incelenmesi ve araştırma sonuçlarının dışarı aktarılması farklı sorumluluklar doğurur.

Önceki bölümde portalın temel yapısını ve lisanslama seçeneklerini ele aldık. Bu bölümde ise kullanım hakkından işlem yetkisine geçiyoruz: Hangi kullanıcı hangi çözümü yönetmeli, hangi içeriklere erişmeli ve bu erişim nasıl sınırlandırılmalıdır?

Purview’da yetkilendirme yalnızca menüleri görünür hale getirmek için yapılmaz. Kurumsal verilerin, çalışan iletişimlerinin ve inceleme içeriklerinin uygun kapsamda kullanılmasını sağlar.

Bu nedenle başlangıç noktası, kullanıcıya geniş bir yönetici rolü atamak yerine görevini ve erişim ihtiyacını açıkça tanımlamak olmalıdır.

Microsoft Purview Portal ve Yetkilendirme blog yazısı içinde aşağıda ki bilgileri paylaşmaktayız.

1. Portal Erişimi ile İçerik Erişimi Arasındaki Fark

Microsoft Purview portalı, farklı çözümlere ortak bir yönetim deneyimi üzerinden erişim sağlar. Kullanıcıların gördüğü çözüm kartları ve özellikler, izinlerine ve desteklenen abonelik kapsamına göre değişebilir. Microsoft Purview portalı hakkında

Ancak portalda oturum açılması, bütün politikaların yönetilebildiği veya bütün içeriklerin okunabildiği anlamına gelmez.

Örneğin bir kullanıcının raporları değerlendirmesi gerekebilir. Başka bir kullanıcı politika yapılandırabilir. Bir inceleyici ise yalnızca görevli olduğu inceleme kapsamındaki içeriklere erişebilir.

Bu ihtiyaçlar aynı yetkiyle karşılanmak zorunda değildir. Kurumun erişim planında aşağıdaki sorular ayrı değerlendirilmelidir:

  • Kullanıcı hangi çözümde çalışacak?
  • Hangi işlemleri gerçekleştirecek?
  • İçeriğin kendisini görmesi gerekiyor mu?
  • Hangi kullanıcıların veya veri kaynaklarının içeriğine erişecek?
  • Erişim ihtiyacı sürekli mi, belirli bir görevle mi sınırlı?

2. Rol, Rol Grubu ve Kullanıcı İlişkisi

Microsoft Purview, Role-Based Access Control — RBAC, yani rol tabanlı erişim kontrolü yaklaşımını kullanır.

Rol, belirli işlemleri gerçekleştirmek için izin sağlar. Rol grubu, görevlerin yürütülmesini destekleyen rolleri bir araya getirir. Kullanıcının rol grubuna üyeliği, ilgili izinlerin atanmasını sağlar.

Portalda rol grupları Settings > Roles and scopes > Role groups alanından yönetilir. Bu yönetim için uygun Role Management yetkisi gerekir. Microsoft Purview izinleri

Kurumsal açıdan rol seçimi, kişinin unvanından çok yapacağı işe dayanmalıdır. “BT yöneticisi” veya “uyum sorumlusu” ifadesi, hangi verilere erişileceğini tek başına açıklamaz.

Örneğin uyum ekibindeki bir kişinin kontrol kanıtlarını takip etmesi, çalışan iletişimlerini incelemesi gerektiği anlamına gelmez. Aynı şekilde teknik yönetim görevi, bütün hukuki incelemelere erişim ihtiyacını doğurmaz.

3. En Az Ayrıcalık Yaklaşımı

En az ayrıcalık — least privilege, kullanıcıya görevini yerine getirmek için gereken izinlerin verilmesidir. Microsoft da Purview erişim planında bu yaklaşımı ve Global Administrator kullanımının sınırlandırılmasını önerir. Erişim kontrolü yaklaşımı

Kurumun uygulamasında bu ilke üç soruya dönüştürülebilir:

  1. Bu izin hangi görev için gerekiyor?
  2. Görev daha dar bir izin kümesiyle yapılabilir mi?
  3. Görev sona erdiğinde erişim devam etmeli mi?

Yetki talebinin amacı ve kapsamı kaydedilirse sonraki gözden geçirmeler daha kolay yapılır. Özellikle hassas içeriklere erişim ve dışarı aktarma işlemleri için sorumlulukların açık olması gerekir.

Bu yaklaşımın iletişim gözetimindeki önemini Exchange Server Supervisory Review Güvenlik ve Yetkilendirme makalemizde ele almıştık.

4. Microsoft Entra Rolleri ile Purview Rol Grupları

Microsoft Entra yönetici rolleri ile Purview çözüm izinleri birlikte değerlendirilmelidir. Bir kullanıcının erişimi yalnızca son atanan rol grubundan oluşmayabilir.

Özellikle kapsamlandırılmış Purview atamalarının yanında daha geniş Entra rolleri bulunuyorsa, çakışan yeteneklerde Entra rolü öncelik kazanabilir. Bu durumda beklenen kapsam sınırı uygulanmayabilir. Rol önceliği ve kapsam davranışı

Kurumun erişim kontrolünde doğrudan atamalar kadar diğer yönetici rolleri ve grup üyelikleri de incelenmelidir.

Örneğin yalnızca belirli bir iş birimi için yetkilendirildiği düşünülen kullanıcının, başka bir atama nedeniyle kurum genelindeki verilere erişmesi mümkündür. Bu nedenle gerçek erişim, kullanıcının hesabıyla test edilmelidir.

5. Görevlerin Ayrılması Nasıl Planlanmalıdır?

Purview çalışmalarında politika yönetimi, içerik incelemesi, hukuki değerlendirme ve denetim farklı sorumluluklardır.

Aşağıdaki tablo, kurum için örnek bir görev dağılımını göstermektedir. Tablodaki ifadeler hazır Purview rol grubu adları değildir; teknik izinler ilgili çözümün rol yapısıyla ayrıca eşleştirilmelidir.

Görev Temel sorumluluk Erişim planında değerlendirilmesi gereken konu
Teknik yönetim Çözümü hazırlamak, politikaları yapılandırmak ve teknik işleyişi takip etmek Yapılandırma için gereken izinlerle içerik inceleme ihtiyacını ayrı değerlendirmek
İçerik incelemesi Yetkili kapsamdaki bulguları değerlendirmek ve gerekçeleri kaydetmek İlgili politika, vaka veya inceleme kapsamına erişimi doğrulamak
Hukuki değerlendirme İnceleme kapsamını, koruma ihtiyacını ve paylaşım kararlarını değerlendirmek Teknik arama, koruma ve dışarı aktarma görevlerinin kimler tarafından yürütüleceğini belirlemek
Uyum çalışmaları Kontrolleri, görevleri ve destekleyici kanıtları takip etmek Kontrol takibi için gereken erişimi diğer çözümlerdeki içerik erişiminden ayırmak
Denetim Süreci, değişiklikleri ve gerçekleştirilen işlemleri gözden geçirmek Görev için gerekli görüntüleme ve araştırma izinlerini belirlemek

Küçük kurumlarda aynı kişi birden fazla görev üstlenebilir. Böyle durumlarda da hangi işlemin hangi sorumlulukla yapıldığı ve kararların nasıl kontrol edildiği açık olmalıdır.

Operasyonel görev dağılımı için Supervisory Review Süreç ve Roller makalesindeki çerçeveden yararlanılabilir.

6. Communication Compliance Yetkileri

Communication Compliance’da politika yönetimi ile iletişim incelemesi farklı görevlerdir. Çözüm; Communication Compliance Admins, Communication Compliance Analysts ve Communication Compliance Investigators gibi görev odaklı rol grupları sunar.

İnceleme erişimi planlanırken ilgili rol izinlerinin yanında politika üzerindeki reviewer atamaları da değerlendirilmelidir. Communication Compliance yapılandırma ve izinleri

Kurumun önce hangi ekibin politika oluşturacağını ve hangi kişilerin bulguları değerlendireceğini belirlemesi gerekir. Sonrasında bu görevler teknik izinlere dönüştürülmelidir.

Örneğin müşteri iletişimlerini inceleyen kişinin bütün politikaları değiştirmesi gerekmeyebilir. İnceleme yapan kişinin bulguyu hangi koşullarda hukuk veya bilgi güvenliği ekibine aktaracağı da tanımlanmalıdır.

Supervisory Review yaklaşımının temelini Supervisory Review Nedir makalemizde açıklamıştık. Purview’da bu yaklaşımı uygularken süreç ile ürün izinleri birlikte ele alınmalıdır.

7. eDiscovery Yetkileri ve Vaka Erişimi

eDiscovery’de arama, önizleme, koruma, inceleme ve dışarı aktarma işlemleri farklı izinlerle ilişkilidir.

eDiscovery Manager ve eDiscovery Administrator ayrımı özellikle önemlidir. Administrator kapsamı, kurum genelindeki vakalara erişim gibi daha geniş yetenekler sağlar. Diğer kullanıcıların vaka görünürlüğünde ise üyelik ve ilgili izinler belirleyicidir. Güncel eDiscovery izinleri

Bu nedenle her hukuki inceleme için aynı geniş rol grubunun atanması yerine, kişinin yapacağı işlem ve erişeceği vaka belirlenmelidir.

Örneğin yalnızca inceleme içeriğini değerlendirecek bir kişinin bütün kaynaklarda yeni aramalar başlatması veya sonuçları dışarı aktarması gerekmeyebilir. Arama, inceleme ve dışarı aktarma sorumlulukları kurum ihtiyacına göre ayrılabilir.

İnceleme kapsamının süreç tarafını Supervisory Review Dava Yönetimi makalemizde ele almıştık. eDiscovery’nin kavramsal temeli için Exchange Server eDiscovery Nedir yazısı da başlangıç noktasıdır.

8. Sınıflandırma Bilgisi ile İçeriğin Kendisine Erişim

Bir içeriğin hassas veri içerdiğini bilmek ile o içeriği açıp okumak farklı ihtiyaçlardır.

Örneğin Content Explorer’da liste görünürlüğü ve içerik görüntüleme için ayrı izinler bulunmaktadır. Content Explorer List Viewer ile Content Explorer Content Viewer ayrımı, bu iki erişim düzeyini açıkça göstermektedir. Content Explorer izinleri

Kurumun yalnızca sınıflandırma dağılımını veya bulguların konumunu değerlendirmesi gereken kullanıcıya içerik okuma yetkisi vermesi her durumda gerekli olmayabilir.

Bu ayrım, veri sınıflandırma çalışmalarında da korunmalıdır. Raporlama ihtiyacı ile hassas belgelerin içeriğine erişim ihtiyacı ayrı kaydedilmelidir.

9. Administrative Units ile Kapsam Yönetimi

Administrative Units — Yönetim birimleri, desteklenen Purview çözümlerinde belirli kullanıcı ve gruplara yönelik yönetim kapsamı oluşturmayı destekler. Kullanılabilir işlevler çözüm bazında farklılık gösterebilir. Purview yönetim birimleri

Örneğin farklı bölgelerde çalışan bir kurum, ilgili ekiplerin sorumluluk alanlarını ayırmak isteyebilir. Ancak bir yönetim birimi oluşturulması, bütün Purview çözümlerinin aynı şekilde sınırlandırıldığı anlamına gelmez.

Kurumun kapsam planında şu konular doğrulanmalıdır:

  • İlgili çözüm kapsamlandırmayı destekliyor mu?
  • Hangi kullanıcılar ve kaynaklar bu kapsama dahil?
  • Kullanıcının başka atamalardan gelen geniş izinleri var mı?
  • Paylaşılan veri konumları nasıl değerlendiriliyor?
  • Kapsam dışında kalan verilere erişim engelleniyor mu?

Erişim testinde yalnızca görev alanındaki verinin görülebildiğine bakılmamalıdır. Görev alanı dışındaki verilere erişilemediği de kontrol edilmelidir.

10. Data Map ve Unified Catalog Yetkilendirmesi

Veri yönetişimi çözümlerinde platform yönetimi, veri varlıklarının düzenlenmesi ve kurumsal iş bağlamının yönetilmesi farklı izinler gerektirebilir. Data Map ve Unified Catalog için çözüm bazındaki rol yapısı ayrıca incelenmelidir. Veri yönetişimi rolleri ve izinleri

Kurum, veri sahipliği ve veri yönetişimi sorumluluklarını teknik yönetim görevlerinden ayırmalıdır.

Örneğin bir veri ürününün açıklamasını ve sahipliğini düzenleyen kişinin kaynak veri tabanındaki bütün kayıtları yönetmesi gerekmez. Katalogdaki erişim ile kaynak sistemdeki asıl veriye erişim ayrı değerlendirilmelidir.

Bu yapı, serimizin Data Map ve Unified Catalog bölümünde daha ayrıntılı ele alınacaktır.

11. Geçici Erişim ve Ayrıcalıklı Yetkiler

Bazı görevler sürekli erişim gerektirirken bazıları belirli bir inceleme veya bakım çalışmasıyla sınırlıdır.

Kurum, geçici görevlerde erişimin başlangıç ve bitiş koşullarını tanımlamalıdır. Microsoft Entra Privileged Identity Management — PIM, uygun grup senaryolarında gerektiğinde etkinleştirilen üyelik ve onay akışlarını destekleyebilir. PIM for Groups

Purview tarafında da desteklenen rol gruplarında süreli atamalar bulunur. Ancak bu destek bütün rol grupları için aynı değildir; eDiscovery Manager ve Administrator grupları ilgili otomatik sona erme özelliğinin istisnaları arasındadır. Purview geçici izinleri

Bu nedenle “geçici yetki verdik” ifadesi teknik olarak doğrulanmalıdır. Görev tamamlandığında erişimin kaldırılması veya yeniden onaylanması için sorumluluk belirlenmelidir.

12. Rol Ataması İçin Önerilen Uygulama Akışı

Kurumun rol atamalarında aşağıdaki sıra izlenebilir:

  1. Görevi tanımlamak: Kullanıcı hangi işlemleri yapacak?
  2. Veri kapsamını belirlemek: Hangi içeriklere ve kaynaklara erişmesi gerekiyor?
  3. İlgili çözümün izinlerini incelemek: Hazır rol grubu yeterli mi, daha dar bir kombinasyon gerekli mi?
  4. Mevcut erişimleri kontrol etmek: Diğer roller ve grup üyelikleri ek yetki sağlıyor mu?
  5. Atamayı gerçekleştirmek: Uygun yetkili hesapla rol üyeliğini düzenlemek.
  6. Gerçek erişimi test etmek: Gerekli işlemler yapılabiliyor mu, kapsam dışı işlemler engelleniyor mu?
  7. Atamayı kaydetmek: Amaç, kapsam, onaylayan kişi ve gözden geçirme tarihini belirtmek.

Grup üzerinden üyelik kullanılacaksa, ilgili çözümün desteklediği grup türü ayrıca kontrol edilmelidir. Her grup türünün her rol veya vaka üyeliğinde kullanılabileceği varsayılmamalıdır.

13. Erişim Sorunlarında Nereden Başlanmalıdır?

Bir kullanıcı beklenen işlemi yapamadığında, doğrudan geniş yönetici yetkisi vermek yerine sorunun kaynağı belirlenmelidir.

Öncelikle doğru kurumsal ortamda oturum açıldığı, gereken rol üyeliğinin bulunduğu ve varsa politika veya vaka atamasının yapıldığı kontrol edilmelidir. Lisans ve teknik ön koşullar da değerlendirmeye dahil edilmelidir.

Rol değişikliklerinin uygulanması anlık olmayabilir. Sorun araştırılırken atama zamanı, hata mesajı ve yapılmak istenen işlem kaydedilmelidir.

Kurumun hedefi, kullanıcının görevini yerine getirebilmesini sağlarken gereksiz içerik erişimi oluşturmamaktır. Sorun giderme amacıyla verilen ek yetkiler, çalışma tamamlandıktan sonra gözden geçirilmelidir.

14. Yetkilerin Yaşam Döngüsü Nasıl Yönetilmelidir?

Yetkilendirme, ilk kurulumla tamamlanan bir işlem değildir. Çalışanın görevi değişebilir, bir vaka kapanabilir veya inceleme sorumluluğu başka bir ekibe aktarılabilir.

Bu nedenle kurumun erişim gözden geçirmesi aşağıdaki değişiklikleri kapsamalıdır:

  • İşe giriş, görev değişikliği ve işten ayrılma.
  • Yeni politika veya vaka oluşturulması.
  • İnceleme kapsamının genişlemesi.
  • Geçici görevlerin tamamlanması.
  • Grup üyeliklerinin değişmesi.
  • Yeni çözüm veya veri kaynağının kullanıma alınması.

Rol üyeliklerinin yanında hassas içeriklere erişim ve dışarı aktarma işlemleri de kurumun denetim planında değerlendirilmelidir.

Denetim yaklaşımının temelini Exchange Server Audit Logging makalemizde, gözetim kayıtlarının önemini ise Supervisory Review Veri ve Denetim Boyutu bölümünde ele almıştık.

15. Yetkilendirmeden Veri Sınıflandırmaya

Exchange Server Compliance Management etiketi altındaki çalışmalarımızda olduğu gibi Purview kullanımında da teknik kontroller, sorumluluklar ve denetim süreçleri birlikte planlanmalıdır.

Doğru yetkilendirme, kullanıcının görevini yerine getirmesini sağlarken içerik erişimini ihtiyaç duyulan kapsamla sınırlar. Rol adı kadar gerçek erişimin, görev süresinin ve diğer atamalardan gelen izinlerin değerlendirilmesi gerekir.

Portal ve erişim hazırlığının ardından hangi verilerin hassas olduğunu, nasıl tanınacağını ve hangi sınıflandırma yaklaşımının kullanılacağını belirleyebiliriz.