69 posts tagged with "Azure"

In the first part of our article series, we tried to understand the Azure Resource Graph service. Now with executing sample queries, let's try to detail and implement them. For example, let's suppose that we have a scenario like this: an organization with up to 500~ Azure Subscriptions that one person manages. And this person has to list all of the storage accounts.

We mentioned plenty of different ways to complete the scenario above before. If you wish, you can access this information from Azure Portal or use the Get-AzStorageAccount cmdlet on PowerShell by visiting every subscription. Of course, there is an easier way, and it is using Azure Resource Graph Query. Let's try this to get information in a more accessible way.

With this article, we will start an article series that will cover Azure Resource Graph and the particular features that make it different. You might never used or you might have never heard Azure Resource Graph before, but you will have a grasp of it with this article series. In this series, we will try to create and improve solutions that needed for real scenarios. Now without getting into detail, let's jump into our article.

What is Azure Resource Graph?​

We can define Azure Resource Graph as an Azure service extension of Azure Resource Manager for absolute beginners. To answer what it provides and why we should use it, we need to look at the examples like the actions that we can execute in subscriptions in our organization by using Azure Resource Graph. These examples are:

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.

• Hizmetlere genel bakış
• Performans farklılıkları
• Sonuç

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.

• Input bindings are passed in via param block.
• Write to the Azure Functions log stream.
• Associate values to output bindings by calling 'Push-OutputBinding'.

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.

• Visual Studio Code kullanarak Azure Function App Projesi oluşturmak
• Azure Functions için örnek folder mimarisi
• Mevcut Azure Function App projesi içerisine yeni bir function oluşturmak

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.