Microsoft Teams’in hayatımıza girmesi ile beraber Skype For Business Online tarafından Microsoft Teams’e geçişlerde hız kazanmaya başladı. Özellikle Microsoft’un “1 Ekim 2018” tarihi itibari ile 500 kullanıcı ve altı lisansa sahip olan yeni Office 365 müşterilerinde Skype Online servisini kapatma kararı almıştı. Bu da bir anlama Office 365 geçişlerinde artık firmalar 500 kullanıcı altı ise direk Microsoft Teams ile başlıyor, buda kurumsal iletişimlerini bu platform üzerinden devam ettirmeleri anlamına geliyor. Mevcuttaki Skype For Business Online lisansına sahip olan tenant’larda ise Microsoft Teams geçişi yapılana kadar kullanım devam ediyor fakat burada Microsoft’un özellikle Teams geçişlerinde firmalara verdiği önemi atlamamak gerek , bu işin üzerinde ciddi yatırımlar yapıyorlar ve geçişler konusunda firmalara ciddi destek sağlamaktalar. Tenant’lar üzerinde Microsoft Teamse geçiş admin center üzerinde planlanabilmektedir. En çok sorulan sorular arasında yer alan Skype For Business’ın Online üzerinde ne zaman sonlandıracağı konusunda ise Microsoft net bir tarih vermezken Skype For Business Online supportun süreceğini fakat vizyon olarak Microsoft Teams tarafına ağırlık vereceklerini açık açık belirtmekteler. Skype For Business On-Premise tarafta 2019 sürümü ile beraber hayatına devam ediyor olacak. Skype For Business 2019 hybrid yapılarda artık Skype For Online migration dışında Teamse de user migration işlemini yapabiliyor olacağız. Microsoft , Skype For Busines 2019 sürümünde Teams ile uyumluluğa önem vererek alt yapıyı bunun üzerine kurgulamış oldu.

Microsoft’un Teams ile amacı aslında sohbet , ses , video , toplantı , içerik erişimi dışında ekipleri bir araya getirerek çalışmalarını tek ekrandan sunmak ve üretkenliği arttırmak üzerine kurulu buda yeni bize yeni bir deneyim yaşatmaktadır. Zaten Teams , back-end infrastructure olarak Skype for businessı içermekle beraber bandwidth tüketiminde daha efektif , machine learning yetenekleri , minumum maintenance ve upgrade üzerine inşa edilmiştir. Bu dönüşüm sürecinde bir yandan Microsoft 365 Admin Panel üzerinde de IT ekiplerinin alması gereken bir takım aksiyon listesi bulunmaktadır. Geçiş öncesi bu ayarların yapılması yönetilebilirliği sağlamak adına işleri daha kolaylaştırıyor olacak.

Microsoft Teams uygulamasının Deployment’ı için izlenecek olan adımları daha önceki makalemde paylaşmıştım bu linkten göz atabilirsiniz.

Deployment öncesi Teams Admin Center’da alınabilecek aksiyonları hem kısaca açıklıyor hemde nasıl konfigürasyon yapmamız gerektiği konusunda kendi deneyimlerimi paylaşıyor olacağım.Buradaki her bir teknik özellik için yakında zamanda ayrı ayrı çok daha teknik makalelerde hazırlamayı düşünüyorum. Temel olarak 30 dakika’da Microsoft Teams Admin Center nasıl yapılandırılır şimdi gelin konfigürasyon adımlarına bir göz atalım ;

Konu başlıklarımız;

• Message Translation özelliği
• External Access özelliği
• Sohbet içerik ayarları
• Teams Guest Access özelliği
• Office 365 Groups create kısıtlaması
• Meeting içerik ayarları
   

1-Message Translation özelliği

Teams içerisindeki inline message translation özelliği sohbet alanında olan yazışmaların otomatik translate edilmesini sağlamaktadır. Özellikle çok uluslu ve farklı ülkelerdeki ofislerde çalışanı olan firmalar için birbirlerinin dillerini bilmedikleri durumlarda sohbet içerisindeki yazışmayı kullanıcının Teams ayarlarındaki dil seçeneğine göre translate etmektedir. Translate edilebilen şuan 36 dil bulunmaktadır tabilide bu dil desteği her geçen gün artıyor olacaktır , güncel desteklenen dil listesine ulaşmak için göz atınız.Bu özelliği kullanıcılar üzerinde etkinleştirmek istiyorsanız eğer Microsoft 365 Admin Center altındaki Teams Admin panelini veya powershell kullanmanız gerekmektedir. Bu özellik default olarak kapalı gelmektedir.

Microsoft Teams & Skype for Business Admin Center\Messaging policies kısmında bulunan kullanıcıları tepeden etkileyen Global (Org-wide default) altından Allow users to translate messages özelliği enable edilir.

İpucu ! : ilgili özelliği enable ettiğinizde genel olarak 0-30 dakika içerisinde özellik Tenant üzerinde aktif hale gelmektedir. Fakat kullanıcıların bu özelliği kullanabilmesi adına uygulamayı kapatıp açmaları gerekmektedir. Aslında siz Tenant üzerinde bu özelliği aktif ettiğinizde bir sonraki gün kullanıcılar bilgisayaları açtıklarında bu özellikten yararlanmaya başlıyor olacaklar gibi düşünebilirsiniz.

Konuyu bir örnekle açıklamak adınahakan.marangoz@hakanmarangoz.com adlı kullanıcımdan umit.seyhan@hakanmarangoz.com kullanıcısına sohbet aracılığı ile İngilizce bir içerik yazıyorum.

Ümit SEYHAN kullanıcısı kendi Teams’i üzerinden gelen ilgili mesajı isterse translate özelliğini kullanarak kendi diline çevirebilmektedir. Buradaki kritik nokta çevir seçeneğini seçtikten sonra hangi dile çevirmek istediğini sormamakta , yanlızca Ümit SEYHAN kullanıcısının Teams arayüz dili ne ise ona otomatik translate etmektedir.

2-External Access federation özelliği

Eski Skype For Business Online admin center üzerinden ayarladığımız External access özelliği artık SFB ve Teams Admin centerının birleşmesi ile beraber Org-wide settings altından yapılandırılmaktadır. Teams’te de SFB’da olduğu gibi dış Office 365 organizasyonlarındaki SFB & Teams kullanıcıları ile iletişim kurmamızı sağlamaktadır. Burada eklemek istediğim Teams üzerinden şuan için maalesef bireysel Skype kullanıcıları ile iletişim kuramamaktayız.Aşağıdaki geçerli olan “Users can communicate with external Skype users” seçeneği sadece SFB Online kullanan müşteriler için geçerlidir.

Hali hazır’da hem Teams hem SFB Online kullanıyorsanız organizasyon’da, istediğiniz domaine erişim verebileceğiniz gibi istersenizde erişimi kapatabilirsiniz.

Default olarak External Access özelliğiinde herhangi bir değişiklik yapmamanız durumunda federation tüm domainlere açık hale geliyor olacak.

Makalenin ikinci bölümünde ayarlara devam ediyor olacağız.

Makelenin birinci bölümünde giriş yaptığımız Microsoft Teams Admin Center yapılandırma ayarlarına ikinci bölüm ile devam etmekteyiz.

Makalemin ilk bölümüne aşağıdaki link üzerinden erişebilirsiniz;

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/01/20/microsoft-teams-admin-center-ilk-dokunu-b-l-m-1.aspx

3-Sohbet içerik ayarları

Varsayılan olarak Messaging policies altında gelen ve tüm organizasyona default olarak uygulanan Global (Org-wide default) kuralındaki ayarlara göz atacak olursak ;

Owners can delete sent messages : Microsoft Teams üzerinden oluşturulan Ekip grupları içerisinde bir veya birden fazla owner (sahip) belirlenebilmektedir. Bu owner yetkisine sahip kullanıcılar ekipler içerisindeki kanalları ve ayarları yönetebilmektedir. Bu ekipler üzerinde owner yetkisine sahip kullanıcıların gönderdiği içeriği silip silemeyeceğine dair olanak sağlar.

Users can delete sent messages : Kullanıcının Teams arayüzündeki sohbet vasıtası ile gönderdiği içeriği silmesine olanak sağlar.

Users can edit sent messages : Kullanıcının Teams arayüzündeki sohbet vasıtası ile yazdığı içeriği düzenlemesine olanak sağlar.

Benim burada kişisel görüşüm kullanıcıların yazdıkları içeriklerin silinmemesi yönünde policy’i düzenlemek oluyor. Çünkü birbirlerine attıkları içeriği silerek bir takım anlaşmazlıklara yol açabilirler. Ekip sohbetler veya birbirleriyle ettikleri sohbetleri Security and Compliance Center altındaki Retention policy bölümünden saklamayı aktif etmediyseniz silinen bir mesajı’da şuan ki mimari’de geri alamıyor olacaksınız.Bunun bazı zamanlar kötüye kullanılabileceğini tahmin etmeniz mümkündür

Bir örnekle açıklamak gerekirse Hakan MARANGOZ kullanıcısı sohbet bölümünden yazdığı içeriği aşağıdaki gibi silebilmekte ve karşı taraftaki kullanıcıda bu içerik bir anda yok olmaktadır.

Mesajı silen kullanıcı ’da mesajı geri almak bir opsiyon bulunmaktadır.

Kullanıcı mesajın silindiğine dair herhangi bir uyarı almamaktadır.

Organizasyonunuzda Teams yaygınlaştırması yapmadan önce bu yukarıda belirttiğim 3 özelliği yapınıza ve şirket politikanıza göre ayarlamakta muhakkak fayda var. Mesajın delete veya edit edilmesi çokta istenilen bir durum değildir.

4-Teams Guest Access özelliği

Teams üzerinde belkide müşterilerin en çok sorduğu soruların başında Guest Access özelliği gelmektedir Microsoft Teams üzerindeki ekiplerimize , dışarıdan çalıştığımız ve projeler yürüttüğümüz kişileri bu takımlara dahil edebilmekteyiz. Bu özelliğin ismi konunun başlığından anlaşılacağı gibi “Guess Access” olarak adlandırılmaktadır.

Guest Access özelliğini şirket politika yapınıza göre enable edebilir veya disable kalmasını sağlayabilirsiniz. Guest Access özelliğini tüm organizasyona açmak istememeniz durumunda Powershell ile sadece spesifik ekiplere izin verebilir veya sadece bazı spesifik ekiplere Guest Access özelliğini kapatabilirsiniz.Fakat üretkenlik, iletişim, şirket dışında çalışan iş yürüttüğünüz firmalar ile bir arada bulunmak ve çok daha hızlı aksiyon alabilmek adına kesinlikle bu özelliği açılmasını önermekteyim.

Microsoft Teams & Skype For Business Admin Center altındaki Org-Wide Settings altında bulunan Guest Access bölümünden “Allow guest access in Microsoft Teams” seçeneğini enable etmeniz yeterlidir.

İlgili özellik Tenant üzerinde 0-24 saat içerisinde aktif hale geliyor olacak.

Bununla beraber bilgi güvenliğinide sağlamakta kesinlikle fayda var.Guest kullanıcılarının Microsoft Teams içerisindeki dahil oldukları ekip’lerde veya organizasyon içerisinde kullanacakları Chat ve Meeting özelliklerindeki uygulanacak policy’leri aşağıdan yapılandırabiliriz.Bir kaç örnekle açıklamak gerekirse Guest kullanıcılarının organizasyon içerisinde video konferans veya Screen Sharing yapıp yapamayacakları hatta ekip içerisindeki veya 1:1 sohberlerde Guest kullanıcılarının yolladıkları iletileri düzenleyip düzenleyemiyeceği veya silip silemeyeceği gibi ayarları yapılandırabiliriz. Her organizasyon’da yapılandırma tamamen şirket politikalarına göre değişeceği için bu kısımda da sizin kendi yapınıza uygun policy’i yapılandırmanız gerekmektedir.

Not ! : Burada edit ve delete kuralında sadece gönderdiği iletiyi düzenleme ve silme yetkisinden bahsetmektedir. Başkasının gönderdiği bir iletiyi zaten düzenleyememekte ve silememektedir.

Guest access özelliği ile ekibe dış organizasyondan bir kullanıcıyı dahil etmeye göz atalım. Dış organizasyondan eklemek istediğimiz kullanıcıyı ilgili ekibe geldikten sonra Manage team altındaki members bölümünden ilgili kişinin email adresini yazarak ekleyebilirsiniz. Burada kurumsal email dışında windowslive.com , gmail.com , outlook.com gibi bireysel adreslerede desteği bulunmaktadır. Eklenecek olan karşı tarafın Exchange veya Exchange Online kullanma gibi bir zorunluluğu bulunmamaktadır. İstediği platfrom’da email hizmetini kullanabilir.

Dış kullanıcıyı eklediğinizde karşı tarafa Teams ile ilgili bir davet maili gidiyor olacak. Karşı taraf ilgili davet linkini tıklayıp üyelik işlemini tamamladığında Teams uygulamasından ücretsiz olarak organizasyonunuza dahil oluyor olacak.

Makalenin üçüncü bölümünde ayarlara devam ediyor olacağız.

Makelenin birinci ve ikinci bölümünde giriş yaptığımız Microsoft Teams Admin Center yapılandırma ayarlarına üçüncü bölüm ile devam etmekteyiz.

Makalemin ilk iki bölüme aşağıdaki linklerden ulaşabilirsiniz;

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/01/20/microsoft-teams-admin-center-ilk-dokunu-b-l-m-1.aspx

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/01/20/microsoft-teams-admin-center-ilk-dokunu-b-l-m-2.aspx

5-Office 365 Groups create kısıtlaması

Microsoft Teams üzerinde kullanıcılar IT birimine ihtiyaç duymadan Teams üzerinde kendi Ekiplerini oluşturabilmekte ve ekip üyelerini ekleyerek Teams süreçlerini kendileri yönetebilmektedir. Fakat büyük yapılarda kullanıcıların, kendilerinin Ekip oluşturabilmesi takibi zorlaştırdığı için IT birimleri tarafından tercih edilen bir durum değildir. Burada Ekip oluştururken özellikle ayarlar kısmında bulunan Ekibin “private” mı yoksa “public” bir ekip mi olacağı kısmı kullanıcılar tarafından yanlış seçilen konuların başında gelmektedir. Böyle durumlarda özellikle kritik konuların ve belgelerin bulunduğu Ekiplerin datalarının diğer departmanlar tarafından görülmesi hoş olmayacaktır. Eğer IT ekipleri Teams gruplarını kendilerinin yönetiminde olmasını ve taleple açılmasını isterlerse yada bunun dışında organizasyon içinde sadece birim yöneticilerine Ekip oluşturma yetkisi tanımlamak isterlerse bunun için Office 365 portal üzerinde bir kısıtlamaya gidilmesi gerekmektedir.

