Merhaba

İlk iki bölümde on-premises Active Directory ortamımızı kurduk ve Microsoft Entra Connect Sync ile kullanıcılarımızı Entra ID’ye senkronize ettik. Kullanıcılarımız artık on-premises parolalarıyla buluta oturum açabiliyor. Bu bölümde tenant’ın güvenlik tarafına geçiyoruz: yeni tenant’larda varsayılan olarak açık gelen Security Defaults’u kapatıp yerine break-glass hesapları ve Conditional Access politikalarıyla daha esnek, denetlenebilir ve istisnaları belgelenmiş bir yapı kuracağız.

Security Defaults ve Conditional Access Farkı

Security Defaults, Microsoft’un her tenant için ücretsiz sunduğu temel koruma paketi. Açık olduğunda tüm kullanıcıların MFA’ya kaydolmasını istiyor, yöneticilerden her oturumda MFA talep ediyor ve legacy authentication (eski kimlik doğrulama) protokollerini engelliyor. Küçük ortamlar için iyi bir başlangıç noktası, ancak iki önemli sınırı var: hiçbir kullanıcı ya da hesap için istisna tanımlanamıyor ve koşula bağlı kurallar (konum, cihaz durumu, uygulama, risk seviyesi) yazılamıyor.

Conditional Access ise “kim, neye, hangi koşulda erişirse ne olsun” sorularını tek tek tanımlayabildiğimiz politika motoru. Microsoft Entra ID P1 lisansı gerektiriyor ve Security Defaults ile aynı anda kullanılamıyor; Conditional Access politikalarını etkinleştirebilmek için önce Security Defaults’un kapatılması gerekiyor.

Senkronizasyon Hesabı ve MFA: Eski ve Güncel Durum

Eski Entra Connect kurulumlarında Security Defaults’tan Conditional Access’e geçişin en sık gerekçesi, senkronizasyon hesabını MFA’dan hariç tutma ihtiyacıydı. Bu sürümlerde Entra Connect, Entra ID’ye Sync_SUNUCUADI_... adıyla oluşturulan bir kullanıcı hesabıyla bağlanıyordu ve MFA isteyen politikalar bu hesabın senkronizasyonunu engelleyebiliyordu.

Güncel sürümde durum farklı. Bölüm 2’de doğruladığımız gibi Entra Connect artık Entra ID’ye kullanıcı hesabıyla değil, sertifikalı bir uygulama kimliğiyle (application-based authentication) bağlanıyor. Kullanıcılara yönelik Conditional Access politikaları bu uygulama kimliğine uygulanmadığı için senkronizasyon için ayrı bir istisna tanımlamamız gerekmiyor. Yani güncel sürümde Security Defaults’tan Conditional Access’e geçişin gerekçesi senkronizasyon değil, istisnaları ve kuralları kendimizin yönetebilmesi.

Adım 1: Break-glass Hesaplarını Oluşturma

Conditional Access ile çalışırken yapılabilecek en tehlikeli hata, yanlış yapılandırılmış bir politika yüzünden tenant’a erişimi tamamen kaybetmek. Break-glass (acil durum erişim) hesapları tam olarak bu senaryo için var: normal yönetim hesapları kilitlendiğinde, MFA altyapısında bir sorun yaşandığında ya da hatalı bir politika tüm yöneticileri dışarıda bıraktığında tenant’a girmemizi sağlayan son kapı.

Microsoft’un önerileri doğrultusunda iki adet break-glass hesabı oluşturuyoruz ve şu kurallara uyuyoruz:

• Hesaplar cloud-only olmalı ve onmicrosoft.com uzantısını kullanmalı. On-premises’ten senkronize edilen bir hesap, on-premises tarafta yaşanacak bir sorundan etkilenir.
• Hesaplar belirli bir kişiye bağlı olmamalı; bir çalışanın ayrılması ya da tatile çıkması erişimi etkilememeli.
• Global Administrator rolü kalıcı olarak atanmalı. Privileged Identity Management kullanıyorsanız bu hesapların rolü eligible (uygun) değil, active (etkin) olmalı.
• Microsoft’un yönetim portalları için zorunlu kıldığı MFA bu hesaplar için de geçerli. Bu yüzden hesaplara phishing-resistant (kimlik avına dayanıklı) bir yöntem, tercihen FIDO2 güvenlik anahtarı ya da passkey kaydediyoruz.
• Kimlik bilgileri fiziksel olarak güvenli bir yerde, iki ayrı noktada saklanmalı.

İki hesabı da aynı adımlarla oluşturuyoruz. Aşağıda bg-admin01 için ekranları tek tek gösteriyorum; bg-admin02 için aynı adımları yalnızca hesap adını değiştirerek tekrarlıyoruz. Kendi tenant’ınızda pwqv yerine tenant’ınızın başlangıç alan adını kullanın. Hesap adlarının tahmin edilmesini zorlaştırmak için üretim ortamında daha az belirgin adlar tercih edebilirsiniz.

Yeni Kullanıcı Oluşturmayı Başlatma

Entra admin center’da Entra ID > Users > All users sayfasını açıp üst menüdeki New user açılır listesinden Create new user seçeneğine tıklıyoruz. Aynı listedeki Invite external user seçeneği başka bir tenant’tan misafir (B2B) kullanıcı davet etmek içindir; break-glass hesabı tenant’ın kendi üyesi olmalı, bu yüzden Create new user ile devam ediyoruz.

Basics Sekmesi

Basics sekmesinde hesabın temel kimlik bilgilerini giriyoruz:

• User principal name: Sol alana bg-admin01 yazıyor, sağdaki açılır listeden alan adı olarak pwqv.onmicrosoft.com seçiyoruz. Listede bakicubuk.tech de görünür; onu seçmiyoruz, çünkü break-glass hesabının özel alan adına ya da DNS’e bağımlı olmaması gerekiyor.
• Mail nickname: Derive from user principal name kutusu işaretli kaldığında UPN’in @ öncesi kısmından otomatik doldurulur, dokunmuyoruz.
• Display name: bg-admin01 olarak giriyoruz.
• Password: Auto-generate password işaretli bırakıyoruz; Entra karmaşık bir geçici parola üretir.
• Account enabled: İşaretli kalıyor.

