Microsoft 365 ve Entra ID Güvenliği Nasıl Sağlanır?

Kurumsal e-posta hesabı artık yalnızca e-posta hesabı değildir.

Aynı kullanıcı hesabı;

Outlook,

Teams,

SharePoint,

OneDrive,

Microsoft 365 uygulamaları,

Azure kaynakları,

kurumsal SaaS platformları

gibi çok sayıda servise erişim sağlayabilir.

Bu nedenle bir Microsoft 365 hesabının ele geçirilmesi yalnızca mailbox erişimi anlamına gelmez.

Saldırgan;

e-posta yazışmalarını okuyabilir,

SharePoint dokümanlarına ulaşabilir,

OneDrive verilerini indirebilir,

Teams mesajlarını inceleyebilir,

başka kullanıcılara phishing mesajları gönderebilir,

mail forwarding rule oluşturabilir,

OAuth uygulaması yetkilendirebilir,

aktif session'ları kötüye kullanabilir

ve daha yüksek yetkilere ulaşmaya çalışabilir.

Bu nedenle modern kurumsal güvenlikte Microsoft 365 Security ve Microsoft Entra ID Security, sistem ve bulut güvenliğinin en kritik alanlarından biridir.

Buradaki temel yaklaşım sadece:

“MFA açık mı?”

sorusunu sormak değildir.

Daha doğru sorular şunlardır:

Hangi kullanıcı hangi uygulamaya erişebiliyor?

Hangi hesap privileged?

Conditional Access politikaları doğru mu?

Şüpheli sign-in davranışı izleniyor mu?

OAuth uygulamaları kontrol ediliyor mu?

Session token güvenliği nasıl sağlanıyor?

Global Administrator hesapları nasıl korunuyor?

Microsoft 365 güvenliği artık yalnızca parola güvenliği değil, tam anlamıyla bir Cloud Identity Security problemidir.

Microsoft 365 Güvenliği Nedir?

Microsoft 365 Security, Microsoft 365 ekosistemindeki kullanıcıların, e-postaların, dosyaların, kimliklerin, uygulamaların ve erişim süreçlerinin güvenli şekilde korunmasını ifade eder.

Bu kapsam;

• Exchange Online,
• Teams,
• SharePoint Online,
• OneDrive,
• Microsoft Entra ID,
• Microsoft Defender,
• Conditional Access,
• MFA,
• OAuth uygulamaları,
• Identity Protection

gibi birçok bileşeni içerir.

Microsoft 365 güvenliği yalnızca mail güvenliği değildir.

Çünkü kimlik ele geçirildiğinde saldırgan aynı hesapla çok sayıda cloud kaynağına ulaşabilir.

Microsoft Entra ID Nedir?

Microsoft Entra ID, Microsoft'un cloud tabanlı kimlik ve erişim yönetimi servisidir.

Önceki adı Azure Active Directory – Azure AD idi.

Entra ID;

kullanıcıları,

grupları,

uygulama erişimlerini,

rolleri,

authentication süreçlerini,

Conditional Access politikalarını

yönetebilir.

Bu nedenle Entra ID, Microsoft 365 güvenliğinin temel kimlik katmanıdır.

Entra ID ile Active Directory Aynı Şey midir?

Hayır.

İkisi birbirine bağlı olabilir ancak aynı teknoloji değildir.

Active Directory Domain Services

On-premise Windows domain yapısıdır.

Microsoft Entra ID

Cloud identity ve access management platformudur.

Hybrid yapılarda kullanıcılar Active Directory'den Entra ID'ye senkronize edilebilir.

Bu nedenle saldırgan açısından iki ortam arasında ilişki bulunabilir.

Hybrid Identity Nedir?

Hybrid Identity, on-premise Active Directory ile Microsoft Entra ID'nin birlikte kullanıldığı kimlik mimarisidir.

Kullanıcı;

domain hesabıyla bilgisayara giriş yapabilir,

aynı kimlikle Microsoft 365 kullanabilir,

cloud uygulamalarına erişebilir.

Bu büyük operasyonel kolaylık sağlar.

Ancak güvenlik açısından iki ortamın birlikte değerlendirilmesini gerektirir.

Bir taraftaki compromise diğer tarafta etki oluşturabilir.

Microsoft 365 Hesapları Neden Saldırganların Hedefidir?

Çünkü tek bir hesap çok yüksek değere sahip olabilir.

Bir çalışan mailbox'ında;

fatura,

sözleşme,

müşteri bilgisi,

finans yazışması,

şifre sıfırlama mesajı,

toplantı bilgileri

bulunabilir.

Buna ek olarak aynı hesap OneDrive ve SharePoint erişimine sahip olabilir.

Bu nedenle saldırgan için Microsoft 365 hesabı bazen sunucu hesabından bile daha değerli olabilir.

Business Email Compromise Nedir?

Business Email Compromise – BEC, saldırganın kurumsal e-posta hesabını ele geçirerek veya taklit ederek finansal dolandırıcılık gerçekleştirmeye çalıştığı saldırı türüdür.

Örneğin saldırgan;

CFO,

CEO,

tedarikçi,

finans çalışanı

gibi davranabilir.

Sahte ödeme talebi gönderebilir.

Fatura üzerindeki banka hesabını değiştirebilir.

Tedarikçiye farklı hesap bilgisi iletebilir.

Bu nedenle Microsoft 365 Security, finansal dolandırıcılık riskleriyle doğrudan ilişkilidir.

Account Takeover Nedir?

Account Takeover – ATO, saldırganın kullanıcı hesabının kontrolünü ele geçirmesidir.

