PowerShell ile Exchange Online Verilerini İşlemek için Azure Otomasyonunu Kullanma


Runbook Bazı Durumlarda Yararlıdır

Güncelleme: Bu yazı artık biraz eski. Azure Otomasyonu artık RunAs hesaplarını desteklemiyor ve Exchange Online yönetimi PowerShell modülü artık yönetilen kimlikleri destekliyor.

Practical365.com makaleleri genellikle, ortak yönetim işlemlerini otomatikleştirmek için Microsoft 365 verileriyle çalışmanın ilkelerini gösteren PowerShell kodunu içerir. Bazen okuyucular kodu Azure Otomasyonu runbook'larıyla kullanmanın mümkün olup olmadığını soruyor. Klasik bir danışmanın yanıtı göz önüne alındığında, benim yanıtım "duruma göre değişir" olur. Bağımlılıklar arasında kodun ne yaptığı, ilgili PowerShell modülleri ve bir betiğin etkileşimli olup olmadığı yer alır. Sean McAvinue, Exchange Online aktarım kurallarında zamanlanmış bir sorumluluk reddi beyanının uygulanmasına ilişkin makalesinde temel bilgileri ele alıyor ancak ben süreç üzerinde çalışmak ve bir Azure otomasyon hesabının ve bazı runbook'ların nasıl oluşturulacağını belgelemek istedim. İşte şunu keşfettim.

Güncelleme: Exchange Online'ı Azure Otomasyonu ve Yönetilen Kimlikler ile kullanma hakkında daha fazla bilgi için bu makaleye bakın.

Azure Otomasyon Hesaplarının Rolü

Azure Otomasyonu, sanal makineleri kullanarak iş yürütme yeteneğidir. Azure Otomasyonunu kullanmak için bir Azure aboneliğiyle ilişkili bir Azure Otomasyonu hesabınızın olması gerekir (tükettiğiniz kaynakların ücretini ödemek için). Buna karşılık otomasyon hesabı, bir runbook'ta PowerShell betiğini çalıştırmak gibi iş yapmak için gereken kaynaklara erişim sağlamak amacıyla kimlik doğrulama için kullanılan bir Azure RunAs hesabını destekler. İşleri yoluna koymak için ben:

  • Otomasyon hesabı için kullanılacak aboneliğin Azure Sahibi rolüne sahip bir hesapla Azure portalında oturum açıldı.
  • Yeni bir otomasyon hesabı oluşturuldu. Bu noktada Azure aboneliğini belirtmeniz gerekiyor.
  • RunAs hesabı oluşturuldu. Bu, Azure AD'de kimlik doğrulama ve izinler için temel görevi gören bir uygulama ve hizmet sorumlusunun oluşturulmasıyla sonuçlanır. Azure, hizmet sorumlusunun bir yıl boyunca kimlik doğrulama için kullanabileceği bir X.509 sertifikası (hesaptaki bir sertifika varlığı) oluşturur (sertifika kolayca yenilenebilir). Şu anda Exchange Online, Azure yönetilen kimliklerini desteklemediğinden RunAs hesabının kullanılması alınacak yaklaşımdır. Son olarak AzureRunAsConnection adlı bir bağlantı varlığı kullanılabilir hale gelir. Bu varlığın nasıl kullanıldığını daha sonra göreceğiz.

RunAs hesabını oluşturduktan sonra, uygulama tanımlayıcısı ve hizmet sorumlusu nesne tanımlayıcısı için Azure tarafından bildirilen bilgileri kaydedin. PowerShell aracılığıyla izin atamak için bu ayrıntılara daha sonra ihtiyacımız olacak.

PowerShell için Microsoft Graph SDK'sıyla runbook'un nasıl kullanılacağı hakkında bilgi edinin.

Azure Otomasyonunda Exchange Online PowerShell'i Kullanma

Exchange Online, tüm Microsoft 365 iş yükleri arasında PowerShell için en eksiksiz desteğe sahiptir. Posta kutuları ve e-posta yönetiminin diğer özelliklerinin yanı sıra modül, Microsoft 365 gruplarını da kapsar ve uyumluluk uç noktasına başka bir oturum bağlarsanız bilgi yönetimini ve diğer uyumluluk çözümlerini yönetmek için cmdlet'ler içerir. Bu nedenle, Microsoft için Azure Otomasyonuna yönelik herhangi bir araştırmaya Exchange Online ile başlamak mantıklı olacaktır.

Microsoft Graph sorgularını çalıştırmak için PowerShell'i kullandıysanız kullanıcı ve diğer verilere erişmek için gerekli izinlere sahip olmak üzere bir uygulamayı kaydetmeniz gerektiğini biliyorsunuzdur. Çoğu durumda uygulamaların kullanıcı profillerini, grup bilgilerini okuma vb. görevleri gerçekleştirmek için uygulama izinlerini kullanması gerekir. Yöneticilerin, uygulamaların uygulama izinlerini kullanmasına izin vermesi gerekir.