Basics sekmesinde gerekli yapılandırmayı tamamladıktan sonra Next:Properties seçeneğine tıklayarak devam ediyoruz.

Properties Sekmesi

Properties sekmesinde iş unvanı, departman, şirket adı ve Usage location (kullanım konumu) gibi alanlar bulunur. Break-glass hesabı bir kişiye bağlı olmadığı için bu alanları boş bırakıp Next: Assignments ile ilerliyoruz. Usage location yalnızca hesaba lisans atanacaksa gerekir; break-glass hesaplarının yönetim portallarına erişmesi için lisans zorunlu değil.

Assignments Sekmesi ve Rol Ataması

Assignments sekmesinde hesabı gruplara ekleyebilir ya da rol atayabiliriz. Rol atamasını oluşturma sırasında yapmak, hesabın bir an bile yetkisiz ve yarım yapılandırılmış kalmasını önler. Add role bağlantısına tıklıyoruz.

Açılan Directory roles panelinde arama kutusuna global yazıyor, listeden Global Administrator rolünü işaretleyip Select ile onaylıyoruz. Listede Global Reader gibi benzer adlı roller de çıkar; seçimin Global Administrator olduğundan emin olun.

Panel kapandığında Assignments listesinde Role türünde Global Administrator satırı görünür. Grup üyeliğini burada eklemiyoruz; CA-Exclude-BreakGlass grubunu iki hesap da hazır olduktan sonra oluşturacağız. Next: Review + create ile devam ediyoruz.

Review + create

Son ekranda User principal name, Display name, User type (Member) ve atanan rolü Global Administrator kontrol ediyoruz. Parolayı hala kaydetmediyseniz Previous ile Basics sekmesine dönüp şimdi kaydedin. Her şey doğruysa Create ile hesabı oluşturuyoruz.

Aynı adımları [email protected] için tekrarlıyoruz. İki hesabın Global Administrator ataması Entra ID > Roles & admins > Global Administrator > Assignments sayfasında Active olarak listelenmelidir.

Ardından bu iki hesabı içeren bir güvenlik grubu oluşturuyoruz. Tüm Conditional Access politikalarında istisnayı tek tek kullanıcılarla değil bu grupla tanımlayacağız; böylece istisnalar tek bir yerden yönetilecek ve belgelenmiş olacak.

CA-Exclude-BreakGlass Grubunu Oluşturma

İki hesap da hazır olduğuna göre onları içeren bir güvenlik grubu oluşturuyoruz. Tüm Conditional Access politikalarında istisnayı tek tek kullanıcılarla değil bu grupla tanımlayacağız. Böylece istisnalar tek bir yerden yönetilir ve belgelenmiş olur; ileride bir break-glass hesabını değiştirmek gerekirse politikalara dokunmadan yalnızca grup üyeliğini güncelleriz.

Entra ID > Groups > All groups sayfasında üst menüden New group‘a tıklıyoruz. Tenant’ta henüz bulut grubu olmadığı için liste boş. Bu ekranda Unable to complete due to service connection error gibi bir uyarı görürseniz listenin yüklenmesi sırasında yaşanan geçici bir hatadır; Refresh ile yeniden deneyebilir ya da doğrudan New group ile devam edebilirsiniz.

New Group formunda şu alanları dolduruyoruz:

• Group type: Security. Microsoft 365 türü paylaşılan posta kutusu, takvim ve SharePoint sitesi gibi işbirliği kaynakları oluşturur; Conditional Access istisnası için bunlara ihtiyacımız yok.
• Group name: CA-Exclude-BreakGlass. Adın başındaki CA-Exclude öneki, grubun Conditional Access istisnası için kullanıldığını listede bir bakışta anlatır.
• Group description: Lab’da boş bıraktık. Üretim ortamında “Break-glass hesapları, tüm CA politikalarından hariç tutulur. Üyelik değişikliği onay gerektirir.” gibi bir açıklama yazmak, grubu sonradan görecek yöneticiler için iyi bir belgedir.
• Membership type: Assigned. Dynamic User seçeneği üyeliği bir kurala göre otomatik belirler; istisna grubunda üyeliğin yalnızca bilinçli olarak eklenen hesaplardan oluşması gerektiği için dinamik üyelik kullanmıyoruz.
• Owners: Boş bırakıyoruz. Gruba sahip atamak, o kişiye üyeliği değiştirme yetkisi verir; bu da istisna listesini genişletmenin kolay bir yolu olur.

Members başlığının altındaki No members selected bağlantısına tıklıyoruz.

Add members panelinde arama kutusuna bg yazıyoruz. Listede bg-admin01 ve bg-admin02 kullanıcıları çıkıyor; ikisini de işaretliyoruz. Sağdaki Selected (2) listesinde iki hesabın UPN’lerini kontrol edip Select ile paneli kapatıyoruz.

Forma döndüğümüzde Members alanında 2 members selected yazıyor. Create ile grubu oluşturuyoruz.

Grup birkaç saniye içinde All groups listesinde görünür. Arama kutusuna ca yazdığımızda CA-Exclude-BreakGlass grubunu Group type altında Security ve Membership type altında Assigned olarak görüyoruz. Grubun Object Id değerini not almak faydalı; politikaları ileride PowerShell ya da Microsoft Graph ile yönetirseniz istisna grubunu bu kimlikle referans vereceksiniz.

Her iki hesapla ayrı ayrı oturum açıp FIDO2 güvenlik anahtarı ya da passkey kaydını tamamlıyor ve hesapların sorunsuz çalıştığını test ediyoruz. Break-glass hesaplarının oturum açma etkinliklerinin izlenmesi de en az hesapların kendisi kadar önemli: bu hesaplarla yapılan her oturum açma bir alarm üretmeli. Log Analytics’e aktarılan sign-in loglarında bu hesaplar için bir uyarı kuralı tanımlamak bunun en pratik yolu.