Microsoft 365 tarafında bu;

parola ele geçirilmesi,

phishing,

session theft,

OAuth abuse,

MFA manipulation

gibi yöntemlerle gerçekleşebilir.

Bir ATO olayı sonrasında sadece parola değiştirmek her zaman yeterli olmayabilir.

Session ve application consent de değerlendirilmelidir.

MFA Nedir?

Multi-Factor Authentication – MFA, kullanıcı girişinde parolaya ek olarak ikinci veya daha fazla doğrulama faktörü kullanılmasını sağlar.

Örneğin;

mobil uygulama onayı,

donanımsal güvenlik anahtarı,

sertifika,

biyometrik doğrulama

kullanılabilir.

MFA, credential theft saldırılarının etkisini önemli ölçüde azaltır.

Ancak tamamen ortadan kaldırmaz.

MFA Varsa Hesap Ele Geçirilemez mi?

Hayır.

Saldırgan farklı teknikleri kullanabilir.

Örneğin;

MFA fatigue,

session cookie theft,

adversary-in-the-middle phishing,

OAuth consent abuse,

legacy authentication

gibi yöntemler MFA'nın etrafından dolaşmaya çalışabilir.

Bu nedenle modern Microsoft 365 güvenliği:

MFA + Conditional Access + Session Security + Identity Monitoring

şeklinde düşünülmelidir.

MFA Fatigue Nedir?

MFA Fatigue, saldırganın kullanıcıya art arda MFA onay bildirimi göndererek yanlışlıkla veya bıkkınlık sonucu onay vermesini sağlamaya çalıştığı saldırı yaklaşımıdır.

Kullanıcı sürekli:

“Giriş yapmak istiyor musunuz?”

bildirimi alabilir.

Sonunda istemeden onay verebilir.

Bu nedenle sadece push notification tabanlı MFA yerine daha güçlü authentication yöntemleri değerlendirilebilir.

Number Matching Nedir?

MFA push yöntemlerinde Number Matching, login ekranında gösterilen numaranın authenticator uygulamasında girilmesini gerektiren yöntemdir.

Bu, basit “Approve / Deny” modeline göre MFA fatigue riskini azaltabilir.

Ancak phishing-resistant authentication kadar güçlü değildir.

Phishing-Resistant MFA Nedir?

Phishing-Resistant MFA, kullanıcının doğrulama bilgisinin sahte login sayfasına taşınmasını zorlaştıran authentication yöntemlerini ifade eder.

Örneğin;

FIDO2 security key,

passkey,

certificate-based authentication

bu kategoriye yaklaşabilir.

Özellikle privileged hesaplarda güçlü şekilde değerlendirilmelidir.

Passkey Nedir?

Passkey, parola kullanımını azaltan modern authentication yaklaşımıdır.

Cryptographic key tabanlı çalışabilir ve phishing saldırılarına karşı klasik password + OTP yöntemlerinden daha dayanıklı olabilir.

Kurumsal identity security stratejilerinde passwordless authentication giderek daha fazla önem kazanmaktadır.

Conditional Access Nedir?

Conditional Access, kullanıcının erişim isteğini farklı risk ve koşullara göre değerlendiren politika mekanizmasıdır.

Örneğin;

kullanıcı kimliği,

cihaz durumu,

lokasyon,

uygulama,

sign-in risk,

authentication strength

gibi koşullar değerlendirilebilir.

Sonuç olarak;

erişim verilebilir,

MFA istenebilir,

erişim engellenebilir,

compliant device şartı konabilir.

Bu nedenle Conditional Access, Microsoft 365 ve Entra ID güvenliğinin temel kontrollerinden biridir.

Conditional Access Nasıl Çalışır?

Basit bir örnek:

Kullanıcı Türkiye'den, kurumsal cihazdan ve normal davranışla giriş yapıyor.

→ Erişim verilebilir.

Aynı kullanıcı kısa süre sonra beklenmeyen bir lokasyondan riskli login gerçekleştiriyor.

→ MFA veya ek kontrol istenebilir.

Privileged kullanıcı unmanaged cihazdan bağlanmaya çalışıyor.

→ Erişim engellenebilir.

Bu yaklaşım statik parola güvenliğinden daha dinamik bir model sağlar.

Named Locations Nedir?

Conditional Access içerisinde belirli network veya lokasyonlar Named Locations olarak tanımlanabilir.

Örneğin kurumsal ofis IP'leri güvenilir olarak işaretlenebilir.

Ancak “güvenilir IP” kavramı sınırsız güven anlamına gelmemelidir.

Bir ofis cihazı ele geçirilebilir.

Bu nedenle location tek güvenlik sinyali olmamalıdır.

Impossible Travel Nedir?

Impossible Travel, aynı kullanıcının fiziksel olarak mümkün olmayacak kadar kısa sürede birbirinden uzak lokasyonlardan giriş yapmasıdır.

Örneğin;

09:00 İstanbul

09:20 New York

gibi.

Bu davranış account compromise göstergesi olabilir.

Ancak VPN, proxy veya cloud egress noktaları false positive oluşturabilir.

Bu nedenle bağlam önemlidir.

Sign-In Risk Nedir?

Entra ID Identity Protection benzeri sistemler giriş davranışına göre risk seviyesi oluşturabilir.

Örneğin;

anonymizing IP,

atypical travel,

malicious IP,

password spray ilişkisi

gibi sinyaller kullanılabilir.

Bu risk Conditional Access ile birleştirilerek otomatik aksiyon alınabilir.