İpucu ! : Office 365 üzerinde oluşturulan her bir ekip için aslında arka planda bir Office 365 Groups açılmaktadır. Bu Office 365 Groups’la beraber siz Planner , Onedrive , Onenote gibi özelliklere bu Groups altında sahip olursunuz. Varsayılan olarak Office 365 Portalı altında bir kullanıcının Office 365 Groups açma yetkisi otomatik gelmektedir yani kullanıcılar isterse çok basit bir şekilde aşağıdaki uygulamalr aracılığıyla Office 365 Groups oluşturabilmektedirler.

Outlook

SharePoint

Yammer

Microsoft Teams

StaffHub

Planner

PowerBI

Outlook 2016 Groups create

OWA Groups create

Konuyu çok fazla dağıtmadan amacımıza geri dönelim, burada hedeflediğimiz nokta Portal üzerinde Office 365 Groups create etme yetkisini herkese kapatıp sadece bizim belirleyeceğimiz bir Security Group içerisindeki memberlara bu yetkiyi tanımlamak olacak. Biz Office 365 Groups yetkisini aldığımızda belirlediğimiz kullanıcılar dışındaki kullanıcılar doğal olarak Microsoft Teams üzerinden ekip oluşturamıyor olacaklar.

Sırasıyla izlememiz gereken adımlar aşağıdaki gibidir. Kalın olarak işaretlediğim bölümlere sizin yapınızdaki değerler geliyor olacak.

1-AD Connect ile objelerinizi sync ediyorsanız Local Active Directory üzerinde “Office365Groups-Administrators” adlı bir security group oluşturunuz. Objeleriniz Azure AD üzerinde ve AD Connect tool’u kullanmıyorsanız Security Group’u direk Exchange Admin Center üzerinden oluşturunuz.

2-Kimlerin Office 365 tarafında groups create yetkisine sahip olmasını istiyorsanız o kullanıcıları ilgili Security Group’a member ediniz.

3-Bilgisayarınızda Powershell’i Administrator yetkisi ile çalıştırıp Azure Active Directory Powershell Modülünü bilgisayarınıza kurunuz.

Install-Module AzureADPreview

Powerhell üzerinden Connect-AzureAD komutu ile Office 365 Global admin yetkisine sahip kullanıcınızla giriş yaparak Azure Active Directory’e erişiniz.

Get-AzureADGroup -SearchString "Office365Groups-Administrators" komutu ile oluşturmuş olduğumuz Security Group’a ait ObjectID bilgisini öğreniyoruz. ObjectGUID numarası en sonunda doğrulama için gerekiyor olacak.

Aşağıdaki komutları tek sefer kopyalayıp yapıştırabilirsiniz.

$Template = Get-AzureADDirectorySettingTemplate | where {$_.DisplayName -eq 'Group.Unified'}
$Setting = $Template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $Setting
$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id
$Setting["EnableGroupCreation"] = $False
$Setting["GroupCreationAllowedGroupId"] = (Get-AzureADGroup -SearchString"Office365Groups-Administrators").objectid
Set-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id -DirectorySetting $Setting
$Setting.values

Son komutla beraber eğer “GroupCreationAllowedGroupID” kısmında ilgili security group’a ait ObjectID numarasın görüyorsanız yapılandırma başarıyla tamamlanmış demektir.

Yetkisi olmayan bir kullanıcı ekip oluşturmayı denediğinde aşağıdaki gibi ekip oluşturma seçeneği gelmemektedir. Ekip oluşturma seçeneği sadece yetkisi olan kullanıcılar’da aktif oluyor olacak.

6-Meeting içerik ayarları

Microsoft Teams üzerindeki Meeting aracılığıyla hem iç hem dış kullanıcılar ile toplantılar düzenleyebilir katılımcıların bu toplantılara katılmasını sağlayabilirsiniz. Meeting özelliği ile şirket içindeki farklı lokasyonlarda olan çalışanlarınızlada kolay ve hızlı bir şekilde dilerseniz günlük , haftalık veya belirli belirlediğiniz dönemlerde toplantılar gerçekleştirebilirsiniz.Özellikle şirket dışında olan müşterileriniz veya çalışmış olduğunuz iş ortaklarınız varsa biraraya gelmenin en hızlı yolu Teams Meeting özelliğinden geçmektedir. Bu meeting özelliğine aslında bir çoğumuz Skype For Business toplantılarından aşinayız. Bu yapılan online toplantılar üzerinde gelen bir takım özellikler bulunmaktadır. Karşı taraf ile masaüstü , powerspoint , whiteboard paylaşımı veya ses kayıtlarının alınması , Video konferansının yapılması gibi opsiyonlar sunmaktadır.

Adminler dilerse bu özellikleri yöneterek kurum politikasına uygun bir şekilde bu policy’leri yapılandırabilirler.

Meeting policies üzerinde yapılandırma olarak göz atabileceğiniz Genel , Ses & Video ve içerik paylaşım ayarları bulunmaktadır. Tekrar belirttiğim gibi bu özellikleri on veya off yapmak tamamen kurumların gizlilik politikasına göre değişiklik göstermektedir.

3 bölümden oluşan makale serimde temel amacım Microsoft Teams Admin Center’ı 30 dakika içerisinde nasıl hale getirebileceğimiz üzerineydi.

Umarım faydalı olmuştur , keyifli okumalar.

Bu makalemizde Azure Security Center ? Security center public cloud tabanlı olduğunda, uyarı seviyeleri nelerdir ? Security center mimarisi ve security duruşuna değineceğim.

Azure Security Center, Veri merkezi (DC) içerisinde, sistem alt yapısını işlettiğiniz tüm ürünler, servisler ve işletim sistemleri güvenliği tek merkezden yönetmeniz için tasarlanmış bir Azure servisidir. Bilinen güvenlik servisleri, protokolleri, entegrasyonu ve servislerin uzatılmasına destek sağlar. Servis uzatılmasından kastımız, hibrid cloud/otomasyon mimarilerine adapte edilebilirlik.

Ancak Azure servisi, Azure Public Cloud üzerinden anons edilip, çalıştırıldığı için, Onprem veri merkezleri ile doğrudan kıyaslanamaz. Veri merkezleri kıyaslamalarında basit görünen ama sık yaşanan konulardan bir tanesidir.

Eğer Güvenlik postür’ünden Azure Security Center’ı ele alacak olursak, platform anlamında IaaS, PaaS ve SaaS bileşenlerinin tamamını, onprem veri merkezlerinizde konumlandırdığınız ve güvenli kıldığınız gibi, Azure üzerinde ve Azure Security Center servisi ile de en az Onprem yetenekleri kadar, güvenliği, sıkılaştırmayı, denetimi ve diğer güvenlik standartlarını yakalamanız mümkün.

Peki Azure Security Center hangi güvenlik başlıklarında ve detaylarında bu imkanları adresler;

Hızlı Değişen iş yüklerinizde, yani çeşitlilik gösteren iş yüklerinizde, tek bir platform/tek bir elden , servislerinizi, servis gruplarınızı, kişi/grup servis seviyelerini ve atamalarını, en güncel güvenlik standartlarına yerine getirebilirsiniz.

Komplike bir şekilde artan ataklarda, artan iş yüklerinde beraberinde kompleksliği de getirmektedir. Public Cloud üzerinde yapılan tüm çalışmalar ve iş yüklerinin büyük bir çoğunluğu internete bakan yüzde olduğu için, eğer belirlenen güvenlik standartlarını sağlamaz iseniz, artan iş yükü beraberinde artan zafiyet yüzeyine eşlik edecektir. Bu yüzeyden kurtulmanın en kolay yolu, azure security center politikalarını takip etmektir.

Güvenlik becerilerinin yetersiz olduğunda, artan güvenlik tehditleri ve yaşanan açıklar sayısız koruma tedbirlerini ve sayısına yetişemeyeceğiniz yönetimsel işi beraberinde getirmektedir. Bu tehdit ve becerilerle kişilerin mücadelesi rakamsal yoğunluk anlamında yeterince etkin sağlanamaz, bu doğrultuda doğru kaynaklar ile optimum yönetim imkanları elde etmek adına security center’ dan istifa edilebilir.

Azure Security Center, güvenlik postürve bakış açınıza şu soruları sormanızda yardımcı olur, doğru kaynağı doğru yerlere atadınız mı? Bu atama güvenlimi değil mi ?

Zararlılara karşı koruma ve iyileştirme önerileri ile birlikte uyarılarda bulunur.

Birçok özelliği ve detayı, public cloud farkı ile hızlı, entegre ve koruma sağlayabilirsiniz.

Azure Security Center Mimarisi

Azure hizmeti içerisinde dahili olarak doğal olarak yüklü, native bir PaaS uygulamasıdır. Azure içerisinde yer aldığı için Servis Fabrik, SQL veri tabanı ve storage hesabı mevcuttur. İzleme ve koruma fonksiyonları için ve üstteki servislere kendini yazması için, herhangi bir kurulum gerektirmemektedir.

Ek olarak Security Center, Azure üzerinde olmayan sunucular, sanal makineler, bulut ve onprem kaynaklarda olan Windows veya Linux yüklü makineleri de MMA uygulaması yüklenerek, Security center içerisinde açılmasını sağlar.

Logların toplanması, işlenmesi, herhangi bir anormal aktivite izlediğinde, uyarıların takip ve iletilmesi gibi tüm çıktıları aktarmak ve çıktıların dizayn etmek mümkündür.

Security Center aktif edildiğinde, Security Center refleks olarak Azure içerisinde, Security Center alt kategorisi inşa edecektir, bu andan itibaren Security center kullanmaya karar verdiniz, ücretsiz veya standart versiyonun birisini kullanacaksınız. Versiyonları hakkında daha fazla bilgi almak için;

http://www.cozumpark.com/blogs/cloud_computing/archive/2017/07/16/azure-security-center-free-ve-standart-tier-farklari.aspx

Makalesinden faydalanabilirsiniz.

Organizasyon veya Yapının Güvenli Kılınması ve Yönetilmesi adına, Security İlkeleri ile çalışma yapmanız gerekmektedir.

Güvenliği artırılması

Azure Security Center ile güvenliğin artırılması hususunda, Azure Security Center’ı aktif ettiniz ve ardından sanal makineleri, veri servislerini, Azure ve Azure üzerinde olmayan sanal makineleri,  Azure PaaS servislerini ve tüm bu iş yükleri için kurum gözünden görünürlüğü artırmanız gereklidir.

Güvenlik Politikaları ve Uyumlulukların Yönetilmesi

Şunu hatırlatmakta fayda var, her zaman güvenlik ihtiyaçları ve iş yükleri terzi işi dizaynlar ve bakış açıları gerektirir. Bu müdahale ve yönetim şekline sahipseniz, dünya standartlarında uygulanırlık kazanmış bütün güvenlik ilkelerini Security center üzerinde bulabilirsiniz.

Aşağıdaki ekranda genel Policy/İlke yönetim ekranına dair bir ön izlenim bulabilirsiniz.

Security Center Azure abonelik merkezi detaylarının bir kopyasını okunur vaziyette tutar eğer bir aksilik olursa, kapsam itibari ile sizi uyaracaktır. Örnek ön gösterimi aşağıdaki gibi görüntüleyebilirsiniz.

Sürekli ve Eş zamanlı Gerçekleştirilen Tarama Çalışmalarını gerçekleştirir,

Security Center, devamlı olarak sistem üzerindeki iletişimi izler protokol seviyesinde, ağ seviyesinde ve önerilen, ihtiyaç duyulan güvenlik tanımlamalarını işaretleyip, ağ genel iletişim haritasını çıkartarak, atak ağlarını, istenmeyen durumları, cihazların birbiri ile olan bağlarını, istenmeyen bağlantıların bloklanmasının kolaylaştırılması gibi birçok detayı net bir şekilde haritalar. Bu detaya ait temel gösterimi aşağıdaki gibi görebilirsiniz.

Cihazların güvenlik skorlarını, güvenlik skorlarına göre güvenlik iyileştirme tavsiyelerini ve kritiklik durumlarına göre sıralama detaylarını da görmeniz mümkündür. Aşağıdaki görselde görüntüleyebilirsiniz.

Makine cihaz, işletim sistemi, PaaS özelinde, örnek SQL sunucu için, standart kaynak kullanımını, kaynakların kimlere ve aboneliklere atandığını görebilirsiniz.

Tehditlere Karşı Koruma

Security Center içerisinde tehditlerin önlenmesi, tespit edilmesi başlıklarında IaaS ve Azure olmayan PaaS ortamlarda, kurulumlar yapmak mümkün.

Security Center, tehditlere karşı koruma ve tehditlerin bütünleşik zarar verici analizini yapmak konusunda, tüm envanterleri tarayıp, yapınızın tamamı için tüm cihazlarda ve kaynaklarda tüm yapının hikayesini çıkartmak için atak kampanyalarına karşı koruma mimarisi çıkartabilir.

ATP mekanizması ve yetkinliği ile Security Center, bilinen atak metotlarının tamamı için PaaS ve IaaS ortamlarınızda güvenlik önlemleri ve çalışmalarını sağlamak için, yetkin ve efektif bir portaldir.

ATP ve Atak vektörü özelinde çalışmalarını PaaS ile sağlar. Bu minvalde, Azure App Service, Azure SQL, Azure Storage Account ve birçok servis ile entegre olur.

Ayrıca Microsoft Cloud App Security ile entegre olarak UEBA ile anormal davranış tespitlerini Azure aktivite logları üzerine taşır.

Azure Security Center platformunu kullanmak istediğiniz ve Public Cloud/ Hybrid Cloud iş modellerine adapte olmaya her geçen gün kazanan tüm işletme ve endüstrilerde ihtiyaç duyulacak ve yaygınlaşacak bir çözümdür.

Keyifli Okumalar.

Bu makalemizde sizlere kurumsal ürün ailesinden olan ES1640dc ile Vmware vCenter üzerinde site recovery manager entegrasyonunun nasıl yapılacağını anlatacağım.

QNAP ES1640dc, kurumsal sınıf depolama sistemidir. Yalnızca güç kaynağı modüllerinde değil, çift denetleyici sistem modüllerinde de yedekli donanım sağlar. Yani pek çok storage sisteminde olduğu gibi aslında temel olarak yüksek erişilebilirlik için tasarlanmıştır. Bu konudaki diğer bir makalemizi aşağıdaki linkten takip edebilirsiniz;

http://www.cozumpark.com/blogs/donanm/archive/2016/07/31/qnap-es1640dc-e5-96g-urun-inceleme.aspx

Peki böylesine kurumsal bir ürünü şirket organizasyonunuz içerisinde basit bir depolama ünitesi yerine ne tür çözümler için kullanabilirsiniz? Aslında bir önceki makalemizde bu konuda pek çok fikir sunmuştuk, bu makalemizde ise bu fikirlerden birisi olan birden çok veri merkezi içeren müşterilerin site recovery uygulamasında QNAP ürününü nasıl konumlandıracağını göreceğiz;

Bu makale, VMware Site Recovery Manager (SRM) ile QNAP ES1640dc depolama sistemine Disaster Recovery ortamı oluşturmak için adım adım anlatım kılavuzudur. Bu nedenle biraz uzun olmak ile birlikte adım adım bir makale olduğu için felaket öncesinde mutlaka şirket organizasyonunuz için uyarlanmalıdır.