Adım 2: Security Defaults’u Kapatma

Security Defaults ile Conditional Access aynı anda kullanılamaz; Conditional Access politikalarını etkinleştirebilmek için önce Security Defaults’u kapatmamız gerekiyor. Security Defaults’u kapattığımız an ile Conditional Access politikalarının devreye girdiği an arasında kullanıcılar için MFA zorunluluğu ve legacy authentication engeli ortadan kalkar. Bu yüzden bu adımı tamamladıktan sonra ara vermeden Adım 3 ve Adım 4’e geçiyoruz. Üretim ortamında bu işi kullanıcı trafiğinin düşük olduğu bir bakım penceresinde, politikaların tasarımı önceden yazılı olarak hazırlanmış şekilde yapmak gerekir.

Security Defaults Ayarına Ulaşma

Entra admin center’da Entra ID > Overview sayfasını açıp Properties sekmesine geçiyoruz. Sayfanın en altındaki Security defaults bölümünde Your organization is protected by security defaults. ifadesi, tenant’ın şu anda Security Defaults ile korunduğunu gösteriyor. Hemen altındaki Manage security defaults bağlantısına tıklıyoruz.

Sağda açılan Security defaults panelinde değerin Enabled olduğunu ve Your organization is currently using security defaults. mesajını görüyoruz. Panel, MFA’nın hesap ele geçirme saldırılarının yüzde 99,9‘unu durdurabileceğini ve Security Defaults açıkken ele geçirme oranında yüzde 80‘lik bir düşüş görüldüğünü hatırlatıyor.

Disabled Seçimi ve Kapatma Gerekçeleri

Açılır listeden Disabled seçtiğimizde panel turuncu bir uyarıyla With security defaults disabled, your organization is vulnerable to common identity-related attacks. diyor ve altında zorunlu bir Reason for disabling (kapatma gerekçesi) bölümü açılıyor. Burada seçilen gerekçe Microsoft’a geri bildirim olarak gider; hangi seçeneği işaretlersek işaretleyelim Security Defaults aynı şekilde kapanır, tenant’ta başka bir ayar değişmez.

Yine de seçenekler, kuruluşların Security Defaults’u neden kapattığını ve her durumda aslında neyin yapılması gerektiğini iyi özetliyor:

Gerekçelerin dördünden üçü aslında Security Defaults’un işini yaptığını gösteren şikayetler. Lisansı Security Defaults ile sınırlı olan bir kuruluşta bu nedenlerle kapatma yapmak, kullanıcıları MFA’sız bırakır ve Conditional Access ile bir alternatif kurulmadıkça önerilmez.

Gerekçeyi Seçip Kaydetme

Bizim senaryomuz tam olarak ilk seçeneğe uyuyor: My organization is planning to use Conditional Access seçeneğini işaretliyoruz. Bu seçenekte panel ek bir uyarı gösteriyor: Once you disabled security defaults, your organization will not be protected until you create Conditional Access policies to protect your identities. Yani Security Defaults kapandığı andan itibaren koruma, bizim oluşturacağımız politikalara bağlı. Save ile kaydediyoruz.

Save‘e bastığımızda panelin üst kısmında son bir onay kutusu açılıyor: Disable security defaults başlığı altında Disabling security defaults will leave your organization vulnerable to common attacks. uyarısı yer alıyor. Portal, kararın bilinçli verildiğinden emin olmak için bu onayı ayrıca istiyor. Disable ile onaylıyoruz.

İşlem birkaç saniye içinde tamamlanıyor ve sağ üstte Successfully disabled security defaults policy. bildirimi görünüyor. Portal bizi doğrudan Conditional Access | Overview sayfasına yönlendiriyor; Microsoft da bir sonraki adımın politika oluşturmak olduğunu bu şekilde hatırlatıyor.

Conditional Access sayfasının sol menüsü bu bölümde kullanacağımız alanları bir arada gösteriyor:

• Policies: Microsoft-managed policies dahil tüm politikaların listesi. Adım 3 ve Adım 4 burada geçiyor.
• Named locations: Güvenilir IP aralıklarının ve ülkelerin tanımlandığı yer. Konuma dayalı koşullar yazarken kullanılır.
• Authentication strengths: Hangi kimlik doğrulama yöntemlerinin kabul edileceğini belirleyen tanımlar. CA003 politikasında Phishing-resistant MFA gücünü buradan seçeceğiz.
• Classic policies: Eski Azure AD döneminden kalan, yeni politika modeline taşınması gereken klasik politikalar. Yeni bir tenant’ta bu liste boştur.
• Sign-in logs ve Insights and reporting: Politikaların Report-only modunda nasıl sonuç vereceğini görmek için kullanacağımız izleme ekranları.

Security Defaults artık kapalı. Vakit kaybetmeden Microsoft-managed policies’e geçiyoruz.

Adım 3: Policies Sayfası ve Microsoft-managed Policies

Conditional Access menüsünden Policies sayfasına geçiyoruz. Lab tenant’ımızda liste boş: sayfa bize Conditional Access’in ne olduğunu iki örnekle anlatan bir tablo ve Create your first policy diye başlayan üç adımlık bir başlangıç rehberi gösteriyor. Yani tenant’ta henüz hiçbir politika yok; Security Defaults kapandığı için şu anda kullanıcıları koruyan bir kural da yok.

Üst menüdeki seçenekler bu bölüm boyunca kullanacağımız araçlar:

