Azure SQL Veritabanı Bakım Süreçlerini İyileştirmek

Bu yazıyı uzun zamandır üzerine düşündüğümüz ve bulduğumuz bir çözüm üzerine ele alıyorum. Bu yazımızın temel amacı PEAKUP Azure Services paketini neden geliştirdiğimizle doğrudan alakalıdır. Ek olarak doğru kullanım noktasında, ölçeklendirme ile ilgili problemlerin Azure üzerinde aslında çok az maliyetler ile nasıl çözülebildiğini göstermektir. Bu yazının kapsamı ve faydası, birden fazla veritabanı yönetimi, Azure SQL Sunucu üzerinde veritabanlarının bakımını ve performansını arttırmak üzeredir.
Yazının girişinde bahsettiğimiz paketi geliştirirken Azure üzerinde deneyimlediğimiz bir ilginç şeyse, REST üzerinden iletilen tüm Scale Up/Down taleplerinin portal.azure.com üzerinden yapılan taleplerden belkide iki katı kadar kısa bir sürede gerçekleşmesiydi!

Vaka

PEAKUP’ın Velocity ürünü içerisinde yer alan bazı müşterilerimizin kayıtları yüz binleri bazıları da milyonları bulabiliyor. İlerleyen zamanlarda yüz milyonlara hatta milyarlara kadar ulaşacağından eminim. Bu nedenle gerekli bakım stratejilerini daha baştan, en doğru ve pratik şekilde kurgulamak son derece değerli! Ürün içerisinde tek bir veritabanı içerisinde Multi Tenant bir yapı uygularken aynı zamanda KVKK gereği bulut kaynakları kullanmayan müşterilerimiz için yerel sunucu desteği sunuyoruz ya da müşterilerimizin kendilerine ait Azure kaynakları içerisinde tuttukları veritabanlarını da kullanabiliyoruz. Yani bir veritabanı üzerinde birden fazla Multi Tenant yapının yanında birden fazla veritabanı üzerinde de yine birden fazla Multi Tenant bir mimariden bahsediyoruz.

Velocity platformunun her zaman erişime açık olması, her zaman yüksek ve ayrıca aynı performansta olması ürün için ortaya koyduğumuz en önemli prensiplerden yalnızca bir kaçı arasında yer alıyor. Genel olarak kullanım, iş dünyasına hitap ettiği içini iş günleri ve çalışma saatleri içerisinde çok yüksek olsa da mavi yakanın ağırlıklı olduğu ve 24 saat operasyonun devam ettiği müşterilerimizde gece kullanımı da oldukça yüksek oluyor. Bu nedenle bakım süreçlerinin kullanımın görece daha az az saatlerde olduğu zamanlarda olsa da kesinlikle platformu durdurmaması ya da herhangi bir yavaşlığa, kesintiye sebep olmaması gerekiyor. Söz konusu yedi gün yirmi dört saat devam eden bir operasyon olduğunda sürekli erişebilirlik taviz verilebilecek bir konu opsiyonundan çıkıyor.

Sürekli büyüyen veritabanlarında, veritabanının sürekli, doğru ve düzgün bir şekilde yedeklenmesi, verilerin sürekli olarak sıralı bir şekilde depolandığını kontrol etmek veritabanı ölçeklendirme konusundaki en kritik operasyonlardan birisidir. Yedekleme safhası Azure tarafından otomatik olarak yönetildiği için bu yük üzerinizden kalksa da Index’lerin bakımları, Partition’ların gerekli zamanlarda tekrar yapılandırılmaları gibi konular veritabanı üzerinde ciddi anlamda yük yaratan operasyonların başında gelir. Azure SQL içerisinde sorguların performanslarını takip etmek, yavaş sorguları tespit edip bunlar için aksiyon almak “Database recommendations” bölümündeki tavsiyeler eşliğinde kolayca yapılsa da, bakım süreçlerinde bu aksiyonları almaya başladığınızda veritabanı performansıyla ilgili ciddi sorunlar sizleri bekliyor. Üstelik bu problem, On Premise olarak çalışan SQL sunucuları için oldukça güç! İşte bunun için doğru zamanda, doğru miktarda kaynak kullanımı son derece kritik rol oynuyor.

Veritabanın sahip olduğu sunucu tipi(enterprise, developer, express vb.) bir çok geliştirici tarafından çok önem arz etmese de söz konusu bakım olduğunda böylesi kriterlerin değeri ortaya çıkıyor. Zira SQL Server Enterprise içerisinde Index bakımları Online olarak yapılabilirken, system içerisinde herhangi bir duraksama söz konusu olmaktan çıkıyor. Ancak veritabanının kullandığı kaynaklar ve bakımların süresiyle ilgili problemler, problem olmaya devam ediyor. Şu da unutulmamalıdır ki veritabanı üzerinde yapılan her Index, her Partition operasyonu performasın artacağı garantisini vermez… Zira diskin büyümesine haliyle SQL Server tarafından belleğe alınan verinin daha da büyük hale gelmesiyle kaynak kullanımı bir yerden sonra yetersiz oluyor. Özellikle söz gelimi olarak 1, 2, 4 ve 14 hafta olacak şekilde bir Retention Policy, veritabanı üzerinde her zaman yükün artacağını bunun yanı sıra bakım konularının kritik seviyesini en üst seviyeye çekiyor.

Bakım süreçlerinin en hızlı şekilde yapılması hem kullanıcı memnuniyeti, hem ölçeğin sürekli olarak arttırılabilir noktada olması hem de itibar açısından son derece önemli bir hale geliyor. İşte bu nedenle Azure üzerinde kaynakları ihtiyacınız olduğu anda dilediğiniz kadar arttırabilmek ya da azaltabilmek (Scale Up/Scale Down) son derece kilit bir rol oynuyor. Üstelik sadece süreç olarak değil maliyet olarak da!

İhtiyacımız olan senaryo, bakım süresi öncesinde kullandığımız veritabanı planını bir ya da iki üst seviyedeki kaynak oranında arttırmak ve bakım sonrasında eski kaynaklara geri dönebilmek… Böylece arttırılan kaynakların bir kısımı bakım kalan kısmı da platformun düzenli bir şekilde devam etmesi için hazır olarak bekliyor!

Üstelik bu operasyon sırasında, hiçbir bakım işleminin zaman aşımına uğramaması ve bakım sürecini en baştan tekrar başlatmamak ya da veritabanının kilitlenmesi gibi çok büyük riskleri ortadan kaldırmak… Böylece veritabanı üzerindeki maliyete sadece saatlik fiyatlar ile katlanırken, belkide 3-4 saat kadar sürecek bir operasyonu dakikalar içerisinde tamamlayabilmek!
Söz konusu problemlerin bir de, birden fazla sunucunun ya da birden fazla veritabanının olduğu noktalarda problem daha da karmaşıklaşıyor. Zira bir veritabanı ile ilgili böyle bir işlemi haftada bir, elle yapmak çok ciddi vakit almaz ya da kendi içerisinde büyük riskler barındırmaz. Ancak birden fazla sunucu, birden fazla veritabanı ve tüm bunların yanında bakımın yapılma sıklığını düşündüğümüz zaman süreci otomatize etmek artık zorunlu hale geliyor.

