Azure Otomasyonuyla Kendi Uyarlanabilir Saklama Politikalarınızı Oluşturun


Kendin Yap Uyarlanabilir Saklama Politikaları ile İleri Teknoloji Lisanslardan Kaçının

Microsoft 365 saklama ilkelerine yönelik uyarlanabilir kapsamları kapsayan son makalemde, saklama işlemine yönelik hesap kümesini tanımlamak için Azure AD özel özniteliklerinin nasıl kullanılacağını ele aldım. Kapsam sorgusu tarafından bulunan hesap kümesini değerlendirmek ve raporlamak çok uzun sürmesinin yanı sıra, uyarlanabilir kapsamlar iyi çalışır ve Microsoft Purview saklama işleminin bir yönetici tarafından sürekli güncelleştirmeler yapılmadan belirli hesap kümelerine otomatik olarak uygulanmasını sağlamanın iyi bir yoludur.

Uyarlanabilir kapsamların dezavantajı, Office 365 E5 veya Microsoft 365 E5 uyumluluk lisanslarına gereksinim duymalarıdır. Microsoft, belki de Office 365 kullanıcı büyümesinin yavaşlamasının bir sonucu olarak, bulut kullanıcı tabanından elde edilen gelir miktarını en üst düzeye çıkarmak istiyor. Sonuç olarak, özellikle uyumluluk alanında, otomatik işlemeyi içeren herhangi bir özelliğin genellikle üst düzey lisanslar gerektirmesidir.

Statik Saklama Politikaları

Statik kapsamlara sahip Microsoft 365 saklama ilkeleri, Office 365 E3 kiracıları tarafından kullanılabilir. Statik kapsam, yöneticilerin bir politika tarafından işlenen konumlar kümesini yönetmekten sorumlu olduğu anlamına gelir. Konum bir posta kutusu, site, grup, ekip veya OneDrive hesabı olabilir.

Saklama ilkesinin belirli bir türdeki tüm konumlara (tüm posta kutuları veya tüm siteler gibi) uygulanması durumunda olduğu gibi, bazen hiçbir yönetime gerek yoktur. Diğer durumlarda, bir politikada belirtilen statik konumlar kümesinin doğru olduğundan emin olmak büyük çaba gerektirebilir.

PowerShell ve Azure Otomasyonu Uyarlanabilir Saklama İlkeleri için Güncelleştirmeler Sağlıyor

Aklıma bir PowerShell betiği ve Azure Otomasyonu kombinasyonuyla bir tür kendin yap uyarlamalı tutma işlemi oluşturmanın mümkün olabileceği düşüncesi geldi. Bu kombinasyon, üst düzey lisanslara ihtiyaç duymadan uyarlanabilir kapsamların yaptıklarını kopyalıyor. Bu senaryoda PowerShell betiği:

  • Saklama ilkesinin işleneceği konum kümesini tanımlar. Uyarlanabilir kapsamlar bu bilgiyi bulmak için Azure AD'yi sorgular. Senaryomuz da aynısını yapabilir.
  • Kaldırılması gereken ve eklenmesi gereken konumları hesaplamak için saklama politikasında önceden belirtilen konumları kontrol eder.
  • Saklama politikasını yeni konumlarla günceller.

Azure Otomasyonu, bekletme ilkesindeki değişiklikleri algılamak ve uygulamak için betiği zamanlanmış bir şekilde çalıştırır. Exchange Online yönetim modülünün V3.0 tarafından yönetilen kimlikler için yakın zamanda eklenen destek, uyumluluk uç noktasında çalışan cmdlet'lerin bağlanmak için hala kimlik bilgileri gerektirmesine rağmen bu süreci kolaylaştırıyor (Microsoft bu sorunu düzeltmek için çalışıyor ve bir düzeltme yapılabilir) Bu makaleyi okuduğunuzda mevcut olacaktır).

Örnek Bir Uygulama