İlk olarak makaledeki mimarimizi görelim;

Mimari şemada iki alan mevcut. Soldaki A Sitesi birincil sistemdir ve korunmaktadır. Sağdaki B Sitesi, kurtarma sitesidir ve A alanı başarısız olduğunda kullanılacaktır.

1.2 Sistem yapılandırması

2. Depolama alanınızı yapılandırma

Olağanüstü durum kurtarma sistemlerini kurmaya başlamadan önce, depolama ayarlarınızı yapılandırmanız gerekir.

2.1 Depolama havuzu ve iSCSI LUN oluşturma

Depolama havuzu ve iSCSI LUN'un nasıl oluşturulacağı hakkında ayrıntılı bilgi için ES1640dc kullanım kılavuzuna bakabilirsiniz. SCA'da RAID 10 tipinde bir depolama havuzu Pool1 oluşturulur.

Oluşturulan ve iSCSI hedefine eklenen dört LUN vardır.

• vdi_0, sanal makinelerinizi (VM'ler) saklamak için kullanılır.

• VMware SRM için yer tutucu kullanılır.

2.2 Sunuculardan depolamaya bağlanma

Sunucudan storage’a önerilen bağlantı, Çok Yollu I / O (MPIO) kullanmaktır. Lütfen tamamlamak için aşağıdaki adımları izleyin.

[Yapılandırma] sekmesini seçin → Depolama Adaptörleri → Özellikler'i seçmek için iSCSI Yazılım Adaptörüne sağ tıklayın.

[Dinamik Keşif] sekmesini seçin ve ardından iSCSI Sunucusu IP'sini girin

İSCSI hedeflerini yeniden taramak için Tamam'ı tıklayın ve sekmeyi kapatın.

Tüm iSCSI Sunucu Konumu IP’lerini Dinamik Bulma’ya eklemek için yukarıdaki adımları tekrarlayın, ardından hedefleri takip edin

2.3 SNAPSYNC ile storage replication yapılandırma

SNAPSYNC, ES1640dc'deki blok tabanlı bir depolama çoğaltma işlevidir. Felaket kurtarma işlemini VMware SRM ile yapmak için, depolama alanını çoğaltma seçeneklerinden biridir.

2.3.1 Snapsync Sunucusunu Yapılandırma

Snapsync işlevini yapılandırmak için, storage web sayfasına giriş yapın ve paneldeki Backup Station simgesine tıklayın.

Yapılandırmak için sol paneldeki Snapsync Sunucusunu seçin.

Snapsync Sunucusunu Etkinleştir onay kutusunu seçin ve Bağlantı Noktası Numarası ve Maksimum indirme oranını varsayılan olarak bırakın. Bir ana bilgisayar oluşturmak için Ana Makine Oluştur düğmesine tıklayın. Uzak ES1640dc storage sisteminin depolama IP'sini ve yönetici oturum açma parolasını girin. Oluşturmak için Uygula'yı tıklayın.

Uzak ana bilgisayar oluşturulur.

2.3.2 Snapsync İşi Oluştur

Sol paneldeki Snapsync seçeneğine tıklayın ve sağ paneldeki Replikasyon İşi Oluştur düğmesine tıklayın.

İşi oluşturmak için aşağıdaki bilgileri girin

• Remote Replication İş Adı.

• Uzak Ana Bilgisayarı seçip ata

• Kaynak Havuzu'nu seçin ve atayın

• Kaynak Paylaşımlı Klasör / LUN seçin ve atayın

• Hedef Havuzu seçin ve atayın

• Hedef Paylaşılan Klasör / Öğeyi atamak ve oluşturmak için Yeni düğmesine tıklayın.

• Bir Çoğaltma İşi oluşturmak için Tamam düğmesine tıklayın.

Snapsync iş oluşturma işlemi tamamlandı ve ilk senkronizasyonu otomatik olarak başlattı.

İlk senkronizasyon yapılır ve durum güncellenecek şekilde değişir.

2.3.3 Hedef LUN'u iSCSI hedefine ekle

Site B'de, snapsync görevi tamamlandıktan sonra altındaki Eşlenmemiş iSCSI LUN Listesinde yeni bir iSCSI bulmalısınız.

LUN'u seçin ve Eylem düğmesine tıklayın ve bu LUN'u iSCSI hedefine eşlemek için Harita'yı seçin.

Hedef LUN, iSCSI hedefine eşlenir.

3. SRM Kurulumu

SRM sunucusunu kurmadan önce,

- VMware vCenter Site Recovery Yöneticisi yazılımını indirin

- Bir veritabanı hazırlayın ve SRM'nin vCenter'da erişmesi için kullanıcı girişi yapın

- Veritabanına erişmek için SQL Server Yerel İstemcisi sürücüsünü SRM sunucusuna yükleyin.

- SRM'yi ayrı ayrı kurmak için başka bir Windows 2012 Server VM ekleyin

3.1 Her iki site için SRM yazılımını yükleyin

SRM yazılımını açın, İleri'ye tıklayın.

Sonrakine tıkla.

EULA'yı kabul edin ve İleri'ye tıklayın.

Sonrakine tıkla

Yüklenecek hedef klasörü seçin ve İleri'ye tıklayın.

Platform Servis Denetleyicisi (PSC) bilgisini girin, İleri'ye tıklayın.

PSC sertifikasını kabul etmek için Kabul Et'i tıklayın.

vCenter Address Seçin

VMware vCenter SRM'yi kaydetmek için bilgi girin ve İleri'ye tıklayın.

Varsayılan Site Recovery Manager Eklenti Tanımlayıcısı'nı seçin, İleri'ye tıklayın.

Otomatik olarak bir sertifika oluştur'u seçin, İleri'ye tıklayın.

Sertifika Bilgilerini Girin, İleri'ye tıklayın.

Özel veritabanı sunucusu kullan'ı seçin ve sonra DSN Kurulumu'nu tıklatın.

Sistem DSN sekmesini seçin ve Ekle düğmesine tıklayın.

SQL Server Native Client'i seçin ve Son'a tıklayın.

DSN Adı, Tanımı ve SQL sunucu adresini girin ve İleri'ye tıklayın.

Kullanıcı tarafından girilen giriş kimliği ve şifreyi kullanarak SQL Server kimlik doğrulaması seçeneğini belirleyin ve vCenter'da eklediğiniz giriş kullanıcısı kimlik bilgilerini girin ve İleri'yi tıklayın.

Varsayılan veritabanını SRM'nin SRM'nin kullanması için hazırladığı SRM olarak değiştirip İleri'ye tıklayın.

Bitir düğmesine tıklayın.

Veri kaynağı oluşturuldu, şimdi DB'yi test etmek için Veri Kaynağını Test Et seçeneğine tıklayabilirsiniz.

Test tamamlandı, kapatmak için Tamam'ı tıklayın.

Yeni Sistem DSN'si oluşturuldu, DSN kurulumunu tamamlamak için Tamam'a tıklayın.

DSN’yi manuel olarak girmenizi bildiren bir pencere açılır.

SRM'yi girin, İleri'ye tıklayın.

SRM Veri Tabanı giriş kullanıcısı kimlik bilgilerini girin ve İleri düğmesine tıklayın.

SRM servisini çalıştırmak için yerel yönetici kimlik bilgilerini girin, İleri'ye tıklayın.

Yükle'ye tıklayın.

Yükleme tamamlandı, Son'a tıklayın.

3.2 SRM Sitelerini Yapılandırma

SRM'yi yapılandırmadan önce, her iki sitenin de SRM / vCenter'ın birbirine erişebildiğinden emin olun.

3.2.1 Site Recovery Manager Sunucu Örneklerini Bağlayın

VSphere Web Client ana sayfasındaki Site Recovery simgesine tıklayın.

Sol paneldeki Siteler'i tıklayın.

Korunan Site vCenter panelini seçin ve Siteleri eşleştir'i tıklayın.

Kurtarma Sitesi PSC adresini girin, İleri'ye tıklayın.

Kurtarma Sitesi vCenter'ı seçin ve kimlik bilgilerini girin, ardından Son'a tıklayın.

VCenter'a bağlanmak için Evet'i tıklayın.

Site başarıyla eşleştirildi.

3.2.2 Siteler Kaynak Eşlemelerini Yapılandırma

Kaynak eşlemeleri oluştur'u tıklayın.

Eşlenmiş sitelerin küme eşlemesini ekleyin, İleri'yi tıklayın.

Eşleştirilmiş site için ters eşleme oluşturun, Son ’u tıklayın.

3.2.3 Siteleri Klasör Eşlemelerini Yapılandırma

Klasör eşlemeleri oluştur'u tıklayın.

Eşlemeleri manuel olarak hazırla'yı seçin ve İleri'ye tıklayın.

Sitelerin eşleme klasörlerini ekleyin, İleri'yi tıklayın.

Ters eşlemeler oluşturun, İleri'ye tıklayın.

3.2.4 Siteleri Ağ Eşlemelerini Yapılandırma

Network eşlemeleri oluştur'u tıklayın.

Eşlemeleri manuel olarak hazırla'yı seçin ve İleri'ye tıklayın.

Sitelerin eşleme ağlarını ekleyin, İleri 'yi tıklayın.

Ters eşlemeler oluşturun, İleri'ye tıklayın.

Yapılandırmayı kontrol edin, Son'a tıklayın

3.2.5 Siteleri Yer Tutucu Veri tabanlarını Yapılandırma

Planlı geçişi ve yeniden korumayı etkinleştirmek için her iki sitede de yer tutucu veri depoları seçmelisiniz. Yer tutucu veri depolarının belirli kriterleri karşılaması gerekir.

- Kümeler için yer tutucu veri depolarının kümedeki tüm ana bilgisayarlar tarafından görülmesi gerekir.

- Çoğaltılmış veri depolarını yer tutucu veri depoları olarak seçemezsiniz.

Siteleri Yer Tutucusu Veri Deposunu Yapılandır

Yer tutucuyu seçin ve ardından Tamam

3.3 Dizi Yöneticilerini Yapılandırma

Dizi Yöneticilerini yapılandırmak için, QNAP SRA eklentisinin önceden yüklenmesi gerekir.

3.3.1 SRA eklentisi kurulumu

QNAP SRA yazılımını SRM sunucusunda açın, İleri'ye tıklayın.

EULA'yı kabul etmek için Kabul Ediyorum'u tıklayın.

Kurulumu tamamlamak için Son'a tıklayın.

3.3.2 Dizi Yöneticileri Ekleyin

Dizi yöneticisi ekle 'yi tıklayın ve dizi çiftini etkinleştirin.

Bir çift dizi yöneticisi ekle'yi seçin ve İleri'ye tıklayın.

Eşleşmiş siteleri seçin, İleri'ye tıklayın.

QNAP Kurumsal Depolama SRA'yı seçin, İleri'ye tıklayın.

Siteyi Yapılandırma bir dizi yöneticisi, görünen adı ve yönetim bilgilerini sağlayın, ardından İleri'ye tıklayın.

-Yönetme URL'si: Site A SCA Yönetimi IP'si

-Ekstra Yönetim URL'si: Site A Site A SCB Yönetim IP'si

-Kullanıcı adı: Site A SC yönetici kullanıcı adı, varsayılan yöneticidir

-Password: Site A SC şifresi

Dizi yöneticisi oluşturma, Snapsync Çoğaltma İşi bu adımda kontrol edilecektir.

Site B dizi yöneticisini yapılandırın, görünen adı ve yönetim bilgilerini sağlayın, ardından İleri'ye tıklayın.

-Yönetim URL: Site B SCA Yönetimi IP

-Ekstra Yönetim URL'si: Site B Site A SCB Yönetimi IP

-Kullanıcı adı: Site B SC yönetici kullanıcı adı, varsayılan yöneticidir

-Password: Site B SC şifresi

SC Dizi Çiftini seçin, İleri'ye tıklayın.

Son'u tıklayın.

3.3.3 Koruma Grubu Oluştur

Koruma Grubu Oluştur'u tıklayın.

Grup adını girin, İleri'ye tıklayın.

Site A'dan Site B'ye kadar koruma yönünü seçin ve dizi tabanlı çoğaltmayı seçin, ardından İleri'yi tıklatın.

VM'lerin korunacağı veri deposunu seçin ve İleri'yi tıklayın.

Son'u tıklayın.

3.3.4 Kurtarma Planı Oluştur

Kurtarma Planı Oluştur'u tıklayın.

Plan adını girin, konum seçin ve İleri'ye tıklayın.

Kurtarma Sitesi olarak Site B'yi seçin, İleri'ye tıklayın.

Koruma grupları seçin, İleri'ye tıklayın.

Test VM ağını seçin, İleri'ye tıklayın.

Kurtarma Planı oluşturuldu, Son'a tıklayın.

4. Site Kurtarma Senaryoları

VMware SRM, site kurtarma için aşağıdaki türleri sunar

- Test Kurtarma

- Planlı migration

- Disaster kurtarma

4.1 Test Kurtarma

Sağ sekmede Kurtarma Planları'nı seçin ve aşağıdaki pencerede plan adına tıklayın.

Kurtarma Planını Test Et düğmesini tıklayın.

Sonrakine tıkla.

Testi çalıştırmak için Son'a tıklayın.

Monitör sekmesinde, test durumunu görebilirsiniz.

Test yapıldıktan sonra Plan durumu Test tamamlandı olarak değişir.

Test ortamını temizlemek için Kurtarma Kurtarma Planı düğmesine tıklayın.

Sonrakine tıkla.

Test planı ortamı temizlendi. Plan durumu Hazır olarak değişir.

4.2 Planlı migration

Herhangi bir durum anına, yerel bakım sebeplerinden dolayı VM'leri başka bir siteye geçirmek istiyorsunuz.

Planlanan geçiş, kalıcı VM verilerini hızlı bir şekilde aktarmanıza ve otomatik alma hizmetini kurtarma sitesine aktarmanıza yardımcı olur.

Kurtarma Planını Çalıştır düğmesini tıklayın.

Onay kutusunu seçin ve Planlı Geçiş'i seçin ve İleri'ye tıklayın.

İzleme sekmesinde, planlanan taşıma işlemi devam ediyor.

Planlanan geçiş tamamlandı.

Koruma alanındaki sanal makinelerin etkin olmadığını görebilirsiniz.

Kurtarma sitelerinde sanal makineler etkin hale geldi.

SnapSync Çoğaltma İşinin durumunu öğrenebilirsiniz.

Şu anda, iki site arasında veri senkronizasyonu yok.

Şimdi rol değişikliklerini başlatmak ve senkronizasyonu devam ettirmek için lütfen Reprotect Recovery Plan düğmesine tıklayın.

Onay kutusunu seçin ve İleri'ye tıklayın.

Reprotect işlemi çalışıyor.

Reprotect işlemi tamamlandı.

Reprotect işlemi tamamlandıktan sonra, depolama sisteminin SnapSync Çoğaltma İşindeki rolün (kaynak ve hedef) geri alındığını ve durumun güncellendiğini görebilirsiniz.

Şimdi planlanan taşıma işlemi tamamlandı ve bakım çalışmaları için A sahasının kapatılması güvenli.

4.3 Disaster recovery

Herhangi bir nedenle, koruma siteniz kapalı ve tüm hizmetleri mümkün olan en kısa sürede devam ettirmek için kurtarma sitenizi açmanız gerekiyor.

Kurtarma sitesinde, aşağıdaki uyarı mesajını göreceksiniz.

Kurtarma planı sekmesine gidin, Kurtarma Planını Çalıştır düğmesini tıklayın.

Olağanüstü Durum Kurtarmayı çalıştırmak için onay kutusunu seçin ve İleri'yi tıklayın.

Olağanüstü durum kurtarma şu anda devam ediyor. Bu modda, hata adımları dikkate alınmayacak.

Disaster Recovery kurtarma işlemi tamamlandı.

Tüm VM'ler kurtarma sitesinde çalışıyor.

Not: Site A kapalı olduğundan şu anda hiçbir koruma olmadığını lütfen unutmayın. Sorunu Site A'da çözmeniz ve en kısa sürede ortaya çıkarmanız gerekiyor.

Bakım yapıldıktan sonra, SRM bağlantısını yeniden bağlamak için A vSphere Web Client sitesine gidin. Bir açılır pencere Site B vCenter kimlik bilgilerini soracak, oturum açmak için kimlik bilgilerini girecektir.

Kurtarma Planı'nın İzleme sekmesinde, Site A yokken eksik öğeleri yeniden senkronize etmek için kurtarma işlemini tekrar yapmanız istenecektir.

Kurtarma Planını Çalıştır düğmesini tıklayın.

Next diyerek ilerleyin

Kurtarma tamamlandı.

Senkronizasyon yönünü geri almak ve site B'den site A'ya senkronize etmeye başlamak için Kurtarma Planını Tekrarla düğmesine tıklayın.

Reprotect süreci devam ediyor.

Reprotect işlemi tamamlandı. Artık plan durumu hazır olarak değişir.

Reprotect işlemi yapıldıktan sonra kaynak ve hedefi tersine çevirir. Depolama sisteminin snapsync job web sayfasında senkronizasyon yönünün SiteA → SiteB'den SiteB → SiteA'ya değiştirildiğini görebilirsiniz.

Şimdi B Sitesi koruma alanı haline geliyor ve A Sitesi kurtarma alanı haline geliyor.

SiteA' yı koruma sitesi olarak ve SiteB' yi kurtarma sitesi olarak tutmak istiyorsanız, Planlı geçişi yapmanız ve tekrar korumanız gerekir.

Makalemin sonuna geldik, umarım faydalı bir makale olmuştur.

Kaynak;

https://www.qnap.com/en-uk/how-to/tutorial/article/deploying-vmware-vcenter-site-recovery-manager-with-qnap-es1640dc/

Office 365 Migration projeleri yaparken eğer müşteri ortamında Exchange server varsa hepimizin çokca tercih ettiği bir yöntem olan hybrid, Exchange ve Exchange Online arasında bir organizasyon ilişkisi kurarak minumum kesinti ile mailboxlarımızı Cloud’a aktarabileceğimiz gibi hem Exchange hem Exchange Online platformunda kullanıcıların bir arada çalışmasına olanak sağlamaktadır.Bu organizasyon ilişkisi kurarken kullandığımız tool’u ise Hybrid Wizard olarak adlandırıyoruz.Microsoft tarafından 2018 Haziran ayında anons edilen Hybrid wizard içerisinde gelen “Hybrid Organization Configuration Transfer” v1 özelliği ve sonrasında 2018 Kasım ayında gelen yeni bir update ile “Hybrid Organization Configuration Transfer” v2 özelliği sunuldu ve v1’in üzerine geliştirmeler ve iyileştirmeler yapıldı.

Peki nedir bu Hybrid Organization Configuration Transfer ? Ne gibi ihtiyaçlarımızı karşılıyor ?

Hybrid Organization Configuration Transfer ile beraber on-premise Exchange üzerindeki bir takım configuration ayarlarının Exchange Online tarafına Hybrid Wizard tool’u aracılığıyla taşınmasına olanak sağlandı. Bu özellik, geçiş işlemleri sırasında on-premise Exchange'den Exchange Online'a tek seferde önemli organizasyon ilkesi nesnelerinin aktarılmasını sağlar. HCW'yi çalıştıran admin, on-premise Exchange'den Exchange Online'a taşınırken tespit edilen tüm nesneleri taşımayı seçebilir veya hiçbirini aktarmamayı seçebilir. Configuration Transferin support ettiği configurationlar aşağıdaki gibidir. Bu özellikler mevcut Hybrid wizard içinde entegre gelmektedir.

OCT-V1 (Haziran 2018)

• Active Sync Mailbox Policy
• Mobile Device Mailbox Policy
• OWA Mailbox Policy
• Retention Policy
• Retention Policy Tag

OCT-V2 (Güncel sürüm)

• Active Sync Device Access Rule
• Active Sync Organization Settings
• Address List
• DLP Policy
• Malware Filter Policy
• Organization Config
• Policy Tip Config

Yukarıda listelenenlerin dışındaki politikalar hybrid wizard tarafından kopyalanmaz ve Office 365'e manuel olarak kopyalanması gerekir. Hybrid wizard tarafından kopyalanan politikaların ve özniteliklerin bir listesi için ;

https://docs.microsoft.com/en-us/exchange/organization-configuration-transfer-attributes

Configuration transfer Exchange 2010 , 2013 , 2016 ve 2019 versiyonlarında en son cumulative update ile beraber support edilmektedir.

Hybrid yapıların kurulması, çoğu zaman müşteri ortamındaki network, sertifika ve cumulative update’lerin eksik olmasından dolayı alt yapının sağlıklı hale getirilmesi süreci ile beraber ciddi zaman almaktadır. Alt yapı best practices’lere uygun hale getirildikten sonra ilk yaptığımız işlerin başında hybrid wizard tool’u ile organizasyon ilişkini kurup ortamı geçişe hazır hale getirmektir. Bunun üzerine alt yapıyı sağlıklı hale getirsekte büyük organizasyonlarda bu iş bu kadar kolay olmamaktadır. Hali hazır’da on-premise yapıda kullandıkları OWA Mailbox Policy , Retention Policy , DLP Policy’ler vs varsa organization configuration transfer özelliği olmadan önce bunları tek tek gidip Exchange online üzerinde oluşturuyorduk buda bize geçişlerde ortamdaki policy’lere göre 2 ,3 gün kaybettirmekteydi. Organization configuration transfer ile artık bu işlemi bir kaç dakika’da tamamlayabilmekteyiz.

Organization configuration transfer sadece Policy’leri şirket içindeki Exchange Online'a kopyalamakla kalmaz, aynı zamanda on-premise exchange üzerindeki policy’lerde yapılan değişiklikleri Exchange Online üzerinde güncelleştirir. Policy değerleri Exchange Online üzerine taşındıktan sonra şirket içi policy güncellenirse, adminler güncellenen değerlerin tekrardan Exchange Online üzerine kopyalanması için Organization configuration transferi tekrar çalıştırmalıdırlar. Zaten wizard’ı her çalıştırdığınızda size değişen objeleri tespit edip Exchange Online tarafına yazacağı konusunda bilgi veriyor olacak.

Policy’lerden bir örnek gösterek makaleyi sonlandırıyor olacağım. Organization configuration transfer ile taşıdığım örnek retention policy’ler Exchange Online policy altındaki retention policies altına birebir olacak şekilde kopyalandı. Özellikle hybrid projelerinde bu şekilde policy’lerin taşınması süreçleri hızlandıracağı gibi manuel taşıma ile oluşabilecek hatalarında önüne geçiyor olacak.

Umarım faydalı olmuştur , keyifli okumalar.

Makaleme öncelikle System Hardening (Sistem Sıkılaştırma) nedir ile başlamak istiyorum.

Sistem sıkılaştırmanın amacı, mümkün olduğu kadar çok güvenlik riskini ortadan kaldırmaktır. Saldırı yüzeyini azaltarak sistemin emniyete alınması işlemidir. Bir sistem ne kadar çok işlevi yerine getirirse o kadar büyük bir güvenlik açığı yüzeyine sahiptir; Prensipte, tek işlevli bir sistem çok amaçlı bir sistemden daha güvenlidir. Kullanılabilir saldırı vektörlerinin azaltılması gereksiz yazılımların, gereksiz kullanıcı adlarının veya girişlerin kaldırılmasını ve gereksiz hizmetlerin devre dışı bırakılmasını veya kaldırılmasını içerir. Mümkün olduğunda sistemi en son güvenlik yamaları ve düzeltmelerini yükleyerek güncel tutulmasını da içermektedir.

Microsoft Baseline Security Analyzer (MBSA)

Microsoft Baseline Security Analyzer (MBSA), bir veya daha fazla bilgisayarda var olan yönetimsel güvenlik açıklarını değerlendirme olanağı sağlar. MBSA belirtilen bilgisayarları tarar ve daha sonra her bir bilgisayar için MBSA'nın gerçekleştirdiği güvenlik kontrolleri, sonuçları ve herhangi bir sorunu çözme önerileriyle ilgili ayrıntıları içeren bir rapor oluşturur. İşletim sisteminde güvenlik sorunlarına neden olabilecek yanlış yapılandırma kontrolünün yanı sıra, Microsoft SQL Server, MSDE ve Microsoft Internet Information Services'de (IIS) güvenlik sorunlarını da kontrol edebilir. Bir bilgisayarın yüklü olan en güncel Microsoft Windows ve Microsoft Office güncellemelerine sahip olup olmadığını da belirleyebilir ve Microsoft Update sitesi tarafından barındırılan diğer ürünler için güvenlik güncellemelerini, güncelleme toplamalarını ve servis paketlerini kontrol edebilir.

Microsoft Baseline Security Analyzer (MBSA) 2.3 Sistem Gereksinimleri

https://download.cnet.com/Microsoft-Baseline-Security-Analyzer/3000-2086_4-10105019.html

Microsoft Baseline Security Analyzer 2.3 sürümünü indirebilirsiniz.

* 2014 yılında Steve Ballmer'ın yerine Microsoft'un CEO pozisyonuna Satya Nadella atandı. Bu yönetimsel değişiklik nedeniyle MBSA'nın geliştirilmesi ve kullanım politikası da değiştirilmiş ve durdurulmuş olabilir.

Kullanım:

Kurulum tamamlandıktan sonra Microsoft Baseline Security Analyzer 2.3 ilk kullanım için başlatabilirsiniz. Taramak istediğiniz her bilgisayar için yönetici haklarına sahip olmanız gerekir.

MBSA üç ana seçenek sunmaktadır.

Scan a computer                                             (Bir bilgisayarı tara)

Scan multiple computers                                 (Birden fazla bilgisayar tara)

View existing security scan reports                (Mevcut güvenlik taraması raporlarını görüntüleyin)

Scan a computer seçeneğini kullanarak MBSA’nın kurulu olduğu bilgisayarı ya da IP adresi girilerek Windows bilgisayarınızı taraya bilirsiniz.

Taramaya başlamadan önce güvenlik güncelleştirmesi bilgilerini indirirken lütfen bekleyiniz. Bu süre bağlantı hızınıza göre değişiklik gösterebilir.

Tarama tamamlandıktan sonra sonuçlar MBSA tarafından raporlanmaktadır.

Rapor üzerinde sonuçları incelemek için "Result details" tıklanarak detayları görüntüleye bilirsiniz.

Örnek taramada Local Account Password Test (Yerel Hesap Parola Testi) bulgusunda

Bazı kullanıcı hesaplarının boş veya basit parolaları var veya analiz edilemiyor gibi bir sonuç göstermektedir. 

What was scanned (Ne tarandı) tıklanarak ilgili bulguda nelerin kontrolü yapıldığı hakkında detaylı bilgilere erişebilirsiniz.

How to correct this (Bu nasıl düzeltilir?) tıklanarak ilgili bulguda nelerin kontrolü yapıldığı ve çözüm önerileri hakkında detaylı bilgilere erişebilirsiniz.

Scanning Options (Tarama Seçenekleri) hakkında detaylı bilgilere erişmek için ilgili yardım dosyalarını inceleyebilirsiniz.

file:///C:/Program%20Files/Microsoft%20Baseline%20Security%20Analyzer%202/Help/mbsahelp.html#Options

C:\Program Files\Microsoft Baseline Security Analyzer 2\optionshelp.html

Scan multiple computers seçeneğini kullanarak ağınızda bulunan Windows bilgisayarları taraya bilirsiniz. Topolojinize göre IP aralığını belirledikten sonra tarama işlemini gerçekleştirebilirsiniz.

View existing security scan reports seçeneğini kullanarak mevcut güvenlik taraması raporlarını görüntüleyebilirsiniz. Daha önce yapmış olduğunuz taramaların detaylarına bu seçenek ile erişebilir ve raporları inceleyerek değerlendirebilirsiniz.

Örnek Rapor;

Örnek Rapor;

mbsacli.exe MBSA'nın komut satırı aracıdır. MBSA grafik kullanıcı ara birimi dışında komut satırından da kullanım sunmaktadır. MBSA'nın kurulduğu dizinde yer almaktadır.

Örnek Dizin;

Örnek Kullanım;

mbsacli.exe komut satırı aracının tarama seçenekleri hakkında detaylı bilgilere erişmek için ilgili yardım dosyasını inceleyebilirsiniz.

C:\Program Files\Microsoft Baseline Security Analyzer 2\Help\mbsahelp.html

mbsacli.exe MBSA'nın komut satırı aracı MBSA’nın grafik kullanıcı ara birimine göre daha fazla tarama seçenekleri sunmaktadır. Kapsamlı taramalar yapıp detaylı rapor çıktıları üretebilirsiniz.

MBSA artık aktif olarak geliştirilen bir araç olmasa da özellikle regülasyon ve uyum süreçlerinde çok yardımcı olabilecek ücretsiz bir uygulamadır.

Azure Multi-Factor Authentication (Azure MFA), kullanıcıların oturum açma taleplerini karşılarken, verilere ve uygulamalara erişimi korumaya da yardımcı olur. Telefon görüşmesi, SMS veya mobil uygulama bildirimi ve bir kerelik parolalar gibi çeşitli kolay doğrulama seçenekleri aracılığıyla güçlü kimlik doğrulaması olanağı sunarak kullanıcıların istedikleri yöntemi seçmelerine olanak tanır. Hem şirket içinde hem de bulutta kullanılarak, çevrimiçi Microsoft hizmetlerine, Azure Active Directory bağlantılı SaaS uygulamalarına, iş kolu uygulamalarına ve uzaktan erişim uygulamalarına erişmeye yönelik güvenlik özellikleri eklenebilir.

Bu makalemizde de Exchange Server 2019 üzerinde yani local bir sistem içerisinde Azure MFA kurulum ve konfigürasyonundan bahsedeceğiz.

Azure MFA servisi fiyatlandırmasına aşağıdaki linkten ulaşabilirsiniz.

https://azure.microsoft.com/tr-tr/pricing/details/multi-factor-authentication/

Hali hazırda aşağıdaki Office 365 paketlerini kullanıyorsanız Azure MFA servisine ek bir ücret ödemeden local sistemler içerisinde kullanabilirsiniz. Bu paketlerden birine sahip değilseniz bu paketleri kullanıcı bazlı olarak aylık veya yıllık şeklinde kiralayabilirsiniz.

·         Azure AD Plan 1

·         Azure AD Plan 2

·         Microsoft 365 Business

·         Microsoft 365 E3

·         Microsoft 365 E5

·         Microsoft 365 F1

·         Office 365 Enterprise Mobility + Security E3

·         Office 365 Enterprise Mobility + Security E5

·         EA Agreement

1 Ekim 2018 itibaren geçerli olmak üzere artık Azure MFA Standalone olarak kullanılamayacak.

Azure MFA servisini kullanmak için gereksinimlerimizi belirttik. Peki Azure MFA servisini Exchange Server üzerinden neden kullanmalıyız? Ülkemizde halen Exchange Server kullanan firmalar var ve bir çok firmanın Outlook Web Access (OWA) ve Exchange Admin Center (ECP) panellerine dışarıdan erişim yapılabilmekte. Durum böyle olduğunda aslında local AD içerisindeki kimlik bilgilerinizi dış dünyaya açmış oluyorsunuz. Şirket dışından maillerine erişmek isteyen personel veya Exchange adminleri olabilir. Bu noktada ise gerçek kullanıcıların sisteme bağlanıp bağlanmadığını kontrol etmek için Azure MFA ile kullanıcı kimliğini ikinci kez doğrulayarak sisteme erişimlerini güvenli bir şekilde sağlayabilirsiniz.

O zaman Exchange Server 2019 üzerinde Azure MFA servisini etkinleştirme işlemlerine geçebiliriz.

İlk olarak Azure AD planımızın yukarıda belirtmiş olduğumuz Azure AD Plan 1 veya Azure AD Plan 2 seviyesine getirmek için gerekli lisans alımların gerçekleştiriyoruz. Sonrasında Azure yönetim paneline Owner yetkisine sahip kullanıcı hesabı ile giriş yaptıktan sonra arama bölümüne Azure Active Directory yazarak, Services başlığının altındaki Azure Active Directory seçeneğini seçiyoruz.

Resim 01

Azure AD servisinin içerisine geldiğimizde sol taraftaki menü içerisinden “MFA” seçeneğini seçiyoruz.

Resim 02

“MFA” detaylarına geldiğimizde yine sol taraftaki menü içerisinden  “Server Settings” seçeneğini seçip, “Azure MFA Server” uygulamasını “Exchange” sunucusuna indiriyoruz.

Resim 03

Resim 04

Resim 05

İndirme işlemi tamamlandıktan sonra kurulum dosyasını çalıştırıp, “I Agree” seçeneğini seçtikten sonra kurulum adımlarına devam ediyoruz.

Resim 06

Azure MFA Server uygulamasının sunucu içerisinde hangi dosya dizini içerisine kurulacağını belirtiyoruz.

Resim 07

Resim 08

Kurulumu bitirmek için “Finish” butonuna tıklıyoruz.

Resim 09

Azure MFA Server uygulamasını neden Exchange Server üzerine kuruduğumuza gelecek olursak, Azure MFA Server’ ın Exchange Server’ a ait Virtual Directory bilgilerini erişmesi gerektiğinden kurulumu Exchange Server üzerine gerçekleştiriyoruz.

Azure MFA Server’ımızı kendi aboneliğimize bağlayabilmek için Azure MFA Server' a ait aktivasyon kimlik bilgilerini alıyoruz. Bu kimlik bilgisindeki şifre 10 dakikada bir değişti için aktivasyon işlemini kimlik bilgisi üretildikten sonra hemen yapılması gerekiyor. Yoksa tekrardan yeni aktivasyon kimlik bilgisi oluşturmanız gerekli.

Resim 10

Aktivasyon işlemi sırasında Exchange sunucunun aşağıdaki URL ve IP adreslerine erişimini sağlamanız ve Azure MFA servisini kullandığınız sürece bu URL ve IP adreslerine daime erişiyor olması gerekmektedir.

Resim 11

Network tarafında da gerekli izinleri verdikten sonra yukarı oluşturulan Azure MFA Server' a ait aktivasyon kimlik bilgilerini “Email” ve “Password” alanlarına girip, “Activate” butonuna tıklıyoruz.

Resim 12

Aktivasyon işlemi gerçekleştiriliyor.

Resim 13

Active Directory içerisinde MFA sunucularımızın yer alacağı bir grup oluşturuyoruz. Buradaki amaç HA yapısını sağlamak.

Resim 14

Status bölümünden Azure MFA Server’ımızın aktif olduğunu ve versiyonunu görebiliyoruz. Versiyonu belirli aralıklarla güncellemenizi tavsiye ederim.

Resim 15

MFA Server üzerinde kullanıcı kimliğini doğrulamak için mobil telefon numarasının AD üzerinde mobile attribute içerisine girilmesi gerekiyor. İstenilirse mobile attribute yerine farklı bir attribute içerisine yazılan değerlerde kullanılabilir. Girilen telefon numarasının format “+905xxxxxxxxx” şeklinde olmalıdır.

Resim 16

AD üzerinde kullanıcılara mobil numara girme işlemlerini tamamlandıktan sonra kullanıcıların MFA Server üzerine otomatik olarak gelmesi için MFA Server Provider üzerinde “Synchronization” özelliğini aktif ediyoruz. Bunun için “Directory Integration” bölümüne gelip, sağ taraftaki “Synchronization” sekmesine gelip, “Add” butonuna tıklıyoruz.

Resim 17

Gelen pencerede eşitlenmesini istediğimiz grubun üyelerini burada seçiyoruz.

Resim 18

Resim 19

“Synchronize Now” butonuna tıklıyoruz. Bu ekranda “Synchronization” işleminin ne kadar sıklıkla yapılacağını da belirtebiliyoruz. Varsayılan değer 5 dakika olarak atanmış durumda.

Resim 20

Resim 21

Sol taraftaki menü içerisinden “Users” bölümüne geliyoruz ve sync ettiğimiz kullanıcıların hemen buraya geldiğini görebilmekteyiz. Eklediğimiz kullanıcı veya kullanıcılarda MFA servisinin çalışıp, çalışmadığını kullanıcıyı seçtikten sonra “Test…” butonuna basarak kontrol edebiliriz.

Resim 22

Test edeceğimiz kullanıcının AD logon bilgilerini girdikten sonra gelen aramada “#” tuşuna bastıktan sonra MFA servisinin çalıştığını görmüş oluyoruz.

Resim 23

Resim 24

Resim 25

Azure MFA Provider tarafında MFA yapılabilmesi için AD üzerindeki gerekli ayarları ve Azure MFA tarafındaki gereksinimleri tamamladık. Burada dikkat edilmesi gereken nokta Azure MFA Provider uygulamasının Exchange Server üzerine kurulması gerektiği. Çünkü IIS servisi üzerinde ayarlar yapılacağı için Azure MFA Provider’ ın IIS üzerindeki Exchange ait Virtual Directory dizinlerini görebilmesi gerekiyor.

“IIS Authentication” menüsüne geldikten sonra “Enable IIS authentication” seçeneğini aktif edip, “Native Module” sekmesine gelerek, Exchange Server tarafında hangi virtual directory üzerinden giriş olma işlemi sırasında Azure MFA servisinin kullanılacağını seçiyoruz. Bu makalemizde sadece OWA ve ECP için MFA kullanılsın diye ayar yaptık.

Resim 26

Ardından “HTTP” menüsü içerisine gelerek Exchange Serverımıza ait Base URL’I buraya yazıyoruz.

Resim 27

Burada dikkat edilmesi gereken nokta tüm kullanıcılarınızda MFA uygulamayacaksınız “Require Multi-Factor Authentication user match” seçeneğini işaretlememeniz gerekiyor. Eğer işaretlerseniz tüm kullanıcılarınızı MFA yapmaya zorlayacak.

Resim 28

Azure MFA Provider üzerinde tüm gerekli ayarlamaları tamamladık. Şimdi OWA üzerinde üzerinden sisteme giriş yapmayı deniyoruz.

Resim 29

Kullanıcı hesap bilgilerini girdikten sonra OWA’nın hemen açılmaması gerekiyor. Telefonunuza gelen çağrıyı yanıtladıktan sonra OWA üzerinden mailboxınıza ulaşım sağlayabiliyorsunuz.

Resim 30

Resim 31

Bu makalemizde de Exchange Server 2019 üzerinde yani local bir sistem içerisinde Azure MFA kurulum ve konfigürasyonunun nasıl yapılacağını gösterdik. Umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek dileğiyle.

Azure üzerinde neden scale set vm kullanmalıyız? Bu makalemize soru cümlesi ile başlamak istedim. Çünkü Azure üzerinde bir vm kurmak artık çok basit. Bu soruya en güzel cevap e-ticaret siteleri. E-ticaret sitelerinin belirli günlerde yani bu black Friday veya başka bir kampanya günlerinde e-ticaret sitesine yapılan yoğun giriş isteklerinden dolayı sistemin gelen isteklere geç cevap vermesi hatta bu istekleri bir süre sonra karşılayamaz olması durumundan sistemin tamamen erişilmez olması gibi sonuçlar doğurabilir.

Bu noktada Azure üzerinde scale sets vm konumlandırdığınızda vm ‘leri otomatik olarak yatay veya dikey şekilde ölçeklendirebiliyoruz. Bu ölçeklendirme yapılırken bu sunuculardaki yük dengeleme işlemlerini de Azure Load Balancer veya Application Gateway ile sağlayabiliyoruz.

Scale sets, aynı VM’ leri bir küme olarak dağıtmanızı ve yönetmenizi kolaylaştırır. Azure portalı, Azure PowerShell veya Azure CLI kullanarak Linux veya Windows sanal sunucuları için scale sets oluşturabilirsiniz. Bu makalemizde de Azure PowerShell ile scale set vm oluşturmayı göreceğiz.

Ayrıca scale set işlemlerini Python veya Node.js gibi SDK'larla veya doğrudan REST API kullanarak da oluşturabilir ve yönetebilirsiniz.

Resim 01

Genel itibariyle scale set vm’ leri ne amaçla kullanmamız gerektiğinden bahsettik. Artık işlemlere Azure PowerShell başlayabiliriz.

Login-AzureRmAccount

Komutu ile Azure aboneliğimizde owner yetkisine sahip olan bir kullanıcı hesabı ile giriş yapıyoruz.

Resim 02

Bende birden fazla abonelik olduğundan işlem yapacağım aboneliği seçmem gerekiyor. Bunun içinse mevcutta sahip olduğum tüm aboneliklerin listesini görmek için:

Get-AzureRmSubscription

Komutunu yazıyorum.

Resim 03

Abonelik listesi geldikten sonra hangi abonelik içerisinde çalışacaksam Select-AzureRmSubscription -SubscriptionName "Visual Studio Enterprise"

Komutunu yazarak, abonelik seçimimi gerçekleştiriyorum.

Resim 04

Artık seçmiş olduğumuz abonelik içerisinde çalışmaya hazırız.

Subsctiption id, resource group name, scale set name ve region değerlerini giriyoruz.

$mySubscriptionId = (Get-AzureRmSubscription)[2].Id

$myResourceGroup = "rg-vmss"

$myScaleSet = "utss"

$myLocation = "West Europe"

Resim 05

$vmcred = Get-Credential

Oluşturacağımız vm’ e ait login bilgilerini giriyoruz.

Resim 06

Sonrasında scale set vm’ imizi oluşturmak için aşağıdaki komut satırını çalıştırıyoruz.

New-AzureRmVmss -Credential $vmcred -ResourceGroupName $myResourceGroup -VMScaleSetName $myScaleSet -Location $myLocation -VirtualNetworkName "utvnet" -SubnetName "default" -PublicIpAddressName "utnlb01" -LoadBalancerName "utnlb"

Yaklaşık olarak 3 dakika içerisinde vm scale set kurulumumuz tamamlanıyor.

Resim 07

Resim 08

Resim 09

Resim 10

Scale set vm’ i oluşturma işlemi tamamlandı. Şimdi auto scale özelliğini aktif etmek için aşağıdaki komutu çalıştırıyoruz. Aşağıdaki komut içerisinde yeni bir auto scale kuralı oluşturarak, cpu kullanımı %70 olduğunda ve bu kullanım oranı 5 dakika boyunca devam ettiğinde scale set içerisindeki vm sayısını 3’e çıkarmak için gerekli olan ayarları gerçekleştiriyor.

$myRuleScaleOut = New-AzureRmAutoscaleRule -MetricName "Percentage CPU" -MetricResourceId /subscriptions/$mySubscriptionId/resourceGroups/$myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/$myScaleSet -TimeGrain 00:01:00 -MetricStatistic "Average" -TimeWindow 00:05:00 -Operator "GreaterThan" -Threshold 70 -ScaleActionDirection "Increase" –ScaleActionScaleType "ChangeCount" -ScaleActionValue 3 -ScaleActionCooldown 00:05:00

Resim 11

Scale out kuralını yazmış olduk. Kullanılan kaynak tüketimi düştüğünde scale set içerisindeki vm sayısının eski haline dönebilmesi için yeni bir kural yazıyoruz. Bu kural içerisinde CPU kullanımı %30 altında olduğunda ve 5 dakika boyunca sürdüğünde scale set içerisindeki vm sayısı 1’e düşürüyor.

$myRuleScaleIn = New-AzureRmAutoscaleRule -MetricName "Percentage CPU" -MetricResourceId /subscriptions/$mySubscriptionId/resourceGroups/$myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/$myScaleSet -Operator "LessThan" -MetricStatistic "Average" -Threshold 30 -TimeGrain 00:01:00 -TimeWindow 00:05:00 -ScaleActionCooldown 00:05:00 -ScaleActionDirection "Decrease" –ScaleActionScaleType "ChangeCount" -ScaleActionValue 1

Resim 12

Scale set kurallarını oluşturduktan sonra scale set profilini oluşturmamız gerekiyor. Bunun için aşağıdaki komut satırını çalıştırıyoruz. Profili belirlerken scale set içerisinde olması gereken en az vm sayısı ve en fazla olması gereken vm sayısını belirtip, yukarıda belirttiğimiz kurallara göre bu profilin çalışacağını belirtiyoruz.

$myScaleProfile = New-AzureRmAutoscaleProfile -DefaultCapacity 2 -MaximumCapacity 10 -MinimumCapacity 2 -Rule $myRuleScaleOut,$myRuleScaleIn -Name "autoprofile"

Resim 13

Oluşturmuş olduğumuz scale set profilini uygulamak için aşağıdaki komutunu çalıştırarak profil atamasını gerçekleştiriyoruz.

Add-AzureRmAutoscaleSetting -Location $myLocation -Name "autosetting" -ResourceGroup $myResourceGroup -TargetResourceId /subscriptions/$mySubscriptionId/resourceGroups/$myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/$myScaleSet -AutoscaleProfile $myScaleProfile

Scale set olarak oluşturduğumuz vm’ e rdp veya powershell ile uzak bağlantıları sağlamak için Azure Load Balancer üzerinde oluşturulan NAT kurallarını listeleyerek bağlantıyı sağlayabiliyoruz.

$lb = Get-AzureRmLoadBalancer -ResourceGroupName "rg-vmss" -Name "utnlb"

Get-AzureRmLoadBalancerInboundNatRuleConfig -LoadBalancer $lb | Select-Object Name,Protocol,FrontEndPort,BackEndPort

Get-AzureRmPublicIpAddress -ResourceGroupName "rg-vmss" -Name utnlb01 | Select IpAddress

Resim 14

Resim 15

Artık scale set olarak oluşturduğumuz vm’ i kullanabiliriz. Bu makalemizde Azure üzerinde neden scale set vm konumlandırmalıyız konusunu ve scale set vm’ in PowerShell kullanılarak nasıl oluşturulabileceğinden bahsetmiş olduk. Umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek üzere.

Ofis 365 uygulamaları günden güne dünyada bir çok kullanıcı ve kurumun hayatına girmeye devam ediyor. Günümüzdeki güvenlik risklerinin çoğalması sebebi ile Ofis 365 tarafında güvenlik anlamında bir çok yol alınıyor. Bunlarda bir tanesi İki Faktörlü Kimlik Doğrulama. Bu özellik bir çok kurum tarafından devreye alınır duruma geldi. Bulut ortamda hiçbir sorun olmadan çalışan bu mekanizma bilgisayarımıza kurulu olan Ofis uygulamalarında bağlantı sorununa neden olabilmekte. (Outlook, Skype Kurumsal, One Drive, Sharepoint gibi)

Makalemizde İkili kimlik doğrulamanın aktif edilmesi ile birlikte yerleşik olarak kurulan Ofis 365 uygulamaları (Outlook, Skype Kurumsal, One Drive, Sharepoint) üzerinde kimlik doğrulama işlemlerinin sorunsuz çalışabilmesi için yapılması gerekenleri anlatacağız.

Skype uygulaması ile başlayacağız. Bu adımlarda Skype ve Exchange Online tarafında işlemler yapmamız gerekecek. Öncelikle Skype işlemleri ile başlayalım. PowerShell üzerinden Skype ile ilgili bazı komutlar çalıştıracağımız için öncelikle Powershell Skype modülünü aşağıdaki adresten yüklemelisiniz.

https://www.microsoft.com/en-us/download/details.aspx?id=39366

Bu yükleme işleminden sonra öncelikle Ofis 365 hesabımız üzerinden oturum açalım.

$sfboSession = New-CsOnlineSession -UserName firma@firmaaalanadi.com

Import-PSSession $sfboSession

Yukarıdaki işlemlerden sonra login olma adımlarını tamamladık. İşlem yapabilecek kütüphane çağırma işlemlerini tamamladık. Şimdi öncelikle İkili Kimlik doğrulama işlemi için Modern Kimlik Doğrulama özelliğinin aktif lup olmadığına bakalım.

Not: Eski Ofis 365 üyeliklerinde bu varsayılan olarak kapalı gelirken yeni aboneliklerde varsayılan olarak açık gelmektedir. Özelliğin durumunu görüntülemek için aşağıdaki komutu çalıştıralım.

Get-CsOAuthConfiguration

Şu anda bu özelliğimiz kapalı durumda.

Bu özelliğimizi açmak için aşağıdaki komutu çalıştıralım.

Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

Komutun çalışmasından sonra aşağıdaki durumu gözlemleyelim. Gerekli ayarımız aktif oldu. Bu işlemden sonra İkili Kimlik Doğrulaması aktif edilen hesaplarda yerleşik uygulama Skype Kurumsal Kullanılması durumunda oturum açma işlemlerinde sorun yaşanmayacaktır.

Bu aşamadan sonra Outlook, Sharepoint ve OneDrive gibi uygulamalarda sorun yaşamamak adına neler yapacağız onları ele alalım. Öncelikle Powershell üzerinden login işlemlerimizi tamamlayalım.

Organizasyon üzerinde Modern kimlik doğrulama açık mı, kapalı mı aşağıdaki komutla kontrol edelim.

Görüldüğü gibi organizasyonumuzda bu özellik kapalı.

Get-OrganizationConfig | Format-Table -Auto Name,OAuth*

Özelliği devreye almak için aşağıdaki komutu çalıştıralım.

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Şimdi durumu tekrar gözlemleyelim. Şu anda özelliğin açıldığını görebiliyoruz.

Buraya kadar olan adımlarda organizasyonda İkili kimlik doğrulama özelliğinin açılmasından sonra lokalde kurulu ofis uygulamalarında ortaya çıkacak olan kimlik doğrulama sorunlarını nasıl çözeceğimizi görmüş olduk.

Buraya kadar olan aşamalar haricinde Powershell üzerinden işlem yapan kullanıcılarda İkili Kimlik Doğrulamasının açık olması durumunda PowerShell üzerinden nasıl işlem yapacaklarına göz atalım.

Exchange Online MFA PowerShell Kullanımı

Exchange Üzerinde İkili Kimlik Doğrulaması açık sistemler üzerinde Powershell kullanabilmek için bir eklenti yüklememiz gerekmekte. Bu işlemi kesinlikle İnternet Explorer üzerinden yapmalıyız.

Öncelikle Exchange yönetim paneline girip Karma linkine tıklayalım açılan ekranda yapılandır butonuna tıklayarak gerekli eklentiyi indirelim.

Eklentiyi kuralım.

Bu aşamadan sonra Exchange Online PowerShell modülü programlarımıza yüklenecek masaüstüne kısayol gelecektir. İkili kimlik doğrulması olan sistemlerde işlemlerimizi buradan yapabiliriz.

Bu işlemler için aşağıdaki komut setini kullanmak gerekir.

Connect-EXOPSSession -UserPrincipalName powershellkullanacakhesap@kurumalanadi.com

Skype Kurumsal MFA PowerShell Kullanımı

Skype için normal Powershell üzerinden aşağıdaki seti çalıştırmamız gerekli.

$Session = New-CsOnlineSession -UserName powershellkullanacakhesap@kurumalanadi.com

TEAMS MFA PowerShell Kullanımı

Skype için normal Powershell üzerinden aşağıdaki seti çalıştırmamız gerekli.

Connect-MicrosoftTeams -AccountId powershellkullanacakhesap@kurumalanadi.com

Ofis 365 Security Center MFA PowerShell Kullanımı

Skype için normal Powershell üzerinden aşağıdaki seti çalıştırmamız gerekli.

Connect-IPPSSession -UserPrincipalName powershellkullanacakhesap@kurumalanadi.com

Sharepoint Online MFA PowerShell Kullanımı

Skype için normal Powershell üzerinden aşağıdaki seti çalıştırmamız gerekli.

Connect-SPOService -Url https://<SP Admin Center>.sharepoint.com

Azure Active Directory MFA PowerShell Kullanımı

Skype için normal Powershell üzerinden aşağıdaki seti çalıştırmamız gerekli.

Connect-AzureAD -AccountId powershellkullanacakhesap@kurumalanadi.com

Bir makalemizin daha sonuna geldik umarım yaralı olur.

Kurum IT sistemlerindeki teknolojilerin son hızla geliştiği ve bizi nerelere getirdiğini hep birlikte yaşıyor ve görüyoruz. Klasik mimari bir yandan devam ederken, bulut sistemler, tümleşik mimari ve hiper tümleşik mimari başta olmak üzere birçok koldan teknolojiler gelişmeye devam ediyor. İnceleme konumuz hiper tümleşik mimari (HCI) ve faydaları. Çünkü ciddi bir ivme ile klasik mimarilere ciddi rakip durumunda. Bu gidişat hiper tümleşik mimarileri çok yüksek yoğunlukla karşımıza çıkaracak. Yine pazara baktığımızda bu konuda çok ürün geliştirildi. Birden fazla firmanın ürünleri mevcut. Bugün sizlere piyasada standartları belirleyen ve rakiplerinin bir kuşak üzerinde bir teknoloji ve üründen bahsedeceğim.

DellEMC VxRAIL

Bir çözüm düşününki, temelinde kendini ispatlamış, lider sanallaştırma çözümü olan VMware var. Ve bu ürün aynı donanım üreticisi ile birlikte vSAN isimli ürünü de geliştiriyor. Size DellEMC sunucu ailesinin sağlam donanımları ile VMware’ in vSAN’ının kusursuz şekilde bir araya getirilmesi ile ortaya çıkan muhteşem HCI çözümünden bahsediyorum. Tamamen kusursuz, akıllı cep telefonu kullanır gibi yönetebileceğiniz bir kurumsal sistem. Kulağa çok hoş geliyor değil mi? Bakalım aşağıdaki başlıklar sizlere neler çağrıştıracak.

Peki nasıl oldu bu iş, nasıl HCI bu kadar popular hale geldi. Ve neler oldu tarihte neler yaşandı? Aslında tüm hikâye, mevcut sistemlerin yönetilmesi ve kablo karmaşasının sistem yöneticilerinin hayatında büyük zaman alması ve git gide daha da karmaşık hale gelmesi ile ortaya çıktı. Günümüzde son kullanıcılardan gelen talepler ve tüm istekler, daha kısa adımlarla kullanılan ve sonuca gitmek için daha az efor gerektiren sistemler olması yönünde. Adımların azaltılması ve operasyonların kolaylaştırılması en kıymetli değer olan zamanı kazanmamıza sebep olacaktır. Dolayısıyla sistemlerde neden kolaylaştırılmasın? İşte bunun için başlatılan süreci aşağıdaki gibi görebiliriz,

Gördüğünüz gibi aslında VxRAIL ciddi bir tecrübenin ve birikimin bal peteğinden süzülmüş ve lezzetlendirilmiş damlaları gibi. Netice itibarı ile bu kadar kısa sürede bu kadar ilgi görmesi ve zirveye yerleşmesinin temelinde de bu yatıyor.

Avantajları rakamlara dökecek olursak, %73 kurulum kolaylığı sağlıyor. %46 işletme operasyonlarında kolaylık ve fayda sağlıyor. Peki 5 yıllık yatırım maliyetinde rakam ne? hesaplanmış raporlarda rakam %69 olarak çıkıyor. Çok ciddi değil mi? Evet inanılmaz rakamlar ve ayrıca teknoloji getirisi.

Peki başka neler mevcut. Hangi diskler, hangi RAM’ler kullanılabiliyor. Bunları en anlaşılır şekilde aşağıdaki gibi görebilirsiniz. Burada da yine tecrübeli ve kıdemli sunucu üreticisi DellEMC’ nin PowerEdge sunucu ailesinin üstün ürünleri bizleri karşılıyor. Oldukça geniş ürün skalası ile her ihtiyaca uygun ürünler mevcut. Aşağıdaki ekran görüntüsünde kullanılan ürünlerin detaylarını görebilirsiniz.

Şu an pazarda 14ncü nesil VxRAIL kullanılıyor. Sistem olarakta sürüm 4.7 kullanılıyor. VxRAIL’in Sunucu modellerine göre yeteneklerini bir tabloda görmek isterseniz, aşağıdaki gibi görebilirsiniz. Bu tabloda ihtiyaç duyduğunuz tüm seçenekleri bulabilirsiniz.

HCI sistemler ilk emeklemeye başladıklarında en büyük problem disk ilavesi idi. Aslında bazı sistemlerde hala öyle. Yani disk ilavesi gerektiğinde size node ilavesi zorunluluğu getiriyordu. Düşünsenize disk alanına ihtiyacınız var ve siz CPU ve RAM’de almak zorunda kalıyorsunuz. Bitmiyor yeni gelen CPU’lar için lisans’ta almak zorundasınız. Sadece sanallaştırma tarafı değil yedekleme ve çalışan sistemler tarafında üstelik. İşte sırf bu yüzden o zamanlar HCI sistemleri çok fazla önermiyorduk. Dediğim gibi hala paket paket büyümek zorunda olan sistemler var ve size ilave lisans alma zorunluluğu mevcut. Size önerim şiddetle uzak durmanız ve esnek çözümlere yönelmenizdir. Şimdi bu işler VxRAIL’de nasıl oluyor? Aşağıdaki ekran görüntüsünü detaylandıralım isterseniz. Bu ekran görüntüsü tüm sorularınızın cevabı olacak nitelikte.

VxRAIL’I en az 3 node ile başlatmak hem performans hemde güvenlik açısından sizi çok rahatlatacaktır. Ayrıca ilk yatırımı bu şekilde yapmak zaten kurum yararına olacaktır. Hem güvenlik hemde performans anlamında en faydalı seçim olacaktır. Rakip çözümler tek node bile başladıklarını söyleyip avantajmış gibi lanse ediyor olabilirler. Ama siz kanmayın çünkü netice itibarı ile kurumunuzun kalbi olan verilerinizin barındırıldığı yer bu sistemler olacaktır. Burada yaşayacağınız herhangi bir kayıp cevabını veremeyeceğiniz sorulara sebep olabilir.

Detaylandırmak gerekirse, yukarıdaki ile 3 node ile başlangıç yaptıktan sonra, eğer CPU ve RAM ihtiyacınız varsa node ilave edebilirsiniz. Üstteki görüntünün orta kısmında göreceğiniz üzere en alttaki node size yeni güç sağlayacaktır. Peki CPU ve RAM ihtiyacım kalmadı, ama disk ihtiyacım var. Yine node’mu alacağım. HAYIR!!!

Sadece disk ilavesi ile devam edebilirsiniz. Onuda yukarıdaki görüntüdeki sağ tarafta görebilirsiniz. Işte bu esneklikler bizi o kadar rahatlattı ki, artık HCI sistemleri kurumunuzda kullanmamak için hiçbir neden kalmadı.

Demiştik ya VxRAIL tam bir hiper bütünlelik sistemdir. Tüm veri bu yapı içinde ve stabil şekildedir. O zaman yedekleme ve veri koruma nasıl olacak. Bazı rakiplerde hala verinin dışarı çıkartılması sorun. Oysaki VxRAIL içinden veriyi yedekleme yazılımınız ne olursa olsun dışarı çıkarmak, disk ve tape sistemlerde korumak çok kolay ve problemsiz. Bu iş içinde DellEMC ürünü olan DPS suite tüm yetenekleri ile yanı başınızda. DPS suite içinde Avamar ve Networker size ister disk sistemlere isterseniz tape sistemlere veriyi çıkarmak için yardımcı olacaktır.

Son olarak ISV olarak kısaltılan bir terimden bahsetmek istiyorum sizlere. ISV “Indepentent Software Vendor” cümlesinin kısaltılmış halidir. Bu şu demek oluyor aslında; Ey Vendor, sen donanımı ürettin ama benim ürettiğim yazılım senin sisteminde çalışırmı çalışmazmı ben garanti vermiyorum. Dolayısıyla aldığınız donanım ve HCI çözümü yazılım üreticileri tarafından onaylı ve sertifikalı hale gelmeden tam bir güven sağlayamayabilir. Tam burada yazımıza en can alıcı aşağıdaki ekranı ilave ediyoruz.

Yukarıda gördüğünüz tüm ürünler tabiki portföyün çok kısıtlı bir kısmı. Listeye en son büyük yazılım devi  SAP’nin HANA çözümü ilave oldu. Evet yanlış okumadınız. SAP HANA artık VxRAIL üzerinde perofmans ve stabilite olarak sertifikalı.

Aslında konu özelinde saatlerce konuşulup yazılar yazabiliriz ama en önemli hatları ile VxRAIL’i sizlere yukarıdaki gibi açıklayabiliriz. Eğer iş yükünüz yukarıdaki kriterlere uygun ise sizde çalıştığınız kurumlara katma değeri yüksek bu tip sistemlerle kazanımlar sağlayabilirsiniz. Unutmayın, yönetim kolaylığı, verimlilik ve sağlam sistemleri kullanmak sizinde hakkınız.

Office 365 taşıma senaryolarından birisi olan Hybrid Deployment ile Office 365 içerisinde yeni bir Exchange Online organizasyonu oluşturulmakta ve bu organizasyon yerelde barındırılan Exchange Server organizasyonu ile entegre edilmektedir. Bu entegrasyon işleminde yerel Active Directory kaynakları bulut hizmetleri ile senkronize olup, aşağıdaki özellikler aktif edilmektedir.

·         Yerel Exchange Server ve Office 365 arasında güvenli mail trafiği

·         Ortak paylaşılan bir domain alanı için (ör: domain.com) her iki exchange organizasyonu tarafından da yönetilen mail akışı

·         Birleştirilmiş GAL adres listesi

·         Yerel Exchange Server ve Office 365 arasında free/busy takvim bilgilerinin ortak kullanılması

·         Gelen ve giden maillerin merkezi kontrollerinin gerçekleştirilmesi. İstenildiği takdirde tüm mail trafiği yerel veya online Exchange sunucular üzerinden yönlendirilebilir.

·         Yerel Exchange Server ve Office 365 tarafından kullanılan ortak Outlook Web App adresi

·         İki taraflı istenildiği zaman mailbox taşıma işleminin gerçekleştirilebilmesi

·         Yerel Exchange Server ve Office 365 arasında Message Tracking, MailTips ve Multi-Mailbox Search işlemlerinin gerçekleştirilebilmesi

·         Yerel Exchange Server hesapları için bulut tabanlı mesaj arşivleme imkanı

Aşağıdaki diyagramda örnek bir Hybrid Deployment mimarisi görülmektedir. Yerel Exchange Server Client Access Server ile Office 365 Hybrid entegrasyonu gerçekleştirilmiştir.

Resim 1

Office 365 Hybrid Deployment ön gereksinimleri

Hybrid yapılandırmasını gerçekleştirilmesi için var olan altyapıda bazı ön gereksinimlere ihtiyaç duyulmaktadır.

Yerelde bulunan tüm Exchange 2010,2013,2016 ve 2019 sunucuların üzerinde en güncel Cumulative Update paketinin kurulmuş olması gerekmektedir.

Forest Functional Level min. Windows Server 2003 olması gerekmektedir.

Ortamda en az Windows Server 2003 SP1 işletim sistemine sahip bir Domain Controller sunucusu olması gerekmektedir.

Yerel Exchange Web hizmetlerinin (Outlook Anywhere, AutoDiscover, Outlook Web App, Active Sync) internet üzerinden sağlıklı çalıştığının kontrol edilmesi gerekmektedir.

Exchange hizmetleri için kurumsal sertifikaların alınmış olması gerekmektedir.

Yerel Public Folder hesaplarının Office 365 migration işlemi için hazırlanması gerekmektedir.

Office 365’e taşınan istemciler için aşağıdaki Office sürümlerinin konumlandırılması

·         Office 2003 kullanan makinalar var ise => Service Pack 3 (sadece POP3 veya IMAP olarak kurulabilir.)

·         Office 2007 => Service Pack 3 + KB2687404

·         Office 2010 => Service Pack 2 yüklü olmalıdır.

·         Office 2013

·         Office 2016

·         Office 2019

Hybrid Deployment özellikleri ve bileşenlerinin, doğru çalışması için protokollerin, bağlantı noktalarının ve bağlantı uç noktalarının Office 365 tarafından erişilebilir olmasını gerekir. Hybrid Deployment yapılandırmadan önce, şirket içi ağınızın ve güvenlik yapılandırmanızın aşağıdaki tablodaki özellikleri ve bileşenleri destekleyebildiğini doğrulamanız gerekmekte. Protokollere, bağlantı noktalarına ve bitiş noktalarına izin vermenin yanı sıra, ağınızdaki bilgisayarların, aynı zamanda listelenen IP adreslerine, bağlantı noktalarına ve URL’lere erişebilmeleri gerekir. Office 365 URL ve ip adres listesine aşağıdaki adresten ulaşabilirsiniz.

https://go.microsoft.com/fwlink/?LinkId=823100

Hybrid deployment protokol, port ve endpoints gereksinimleri:

Bu makalemizde Office 365 Hybrid Deployment hakkında genel bilgi verip, ön gereksinimlerinin neler olduğundan bahsetmiş olduk. Umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek üzere.

Bir önceki makalemizde Office 365 Hybrid Deployment hakkında genel bilgi verip, ön gereksinimlerinin neler olduğundan bahsetmiştik.

Aşağıdaki link üzerinden bu makaleme ulaşabilirsiniz;

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/02/03/exchange-server-2019-ile-office-365-hybrid-deployment-b-l-m-1.aspx

Artık şimdi Exchange 2019 olan bir sistem üzerinde Hybrid Deployment için gerekli olan çalışmalara başlayabiliriz.

Gereksinimlerde de bahsettiğimiz üzere Exchange sunucumuzun Outlook Connectivity ve Autodiscover servislerinin sorunsuz çalışması gerekiyor. Bu servislerin kontrolünü Microsoft’un sistemi olan https://testconnectivity.microsoft.com/ adresinden kontrol edeceğiz.

Test Connectivity sayfasına ilk girdiğimizde gelen sayfa içerisinde bulunan “Exchange Server” tabındaki “Outlook Connectivity” seçeneğini seçerek işlemlere başlıyoruz.

Resim 01

Ardından testimizi gerçekleştireceğimiz mail hesabına ait email, logon name ve password bilgilerini girip, “Perform Test” butonuna tıklıyoruz. Mail hesabının outlook’ a bağlanmada bir sorun yaşayıp, yaşamadığını kontrol edeceğiz.

Resim 02

Girmiş olduğumuz bilgiler doğrultusunda kontroller gerçekleştiriliyor.

Resim 03

Kontroller sonrasında çıkan sonucun “Conenctivity Test Successful with Warnings” olması gerekiyor. Eğer kırmızı renkte olan hata alırsanız sonucun detayına bakarak bu problemi gidermeniz gerekiyor.

Resim 04

“Outlook Conenctivity” testmizi tamamladıktan sonra “Outlook Autodiscover” testini gerçekleştireceğiz.

Resim 05

Tekrardan testlerimizi gerçekleştireceğimiz mail hesap bilgilerini girdikten sonra “Perform Test” butonuna tıklıyoruz.

Resim 06

Girmiş olduğumuz bilgiler doğrultusunda kontroller gerçekleştiriliyor.

Resim 07

Kontroller sonrasında çıkan sonucun “Conenctivity Test Successful with Warnings” olması gerekiyor. Eğer kırmızı renkte olan hata alırsanız sonucun detayına bakarak bu problemi gidermeniz gerekiyor.

Resim 08

Bu makalemizde Excahnge 2019 üzerinde bulunan Outlook Conenctivity ve Outlook Autodiscover servislerine ait kontrollerin nasıl yapılacağından bahsetmiş olduk. Umarım faydalı bir makale olmuştur. Bir sonraki makalede görüşmek dileğiyle.

Bir önceki makalemizde Excahnge 2019 üzerinde bulunan Outlook Conenctivity ve Outlook Autodiscover servislerine ait kontrollerin nasıl yapılacağını göstermiştik.

Makalemin ilk iki bölümüne aşağıdaki linklerden ulaşabilirsiniz;

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/02/03/exchange-server-2019-ile-office-365-hybrid-deployment-b-l-m-1.aspx

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/02/03/exchange-server-2019-ile-office-365-hybrid-deployment-b-l-m-2.aspx

Testlerimizden de başarılı bir şekilde geçtiğimize göre artık Hybrid Deployment için gerekli olan kurulumları gerçekleştirebiliriz. Kurulumların ilk başında Azure AD Connect Tool’u geliyor.

Bildiğiniz üzere Azure AD Connect Tool’u Local AD objelerini Azure AD üzerine eşitlemek için kullanılıyor.

Aşağıdaki adres üzerinden Azure AD Connect Tool’unu indiriyoruz.

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Azure AD Connect Tool’u için OS gereksinimleri detaylarda yazmaktadır. Tavsiye edilen yöntem Azure AD Connect Tool’unun yeni bir sunucu üzerine kurulmasıdır. Yeni sunucu kuramıyorsanız mevcut bir sunucu üzerine de kurulumu yapabilirsiniz.

Resim 01

İndirme işlemi tamamlandıktan sonra uygulamayı çalıştırıyoruz ve sözleşmeyi kabul ettikten sonra “Continue” butonuna tıklayarak devam ediyoruz.

Resim 02

Hybrid Deployment yapacağımız için kurulum adımına “Customize” butonuna tıklayarak devam ediyoruz.

Resim 03

“Install” butonuna tıklayarak Azure AD Connect Tool’unun kurulumunu tamamlıyoruz.

Resim 04

Resim 05

Kurulum tamamlandıktan sonra sıra geldi ayarların yapılmasına kullanıcıların şifrelerini Azure AD üzerine eşitlemek için “Password Hash Synchronization” seçeneğini seçerek devam ediyoruz.

Resim 06

Office 365 panelinde global admin yetkisine sahip olan hesabın bilgilerini giriyoruz.

Resim 07

Local AD objelerini bağlanmak için ise “Add Directory” butonuna tıklıyoruz.

Resim 08

Local AD içerisinde “Enterprise Admin” grubuna ait hesabı buraya tanımlıyoruz.

Resim 09

Local AD ortamımıza erişim sağladıktan sonra “Next” butonuna tıklıyoruz.

Resim 10

Local AD ve Azure AD ortamlarına erişimler kontrol ediliyor.

Resim 11

Kullanıcıların Office 365 portalına hangi AD attribute ile girme ayarına geldiğinde Exchange sunucu üzerinde kullanılan Accepted Domain’inin Office365 üzerinde tanımlı olmadığını görüyoruz. Bu sebeple Azure AD Connect Tool’unun kurulumuna devam edebilmek için kullandığımız domaini Office 365 üzerine tanımlamamız gerek.

Not: Kullandığımız domaini tanımlamadan da işleme devam edebiliriz. Fakat bu şekilde işlemi gerçekleştirdiğimizde kullanıcıların Office 365’e erişim sağlarken girmek durumda olacakları hesap bilgilerinin sonu “onmicrosoft.com” domaini ile bitecektir.

Resim 12

Bu makalemizde Azure AD Connect Tool’unun kurulum ve ayarlara ait adımların bir kısmının nasıl yapılacağını göstermiş olduk. Yeni bölümde Azure AD Connect Tool’una ilişkin yapılandırmaya devam edeceğiz. Umarım faydalı bir makale olmuştur. Bir sonraki makalede görüşmek dileğiyle.

Azure üzerinde her geçen gün artan pek çok servis bulunmaktadır. Artık kimse bunların listesini veya sayısını paylaşmak istemiyor çünkü bunları yazdıkları tarih’ den 3 ay sonra bu rakamlar geçersiz kalıyor. Bir zamanlar Azure üzerinde 150’ den fazla servis var şeklinde yazarken artık sadece aşağıdaki link’ i paylaşıyorum;

https://azure.microsoft.com/en-us/services/

Benim bu makalede ele alacağım servis DDOS servisi.

Distributed denial of service (DDoS) saldırıları, uygulamalarını buluta taşıyan müşterilerin karşılaştığı en büyük kullanılabilirlik ve güvenlik sorunlarından birisidir. Uzun yıllardır bildiğimiz ve aslında yerleşik sistemler veya bulut sistemleri fark etmeksizin uygulama veya hizmetlerimize karşı düzenlenebilir. Bir DDoS saldırısının temel amacı, bir uygulamanın kaynaklarını tüketmek ve bundan dolayı uygulamanın veya servisin hizmet veremez duruma gelmesini sağlamaktır.

Dediğim gibi DdoS yeni karşılaştığımız bir atak türü değil, yıllardır aslında DdoS saldırıları ile yaşamayı öğrendik. Ancak öğrendiğimiz tecrübeler ve çözümler hep yerleşik sistemler için olunca Azure üzerinde veya bir başka bulut sağlayıcısı üzerinde işler biraz değişiklik gösteriyor.

Öncelikle bulut üzerinde SaaS, PaaS veya IaaS olarak bildiğimiz katmanlar var. Uygulamanızın hangi katmanda ise aslında ona göre farklı çözümler sunulmaktadır. Buradaki kritik konu yerleşik sistemleri iyi bildiğimiz kadar bulut sistemlerine hâkim olmayışımız.

İlk olarak yerleşik sistemlerden alışkın olduğunuz pek çok marka aslında Azure üzerinde size hizmet etmeye hazır olarak sunulmaktadır.

Barracuda gibi, F5 gibi, Imperva gibi yerleşik kurumsal müşteriler tarafından tercih edilen ürünleri azure üzerinde konumlandırıp mevcut sistemlerinizi bulut üzerinde de aynı yerleşik sistemleri koruduğunuz gibi koruyabilirsiniz.

Burada bulut sağlayıcı aslında birden ISP rolüne geçer.

Örneğin bir bankayı düşünün, yerel bir veya iki ISP den internet hattı alıyor ve tüm veri merkezini bu tarz cihazlar ile koruyor. Ancak gelen atak ISP için bile fazla olur ise bu durumda işler değişebilir.

Örneğin bizim güvenlik ekibimizin geçen yıl bir bankaya yaptığı saldırı 7.6Gbps olarak kayıtlara geçti;

Yani artık bu rakamlar ulaşılması zor rakamlar değil. Bu durumda ISP bunu kesemiyor ise zaten sizin DdoS cihazınızın bir anlamı yok demektir. Çünkü konu ISP yi aşmış oluyor.

Azure da tabiki yerel ISP lere göre çok daha dağıtık ve büyük veri merkezleri olduğu için öncelikle bu sınır veya eşik değeri çok yüksek. Bu durumda kiralayacağınız yukarıdaki ürünlerin ayarlaması büyük önem kazanıyor. Yani böyle büyük bir trafik ile saldırı gelir ise yapılandırmanızın iyi olmaması durumunda işler kötüye gidebilir.

Bu nedenle bu ürünler daha çok belirli DdoS atakları veya özellikle Application Firewall, NLB gibi hizmetler için tercih ediliyor.

Peki bu cihazları kullanmadan korunmak mümkün mü?

Tabiki. Zaten PaaS kullanıyorsanız bu cihazlar çok anlamlı olmaz. IaaS da evet mevcut sanal makine parkurunuzu koruyabilir ama platform değiştikçe kullanacağınız ürünler de değişmektedir.

Örneğin bir uygulama geliştirdiniz ve Web App olarak konumlandırdınız. Üstüne bunu veri tabanını da PaaS’ dan aldığınız bir hizmete bağladınız. Özetle ortada ne IIS makinesi ne SQL makinesi yok, hepsi birer hosting hizmeti gibi Microsoft tarafından sunuluyor.

Böyle bir senaryoda ek olarak DdoS koruma paketi almanız şart değil. Çünkü Azure veri merkezleri çok büyük olduğu için sunduğu tüm stansart hizmetleri kapsayan bir koruma özelliği mevcut.

Örneğin DNS hizmetiniz yerel bir ISP de, ama atak yedi ve sizin de canınız yandı. Bunu aldınız ve Azure DNS’ servisine taşıdınız. Soru şu, peki bu hizmetin DdoS koruması var mı? Evet ama detaylandırmamız gereken birkaç konu da yer alıyor.

Basic ve Standart isminde iki hizmet yer almaktadır.

Basic, tüm azure servisleri için aslında geçerli olan temel bir koruma sağlar. Bu koruma bir nevi aslında genel olarak azure veri merkezlerinin trafiğini izleyip olası temel atakların kesilmesini sağlar. Ancak birileri size özel yani hedefli atak yapıyor ise bu durumda işler değişir.

Gördüğünüz gibi standart paketi ücretli ancak gerçekten bir şirket için gereksinimleri karşılamak üzere tasarlanmıştır.

Güvenlik işinde olanlar hemen şunu soracaktır, peki ne tür ataklar konusunda DdoS koruması sağlıyor?

Temelde 3 tip atak için koruma sağlamaktır;

Volumetric

Protocol

Resource (application) Layer

Layer 3-7 arasında çalışır.

Temel faydaları;

Native platform integrations

Azure üzerinden kolayca yönetilir. Kaynaklarınız ve onların yapılandırmalarını anlayabilir. Çünkü tek bir platform olarak çalışmaktadır.

Turn-key protection

Aktif edilmesi ile tüm sistemi korur. Ek yapılandırma gerektirmez. Olası ataklarda kendisi otomatik aksiyon alır.

Always-on traffic monitoring

Trafik 7x24 izlenmektedir.

Adaptive Tuning

En kıymetli özelliklerinden biriside uygulamalarınızı zaman içerisinde analiz ederek bir trafik şablonu çıkarabilir. Bu sayede uygulamanıza özel bir plan yapabilirsiniz. Bir nevi korumayı uygulamanız için kişiselleştirebilirsiniz.

Multi-Layered protection

Eğer Azure Web Application Firewall ile beraber kullanırsanız tüm katmanların korunduğu bir model sunar.

Extensive mitigation scale

Çok büyük DDoS saldırılarına karşı koruma sağlamak için, küresel kapasiteye sahip 60'ın üzerinde farklı saldırı türüne karşı tecrübelidir.

Attack analytics

Bir saldırı sırasında beş dakikalık aralıklar ile ayrıntılı raporlar alabilirsiniz. Saldırı sona erdikten sonra tam bir özet rapor alma imkânınız var. Bu sayede aslında olup biten her şeyi izleme şansınız ve geriye dönük inceleme şansınız olur.

Attack alerting

Bir saldırı başladığında veya bittiğinde sizi uyarır. Yine ayarlarınıza bağlı olarak bir loglama operasyonunuz var ise onun ile entegre olabilir (Microsoft Azure Log Analytics, Splunk, Azure Storage, Email ve Azure Portal gibi).

Peki nasıl çalışır?

Özetle gelen trafik 7x24 izlenmektedir. Eğer olası bir anormallik tespit edilir ise bu trafik Azure DdoS servisinden kontrollü bir şekilde geçirilir. Temiz olan trafik sunucu veya uygulamalarınıza ulaşırken atak tipi ile eşleşen trafik ise kesilir. Tüm bunlar tabiki loglanacaktır.

Peki bir uygulamayı devreye aldınız. Daha sonra birileri atak yapmadan siz kendi kendinize atak yapmak istiyorsunuz ve Azure DDos korumasının ne kadar başarılı olduğunu doğrulamak istiyorsunuz.

https://www.ixiacom.com/products/breakingpoint-cloud

Buradan DdoS testi yaptırabilirsiniz.

Örneğin yukarıda güzel bir test var. Azure son derece başarılı bir şekilde bu atağı yakalamış. Tabiki bu bir test, gerçek hayatta saldıranlar her zaman bir adım önde, yani burada bilinen atak türleri var;

Bu ve benzeri 60 atak türü için Azure hazır. Ama örnek 61. Atak için hiçbirimiz hazır değiliz. O noktada ise 7x24 global veri merkezlerinin trafiğinin takip edilmesi ve bunun makine öğrenme teknolojisi ile birleştirilmesi ilse yine kendimizi bir nebze güvende hissedebiliriz.

Özetle, Azure DdoS koruması ile kolay kolay size kimse bir şey yapamaz. Bunun neden söylüyorum, on premde bir müşterime çok ciddi atak yapılıyordu, Türkiye’ nin sayılı ISP lerin den birisindeydi, ancak atak öyle geliyordu ki ISP bile ilgili ip için anons kesiyordu. Sonra komple bu uygulamayı azure’ a taşıdık ve her şey bitti gitti. Aldıktan sonra birkaç deneme yaptılar ama azure gibi global bir oyuncu ile başa çıkamadılar. Zaten böyle bir veri merkezine ancak Google, Amazon, Azure ve benzeri bir veri merkezinden saldırmak lazım ki bu malum izin olmadan onaylanmıyor. Yapmaya kalkarsanız yani azure da bir veya bir den çok makine açıp saldırmayı denerseniz bir süre sonra trafiğinizin otomatik kesildiğini göreceksiniz.

Tabiki bu işi çok organize yapan ve onbinlerce zombi makinesi olanlar için işler kolaylaşsa bile bu durumda da gelen atak tipi bilinen bir atak ise hiçbir işe yaramayacaktır.

Özetle benzer durum bir müşterimizi azure’ a alarak sorununuz çözdük.

Gelelim fiyatlara. Azure genel olarak pahalı! Malum bu biraz aslında aldığınız hizmet ile ilgili. Klasik CPU, RAM, Disk alırsanız biraz pahalı olabilir (şimdi karşılaştırmaya girmiyorum ama yerel bir ISP ile global bir bulut oyuncusunun alt yapısı bir değil ama müşteri bazen bu beni ilgilendirmiyor beni aylık ödediğim rakam ilgilendiriyor dediği için) ancak katma değerli bir hizmet almak isterseniz her zaman ucuz.

WAF, DDos, DNS, WebApp, PaaS hizmetleri, CDN vb.

https://azure.microsoft.com/en-us/pricing/details/ddos-protection/

Ne kadar çok data trafiğiniz olur ise o kadar çok ödersiniz.

Örnek aylık 1TB trafiğiniz olur ise 215$ para ödersiniz.

Umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek üzere.

Kaynak:

https://docs.microsoft.com/en-us/azure/virtual-network/ddos-protection-overview

Bir önceki makalemizde Azure AD Connect Tool’unun kurulum ve ayarlarının bir kısmına ait yapılandırmayı göstermiştik.

Bundan önceki makalelerime aşağıdaki linklerden ulaşabilirsiniz;

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/02/03/exchange-server-2019-ile-office-365-hybrid-deployment-b-l-m-1.aspx

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/02/03/exchange-server-2019-ile-office-365-hybrid-deployment-b-l-m-2.aspx

http://www.cozumpark.com/blogs/cloud_computing/archive/2019/02/03/exchange-server-2019-ile-office-365-hybrid-deployment-b-l-m-3.aspx

Azure AD Connect Tool ayarlarının yapılandırılmasına kaldığımız yerden deva edeceğiz. En son domainimiz Office 365 tarafında tanımlı olmadığı için makalemizi bu aşamada bitirmiştik. Şimdi portal.office.com adresine global admin yetkisine sahip hesap ile giriş yapıyoruz.

Resim 01

Resim 02

Sol taraftaki menüden “Kurulum” ve “Etki alanları” bölümüne gelerek “Etki alanı ekle” butonuna tıklıyoruz.

Resim 03

Domainimizi bu alana yazarak “Sonraki” butonuna tıklıyoruz.

Resim 04

Domaininin bize ait oluğunu doğrulamak için otomatik üretilen TXT kaydını DNS sunucumuza giriyoruz.

Resim 05

Resim 06

“Doğrula” butonuna tıklayarak işlemlere devam ediyoruz.

Resim 07

Sahip olduğumuz Office 365 paketinin içinde olan ve kullanmak istediğimiz servisleri seçip, “Kaydet ve kapat” butonuna tıklıyoruz.

Resim 08

Diğer DNS kayıtlarını ilk aşamada eklememize gerek yok. Sadece domaini doğrulamak yeterli.

Resim 09

Sonrasında Azure AD Connect Tool’una gelerek refresh butonuna tıklıyoruz.

Resim 10

Gördüğünüz gibi domaini eklediğimiz için domainimiz “Verified” olarak belirlendi. Daha sonrasında kullanıcıların Office 365 paneline hangi attribute ile login olacağını belirlediğimiz alanı “Userprincipalname” olarak seçiyoruz. Bu değer değişebilir. “Next” butonuna tıklayarak kurulum ayarlarına devam ediyoruz.

Resim 11

Local AD içerisinde hangi Organization Unit’lerin Office 365 ile eşitleneceğini belirtiyoruz ve “Next” butonuna tıklayarak işleme devam ediyoruz.

Resim 12

Bu alanda istersek sadece belirli attribute değerleri dolu olan kullanıcıların eşitlenmesi için ayarları gerçekleştirebiliyoruz ve “Next” butonuna tıklayarak devam ediyoruz.

Resim 13

Bu bölümde ise belirli bir grup içerine üye olan objelerin eşitlenmesi sağlayabiliyoruz. Demo ortamı olduğu için ben tüm ayarları varsayılanda bıraktım.

Resim 14

“Exchange hybrid deployment” seçeneğini seçerek, “Next” butonuna tıklıyoruz.

Resim 15

“Start he synchronization process when configuration completes” seçeneğini işaretleyip, ”Install” butonuna tıklıyoruz.

Resim 16

Resim 17

Azure AD Connect ayarları tamamlandı.

Resim 18

Synchronization Service Manager uygulamasını açarak eşitlenme işlemlerinin ne aşamada olduğunu ve eğer alınan hatalar varsa detaylarını görebiliyoruz.

Resim 19

Office 365 Admin Center bölümünden “Etkin kullanıcılar” bölümüne geldiğimizde Local AD üzerinde olan objelerin Azure AD üzerine eşitlendiğini görebiliyoruz.

Resim 20

Exchange Online Admin Center içerisinde de “posta akışı” bölümünden “kabul edilen etki alanları” bölümüne geldiğimizde mail rooting görevinde kullanılacak olan domainimizin buraya eklendiğini görüyoruz.

Resim 21

Azure AD Connect Tool’unu kurmuş olduğumuz sunucu içerisinde eşitleme işlemlerini manule olarak yapmak için PowerShell’i yönetici olarak çalıştırıp, aşağıdaki komutları yazıyoruz. Ben bu komutu yazmadan önce Exchange üzerinde 2 adet mail hesabı oluşturdum. Böylelikle manuel eşitleme yaparak, hızlı bir şekilde işlemleri gerçekleştirebiliyorum.

Import-Module ADSync

Start-ADSyncSyncCycle -PolicyType Initial

Resim 22

Etkin kullanıcılar bölümüne oluşturmuş olduğum kullanıcılar geldi.

Resim 23

En önemli nokta Office 365’e taşımak istediğiniz kullanıcını Exchange Online Admin Center içerisindeki “Kişiler” bölümüne “Mail Enable” olarak gelmesi gerekiyor.

Resim 24

Bu makalemizde Office 365 Hybrid Deployment’n gereksinimlerinden olan Azure AD Connect Tool’unun ayarlarının nasıl yapılacağından bahsetmiş olduk. Umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek dileğiyle.

Windows Admin Center uzun süredir beklediğimiz ve biz sistem yöneticilerinin işini kolaylaştıracak yeni nesil bir yönetim aracıdır.

Bu konuda daha önce sizler ile paylaştığım aşağıdaki kaynakları inceleyebilirsiniz;

http://www.cozumpark.com/blogs/windows_server/archive/2018/04/15/windows-admin-center-project-honolulu.aspx

http://www.cozumpark.com/blogs/windows_server/archive/2018/04/22/windows-admin-center-deployment.aspx

http://www.cozumpark.com/blogs/windows_server/archive/2018/04/22/windows-admin-center-yetkilendirme-ve-zleme.aspx

Peki bu makale serisinin devamı niteliğinde olan yeni makalemde sizlere ne anlatmak istiyorum;

Yine bir müşterimdeki hikayemizi hızlıca kaleme aldım.

İstek çok basit aslında, var olan yedekleme senaryosuna bulut yedeklemeyi de eklemek istiyor. Ancak aklında pek çok soru işareti var.

Disk olarak map mi yapalım? Azure site recovery mi deneyelim? 3 parti replikasyon yazılımı mı olsun yoksa Azure Backup Agent’ mı kullanalım?

Senaryoları tabiki arttırmak mümkün, malum her şirketin iş ihtiyaçları, kaynakları ve bütçeleri farklı.

Biz bunların arasından bizim için en uygun olan çözümün Azure Backup çözümü olduğuna karar verdik ancak yönetimini Windows Admin Center üzerinden gerçekleştirmek istiyorduk. Son derece kolay bir şekilde yönetime sahip olan WAC sayesinde müşterim bu süreçleri otomatize edebildi, bizede bunun makalesini yazmak düştü

Öncelikle yukarıdaki makalelere göz gezdirip yapınıza uygun bir kurulum yaptığınızı düşünüyorum. Daha sonra ise azure üzerinde backup almanızı sağlayacak bir aboneliğinizin olduğunu. Bu şartların sağlandığın durumda bu süreci nasıl tamamlıyoruz hep beraber görelim;

İlk olarak Windows Admin Center’ ı azure hesabınıza bağlamamız gereklidir.

Bunun için ayarlar üzerinden azure bölümüne geliyoruz;

Register butonuna basıyoruz.