Yakın zamanda, PEAKUP olarak sahip olduğumuz bu çözümü Azure’ın REST API istekleriyle çözülebileceğini zaten tahmin ediyorduk. Ancak programatik olarak olması, ilgili sorunu olası bir durumda diğer ürünlerimizde ve hizmetlerimizde kullanabileceğimiz şekilde çözülmesi bizim için en önemli noktalardan birisiydi. Bu nedenle PEAKUP Azure Services çözümünü ele aldık. İlgili kaynak kod içerisinde, yalnızca SQL ile ilgili sorunları değil ek olarak, Web Application konusunda da benzer problemleri keşfedebileceğiniz çözümleri de bulabilirsiniz.

Modern Authentication’a Geçiş Hakkında Bilgilendirme

[vc_row][vc_column][vc_column_text]1 EKİM 2022 TARİHİNDE BASIC AUTHENTICATION DESTEĞİNİ SONLANDIRDI.

1 Ekim 2022 tarihinde sonlandırılan Basic Authentication sonrasında mobil cihazlarda kurulum olan hesapların hepsinde bağlantı sorunları yaşanmaya başladı.

Mobil cihazların kendi mail uygulamalarında hesapları kaldırıp tekrar eklendiğinde problem ortadan kalkıyor. Fakat güncel sürümlerin kullanılması gerekmektedir ve buda kalıcı bir çözüm değildir kalıcı çözümler için aşağıdaki adımları gerçekleştirebiliriz.

Office uygulamalarında ise,

2016 C2R versiyonlarda güncelleme yapılması halinde sorunsuz giriş yapılmaktadır.

2019 ve 2021 versiyonlar hali hazırda zaten Modern Authenticator desteklenmektedir.

Office 2013 ve Office 2016’nın versiyonlarında güncel olmasına rağmen Basic Authentication’dan Modern Authentication’a geçiş otomatik olarak yapılmıyor. Bu nedenle aşağıdaki regedit keylerini eklemeniz gerekmektedir.

HKEY_CURRENT_USERSoftwareMicrosoftExchangeAlwaysUseMSOAuthForAutoDiscover REG_DWORD    1
HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0CommonIdentityEnableADAL REG_DWORD    1
HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0CommonIdentityVersion REG_DWORD    1

[/vc_column_text][/vc_column][/vc_row]

SQL için Azure Synapse Bağlantısı Genel Önizlemede 

Veriye dayalı, kaliteli içgörüler, şirketlerin rekabetçi kalması için giderek daha kritik hale geliyor ve bu öngörülere ulaşma hızının inanılmaz bir fark yaratıyor. Geleneksel ETL ve ELT pipeline’larının maliyetli ve zaman alıcı yapısı artık hiçbir şekilde yeterli değil. Microsoft Build 2022’de, hem SQL Server 2022 hem de Azure SQL Veritabanında SQL için Azure Synapse Bağlantısının genel önizlemeye sunulduğunu duyuruyoruz. Bu sürümle beraber, artık SQL tabanlı operasyonel depolarınızdan Azure Synapse Analytics’e az kodla ve kodsuz, neredeyse gerçek zamanlı veri replikasyonundan yararlanabilirsiniz. Bu, operasyonel mağazanız üzerinde minimum etkiyle, neredeyse gerçek zamanlı olarak operasyonel veriler üzerinde BI raporlaması çalıştırmayı kolaylaştırır. 

  

SQL için Azure Synapse Bağlantısı nedir? 

SQL için Azure Synapse Bağlantısı, işlem veritabanlarınızdan (hem SQL Server 2022 hem de Azure SQL Veritabanı) verileri Azure Synapse Analytics’te ayrılmış bir SQL havuzunda çoğaltmaya yönelik otomatik bir sistemdir. SQL verilerinizden Azure Synapse’e bir bağlantı kurma işlemi, geleneksel ETL süreçleri için saatler veya günler yerine yalnızca birkaç tıklama ve birkaç dakika alır. Yapılandırıldıktan sonra, ilk verileriniz ayrılmış hedef SQL havuzuna kopyalanır. Tablonun ilk defa oluşturulmasının sonrasında, kaynak verilerinizde yapılan değişiklikler neredeyse gerçek zamanlı olarak yansıtılır. Azure Synapse Analytics’te ayrılmış SQL havuzunun boyutunu ve ayrıca verileri almak için kullanılan çekirdek sayısını kontrol edersiniz ve kaynak sisteminiz, verileri alım için kullanıalabilir hale getirir.

 

Neden kullanalım? 

SQL için Azure Synapse Bağlantısı, SQL Server 2022 veya Azure SQL Veritabanı’ndaki verilere sahip herhangi bir kuruluş için Azure Synapse Analytics’e veri çoğaltmayı kolaylaştırmaya yardımcı olur. Bunun geçerli olduğu birkaç örnek senaryo:  

  • Neredeyse gerçek zamanlı analitik: Geleneksel ETL sistemi, periyodik bir programa göre çalışır. İlk veri çekirdeği oluşturma (ki bu otomatikleştirilmiştir) tamamlandıktan sonra, SQL için Azure Synapse Bağlantısı, işlem verilerinizi neredeyse gerçek zamanlı olarak Azure Synapse Analytics’e yansıtır. 
  • Az kodlu/kodsuz çözümler: SQL için Azure Synapse Bağlantısı, verileri çoğaltmak için az kodlu veya kodsuz bir çözüm sağlar. ETL paketleri veya ambar şemaları oluşturmaya ve yönetmeye gerek yoktur; hangi tabloların çoğaltılacağını seçin, bir dağıtım yöntemi ve depolama mimarisi sağlayın ve bağlantıyı başlatın. 
  • Veri konsolidasyonu: SQL için Azure Synapse Bağlantısı, birden çok operasyonel veritabanından (hem bulut tabanlı hem de şirket içi) verileri, raporlama ve makine öğrenimi modellemesi dahil ancak bunlarla sınırlı olmamaksızın iş yükleri için kullanabileceğiniz tek bir bulut tabanlı analitik çözümde kolayca birleştirmenize olanak tanır. 
  • Kaynak sistemler üzerinde minimum etki: Toplu ETL ve ELT sistemleri, veri değişikliklerini sorgularken operasyonel bir sisteme fazladan yük bindirebilir. SQL için Azure Synapse Bağlantısı, değişiklikleri izleyen ve bunları ayrılmış hedef SQL havuzuna işlenmek üzere geçici bir giriş bölgesine verimli bir şekilde taşıyan ve böylece kaynak sisteminizden değişikliklerin ayıklanmasının etkisini en aza indiren yeni bir değişiklik akışı işlemcisi sunar.

Peki nasıl çalışıyor?
thumbnail image 2 of blog post titled Announcing the Public Preview of Azure Synapse Link for SQL

 SQL için Azure Synapse Bağlantısı, veri hareketini basit ve verimli hale getirmek için en son teknolojiden yararlanır: 

  • Değişiklik akışı: Değişiklik akışı, hem SQL Server 2022’de hem de Azure SQL Veritabanında, kaynak işlem sistemi ile Azure Synapse Analytics arasında veri senkronizasyonunu desteklemek için oluşturulmuş yeni bir özelliktir. 
  • Azure Data Lake Storage 2: SQL için Azure Synapse Bağlantısı, kaynak sistemlerinizden gelen veriler için bir giriş bölgesi olarak Azure Data Lake Storage 2’den yararlanır. Bu “arabellek”, bağlantının kaynak veritabanı sistemleriniz üzerindeki etkisini en aza indirmeye yardımcı olur. 
  • Azure Synapse Analytics’te Ayrılmış SQL Havuzu: Kaynak sistemlerinizden gelen veriler için nihai hedef, Azure Synapse Analytics’teki ayrılmış bir SQL havuzudur. Bu havuzu, hem alınan veri hacminizin hem de sorgu iş yüklerinizin ihtiyaçlarını karşılayacak şekilde boyutlandırabilirsiniz. 
  • Alım Hizmeti: SQL için Azure Synapse Bağlantısını etkinleştirdiğinizde, arka planda verileri giriş bölgesinden ayrılmış hedef SQL havuzuna taşımak için bulut tabanlı bir alım hizmeti dağıtılır. Bu tamamen sizin için yönetilir ve verilerinizi kullanılabilir hale getirmek için arka planda çalışır.