User Risk ile Sign-In Risk Arasındaki Fark

Sign-In Risk

Belirli bir login işleminin risk seviyesidir.

User Risk

Kullanıcının hesabının genel olarak compromise olmuş olma ihtimalini ifade eder.

Bu ayrım otomatik identity response politikaları açısından önemlidir.

Risk-Based Conditional Access Nedir?

Conditional Access politikasının identity risk sinyalleriyle birlikte çalışmasıdır.

Örneğin:

High sign-in risk → access block.

Medium risk → phishing-resistant MFA.

High user risk → password reset veya account remediation.

Bu yaklaşım adaptif identity security sağlar.

Legacy Authentication Nedir?

Legacy authentication, modern MFA ve Conditional Access mekanizmalarını tam olarak desteklemeyen eski authentication protokollerini ifade edebilir.

Örneğin eski mail client veya protokol davranışları bu kapsamda değerlendirilebilir.

Legacy authentication saldırgan için önemlidir çünkü bazı modern kontrolleri bypass etmeye fırsat sağlayabilir.

Mümkün olduğunca kullanım keşfedilmeli ve azaltılmalıdır.

Basic Authentication Neden Risklidir?

Basic Authentication gibi eski authentication yöntemleri kullanıcı adı ve parola temelli yapı nedeniyle password spraying ve credential attack'lara daha açık olabilir.

Modern authentication ve MFA destekleyen yöntemlere geçiş tercih edilmelidir.

Ancak legacy uygulamalar nedeniyle geçiş öncesi dependency analizi yapılmalıdır.

Microsoft 365'te Session Nedir?

Kullanıcı başarılı şekilde giriş yaptıktan sonra her işlemde yeniden parola girmez.

Bunun yerine belirli session veya token mekanizmaları kullanılır.

Bu kullanıcı deneyimi için gereklidir.

Ancak session verisi saldırgan tarafından ele geçirilirse parola ve bazı durumlarda MFA tekrar sorulmadan erişim riski oluşabilir.

Bu nedenle modern identity security'de session protection kritik hale gelmiştir.

Session Hijacking Nedir?

Session Hijacking, aktif kullanıcı session bilgisinin ele geçirilerek yetkisiz erişim için kullanılmasıdır.

Örneğin saldırgan geçerli session cookie veya token elde ederse kullanıcı gibi davranmaya çalışabilir.

Bu nedenle yalnızca:

“Parolayı değiştirdik.”

demek yeterli olmayabilir.

Aktif session'ların revoke edilmesi de gerekebilir.

Token Theft Nedir?

Modern cloud authentication'da token'lar kimlik doğrulama sonucunda erişim sağlamak için kullanılabilir.

Token Theft, bu token'ların saldırgan tarafından ele geçirilmesini ifade eder.

Infostealer malware,

compromised browser,

phishing proxy

gibi yöntemler risk oluşturabilir.

Bu nedenle endpoint security ile identity security birbirinden ayrı düşünülmemelidir.

Adversary-in-the-Middle Phishing Nedir?

Adversary-in-the-Middle – AiTM phishing, saldırganın gerçek login servisi ile kullanıcı arasında proxy gibi davranarak authentication sürecini aracılık etmesi yaklaşımıdır.

Kullanıcı gerçek Microsoft login ekranına benzeyen sayfada credential ve MFA işlemini tamamlayabilir.

Saldırgan session bilgisini ele geçirmeye çalışabilir.

Bu nedenle phishing-resistant authentication yöntemleri giderek daha önemli hale gelmektedir.

OAuth Nedir?

OAuth, uygulamaların kullanıcı parolasını doğrudan almadan belirli kaynaklara yetkili erişim sağlamasına imkan veren authorization framework'üdür.

Microsoft 365 ortamında birçok uygulama OAuth kullanabilir.

Örneğin bir uygulama;

mail okuma,

takvim,

dosyalar

için izin isteyebilir.

Bu yapı meşru ve gereklidir.

Ancak yanlış yönetildiğinde güvenlik riski oluşturabilir.

OAuth Consent Phishing Nedir?

Saldırgan kullanıcıyı kötü amaçlı bir uygulamaya izin vermeye ikna edebilir.

Kullanıcı uygulamaya örneğin;

mail okuma,

dosyalara erişim,

profile erişimi

izni verebilir.

Bu durumda saldırgan parolayı ele geçirmek zorunda olmayabilir.

Yetkilendirilmiş uygulama üzerinden erişim sağlayabilir.

Bu yaklaşım OAuth Consent Phishing olarak adlandırılabilir.

OAuth Uygulamaları Nasıl Kontrol Edilmelidir?

Kurum şu sorulara cevap verebilmelidir:

Hangi uygulamalar tenant'a bağlı?

Hangi permission'ları aldılar?

Kim consent verdi?

Admin consent var mı?

Uygulama hâlâ kullanılıyor mu?

Publisher güvenilir mi?

Bu nedenle App Governance ve OAuth permission review önemlidir.

Admin Consent Nedir?

Bazı OAuth permission'ları yalnızca administrator tarafından tenant genelinde onaylanabilir.

Bu işlem Admin Consent olarak adlandırılır.

Özellikle yüksek privilege sağlayan application permission'lar dikkatle incelenmelidir.

Çünkü yanlış uygulama çok sayıda kullanıcı verisine erişebilir.

Enterprise Application Güvenliği

Entra ID içerisinde üçüncü taraf veya kurum içi uygulamalar Enterprise Application olarak bulunabilir.

Bu uygulamalar;

Single Sign-On,