• New policy: Boş bir politika oluşturur. CA001, CA002 ve CA003’ü bununla yazacağız.
• New policy from template: Microsoft’un hazır şablonlarından (örneğin tüm kullanıcılar için MFA, legacy authentication engelleme) politika üretir. Şablonlar hızlı başlangıç sağlar, ama her ayarı kendimiz görmek için bu yazıda politikaları sıfırdan oluşturuyoruz.
• Upload policy file: Daha önce JSON olarak dışa aktarılmış bir politikayı içe aktarır. Politikaları bir test tenant’ından üretime taşımak ya da yedeklemek için kullanışlıdır.
• What if: Belirli bir kullanıcı ve senaryo için hangi politikaların uygulanacağını, oturum açma olmadan simüle eder. Adım 5’te kullanacağız.
• Preview features: Önizlemedeki Conditional Access özelliklerini açıp kapatmayı sağl

Microsoft-managed Policies Hakkında

Microsoft, bazı tenant’larda kendisi Conditional Access politikaları oluşturuyor. Bu politikalar listede Microsoft-managed olarak işaretlenir ve genellikle yöneticiler için MFA, per-user MFA kullanan kullanıcılar için MFA ya da riskli oturum açmalarda yeniden kimlik doğrulama gibi senaryoları kapsar. Microsoft bunları önce Report-only modunda oluşturur ve yöneticilere bildirim gönderir; yönetici bir işlem yapmazsa belirli bir süre sonunda politikalar otomatik olarak On durumuna geçer.

Bizim tenant’ımız Security Defaults ile korunduğu için Microsoft-managed policies oluşturulmamış, bu yüzden liste boş geliyor. Sizin tenant’ınızda bu politikalar görünüyorsa silinemediklerini bilmek gerekiyor; yalnızca durumlarını (On, Off, Report-only) ve hariç tutulan kullanıcıları değiştirebilirsiniz. Böyle bir durumda her Microsoft-managed policy‘yi açıp Users > Exclude > Users and groups altına CA-Exclude-BreakGlass grubunu ekleyin. Aksi halde bu politikalar ileride On durumuna geçtiğinde break-glass hesaplarını da kapsar.

Adım 4: Kendi Conditional Access Politikalarımızı Oluşturma

Security Defaults’un sağladığı korumayı şimdi kendi politikalarımızla yeniden kuruyoruz. Kurumun adlandırma standardına uyan ve istisnaları belgelenmiş politikalar, Microsoft’un hazır kurallarına göre uzun vadede çok daha kolay yönetiliyor. Lab’ımızda üç temel politika oluşturuyoruz. Her politikayı önce Report-only (Yalnızca rapor) modunda oluşturuyor, etkisini doğruladıktan sonra On (Açık) konumuna alıyoruz.

Üç politikanın oluşturma ekranları büyük ölçüde aynı: Name, Users, Target resources, Conditions, Grant ve Enable policy. Bu yüzden CA001‘i tüm ekranlarıyla adım adım anlatıyor, CA002 ve CA003‘te yalnızca farklı olan ayarları gösteriyoruz.

CA001: Legacy Authentication’ı Engelleme

Legacy authentication, POP, IMAP, SMTP AUTH ve eski Office istemcilerinin kullandığı temel kimlik doğrulama gibi MFA’yı desteklemeyen protokolleri kapsıyor. Bu protokoller açık kaldığı sürece MFA politikalarımız atlatılabilir; parola püskürtme (password spray) saldırılarının büyük kısmı da bu kanallardan geliyor. Security Defaults bu protokolleri zaten engelliyordu; CA001 ile aynı korumayı Conditional Access tarafında yeniden kuruyoruz.

Yeni Politikayı Başlatma

Conditional Access | Overview sayfasındaki Create new policy ya da Policies sayfasındaki New policy ile boş bir politika açıyoruz.

Name alanına CA001-BlockLegacyAuth yazıyoruz. Politika adlarında numara, eylem ve kapsamı içeren bir standart kullanmak, politika sayısı arttığında listeyi okunur tutar ve Sign-in logs incelenirken hangi politikanın ne yaptığını adından anlamayı sağlar. Ardından Assignments altındaki Users bölümünde 0 users and groups selected bağlantısına tıklıyoruz.

Users: Include ve Exclude

Sağda açılan bölümde What does this policy apply to? değeri Users and groups olarak kalıyor. Include sekmesinde üç seçenek var:

• None politikayı kimseye uygulamaz.
• Select users and groups belirli kullanıcı, grup, rol ya da misafir kullanıcıları hedefler.
• All users ise tenant’taki tüm kullanıcıları kapsar.

All users seçiyoruz.

Bu seçimle birlikte portal turuncu bir Don’t lock yourself out! uyarısı gösteriyor: politika tüm kullanıcıları etkileyeceği için önce küçük bir kullanıcı grubunda denenmesini öneriyor. Biz bu riski iki şekilde yönetiyoruz: politikayı Report-only modunda oluşturuyoruz ve break-glass hesaplarını hariç tutuyoruz.

Exclude sekmesine geçiyoruz. Burada Guest or external users, Directory roles ve Users and groups seçenekleri bulunuyor.

Users and groups kutusunu işaretliyoruz.

Açılan Select excluded users and groups panelinde arama kutusuna ca yazıp CA-Exclude-BreakGlass grubunu işaretliyor ve Select ile onaylıyoruz. Panelin başlığında excluded ifadesinin geçtiğine dikkat edin; grubu doğru sekmeye eklediğimizi buradan da teyit edebiliyoruz.

Exclude sekmesinde 1 group ve CA-Exclude-BreakGlass görünüyor; sol taraftaki Users özeti de All users included and specific users excluded olarak değişiyor.

Target Resources

Target resources bölümünde Include sekmesinde şu seçenekler bulunuyor:

• None: Politika hiçbir kaynağa uygulanmaz.
• All internet resources with Global Secure Access: Microsoft Entra Internet Access ile gelen internet trafiğini hedefler. Tenant’ta Global Secure Access dağıtılmadığı için gri görünüyor.
• All agent resources (Preview): Yapay zeka ajanlarının eriştiği kaynakları hedefleyen önizleme seçeneği.
• All resources (formerly ‘All cloud apps’): Entra ID ile kimlik doğrulayan tüm uygulama ve kaynaklar.
• Select resources: Yalnızca seçilen uygulamalar, örneğin sadece Office 365 ya da Azure yönetimi.