Kurulum ve çalıştırma 

SQL için Azure Synapse Bağlantısını kullanmak için önce Azure Synapse Analytics ortamınızda aşağıdaki öğeleri oluşturmanız gerekmektedir: 

  • Kaynak Veritabanına Bağlantılı Hizmet: Bu, standart bir Azure Synapse Analytics bağlantılı hizmetidir ve Azure SQL Veritabanı veya SQL Server 2022 için oluşturulabilir.

thumbnail image 3 of blog post titled Announcing the Public Preview of Azure Synapse Link for SQL thumbnail image 4 of blog post titled Announcing the Public Preview of Azure Synapse Link for SQL thumbnail image 5 of blog post titled Announcing the Public Preview of Azure Synapse Link for SQL Azure Synapse Analytics’te Ayrılmış SQL Havuzu: Bu, çoğaltılan işlem verileriniz için hedef olarak kullanılacaktır. thumbnail image 6 of blog post titled Announcing the Public Preview of Azure Synapse Link for SQL Kaynak veritabanınız olarak SQL Server 2022 kullanıyorsanız, aşağıdakileri de oluşturmanız gerekir (bunlar Azure SQL Veritabanı için otomatik olarak oluşturulmaktadır): 

  • Azure Data Lake Storage 2: Bu, giriş bölgesi olarak kullanılan depolama hesabıdır. Bu hesap sizin tarafınızdan yönetilirken, giriş bölgesindeki dosyalar, bekletme ilkesinin veya dosya biçiminin gerektiği gibi değiştirilebilmesi için yalnızca SQL için Azure Synapse Bağlantısı için kullanılabilir. 
  • Açılış Bölgesine Bağlı Hizmet: Azure Synapse Analytics çalışma alanında, yukarıda oluşturulan depolama hesabını gösteren bağlantılı bir hizmet oluşturmanız gerekmektedir

thumbnail image 7 of blog post titled Announcing the Public Preview of Azure Synapse Link for SQL Şirket İçinde Barındırılan Entegrasyon Çalışma Zamanı: Aynı zamanda hem SQL Server 2022 veritabanıyla hem de Azure Synapse Analytics ortamıyla iletişim kurabilen şirket içinde barındırılan bir entegrasyon çalışma zamanı yapılandırmanız ve yüklemeniz gerekmektedir. Bu, iki ortam arasındaki komutlara aracılık etmek için kullanılır. thumbnail image 8 of blog post titled Announcing the Public Preview of Azure Synapse Link for SQL Ön koşulları yerine getirdikten sonra Azure Synapse Analytics’te bir Azure Synapse Bağlantısı oluşturabilirsiniz. Bağlantıyı oluşturduğunuzda: 

  • Kaynak veritabanını, 
  • Kaynaktan çoğaltmak istediğiniz tabloları, 
  • Ve ayrılmış hedef SQL havuzunu belirtisiniz.
     

Bağlantıda kurduğunuz her tablo için: 

  • Ayrılmış hedef SQL havuzundaki tablo ve şema adlarını (bunların kaynak tablo ve şema adlarıyla aynı olması gerekmez), 
  • Dağıtım türünü (hepsini bir kez deneme dağıtılmış, karma dağıtılmış veya çoğaltılmış tabloları kullanabilirsiniz), 
  • Ve yapı türünü belirtebilirsiniz. 

 Bilinen mevcut sınırlamaların yanı sıra ayrıntılı talimatlar Microsoft’un resmi belgelerinde mevcuttur.   İlk kurulumu tamamladıktan sonra bağlantıyı başlatabilirsiniz. Bu noktada, şunlar gerçekleşir: 

  • Şema ve kaynak tablolardan gelen verilerin ilk dışa aktarımı gerçekleştirilir. Bu çalışma aslında kaynak veritabanı (Azure SQL DB veya SQL Server 2022) tarafından yapılır ve veriler iniş bölgesine yerleştirilir. 
  • Alma hizmeti, giriş bölgesinden anlık görüntüleri alır, ayrılmış SQL havuzunda hedef tabloları oluşturur ve ardından ilk verileri yükler. 
  • İlk yükleme tamamlandıktan sonra, kaynak veritabanı her tablo için değişiklikleri alım hizmeti tarafından alındıkları ve ayrılmış hedef SQL havuzuna uygulandıkları iniş bölgesine sürekli olarak yayınlar. 

 Çalışan bir bağlantıda halihazırda bulunan tabloların konfigürasyonunda değişiklik yapamazsınız, ancak yeni tablolar ekleyebilir ve mevcut tabloları kaldırabilirsiniz.  

5 Adımda Azure Synapse Analytics Kurulumu

[vc_row][vc_column][vc_column_text css=”.vc_custom_1645618726799{margin-bottom: 0px !important;}”]

Selamlar! Ben PEAKUP Business Analytics ekibinden Özgür! bu da PEAKUP blog sayfasındaki ilk yazım. 🤭 Azure Synapse Analytics dünyasına hızlı bir bakış ilk yazı için oldukça havalı bir giriş olacağını düşündüm. Ama öncesinde bir Azure Synapse Analytics workspacesine ihtiyacım var. 😐

Hadi gelin birlikte oluşturalım! Azure Portal ana sayfada üst kısımdaki arama bölümüne Azure Synapse Analytics diye aratarak kurulum sayfasına ulaşabiliriz. Basics, Security, Networking, Tags, Review + create adımları karşımıza çıkıyor. Bu aşamaları tek tek anlatalım.

1- Basics

İlk aşamada temel bir Microsoft Azure hizmet oluştururken ihtiyaç duyduğumuz adı ne olmalı, hangi resource group altında oluşacak, hangi regionda barınacak gibi sorulara cevap veriyoruz.

  • Subscription: Workspace yetkiniz olduğu hangi azure faturalandırma hesabı altında var olacak.
  • Resource Group: Workspace hangi azure kaynak grubu altında olacak. Henüz bir kaynak grubunuz yoksa bu aşamada Create New diyerek yeni bir kaynak grubu oluşturabilirsiniz.
  • Managed Resource Group: Azure Synapse Analytics workspacesi oluşurken yanında bir kaç hizmet daha ayağa kalkacak bu hizmetler hangi grup altında oluşsun bunu belirliyoruz. Boş geçersiniz bizim yerimize otomatik bir isim verecek.