OAuth,

SAML

gibi yöntemlerle çalışabilir.

Kullanılmayan veya eski uygulamalar temizlenmelidir.

Aksi halde unutulmuş application registration saldırı yüzeyi oluşturabilir.

Application Registration Nedir?

Developer veya administrator'lar Entra ID içerisinde uygulama kaydı oluşturabilir.

Bu uygulamalar;

client ID,

secret,

certificate,

permission

kullanabilir.

Yanlış yapılandırılmış application registration özellikle yüksek API permission'ları varsa ciddi risk oluşturabilir.

Client Secret Neden Risklidir?

Client secret uygulamanın credential'ıdır.

Eğer secret;

Git repository,

CI/CD log,

script,

configuration file

içerisinde açık olarak bulunursa saldırgan tarafından ele geçirilebilir.

Bu nedenle secret management, rotation ve mümkün olduğunda certificate/managed identity gibi alternatifler değerlendirilmelidir.

Managed Identity Nedir?

Microsoft Azure ortamında Managed Identity, uygulamaların statik kullanıcı adı veya secret saklamadan Azure kaynaklarına erişmesine yardımcı olabilir.

Credential yönetimini kolaylaştırır.

Ancak Managed Identity'ye verilen IAM permission'ları yine minimum yetki prensibine göre düzenlenmelidir.

Secret olmaması gereğinden fazla yetkinin güvenli olduğu anlamına gelmez.

Global Administrator Nedir?

Global Administrator, Entra ID tenant üzerinde çok geniş yönetim yetkisine sahip roldür.

Bu nedenle saldırgan için son derece değerli hedeftir.

Global Administrator sayısı minimum tutulmalıdır.

Günlük kullanıcı hesapları kalıcı Global Admin olmamalıdır.

Global Administrator Hesapları Nasıl Korunmalıdır?

Örneğin;

ayrı privileged account,

phishing-resistant MFA,

PAM/PIM,

Conditional Access,

dedicated admin workstation,

log monitoring

kullanılabilir.

Ayrıca bu hesaplar günlük e-posta veya internet kullanımı için tercih edilmemelidir.

Privileged Identity Management – PIM Nedir?

Microsoft Entra Privileged Identity Management – PIM, yüksek yetkili rollerin sürekli aktif tutulması yerine gerektiğinde etkinleştirilmesine yardımcı olabilir.

Kullanıcı;

role activation isteği yapar,

MFA tamamlar,

gerekirse onay alır,

belirli süre role sahip olur.

Bu yaklaşım Just-in-Time Privileged Access sağlar.

Eligible Role ile Active Role Arasındaki Fark

PIM içerisinde kullanıcı belirli role:

Eligible

olabilir.

Bu, rolü gerektiğinde aktive edebileceği anlamına gelir.

Active

ise rolün şu anda kullanıcı üzerinde aktif olduğu anlamına gelir.

Bu ayrım standing privilege'ın azaltılması açısından önemlidir.

Break Glass Account Nedir?

Break Glass Account, normal authentication veya Conditional Access sistemlerinde ciddi problem oluştuğunda acil yönetim erişimi için kullanılan emergency account'tur.

Bu hesaplar;

çok sınırlı sayıda,

güçlü güvenlik altında,

sürekli monitoring ile

yönetilmelidir.

Normal operasyon için kullanılmamalıdır.

Break Glass Hesabı MFA'sız mı Olmalı?

Emergency account tasarımı kurumun risk modeline bağlıdır.

Amaç tenant'ın tamamını kilitleyen bir kimlik doğrulama problemi yaşandığında acil erişimin mümkün olmasıdır.

Bu nedenle hesap tasarımı Microsoft'un güncel best practice'leri ve kurumun tehdit modeli dikkate alınarak yapılmalıdır.

Önemli olan hesabın varlığının ve kullanımının son derece sıkı izlenmesidir.

Mailbox Forwarding Neden Kritik?

Bir saldırgan mailbox ele geçirdikten sonra gelen e-postaları dış adrese yönlendiren forwarding rule oluşturabilir.

Kullanıcının parolası daha sonra değiştirilse bile saldırgan belirli e-postaları almaya devam edebilir.

Bu nedenle account compromise investigation sırasında;

mail forwarding,

inbox rules,

delegation

kontrol edilmelidir.

Inbox Rule Attack Nedir?

Saldırgan mailbox içerisinde belirli mesajları;

silmek,

gizlemek,

başka klasöre taşımak,

forward etmek

için rule oluşturabilir.

Örneğin banka veya güvenlik bildirimleri otomatik olarak silinebilir.

Bu nedenle beklenmeyen mailbox rule creation SOC tarafından izlenebilir.

External Forwarding Kapatılmalı mı?

İş ihtiyacına göre dış forwarding sınırlandırılabilir.

Kurumsal e-postanın otomatik olarak harici mailbox'a yönlendirilmesi veri sızıntısı riski oluşturabilir.

Bu nedenle external forwarding policy kurum bazında değerlendirilmelidir.

Mailbox Delegation Nedir?

Başka kullanıcının;

Read and Manage,

Send As,

Send on Behalf

gibi mailbox yetkileri olabilir.

Bunlar meşru iş ihtiyaçları için kullanılabilir.

Ancak yanlış delegation saldırganın fark edilmeden başka kullanıcı adına mail göndermesine yardımcı olabilir.

Bu nedenle delegation envanteri ve access review önemlidir.

Shared Mailbox Güvenliği

Finance, HR, Sales gibi ekipler shared mailbox kullanabilir.