Aynı şekilde, bir RunAs hesabının Exchange Online yönetim modülündeki cmdlet'leri kullanabilmesi için önce bir yöneticinin Exchange Online'a yönetim erişimi için izin vermesi gerekir. Bunu Azure AD yönetim merkezinin Kayıtlı Uygulamalar bölümünden üç adımda yapabilirsiniz:

  • RunAs hesabı için oluşturulan uygulamayı seçin (adı otomasyon hesabı artı ExoAutomationAccount_Y6LgjDYIfPnxmFzrqdbaClsnTD/gN4BNnVMywiju5hk= gibi rastgele bir dize olacaktır)
  • Office 365 Exchange Online API'sinden ExchangeManageAsApp iznini atayın.
  • Kuruluş için onay verin.

Şekil 1'de ExchangeManageAsApp izninin izin alınarak verildiği gösterilmektedir.

Ayrıca RunAs hesabının hizmet sorumlusunu Exchange Yöneticisi rolüne eklemeniz gerekir. Bunu Azure AD yönetim merkezinin Roller ve yöneticiler bölümünde yapabilirsiniz (Şekil 2).

Exchange Çevrimiçi Yönetim Modülünü İçe Aktarın

RunAs hesabının hizmet sorumlusu artık Exchange Online yöneticisi olarak hareket etmek için uygun izinlere sahiptir. Bir sonraki adım, otomasyon hesabının Exchange cmdlet'lerini kullanmasına izin vermektir. Azure Otomasyonunun belirli makinelere bağlı olmadığını, dolayısıyla otomasyon hesabı için paylaşılan bir kaynak olarak kullanılabilir hale getirmek amacıyla Exchange Online yönetim modülünü içe aktarmanız gerektiğini unutmayın. Azure Otomasyonu, Exchange cmdlet'lerini çağıran bir runbook yürüttüğünde modülü otomatik olarak yükler.

İlk olarak, paylaşılan kaynaklar bölümünde Modüller'i bulun (birçok modül önceden yüklenmiştir, ancak Exchange bunlardan biri değildir). Daha sonra Exchange Online yönetim modülünü bulmak için modül galerisine göz atın (Şekil 3). Modülü seçin, PowerShell çalışma zamanı sürümü için sürüm 5,1'i seçin ve ardından modülü içeri aktarın. Bu işlemin tamamlanması birkaç dakika sürecektir. İçe aktarmanın ne zaman biteceğini öğrenmek için modüller görünümünü yenileyebilirsiniz.

Azure AD, Teams ve SharePoint Online dahil olmak üzere diğer Microsoft 365 modülleri de galeride mevcuttur. Çoğu görev, birden fazla modülden cmdlet'ler gerektirir; bu nedenle, ne yapmak istediğinize bağlı olarak diğer modülleri içe aktarmanız gerekebilir.

Runbook Oluşturma ve Test Etme

Runbook'lar, Azure Otomasyonunun işleri tamamlamak için kullandığı şeydir. Bu örnekte runbook'u korumalı alanda çalıştırılmaya hazır eksiksiz bir PowerShell betiği olarak düşünebilirsiniz. Otomasyon hesabı için İşlem Otomasyonu bölümünün altında yeni runbook'lar oluşturursunuz. Azure, kişilerin tekniğe başlamasına yardımcı olmak için hesaba birkaç öğretici runbook yükler.

Bazı şeyleri test etmek için, grup silme olaylarını bildirmek üzere denetim günlüğünü tarayan bir komut dosyası aldım ve kodu yeni bir PowerShell runbook'a kopyaladım. Kopyalanan koddan önce, otomasyon bağlantısına (AzureRunAsConnection) bir oturum oluşturmak ve Exchange Online'a bağlanmak ve otomasyon bağlantısına sahip oturumu kullanan hesap için oluşturulan sertifika parmak izini kullanarak kimlik doğrulamak için bazı satırlar ekledim.

$Session = Get-AutomationConnection –Name AzureRunAsConnection
$Tenant = 'office365itpros.onmicrosoft.com'
Connect-ExchangeOnline –CertificateThumbprint $Session.CertificateThumbprint –AppId $Session.ApplicationID –ShowBanner:$false –Organization $Tenant

Otomasyon hesabımızın Exchange'i bir uygulama olarak yönetme iznine sahip olduğunu ve hizmet sorumlusunun Exchange yönetici rol grubunun bir üyesi olduğunu, dolayısıyla runbook'un kimliği doğrulandıktan sonra herhangi bir Exchange yönetim cmdlet'ini çalıştırabileceğini unutmayın.