Sırada workspace detayları var 🤓

  • Workspace name: Oluşturcağımız workspace bir isim verelim.

    Çalışma alanı adı 1 ila 50 karakter uzunluğunda olmalıdır. Çalışma alanı adı bir harf veya sayı ile başlamalıdır. Çalışma alanı adı bir harf veya sayı ile bitmelidir. Çalışma alanı adı benzersiz olmalıdır.

  • Region: Oluşacak olan workspace bir Azure Hizmeti olduğundan ülkemize en yakın Region seçimi yaparak ilerleyebiliriz.

  • Select Data Lake Storage Gen2: Bir lake hause projesinin olmazsa olmazları txt, csv, json gibi dosyalarımız barınacağı bir Storage hesabı oluşturalım.

  • Account Name: Storage Account adını girelim veya var olacak bir Account seçip ilerleyelim.

  • File System Name: Storage Account altındaki bir file system seçelim yoksa Create New diyerek yeni bir tane oluşturalım.

Basics sayfası bu kadar. 🙃 Security aşamasına ilerleyebiliriz.

2- Security

Adından da anlaşılacağı gibi çalışma alanınız için güvenlik seçeneklerini yapılandıracağımız aşamadayız.

Bu aşamada bizi ilgilendiren kısım; SQL administrator credentials workspace altında oluşturacağımzı dedicated veya serverless sql pool veri tabanlarına hangi bilgilerle erişeceğimizi burada belirliyoruz.

next next please 👉

3- Networking

Oluşturacağımız çalışma alanımızın temel ağ ayarlarını yapılandırın.

Bu aşamada özel bir sanal network tarzı bir yapıya ihtiyacınız yoksa varsayılan ayarları bırakıp diğer sayfaya ilerleyebiliriz.

4- Tags

Oluşturduğunuz herhangi bir Microsoft Azure hizmetine etiket vererek hizmetleri ayırarak gruplayabilirsiniz. Bunun amacı kategorilere ayırdığınız hizmetlerin faturalandırma, kullanım gibi detaylarını daha iyi analiz edebilmek.

Zorunlu bir aşama değil boş bırakıp da ilerleyebiliriz.

5- Review + create

Önceki adımlarda herhangi bir şeyi atlamayıp isimlendirme vs konusunda hata almadıysak başlamaya hazırız. Synapse Analytics ilk oluştuğunda içerisinde default olarak gelen Serverless SQL‘nin fiyatlandırmasına ve altında workspace ile ilgili detayları görüyoruz.

Artık hazırız! 🚀 Sonraki yazıda görüşmek üzere.

[/vc_column_text][/vc_column][/vc_row]

Windows Server 2022 artık genel kullanımda!

Merhaba sevgili okurlar,
Bugün Windows Server 2022’nin artık genel kullanıma sunulduğunu haber vermekten heyecan duyuyoruz. Bu, hem büyük şirketler hem de küçük işletmeler tarafından işlerini ve kritik görev iş yüklerini yürütme konusunda güvenilen işletim sistemi için ileriye doğru atılmış büyük bir adım.

windows server 2022

Windows Server 2022 ile müşteriler, iş yüklerini güvenli bir şekilde çalıştırmaya, yeni hibrit bulut senaryolarını etkinleştirmeye ve uygulamalarını gelişen iş gereksinimlerini karşılayacak şekilde modernize etmeye devam edebilirler. İsterseniz hemen Windows Server 2022’nin yeni teknik özelliklerine ve müşterilerin sunucu ortamlarını modernize etmek için bunlardan nasıl yararlanabileceklerine bir göz atalım.

Neden Windows Server 2022’ye Geçmelisiniz?

Gelişmiş çok katmanlı güvenlik

Güvenlik her zaman Windows Server’ın temel taşı olmuştur. Windows yine müşterileri için güvenliği ön planda tutarak, Windows Server 2022’de çok sayıda güvenlik geliştirmesi sunuyor. Bu sürümde müşteriler, Güvenli çekirdekli sunucu ve güvenli bağlantı ile çok katmanlı güvenlikten yararlanabilir. Güvenli çekirdekli sunucu, Windows’un donanım ortaklarının, müşterilerin kritik sistemlerinin güvenliğini güçlendirmelerine yardımcı olmak için donanım, bellenim ve sürücüler sağladığı anlamına gelir. BT ve SecOps ekiplerinin, Secured-core (güvenli çekirdek) sunucusunun gelişmiş koruması ve donanım, bellenim ve sanallaştırma katmanlarında önleyici savunması ile ortamlarında geniş kapsamlı güvenlik sağlamalarına olanak tanır.

Windows Server 2022’deki güvenli bağlantı, taşıma sırasında güvenliğe başka bir katman ekler. Yeni sürüm, sunucu mesaj bloğu (SMB) protokolü desteği ile daha hızlı ve daha güvenli şifrelenmiş güvenli hiper metin aktarım iletişim protokolü (HTTPS) ve endüstri standardı AES-256 şifrelemesi ekler.

Azure ile Hibrit Özellikler

Müşteriler, işletmelerini dijital olarak dönüştürmek için hibrit ve çoklu bulut yaklaşımını seçiyor. Artık Azure Arc ile bağlanarak şirket içi Windows Server 2022 ile bulut hizmetlerinden yararlanabilirler.

Aynı zamanda, Windows Server 2022’de müşteriler SMB Sıkıştırma (SMB Compression) gibi Dosya Sunucusu geliştirmelerinden yararlanabilir. SMB Sıkıştırma, bir ağ üzerinden aktarılırken verileri sıkıştırarak uygulama dosyasının aktarımını iyileştirir. Son olarak, yöneticiler tarafından oldukça sevilen bir araç olan Windows Admin Center, Azure bağlantılı senaryolar için yeni bir olay görüntüleyici ve ağ geçidi proxy desteği gibi modern sunucu yönetimi deneyimi getiriyor.

Esnek uygulama platformu

Windows Server 2022’ye yükseltme yapan müşterilerin, Tier1 uygulamaları talep edenler için 48 TB bellek ve 64 fiziksel yuvada çalışan 2.048 mantıksal çekirdek desteği gibi ölçeklenebilirlik iyileştirmelerinden yararlanması mümkün. Bu sürümde müşteriler aynı zamanda Windows kapsayıcılarına yönelik gelişmelerden de yararlanabilir. Örneğin, Windows Server 2022, Windows kapsayıcılarının uygulama uyumluluğunu iyileştirir, düğüm yapılandırması (node configuration) için HostProcess kapsayıcılarını içerir, IPv6 ve dual-stack’i destekler ve Calico ile tutarlı ağ ilkesi uygulamasını sağlar. Ayrıca, Windows Server 2022 kapsayıcı desteğini etkinleştirmek ve yeni özellikleri Azure Kubernetes Hizmetine (AKS) ve Azure Stack HCI üzerinde AKS’ye getirmek için Kubernetes topluluğuyla birlikte çalışmaya devam ediliyor.

Windows Server 2022 önizleme özellikleri hakkında daha ayrıntılı bilgi için Windows Server önizleme bloguna ve teknik belgelere göz atmayı unutmayın.

Windows Server’dan Daha Fazlasını Edinin

Geçen yıl, Microsoft yalnızca Windows Server 2022’yi tanıtmakla kalmadı. Aynı zamanda Windows Server için Azure hizmetlerini ve hizmet geliştirmelerini de tanıttı. İsterseniz Müşterilerin yararlanabileceği iki yaygın senaryo ve özelliğe hemen bir göz atalım.