Bu mailbox'lara erişen kullanıcıların düzenli olarak gözden geçirilmesi gerekir.

Çalışan departmandan ayrılmış olabilir ancak erişimi hâlâ devam ediyor olabilir.

Joiner-Mover-Leaver süreci shared mailbox yetkilerini de kapsamalıdır.

Microsoft 365 Phishing Koruması Nasıl Sağlanır?

Tek bir kontrol yeterli değildir.

Örneğin;

email authentication,

anti-phishing,

Safe Links,

Safe Attachments,

user awareness,

MFA,

Conditional Access

birlikte kullanılabilir.

Ama phishing güvenliği yalnızca mail gateway'de çözülmez.

Saldırgan sosyal medya veya başka kanallardan da phishing linki gönderebilir.

Bu nedenle identity tarafının dayanıklı olması gerekir.

SPF Nedir?

Sender Policy Framework – SPF, belirli domain adına hangi mail sunucularının e-posta göndermeye yetkili olduğunu belirtmeye yardımcı olur.

Email spoofing riskini azaltan kontrollerden biridir.

Ancak SPF tek başına yeterli değildir.

DKIM ve DMARC ile birlikte değerlendirilmelidir.

DKIM Nedir?

DomainKeys Identified Mail – DKIM, gönderilen e-postanın cryptographic signature ile doğrulanmasına yardımcı olur.

Mesajın belirli domain adına yetkili sistem tarafından gönderildiğini ve aktarım sırasında değiştirilmediğini doğrulamaya katkı sağlar.

DMARC Nedir?

Domain-based Message Authentication, Reporting and Conformance – DMARC, SPF ve DKIM sonuçlarını domain policy ile birleştirir.

Kurum;

none,

quarantine,

reject

gibi politika uygulayabilir.

DMARC ayrıca raporlama sağlayabilir.

Bu sayede kurum kendi domain'inin spoof edilmesini azaltabilir.

DMARC “p=none” Yeterli midir?

p=none genellikle monitoring aşaması için kullanılabilir.

Ancak spoofing'i aktif olarak engellemez.

Kurum doğru SPF/DKIM yapısını doğruladıktan sonra risk ve operasyonel ihtiyaçlarına göre daha güçlü policy'lere geçebilir.

Geçiş kontrollü yapılmalıdır.

Anti-Phishing Policy Nedir?

Microsoft 365 tarafında impersonation ve phishing risklerine karşı farklı koruma politikaları uygulanabilir.

Özellikle;

executive impersonation,

domain impersonation,

user impersonation

senaryoları önemli olabilir.

CEO, CFO ve finans yöneticileri gibi kullanıcılar daha yüksek koruma profiline alınabilir.

VIP User Monitoring Neden Önemlidir?

Saldırganlar kritik yöneticileri hedefleyebilir.

CEO,

CFO,

yönetim kurulu,

finans ekibi

gibi kullanıcılar BEC açısından yüksek değerli hedefler olabilir.

Bu nedenle bu hesaplar için daha sıkı sign-in ve mail security politikaları uygulanabilir.

Microsoft Teams Üzerinden Phishing Mümkün mü?

Evet.

Phishing yalnızca e-posta üzerinden gerçekleşmez.

Saldırgan ele geçirilmiş veya harici hesaplar üzerinden Teams mesajı göndermeye çalışabilir.

Bu nedenle external communication ve guest access politikaları da güvenlik açısından değerlendirilmelidir.

Guest User Nedir?

Microsoft 365 ve Entra ID ortamında harici kullanıcılar tenant'a guest olarak eklenebilir.

Bu iş birliği için faydalıdır.

Ancak yıllar önce eklenmiş ve artık kullanılmayan guest hesaplar risk oluşturabilir.

Bu nedenle guest access düzenli olarak review edilmelidir.

B2B Collaboration Güvenliği

Harici iş ortakları SharePoint, Teams veya uygulamalara erişebilir.

Bu nedenle;

guest lifecycle,

access review,

MFA,

Conditional Access,

data sharing policy

birlikte değerlendirilmelidir.

Third-party identity riskleri modern cloud security'nin önemli parçalarındandır.

SharePoint ve OneDrive Güvenliği Neden Önemlidir?

Microsoft 365 hesapları genellikle kurumsal dokümanlara erişim sağlar.

Yanlış sharing policy nedeniyle;

müşteri bilgileri,

sözleşmeler,

teklifler,

finans dosyaları

harici kullanıcılarla paylaşılabilir.

Bu nedenle identity security ile data security birlikte ele alınmalıdır.

Anonymous Sharing Nedir?

Bazı dosyalar “Anyone with the link” benzeri mekanizmalarla paylaşılabilir.

Bu durumda linki bilen kişi authentication olmadan dosyaya erişebilir.

İş ihtiyacına göre bu özellik sınırlanabilir.

Özellikle hassas veri içeren SharePoint sitelerinde daha kontrollü sharing politikaları uygulanmalıdır.

Sensitivity Label Nedir?

Sensitivity Labels, verilerin hassasiyet seviyesine göre sınıflandırılması ve koruma politikalarının uygulanmasına yardımcı olabilir.

Örneğin;

Public,

Internal,

Confidential,

Highly Confidential

gibi sınıflar kullanılabilir.

Bu etiketler encryption veya sharing restriction gibi kontrollerle ilişkilendirilebilir.

DLP Microsoft 365 Güvenliğinde Nasıl Kullanılır?

Data Loss Prevention – DLP, hassas verilerin yetkisiz paylaşımını tespit etmeye ve önlemeye yardımcı olabilir.