Sorumlunun çalıştığını kanıtlamak için bir Azure Otomasyon runbook'u (Azure Otomasyon ortamında çalıştırılacak bir betiğin sürümü) yazdım. Uyarlanabilir kapsamlar, kullanıcıları ve grupları veya SharePoint Çevrimiçi Sitelerini işleyebilir. Bu gösterim için komut dosyası, sorgu tarafından bulunan kullanıcı hesaplarının sahip olduğu Exchange Online posta kutularını ve OneDrive İş hesaplarını güncelleştirerek kullanıcı hesaplarını işler.

Başlamak için statik kapsama sahip yeni bir statik saklama ilkesi oluşturdum ve posta kutuları ile OneDrive hesapları için tek bir konum tanımladım (Şekil 1). Bu garip bir adım gibi görünse de, bunu yapmak ve politikayı mevcut tüm konumlarda hedeflememek önemlidir. Bir konum için Tümü'nün gösterildiği bir politika, tüm konumları arar ve işler. Örneğin, Tüm posta kutularını işlemeyi seçerseniz, politika tüm kullanıcı, paylaşılan ve etkin olmayan posta kutularını işler.

Microsoft Purview, bir iş yükü için tüm kullanılabilir konumları (tüm posta kutuları gibi) işlerken saklama ilkelerini farklı şekilde ele alır. Komut dosyası tarafından kullanılan Set-RetentionCompliancePolicy cmdlet'i, yalnızca politikanın seçilen konumları işleyecek şekilde ayarlanması durumunda konumları güncelleyebilir. Başka bir deyişle, Set-RetentionCompliancePolicy cmdlet'i bir politikada hepsi bir arada ve seçmeli işleme arasında geçiş yapamaz.

Senaryoyu Yazmak

Üzerinde çalışacağımız bir hedef politikasıyla devam edip işlenecek bazı posta kutuları ve OneDrive hesapları bulabiliriz. Komut dosyası şunları yapar:

  • Kiracının varsayılan etki alanını bulmak amacıyla Get-MgOrganization cmdlet'ini çalıştırmak için Microsoft Graph PowerShell SDK'sına yönetilen bir kimlikle bağlanır. Hedef OneDrive İş hesaplarının URL'lerini hesaplamak için buna ihtiyacımız var.
  • Yönetilen bir kimlikle Exchange Online'a bağlanın.
  • Azure Key Vault'ta depolanan hesap kimlik bilgilerini kullanarak uyumluluk uç noktasına bağlanın. Microsoft, uyumluluk cmdlet'lerini yönetilen kimlikleri kullanacak şekilde yükselttiğinde (veya sertifika tabanlı kimlik doğrulamayı düzelttiğinde) depolanan kimlik bilgilerinin kullanılmasına artık gerek kalmayacak.
  • SharePoint Online yönetim uç noktasına bağlanmak için aynı hesap kimlik bilgilerini kullanın.
  • Hedef posta kutuları kümesini bulun. Bu örnek, posta kutularını işaretlemek için önceki makalede olduğu gibi aynı özel özniteliği kullanır.
  • Kiracıda OneDrive İş hesapları kümesini bulun ve sahibin adını ve URL'sini bir karma tablosunda saklayın.
  • Her posta kutusunun kullanıcı asıl adını OneDrive karma tablosuna göre kontrol etmek için posta kutuları kümesinde dolaşın. Bir eşleşme bulunursa OneDrive hesabının posta kutusu sahibine ait olduğunu biliyoruz ve bu nedenle onu bir listede saklıyoruz.
  • Get-RetentionCompliancePolicy cmdlet'ini kullanarak politikadaki geçerli konumlar kümesini alın.
  • Geçerli konum kümesinde hangi posta kutularının olmadığını kontrol edin ve politikaya eklenecek posta kutularının bir listesini oluşturun. OneDrive hesapları için de aynısını yapın.
  • Herhangi bir posta kutusunun ve OneDrive hesabının politika kapsamında olup olmadığını, ancak olmaması gerektiğini kontrol edin. Herhangi bir yer bulursak, bunları politikadan kaldırılacak konumlar listesine ekleyin.
  • İlkede olması gereken konumları eklemek ve olmaması gerekenleri kaldırmak için Set-RetentionCompliancePolicy cmdlet'ini çağırın.
  • Artık politikanın kapsadığı konum kümesini bildirmek için Get-RetentionCompliancePolicy cmdlet'ini çağırın.