Azure üzerinde: Azure Automanage (önizleme aşamasında), BT uzmanlarının yalnızca en iyi bulut uygulamalarını otomatikleştirmesine değil, aynı zamanda Microsoft bulut benimseme çerçevesiyle Microsoft’un kurumsal uzmanlığını uygulamaya koymasına olanak tanır. Windows Server için Azure Automanage ile müşteriler ağ IP’sinde herhangi bir değişiklik olmadan Azure’a kolayca geçebilir, QUIC üzerinde SMB kullanarak Azure’a güvenli bir şekilde dosya aktarımı yapabilir ve yeni Windows Server Azure Sanal Makineleri için hotpatch uygulayabilirler.

Müşteriler, mevcut uygulamaları modernize etme konusunda uygulama mimarisi ihtiyaçlarına bağlı olarak Azure’da birçok seçeneğe sahiptir. Örneğin, yerel .NET desteğine sahip Azure Kubernetes Service (AKS), müşterilerin, pek çok kişinin tercih ettiği kapsayıcı düzenleyicisi olan Kubernetes ile uygulamalarını modernleştirmesine olanak tanır.

Son olarak, müşteriler iş yüklerini Azure’a taşıdıklarında, Azure Hibrit Avantajı ve Windows Server 2008 ve 2012 için ücretsiz Genişletilmiş Güvenlik Güncelleştirmeleri gibi avantajlardan -sadece Azure’da- yararlanabilirler.

Hibrit ve şirket içi: Birçok müşteri, şirket içerisinde uygulama ve hizmet çalıştırma ihtiyacı duymaktadır. Müşteriler, Azure Arc ve Azure Stack HCI aracılığıyla sırasıyla yönetim ve sanallaştırma katmanlarını modernize edebilirler. Aynı şekilde, Windows Server uygulamalarını şirket içinde modernize etmek isteyen müşteriler, Azure Stack HCI üzerinde AKS kullanabilir.

Bir yandan Windows Server Uzun Vadeli Hizmet Kanalında (LTSC) yeni özellikler sunmaya devam edilecek. Bir yandan da Azure’da müşterilerin Windows Server BT ortamlarını modernize etmelerini kolaylaştıran yeni senaryolar da etkinleştirilecek.

Windows Server 2022 Yolculuğunuza Başlayın

Windows Server 2022, çok çeşitli özellikler içeriyor. Eğer siz de Windows Server 2020 yolculuğuna başlamak istiyorsanız, aşağıdaki yolları kullanabilirsiniz:

 

 

 

Windows 11 ile ilgili sıkça sorulan soruları ele aldığımız yazımızı buradan okuyabilirsiniz.

Yeni özellikler ve güzel haberlerle görüşmek dileğiyle, kendinize iyi bakın. 👩🏻‍💻

Önü Alınmayan CPU Yükselişi ve Profiling Aracılığıyla Tespit Edilmesi

Bu problem boyunca yaptığımız ciddi code refactor, test ve daha az kaynak ile daha fazla performans elde ettiğimiz çalışmaları makale içerisine dahil etmedim. 8 Mart 2021 günü 2 Instance olacak şekilde Azure Web Application’da çalışan Velocity uygulaması bir anda CPU göstergelerinde ciddi artışlar olduğu ile ilgili hatalar fırlatmaya başladı. PEAKUP’da bu tarz problemlere yaklaşımımız genelde “öncelikle yangını söndür, söndüremiyorsan kontrol altına al ve süreci inceleyip, problem ortadan kaldır” şeklindedir.

Her ne kadar Auto Scaling ile ilgili Azure ayarlarını yapmış olsak da her bir Velocity müşterisi onboarding (tüm içeriklerin girildiği ve kullanıcı eğitimlerinin verildiği) sürecini tamamladıktan sonra kendi içerisindeki kullanıcılarına portal kullanımını duyurdukları zaman sistemi ikinci bir ekranda genel olarak izliyoruz. Anlık gelen kullanıcı sayısını Power BI üzerinden kendi geliştirdiğimiz Analytics Tool’u ile izliyoruz. Bu tarih için planladığımız, olası ansızın gelebilecek bir yük yoktu. Ancak ürünün kullanımı gereği bazı müşteriler portal içerisinden duyuru yaptığında da ansızın bir yük gelebiliyordu. Bu durumda Azure üzerinde otomatik olarak ölçeklendirme için CPU, Memory vb. metrikler üzerinde kurguladığımız alarmlar devreye giriyor ve anında olası bir problemin önüne geçiyorduk.

Bu defa taşıdığımız yük, günlük trafiğimizin ortalamasında olmasına rağmen 12 Instance açıkken bile bir türlü CPU ile ilgili problemi çözemiyorduk. Üzerinden toplantı odaları, yaklaşan toplantılarım vb. bilgileri çektiğimiz ONE uygulaması ve Authenticator uygulaması da herhangi bir spike ile karşı karşıya kalmamasına rağmen Velocity’de sıra dışı bir durum vardı.

Problemi gidermek için kontrol ettiğimiz, denediğimiz bazı adımlar;

  • Bağlı çalışan tüm diğer uygulamaların kaynakları ve veri tabanları yeterli seviyede yükü kaldırıyor mu?
    • Buradaki amacımız Velocity ve diğer tüm ürünlerimizin ortak olarak kullandığı Authenticator ya da bağlı olduğu herhangi bir servisin veritabanı tarafında ya da backend tarafda gönderdiğimiz talepler karşısında herhangi bir bottleneck yaşanıp yaşanmadığını kontrol etmek oldu. Hiçbir problem tespit edilemedi. Aksine fazla kaynak rezerve edildiği tespit edilip bazı kaynaklarda düşüşe gidildi.
  • Öncelikle SQL Server içerisinde Created alanına göre anormal bir veri artışı var mı?
    • Bazı müşteriler ürünü beyaz ve mavi yaka şeklinde ayırıp bu kullanıcılara portallarını belli bir arayla açabiliyorlar. Son gelen kullanıcı sayısında herhangi bir ani artış olup olmadığını inceledik. Ek olarak Velocity’nin free versiyonu tarafından gelebilecek olası bir artış var mı yok mu bu metrikleri kontrol ettik ve sıradışı bir durum tespit edemedik.
  • JSON Formatındaki Verinin Büyüklüğü Bizi Ne Kadar Etkiliyor?
    • Neredeyse iki yıllık haberleşme kayıtlarını, günlük verilerin girildiği, yüzbinlerce telefon numarasının olduğu bazı widgetların içerisindeki veriler işlenirken acaba CPU tarafında buna bağlı bir kilitlenme mi var sorusu aklımıza geldi. Bunun için müşterilerimizden en büyük veriye sahip olan Widgetlardan beş tane seçip bunlara, test ortamında random veriler girmeye başladık ve CPU tarafında hiçbir değişim olmadığını tespit ettik. Sorun yine çözülmedi!
  • Diğer uygulamalara bağlanıp veri çeken Widgetlarımız(Twitter, Toplantı Odaları, İzin Uygulaması, Haberler vb.) widgetlar tarafında mı bir problem var?
    • Bir Intranetin en önemli olan hizmetlerinden olan Toplantı Odaları, Yaklaşan Toplantılarım, Dış Kaynak Haberleri, Bugün Kimler Uzaktan çalışıyor gibi katma değeri en yüksek ama en fazla CPU tüketimi sağlayan widgetları tek tek kontrol ettik. Her birisini teker teker kullanımdan kaldırıp sonrasında CPU ile ilgili durumu monitör ettik. Ciddi bir düşüş gözlemlendi.
  • Problem Spesifik bir serviste mi? Başka servisleri de etkiliyor mu?
    • Bunu görmek için, Velocity’nin kullandığı tüm servislere Apache’nin AB toolu ile hem localde hem de DEV Stage içerisinde Linux bir makine üzerinden 1000 tane 50 Concurrent request göndererek metrikleri takip ettik. Velocity dışında One servisinde bir problem keşfedildi ve giderildi. Ancak sorun Velocity tarafında sürmeye devam etti.