Örneğin;

kişisel veri,

finans bilgisi,

kredi kartı,

kimlik numarası

gibi veri tipleri izlenebilir.

DLP identity compromise sonrasında oluşabilecek data exfiltration riskini azaltan ek bir katmandır.

Microsoft 365 Audit Log Neden Önemlidir?

Audit log sayesinde;

login,

mailbox change,

file access,

admin action,

sharing,

role change

gibi aktiviteler incelenebilir.

Incident Response sırasında saldırganın ne yaptığını anlamak için kritik veri kaynağıdır.

Bu nedenle gerekli audit ve retention ayarları önceden planlanmalıdır.

Unified Audit Log Nedir?

Microsoft 365 servislerinden farklı aktivitelerin merkezi olarak incelenmesine olanak sağlayan audit altyapısıdır.

Örneğin Exchange, SharePoint veya Entra aktiviteleri üzerinden olay analizi yapılabilir.

SOC ve DFIR süreçleri için önemli visibility sağlar.

Entra Sign-In Logs Neden Önemlidir?

Sign-in loglar;

kullanıcı,

IP,

lokasyon,

uygulama,

authentication result,

Conditional Access result

gibi bilgileri sağlayabilir.

Bir account takeover araştırmasının temel kaynaklarından biridir.

Audit Logs ile Sign-In Logs Arasındaki Fark

Sign-In Logs

Authentication işlemlerini gösterir.

Audit Logs

Tenant içerisinde yapılan yönetimsel ve konfigürasyon işlemlerini gösterebilir.

Örneğin kullanıcı giriş yaptıktan sonra yeni Global Admin role atadıysa iki farklı log kaynağını birlikte incelemek gerekir.

SOC Microsoft 365 İçin Neleri İzlemeli?

Örnek use case'ler:

çok sayıda başarısız login,

password spraying,

riskli login,

beklenmeyen lokasyon,

yeni MFA method ekleme,

privileged role activation,

mail forwarding creation,

OAuth consent,

new app registration,

external file sharing.

Bu use case'ler kurumun risk profiline göre özelleştirilmelidir.

Yeni MFA Method Eklenmesi Neden Kritik?

Saldırgan hesabı ele geçirdikten sonra kendi authentication method'unu eklemeye çalışabilir.

Bu durumda kullanıcı parolayı değiştirirse bile saldırgan başka doğrulama yöntemi üzerinden erişim sağlamaya çalışabilir.

Bu nedenle beklenmeyen MFA registration veya authentication method değişiklikleri izlenmelidir.

Password Reset Sonrası Ne Kontrol Edilmeli?

Account compromise sonrasında yalnızca parola reset yeterli olmayabilir.

Ayrıca;

session revoke,

MFA methods,

OAuth consent,

mailbox rules,

forwarding,

delegated access,

application passwords,

recent role changes

kontrol edilmelidir.

Bu daha kapsamlı bir Identity Incident Response yaklaşımıdır.

Session Revoke Neden Gereklidir?

Kullanıcı parolasını değiştirse bile daha önce oluşturulmuş bazı session'lar belirli koşullarda bir süre devam edebilir.

Bu nedenle compromise durumunda aktif session ve refresh token'ların revoke edilmesi gerekebilir.

Amaç saldırganın mevcut session ile erişimi sürdürmesini engellemektir.

Continuous Access Evaluation Nedir?

Continuous Access Evaluation – CAE, belirli kritik güvenlik olaylarında session erişiminin daha hızlı yeniden değerlendirilmesine yardımcı olan mekanizmalardan biridir.

Örneğin kullanıcı disable edilirse veya risk seviyesi değişirse erişimin daha hızlı kesilmesi mümkün olabilir.

Bu yaklaşım modern cloud session security için önemlidir.

Device Compliance Nedir?

Conditional Access yalnızca kullanıcıya değil cihaza da bakabilir.

Örneğin erişim için cihazın;

managed,

compliant,

encrypted,

güncel

olması şartı getirilebilir.

Bu şekilde credential doğru olsa bile güvenilmeyen cihaz üzerinden erişim sınırlandırılabilir.

Intune ile Entra ID Güvenliği Nasıl Birleşir?

Microsoft Intune cihazların güvenlik ve compliance durumunu yönetebilir.

Conditional Access bu compliance bilgisini kullanabilir.

Örneğin:

Compliant corporate device → erişim.

Unmanaged device → sınırlı erişim veya block.

Bu yaklaşım identity + device security birleşimidir.

BYOD Microsoft 365 Güvenliğinde Nasıl Yönetilir?

Bring Your Own Device – BYOD, çalışanların kişisel cihazlardan kurumsal servislere erişmesini ifade eder.

Bu durumda;

browser-only access,

download restriction,

app protection policy,

MFA,

Conditional Access

gibi kontroller düşünülebilir.

Amaç kişisel cihazı tamamen kurum cihazı gibi yönetmeden kurumsal veriyi korumaktır.

Token Protection Nedir?

Modern identity platformlarında token'ın yalnızca belirli cihaz veya session bağlamında kullanılmasını sağlayan ek güvenlik mekanizmaları geliştirilmektedir.

Amaç çalınan token'ın farklı cihazda yeniden kullanılmasını zorlaştırmaktır.

Bu yaklaşım özellikle session hijacking riskine karşı önemlidir.

Identity Secure Score Nedir?

Microsoft ekosisteminde farklı security posture metrikleri kullanılabilir.

Ancak herhangi bir skor tek başına güvenlik seviyesi değildir.