PowerShell koduyla çalışmak için daha önce bir PowerShell ISE veya Cloud Shell düzenleyicisi kullandıysanız runbook düzenleyicisi size tanıdık gelecektir (Şekil 4). Kodu etkileşimli kullanımdan otomasyona aktarmak, tüm kullanıcı etkileşimi cmdlet'lerinin (Read-Host gibi) kaldırılmasını gerektirirken, Write-Output, Write-Host'un yerini alır. Kodun başsız bir sanal alanda çalıştığını, dolayısıyla kullanıcı etkileşimlerini dahil etmenin bir anlamı olmadığını unutmayın. Hazır olduğunuzda kodu kaydedin ve Test bölmesi simgesini tıklayın.

Test bölmesi, runbook'u yürütmenize ve kodunuzun çalışıp çalışmadığını kontrol etmenize olanak tanır. Başlamak için başlat'ı tıklayın. Azure Otomasyonu runbook'u sıraya koyar ve bir kaynak (korumalı alan makinesi) kullanılabilir olduğunda kod çalışır. Bir hata oluşana veya komut dosyası bitene kadar hiçbir şey görmezsiniz; bu noktada Test bölmesinde herhangi bir çıktı görüntülenir (Şekil 5).

Bir komut dosyasını kısa bir süre içinde birden çok kez çalıştırırsanız Exchange Online bağlantınızı kısıtlayabilir. Bu olduğunda sıra bir fincan kahve içmeye gelir. Kısma mekanizması birkaç dakika sonra devre dışı kalacak ve tekrar deneyebileceksiniz. Alternatif olarak, oturumu kapatmak için komut dosyanıza Disconnect-ExchangeOnline cmdlet'ini ekleyin.

Kodun çalıştığından emin olduktan sonra runbook'u yayımlayabilirsiniz (Şekil 4'te gösterildiği gibi kodu düzenlerken Yayımla simgesine tıklayın). Daha sonra, daha fazla geliştirme için runbook'un taslak bir sürümüne ve farklı şekillerde çalıştırılabilecek yayınlanmış bir sürümüne sahip olacaksınız. Örneğin, Azure Otomasyonunu, çalıştırmayı belirli bir tarih ve saatte bir kez yürütecek veya aralıklarla çalıştıracak şekilde zamanlayabilirsiniz.

Güvenlik ve Uyumluluk için Sertifika Tabanlı Kimlik Doğrulama

Şu ana kadarki açıklama ana Exchange Online yönetim modülündeki cmdlet'leri kapsamaktadır. Modül ayrıca Connect-IPPSSession cmdlet'i çalıştırıldıktan sonra kullanılabilen güvenlik ve uyumluluk cmdlet'lerini de içerir. Bu cmdlet'ler şu anda sertifika tabanlı kimlik doğrulamayı desteklemiyor ancak yakında desteklenecek. Microsoft 365 mesaj merkezi bildirimi MC316448'e (21 Ocak 2022) göre bu özelliğin Mart ayının başına kadar her yerde kullanılabilir olması bekleniyor.

Şimdilik güvenlik ve uyumluluk cmdlet'lerini kullanmak istiyorsanız otomasyon hesabına kullanıcı adı ve parola kimlik bilgisi ekleyebilirsiniz. Hesap, çok faktörlü kimlik doğrulamayı (MFA) kullanamaz ve bir Exchange yöneticisi olmalıdır. MFA'nın olmaması, bunu pek tercih edilmeyen bir yöntem haline getirir ancak Azure Otomasyonu'nun farklı kimlik bilgileri türlerini desteklediğini göstermeye yarar. Bu yöntemi, SharePoint Online yönetim modülü gibi sertifika tabanlı kimlik doğrulamayı desteklemeyen diğer modüllerle kullandım.

Bu kod, Otomasyon hesabında kimlik bilgisi olarak saklanan ve O365Password olarak adlandırılan, saklanan kullanıcı adına ve şifreye erişir ve kimlik bilgisini güvenlik ve uyumluluk uç noktasına bağlanmak için kullanır:

$O365Cred = Get-AutomationPSCredential -Name "O365Password"
Connect-IPPSSession -Credential $O365Cred

Grafik API'leriyle otomatikleştirme

Elbette, Exchange Online cmdlet'leri erişmek isteyebileceğiniz tüm verileri kapsamaz, ancak bir Microsoft Graph API'sinin kapsama ihtimali yüksektir. Örnek olarak, hizmet sorumluları için oturum açma bilgilerini raporlamak için kullanılan bir komut dosyasını aldım ve bunu bir runbook'a aktardım. Normalde, Graph API sorgularıyla etkileşim kurmak için bir komut dosyası yazdığınızda, kimlik doğrulaması yapmak ve bir erişim belirtecini döndürmek için kullanılan kayıtlı uygulamayı, kiracıyı ve uygulama sırrını (veya sertifikayı) tanımlayan bir giriş bölümü bulunur. Runbook kullandığınızda kayıtlı uygulama yerine otomasyon hesabını ve uygulama sırrı yerine sertifika parmak izini kullanırız. Bu nedenle, şu şekilde bağlanmak için normal giriş kısmını kodla değiştiriyoruz:

# Set up a connection
$Connection = Get-AutomationConnection -Name AzureRunAsConnection
# Get certificate from the automation account
$Certificate = Get-AutomationCertificate -Name AzureRunAsCertificate
# Get an access token using the Get-MsalToken cmdlet from the MSAL.PS Module
$GraphConnection = Get-MsalToken -ClientCertificate $Certificate -ClientId $Connection.ApplicationID -TenantId  $Connection.TenantID 
# Populate the headers for our Graph queries
$Header =  @{Authorization = "Bearer $($GraphConnection.AccessToken)"}

Bu kod, erişim belirteci almak için MSAL.PS (Microsoft Kimlik Doğrulama Kitaplığı) adlı bir modülü kullanır. Modül hakkında daha fazla bilgiyi buradan edinebilirsiniz.

RunAs hesabının hizmet sorumlusunun verilere erişim iznine ihtiyacı olduğunu unutmayın. Bu durumda, yöneticinin Directory.Read.All ve AuditLog.Read.Tüm uygulama izinleri için onay vermesi gerekir. Erişim belirteci, izinlerin mevcut olduğunu doğrular, böylece şunları çalıştırabiliriz:

$Uri = "https://graph.microsoft.com/beta/auditLogs/signIns?&`$filter=createdDateTime ge " + $StartDate + " and createdDateTime le " + $EndDate + " and signInEventTypes/any(z:z eq 'servicePrincipal')"
[array]$SpSignInData = Invoke-RestMethod -Method GET -Uri $Uri -ContentType "application/json" -Headers $Header

Bundan sonra, Graph sorgusunun döndürdüğü her şeyi işleyip raporlamak kalıyor. Şekil 6, verilerin Test bölmesinde nasıl göründüğünü gösterir.

İşletmeler için Otomasyon

Benim bakış açıma göre Azure Otomasyon runbook'larının en iyi kullanımı, Office 365 denetim günlüğünden günlük veri alıntıları almak ve bunları uzun süreli saklama için harici bir depoya yazmak gibi uzun süreler alması muhtemel işlerde büyük miktarda veriyi işlemek olacaktır. . Aslında bu bir kurumsal oyundur.

Hangi Microsoft 365 gruplarının sahibi olmadığını veya hangi takımların duyarlılık etiketlerinin eksik olduğunu kontrol etmek gibi diğer geçici yönetim prosedürlerinin, bir kuruluş bu kontrolleri düzenli aralıklarla yapmadığı sürece etkileşimli olarak yürütülmesi daha iyidir. Bu durumda runbook iyi bir seçimdir.

Hatırlanması gerekenler şunlardır:

  • Azure aboneliğine ihtiyacınız var. Veri miktarlarınız büyük olmadığı sürece fazla harcama yapmazsınız ancak yine de bir aboneliğinizin olması gerekir. Bu makalenin yazılması sırasında geliştirilen runbook'lara beş sent harcamayı başardım.
  • Komut dosyalarında hiçbir kullanıcı etkileşimi oluşmaz. Örneğin, kullanıcıdan bir işlemin devam etmesi gerektiğini onaylamasını isteyemezsiniz.
  • Runbook'lar korumalı alan makinelerinde yürütülür. İşleme sonuçlarını bir dosya olarak kaydetmek istiyorsanız, bunu bir ağ konumunda yapmanız gerekir. Aksi takdirde bir Teams kanalına e-posta gönderebilir veya mesaj gönderebilirsiniz.

Diğer teknolojilerde olduğu gibi deha, Azure Otomasyonunun güçlü yanlarından yararlanırken olumsuz yanlarını en aza indirmekte yatmaktadır. Her araç gibi, gerçek işi yapmak için bunları nasıl kullanacağınızı öğrendikten sonra muhtemelen bir veya iki runbook'u da kullanabilirsiniz. Exchange Online ve diğer Microsoft 365 PowerShell modülleri, Microsoft Graph API sorgularında olduğu gibi runbook'larda erişilebilir ve kullanılabilir olduğundan pek çok potansiyel mevcuttur. Bazı uygulamalar, denemeler ve yanılmalar, Azure Otomasyonu runbook'larının kiracı yönetimi araç setinizde kritik bir araç haline gelebilecek kadar güçlü olup olmadığını yakında ortaya çıkaracaktır.

İlgili makaleler