Yüksek CPU kullanacak tüm Widgetları tek tek incelemeye başladık. Önce portaldan kaldırıp sonrasında oluşan yükün artış veya azalış durumuna göre hareket edecektik.

İlgili widgetlarla ilgili tam bir factoring süreci başlatmak üzereyken problemin tekrar yaşandığını ancak bu defa CPU’daki yükselişlerin daha kısa süre içerisinde normale döndüğünü gözlemledik.

Problemin JSON tipindeki verileri işlediğimiz bir aşamadan kaynaklanmadığından emindim. Çünkü CPU tarafındaki kaynakları tüketebilecek diğer tüm işlemler (Image Processing, Video Processing) başka bir servis içerisinde, döviz-hava durumu gibi widgetlar da başka bir servis içerisinden geliyordu. Bu nedenle JSON tarafında en çok işlem yaptığımız methodları inceleyip tekrar testlere başladık.

Velocity içerisindeki Dependency Injection apısı tamamen kullanıcını yaptığı ilk request sonrasında kurgulanmaktadır. Kullanıcının bağlı olduğu Tenant Hybird mi yani İstanbul’daki bir sunucuda mı çalıştığı yoksa Azure üzerinde Cloud’da mı çalıştığı yapılan ilk requestten sonrasında kurgulanmaktadır. Bu aşamada gelen kullanıcının kim olduğunun tanımını yapan endpointi yani tüm isteklerin aktığı OnActionExecutionAsync methodunu incelemeye başladım.

HttpClient kütüphanesi bu gibi arka arkaya yapılan işlemler için önerilmediğinden dolayı IHttpClientFactory tarafından aldığımız CreateClient methoduyla gelen tüm HttpClient objelerini saatlik olarak isimlendirmeye başladık.

İlk başlarda yaşadığımız spike problemi devam etse de CPU’daki %100 ve üzeri oranda takılı kalma problemi yine süre olarak ciddi anlamda düşüş gösterse de problem hala devam etti.

Problemi daha detaylı incelemek için Azure’un Web Application’a özel olarak sunduğu, tüm metrikleri inceleyebileceğiniz bir uygulaması bulunmaktadır. Bu uygulama application Insight olarak geçer. Velocity’de temel özellikleriyle birlikte açık olan bu uygulamanın tüm Profiling ile ilgili özelliklerini açmaya karar verdik.

Kaynakları arttırmaya devam edip, Azure Application Insight ile problemi araştırmaya, metrikleri toplamaya devam ederken şununla karşılaştık. Application Insight sonrasında ortalama olarak çok küçük sayıda diyebileceğimiz isteklerde bile uygulamada CPU %110’ün üzerine çıkmaya başladı. Araştırdığımızda buna başka geliştiricilerin de maruz kaldığını öğrendik. Haliyle Application Insight tarafını tamamen kapattık ve sorun büyük oranda çözülmüş gibi görünmeye başladı.

 

Sonrasındaki bir hafta boyunca herhangi bir problem olmadan devam eden süreç ilerleyen zamanlarda yüksek Memory Exception hatalarıyla tekrar baş göstermeye başladı… Uygulamalarımızı Web Application içerisinde InProcess olacak şekilde doğrudan IIS’e vermekteydik. Application Insight’ın yarattığı yükü kaldırmak ve direkt olarak performansı koruyabilmek için Kestrel üzerinden bir Reverse Proxy yarattık ve artık hataları çok daha derinlemesine görmeye başladık.

 

Uygulama içerisinde Kestrel sayesinde her bir Request ve SQL sorgusunun çıktısını görmeye başladık. Artık Application Insight’ı açıp bunun yanında ek olarak uygulamanın çalıştığı anda yarattığı hataları görebilir hale geldik. Takım arkadaşlarım Fatih Doğan ve Fatih Memiş’in de bu aşamada dahil olduğu süreçte Code Review aşamasına geçtik. Bottleneck (dar boğaz) yaşadığımız yerin daha uygulamaya gelen ilk isteğin işlendi süreçten başlayıp son aşamasına kadar bütün kodu satır satır kontrol etmeye başladık. Bu esnada artık Kestrel’dan hem daha mantıklı hem de daha yardımcı olacak hataları almaya başladık. Zira uygulama bir yerden sonra CPU tarafında herhangi bir problem yaşamasa da memory tarafında ciddi şekilde sorunlar yaşadığımızı ve bunun kurguladığımız Dependecy Injection mimarisinden oluştuğunu keşfettik.

Normal web uygulamalarında tüm Dependency’ler Startup içerisinde tanımlanırken, Velocity’de neredeyse bütün database ile alakalı Dependency’ler ilk requesttin geldiği BaseController içerisinde tanımlanıyor. Bunun sebebi gelen talebi karşılarken minimum seviyede kaynağı ayağa kaldırmak ve bazı davranışsal değişikliklerin request bazında olabilmesini sağlayabilmektir.

Dependency yapısını yönetmek için Startup.cs içerisinde ayağa Singleton olarak kaldırdığımız IServiceCollection Instance’ı problemin ana kaynağı gibi görünmeye başladı.

İhtiyaç olduğu kadar Depdency’i ayağa kaldırdığımız aşamada kullandığımız IServiceCollection sınıfının Scope ile ilgili işlemler bittikten sonra artık kullandığı kaynakları Memory’den atmadığını ve bunun bütün uygulamayı etkilediğini fark ettik. Normalde içerisinden çektiğimiz BuildServiceProvider methodu ile çektiğimiz bir servisi artık IServiceProvider ile yüklemeye karar verdik.

Geçişi sağladıktan sonra metrikleri takip ettiğimizde çok ciddi düşüşün olduğunu fark ettik. Bottleneck’e sebep olan şeyin Startup’da Singleton olarak eklediğimiz IServiceCollection Instance’ının BaseController içerisinde tekrar yeni bir IServiceCollection üzerinden alınması olduğunu keşfettik ve IServiceCollection yerine IServiceProvider ile ihtiyacımız olan Dependency kurgusunu sağladık. Böylece sorun ortadan kalkmış oldu.

Bu süreçte yaşanan sorunlar nedeniyle bizi hoşgörüyle karşılayan tüm Velocity müşterilerine, Fatih Doğan, Fatih Memiş ve tüm Velocity takımına teşekkür ederim.

Microsoft 365 Threat Protection ve ATP Ürün Ailesine Genel Bakış