All resources seçiyoruz.

Portal bu seçimde Don’t lock yourself out! This policy impacts the Azure portal. uyarısı veriyor, çünkü politika yönetim portallarını da kapsıyor. CA001 yalnızca legacy authentication istemcilerini hedeflediği ve portallar modern authentication kullandığı için bu politika yönetim erişimimizi etkilemez; yine de uyarı her politikada ciddiye alınmalı.

Conditions: Client Apps

Conditions bölümünde 0 conditions selected bağlantısına tıkladığımızda politikanın hangi durumlarda devreye gireceğini belirleyen koşullar listeleniyor:

User risk ve Sign-in risk (Entra ID Protection risk seviyeleri, P2 gerektirir), Insider risk (Microsoft Purview Insider Risk Management), Device platforms (Windows, iOS, Android gibi işletim sistemleri), Locations (Named locations ile tanımlı konumlar), Client apps, Filter for devices ve Authentication flows (device code flow gibi akışlar).

CA001 için yalnızca Client apps koşulunu kullanıyoruz; altındaki Not configured bağlantısına tıklıyoruz.

Client apps panelinde Configure değerini Yes yapıyoruz. Panel istemcileri iki başlık altında gruplandırıyor:

• Modern authentication clients: Browser ile Mobile apps and desktop clients. Bunlar MFA destekleyen modern istemcilerdir ve CA001‘de işaretlenmemelidir.
• Legacy authentication clients: Exchange ActiveSync clients ile Other clients. Other clients; POP, IMAP, SMTP AUTH, MAPI over HTTP’nin temel kimlik doğrulama kullanan kullanımları ve eski Office sürümleri gibi protokolleri kapsar.

Yalnızca Exchange ActiveSync clients ve Other clients kutularını işaretli bırakıp Done ile paneli kapatıyoruz.

Conditions özeti 1 condition selected, Client apps değeri 2 included olarak görünüyor.

Grant: Block Access

Access controls altındaki Grant bölümünde 0 controls selected bağlantısına tıklıyoruz. Grant paneli iki ana seçenek sunuyor: Block access erişimi tamamen engeller, Grant access ise erişime izin verir ama altındaki koşulları şart koşar.

Grant access altındaki kontroller şunlar:

• Require multifactor authentication: Kullanıcıdan MFA ister. CA002‘de kullanacağız.
• Require authentication strength: Hangi MFA yöntemlerinin kabul edileceğini belirler, örneğin yalnızca phishing-resistant yöntemler. CA003‘te kullanacağız.
• Require device to be marked as compliant: Cihazın Intune uyumluluk politikalarını karşılamasını ister.
• Require Microsoft Entra hybrid joined device: Cihazın hem on-premises AD’ye hem Entra ID’ye kayıtlı olmasını ister.
• Require approved client app ve Require app protection policy: Mobil cihazlarda onaylı uygulama ya da Intune uygulama koruma politikası şartı koyar.
• Require password change ve Require risk remediation: Riskli kullanıcılar için Entra ID Protection ile kullanılan kontrollerdir.

Birden fazla kontrol seçildiğinde For multiple controls altında hepsinin mi Require all the selected controls yoksa birinin mi Require one of the selected controls yeterli olacağı belirlenir.

CA001 için Block access seçip Select ile onaylıyoruz. Legacy authentication istemcileri MFA desteklemediğinden bu istemciler için MFA iste demenin anlamı yok; tek doğru kontrol engellemek.

Enable Policy ve Create

Özette Users, Target resources, Conditions ve Grant değerlerini son kez kontrol ediyoruz. Enable policy bölümünü Report-only olarak kalıyor. Create‘e bastığımızda portal ikinci bir Don’t lock yourself out! uyarısı gösterebiliyor ve oturum açmış yönetici hesabının politikadan etkileneceğini hatırlatıp iki seçenek sunuyor:

• Exclude current user, [email protected], from this policy: Oturum açmış yönetici hesabını politikanın Exclude listesine ekler.
• I understand that my account will be impacted by this policy. Proceed anyway: Hesabı istisna eklemeden politikayı kaydeder.

Bu politika için ikinci seçeneği tercih ediyoruz. Yönetici hesabımız modern authentication kullandığı için CA001‘den etkilenmiyor. Ayrıca istisnaları yalnızca CA-Exclude-BreakGlass grubu üzerinden, belgelenmiş şekilde yönetmek istiyoruz. Her politikaya tek tek eklenen kullanıcı istisnaları zamanla kimsenin hatırlamadığı açıklara dönüşür.

I understand that my account will be impacted by this policy. Proceed anyway seçeneğini işaretleyip Create ile politikayı oluşturuyoruz.

Politika kaydedildiğinde sağ üstte Successfully created ‘CA001-BlockLegacyAuth‘ bildirimi görünüyor ve portal Conditional Access | Overview sayfasına dönüyor. CA001 artık Policies listesinde Report-only durumunda yer alıyor.

CA002: Tüm Kullanıcılar İçin MFA

CA001‘deki adımları CA002-RequireMFA-AllUsers adıyla tekrarlıyoruz: Users > Include altında All users, Exclude altında CA-Exclude-BreakGlass, Target resources altında All resources. Bu politikada Conditions bölümüne dokunmuyoruz; MFA tüm istemci türleri için istenecek.

Farklı olan tek adım Grant bölümü: Grant access seçip Require multifactor authentication kutusunu işaretliyor ve Select ile onaylıyoruz. Enable policy bölümünü Report-only bırakıyoruz; Create sırasında Don’t lock yourself out uyarısı yine çıkarsa CA001‘de olduğu gibi I understand that my account will be impacted by this policy. Proceed anyway seçeneğiyle devam ediyoruz.

