Kimlik & Bulut Güvenliği Mimarisi

Microsoft Entra ID ve Hibrit Kimlik Güvenliği: Sıfır Güven (Zero Trust) ve Conditional Access Mimarisi

On-Premises Active Directory'den buluta uzanan hibrit yapılarda kimlik sınırlarını korumak, oltalama dirençli MFA uygulamak ve kurumsal erişim politikalarını uçtan uca tasarlamak.

Modern kurumsal BT altyapılarında geleneksel "ağ çevresi" (network perimeter) kavramı yerini tamamen kimlik merkezli güvenliğe (Identity as the Primary Security Perimeter) bırakmıştır. Kullanıcıların şirket dışından, mobil cihazlardan ve çoklu bulut ortamlarından kurumsal kaynaklara eriştiği günümüz mimarisinde, bir kurumun güvenlik duruşunu belirleyen en kritik katman Microsoft Entra ID (eski adıyla Azure AD) ve şirket içi Active Directory (AD DS) arasındaki hibrit kimlik köprüsüdür.

🛡️ Sıfır Güven (Zero Trust) Prensibi: "Asla varsayılan olarak güvenme, her zaman doğrula." İstek şirket içi yerel ağdan (LAN) gelse bile; kullanıcının kimliği, cihazın uyumluluk durumu, oturum riski ve erişilmek istenen uygulamanın hassasiyeti gerçek zamanlı olarak doğrulanmalıdır.

Bu rehberde, çoklu domain/forest barındıran kurumsal bir Active Directory yapısından Microsoft Entra ID'ye uzanan hibrit kimlik mimarisini nasıl güvenli hale getireceğimizi, Conditional Access (Koşullu Erişim) karar motorunu nasıl yapılandıracağımızı ve ayrıcalıklı hesapları PIM (Privileged Identity Management) ile nasıl koruyacağımızı adım adım inceleyeceğiz.

Zero Trust Kimlik Doğrulama ve Karar Mimarisi

1. Sinyal Toplama (Signals)

Kullanıcı rolü, cihaz sağlığı (Intune Compliant / Hybrid Joined), IP konumu, istemci uygulaması ve gerçek zamanlı oturum riski (Entra ID Protection).

2. Karar Motoru (Conditional Access)

Sinyalleri kurumsal politikalarla değerlendirir: Erişime İzin Ver (Grant), Ek Doğrulama İste (MFA / FIDO2) veya Erişimi Engelle (Block).

3. Uygulama & Oturum Kontrolü

Microsoft 365, Azure, SaaS uygulamaları ve Entra Private Access ile korunan şirket içi kaynaklara kısıtlı veya tam erişim sağlanır.

1

Hibrit Kimlik Altyapısı ve Senkronizasyon Güvenliği

Active Directory'den Entra ID'ye Güvenli Köprü Kurmak

Kurumsal yapıların büyük çoğunluğu şirket içi Active Directory dizinini Microsoft Entra Connect veya Entra Cloud Sync aracılığıyla bulutla senkronize eder. Ancak bu köprü doğru izole edilmezse, şirket içinde ele geçirilen bir yetkili hesap bulut ortamını; bulutta ele geçirilen bir hesap ise şirket içi ortamı tehlikeye atabilir.

Hibrit kimlik mimarisini tasarlarken dikkat edilmesi gereken üç temel yapı taşı vardır:

• Kimlik Doğrulama Yöntemi Seçimi: Karmaşıklığı ve altyapı bağımlılığını azaltmak için Password Hash Synchronization (PHS), en yüksek erişilebilirliği sağlar ve Leaked Credentials (Sızdırılmış Kimlik Bilgileri) tespiti için Entra ID Protection ile doğrudan entegre çalışır.
• Tier 0 (Katman 0) İzolasyonu: Entra Connect sunucusu, tıpkı bir Domain Controller gibi Tier 0 varlığı olarak kabul edilmeli; üzerinde yalnızca senkronizasyon servisleri çalışmalı ve erişimleri sıkılaştırılmalıdır.
• Ayrıcalıklı Hesapların Ayrıştırılması (Cloud-Only Admins): Şirket içi Domain Admins veya Enterprise Admins gruplarındaki kullanıcılar asla Entra ID'ye Global Admin olarak senkronize edilmemelidir. Bulut yönetimi için tamamen ayrı, onmicrosoft.com uzantılı ve yalnızca bulutta var olan (Cloud-Only) yönetici hesapları kullanılmalıdır.