Koruma, ilk olarak kullanıcı kimliğiyle başlar ve tüm Microsoft 365 kullanıcı kimlikleri Azure Active Directory (Azure AD) temel alınarak Azure Active Directory Identity Protection tarafında korunur. Azure AD Identity Protection, kimlik gelişimlerine karşı otomatik olarak koruma sağlamak ve çeşitli gelişen risklere karşı kullanıcı bilgilerini güvence altına almak için dinamik zeka ve makine öğrenim dilini desteklemektedir. Bu nedenle Office 365 kullanıcı kimlikleri bir adım daha güvence altındadır. Microsoft 365 threat protection, e-posta yoluyla gönderileni bilinmeyen gelişmiş tehdit ve saldırıları durdurmaya yardımcı olan Office 365 ATP ile maillerinizi korur. Office 365 ATP sayesinde, tüm e-posta üzerindeki linkleri ve eklentileri kontrol ederek zararlı olup olmadığını belirleyip, zararlı olduğu fark ettiğinde taktirde maili farklı bir kullanıcıya daha göndermeden direk o maili siler. Saldırılar geniş çaplı olduğundan dolayı, bazı saldırılar direk cihazlara da yapılır. Fidye yazılımı içeren bir siteyi ziyaret eden bir kullanıcı yanlışla fidye yazılımını windows 10 bilgisayarına indirdiğini varsayalım. Böyle bir durumda Microsoft Edge, bu sitenin kötü amaçlı olup olmadığını belirleyen, erişimi engelleyebilen ve fidye yazılımların ilk adımında güvenliği ele alan Windows Defender ATP’nin tarayıcı koruma özelliğini kullanır. Windows Defender ATP, Windows Defender Antivirus, AppLocker ve Windows Defender Device Guard gibi makinelerde varolan Windows güvenlik teknolojileriyle çalışır. Fidye (Ransomware) saldırıları aynı zamanda bulutta çalışan iş yüklerini hedef alır. Bu tarafta ise Azure Security Center, Azure ve On-prem iş yüklerinizin güvenlik durumuna yönelik hızlı bir görünüm sağlayarak iş süreçlerinizin güvenliğini keşfedip değerlendirmenize ve riski belirleyip azaltmanıza yardımcı olur. Güvenlik çözümlerine yeni ve ek olarak sunulan Azure Advanced Threat Protection (ATP)’de, ağlarınızdaki güvenlik olaylarını tespit etmenize ve araştırmanıza yardımcı olan, bulut tabanlı bir güvenlik çözümüdür. Aynı zamanda siber saldırılarına ve içeriden dışarıya bilgi sızdırma gibi tehditlere karşı koruma sağlamanıza yardımcı olur.


Microsoft’un Office 365 ATP, Azure ATP ve Windows Defender ATP’den oluşan Advance Threat Protection Güvenlik çözümleri bulunmaktadır. Bu Güvenlik çözümleri güvenlik sırasına göre aşağıda sunulmaktadır.

1.Office 365 ATP: E-postanızı bilinmeyen ve gelişmiş saldırılara karşı gerçek zamanlı koruma sağlayan bir güvenlik çözümüdür. Güvenli olmayan eklere karşı koruma sağlayarak ve korumayı kötü amaçlı bağlantıları da içerecek şekilde genişleterek, Exchange Online Protection’ın güvenlik özelliklerini tamamlar ve daha iyi bir koruma sağlar. Güvenli Eklerle, imzaları biliniyor olsa bile kötü amaçlı eklerin ileti ortamınızı etkilemesini önleyebilirsiniz. Tüm şüpheli içerik, makine öğrenme tekniklerini kullanan ve içeriği etkinlik açısından değerlendiren; gerçek zamanlı, davranışsal bir kötü amaçlı yazılım çözümlemesinden geçirilir. Güvenli olmayan ekler, alıcıya gönderilmeden önce detonasyon odasında korumalı alana yerleştirilir. Bunun avantajı, kötü amaçlı yazılım içermeyen ve daha temiz bir posta kutusu elde etmektir.

  • Bilinmeyen kötü amaçlı yazılım ve virüslere karşı Güvenli Ekler özelliğini kullanarak dayanıklı koruma sağlama
  • Güvenli Linkler özelliğini kullanarak kullanıcıları zararlı linklerden koruyan, kötü amaçlı sayfalara karşı gerçek zamanlı, tam koruma.
  • Yöneticileri organizasyonlarındaki olası tehlikelere karşı uyaran zengin bildirim ve URL takip özellikleri.
  • Herhangi bir tehlike anında veya sonrasında mesajlarınıza erişme imkanı

2.Windows Defender ATP: Gelişmiş kötü amaçlı yazılımları tespit edilen ve cihazlarda cihaz seviyesinde koruma sağlan bir güvenlik çözümüdür. Aynı zamanda Akıllı koruma, tespit, araştırma ve yanıt için güvenlik platformu sağlar. Windows Defender ATP, gelişmiş saldırıları ve veri ihlallerini algılar, güvenlik olaylarını otomatikleştirerek cihazın güvenliğini arttırır.

  • Endpoint behavioral sensors: Windows 10 içersinde yer alan sensorler sayesinde, işletim sisteminden davranış sinyalleri toplarak Windows Defender ATP yönetimi portalına işler. İşlenen veriler ise iş süreçleri, kayıt defteri, dosya ve ağ iletişimleri gibidir.
  • Cloud security analytics: Windows ekosistemindeki güvenliği ön planda tutup, davranış sinyalleri üzerinde belirli analizler yapılmasını sağlar.
  • Threat intelligence: Windows Defender ATP’nin saldırgan araçlarını, tekniklerini, prosedürlerini tanımlamasını ve toplanan sensör verilerindeki bilgilere göre uyarılar üretir

Not: Windows bilgisayarlarındaki yaygın kötü amaçlı yazılımlardan korunmak için Malicious Software Removal Tool yazılımını kullanabilirsiniz. MSRT tehditleri bulur ve kaldırır ve bu tehditler tarafından yapılan değişiklikleri tersine çevirir
3.Azure ATP: BT Yöneticilerinin bir ağ içindeki (kötü amaçlı olmayan) saldırganları, ne yaptıklarını ve gerçekleştirecekleri eylemleri izlemesini sağlar.

  • Şüpheli kullanıcı ve cihaz etkinliğini öğrenme akabinde analiz etme
  • Bulut ve kurum içi ortamlardaki tehditleri algılama
  • Active Directory’de depolanan kullanıcı kimlik bilgilerini koruma ve analiz etme
  • Windows Defender Advanced Threat Protection ile entegrasyon sağlayarak araştırma ve analiz seviyesini arttırma

Not: Tüm bunlar E5 lisanslama modeli ile sunulmaktadır.
Azure, Office 365 ve Windows Defender Advanced Threat Protection birlikte daha iyi çalışır

  • Kötü amaçlı yazılım saldırılarının çoğu e-postadan geldiğinden, Office 365 ATP güvenlik katmanın ilk halkasını oluşturur
  • Office 365 ATP, kötü amaçlı yazılımı tanımlamakta başarısız olursa, Aygıtlar tarafında Windows Defender ATP, cihazdaki anormal ve garip davranışı tanımlayarak kötü amaçlı yazılımları yakalamaya çalışır.
  • Kimlik hırsızlığı başarılı olursa, saldırganın Azure ATP aracılığıyla makineden diğerine geçmek için bu kimliği nasıl kullandığını izleyebilirsiniz.

Azure Advanced Threat Protection (Azure ATP) Bileşenleri ve Mimarisi Part-2

Azure ATP Mimarisini aşağıdaki resimde inceleyebilirsiniz.


Azure ATP standalone sensoru, fiziksel veya sanal switch’ler kullanarak (Port Mirroring) domain ortamınızdaki ağ trafiğini izlemektedir. Yada Domain controller sunucusuna Azure ATP sensorünü kurduğunuzda doğrudan event log’lara erişim sağlayabilirsiniz. Bu sebeple network ağınızda herhangi configurasyon yapmanıza gerek kalmayacaktır. Bu iki seceneği de ortamınızda konumlandırabilirsiniz. Bununlarla birlikte toplanan logs ve event’larınızı Windows Event Forwarding (WEF) veya SIEM entegrasyonu üzerinden Azure ATA ye gönderebilirsiniz.