Require multifactor authentication işaretlendiğinde panel iki bilgi notu gösteriyor. İlki, bunun yerine daha yeni olan Require authentication strength kontrolünün denenmesini öneriyor. İkincisi, iki kontrolün aynı politikada birlikte kullanılamayacağını hatırlatıyor; bu yüzden Require authentication strength kutusu gri görünüyor. Require multifactor authentication, kullanıcının kayıtlı herhangi bir MFA yöntemini kabul eder ve yerleşik Multifactor authentication strength ile aynı sonucu verir. Tüm kullanıcılar için bu yeterli; yöntemleri daraltmak istediğimiz yönetici hesapları için CA003‘te authentication strength kullanacağız.

Select ile paneli kapattığımızda Grant özeti 1 control selected olarak görünüyor. Create sırasında çıkan Don’t lock yourself out uyarısında yine I understand that my account will be impacted by this policy. Proceed anyway seçeneğiyle devam ediyoruz.

Politika kaydedildiğinde Successfully created ‘CA002-RequireMFA-AllUsers’ bildirimi görünüyor ve portal Policies sayfasına dönüyor. Bildirim anında liste henüz yenilenmemiş olabilir ve yalnızca CA001 görünebilir; Refresh ile CA002 de listeye gelir.

CA003: Yöneticiler İçin Phishing-resistant MFA

Yönetici hesapları saldırganların birincil hedefi olduğu için bu hesaplardan standart MFA’nın ötesinde, kimlik avına dayanıklı bir doğrulama istiyoruz. Yeni bir politika oluşturup Name alanına CA003-RequirePhishingResistantMFA-Admins yazıyoruz.

Bu politikada kapsam tüm kullanıcılar değil, yönetici rolleri. Users > Include altında Select users and groups seçiyoruz. Seçim yapılana kadar sol tarafta Select users and groups must be configured hatası görünür; alt seçeneklerden en az birinin işaretlenmesi gerekiyor. Directory roles kutusunu işaretliyoruz.

Directory roles altında açılan listeden şu sekiz rolü seçiyoruz: Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, User Administrator ve Hybrid Identity Administrator. Liste 8 selected olarak görünüyor ve hata kayboluyor. Rol tabanlı hedeflemenin avantajı, bir kullanıcıya bu rollerden biri atandığı anda politikanın otomatik olarak devreye girmesi; ayrıca bir grup yönetmeye gerek kalmıyor.

Break-glass hesapları Global Administrator rolüne sahip olduğu için bu politikanın kapsamına giriyor. Bu yüzden Exclude sekmesinde Users and groups altında yine CA-Exclude-BreakGlass grubunu ekliyoruz. Users özeti Specific users included and specific users excluded olarak değişiyor.

Target resources bölümünde CA001 ve CA002‘de olduğu gibi All resources seçiyoruz; Conditions bölümüne dokunmuyoruz.

Grant bölümünde Grant access seçip Require authentication strength kutusunu işaretliyoruz. Bu kutu işaretlendiğinde Require multifactor authentication gri hale geliyor; CA002‘de gördüğümüz gibi iki kontrol birlikte kullanılamıyor. Kutunun altındaki açılır listede Microsoft’un yerleşik üç authentication strength tanımı bulunuyor:

• Multifactor authentication: Güçlü kimlik doğrulamayı karşılayan tüm yöntem kombinasyonları, örneğin parola ve SMS. Require multifactor authentication ile aynı sonucu verir.
• Passwordless MFA: Parola kullanmayan yöntemler, örneğin Microsoft Authenticator ile parolasız oturum açma.
• Phishing-resistant MFA: Kimlik avına dayanıklı parolasız yöntemler; FIDO2 güvenlik anahtarı, passkey, Windows Hello for Business ve sertifika tabanlı kimlik doğrulama.

Authentication strengths sayfasından kendi tanımlarınızı da oluşturabilirsiniz, ancak çoğu senaryo için yerleşik üç tanım yeterli.

Listeden Phishing-resistant MFA seçiyoruz. Panel, harici (B2B) kullanıcılar için kimlik avına dayanıklı doğrulama isteniyorsa cross-tenant access ayarlarında diğer Entra tenant’larından gelen MFA iddialarının kabul edilmesi gerektiğini hatırlatıyor. Bizim politikamız yalnızca kendi tenant’ımızdaki yönetici rollerini hedeflediği için bu not bizi etkilemiyor. Select ile onaylıyoruz.

Özette Users bölümü Specific users included and specific users excluded, Target resources bölümü All resources, Grant bölümü 1 control selected ve Enable policy bölümü Report-only olarak görünüyor. Create ile politikayı kaydediyoruz.

Politika kaydedildiğinde Successfully created ‘CA003-RequirePhishingResistantMFA-Admins’ bildirimi görünüyor. CA002‘de olduğu gibi liste bildirim anında henüz güncellenmemiş olabilir.

Refresh ile listeyi yenilediğimizde User created policies kartında 3 politika görünüyor. CA001, CA002 ve CA003‘ün üçü de Created by sütununda USER, State sütununda Report-only olarak listeleniyor. Microsoft-managed policies kartı ise 0 olarak kalıyor. Artık politikalarımız hazır; hiçbir kullanıcıyı etkilemeden ne yapacaklarını What If ve sign-in logları ile doğrulayabiliriz.

Adım 5: What If ile Politikaları Test Etme

Politikaları açmadan önce hangi senaryoda hangi politikanın devreye gireceğini What If aracıyla simüle ediyoruz. What If gerçek bir oturum açma gerçekleştirmez; seçtiğimiz kullanıcı, uygulama ve koşullara göre politikaları değerlendirip hangisinin uygulanacağını ve hangisinin neden uygulanmayacağını listeler. Report-only durumundaki politikaları da değerlendirdiği için politikaları açmadan test etmenin en hızlı yolu.

What If Aracını Açma

Conditional Access | Policies sayfasının üst menüsündeki What if düğmesine tıklıyoruz.

What if sayfası üç bölümden oluşuyor:

