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.
Azure Custom Resource Provider kullanım örneklerini blog üzerinde uzun bir seri ile paylaşmıştık. Fakat GitHub üzerinde belirttiğim repository üzerinden devamlı bir şekilde güncel tutmaya özen göstereceğim. Eğer talep ederseniz sizde Pull Request gönderip kendi Custom Resource Provider'larınızı paylaşırsanız örnekleri tek noktada toplayabileceğimiz bir yere sahip oluruz. Daha fazlası için aşağıdaki GitHub Repository incelemenizi tavsiye ederim.
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.