Not: Default olarak, en fazla 100 Azure ATP sensorü desteklemektedir.

Azure ATP’i oluşturan bileşenler aşağıdaki gibidir.

  • Azure ATP workspace management portal
  • Azure ATP workspace portal
  • Azure ATP sensor
  • Azure ATP standalone sensor

Azure ATP Yönetim Portalı ve Çalışma Alanı Portalı gereksinimleri
Azure ATP yönetimi ve çalışma portalına erişim aşağıdaki tarayıcıları ve ayarları desteklemektedir.

  • Microsoft Edge
  • Internet Explorer sürüm 10 ve üstü
  • Google Chrome 4.0 ve üstü
  • Minimum ekran genişliği çözünürlüğü 1700 piksel olmalı
  • Güvenlik duvarı/proxy Azure ATP bulut hizmetiyle iletişim kurmak için açık olması gerekir: *. güvenlik duvarı/proxy’de atp.azure.com bağlantı noktası 443‘tür.

Azure ATP standalone sensor gereksinimleri
Azure ATP standalone sensor Windows Server 2012 R2 veya Windows Server 2016 çalışan sunuculara yüklemeyi desteklemektedir. Standalone sensor domain veya workgroup olan bir sunuculara da yüklenebilir.
Azure ATP sensor gereksinimleri
Azure ATP sensor Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 çalıştıran domain üzerine yüklemeyi desteklemektedir. Domain Controller read-only domain controller (RODC) olabilir. Yükleme sırasında .net Framework 4.7 yüklenir ve yükleme sonrasında sunucuyu yeniden başlatmak gerekir. Azure ATP sensor en az 2 CPU ve 6 GB RAM gerektirir.
AZURE ATP CAPACITY PLANNING
AZURE ATP korumasını ortamınıza dahil etmeden önce, Azure ATP kapasite planlaması yapılması gerekir. Azure ATP kapasitesini belirlemenin en basit ve önerilen yolu,
Azure ATP Sizing Tool ‘unu kullanmaktadır. Bu tool’u çalıştırdığınızda size bir excel raporu sunmaktadır. Bu rapor içinde sunucunun CPU ve RAM degerleri belirlenmektedir. Bu degerlere göre Azure ATP sensorünü kullanmanız önerilir.

 

Azure ATP ve Microsoft ATA arasındaki farklar nedir? Part-3

Her iki üründe verilerini şirket için (Active Directory) domain ortamında alırken, Microsoft ATA tamamen şirket için çalışan bir servis olup, Azure ATP ise Azure tarafında barındırılan ve verileri bulut ortamında analiz eden bir bulut servisidir.


Aşağıdaki tabloda arasındaki genel farklar bulunmaktadır.

Feature Azure ATP Microsoft ATA
Environment On-premises & Cloud data sources On-premises
Windows Defender ATP Integration Yes No
Data Storage Sent to Azure On-premises
Deployment Azure Cloud ATA Center
New Sensor Gateway
Updates Automated via Azure Cloud Manual via ATA Center
Domain Controller Agent Sensor: up to 100K pps Lightweight Gateway:
Up to 10K pps
Licensing EMS/Microsoft 365 E5 EMS E3
Standalone Standalone
 Releases   Current Version – 1.9 
Regular Updates (Released March 2018)

Azure ATP Kurulumu ve Yapılandırılması Part-4

Ürün ile ilgili gerekli network ortamını sağladıktan sonra (Sensor), Azure ATP workspace portalına bağlanabiliriz. Erişim sağlayan kullanıcının global administrator veya security administrator yetkilerine sahip olması gerekir. Yetkili kullanıcı
https://portal.atp.azure.com/
adresine tıkladığı taktirde doğrudan Azure ATP workspace alanına erişim sağlayabilir.


Create Workspace butonuna tıklayarak, yeni bir çalışma alanı oluşturabilirsiniz.


Çalışma alanının ismini ve lokasyon bilgilerini güncelledikten sonra, Create butonu ile çalışma alanı oluşturulur. Oluşturalan çalışma alanı primary olarak düzenlendiğinde, Windows Defender ATP ile doğrudan entegrasyon yapılabilir. Primary olarak ayarlanmadığında Azure ATP ile Windows Defender ATP entegrasyonu yapılamamaktadır.

Not: Primary olarak ayarlanmamış bir çalışma alanına Windows Defender ATP entegrasyonu yapılmak istenildiğinde tüm yapıyı silip, yeniden primary olarak ayarlanması gerekir.


Çalışma alanını ilk kez açtığınızda sizi yukaridaki gibi bir pencereye karşılayacaktır. Burada kullanıcı erişim bilgileri Active Directory’unuzdeki bir kullanıcı hesabı olması gerekir.

Not: Bu kullanıcıya read-only user yetkisi verilir.


Directory Services bölümünden gerekli domain ayarlarını yaptıktan sonra, Azure ATP kurulumu paketini ister özel bir sunucuya, isterseniz AD sunucusuna indirebilirsiniz.


Sensors bölümünde Azure ATP sensor yazılımı indirebilirsiniz. Ayrıca yazılımın Azure ATP portalı ile iletişim kurabilmesi için Access key gereklidir.

Access key; kimlik doğrulama ve TLS şifreleme işleminden sonra bir kerelik kullanıma sunulan paroladır.


Çalışma alanından indirmiş olduğumuz Azure ATP Sensor yazılımını çalıştıyoruz.


Yüklenen sunucuda .Net Framework 4.7 yüklü değil ise Azure ATP Sensor paketi ile birlikte .Net kurulumu gerçekleştirilir.


.Net Framework 4.7 kurulumu tamamlandıktan sonra, Azure ATP kurulumu ekranı gelmektedir. Dil ayarını yapıp ilerliyoruz.


Azure ATP Sensor yazılımı, kurulum yapılacak sunucuyu denetleyerek Sensor veya Standalone Sensor mu? olması gerektiğini karar verir. Kurulumu AD üzerindeki bir sunucuya yapıldığından dolayı Sensor butonu aktif olarak gelmektedir.


Bir sonraki kurulumu ekranına geçtiğimizde bu pencerede kurulum lokasyonu ve Access key bilgileri bulunmaktadır. Lokasyonu değiştirmeden Azure ATP çalışma alanındaki Access key girilerek ilerlenir.


Bu şekilde Azure ATP Sensor kurulumu tamamlanır.


Azure ATP yönetimi portalında Sensors bölümüne geldiğimizde Service Status kısmından sunucu(DC01) ile iletişim halinde olduğunu görebilirsiniz.


Azure ATP’nın bağlı olduğu sunucu ismine tıkladığımızda Description – Domain Controllers (FQDN) – Capture Network adapters – Domain synchronizer candidate başlıklarını bulunmaktadır. Bu tarafta FQDN bölümü otomatik olarak ilk yapılandırmayla birlikte gelmektedir. Capture Netwprk Adapters ise Azure ATP sensorunun bağlı olduğu bilgisayarlardaki network’u simgeler. Domain synchronizer candidate Azure ATP ve Active Directory arasındaki senkronizasyondan sorumlu bölümdür.