• Identity: Testin kimin adına yapılacağı. Select identity type alanında Users (kullanıcı) ya da Workload identities (servis hesabı) seçilir.
• Target resource: Kullanıcının erişmeye çalıştığı uygulama, kullanıcı eylemi ya da authentication context.
• Sign-in conditions: Device platform, Client app, Authentication flow, risk seviyeleri, IP adresi, ülke ve cihaz filtresi gibi oturum açma koşulları. Device platform ve Client app zorunlu, diğerleri isteğe bağlı.

Select identity type değeri Users olarak kalıyor. User altındaki Edit user bağlantısına tıklıyoruz.

Test Kullanıcısını Seçme

Users panelinde arama kutusuna nihat yazıyor, Bölüm 2’de on-premises AD’den senkronize ettiğimiz Nihat Cubuk ([email protected]) kullanıcısını işaretleyip Select ile onaylıyoruz. Bu kullanıcı herhangi bir yönetici rolüne sahip olmayan standart bir hibrit kullanıcı, yani CA001 ve CA002‘nin kapsamında, CA003‘ün kapsamı dışında.

Hedef Uygulamayı Seçme

Target resource bölümünde Select target type değeri Cloud apps kalıyor ve Select cloud app bağlantısına tıklıyoruz. Politikalarımızda kullandığımız All resources seçeneği What If aracında bulunmuyor; burada tek tek uygulama seçiliyor. Politikalarımız tüm kaynakları hedeflediği için hangi uygulamayı seçersek seçelim kapsama giriyor.

Arama kutusuna office yazıp Office 365 Exchange Online uygulamasını seçiyoruz. Exchange Online’ın uygulama kimliği 00000002-0000-0ff1-ce00-000000000000 her Microsoft 365 tenant’ında aynıdır. Hem kullanıcının en sık eriştiği uygulama olduğu için hem de legacy authentication protokolleri (Exchange ActiveSync, POP, IMAP, SMTP AUTH) doğrudan Exchange Online’a bağlandığı için bu test için en anlamlı hedef.

İpucu: Arama kutusuna yalnızca exchange ya da teams yazarsanız listede ExchangeRevocationSync ya da Teams NRT DLP Service gibi arka planda çalışan servis uygulamaları çıkabilir. Bunlar kullanıcıların oturum açtığı uygulamalar değildir; test için Office 365 Exchange Online, Office 365 SharePoint Online ya da Office 365 gibi kullanıcıya dönük uygulamaları seçin.

Oturum Açma Koşulları ve Değerlendirme

Sign-in conditions altında Device platform için Windows, Client app için Browser seçiyoruz. Diğer alanları boş bırakıyoruz. Bu senaryo, Nihat Cubuk ([email protected]) kullanıcısının Windows bir bilgisayarda tarayıcıdan Outlook web’e girmesini simüle ediyor. What if düğmesine basıyoruz.

Evaluation result bölümünde sonuç iki sekmede gösteriliyor. Üstteki Classic policies are not evaluated by this tool. notu, eski klasik politikaların What If tarafından değerlendirilmediğini hatırlatıyor; bizim tenant’ımızda klasik politika olmadığı için bu not bizi etkilemiyor.

Policies that will apply sekmesinde 1 policy found görünüyor: CA002-RequireMFA-AllUsers, Grant controls sütununda Require multifactor authentication ve State sütununda Report-only. Yani politika açık olsaydı Nihat Cubuk ([email protected]) kullanıcısı tarayıcıdan oturum açarken MFA ile karşılaşacaktı.

Policies that will not apply sekmesinde ise diğer iki politika ve uygulanmama gerekçeleri listeleniyor:

• CA001-BlockLegacyAuth, Client app: Politika yalnızca Exchange ActiveSync ve Other clients istemcilerini hedefliyor. Tarayıcı modern authentication kullanan bir istemci olduğu için CA001 devreye girmiyor. Bu, CA001‘in modern istemcileri etkilemeden yalnızca legacy trafiği hedeflediğinin kanıtı.
• CA003-RequirePhishingResistantMFA-Admins, Users and groups: Nihat Cubuk ([email protected]) kullanıcısı politikada seçtiğimiz yönetici rollerinden hiçbirine sahip değil.

Aynı testi Client app değerini Exchange ActiveSync clients ya da Other clients yaparak tekrarladığımızda CA001‘in Policies that will apply sekmesine geçtiğini görürüz. Böylece legacy authentication engelinin doğru istemcileri yakaladığını da doğrulamış oluruz.

Break-glass Hesabıyla Test

Son olarak aynı testi break-glass hesabıyla tekrarlıyoruz. Formdaki diğer değerleri (Office 365 Exchange Online, Windows, Browser) değiştirmeden Edit user ile Users panelini açıyor, arama kutusuna bg yazıp [email protected] hesabını seçiyoruz.

Bu hesap Global Administrator rolüne sahip olduğu için normalde CA002 ve CA003‘ün kapsamına girerdi. What if düğmesine bastığımızda Policies that will apply sekmesinde 0 policies found ve No policies görünüyor; yani bg-admin01 ile yapılan bir oturum açmaya hiçbir politikamız uygulanmıyor.

Policies that will not apply sekmesinde üç politika da listeleniyor ve üçünün de gerekçesi Users and groups. What If burada ayrıntıya girmiyor, ancak nihat.cubuk testinden farkı açık: Nihat Cubuk ([email protected]) kullanıcısına CA002 uygulanıyordu, bg-admin01‘de ise All users kapsamında olmasına rağmen uygulanmıyor. Bunun tek nedeni, üç politikada da Exclude sekmesine eklediğimiz CA-Exclude-BreakGlass grubu. Has filter? sütunundaki No değeri, politikalarda cihaz filtresi kullanılmadığını gösteriyor.

Bu sonuç, bir politika hatası tüm yöneticileri dışarıda bıraksa bile break-glass hesaplarıyla tenant’a girebileceğimizi doğruluyor. İleride yeni bir politika eklediğinizde ya da mevcut bir politikayı değiştirdiğinizde bu testi tekrarlamayı alışkanlık haline getirin.

