Microsoft Purview Data Lifecycle Management, kurumsal içeriğin ne kadar süre saklanacağını ve hangi koşullarda silineceğini yönetmeye yardımcı olur. Saklama politikaları ve saklama etiketleri, bu yaklaşımın temel mekanizmalarıdır.
Kurumlar her gün e-posta, belge ve mesaj üretir. Bu içeriklerin bir bölümü uzun süre korunmalıdır; bir bölümü ise iş değerini kaybettikten ve saklama gereksinimleri sona erdikten sonra silinmelidir.
Bütün verileri süresiz tutmak, yönetim ihtiyacını ortadan kaldırmaz. Gereksiz veri birikimi; erişim, araştırma, depolama ve güvenlik çalışmalarını zorlaştırabilir. Öte yandan ihtiyaç duyulan kayıtların erken silinmesi de iş sürekliliği ve inceleme süreçlerinde sorun oluşturabilir.
Önceki bölümlerde hassas verinin tanınmasını, korunmasını ve kullanımının DLP politikalarıyla yönetilmesini ele aldık. Bu bölümde ise verinin saklama ve silme yaşam döngüsüne odaklanacağız. Microsoft Purview Data Lifecycle Management makalesi içinde aşağıdaki bilgilere sahip olacaksınız.
1. Data Lifecycle Management Nedir?
Data Lifecycle Management — DLM, gerekli içeriğin korunmasını ve artık tutulması gerekmeyen içeriğin silinmesini destekleyen Purview yeteneklerini kapsar.
Saklama politikaları; Exchange Online, SharePoint, OneDrive ve Teams gibi desteklenen Microsoft 365 konumlarında uygulanabilir. İçerik belirli süreyle veya süresiz saklanabilir; yalnızca silme ya da saklama sonrasında silme yaklaşımı da yapılandırılabilir. Microsoft Purview Data Lifecycle Management
Kurum açısından temel kararlar şunlardır:
- Hangi içerikler yönetilecek?
- Saklama süresi hangi gerekçeye dayanacak?
- Süre hangi tarihten itibaren hesaplanacak?
- Süre sonunda hangi işlem uygulanacak?
- Başka bir koruma veya inceleme gereksinimi var mı?
Teknik politika, bu kararların uygulanmasına yardımcı olur. Saklama süresinin kurumsal ve hukuki gerekçesi ise ilgili iş birimleri tarafından belirlenmelidir.
2. Veri Yaşam Döngüsü Neden Yönetilmelidir?
Bir içeriğin oluşturulması, sürekli saklanması gerektiği anlamına gelmez. Benzer şekilde günlük kullanımın sona ermesi de içeriğin hemen silinebileceğini göstermez.
Örneğin geçici bir çalışma notuyla imzalanmış sözleşmenin saklama ihtiyacı farklıdır. Müşteri iletişimleri, personel belgeleri ve proje dosyaları da farklı gereksinimlere sahip olabilir.
Kurumun yaşam döngüsü yaklaşımı, bu içerik kategorilerini ve sorumluluklarını açıklamalıdır. Saklama süreleri yalnızca depolama alanını azaltmak amacıyla belirlenmemelidir.
Bu yönetim çerçevesinin Exchange tarafındaki temelini Exchange Server Messaging Records Management makalemizde ele almıştık.
3. Saklama ve Silme İçin Üç Temel Yaklaşım
Purview saklama yapılandırmasında üç temel sonuç hedeflenebilir:
- Yalnızca saklama: İçeriği belirlenen süre boyunca veya süresiz korumak.
- Yalnızca silme: Belirlenen süreyi dolduran içeriği silmek.
- Saklama ve ardından silme: İçeriği belirli süre koruduktan sonra silmek.
Yalnızca saklama seçeneğinde sürenin sona ermesi, içeriğin otomatik olarak silineceği anlamına gelmez. Bunun için uygun silme davranışının ayrıca yapılandırılması gerekir. Saklama politikaları ve etiketleri
Aşağıdaki tablo, yaklaşımların kurumsal anlamını özetlemektedir.
| Yaklaşım | Temel amaç | Değerlendirme noktası |
|---|---|---|
| Yalnızca saklama | Gerekli içeriğin kalıcı silinmesini belirlenen süre boyunca önlemek | Süre sonunda otomatik silme bekleniyorsa ayrıca yapılandırılmalıdır |
| Yalnızca silme | Belirlenen yaştaki içeriğin kaldırılmasını sağlamak | İçeriği süre boyunca koruyan bir saklama güvencesi sağlamaz |
| Saklama ve ardından silme | Koruma ve süre sonu silme kararlarını birlikte uygulamak | Diğer saklama ve koruma gereksinimleriyle etkileşim değerlendirilmelidir |
4. Retention Policy — Saklama Politikası
Saklama politikası, seçilen veri konumundaki içeriklere ortak yaşam döngüsü ayarları uygulamak için kullanılır.
Örneğin belirli posta kutularına veya SharePoint sitelerine aynı saklama yaklaşımı uygulanabilir. Kapsamın tamamı, seçili kaynaklar veya uygun koşullarda uyarlanabilir kapsamlar değerlendirilebilir. Saklama politikası oluşturma
Kurumun politika tasarımında yalnızca süreyi değil, dahil edilen ve hariç tutulan kaynakları da belirlemesi gerekir.
“Bütün proje belgelerini yönetmek” gibi bir hedef, belgelerin hangi sistemlerde bulunduğu açıklanmadan teknik yapılandırmaya dönüştürülemez. E-postalar, dosyalar ve sohbet mesajları ayrı konumlarda olabilir.
5. Retention Label — Saklama Etiketi
Saklama etiketi, yaşam döngüsü ayarlarının belge veya e-posta gibi öğeler seviyesinde uygulanmasını sağlar.
Aynı konumda bulunan farklı içerik türleri için farklı saklama gereksinimleri varsa etiket yaklaşımı değerlendirilebilir. Etiketler, desteklenen yöntemlerle kullanıcı tarafından veya otomatik olarak uygulanabilir. Politikalar ve etiketler arasındaki fark
Örneğin aynı çalışma alanında bulunan sözleşmeler ve geçici raporlar farklı sürelerle yönetilebilir.
Saklama etiketi oluşturulması, bütün ilgili içeriklerin kendiliğinden etiketlendiği anlamına gelmez. Yayımlama veya otomatik uygulama yöntemi, kapsam ve sonuçlar ayrıca doğrulanmalıdır.
Kayıt tanımlama ve elden çıkarma incelemesi gibi daha gelişmiş etiket yeteneklerini sonraki Records Management bölümünde ele alacağız.
6. Saklama Süresi Hangi Tarihten Başlar?
Bir sürenin belirlenmesi kadar başlangıç tarihinin seçilmesi de önemlidir.
Desteklenen içerik ve yapılandırmaya göre oluşturulma, son değiştirilme veya etiketlenme tarihi kullanılabilir. Olay temelli başlangıç ise ilgili Records Management yetenekleri kapsamında değerlendirilir. Bütün başlangıç seçenekleri her veri konumunda aynı şekilde kullanılamaz. Saklama süresi ayarları
Örneğin “beş yıl sakla” ifadesi, başlangıç noktası açıklanmadan yeterli değildir. Belgenin oluşturulmasından itibaren beş yıl ile etiketlenmesinden itibaren beş yıl farklı sonuçlar üretir.
Bu nedenle kurumun saklama çizelgesinde süre, başlangıç olayı ve süre sonu işlemi birlikte bulunmalıdır.
7. Kullanıcı İçeriği Silerse Ne Olur?
Saklama, kullanıcının içeriği normal çalışma alanından kaldırmasını her durumda engelleyen bir davranış değildir.
Saklama koşulları altında düzenlenen veya silinen içeriğin gerekli kopyası, ilgili hizmetin koruma mekanizmasıyla tutulabilir. Bu içerik normal kullanıcı görünümünde bulunmayabilir. Saklama mekanizmasının çalışma şekli
Exchange tarafında Recoverable Items alanı, saklama davranışının önemli parçalarından biridir. Politikanın etkisi posta kutusunun özellikleri ve diğer korumalarla birlikte değerlendirilmelidir. Exchange için saklama
Kurum, kullanıcı görünümünden kaldırılan içerikle kalıcı olarak silinen içeriği ayırmalıdır. Saklanan veriye erişim, yetkili inceleme süreci üzerinden yürütülebilir.
8. Teams Mesajları ile Dosyalarının Kapsamı
Teams içinde görülen bütün içerikler aynı veri konumunda tutulmaz.
Sohbet ve kanal mesajları için saklama ayarları değerlendirilirken, paylaşılan dosyaların bulunduğu SharePoint veya OneDrive kaynakları ayrıca kapsama alınmalıdır. Mesaj saklama politikası, dosyaların yaşam döngüsünü tek başına yönetmez. Teams için saklama
Örneğin bir mesajın saklanması, mesajdaki bağlantının işaret ettiği dosyanın da aynı süreyle korunacağı anlamına gelmez.
Kurumun “Teams verilerini saklıyoruz” ifadesi; mesajlar, dosyalar ve ilgili diğer içerik türleri için hangi kapsamın uygulandığını açıklamalıdır.
9. Birden Fazla Saklama Ayarı Çakışırsa
Aynı içerik birden fazla politika, etiket veya koruma gereksinimine tabi olabilir.
Standart saklama ilkelerinde, içeriği koruma gereksinimi silme isteğine göre önceliklidir. Birden fazla saklama gereksiniminde daha uzun süre etkili olabilir; açıkça uygulanan öğe ayarları ve silme kuralları için de ilgili öncelik ilkeleri değerlendirilir. Saklama öncelik ilkeleri
Bu nedenle sonuç, yalnızca son oluşturulan politika veya en kısa süre üzerinden hesaplanmamalıdır.
Kurumun yeni politika öncesinde mevcut ayarları çıkarması gerekir. Beklenen silmenin gerçekleşmemesi, başka bir saklama veya hukuki koruma gereksiniminden kaynaklanabilir.
10. Exchange MRM ile Purview Saklama Arasındaki Fark
Exchange Messaging Records Management — MRM politikaları ve etiketleri, posta kutusu içeriğinin yaşam döngüsünü yönetmek için kullanılır. Purview saklama politikaları ise desteklenen Microsoft 365 hizmetlerinde daha geniş bir kapsam sağlar.
Microsoft, yeni uyum saklama ihtiyaçlarında uygun Purview özelliklerinin değerlendirilmesini önerir. Ancak arşiv posta kutusuna taşıma gibi Exchange’e özgü ihtiyaçlar ayrıca ele alınmalıdır. Data Lifecycle Management ve Exchange özellikleri
Dolayısıyla Purview saklama politikasının oluşturulması, MRM’deki bütün işlemlerin birebir karşılandığı anlamına gelmez. Mevcut politikaların amacı ve yeni yapıdaki karşılığı ayrı değerlendirilmelidir.
MRM bileşenlerini Default Policy Tag ve Retention Policy Tags makalelerimizde ayrıntılandırmıştık.
11. Saklama, Arşivleme, Yedekleme ve Hukuki Koruma
Bu mekanizmalar farklı amaçlarla kullanılır:
- Saklama: İçeriğin yaşam döngüsünü ve kalıcı silinme koşullarını yönetir.
- Arşivleme: Uzun süreli kayıt yönetimi, erişim veya posta kutusu kapasitesi ihtiyaçlarını destekleyebilir.
- Yedekleme: Kurtarma ihtiyacına odaklanır.
- Hukuki koruma: Belirli bir inceleme için gerekli içeriğin korunmasını hedefler.
Purview saklama politikasının bulunması, bütün kurtarma ihtiyaçlarının karşılandığını göstermez. Aynı şekilde rutin saklama süresi, belirli bir davanın koruma kapsamını tek başına belirlemez.
Bu ayrımları Backup VS In-Place Archiving ve Supervisory Review Dava Yönetimi makalelerimizde ele almıştık.
12. Data Lifecycle Management ile Records Management
DLM, genel saklama ve silme ihtiyaçlarının yönetimine odaklanır. Records Management, kayıt niteliğindeki içerikler için daha ayrıntılı kontroller sağlar.
Kayıt olarak tanımlama, olay temelli saklama ve elden çıkarma incelemesi gibi yetenekler Records Management kapsamında değerlendirilir. İki alan saklama etiketleri gibi ortak mekanizmalardan yararlanabilir. Microsoft Purview Records Management
Örneğin günlük çalışma belgelerinin yaşam döngüsüyle resmi sözleşmelerin kayıt yönetimi aynı ayrıntı düzeyini gerektirmeyebilir.
Kurumun hangi içeriği kayıt olarak kabul ettiği, bu içeriğin kim tarafından yönetileceği ve süre sonunda nasıl değerlendirileceği açıkça tanımlanmalıdır.
13. Kurumlar İçin Uygulama Senaryoları
13.1 Genel E-posta İçeriği
Belirli posta kutuları için ortak bir saklama yaklaşımı uygulanabilir.
Öneri: Süre ve başlangıç tarihi, içerik türleri ve mevcut korumalarla birlikte değerlendirilmelidir. Bütün yazışmalar için tek bir süre kullanılacağı varsayılmamalıdır.
13.2 Proje Çalışma Alanları
Proje dosyaları, mesajları ve e-postaları farklı sistemlerde bulunabilir.
Öneri: Kaynaklar birlikte envanterlenmeli; her veri konumunun kapsamı ayrıca doğrulanmalıdır. Proje kapanışıyla başlayan gereksinimler varsa uygun olay temelli kayıt yönetimi yaklaşımı değerlendirilmelidir.
13.3 İşten Ayrılan Çalışanlar
Çalışanın ayrılması, bütün verilerin hemen silineceği anlamına gelmez. Posta kutusu ve dosya kaynaklarının yaşam döngüsü ayrı planlanmalıdır.
Öneri: Hesap kaldırma işlemlerinden önce saklama ihtiyacı ve ilgili hizmetin koşulları kontrol edilmelidir. Exchange Online’daki inactive mailbox yaklaşımı, gerekli koşulları sağlayan senaryolarda değerlendirilebilir. DLM kapsamındaki diğer yetenekler
13.4 İş Değerini Kaybetmiş İçerik
Geçici içeriklerin süresiz tutulması gereksiz veri birikimi oluşturabilir.
Öneri: Silme kapsamı kontrollü belirlenmeli; diğer koruma gereksinimleri ve kullanıcıya etkisi pilot çalışmada doğrulanmalıdır.
14. Silme Politikalarında Değişiklik Yönetimi
Silme davranışı geri dönüşü zor sonuçlar oluşturabilir. Bu nedenle kapsam, süre başlangıcı ve diğer politikalarla etkileşim uygulama öncesinde değerlendirilmelidir.
Özellikle geçmiş içerikler yeni politikaya dahil edildiğinde, bazı öğeler belirlenen süreyi zaten doldurmuş olabilir.
Politikanın uygulanması ve kalıcı silme işlemleri hizmetlerin işleme süreçlerine bağlıdır. Sürenin dolması, bütün içeriğin aynı anda silineceği anlamına gelmez. Saklama ve silme ayarları
DLP’deki simülasyon yaklaşımının bütün saklama politikalarında aynı biçimde bulunduğu varsayılmamalıdır. Test yöntemi, ilgili özelliğin desteklediği araçlar ve sınırlı kapsamlı uygulamalar üzerinden belirlenmelidir.
15. Başlangıç ve İşletim Planı
DLM çalışması için aşağıdaki sıra izlenebilir:
- İçerik kategorilerini belirlemek: Hangi kayıtlar ve çalışma içerikleri yönetilecek?
- Saklama gerekçelerini kaydetmek: Süreleri hangi iş ve uyum ihtiyaçları belirliyor?
- Kaynakları envanterlemek: E-posta, dosya ve mesajlar nerede bulunuyor?
- Politika veya etiket yaklaşımını seçmek: Ortak konum ayarı mı, öğe bazında ayrım mı gerekiyor?
- Başlangıç ve bitiş davranışını tanımlamak: Süre ne zaman başlayacak, sonunda ne olacak?
- Mevcut korumaları incelemek: Başka politika, etiket veya hukuki koruma var mı?
- Lisans ve yetkileri doğrulamak: Seçilen özellik için gereken koşullar karşılanıyor mu?
- Sınırlı kapsamda test etmek: Kullanıcı deneyimi ve teknik sonuçlar beklenenle uyumlu mu?
- Değişiklikleri gözden geçirmek: Yeni kaynaklar ve gereksinimler nasıl yönetilecek?
Kapsam genişledikçe depolama ve inceleme etkileri de değerlendirilmelidir. Saklanan içeriğin normal kullanıcı görünümünde bulunmaması, depolama etkisinin ortadan kalktığı anlamına gelmez.
16. Veri Yaşam Döngüsünden Kayıt Yönetimine
Exchange Server Compliance Management etiketi altındaki çalışmalarımızda olduğu gibi Purview yaşam döngüsü yönetimi de kurumsal kararların teknik kontrollerle uygulanmasına dayanır.
Doğru yaklaşım, hangi içeriğin neden saklanacağını ve hangi koşullarda silineceğini açıklamaktır. Politika kapsamı, süre başlangıcı ve diğer korumalarla etkileşim birlikte değerlendirilmelidir.
Bir sonraki bölümde bu çerçeveyi resmi ve yüksek değerli kayıtlar için daha ayrıntılı kontrol sağlayan Records Management yaklaşımıyla geliştireceğiz.