📌 Mimari Kontrol Listesi: Hibrit Dizin Sıkılaştırma

• Seamless SSO kullanılıyorsa AZUREADSSOACC bilgisayar hesabının Kerberos şifreleme anahtarlarını düzenli periyotlarla (en az 30 günde bir) döndürün (rollover).
• Çoklu child domain barındıran forest yapılarında, yalnızca aktif ve gerekli Organizational Unit (OU) birimlerini kapsam içine (OU Filtering) alın.
• Soft Match (SMTP Matching) özelliğini üretim ortamında suistimalleri önlemek adına senkronizasyon tamamlandıktan sonra devre dışı bırakın (Disable-SoftMatchOnUpn).

2

Conditional Access (Koşullu Erişim) Mimari Tasarımı

Sıfır Güven İlkelerini Politikaya Dönüştürmek

Conditional Access, Microsoft Entra ID'nin Sıfır Güven politikalarını yürüten kalbidir. Başarılı bir Conditional Access mimarisi, rastgele oluşturulmuş onlarca kuraldan değil; standart bir isimlendirme standardına (Naming Convention) sahip, birbiriyle çakışmayan katmanlı politikalardan oluşur.

Politika Kodu & Adı	Hedef Kitle & Koşul	Uygulanan Kontrol (Grant / Session)
CA001 - Block Legacy Auth	Tüm Kullanıcılar | Exchange ActiveSync & Diğer Eski İstemciler	Block Access (Modern kimlik doğrulamayı desteklemeyen protokolleri engeller)
CA002 - Require Phishing-Resistant MFA for Admins	Tüm Yönetici Rolleri (Directory Roles) | Tüm Bulut Uygulamaları	Require Authentication Strength: Phishing-resistant MFA (FIDO2 / Windows Hello)
CA003 - Require Compliant Device for Corporate Data	Tüm Kullanıcılar | Office 365 & Kritik Kurumsal Uygulamalar	Require Device to be Marked as Compliant veya Hybrid Entra Joined
CA004 - Block High Risk Sign-ins	Tüm Kullanıcılar | Sign-in Risk = High (Entra ID Protection)	Block Access veya Güvenli Parola Sıfırlama + MFA

🚨 Hayati Kural — Acil Durum (Break-Glass) Hesapları: Herhangi bir yanlış Conditional Access yapılandırmasında veya bölgesel MFA servis kesintisinde tenant'a kilitlenmemek için en az 2 adet Cloud-Only Break-Glass Global Admin hesabı oluşturulmalı, bu hesaplar tüm Conditional Access politikalarından hariç tutulmalı (Exclude), çok uzun FIDO2 donanım anahtarlarıyla korunmalı ve kullanım anında Microsoft Sentinel / Azure Monitor üzerinden anında kritik alarm üretecek şekilde izlenmelidir.

3

Oltalama Dirençli MFA (Phishing-Resistant MFA) Geçişi

SMS ve Push Bildirimlerinden FIDO2 ve Passkey Mimarisine

Geleneksel SMS doğrulaması, sesli arama ve hatta standart uygulama bildirimleri (Push Notification); AiTM (Adversary-in-the-Middle / Ortadaki Saldırgan) ters vekil sunucu (reverse proxy) saldırılarına ve MFA Fatigue (MFA Yorgunluğu) tekniklerine karşı savunmasızdır. Saldırganlar sahte bir giriş sayfası üzerinden oturum çerezini (session token) çalabildiği için standart MFA tek başına yeterli değildir.

Kurumsal güvenliği bir üst seviyeye taşımak için Entra ID içindeki Authentication Strengths (Kimlik Doğrulama Güçleri) özelliği kullanılmalı ve şu üç yöntem standart haline getirilmelidir:

• FIDO2 Güvenlik Anahtarları ve Passkey (Microsoft Authenticator): Kriptografik olarak alan adına (origin-bound) bağlı olduğu için sahte sitelerde (AiTM) çalışmaz.
• Windows Hello for Business (WHfB): Cihaz üzerindeki TPM 2.0 çipini kullanarak biyometrik veya PIN doğrulaması sağlar.
• Certificate-Based Authentication (CBA): Özellikle kurumsal PKI altyapısına sahip organizasyonlarda sertifika tabanlı güçlü doğrulama sunar.