Örneğin skor yüksek olabilir ancak kritik Global Admin hesabının güvenliği zayıf olabilir.

Bu nedenle posture score;

risk,

business context,

attack path

ile birlikte yorumlanmalıdır.

Entra ID Attack Path Nedir?

Cloud identity ortamında da kullanıcı, role, application ve permission ilişkilerinden oluşan saldırı yolları bulunabilir.

Örneğin:

Normal User

↓

Application Owner

↓

Credential Creation

↓

High-Privilege API Permission

↓

Critical Resource

gibi zincirler oluşabilir.

Bu nedenle cloud identity'de de Attack Path Analysis önem kazanmaktadır.

Role Assignment Neden Sürekli İzlenmelidir?

Bir kullanıcının;

Global Administrator,

Privileged Role Administrator,

Application Administrator

gibi rollere atanması yüksek etkili olaydır.

Bu değişiklikler SOC tarafından izlenmeli ve change kaydıyla doğrulanmalıdır.

Least Privilege Entra ID'de Nasıl Uygulanır?

Bir kullanıcıya “iş kolay olsun” diye Global Admin vermek yerine göreve özel rol kullanılmalıdır.

Örneğin;

Exchange işlemleri için Exchange rolü,

user management için uygun identity rolü

kullanılabilir.

Bu yaklaşım compromise impact'i sınırlar.

Access Review Nedir?

Access Review, kullanıcıların, guest hesapların ve privileged rollerin gerçekten hâlâ gerekli olup olmadığının düzenli olarak gözden geçirilmesidir.

Örneğin proje tamamlandıktan sonra harici danışmanın SharePoint erişimi kaldırılmalıdır.

Bu süreç privilege creep ve stale access riskini azaltır.

Identity Governance Nedir?

Identity Governance, kullanıcı erişimlerinin yaşam döngüsünü, onay süreçlerini ve access review'larını yöneten daha geniş güvenlik alanıdır.

Joiner-Mover-Leaver,

access package,

entitlement,

role review

gibi süreçleri kapsayabilir.

Identity security yalnızca saldırı tespitinden değil, doğru erişim yönetişiminden de oluşur.

Microsoft 365 Incident Response Nasıl Yapılır?

Bir hesap compromise olduğunda süreç genel olarak şu alanları değerlendirebilir:

Account Containment

Hesap güvenliği sağlanır.

Session Revocation

Aktif session'lar değerlendirilir.

Authentication Review

MFA ve authentication methods incelenir.

Mailbox Review

Forwarding ve inbox rule kontrol edilir.

OAuth Review

Uygulama consent'leri incelenir.

Audit Review

Saldırganın aktiviteleri analiz edilir.

Data Exposure

Erişilen veya indirilen dosyalar değerlendirilir.

Bu yaklaşım yalnızca password reset'ten çok daha kapsamlıdır.

Microsoft 365 Compromise Assessment Nedir?

Microsoft 365 Compromise Assessment, tenant içerisinde geçmiş veya aktif kompromizasyon belirtilerinin araştırılmasıdır.

Örneğin;

riskli sign-in,

mailbox rule,

suspicious OAuth,

privileged role change,

external sharing,

abnormal downloads

incelenebilir.

Amaç “şu anda alarm var mı?” sorusundan daha geniştir.

“Saldırgan daha önce içeride bulunmuş olabilir mi?”

sorusuna cevap arar.

Threat Hunting Microsoft 365'te Yapılır mı?

Evet.

Threat Hunting yalnızca endpoint üzerinde yapılmaz.

Cloud telemetry üzerinde de uygulanabilir.

Örneğin hipotez:

“Bir saldırgan compromised hesabı kullanarak mail forwarding oluşturmuş olabilir.”

Ardından audit ve Exchange kayıtlarında geçmişe dönük arama yapılabilir.

Bu şekilde cloud threat hunting gerçekleştirilebilir.

Microsoft 365 ile SIEM Entegrasyonu Neden Önemlidir?

Identity ve mail telemetry'sinin sadece Microsoft portalında bulunması SOC görünürlüğünü parçalayabilir.

SIEM entegrasyonu sayesinde;

Entra sign-in,

audit,

Defender,

mail security

olayları diğer sistemlerle korele edilebilir.

Örneğin:

Risky Sign-In

EDR infostealer alert

Mail Forwarding Creation

aynı incident altında birleşebilir.

Bu çok daha güçlü bir saldırı sinyalidir.

XDR Microsoft 365 Güvenliğinde Nasıl Kullanılır?

XDR;

identity,

endpoint,

email,

cloud application

telemetry'sini birlikte analiz edebilir.

Örneğin phishing maili alan kullanıcıdan başlayan saldırı;

mail,

endpoint,

identity

katmanlarında takip edilebilir.

Bu nedenle Microsoft 365 güvenliği yalnızca Entra portalı üzerinden yönetilmemelidir.

Uçtan uca visibility önemlidir.

Zero Trust Microsoft 365'te Nasıl Uygulanır?

Zero Trust yaklaşımında hiçbir login yalnızca doğru parola nedeniyle otomatik güvenilir sayılmaz.

Şunlar birlikte değerlendirilir:

Who?

Kullanıcı kim?

Device?

Hangi cihaz?

Where?

Nereden bağlanıyor?

Risk?

Sign-in riskli mi?

Resource?

Hangi veriye erişiyor?

Authentication Strength?

Hangi MFA yöntemi kullanıldı?

Bu model Microsoft 365 identity security'nin modern temelini oluşturur.