Microsoft'un bekletme politikalarına yönelik aktif kapsamları uygulamak için kullandığı kodu hiç görmedim, ancak bir politikanın kapsaması gereken konum kümesini belirlemek için hemen hemen aynı türde işlemlerin gerçekleştiğinden eminim. Microsoft kodunun benimkinden daha zarif ve hassas olduğundan eminim (ve PowerShell'de yazılmamıştır), ancak önemli olan, kodun uyarlanabilir kapsam ile aynı işi yapması ve çalışmasıdır.

Bir uyumluluk ilkesinin en fazla 1.000 ayrı posta kutusunu desteklediğini unutmayın. Daha da önemlisi, SharePoint Online siteleri ve OneDrive İş hesapları için sınır daha düşüktür (100). Üretimde kullanılan komut dosyalarına yönelik test ve hata işlemenin bu sınırlamaları karşılaması gerekir. Sınırları aşmak için, farklı posta kutusu, site ve hesap gruplarını hedefleyen, aynı saklama ayarlarına sahip birden çok politika oluşturabilirsiniz.

Active Directory için Siber Güvenlik Risk Yönetimi

Bu Siber Güvenlik Risk Yönetimi Çözümleri aracılığıyla AD saldırılarını nasıl önleyeceğinizi ve bu saldırılardan nasıl kurtulacağınızı keşfedin.

Komut Dosyasını Çalıştırma

Komut dosyasını GitHub'dan indirebilir ve kendiniz test edebilirsiniz. Betik Azure Otomasyonu'nda çalışır. Kodun kimlik doğrulama bölümünde yapılan bazı değişiklikler, kodun etkileşimli olarak çalışmasını sağlayacaktır.

Şekil 2, bir Azure Otomasyonu oturumunun test bölmesinde çalıştırıldıktan sonra betiğin sonuçlarını gösterir. Çıktı, posta kutularına eklenecek ve kaldırılacak nesne tanımlayıcılarını gösterirken URL'ler OneDrive İş hesapları için kullanılır. Bunlar dahili olarak konumları tanımlamak için kullanılan değerlerdir. İsterseniz çıktıları hesap adlarını gösterecek şekilde değiştirmek kolay olacaktır. Ancak betik zamanlanmış bir Azure Otomasyonu görevi olarak çalıştığından, bir şeyler ters gitmedikçe muhtemelen hiç kimse çıktıya bakmayacaktır.

Şekil 3, komut dosyası çalıştırıldıktan sonra saklama ilkesinin özelliklerini göstermektedir. Daha önce hem Exchange Online hem de OneDrive for Business için tek bir konum belirtilirken, politika artık 24 posta kutusunu ve 23 hesabı kapsıyor. İki sayı arasındaki tutarsızlık, henüz OneDrive'da oturum açmamış yeni bir hesaptan kaynaklanmaktadır.

Burada açıklanan aynı prensip, Microsoft 365 Grupları veya SharePoint Online siteleri için uyarlanabilir bir saklama ilkesi oluşturacak şekilde genişletilebilir. Bu sadece PowerShell programlama meselesi.

Kendin Yap Her Zaman Mümkün Değil

Bir Microsoft 365 özelliğini DIY koduyla yeniden oluşturmak her zaman mümkün değildir. Bu durumda, uyarlanabilir saklama işleminin özel bir biçimini oluşturmak oldukça basittir. PowerShell ve Azure Otomasyonu kombinasyonu, Microsoft'un uyarlanabilir kapsamlarda sunduklarını etkili bir şekilde çoğaltır.

İlgili makaleler