Report-only modundaki politikaların gerçek oturum açmalardaki etkisini de Entra ID > Sign-in logs altında bir oturum kaydına tıklayıp Report-only sekmesinden görebiliyoruz. Burada politika Report-only: Success ya da Report-only: Failure olarak işaretleniyor; yani politika açık olsaydı ne olacağını hiçbir kullanıcıyı etkilemeden görmüş oluyoruz.

Adım 6: Politikaları Etkinleştirme

What If sonuçları ve report-only kayıtları beklediğimiz gibi olduğunda politikaları On konumuna alıyoruz. Önce CA001 ve CA002‘yi açıyoruz. CA003‘ü ise politika kapsamındaki yönetici hesapları passkey, FIDO2 anahtarı ya da Windows Hello for Business gibi kimlik avına dayanıklı bir yöntem kaydettikten sonra açacağız; lab’da bu aşamada Report-only olarak bırakıyoruz.

Policies listesinde CA001-BlockLegacyAuth politikasına tıkladığımızda önce Policy details paneli açılıyor.

Bu panel politikanın özetini gösteriyor: State bölümü Report-only (policy is evaluated but not enforced), Users, agent or workload identites bölümü All users, Excluded identities bölümü 0 users, 1 group, 0 roles, Included resources bölümü All resources, Client apps bölümü Exchange active sync clients, Other clients ve Requirements for access bölümü Block access.

Panelin üst menüsünde View or Edit, Duplicate, Download JSON ve Delete seçenekleri bulunuyor. Download JSON, politikayı yedeklemek ya da Upload policy file ile başka bir tenant’a taşımak için kullanışlı. Policy impact sekmesi ise Report-only süresince politikanın gerçek oturum açmalarda nasıl sonuç vereceğini özetliyor.

Düzenleme için View or Edit‘e tıklıyoruz.

Politika düzenleme ekranında Enable policy değerini On yapıyoruz. Kaydetmeden önce portal, politika oluştururken gördüğümüz Don’t lock yourself out! uyarısını tekrar gösteriyor. Yine I understand that my account will be impacted by this policy. Proceed anyway seçeneğini işaretleyip Save ile kaydediyoruz.

Aynı adımları CA002-RequireMFA-AllUsers için de tekrarlıyoruz.

Refresh ile listeyi yenilediğimizde CA001-BlockLegacyAuth ve CA002-RequireMFA-AllUsers polikitaları On, CA003-RequirePhishingResistantMFA-Admins polikitası ise Report-only olarak görünüyor. Artık legacy authentication engelleniyor ve break-glass hesapları dışındaki tüm kullanıcılar için MFA zorunlu. Security Defaults’un sağladığı iki temel korumayı Conditional Access ile yeniden kurmuş olduk.

Tenant’ınızda Microsoft-managed policies de varsa, kendi politikalarınız aynı korumayı sağladığında bunları kapatmak mümkün. Ancak bu politikalar Microsoft’un yeni tehditlere göre güncellediği bir koruma katmanı olduğundan, break-glass istisnasını ekledikten sonra açık bırakmak da makul bir tercih.

Adım 7: Senkronize Kullanıcıyla İlk Oturum Açma

Politikalar açıldıktan sonra senkronize kullanıcılarımızdan biriyle, örneğin Nihat Cubuk ile, bir tarayıcıdan myapplications.microsoft.com adresine oturum açıyoruz. Kullanıcı adı olarak on-premises UPN’i [email protected], parola olarak da on-premises Active Directory parolasını giriyoruz. Password Hash Synchronization sayesinde parola kabul ediliyor. Kullanıcının henüz kayıtlı bir MFA yöntemi olmadığı için CA002 politikası devreye giriyor ve Microsoft kullanıcıyı Let’s keep your account secure ekranına yönlendiriyor. Ekrandaki We’ll help you set up another way to verify it’s you. ifadesi, parolaya ek olarak ikinci bir doğrulama yöntemi kaydedileceğini anlatıyor. Eski arayüzde aynı adım More information required başlığıyla görünür.

Bu ekran iki şeyi birlikte doğruluyor. Birincisi, on-premises AD parolası Entra ID’de geçerli; yani Bölüm 2’de kurduğumuz Password Hash Synchronization çalışıyor. İkincisi, CA002 politikası On konumunda ve kullanıcıya MFA zorunluluğunu uyguluyor. Next ile Microsoft Authenticator kurulumuna geçiyoruz; kullanıcı telefonuna uygulamayı yükleyip ekrandaki QR kodu okutarak kaydı tamamlıyor.

Bu oturum açma henüz domain’e bağlı olmayan bir makineden yapıldığı için kullanıcı parolasını elle giriyor. Bölüm 4’te aynı kullanıcıyla W11CL01 üzerinden oturum açtığımızda parola sorulmadığını, yalnızca MFA istendiğini göreceğiz.

Özet ve Sonraki Bölüm

Bu bölümde Security Defaults’tan Conditional Access’e geçtik. İki break-glass hesabı oluşturup bunları tek bir istisna grubunda topladık, Security Defaults’u kapatıp Policies sayfasını ve Microsoft-managed policies’in nasıl ele alınacağını inceledik, ardından legacy authentication engelleme, tüm kullanıcılar için MFA ve yöneticiler için phishing-resistant MFA politikalarımızı report-only modunda oluşturup What If ile test ettik. Ardından CA001 ile CA002‘yi etkinleştirdik, CA003‘ü ise yönetici hesaplarına kimlik avına dayanıklı yöntem kaydı yapılana kadar Report-only bıraktık. Güncel Entra Connect sürümünün uygulama kimliğiyle çalışması sayesinde senkronizasyon için ayrı bir istisna tanımlamamıza gerek kalmadı.

Bölüm 4’te Seamless SSO için grup ilkesini yapılandıracak, W11CL01 üzerinden uçtan uca testi yapacak ve AZUREADSSOACC hesabını AES ile sıkılaştıracağız.