Microsoft 365 Güvenlik Değerlendirmesi Nasıl Yapılır?

Profesyonel bir Microsoft 365 Security Assessment şu alanları kapsayabilir:

Tenant Architecture

Tenant ve domain yapısı.

Identity & Authentication

MFA, Conditional Access, sign-in politikaları.

Privileged Roles

Global Admin ve diğer yönetim rolleri.

OAuth & Applications

Enterprise apps ve permission'lar.

Exchange Security

Mailbox, forwarding ve mail güvenliği.

SharePoint / OneDrive

Sharing ve veri erişimleri.

Audit & Monitoring

Loglama ve SOC entegrasyonu.

Device Security

Managed ve unmanaged erişimler.

Incident Response

Cloud account compromise süreçleri.

Bu yaklaşım yalnızca Secure Score kontrolünden daha geniş olmalıdır.

Microsoft 365 Security Assessment ile Pentest Aynı Şey midir?

Hayır.

Microsoft 365 Security Assessment ağırlıklı olarak;

konfigürasyon,

identity,

permission,

policy,

monitoring

değerlendirmesidir.

Pentest ise kontrollü saldırı senaryoları üzerinden istismar edilebilirliği test eder.

Her iki çalışma farklı bilgiler sağlar ve birbirini tamamlayabilir.

Microsoft 365 Güvenlik Raporunda Neler Olmalıdır?

Profesyonel rapor şu bölümleri içerebilir:

Executive Summary

Yönetim için risk özeti.

Identity Security

MFA ve Conditional Access.

Privileged Access

Global Admin ve PIM.

Application Security

OAuth ve application permission'ları.

Email Security

Phishing, BEC ve forwarding riskleri.

Data Sharing

SharePoint ve OneDrive kontrolleri.

Session Security

Token ve session riskleri.

Logging & SOC

Detection coverage.

Incident Readiness

Compromise response kapasitesi.

Remediation Roadmap

Önceliklendirilmiş aksiyon planı.

Microsoft 365 Güvenliğinde KPI'lar Nelerdir?

Örneğin;

MFA Coverage

Phishing-Resistant MFA Coverage

Global Admin Count

PIM Adoption

Legacy Authentication Usage

Guest Account Count

Stale Guest Percentage

External Forwarding Count

Risky Sign-In Count

OAuth High-Risk App Count

Logging Coverage

gibi metrikler kullanılabilir.

Ancak KPI'lar tek başına hedef olmamalıdır.

Gerçek risk azaltımını göstermelidir.

Microsoft 365 Güvenliğinde En Büyük Hata Nedir?

En yaygın yanlışlardan biri:

“MFA açtık, Microsoft 365 güvenli.”

yaklaşımıdır.

MFA çok önemli bir kontroldür.

Ancak saldırgan;

session,

OAuth,

mailbox rules,

application permissions,

privileged roles,

legacy protocols

üzerinden farklı yollar deneyebilir.

Bu nedenle güvenli tenant şu denklemle düşünülmelidir:

Strong Authentication + Conditional Access + Least Privilege + Session Security + App Governance + Email Security + Data Protection + Monitoring

Microsoft 365 için Temel Güvenlik Kontrolleri

Kurumsal yaklaşım olarak şu katmanlar değerlendirilebilir:

MFA / Passwordless

Kimlik doğrulama güvenliği.

Conditional Access

Risk bazlı erişim kontrolü.

PIM

Privileged rol yönetimi.

Least Privilege

Minimum yetki.

OAuth Governance

Uygulama izinlerinin kontrolü.

Mail Security

BEC ve phishing koruması.

DLP / Data Classification

Veri güvenliği.

Device Compliance

Cihaz güvenliği.

Audit / SIEM

Görünürlük.

Identity Incident Response

Kompromizasyon müdahalesi.

Bu kontroller birlikte çalışmalıdır.

Sonuç: Microsoft 365 Güvenliğinin Merkezi Parola Değil Kimliktir

Microsoft 365 modern kurumların en değerli çalışma platformlarından biridir.

E-posta.

Dosya.

Toplantı.

Sohbet.

Uygulama.

Kimlik.

Hepsi aynı ekosistem içerisinde yer alabilir.

Bu nedenle tek bir cloud identity'nin ele geçirilmesi saldırgan için çok geniş bir erişim alanı oluşturabilir.

Güçlü Microsoft 365 ve Entra ID güvenliği yalnızca:

güçlü parola + MFA

yaklaşımından oluşmaz.

Gerçek güvenlik;

Phishing-Resistant Authentication

Conditional Access

PIM

Least Privilege

OAuth Governance

Session Security

Mail Security

Data Protection

SOC Monitoring

katmanlarının birlikte çalışmasıyla oluşur.

Ve özellikle şu soru sürekli sorulmalıdır:

Bir kullanıcının parolası bugün saldırganın eline geçse, hangi güvenlik katmanları bu hesabın kritik verilere ulaşmasını engeller?

Bu sorunun cevabı güçlü ise kimlik mimarisi dayanıklıdır.

Zayıfsa yalnızca parola güvenliğine bağımlı bir sistem vardır.

Ancak Microsoft 365 yalnızca cloud ekosisteminin bir parçasıdır.

Modern kurumlar aynı zamanda;

AWS,

Microsoft Azure,

Google Cloud

üzerinde sunucular, uygulamalar, database'ler ve container altyapıları çalıştırıyor.

Bu noktada yeni bir güvenlik sorusu ortaya çıkar:

Cloud provider güvenli olsa bile sizin cloud ortamınız gerçekten güvenli mi?