Bir çalışanın Microsoft 365 hesabına giriş yaparken kullanıcı adını ve parolasını doğru girmesi, o an erişmek istediği şirket kaynaklarına otomatik olarak ulaşabilmesi gerektiği anlamına gelir mi? Geleneksel güvenlik yaklaşımlarına göre cevap genellikle “evet”tir. Ancak günümüzün dağıtık, bulut tabanlı ve hibrit çalışma ortamlarında doğru parola, güvenliğin yalnızca başlangıç noktasıdır.
Şirketinizin finansal verilerine, müşteri sözleşmelerine veya iç yazışmalarına erişmek isteyen bu kullanıcının kimliği ele geçirilmiş olabilir. Kullanıcı gerçekten o kişi olsa bile, bağlantı kurduğu cihaz şirketinizin güvenlik politikalarına uymayan, güncellemeleri eksik veya zararlı yazılım barındıran kişisel bir cihaz olabilir. Belki de kullanıcının o an bulunduğu konum şüphelidir veya erişmek istediği kaynağa o günkü iş tanımı gereği aslında ihtiyacı yoktur.
Tüm bu değişkenler, güvenliğin yalnızca “ağ sınırından içeri girmeyi başaran herkese güvenme” mantığından çıkarak her bir erişim talebinin anlık ve bağlamsal olarak değerlendirilmesi gerektiği gerçeğini ortaya çıkarır. İşte Microsoft 365 Zero Trust yaklaşımının temelinde bu sürekli değerlendirme ve doğrulama ihtiyacı yatar. Zero Trust, tek bir güvenlik yazılımı satın alıp kurarak elde edilebilecek bir özellik değildir. Kimlik doğrulamasından cihazın sağlık durumuna, kullanıcının bulunduğu konumdan talep ettiği yetkiye kadar her adımın sürekli sorgulandığı bir mimari ve felsefedir.
Bu rehberde, Zero Trust (Sıfır Güven) yaklaşımının ne olduğunu, geleneksel güvenlik modellerinden neden ayrıldığını ve Microsoft 365 ekosisteminde—özellikle Microsoft Entra ID, Conditional Access, Microsoft Intune ve Microsoft Defender bileşenleriyle—bu mimarinin gerçek işletme senaryolarında nasıl inşa edilebileceğini inceleyeceğiz.
Zero Trust Nedir?
Zero Trust, en temel çevirisiyle “Sıfır Güven” anlamına gelse de, aslında güvenin tamamen yok edilmesi değil, güvenin hiçbir zaman varsayılan (default) olarak kabul edilmemesi esasına dayanır.
Zero Trust’ın temel mantığı
Zero Trust mimarisinin temel sloganı “Asla güvenme, daima doğrula” (Never Trust, Always Verify) şeklindedir. Bu mantık, bir kaynağa (bir SharePoint klasörü, bir e-posta kutusu veya bir SaaS uygulaması) erişmek isteyen kişi veya cihazın, sistemin neresinde bulunduğundan bağımsız olarak sürekli doğrulanmasını gerektirir.
Kullanıcı şirket ağı içerisindeyken otomatik olarak güvenilir kabul edilmemelidir çünkü günümüzde ağın içi ve dışı arasındaki sınır bulanıklaşmıştır. Ayrıca, bir saldırgan çeşitli yöntemlerle (örneğin fiziksel olarak ofise sızarak veya içerideki bir cihazı ele geçirerek) ağın içine zaten dahil olmuş olabilir. Kullanıcı adı ve parola tek başına yeterli değildir çünkü kimlik bilgileri oltalama (phishing) veya veri sızıntıları yoluyla kolayca çalınabilmektedir.
Cihazın durumu kritiktir çünkü tamamen yetkili bir kullanıcının doğru kimlik bilgileriyle bile olsa zafiyet barındıran, işletim sistemi güncel olmayan veya üzerinde zararlı yazılım (malware) çalışan bir cihazdan şirket verilerine ulaşması verinin çalınması veya şifrelenmesi (ransomware) riskini doğurur. Tüm bu nedenlerle erişim statik bir hak değil, sürekli olarak değerlendirilen dinamik bir karar olmalıdır.
Geleneksel çevre güvenliği ile Zero Trust arasındaki fark
Geleneksel ağ güvenliği genellikle bir kale ve hendek (castle-and-moat) modeline benzetilir. Bu yaklaşımda:
İnternet → Güvenlik Duvarı (Firewall) → Kurumsal Ağ → Güvenilir İç Ağ
şeklinde bir akış vardır. Güvenlik duvarını geçip ağa dahil olan herkes ve her cihaz “güvenilir” olarak kabul edilir. Bir kez VPN ile ağa bağlanan veya ofisteki ethernet kablosunu bilgisayarına takan bir çalışana, içerideki dosya sunucularına, veri tabanlarına ve uygulamalara geniş bir erişim hakkı tanınır.
Zero Trust yaklaşımında ise güvenlik sınırı yalnızca fiziksel veya mantıksal ağ çevresi (network perimeter) değildir. Yeni güvenlik çevresi doğrudan “kimlikler” ve “cihazlar”dır.
| Konu | Geleneksel Yaklaşım | Zero Trust |
|---|---|---|
| Güven modeli | Ağ sınırından geçene güvenilir | Varsayılan güven yoktur, her adım doğrulanır |
| Kimlik | Sisteme girişte önemlidir | Merkezi güvenlik unsuru ve kontrol noktasıdır |
| Cihaz | Ağda olması yeterli olabilir | Cihazın sağlığı erişim kararında kritiktir |
| Yetki | Geniş kapsamlı erişim verilebilir | Yalnızca gereken kadar (En az ayrıcalık) |
| Erişim | Bir kez doğrulama genellikle yeterlidir | Sürekli ve bağlamsal değerlendirme yapılır |
| İç ağ | Doğası gereği güvenilir kabul edilir | İnternetteki herhangi bir ağ gibi güvensiz varsayılır |
| İzleme | Genellikle ağ trafiği odaklıdır | Kimlik, cihaz, veri ve kaynak odaklıdır |
Zero Trust’ın Temel Prensipleri
Microsoft’un Zero Trust mimarisi üç temel prensip üzerine inşa edilmiştir. Microsoft 365 üzerinde yapılandırılan tüm güvenlik politikaları bu üç kuralı destekleyecek şekilde çalışır.
Verify Explicitly (Açıkça Doğrula)
Erişim taleplerini sadece kullanıcı adı ve parolaya dayanarak değil, elde edilebilecek tüm veri noktalarını kullanarak doğrulamaktır.
Örnek: Bir kullanıcı Microsoft Teams’e giriş yapmak istediğinde sistem sadece parolaya bakmaz. Kullanıcının kimliğine (Entra ID), anlık konumuna, IP adresinin risk skoruna, giriş yaptığı cihazın şirket tarafından yönetilip yönetilmediğine (Intune) ve cihazda bir tehdit olup olmadığına (Defender) eşzamanlı olarak bakar.
Use Least Privilege Access (En Az Ayrıcalıklı Erişimi Kullan)
Kullanıcılara veya sistemlere sadece görevlerini yerine getirmeleri için gereken sürede ve gereken asgari düzeyde yetki vermektir. Just-In-Time (JIT) ve Just-Enough-Access (JEA) bu prensibin temel uygulamalarıdır.
Örnek: Muhasebe departmanındaki bir çalışanın tüm şirketin SharePoint üzerindeki insan kaynakları arşivini görüntüleme yetkisine ihtiyacı yoktur. Veya bir bilgi işlem çalışanının 7/24 kalıcı olarak “Global Administrator” (Genel Yönetici) yetkisine sahip olması gerekmez; sadece yönetimsel bir görev yapacağı zaman onaylı ve kısıtlı süreli (örneğin 2 saatlik) erişim talep etmelidir.
Assume Breach (İhlal Olduğunu Varsay)
Sisteminizin ne kadar güvenli olursa olsun er ya da geç bir noktadan delineceğini (veya zaten delinmiş olduğunu) kabul ederek mimariyi tasarlamaktır. Bu yaklaşım, saldırganın sistemde yatay olarak ilerlemesini (lateral movement) engellemek için ağın ve erişimlerin parçalara ayrılmasını (segmentasyon), verilerin şifrelenmesini ve anormalliklerin sürekli izlenmesini gerektirir.
Örnek: Şirket ağınızın çok güvenli olduğunu düşünseniz bile, bir kullanıcının cihazına sızmış olabilecek bir fidye yazılımının tüm OneDrive ve SharePoint dosyalarınıza ulaşmasını engellemek için anlık cihaz risk skorunu sürekli değerlendiren politikalar ve verinin kendisini koruyan şifreleme etiketleri kullanırsınız.
Microsoft 365 ile Zero Trust Arasındaki İlişki
Microsoft 365, doğası gereği bulut tabanlı bir hizmet olduğu için geleneksel ağ tabanlı güvenlik modelleriyle korunamaz. İşletmelerin e-postaları, dokümanları, toplantı kayıtları ve iş süreçleri Microsoft veri merkezlerinde, çalışanların erişimi ise dünyanın herhangi bir yerindeki farklı cihazlardan gerçekleşmektedir. Bu durum Microsoft 365’i Zero Trust yaklaşımını uygulamak için hem zorunlu bir alan hem de ideal bir ekosistem haline getirir.
Microsoft 365’te Zero Trust, tekil bir ürünün etkinleştirilmesiyle değil, ekosistemdeki farklı bileşenlerin entegre bir şekilde çalışmasıyla sağlanır. Bu mimaride kimlik doğrulamasından tehdit izlemeye kadar uzanan şöyle bir akış gerçekleşir:
- Kullanıcı erişim talep eder ve bu talep ilk olarak Microsoft Entra ID (eski adıyla Azure AD) tarafından karşılanıp kimlik doğrulamasına tabi tutulur.
- MFA (Çok Faktörlü Kimlik Doğrulama) ile parolanın ötesinde bir doğrulama istenir.
- Bu sırada Microsoft Intune devreye girerek cihazın şirketin güvenlik politikalarına uygun olup olmadığını (Device Compliance) kontrol eder.
- Microsoft Defender, cihaz üzerinde o an aktif bir tehdit veya zararlı yazılım olup olmadığını anlık olarak değerlendirir.
- Tüm bu sinyaller (kimlik, konum, cihaz, risk durumu) Conditional Access (Koşullu Erişim) motorunda birleştirilerek erişime izin verilip verilmeyeceğine, kısıtlı izin verilip verilmeyeceğine karar verilir.
- Erişim sağlandıktan sonra Microsoft Purview, kullanıcının dokunduğu verinin hassasiyetini denetler (örneğin, kredi kartı bilgisini içeren dosyanın dışarı çıkarılmasını engeller).
- Arka planda Microsoft Sentinel gibi bir SIEM/SOAR çözümü (veya Defender XDR), tüm bu adımlardaki logları sürekli izleyerek olağandışı bir durum tespit ettiğinde otomatik yanıt süreçlerini başlatır.
İşte Microsoft 365 Zero Trust mimarisi tam olarak bu birbirine entegre katmanların uyumudur.
(Microsoft 365’in güvenlik özelliklerini ve E3/E5 güvenlik seçeneklerini daha geniş bir çerçevede değerlendirmek için kapsamlı Microsoft 365 güvenlik paketleri rehberine göz atabilirsiniz.)
Microsoft Entra ID Zero Trust Mimarisinde Neden Önemlidir?
Microsoft Entra ID (eski Azure Active Directory), Zero Trust mimarisinin kontrol merkezi ve kalbidir. İşletmenizdeki tüm kullanıcı hesaplarının, cihaz kayıtlarının ve uygulamaların kimlik yönetimini üstlenir.
Kimlik merkezli güvenlik
Zero Trust modelinde ağ çevresi ortadan kalktığı için yeni güvenlik sınırı kimliktir. Entra ID, tüm erişim taleplerinin (ister bir Microsoft 365 uygulamasına, ister şirketin on-premises bir sunucusuna, ister üçüncü taraf bir SaaS uygulamasına olsun) yönlendirildiği merkezi otoritedir.
Authentication ve Authorization farkı
Güvenlikte kimlik doğrulama (Authentication – “Sen kimsin?”) ile yetkilendirme (Authorization – “Neye erişebilirsin?”) farklı kavramlardır. Entra ID, kullanıcı adını, parolayı ve MFA’yı kontrol ederek Authentication’ı gerçekleştirir. Ancak Zero Trust yaklaşımında bu yeterli değildir; ardından kullanıcının o anki durumu ve grup üyeliklerine bakarak yetkilendirme (Authorization) adımını yönetir.
Kullanıcı kimliğinin güvenlik sınırı haline gelmesi
Herhangi bir cihazdan, herhangi bir ağdan gelen istek ilk olarak Entra ID kapısını çalar. Bu nedenle kimliğin korunması, tüm verinin korunmasıyla eşdeğerdir. “Assume Breach” (İhlal Olduğunu Varsay) prensibi gereği, saldırganın ilk hedefi her zaman bir çalışanın kimliğini (credentials) ele geçirmektir.
Yönetici hesaplarının korunması
Global Administrator (Genel Yönetici), Exchange Administrator veya SharePoint Administrator gibi ayrıcalıklı roller, saldırganlar için en değerli hedeflerdir. Entra ID, standart kullanıcılara nazaran bu hesaplar için çok daha katı güvenlik süreçleri (Privileged Identity Management – PIM) uygulanmasına olanak tanıyarak Least Privilege (En Az Ayrıcalık) ilkesini hayata geçirir.
Microsoft 365’te MFA ve Zero Trust
Multi-Factor Authentication (MFA), parola tabanlı saldırılara karşı en temel ve en kritik savunma hattıdır.
MFA nedir?
MFA, kimlik doğrulama sürecine kullanıcının “bildiği bir şey” (parola) dışına çıkarak, “sahip olduğu bir şeyi” (akıllı telefondaki Authenticator uygulaması, SMS kodu, FIDO2 güvenlik anahtarı) veya “olduğu bir şeyi” (parmak izi, yüz tanıma) eklemesidir.
MFA neden parola güvenliğinden daha güçlüdür?
Bir çalışanın parolası basit olabilir, başka platformlarda kullandığı bir parolayla aynı olabilir, phishing (oltalama) sitelerine bilmeden girilmiş olabilir veya şirket dışı bir veri sızıntısında açığa çıkmış olabilir. Saldırgan bu parolayı ele geçirse bile, sisteme girmeye çalıştığında kullanıcının telefonuna düşen doğrulama ekranına sahip olmadığı için erişim engellenir. Microsoft verilerine göre MFA, kimlik hırsızlığı saldırılarını %99’un üzerinde bir oranda engellemektedir.
MFA tek başına Zero Trust mıdır?
Hayır. Sadece MFA’yı aktif etmek şirketinizi tam anlamıyla Zero Trust mimarisine geçirmez. MFA, Zero Trust’ın “Verify Explicitly” (Açıkça Doğrula) prensibinin kimlik doğrulama ayağıdır. Ancak kimliği doğrulanmış, MFA’yı geçmiş bir kullanıcının cihazı virüslüyse veya kullanıcı iç tehdit unsuru oluşturuyorsa MFA tek başına bu veriyi koruyamaz. Cihaz sağlığı ve erişim politikalarıyla desteklenmelidir.
Passwordless Authentication
Zero Trust mimarisinin ileri seviyelerinde parola kavramı tamamen ortadan kalkmaya başlar. Microsoft Authenticator uygulaması, Windows Hello for Business veya FIDO2 donanım anahtarları kullanılarak “Parolasız” (Passwordless) kimlik doğrulama yöntemleri tercih edilir. Ortada çalınacak bir parola kalmadığında, kimlik avı (phishing) ve brute-force (kaba kuvvet) saldırılarının etkinlik alanı büyük ölçüde yok edilir.
Conditional Access Nedir ve Zero Trust’ta Nasıl Kullanılır?
Koşullu Erişim (Conditional Access), Entra ID’nin karar motorudur ve Microsoft 365’teki Zero Trust uygulamasının beynidir.
Conditional Access nedir?
Temel bir “Eğer… ise… yap” (If-Then) mantığıyla çalışır. Sisteme giriş yapmak isteyen bir kimlik, erişim sağlama kararı verilmeden önce bir dizi şarta tabi tutulur. Koşullar karşılanmazsa erişim engellenir, sınırlandırılır veya ek doğrulama adımları istenir.
Conditional Access hangi sinyalleri değerlendirebilir?
Bir erişim talebi geldiğinde Conditional Access şu sinyalleri değerlendirir:
- Kullanıcı veya Grup: Talep eden kim? Normal bir çalışan mı, yoksa bir dış danışman mı?
- Uygulama: Hangi kaynağa erişmek istiyor? Exchange Online’a mı yoksa hassas bir İK uygulamasına mı?
- Cihaz: Kullanılan cihaz yönetilen (managed) bir cihaz mı?
- Cihaz Uyumluluğu: Intune üzerinden gelen sinyale göre cihaz sağlıklı ve güvenlik kurallarına uygun (compliant) mu?
- Konum: Bağlantı güvenilen bir şirket IP adresinden mi geliyor, yoksa daha önce hiç giriş yapılmamış riskli bir ülkeden mi?
- Oturum Riski: Identity Protection’dan gelen verilere göre, bu kimlik bilgileri şu anda dark web’de satılıyor olabilir mi veya bir botnet üzerinden saldırı girişimi mi yapılıyor?
Conditional Access ile MFA zorunlu hale getirme
MFA’yı tüm kullanıcılar için sürekli açık tutmak (per-user MFA) kullanıcı deneyimini olumsuz etkileyebilir. Conditional Access ile MFA sadece belirli durumlarda zorunlu tutulabilir. Örneğin: “Kullanıcı şirket iç ağından bağlanıyorsa MFA sorma, ancak evden veya kafeden bağlanıyorsa mutlaka MFA onayı iste.”
Riskli oturumları engelleme
Kullanıcının hesabı sabah 09:00’da İstanbul’dan giriş yaptıktan sonra, 09:45’te Rusya’daki bir IP adresinden oturum açmaya çalışırsa (İmkansız Seyahat / Impossible Travel anormalliği), Conditional Access bu oturum riskini yüksek olarak değerlendirip erişimi tamamen engelleyebilir ve kullanıcının parolasını güvenli bir yöntemle sıfırlamasını şart koşabilir.
Yönetici hesaplarına farklı erişim politikası uygulama
Global Admin yetkisine sahip bir kişinin sisteme erişimi, normal bir çalışandan çok daha risklidir. “Yönetici rollerine sahip kişiler, nerede olurlarsa olsunlar her zaman MFA doğrulaması yapmak zorundadır ve sadece cihazları Intune tarafından yönetiliyorsa Microsoft 365 portallerine girebilirler” şeklinde özel politikalar oluşturulabilir.
Yönetilmeyen cihazlardan erişimi kısıtlama
Çalışanların kendi kişisel bilgisayarlarından (BYOD – Bring Your Own Device) şirket verilerine erişmesi yaygındır. Ancak kişisel cihazlar şirketin güvenlik standartlarını karşılamayabilir. Conditional Access ile şu kural yazılabilir: “Kişisel bir cihazdan SharePoint’e girildiğinde erişime izin ver, ancak belgelerin cihazın diskine indirilmesini (download) kesinlikle engelle, sadece tarayıcı üzerinden (browser-only) okumasına izin ver.”
Zero Trust’ta Cihaz Güvenliği Neden Önemlidir?
Geleneksel yapılarda kullanıcının parolasını bilmesi ve MFA’yı geçmesi her şeye ulaşması için yeterlidir. Ancak Zero Trust yaklaşımında “Kimliği doğrulanmış bir kullanıcının her zaman güvenli bir cihaz kullandığı varsayılamaz.”
Örnek bir problem: Bir şirket yöneticisi, oteldeki ortak kullanıma açık (kiosk) bir bilgisayardan veya antivirüs yazılımı olmayan, zararlı yazılım bulaşmış kişisel tabletinden Microsoft 365 hesabına giriş yapar. Kullanıcı adı, parola ve MFA kodunu doğru girer. Eğer sistem sadece kimliğe güveniyorsa (geleneksel model), yönetici içeri girer. Ancak cihazda bulunan arka plan çalışan bir keylogger veya session-hijacking (oturum çalma) yazılımı, kullanıcının eriştiği tüm müşteri verilerini ve finansal raporları anında sızdırabilir. Veya cihazdaki bir fidye yazılımı (ransomware) kullanıcının yetkilerini kullanarak OneDrive’daki kurumsal verileri şifreleyebilir.
Bu nedenle Zero Trust, kimlik doğrulamasına cihazın sağlık durumunu, işletim sistemi güncelliğini ve yönetim statüsünü eşdeğer önemde bir güvenlik sinyali olarak dahil etmek zorundadır.
Microsoft Intune ve Zero Trust
Microsoft Intune, işletmelerin mobil cihaz yönetimini (MDM) ve mobil uygulama yönetimini (MAM) sağlayan bulut tabanlı bir hizmettir. Zero Trust mimarisinde “Cihaz” (Device) sütununun karar verici otoritesidir.
Microsoft Intune nedir?
Intune, işletmelerin Windows, macOS, iOS ve Android cihazları üzerinde kurumsal politikalar uygulamasını, güvenlik ayarlarını yapılandırmasını ve şirket verilerinin kişisel uygulamalara sızmasını engellemesini sağlar.
Cihaz kayıt ve yönetimi
Bir cihazın kurumsal kaynaklara tam erişim sağlayabilmesi için öncelikle Intune platformuna kaydedilmesi (enrollment) gerekir. Bu kayıt işlemi, cihazın şirket envanterine girmesini ve BT departmanı tarafından yönetilebilir hale gelmesini sağlar.
Device Compliance (Cihaz Uyumluluğu)
Intune’un Zero Trust mimarisindeki en kritik rolü Cihaz Uyumluluk Politikaları (Compliance Policies) aracılığıyla ortaya çıkar. Bir cihazın uyumlu (compliant) sayılması için belirli şartları taşıması istenir. Örneğin:
- İşletim sistemi minimum Windows 11’in şu sürümünde olmalı.
- Cihazın diski şifrelenmiş (BitLocker) olmalı.
- Bir antivirüs veya EDR çözümü (Defender) aktif ve çalışır durumda olmalı.
- iOS/Android cihazlar “Jailbreak” veya “Root” edilmemiş olmalı.
Eğer cihaz bu şartlardan herhangi birini sağlamıyorsa (örneğin kullanıcı antivirüsü kapatmışsa), Intune cihazın durumunu “Uyumsuz” (Non-Compliant) olarak günceller.
Uyumlu ve uyumsuz cihazlar
Cihaz uyumsuz duruma düştüğü anda, Entra ID Conditional Access politikası devreye girer. “Cihazın uyumlu olması gereklidir” kuralı ihlal edildiği için, kullanıcının mevcut Microsoft 365 oturumu anında kesilebilir veya yeni kaynaklara erişimi engellenebilir.
BYOD (Kendi Cihazını Getir) senaryoları ve Mobil Uygulama Yönetimi
Kişisel telefonların (BYOD) şirketin cihaz yönetimine tamamen kaydedilmesi çalışan gizliliği açısından her zaman mümkün veya tercih edilebilir değildir. Bu durumda Zero Trust, Intune MAM (Mobil Uygulama Yönetimi) politikalarıyla uygulanır. Kullanıcının telefonunun tamamı yönetilmez; sadece telefondaki kurumsal Outlook, Teams, OneDrive gibi uygulamalar (App Protection Policies) koruma altına alınır. Örneğin, bir çalışan Outlook uygulamasındaki şirket e-postasındaki bir metni kopyalayıp kişisel WhatsApp uygulamasına yapıştıramaz. Bu, cihazı yönetmeden kurumsal veriyi yönetme yaklaşımıdır.
Microsoft Defender ile Zero Trust ve Endpoint Security
Cihazın Intune tarafından yönetiliyor olması ve temel politikalara uyması cihazın o an için bir siber saldırı altında olmadığı anlamına gelmez. Microsoft Defender, Zero Trust’ın tehdit tespit ve yanıt katmanıdır.
Endpoint Security (Uç Nokta Güvenliği) ve Defender for Endpoint
Uç nokta (endpoint), çalışanın kullandığı bilgisayar veya mobil cihazdır. Microsoft Defender for Endpoint, geleneksel bir antivirüs programı değil, cihazdaki işletim sistemi davranışlarını, bellek süreçlerini ve anormallikleri sürekli izleyen gelişmiş bir güvenlik platformudur.
EDR ve XDR nedir?
EDR (Endpoint Detection and Response), cihaz üzerinde gerçekleşen şüpheli aktiviteleri (örneğin bir Word belgesinin arka planda PowerShell çalıştırmaya kalkmasını) tespit edip, bunu otomatik olarak izole eden ve güvenlik ekiplerine bildiren teknolojidir. XDR (Extended Detection and Response) ise, sadece cihazdan gelen (EDR) sinyalleri değil; kimlik, e-posta ve bulut uygulamalarından gelen tüm sinyalleri tek bir platformda birleştiren yapıdır. Microsoft Defender mimarisi bir XDR çözümüdür.
Ele geçirilmiş cihaz senaryosu
Zero Trust yaklaşımının neden cihaz güvenlik sinyallerini de dikkate alması gerektiğine dair çarpıcı bir senaryo:
Kullanıcı, doğru hesabı ve doğru MFA kodunu girerek sisteme bağlanır. Cihaz da Intune’a kayıtlıdır ve disk şifrelemesi açıktır (Compliance şartlarını sağlar). Ancak kullanıcı, kişisel web gezinmesi sırasında farkında olmadan arka planda çalışan bir zararlı yazılım (malware) indirmiştir.
Geleneksel bir modelde (veya sadece Entra ID ve Intune olan bir modelde) bu kullanıcı şirketin SharePoint sunucularına bağlanıp dosyaları senkronize etmeye devam edecektir ve ransomware dosyaları şifreleyecektir. Ancak Zero Trust mimarisinde Microsoft Defender for Endpoint, cihazdaki bu zararlı yazılımın hareketini (anormal dosya erişim davranışını) saniyeler içinde algılar. Cihazın risk seviyesini “Yüksek” (High Risk) olarak işaretler. Bu sinyal derhal Intune’a ve Entra ID’ye iletilir. Conditional Access, yüksek riskli bir cihazın erişimini reddedecek şekilde yapılandırıldığı için, kullanıcının Microsoft 365 bağlantısı zararlı yazılım sunucuya ulaşamadan anında kesilir.
Least Privilege (En Az Ayrıcalık) Nedir?
Verify Explicitly (Doğrulama) ve cihaz güvenliği sağlandıktan sonra, Zero Trust’ın diğer prensibi devreye girer: Kullanıcıya sadece işini yapması için gereken en düşük yetkiyi vermek.
Kullanıcıya neden sınırsız yetki verilmemeli?
Çünkü ele geçirilen bir hesabın şirkete verebileceği zarar (blast radius – etki alanı), o hesabın sahip olduğu yetkilerle doğru orantılıdır. Satış departmanındaki bir çalışanın teknik sunuculara veya finansal tablolara erişiminin baştan kapalı olması, o kullanıcının hesabı çalındığında saldırganın bu verilere ulaşmasını imkansız kılar (Assume Breach).
Yönetici hesapları ve geçici yetki
Zero Trust modelinde kalıcı yönetici (Standing Privileges) hesaplarından kaçınılır. Eğer bir BT uzmanının SharePoint yöneticisi olması gerekiyorsa, bu yetki ona sonsuza kadar verilmemelidir. Bunun yerine Privileged Identity Management (PIM) kullanılır. Kullanıcı standart yetkilerle çalışır, yönetici işlemi yapması gerektiğinde PIM üzerinden örneğin 1 saatlik “Just-in-Time” (JIT – Tam Zamanında) yetki talep eder. Yetki süresi bitince kullanıcının hakları tekrar standart seviyeye düşer.
Yetki gözden geçirme (Access Reviews)
Çalışanların departman değiştirmesi veya projelerin sona ermesi durumlarında, sahip oldukları eski yetkiler genellikle unutulur. Zero Trust, Microsoft Entra ID Governance kapsamındaki “Access Reviews” özelliği ile proje sahiplerine düzenli aralıklarla “Bu kullanıcının hala bu gruba üye olmasına gerek var mı?” sorusunu sorarak yetki fazlalıklarını otomatik olarak temizler.
Zero Trust’ta Yönetici Hesapları Nasıl Korunmalı?
Saldırganların asıl hedefi şirket hiyerarşisindeki sıradan kullanıcılar değil, Global Administrator (Genel Yönetici) yetkisine sahip hesaplardır. Bu hesapların korunması Microsoft 365 Zero Trust stratejisinin en hassas noktasıdır.
- Ayrı Yönetici Hesabı Kullanımı: Yöneticiler günlük e-postalarını okumak, web’de gezinmek veya ofis belgeleri düzenlemek için kesinlikle yetkili hesaplarını kullanmamalıdırlar. Günlük kullanım için standart bir hesap (“ad.soyad@”), yönetimsel işlemler için ayrı bir hesap (“admin.ad@”) oluşturulmalı ve bu hesaplar arasında kesin bir ayrım (Least Privilege) yapılmalıdır. E-posta üzerinden gelebilecek bir phishing veya zararlı ek saldırısı standart hesaba isabet etmelidir.
- Ayrıcalıklı Kimlik Yönetimi (PIM): Yönetici hesaplarında yetkiler sürekli (kalıcı) olarak tutulmamalı, işlemler Just-In-Time (JIT) modeliyle sadece ihtiyaç anında ve bir yöneticinin onayıyla kısa süreliğine aktive edilmelidir.
- Daha Sıkı Conditional Access: Yönetici hesapları sisteme bağlanırken mutlaka daha sıkı politikalara tabi olmalıdır. Örneğin, yöneticiler sadece belirli “Güvenilir Ağlardan” (Trusted Locations) ve “Şirket Tarafından Yönetilen” (Compliant) cihazlardan portale girebilmeli, dışarıdan erişimler engellenmelidir.
- Acil Durum Hesapları (Break-Glass Accounts): Conditional Access yapılandırmalarında yapılan bir hata, tüm yöneticilerin sisteme girişini kilitleyebilir. Bu tür durumlara karşı, günlük operasyonlarda asla kullanılmayan, şifresi son derece uzun ve karmaşık olan, MFA’ya veya CA politikalarına tabi olmayan 1 veya 2 adet “Acil Durum Hesabı” (Break-Glass) Entra ID üzerinde tutulmalı ve bu hesapların kullanımı şiddetli alarm üretecek şekilde izlenmelidir.
Microsoft 365’te Zero Trust ve Uzaktan Çalışma
Zero Trust mimarisinin değeri, özellikle pandemiden sonra standartlaşan hibrit ve uzaktan çalışma senaryolarında daha net ortaya çıkmıştır.
Evden ve farklı lokasyonlardan erişim
Çalışanlar evlerindeki kişisel ağlarından veya kafelerdeki güvensiz ortak Wi-Fi ağlarından şirket verilerine bağlanmaktadır. Geleneksel güvenlik duvarı (Firewall) burada işlevsiz kalır. Zero Trust ise kullanıcının bağlandığı ağa (ev ağı) değil, kimliğine ve cihazına odaklanır. Conditional Access, kullanıcının yeni bir konumdan giriş yaptığını algılayarak risk seviyesini ölçer ve gerekiyorsa erişimi sınırlar.
VPN olmadan güvenli erişim yaklaşımı
Geleneksel uzaktan çalışma modeli VPN’e (Sanal Özel Ağ) dayanıyordu. VPN’in amacı, dışarıdaki bir cihazı sanal olarak şirket iç ağına (ve dolayısıyla tüm iç kaynaklara) dahil etmektir. Zero Trust, VPN’i tamamen ve anında çöpe atmaz; ancak VPN’in “ağa bağlanan herkese içeride geniş haklar tanıma” felsefesini değiştirir. Microsoft 365 kaynaklarına (Teams, SharePoint, Exchange Online) erişim zaten internet üzerinden yapıldığı için VPN’e gerek yoktur. Zero Trust, kaynakları ağın arkasına gizlemek yerine, kimlik ve cihaz koşulları üzerinden mikro segmentasyon ile doğrudan internete açık uygulamaları güvenli hale getirir. Microsoft Entra Private Access ve Microsoft Entra Application Proxy gibi özellikler, on-premises uygulamaları bile VPN kullanmadan Zero Trust prensipleriyle (koşullu erişim ve MFA zorunluluğu ile) internet üzerinden güvenle sunmayı sağlar.
Zero Trust ve Microsoft 365 Uygulamaları
Zero Trust’ın Microsoft 365 iş birliği uygulamalarındaki yansıması, veriye erişimin kontrol edilmesidir.
- Exchange Online (E-posta): E-posta kutularına erişim Conditional Access ile korunur. Eski (Legacy) kimlik doğrulama protokolleri (IMAP, POP3) MFA desteklemediği için tamamen kapatılır (Assume Breach).
- SharePoint ve OneDrive (Dosyalar): Kullanıcıların hangi cihazlardan bu verilere ulaşabileceği denetlenir. Hassas veriler içeren SharePoint sitelerine kişisel cihazlardan (Uyumsuz – Non Compliant cihaz) erişildiğinde, dosya indirme kısıtlanarak sadece tarayıcı üzerinden görüntüleme (Session Control) sağlanır.
- Microsoft Teams: Ekipler arası mesajlaşma ve dosya paylaşımında misafir kullanıcılara (Guest Access) hangi yetkilerin verileceği en az ayrıcalık (Least Privilege) ilkesine göre yönetilir.
Zero Trust ve Veri Güvenliği
Zero Trust’ın nihai amacı sunucuları veya cihazları korumak değil, veriyi (Data) korumaktır. Kimlik ve cihaz güvenliği aşıldığında bile veri kendi kendini koruyabilmelidir.
Microsoft Purview ve Data Loss Prevention (DLP)
Kullanıcı, MFA’yı geçmiş ve şirketin verdiği yönetilen bir cihazdan güvenli bir şekilde sisteme girmiş olabilir. Ancak bu durum, kullanıcının içindeki müşteri kredi kartı bilgilerini barındıran bir Excel tablosunu kişisel e-postasına veya rakip şirkete bilerek veya yanlışlıkla (İç Tehdit – Insider Risk) göndermeyeceği anlamına gelmez. Microsoft Purview Veri Kaybı Önleme (DLP) politikaları, içeriğinde hassas veriler olan dosyaların paylaşılmasını engeller. Sensitivity Labels (Duyarlılık Etiketleri) ile bir belgeye “Çok Gizli” etiketi yapıştırıldığında, belge otomatik olarak şifrelenir (Assume Breach). Belge şirket dışına e-posta ile gönderilse veya bir USB bellekle çalınsa bile, dosyayı açmaya çalışan kişinin Entra ID’ye bağlanıp yetkili bir kullanıcı olduğunu kanıtlaması gerektiği için veri okunamaz. Bu, “kimlik doğrulandı, artık her şeye erişebilir” mantığının reddedilmesidir.
Zero Trust ve Güvenlik Operasyonları
Zero Trust mimarisinin tamamlayıcı unsuru görünürlük ve sürekli izlemedir. Bir politikanın engellediği veya izin verdiği trafiği göremezseniz, tehditlerin farkına varamazsınız.
Tehdit sinyallerinin birleştirilmesi ve Microsoft Sentinel
Cihaz üzerindeki anormallikler (Microsoft Defender), kimlik saldırıları (Entra ID Identity Protection), e-posta üzerinden gelen zararlı bağlantılar (Defender for Office 365) ve veri sızıntısı uyarıları (Microsoft Purview) ayrı ayrı panellere düşerse, güvenlik ekiplerinin (SOC) olaylar arasındaki bağlantıyı (saldırı zincirini) görmesi çok zordur. Microsoft Sentinel (veya Defender XDR altyapısı), tüm bu sistemlerden gelen milyarlarca logu tek bir merkezde (SIEM – Güvenlik Bilgi ve Olay Yönetimi) toplar. Yapay zeka destekli korelasyon ile “Bu cihazdaki zararlı yazılım uyarısı ile şu kullanıcının Rusya’dan gelen başarısız giriş denemesi aynı saldırının parçasıdır” diyerek güvenlik ekiplerine olay müdahale (Incident Response) şansı tanır.
Microsoft 365 Zero Trust Gerçek Bir Saldırı Senaryosunda Nasıl Çalışır?
Zero Trust’ın tek bir ürün olmadığını, birbiriyle konuşan bir güvenlik felsefesi olduğunu anlamak için tipik bir siber saldırı (örneğin Business Email Compromise – BEC veya Ransomware) senaryosunu adım adım inceleyelim:
Geleneksel Güvenlik Modelinde Senaryo: Saldırgan, finans yöneticisine bir phishing (oltalama) e-postası gönderir. Yönetici, sahte Microsoft 365 sayfasına parolasını girer. Saldırgan bu parola ile sisteme anında girer, sahte faturalar göndererek şirketi dolandırır veya şirketin OneDrive verilerini kendi bilgisayarına indirerek siler.
Microsoft 365 Zero Trust Modelinde Aynı Senaryo:
- Saldırının Başlaması: Saldırgan phishing e-postası gönderir. (Bu aşamada Defender for Office 365, zararlı bağlantıyı engellemeye çalışır. Varsayalım ki son derece yeni bir saldırı olduğu için e-posta gelen kutusuna ulaştı.)
- Kimlik Avı: Kullanıcı bağlantıya tıklar ve parolasını girer. Saldırgan parolayı ele geçirir.
- Giriş Denemesi: Saldırgan, kullanıcının parolasıyla kendi bilgisayarından (örneğin yurtdışından) Microsoft 365’e giriş yapmayı dener.
- Entra ID Doğrulaması: Entra ID parolayı doğrular, ancak Conditional Access motoru çalışır: “Kullanıcı her zaman bağlandığı lokasyonun dışından bağlanıyor, oturum riski yüksek (Identity Protection sinyali).”
- MFA Müdahalesi: Conditional Access, kullanıcının asıl telefonuna MFA onay (veya rakam eşleştirme) isteği gönderir. Saldırgan MFA’ya sahip olmadığı için (Verify Explicitly) sisteme giremez.
- Cihaz Katmanı: Varsayalım ki saldırgan çok gelişmiş bir MFA yorgunluğu (Fatigue) veya AiTM (Adversary-in-the-Middle) saldırısıyla MFA’yı da atlattı. Conditional Access ikinci kuralına bakar: “Giriş yapılan cihaz, şirketin Intune sistemine kayıtlı mı ve güvenli mi?” Saldırganın cihazı şirkete kayıtlı olmadığı için (Uyumsuz Cihaz), erişim doğrudan engellenir.
- Sürekli İzleme: Tüm bu başarısız ve riskli giriş denemeleri Microsoft Sentinel veya Defender XDR panellerine “Yüksek Riskli Kimlik” olarak düşer. Sistem otomatik olarak kullanıcının parolasını geçersiz kılarak sıfırlamaya zorlar (Assume Breach).
Görüldüğü gibi hiçbir tek ürün “her şeyi çözmez”. Zero Trust mimarisi, saldırganın her aşamada farklı bir bariyere çarpmasını (Defense in Depth – Derinlemesine Savunma) sağlar.
Microsoft 365 Zero Trust İçin Örnek Güvenlik Politikaları
Gerçek hayatta uygulanabilecek, işletmelerin Zero Trust mimarisini şekillendiren temel Conditional Access (Koşullu Erişim) politikaları şunlardır:
Politika 1 — Tüm kullanıcılar için MFA
- Amacı: Her kullanıcının kimliğini doğrularken parolanın ötesine geçmek (Verify Explicitly).
- Çözdüğü Problem: Parola sızıntıları ve brute-force (kaba kuvvet) saldırıları.
- Yanlış Uygulanırsa: Legacy Authentication (Eski kimlik doğrulama) kullanan sistemler veya yazıcılar (SMTP vs.) istisna edilmezse operasyonel kesintiler yaşanabilir.
Politika 2 — Yönetici hesaplarında daha sıkı erişim
- Amacı: Global Admin gibi yüksek yetkili hesapların sadece şirket ofisinden (Güvenilir IP) veya şirketin yönettiği (Compliant) cihazlardan giriş yapabilmesini sağlamak.
- Çözdüğü Problem: Yönetici hesaplarının ele geçirilerek tüm tenant’ın şifrelenmesi.
- Yanlış Uygulanırsa: Acil durum (Break-glass) hesapları hariç tutulmazsa, IP değişikliklerinde tüm yöneticiler dışarıda kalabilir.
Politika 3 — Riskli oturumların engellenmesi
- Amacı: Identity Protection sinyallerine göre (örneğin imkansız seyahat, sızdırılmış kimlikler) risk seviyesi “Yüksek” olan oturumların şifre sıfırlamaya zorlanması.
- Çözdüğü Problem: Hesabın ele geçirildiği anlaşıldığı durumlarda aktif saldırıları otomatik kesmek.
- Yanlış Uygulanırsa: VPN kullanan ve sık IP değiştiren kullanıcılar gereksiz yere sürekli şifre sıfırlama talepleriyle karşılaşabilir.
Politika 4 — Yönetilmeyen cihazların kısıtlanması (Uygulama Kontrolü)
- Amacı: Intune’da “Uyumlu” (Compliant) olarak işaretlenmeyen kişisel cihazlardan (BYOD) SharePoint ve Exchange’e girildiğinde “sadece web tarayıcısı üzerinden, indirme kapalı” (App-enforced restrictions) şeklinde izin vermek.
- Çözdüğü Problem: Şirket verilerinin güvensiz kişisel cihazların diskine indirilerek dışarı sızmasını önlemek.
- Yanlış Uygulanırsa: Saha çalışanları mobil uygulamaları kullanamayarak iş süreçlerini yavaşlatabilir.
Politika 5 — İşten ayrılan kullanıcıların erişiminin kapatılması
- Amacı: IK sisteminden ayrılış işlemi yapıldığında, kimlik yaşam döngüsü (Identity Lifecycle) süreçleriyle kullanıcının oturumlarının anında iptal edilmesi.
- Çözdüğü Problem: Eski çalışanların şirket verilerine erişmeye devam etmesi (Yetki iptali eksikliği).
Microsoft 365 Zero Trust Uygulamasında Sık Yapılan Hatalar
İşletmeler Zero Trust yolculuğunda genellikle yapılandırma veya strateji hataları yaparlar. En yaygın hatalar:
Zero Trust’ı sadece MFA sanmak
“Tüm kullanıcılarda MFA açık, dolayısıyla güvendeyiz” yanılgısı. MFA tek başına Zero Trust değildir; cihaz uyumluluğu, least privilege ve risk bazlı oturum kontrolleri olmadan mimari eksik kalır.
Cihaz güvenliğini göz ardı etmek
Kullanıcıların hangi cihazdan girdiğine bakmadan sadece kimlik doğrulamaya odaklanmak, zararlı yazılım bulaşmış kişisel bilgisayarların şirket verilerine erişmesine (ve fidye yazılımı bulaştırmasına) kapı aralamaktır.
Yönetici hesaplarını standart kullanıcılarla aynı korumak
Ayrıcalıklı rollere (Global Admin) sahip kullanıcılara standart personelle aynı güvenlik politikalarını uygulamak ve PIM (Ayrıcalıklı Kimlik Yönetimi) kullanmamak saldırganlara açık davetiye çıkarır.
Conditional Access’i plansız şekilde aktif etmek
Koşullu Erişim politikalarını “Report-Only” (Sadece Raporla) modunda test etmeden doğrudan aktif (On) hale getirmek, binlerce çalışanın veya kritik sistem servis hesaplarının aniden sisteme erişememesine (lockout) yol açabilir.
Çok geniş yetkiler vermek
“Yönetim kolay olsun” diyerek şirkette gereğinden fazla kişiye geniş yönetim yetkileri vermek veya SharePoint klasörlerini “herkese açık” bırakmak (Least Privilege prensibinin ihlali).
Eski (Legacy) kimlik doğrulama yöntemlerini açık bırakmak
MFA kullanıyor olsanız bile, eğer IMAP, POP3 gibi eski protokolleri Entra ID üzerinden engellemediyseniz (Block Legacy Authentication), saldırganlar MFA’yı bypass ederek doğrudan bu protokoller üzerinden saldırı yapabilir.
Güvenlik uyarılarını ve logları izlememek
Zero Trust sistemleri çok sayıda log ve uyarı üretir. Bu uyarıları toplayacak bir Sentinel altyapısı veya analiz edecek bir SOC (Güvenlik Operasyon Merkezi) ekibi yoksa, sistem bir alarm çalsa da duyan kimse olmaz.
Kullanıcı deneyimini hesaba katmamak
Aşırı katı, her işlemde tekrar tekrar şifre ve onay isteyen güvenlik politikaları kurgulamak, çalışanları yorar (MFA Fatigue). Çalışanlar işlerini yapmak için WhatsApp, kişisel Gmail gibi kuralları atlayacak alternatif yollar (Shadow IT) aramaya başlarlar.
Microsoft 365’te Zero Trust Nasıl Uygulanır?
Zero Trust, lisans alınca devreye giren bir düğme değildir. Adım adım işletilmesi gereken bir süreçtir.
1. Mevcut ortamı keşfetme
Öncelikle kimlikleriniz nerede (On-premises AD, bulut Entra ID?), hangi cihazlar kullanılıyor, kritik verileriniz nerede duruyor, kimlerin yönetici yetkisi var? Bu envanter (Assessment) çıkarılmalıdır.
2. Kimlik güvenliğini güçlendirme
Eski (Legacy) protokolleri kapatın. Düzenli kullanılmayan eski hesapları silin. Acil durum (Break-glass) hesaplarını oluşturun.
3. MFA ve doğrulama politikalarını oluşturma
Tüm çalışanlar için MFA’yı aktif edin. Mümkün olan departmanlar için parolasız (Passwordless) kimlik doğrulama yöntemlerine (Authenticator app, FIDO2) geçişi planlayın.
4. Cihaz yönetimini oluşturma
Şirket bilgisayarlarını ve mobil cihazları Microsoft Intune’a kaydedin (Enrollment). Her platform (Windows, iOS, Android) için bir “Uyum” (Compliance) standardı belirleyin (Örn: BitLocker zorunlu, şifre zorunlu).
5. Conditional Access tasarlama
Entra ID üzerinde, kimlik, MFA ve cihaz uyumluluk şartlarını birbirine bağlayan “Koşullu Erişim” politikalarını “Report-Only” (Test) modunda tasarlayın ve çalışan erişimlerini engellemediğinden emin olunca devreye alın (Enforcement).
6. Endpoint security ve Defender politikalarını uygulama
Cihazlara Defender for Endpoint (EDR) sensörlerini dağıtın. Cihazlardan gelen risk sinyallerini Intune ve Conditional Access’e bağlayarak, virüslü bir cihazın ağ erişimini otomatik kesmesini sağlayın.
7. Least Privilege modeline geçiş
Global Admin sayısını 5’in altına indirin (tercihen 2 veya 3). Gerekli durumlar için Microsoft Entra Privileged Identity Management (PIM) devreye alın.
8. Veri erişimini değerlendirme
Microsoft Purview kullanarak şirket içindeki hassas (kredi kartı, TC no vs.) verileri sınıflandırın. Bu verilerin yetkisiz indirilmesini veya paylaşılmasını engelleyecek DLP politikalarını yapılandırın.
9. Güvenlik izleme
Oluşturulan tüm politikaların loglarını merkezi bir izleme ortamına (Microsoft Sentinel veya Defender XDR portalı) aktararak düzenli tehdit avcılığı (Threat Hunting) yapın.
Zero Trust’a Geçiş Bir Anda mı Yapılmalı?
Zero Trust dönüşümü, bir hafta sonunda (cutover) bitirilecek bir IT projesi değildir. Organizasyonun büyüklüğüne göre aylara veya yıllara yayılan bir programdır. Süreci bir anda değiştirmek, iş sürekliliğini kesintiye uğratabilir. Aşama aşama ilerlenmelidir:
- Aşama 1 (Kimlik ve Erişim Temeli): Sadece MFA’yı yaygınlaştırmak, eski protokolleri kapatmak ve Conditional Access ile riskli lokasyonları engellemek. Bu hızlı bir kazanımdır (Quick win).
- Aşama 2 (Cihaz Güvenliği): Cihazları Intune’a kaydetmeye başlamak. Cihaz sağlığına göre erişimi şekillendirmek daha fazla planlama ve kullanıcı iletişimi gerektirir.
- Aşama 3 (Veri ve Ayrıcalık): PIM (Ayrıcalıklı erişim) yapısına geçmek, verileri sınıflandırmak (Purview DLP). Bu aşamalar iş birimleriyle (IK, Hukuk, Finans) koordinasyon gerektirir.
- Aşama 4 (Otomasyon ve İzleme): Sentinel ile olay müdahalesini otomatize etmek.
Microsoft 365 E3 ve E5 ile Zero Trust İlişkisi
Zero Trust bir lisans paketi değildir, ancak bu mimariyi hayata geçirmek için Microsoft’un sunduğu teknolojik yeteneklere ihtiyaç vardır. Microsoft 365 E3 ve E5 planları bu mimarinin temel sağlayıcılarıdır.
- Microsoft 365 E3: Zero Trust yolculuğuna başlamak için güçlü bir temeldir. Microsoft Entra ID P1 (Conditional Access için), Intune (cihaz yönetimi için) ve temel veri koruma özelliklerini barındırır. Standart bir Zero Trust modelini E3 ile rahatlıkla inşa edebilir, MFA ve cihaz uyumluluk kurallarını yazabilirsiniz.
- Microsoft 365 E5: Zero Trust’ın “İleri Seviye” (Advanced) özelliklerini sunar. Microsoft Entra ID P2 (Risk bazlı oturum değerlendirmesi – Identity Protection ve PIM – Ayrıcalıklı Erişim Yönetimi için), Defender for Endpoint Plan 2 (Gelişmiş EDR için) ve Purview’un otomatik veri sınıflandırma özelliklerini içerir. E5, “Assume Breach” prensibinde yapay zekanın ve otomasyonun devreye girdiği noktadır.
E3 kullanan işletmeler, ihtiyaçlarına göre sadece “M365 E5 Security” gibi eklentiler (add-ons) alarak da Zero Trust kapasitelerini geliştirebilirler. (Daha detaylı lisans farklılıkları için Microsoft 365 E3 mü E5 mi? değerlendirmemizi inceleyebilirsiniz.)
Zero Trust Hangi İşletmeler İçin Daha Önemlidir?
Zero Trust her işletme için bir standart haline gelmiş olsa da, bazı yapılar için operasyonel bir zorunluluktur:
- Hibrit çalışan şirketler: Personelin bir kısmı ofiste, bir kısmı evde, bir kısmı kafelerde çalışıyorsa geleneksel ağ güvenliği geçersizdir; cihaz ve kimlik tabanlı Zero Trust şarttır.
- Hassas veri işleyen şirketler: Finans, sağlık, hukuk büroları ve finansal teknoloji (Fintech) şirketleri regülasyonlar (KVKK, GDPR, BDDK) gereği verilere “En Az Ayrıcalık” ile erişildiğini ispatlamak zorundadırlar.
- Birden fazla lokasyonu bulunan şirketler: Dağıtık yapılarda verinin kim tarafından, hangi cihazla, nereden açıldığını kontrol etmek (Verify Explicitly) veri sızıntılarını önlemenin tek yoludur.
Microsoft 365 Zero Trust İçin Güvenlik Kontrol Listesi
Kendi Microsoft 365 ortamınızın Zero Trust prensiplerine ne kadar uygun olduğunu değerlendirmek için aşağıdaki temel kontrol listesini kullanabilirsiniz:
Tüm kullanıcıların kimlikleri kontrol edildi mi? (Aktif olmayan hesapların kapatıldığından emin olun.)
MFA herkes için aktif mi? (Sadece yöneticiler için değil, tüm personel için MFA devreye alınmalıdır.)
Yönetici hesapları ayrıldı mı? (Günlük e-posta kullanımı ile admin işlemleri aynı hesap üzerinden yapılmamalıdır.)
Yönetici hesaplarında güçlü erişim politikaları (PIM) var mı? (Yetkiler kalıcı değil, süreli-JIT olarak verilmelidir.)
Conditional Access kullanılıyor mu? (Riskli oturumları, güvensiz konumları engelleyen kurallar yazılmalıdır.)
Cihazlar merkezi olarak yönetiliyor mu? (Microsoft Intune ile şirket cihazları kayıt altına alınmalıdır.)
Cihaz uyumluluğu kontrol ediliyor mu? (BitLocker veya parola olmayan cihazların erişimi kısıtlanmalıdır.)
Endpoint security politikaları uygulanıyor mu? (Defender ile cihazdaki zararlı yazılımlar izlenmelidir.)
Eski (Legacy) kimlik doğrulama yöntemleri engellendi mi? (IMAP/POP gibi MFA desteklemeyen protokoller kapatılmalıdır.)
Ayrılan çalışanların erişimi otomatik sonlandırılıyor mu? (IK süreçleriyle Entra ID senkronize olmalıdır.)
Hassas verilere erişim sınırlandırılıyor mu? (Purview DLP ile dışarıya veri sızıntısı engellenmelidir.)
Güvenlik logları (Sentinel/Defender XDR) aktif izleniyor mu? (Bir saldırı gerçekleştiğinde geriye dönük iz sürebilmek için loglar kritik öneme sahiptir.)
Acil durum (Break-glass) hesapları oluşturuldu mu? (Tüm yöneticilerin sistem dışında kalma riskine karşı acil çıkış kapısı bırakılmalıdır.)
Microsoft 365 Zero Trust Hakkında Sık Sorulan Sorular
Zero Trust nedir?
Geleneksel “ağ içindeki herkese güvenme” mantığından vazgeçerek, her bir erişim talebinin kimlik, cihaz, konum ve risk bağlamında sürekli doğrulanmasını gerektiren siber güvenlik mimarisidir.
Microsoft 365 Zero Trust nedir?
Zero Trust prensiplerinin Microsoft 365 hizmetlerine (Teams, SharePoint, Exchange Online) Microsoft Entra ID, Intune ve Defender gibi entegre güvenlik çözümleri kullanılarak uygulanmasıdır.
Microsoft 365 Zero Trust destekliyor mu?
Evet. Microsoft 365 mimarisi tamamen Zero Trust prensipleri (Doğrula, En Az Ayrıcalık Ver, İhlal Varsay) üzerine tasarlanmış ve bu modele uygun güvenlik ürünleri barındırır.
Zero Trust ile MFA aynı şey mi?
Hayır. MFA, Zero Trust mimarisinin sadece bir parçasıdır (kimlik doğrulama ayağı). Zero Trust ayrıca cihaz güvenliği, erişim politikaları (Conditional Access) ve veri koruma katmanlarını içerir.
Conditional Access nedir?
Kullanıcının sisteme erişim talebini, cihazın sağlığı, lokasyonu, risk seviyesi gibi şartlara bağlayarak anlık olarak erişime izin veren, engelleyen veya MFA talep eden Entra ID karar motorudur.
Microsoft Entra ID Zero Trust için neden önemlidir?
Çünkü Zero Trust modelinde geleneksel ağ sınırının yerini “Kimlik” almıştır. Entra ID, tüm kaynaklara erişimin kontrol edildiği merkezi kimlik doğrulama otoritesidir.
Microsoft Intune Zero Trust’ta ne işe yarar?
Kurumsal verilere bağlanan cihazların şirketin güvenlik politikalarına (şifreleme, güncellik, antivirüs) uyup uymadığını denetleyerek cihaz güvenliği boyutunu sağlar.
Zero Trust için VPN gerekli mi?
Hayır. Zero Trust, bulut hizmetlerine internet üzerinden güvenli erişim sağladığı için (koşullu erişim ve cihaz denetimi ile) bulut uygulamalarında geleneksel VPN gereksinimini büyük ölçüde ortadan kaldırır.
Zero Trust güvenliği nasıl artırır?
Saldırgan bir kullanıcı parolasını ele geçirse bile, kayıtlı cihaza veya onaylı lokasyona sahip olmadığı için, ya da MFA’yı geçemediği için sistemin derinliklerine ilerlemesini (yatay hareket) engelleyerek artırır.
Zero Trust sadece büyük şirketler için mi?
Hayır. Günümüzde ransomware (fidye yazılımı) veya kimlik avı saldırılarına maruz kalabilecek küçük ve orta ölçekli işletmelerin (KOBİ) de temelde bir Zero Trust mimarisine ihtiyacı vardır.
Zero Trust’a geçiş ne kadar sürer?
Zero Trust, bir defada kurulan bir yazılım değil, sürekli bir süreçtir. Temel kimlik politikalarının (MFA) devreye alınması birkaç hafta sürerken, cihaz yönetimi ve veri etiketleme projeleri aylara yayılabilir.
Microsoft 365 E3 Zero Trust için yeterli mi?
Evet, E3 paketi Zero Trust’a başlamak için gereken Entra ID P1 ve Intune gibi temel yapı taşlarını sunar. Standart bir Zero Trust modelini rahatlıkla kurabilirsiniz.
Microsoft 365 E5 Zero Trust için gerekli mi?
Zorunlu değildir ancak risk bazlı kimlik koruması (Identity Protection), ayrıcalıklı hesap yönetimi (PIM) ve gelişmiş cihaz güvenliği (Defender for Endpoint) gibi otomasyon ve derin koruma özellikleri E5 içerisinde yer alır.
Zero Trust’ta least privilege nedir?
Kullanıcılara veya yöneticilere sistemde kalıcı olarak sınırsız yetki vermek yerine, sadece ihtiyaç duydukları an ve görevlerini yapacakları süre boyunca yeterli yetkinin verilmesidir.
Zero Trust uygulanırken en sık yapılan hata nedir?
Cihaz sağlığını veya erişim risklerini hesaba katmadan sadece MFA’yı aktif etmenin Zero Trust için yeterli olduğunu düşünmektir.
Microsoft 365’te Zero Trust Güvenliğinin Temeli Nerede Başlar?
Bu rehber boyunca detaylandırdığımız üzere; bir çalışanın kim olduğunu doğrulamak (Authentication), o çalışanın her cihaza, her veriye ve her uygulamaya sınırsızca erişebileceği anlamına gelmez. Microsoft 365 ortamında Zero Trust; “Kullanıcı kimliği doğrulanmış mı?”, “Hangi cihazdan bağlanıyor?”, “O cihaz güvenlik politikalarına uyuyor mu?”, “Erişim isteği riskli mi?” ve “Bu kaynağa gerçekten ne kadar yetkiyle ihtiyacı var?” sorularının her bağlantı anında birbiri ardına sorulduğu, sürekli bir değerlendirme döngüsüdür.
Zero Trust bir donanım kutusu, tek bir yazılım lisansı veya sihirli bir düğme değildir. Entra ID ile kimliklerin korunmasıyla başlayan, Intune ile cihazların hizaya getirilmesiyle devam eden, Conditional Access ile erişimin filtrelendiği, Defender ile tehditlerin izlendiği ve Purview ile verinin sınırlandırıldığı mimari bir felsefedir. “Sıfır Güven”, çalışanlarınıza güvenmediğiniz anlamına gelmez; dijital ayak izlerinizin karşı karşıya olduğu modern tehditleri ciddiye aldığınız ve varsayımlara (ağ içinde olmak eşittir güvenli olmak) yer bırakmadığınız anlamına gelir.
Kullanıcı deneyimini bozmadan, iş sürekliliğini kesintiye uğratmadan bu karmaşık politikaları (Conditional Access, PIM, Device Compliance) Microsoft 365 ekosisteminizde doğru kurgulamak, aşamalı ve dikkatli bir planlama gerektirir. Zero Trust yolculuğunuzda, sisteminizi bir anda kilitleme riskini almamak ve doğru lisans yatırımıyla (E3/E5 planlaması) maksimum güvenlik düzeyine (SecOps) ulaşmak için, Microsoft 365 güvenlik yapılandırması ve Zero Trust danışmanlığı alanında profesyonel destek almak organizasyonunuzun geleceği için en değerli adımlardan biri olacaktır.
