21 Aralık günü MsHowto Bilişim Topluluğu tarafından düzenlenen etkinlikte "Windows Admin Center ve Azure Yönetimi" isimli sunum ile büyük bir kitleye seslendim. Konuşmacı olarak yer aldığım seminer için Başakşehir Living Lab ekibine teşekkür ederim.Keyifli bir organizasyon oldu. Katılım gösteren tüm herkese teşekkür ediyorum.
Microsoft Cloud and Datacenter Management MVP (Microsoft Valuable Professional) unvanına sahip olan Fırat Yaşar ile birlikte Azure Bastion servisini değerlendirdiğimiz ikinci içeriğimize videomuzdan ulaşabilirsiniz. Konunun devamı için Fırat Yaşar ile hazırladığımız diğer videomuza kanalımızdan ulaşabilirsiniz.
Microsoft Cloud and Datacenter Management MVP (Microsoft Valuable Professional) unvanına sahip olan Fırat Yaşar ile birlikte Azure Bastion servisini değerlendirdiğimiz birinci içeriğimize videomuzdan ulaşabilirsiniz. Konunun devamı için Fırat Yaşar ile hazırladığımız diğer videomuza kanalımızdan ulaşabilirsiniz.
Uzun zamandır vakit harcadığım hizmetlerden bir kaçı olan Azure Front Door ve Application Gateway ikilisinden bu yazımızda bahsedeceğim. Temel anlamıyla bu yazı serisinde hizmetlerin çok detaylarına girmeyi düşünmüyorum fakat avantajlarını ve dezavantajlarını görebileceğimiz bir yazı seri olacak. Seri sonunda en azından sizlere bu servislerden hangisini ne için seçmeniz gerektiğini aktaran bir sonuca kavuşturmayı hedefliyorum. Bildiğiniz gibi şirket/organizasyon içerisinde servisleriniz var bunlar; http veya https olarak public bir şekilde hizmet verebilen (IaaS, PaaS farketmez.), Function ve Web API vs hizmetleriniz olduğu düşünelim ve tüm bu servislerini Internet ortamına açmak istediğimiz zaman güvenlik kriterlerini sağlayan özellikle Web Application Firewall özelliğine sahip cihazlar üzerinden Internet dünyası ile buluşturup müşterilerimizi hizmet vermeyi hedeflemekteyiz. En temel haliyle Web Application Firewall hizmeti sunan cihazlar/servisler bizlere bir web uygulamasına giden ve uygulamadan gelen tüm HTTP trafiğini filtreler, inceler ve bloklar. Bir Web Application Firewall (WAF) ürününün normal bir güvenlik duvarından farkı, sıradan güvenlik duvarları sunucular arasında bir güvenlik geçidi olarak hizmet verirken, WAF ürününün istediği web uygulamalasına ait içeriği filtreleyebilmesidir.HTTP trafiğini inceleyerek, SQL Enjeksiyonu, Siteler Arası Betik Çalıştırma (XSS) ve güvenlik yanlış yapılandırmaları gibi güvenlik zafiyetlerinden kaynaklanan saldırıları engelleyebilmektedir. Bu servisleri/appliance seçerken karışımıza çıkan bir çok seçenek ve sorular ile karışlacaksınız özellikle güvenlik ekibinden gelen soruların başında 'OWASP' desteği var mı? – Bu da nedir derseniz eğer kısaca; Open Source Web Application Security Project(OWASP), web uygulaması güvenliği alanında serbestçe erişilebilir makale kaynakları, metodolojiler, belgeler, araçlar ve teknolojiler üreten çevrimiçi bir topluluktur. Bu tarz servislerin, OWASP Community üzerinden sununulan standard güvenlik zafiyeti içerebilecek tüm standardları izlemesi gerçekten oldukça önem teşik etmektedir. Daha fazla detay öğrenmek istiyorsanız lütfen şu sayfa üzerinen bir göz atın derim. Konuya bağlı kalarak, Web Application Firewall hizmeti, günümüzde daha çok güvenlik ekibi tarafından yönetilmektedir.
Bir önceki yazımızda Visual Studio Code üzerinde ilk fonksiyonumuzu oluşturduk. Hatırlarsanız fonksiyonumuzun adı getResourceStatus olarak belirlemiştik. Fonksiyon bize Azure sanal sunucuların hakkında anlık raporlar (html output olarak) üretmesini sağlamak temel hedefi idi. Bu fonksiyon RESTful isteklerin kabul ediyor olacak ve istediğimiz zaman abonelik içerisinde bulunan sanal sunucuların yapılandırma bilgilerini anlık ve her yerden bir web request ile raporlayabileceğiz.
Fonksiyonumuzu deploy etmeden önce bildiğiniz gibi Azure Subscription içerisine Azure Function App deploy etmemiz gerekiyor. Bunu dilerseniz Azure Portal, ARM Template, VSCode, Powershell yapabilirsiniz. Bu yazı içerisinde size aşağıdaki Powershell Script'ini takip ederek Azure Function App oluşturmanızı yardımcı olacak olan kod bloğunu paylaşıyorum.
Artık ilk Event-Based Automation çözümümüzü beraber geliştirebiliriz, senaryomuzu basit ve anlaşılır yapmak için hemen beraber belirleyelim. Başlangıç seviyesi için kesinlikle basit bir senaryodan ilerleyeceğiz. Örneğin, Azure Function 'HTTP' trigger (tetikleyicisini) kullanarak parametrik olarak gönderilen sanal sunucunun adına göre Azure Function bizim için HTML bir Report oluşturmasını isteyelim. Giriş yazımızı hatırlarsanız, o kısımda 'HTTP' kullanırsak bize bir RESTful HTTP uç noktaları sunar API gibi davranacağından bahsetmiştik. Şimdi ön gereksinimlerimiz neler bunlara bir göz gezdirelim.
Fonksiyonlarımız için ne tür Triggers ( tetikleyiciler) kullanabileceğimizden bahsettik ve örneklerini anlattık. Şimdi hız kesmeden Bindings (tam türkçeye çeviremiyorum. Bağlar/Bağlantılar) kavramına açmak istiyorum. Bindings size fonksiyonunuz içerisinden verilere bağlanmanız için bir yol veya yöntem için yardımcı olurlar. Bir önceki yazımızda bildiğimiz gibi Triggers ( tetikleyicilerin ) bize geliştirdiğimiz fonksiyonun hangi servisler tarafından tetiklenebileceğini söyleyebiliyorduk. Örneğin, Azure Queue Servisi ile fonksiyonunuz tetiklenmesini ( yani çalışmasını/aksiyon almasını ) sağlayabiliyoruz. Fakat bu tetiklemeden sonra Storage Queue servisinden gelen veri bizim için fonksiyonun içerisindeki parametreye atanıyor. Bindings kullanmak zorunda değiliz fakat kullanma senaryomuzu biraz daha açmak ister isek, Storage Queue'den bir mesaj geldiği zaman tetiklenecek olan Azure Fonksiyonumla beraber Storage Table tuttuğum transcation verileriminde bindings kullanarak bir parametreye atanması sağlayıp, daha sonra bu verileri karşılaştırabilir ve fonskiyonumun onun sonuca göre çalışmasını sağlayabilirim. Bindings tamamen isteğe bağlıdır. Bu yüzden karşımıza farklı Bindings türleri çıkıyor olacak. Bir önceki yazımızda herhangi bir kod yazmadan tetikleyen servise erişmemizi sağlayacağından bahsetmiştik. Bindings sayesinde yine farklı servislere kod yazmadan erişip bir parametreye atayıp veriler elde edebilir ve onları değerlendirebiliriz.
Öncelikle bu yazı serisine başlamadan şunu göz önünde bulundurmanızı tavsiye ediyorum, yazı içerisinde geçen Azure servislerin detaylı bir biçimde neler yaptığını anlatmayı düşünmüyorum. Bunları anlamak ve kavramak için internet üzerinde örn:'Microsoft Docs' sınırsız kaynaklara erişme şansınız var. Genel anlamıyla servislerin nerede, ne zaman ve niçin kullanılması gerektiğine değinip servisleri sırası geldikçe ve kullanıma başladıkça sizinle paylaşıyor olacağım. Bu servisleri kullanırken temel veya yüzeysel bir açıklama görebilirsiniz. Fakat bu yazı serisinin temel amacı Serverless hizmetlerini kullarank ve bunlar ile beraber Cloud veya Hybrid otomasyonunun nerelere doğru yelkenler açtığını, son olarakta Powershell Core'un tüm Azure Serverless hizmetlerinde ne/nasıl bir şekilde aktif şekilde röl aldığını anlamanıza yardımcı olmaya çalışacağım.
Bu bölüm içerisinde, Secure DevOps Kit for Azure – Bölüm 2 isimli makalemizi okuyup, temel abonelik seviyesinde Azure Kaynaklarının güvenliğini tarama komutlarını kullandığınızı düşünerek biraz daha ileriye götürecek senaryolar üzerinde durmaya çalışacağım. Temel tarama komutlarını kullandık ve kavramaya çalıştık artık bundan sonra neler yapabileceğimize odaklanacağız. Bildiğiniz gibi , 'Get-AZSKSubscriptionSecurityStatus' kullanılarak manuel bir tarama başlattığımızda, (otomatik olarak) açılan klasör içerisinde CSV dosyasının detaylarına baktığımız zaman AzSK ile yaptığımız taramada değerlendirilen tüm kaynaklar için elde edilmiş bir rapor ve log dosyası sağladığını unutmayalım. Elde ettiğimiz bu dosyaların tümünün detayına ve ne işe yaradıklarını bir önceki yazımızdan ulaşabilirsiniz.
AzSK ile yaptığımız güvenlik kontrollerinde, kontrol hatasını düzeltmek için gereken düzeltme(leri) otomatikleştirilebiliriz. AzSK bu senaryoyu 'FixControls' özelliği ile desteklemektedir. Bu özelliğin mevcut yapılan kontroller için AzSK tarafından kullanıcıların talebi ile bu düzeltmeleri uygulayabilmesi için otomatik bir şekilde oluşturabileceği Powershell Script'i yeteneğine sahiptir. Tahmin edebileceğiniz gibi pek çok yapılan kontrol için eğer sorun bulunduysa ve düzeltilmek isteniyorsa, bunların otomasyonu her zaman uygun değildir, çünkü yapılan kontrollerin düzeltilmesiyle ilgili iş akışı veya çalışan servislerin bağımlılıkları karmaşık olabilir. Sonuç olarak, bu özellik tüm kontroller için mevcut olmayabilir veya geçerli olmayabilir. Bu özelliği 'Get-AZSKSubscriptionSecurityStatus' komutuna '-GenerateFixScript' parametresini eklediğimiz zaman bizim için abonelik içerisinde bulunan tüm kaynakları güvenlik kontrollerinden geçirir ve herhangi bir uyumsuzluk bulur ise bunlar için Powershell Script oluşturur ve bunu çalıştırmamız, bulunan sorunları düzeltmemiz için yeterlidir.
Yukarıdaki resim içerisindeki gibi kullandığımız zaman bizim için tüm kontrolleri yapıp otomatik bir Script oluşturacağından bahsetmiştik. Eğer bu komutu çalıştırırsanız sizin için otomatik olarak ilgili output dosyasını açacak ve Powershell Script'e erişebileceksiniz. Daha önceki yazılarımızdan hatırlayacağınız gibi, bir output klasörü oluşuyordu ve onun altında Securtiy Report adında bir CSV ve Log dosyalarının oluşturduğunu görüyorduk. Farklı bir klasör daha farkedeceksiniz. 'FixControlScripts' parametresini ekledikten sonra yeni bir klasör olacak ve bunun adını 'FixControlScripts' olarak görebilirsiniz. Bunun altında sizin için yaratılan Powershell Script bulunuyor ve bunu çalıştırarak bir AzSK yapmış olduğu denetimlerde eksiklik var ise Script sayesinde düzetlebileceklerinin detaylarını bulabilirsiniz.
'FixControlScripts' adında bir klasörümüz oluştu ve onun altında 'FixControlConfig.json' adında bir dosyamız var. Bu Json dosyasının içerisinde yapılan kontrollerin sonucu, eksikliklerin nasıl tamamlanması gerektiğini, ne tür parametreler alması gerektiğini görebilirsiniz.Bunun dışında 'RunFixScipt.ps1' adında bir adet Powershell Script dosyasıda bulunmakta, isteğinize bağlı olarak direk çalıştırabilir ve sizden talep edilen değerleri parametrik olarak isteyebilir veya FixControlConfig dosyası içerisine sizin doldurarak Script içerisinden otomatik bir şekilde işlenir ve işlemlere başlayabilir.Şimdi beraber JSON dosyası içerisine göz gezdirelim.
Resim içerisinde görmüş olduğunuz 'RunFixScript.ps1' isimli Powershell Script'inin içerisini incelediğiniz zaman parametre olarak 'ParameterFilePath' kesinlikle belirtilmesi gerektiğini fark edeceksiniz ve otomatik olarak bu dosyayı aradığını ve parametrik olarak aldığını göreceksiniz. 'RunFixScript.ps1' isimli Script'in detaylarına bakıyor olacağız ama öncesinde Config File detaylarını anlayalım. Yeşil ile çizdiğim alanlar aslında yapılan kontrolün ne amaçla yapıldıgını açıklamakta ve Description kısmında daha fazla detaylarını bulabilirsiniz. Ama bu Config file oluşmasının sebebi bulunan güvenlik kontrol kriterlerinin JSON içerisine yazılması ve parameters bloğu içerisindeki değerlerin, 'RunFixScript.ps1' dosyası çalıştırıldığı zaman girilen değerleri alarak iş yapmasını sağlamak.
"RunFixScript.ps1" isimli Powershell script'i içerisinde aslında kullanılan komutun "Repair-AzSubscriptionSecurity" olduğunu farkedebilirsiniz. Bu komut aslında bizim "FixControlConfig.Json" dosyasını alarak düzeltme çalışmalarına başlayacak. Talep ederseniz direk bu Powershell Function çağırıp FixControlConfig dosyasını gönderebilirsiniz."RunFixScript.ps1" script'ini çalıştırdığımız zaman yukarıdaki resim içerisinde farkedebileceğiniz gibi yeşil alan kısmında yeni bir "FixControlConfig.timestamp" şeklinde yeni config oluşturdu. Bunun sebebi ise bu Powershell Script'i çağırdığım zaman o config dosyasını alıp parametrik olarak bana bir takım tamamlamam gereken verileri sordu bunlar ( SecurityContactEmails,SecurityPhoneNumber,Tags) şeklinde değerler. Bunların neden gerektiğini CSV dosyası içerisine bakarak anlayabilirsiniz. Script çalışmaya devam ederken bizim için bu değerleri baz alarak abonelik içerisinde otomatik bir şekilde tamamlayabileceği eksik güvenlik kontrollerini tamamlayacak. Script çalışmayı tamamladığı zaman aşağıdaki gibi bir sonuç görmeniz mümkün.
Script çalışmayı tamamladı ve bizim için parametrik olarak talep edilen değerler için güvenlik kontrollerinin eksiklerini tamamladı. Yukarıda görebildiğiniz gibi, "RunFixScript.ps1" isimli script içerisinde "Repair-AzSubscriptionSecurity" fonksiyonu ile Secure DevOps Kit for Azure bizlere, Azure Policy ve Azure Alerts tanımlamalarını yaptı. Azure hesabınız üzerinden bunların tüm detaylarına erişebilirsiniz. Örneğin; AzSK oluşturacağı Alert'in için bize abonelik içerisinde belirli resource tiplerinde herhangi bir aksiyon alındığı zaman bizleri bilgilendiriyor olacak.Bu işlemi yapılmak için, 'AZSKRG' adında bir resource group oluşturup içerisine 'Activitylogalerts' ve 'ActionGroup' için tüm detayları barındıran tanımlamaları sizin için yapıyor olacak. Peki bu Alert'ların ne tür, hangi tip kaynaklar özelinde çalıştığına bakalım.
Bahsettiğimiz ActivityAlerts ve ActionGroups detayları 'AZSKRG' resource group içerisinde bulabilirsiniz.Resource Group'un "Tags" kısmına dikkat ederseniz, en son ne zaman AzSK tarafından oluşturulduğunu, hangi AzSK versiyonun kullanıldığını ve "Alert" versiyonunu görebilirsiniz. Ayrıca isterseniz, 'Azure Monitor' > 'Alerts' basarak neler olduğunu anlama şansınız var. Gördüğünüz üzere Networking, Database, Storage, Web, Analytics gibi farklı resource tiplerine ait activity uyarıları/alarmları yaratılmış. Bunların detayları incelemek için, script çalışmayı tamamladıktan sonraki log dosyasında ( Details.LOG) bakarakta anlama bulabilirsiniz. Aşağıdaki örnekte "AZSK_Networking_Alert' detaylarını ve hangi resource tipleri için alert tanımlamaları yapıldığını görebilirsiniz.
Özetle bu makale içerisinde, Secure Azure DevOps for Kit kullanarak abonelik üzerinde AzSK tarafından bulunan/tamamlanması önerilen güvenlik kontrollerinin nasıl otomatik bir şekilde yapılabileceğini öğrendik. Daha öncede bahsettiğimiz gibi AzSK tarafından otomatik bir şekilde çözülebilen denetim veya güvenlik kontrollerinin, '-GenerateScript' parametresi ile nasıl yapacağımızı anlamış olduk. Diğer serilerimizde Secure DevOps Kit for Azure serisinin Subscription seviyesindeki denetim/kontrol kullanım örneklerine devam edeceğiz.
Secure DevOps Kit for Azure araçının kullanıma artık yavaştan girelim. Öncelikle AzSK için Powershell Module nasıl sahip olacağımıza ve ne tür ön gereksinimler olduğuna beraber inceleyelim. Core MS Engineering tarafından bize aktarılan en az aşağıdaki işletim sürümüne ve powershell versiyonuna sahip olmanız gerekiyor.
Not: Bildiğiniz gibi Powershell Core sayesinde cross platform üzerinde Powershell'e sahip olma imkanı bizlere sunuluyor. Bu sayede Windows veya Linux, macOs farketmeksizin Powershell'i kullanabilirsiniz ama bir takım özelliklerinden yararlanma şansınız olmayabilir. Bu yüzden dökümantasyon tarafında henüz resmi bir detay göremedim özellikle Core veya Desktop sürümü olarak yaptığım bir çok testler de Windows üzerinde Powershell Core tarafında pek sorun yaşamadım. Ancak bu yüzden kendi edindiğim tecrübelerim ile paylaşabilirim ki AzSK Powershell Modülünü sorunsuz kullandığımı söyleyebilirim. Bu detay belki önem arz edebilir. Mümkün oldukça Powershell Core kullanarak hayatımı sürdürüyorum. Hızlıca bu Powershell modülüne nasıl sahip olabiliriz beraber görelim.
Bildiğiniz gibi Powershell üzerinden herhangi bir Modülü dahil etmek istersek bize yardımcı olan cmdlet "Install-Module" olarak karşımıza çıkıyor. Fakat bu komutu yazmadan önce bir konuyu sizinle paylaşmak istiyorum. AzSK Powershell modülü aslında arka tarafta Azure Powershell modülüne ihtiyaç duymaktadır. Bunun temel sebebi ise, AzSK Powershell modülüne sahip olduğunuz ve onun detaylarını incelediğiniz zaman bir çok geliştirilmiş 'advanced-powershell-function'larının olması ve bunların arkasında devamlı Azure Powershell Module ile birlikte gelen cmdlet'ler sayesinde ilgili kaynakların özelliklerini talep ederek iş yapabilmesidir. Örneğin, Azure Subscription seviyesindeki detaylara Secure DevOps Kit for Azure (AzSK) Powershell modüllü erişmek ister ise, Azure Powershell Modülüne ihtiyaç duyacak ve tüm yapılandırma detaylarını bu modül içerisinde bulunan komutlar sayesinde edinecektir. Yukarıda gördüğünüz "Find-Module -Name AzSK -IncludeDependencies -Repository PSGallery" aslında bize AzSK Powershell modülünün ne tür bağımlılıkları olduğunu anlatmaktadır.
Artık AzSK Powershell modülünü Powershell Gallery üzerinden talep edebiliriz. Yukarıda gördüğünüz satır içerisinde (9) kullandığım Powershell komut satırı, benim için AzSK'yı sahip olduğum bilgisayar üzerine indirecek ve bunu sadece sahip olduğum oturum içerisinde kalacak şekilde belirtmiş bulunmaktayım. Scope olarak 'CurrentUser' parametresi bana bu konuda yardımcı oluyor. Repository parametresi ise belirtmek zorunda değilsiniz, çok farklı Repository'ler kullandığım için özellike belirttim eğer tanımlamazsanız PSGallery yani Microsoft'un Windows üzerinde default tanımlamış olduğu Powershell Gallery üzerinden modüle sahip olmaya başlayacaksınız. En sonda kullandığım '-Verbose' parametresi ise 'Install-Module' komutu çalışırken bana arka tarafta yapılanlar hakkında detaylı bilgiler almamı sağlıyor.
Gördüğünüz gibi artık AzSK Powershell Modülüne sahibiz. Modüle içerisinde toplam şimdilik 55 adet cmdlet mevcut ama bir çoğunu bu yazı serisinde tanımaya çalışacağız. Şimdi en temelleri olan Subscription seviyesi bazında Security taramaları gerçekleştireceğiz ve bunun için şimdilik sadece abonelik ile ilgili olanlar ile ilgileneceğim.
İlk bölümde bahsettiğimiz ve konumuzun en temel önem arz eden başlığımız olan 'Subscription Security' yani Azure Aboneliğinin güvenliğinin detaylarına göz gözdirelim. Abonelik içerisinde tarama işlemi başlatmak için, 'Get-AZSKSubscriptionSecurityStatus' function kullanarak bir takım çıktılar/sonuçlar elde edebiliriz. Kullanmaya başladığımız zaman göreceksiniz ki bir çok detayın bu Powershell fonksiyonu tarafından irdelendiğini şahit olacaksınız. Herhangi aboneliği incelemek için bir dizi otomatik tarama gerçekleştirir ve çeşitli güvenlik sorunları, yanlış yapılandırmalar veya eski eserler / ayarlar nedeniyle aboneliğinizin daha yüksek bir risk altında olabileceğinin göstergesi olan koşulları/bulguları sizlere işaretler. Bu fonskiyon aşağıdaki kısımlara tek tek bakarak size bir sonuç oluşturmaya çalışıyor.
Access Control ( IAM ) Erişim kontrolü yapılandırması – abonelik seviyesinde kimlik ve erişim yönetimi ile ilgili sorunlar. ( Abonelik üzerinde bulunan admins/owners, custom-rbac roles, MFA, PIM, SPNs)
Alert Configuration – Azure Aboneliği ve çeşitli azure kaynakları için hassas eylemler için etkinlik uyarılarının yapılandırılması. (Securtiy Center )
Azure Security Center - Azure Güvenlik Merkezi yapılandırması detayları – (Point of contact, VMs Updates, Malware, Extension vb.)
Azure Policy ve Resource Lock- konfigürasyonu – Belirli bir düzeyde tanımlanan Azure Policyler ( Region, VM Size, belirli resource tiplerinin yasaklanması), Resource Lock ve diğer tüm Policy ile yapılabilecek diğer aksiyonlar.Bunun dışında şahsi olarak kullandığım ve sizinde güvenli bir abonelik için Azure Policy ile birlikte çalışan Guest Configuration bakmanızı önerebilirim.
Note: Daha fazla detay için lütfen paylaştığım sayfa üzerinden neden önemli oldukları ve ne seviyede önem gerektirdiklerini anlayabilirsiniz. Lütfen şu sayfaya göz gezdirin.
Yukarıdaki resim üzerinde görüldüğü üzere ilk health check işlemini 'Get-AZSKSubscriptionSecurityStatus' function ile başlattım. Bu komutu çalıştırmadan önce doğal olarak Az Powershell üzerinde tarama başlatalabilmek için ilgili aboneliklere yetkili hesap ile oturum açmanız gerekmektedir. SubscriptionId değerini bu function içerisine gönderdip çalıştırdıktan sonra yukarıda özetle bahsettiğimiz kontrolleri tek tek yapıyor ve sizin için bir sonuç belirlemeye çalışıyor olacak.
İlgili Powershell fonksiyonu bizim için başarılı bir şekilde çalıştı. Yapılan kontroller sonucu ne tür testlerden geçemediğimizin detaylarını Powershell bize Console üzerine yazmış bulunmakta bununla kalmayıp bunları "High", "Critical","Medium" olarak ayırdı. Bunların tüm detayları yukarıda belirttiğim sayfa üzerinde var. İlgili sayfa içerisinde neden seviyelerinin "High",Medium",Critical" olarak ayrıldığını anlayabilirsiniz. Health Check işlemini başlatmak istediğim aboneliğim MSDN olarak belirlemiştim. Üzerinde sadece yaptığım testler olan birazda dağınık bir hesap, yukarıdaki tablo içerisinde bazı adımlardan 'Failed' aldığımı görüyorum. Bunların bazıları "High" ve "Medium" olarak iki kısıma ayrılmış durumda. Yukarıdaki resim içerisinde ayrıca belirttim fakat Powershell fonksiyonu çalışmayı bitirdiği zaman size bir "Windows Explorer" otomatik olarak açıyor olacak ve karşınıza bir takım log dosyaları ve çalıştırdığımız tarama sonucunun daha fazla detaylarını 'CSV' dosyası içerisinde bulabileceksiniz.
Bizim için otomatik bir şekilde output çıktısı oluşturdu, bu dosyalardan en önemlisi CSV detayları ve buna baktığımız zaman hangi tür testlerden başarılı/başarısız olduğumuzu görebileceğiz. Bunun dışında 'Etc' ve 'Visual Studio Enterprise – MCT' folderında Azure aboneliği için tutulan bir takım bilgiler ve Powershell Function çalıştığı süre boyunca Powershell transcript özellğinden faydalanarak console yazılan herşeyin bir çıktısınıda görebiliyorsunuz. İşin özeti bizim için en önemli dosya şimdilik Security Report adındaki dosya olduğunu söyleyebilirim. Şimdi biraz da bu dosya içeriğini inceleyelim.
CSV Dosyasını açtım ve artık içerisindeki değerleri görebiliyoruz. Bizim için nelerin kontrol edildiğini beraber daha rahat anlayabiliriz. Çalıştırdığımız Powershell Function yaptığı tüm testlerin detayları bu kısımda bulunmakta ve CSV dosyasının en sağ tarafında 'Recommendation' kısmına giderek neler yapmanız gerektiğini bulabilirsiniz. Ekran görüntüsü olarak paylaşmadım ama abonelik içerisinde hangi Resource'dan dolayı başarısız sonuçları anlamanız içinde 'CSV' üzerinde 'ResourceId' kısmına bakarak kaynağınızı direk tanıyabilme ve bulma şansınız vardır. Daha fazla detay öğrenmek için lütfen "Visual Studio Enterprise – MCT"(Sizin aboneliğinizin ismi yazacaktır) klasörü içerisinde bulunan 'Subscription.LOG' isimli dosyayı özellikle incelemeyi unutmayın.
Daha farklı bir kullanama yöntemi olan ve parametrik olarak değerler alabilen bu komut, istersek bizlere 'PDF' olarak yukarıda gördüğünüz raporları sunabiliyor. Aslında fikir ve kullanım açısından çok hoş, eğer biden çok farklı aboneliğiniz var ise hepsi için tek tek 'PDF' çıktıları alıp ilgili iş birimlerini bilgilendirebilirsiniz. Gelin beraber kullanım şeklini inceleyelim.
Yukarıda görebildiğiniz gibi yaptığım sadece 'GeneratePDF' parametresini otomatik oluşacak rapor için yatay mı dikey mi olmasına karar vermem oldu. Talep ederseniz ilk kullandığımız komut ( CSV ) sonuna '-DoNotOpenOutputFolder' parametresini eklersek, bizim için herhangi bir 'Windows Explorer' açmayacaktır.
Elde ettiğimiz raporların detaylarına baktığımız zaman bir çok güvenlik kriterleri ele alınmış durumda. Fakat ilgili Powershell komutu içerisine parametrik değerler göndererek almak istediğimiz arama standlarına göre (bunların belirli bir anahtar kelime listesi var örneğin; RBAX, SOX, AuthN) bu değerleri gönderdiğimiz zaman o spesifik bölümler için tarama/health check başlatabiliyorum. Gönderebileceğimiz parametreler ve anlamları aşağıdaki gibidir.
İlk başta bahsetmek istediğim iki adet parametre var. Bunların detaylarını yukarıdaki açıkladım. Paylaştığım bilgi doğrultusunda, bu parametrelerin alabileceği çok fazla değer var ve aşağıda bulunan liste içerisinde parametreleri kullanmaya karar verdiğinizde bu güvenlik etiketlerini kullanarak 'Get-AZSKSubscriptionSecurityStatus' parametre gönderip sadece belirlediğiniz güvenlik denetimine göre sonuç alabilirsiniz.
'FilterTags' ve 'ExcludeTags' alabilecek parametrik değerler yukarıdaki gibi olmalıdır. Şimdi beraber bir örnek yapalım ve gelin nasıl kullanabildiğimizi beraber görelim.
Yukarıda yapmış olduğumuz iki adet farklı örnek bulunuyor. Bu örneklerde görebileceğiniz gibi iki adet farklı tag isimleri göndererek sadece belirlediğimiz güvenlik kriterlerine göre aramalar yaptık. 'SOX' – uyum ve denetimi için 'Get-AZSKSubscriptionSecurityStatus' çalışacak ve ona uygun bir şekilde kontroller yapacaktır.
Diğer farklı bir kullanım yöntemi olan ve parametrik olarak gönderebileceğimiz bölüm ise 'ControlIds' parametresi bize Secure DevOps Kit for Azure için yapılan Control kriterleri bazında filtereleme şansı verecektir. Kullanım şekline beraber bakalım;
Yapmış olduğumuz örnek içerisinde görebileceğiniz üzere, 'ControlIds' parametresi 'Azure_Subscription_AuthZ_Limit_Admin_Owner_Count' eşit olan güvenlik kontrollerine göre rapor oluşturmasını talep ettim ve sadece onun özelinde bana tarama sonucu olan 'CSV' dosyasını yaratıyor olacak.Bu yaptığım aramanın sonucu yine Powershell Console üzerinde görebiliyorum ve ayrıca talep istersem, CSV ve PDF olarak çıktı alma şansım var.
Bu yazımız içerisinde AzSK Powershell modülünün sadece bir komutu olan 'Get-AZSKSubscriptionSecurityStatus' kullanarak nasıl health check raporları almamız üzerine konuştuk. Bir sonraki yazımızda bu Powershell fonksiyonun nasıl kullanıldığına ve ne tür farklı yetenekleri olduğunu anlatmaya devam edeceğiz.