4

Privileged Identity Management (PIM) ve Graph PowerShell Denetimi

Sıfır Kalıcı Yetki (Zero Standing Privileges) ve Otomasyon

Sıfır Güven mimarisinin en önemli ayaklarından biri JIT (Just-In-Time / Tam Zamanında) ve JEA (Just-Enough-Administration / Yeterli Düzeyde Yönetim) ilkeleridir. Break-Glass hesapları hariç hiçbir yönetici hesabında 7/24 kalıcı (Permanent Active) Global Administrator, Exchange Administrator veya Security Administrator yetkisi bulunmamalıdır.

Microsoft Entra PIM ile tüm yöneticiler Eligible (Uygun) statüsünde tanımlanır; yetkiye ihtiyaç duyduklarında gerekçe yazarak, MFA/FIDO2 doğrulamasından geçerek ve gerekiyorsa onay (Approval) mekanizmasıyla maksimum 4-8 saatliğine yetkilerini aktifleştirirler.

Mevcut Entra ID ortamınızdaki tüm Conditional Access politikalarını ve durumlarını Microsoft Graph PowerShell SDK kullanarak saniyeler içinde denetlemek ve raporlamak için aşağıdaki scripti kullanabilirsiniz:

# Microsoft Graph PowerShell Modülü ile Bağlantı Kurma Connect-MgGraph -Scopes "Policy.Read.All", "Directory.Read.All" # Tüm Conditional Access Politikalarını Çekme ve Durum Raporu Oluşturma $CAPolicies = Get-MgIdentityConditionalAccessPolicy -All $Report = foreach ($Policy in $CAPolicies) { [PSCustomObject]@{ PolicyName = $Policy.DisplayName State = $Policy.State # enabled, disabled, enabledForReportingButNotEnforced CreatedDateTime = $Policy.CreatedDateTime ModifiedDateTime = $Policy.ModifiedDateTime IncludeUsers = ($Policy.Conditions.Users.IncludeUsers -join ", ") ExcludeUsersCount= $Policy.Conditions.Users.ExcludeUsers.Count GrantControls = ($Policy.GrantControls.BuiltInControls -join ", ") } } # Raporu Konsolda Tablo Olarak Gösterme ve CSV Olarak Dışa Aktarma $Report | Sort-Object State, PolicyName | Format-Table -AutoSize $Report | Export-Csv -Path "C:\Reports\EntraID_CA_Audit_Report.csv" -NoTypeInformation -Encoding UTF8

💡 Dağıtım İpucu: Report-Only (Yalnızca Raporlama) Modu

• Yeni bir Conditional Access politikasını doğrudan On (Açık) konumda devreye almak yerine, önce Report-only modunda en az 7 gün çalıştırın.
• Entra ID Sign-in Logs (Oturum Açma Günlükleri) üzerinden politikanın mevcut kullanıcıları ve servis hesaplarını nasıl etkileyeceğini analiz ettikten sonra canlıya geçin.

Mimari Özet: Güvenli Bir Hibrit Kimlik İçin 5 Altın Adım

Microsoft Entra ID ve Active Directory hibrit yapısını Sıfır Güven (Zero Trust) standartlarına taşımak tek seferlik bir ayar değil, yaşayan bir mimari süreçtir. Kurumsal ortamınızda bugün hemen uygulayabileceğiniz en kritik 5 adım:

1. Eski kimlik doğrulama protokollerini (Legacy Authentication) istisnasız olarak kapatın.
2. Yönetici hesaplarını şirket içi AD'den ayırın (Cloud-Only) ve tamamını Phishing-Resistant MFA (FIDO2 / Passkey) kapsamına alın.
3. Kalıcı yönetici yetkilerini kaldırarak Entra PIM ile süreli ve onaylı yetkilendirmeye geçin.
4. En az iki adet Break-Glass acil durum hesabı oluşturup donanım anahtarlarıyla güvenceye alın ve log alarmlarını bağlayın.
5. Kullanıcıların kendi cihazlarından (BYOD) kurumsal verilere erişimini Intune cihaz uyumluluğu (Compliant Device) ve uygulama koruma politikaları (MAM) şartına bağlayın.