Microsoft 365'in güvenliğini doğru şekilde sağlamak: Conditional Access, MFA istisnaları ve Break-Glass hesapları günlük operasyonlarda

Microsoft 365’i düzgün şekilde güvene almak isteyenler için Conditional Access (Entra ID’de erişime bağlı ilkeler, önceki adıyla Azure AD) ve Çok Faktörlü Kimlik Doğrulama (MFA, yani en az iki faktörle oturum açma) vazgeçilmezdir. Birçok şirkette MFA ve ilk Conditional Access kuralları hızlıca etkinleştirilir – ve asıl çalışma bundan sonra başlar: istisnalar gerekçelendirilmek zorunda, acil erişimler düzenli biçimde organize edilmeli ve işletme süreçleri güvenliğin destek yüküne dönüşmemesi için tasarlanmalıdır.

Uygulamada „M365’i güvene almak“ nadiren temel tekniklerden başarısız olur; başarısızlık daha çok günlük meselelerden kaynaklanır: arayüzler için servis hesapları, eski protokoller, güvenilir mobil ağ bulunmayan saha çalışanları, yetkileri çok geniş yöneticiler veya tam olarak koruma önleminin IT’nin erişimini engellediği bir incident. Bu yazı, Conditional Access, MFA istisnaları ve Break-Glass hesaplarının nasıl birlikte çalıştığını düzenliyor – ve bunları go-live sonrası da güvenilir kalacak şekilde nasıl işletmeniz gerektiğini açıklar.

Neden Conditional Access etkin noktadır – ve MFA tek başına yeterli değildir

MFA çalınan parolaların riskini önemli ölçüde azaltır, ancak MFA tam bir erişim konsepti değildir. Conditional Access (CA), erişimin hangi koşullarda izinli olduğunu bağlama göre belirler: örn. yalnızca yönetilen cihazlardan, yalnızca belirli ülkelerden, yalnızca risk bazlı değerlendirmeyle veya yalnızca belirli istemci uygulamalarla. Bu, Zero Trust yönünde kritik adımdır (varsayılan olarak hiçbir erişime güvenilmeyen ve sürekli doğrulama yapılan güvenlik modeli).

Microsoft 365’te MFA’nın tek başına yetmemesinin tipik nedenleri:

• Parola yerine token: Modern kimlik doğrulama tokenlarla (zamanla sınırlı erişim biletleri) çalışır. Çalınmış bir token, CA ek koşullar (örn. cihaz durumu veya oturum kontrolü) talep etmezse MFA’yı atlatabilir.
• Yönetici riski: Yönetim hesapları özellikle caziptir. Admin erişimleri için CA kuralları olmadan (örn. yalnızca yönetici iş istasyonlarından veya yalnızca kimlik avına dirençli MFA ile) en büyük saldırı yüzeyi açık kalır.
• “İzinli” çok geniş tanımlanmış: CA uygulamalar, veri sınıfları ve erişim türleri arasında ayrım yapmazsa güvenlik hızla ya çok gevşek ya da çok kısıtlayıcı olur – her iki durum da sorun yaratır.

Operasyonel öz ise şudur: CA politika katmanı olarak, MFA bunun bir bileşeni olarak, artı temiz bir istisna yönetimi ve dayanıklı acil durum yolları.

Mimari genel bakış: Entra ID’de Conditional Access’in gerçekte neyi yönettiği

BT yöneticileri ve işletim için önemli olan, CA’yı „tek bir politika“ olarak görmek değil, bir karar zinciri olarak ele almaktır. Entra ID her oturum açmada sinyalleri değerlendirir ve politikaları uygular. Önemli sinyaller şunlardır:

• Kimlik: Kullanıcılar, gruplar, roller (örn. Global Administrator gibi ayrıcalıklı roller).
• Hedef kaynak: Bulut uygulaması (Exchange Online, SharePoint/OneDrive, Teams, ayrıca Enterprise App üzerinden üçüncü taraflar).
• İstemci türü: Tarayıcı, modern istemciler, mobil uygulamalar ve ayrıca „Legacy Authentication“ (modern token olmayan eski protokoller, örn. eski IMAP/POP/SMTP kimlik doğrulama çeşitleri).
• Cihaz durumu: „Compliant“ veya „hybrid joined“ (yönetilen cihaz; tipik olarak Intune veya etki alanı bağlantısıyla cihaz durumu bildirir).
• Ağ/konum: Named Locations (tanımlı IP aralıkları), ülkeler/bölgeler, risk göstergeleri.
• Oturum koşulları: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (risk olaylarında sürekli yeniden değerlendirme).

Operasyon açısından CA yapılandırmanızın kalitesi büyük ölçüde bu sinyallerin güvenilir olup olmadığına bağlıdır. Bir Named Location, IP adres hijyeniniz kadar iyidir. „Compliant“ tanımı, cihaz yönetiminiz ve Compliance tanımınız kadar değerlidir. Ve risk değerlendirmesi yalnızca ortaya çıkan event’lerle çalışırsanız faydalıdır.

Microsoft 365’i Conditional Access ile doğru şekilde güvenceye alma: Uygulamaya geeign bir politika seti

Günlük kullanımda tek bir „büyük“ kural yerine, birkaç açıkça tanımlanmış politikadan oluşan bir set daha iyi işler. Bu yan etkileri azaltır ve bir incident sırasında hata ayıklamayı kolaylaştırır. Kanıtlanmış temel düzen şu unsurları içerir:

1) Tüm Nutzer için Baseline: MFA zorunlu, Legacy engelle

Normal kullanıcı hesapları için temel kural: MFA gerekli ve Legacy Authentication engellenir. Burada „Legacy“ ‘modası geçmiş’ anlamında değil, teknik olarak problemli demektir: Bu protokoller sıklıkla modern MFA challenge’larını desteklemez ve bu nedenle parola spreyi (password spraying) için tipik bir giriş noktasıdır.

Önemli: Legacy’i „bir gün“ engelleyin demeyin; bunun yerine ölçüm içeren bir geçiş dönemi planlayın. Hangi istemcilerin hâlâ Legacy kullandığını Sign-in Logs üzerinden kontrol edin. Kurumlarda buna sıklıkla çok işlevli yazıcılar, Scan-to-Mail veya özel ortamlardaki eski e-posta istemcileri bağlı olur.

2) Admin-Policy: Baseline’dan belirgin şekilde daha sıkı

Privilegierte rollere kendi politikasını verin: Erişim sadece tanımlı admin uç cihazlarından olsun (ör. „compliant“ ve gerekirse ayrı bir Admin-Workstation stratejisi), yüksek güvenlikli MFA (phishing-resistent, örn. FIDO2/Passkey veya sertifika tabanlı) kullanın ve mümkünse riskli ülke/konum kısıtlamaları uygulayın. Her şirket hemen tam bir Privileged-Access-Architektur (PAM, yani privilegiertes Zugriffsmanagement) kurmayabilir, ancak bu ayrım hemen fayda sağlar: Ele geçirilmiş bir admin hesabı, ele geçirilmiş bir kullanıcı hesabından farklı ve genelde daha geniş bir zarar alanıdır.

3) Policy für externe Zusammenarbeit und Gäste

Gastzugriffe (B2B Collaboration) sıklıkla beklenmedik veri yolları oluşturur: Konuklar SharePoint’ten dosya indirir, Teams içinde çalışır veya proje portallarına erişir. Burada bilinçli olarak belirleyin: Konuklar sadece MFA ile mi girebilecek, belirli uygulamalar hariç tutulacak mı ve oturumlar ne kadar süreyle geçerli olacak. Proje çalışmaları için genellikle daha kısa oturum süresi makuldür; bu, “unutulmuş girişler” riskini azaltır.

4) Policy für sensible Datenpfade: Gerät oder Sitzung absichern

Günlük kullanım farklı koruma gereksinimleri barındırır: Bir satış görevlisi belki her cihazdan e-postaları okuyabilir, ancak yönetilen bir cihaz olmadan SharePoint’ten büyük veri setleri indiremez. Bu tür farkları tek tip „izin/verme“ ile değil, CA kombinasyonlarıyla ifade edin: „Erişim verilir, eğer cihaz compliant“ veya „Erişim yalnızca kısıtlı oturuma sahip tarayıcı üzerinden“. Bu, tamamen engellemekten daha az sert ama hâlâ etkili bir yaklaşımdır.

MFA-Ausnahmen: Nerede gerçekçidirler – ve nasıl kontrol edilirler

MFA istisnaları, bilinçli tasarlandıkları ve operasyonel olarak kontrol edildikleri sürece zayıflık işareti değildir. Kontrolsüz istisnalar gölge çözümler üretir: Kullanıcılar süreçleri atlatır, adminler kuralları aceleyle kapatır ve zamanla politika koleksiyonu anlaşılmaz hale gelir.

Önemli olan ayrımı yapmaktır: Bir MFA istisnası nadiren „MFA kapalı“ anlamına gelir; daha çok „MFA farklı“ veya „erişim sadece başka koşullar altında“ olur. Tipik istisna kategorileri:

Ausnahmefall 1: Nicht-interaktive Zugriffe und Schnittstellen

Birçok süreç yakın yazılım çözümü M365 hizmetleri ile entegre olur: e-posta gönderimi, takvim erişimi, SharePoint dosya depolama, Teams bildirimleri veya Graph-API çağrıları. Bu tür entegrasyonlar devre dışı bırakılmış MFA’ya sahip kullanıcı hesapları üzerinden yürütülmemelidir. Daha uygun olanı, net yetkilendirmeler ve Secret-/sertifika yaşam döngüsü ile App-Registrierungen (Entra ID’de Anwendung) üzerinden teknik erişimdir. Bu bir „MFA-Ausnahme“ değil, denetlenmesi daha kolay başka bir kimlik doğrulama biçimidir.

Operasyonel sonuçlar: Secrets döndürülmeli, sertifikalar süresi dolar ve izinler yeniden sertifikalandırılmalıdır. Entegrasyonlar planlıyorsa Ownership (wer erneuert Zertifikate/Secrets) ve Monitoring (z. B. Warnungen vor Ablauf) tanımlayın. Aksi takdirde „güvenli“ uygulama kimlik doğrulamasından plansız bir kesinti doğar.

Ausnahmefall 2: Geräte ohne modernen Login (z. B. Scanner, Drucker, Raum-Systeme)

Burada SMTP-Relay, Scan-to-Mail veya oda posta kutuları çevresinde klasik tartışmalar doğar. Yanlış çözüm neredeyse her zaman „MFA olmayan bir kullanıcı hesabı“dır. Daha iyi olan, etkileşimli oturum açmaya bağlı olmayan teknik yollardır: IP-RESTriktion ile merkezi bir mail-relay, sertifika veya Connector-ansätze, ya da sıkı izinlere sahip ayrılmış sistem posta kutuları. Kritik olan şudur: Cihazın kendisi MFA’yı kullanamaz; bu nedenle tasarım iletim ve ağ yolunda güvence altına alınmalıdır.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Saha, üretim veya vardiya işletmelerinde cep telefonu çekmemesi veya özel mobil cihazın olmaması gibi durumlar olur. Bu durumda erken dönemde alternatif MFA yöntemlerini düşünmek mantıklıdır: donanım tokenları, FIDO2 güvenlik anahtarları veya Windows Hello for Business (gerätegebundene Anmeldung). „Temporär MFA aus“ operasyonel olarak cazip gelebilir; ancak iyi ölçeklenmez ve neredeyse denetlenemez.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Bazı eski sistemler işleri „kullanıcı olarak“ başlatır; örneğin SharePoint yüklemeleri veya raporlar için. Bugünün perspektifinden bu risklidir çünkü roller ile erişim hakları karışır. Değişim hemen mümkün değilse, ara çözümler kullanın: sınırlı servis hesapları, net Named Locations, güçlü Parol-/Secret-Politikaları ve tutarlı kaydetme. Ve: App-Identitäten’e geçişi „sonra bir gün“ değil, ayrı bir çalışma paketi olarak planlayın.

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

İstisnalar operasyon sırasında sadece bir yaşam döngüsüne sahipse kabul edilebilir. Pratikte bürokrasi gerektirmeyen ama yine de denetlenebilir bir hafif yöntem işe yarıyor:

1. Begründung in einem Satz: Hangi iş veya operasyon fonksiyonu buna bağlı (z. B. „Scan-to-Mail an Standort X“)?
2. Technische Einordnung: Hangi App/Protokolle, hangi hesaplar, hangi veri yolları?
3. Kompensierende Kontrollen: Riski ne sınırlar (IP-RESTriktion, minimal notwendige Rechte, Monitoring)?
4. Ablaufdatum: Her istisnaya bir inceleme tarihi atanır. İnceleme olmadan kaldırılır veya yeniden onaylanır.
5. Owner: Tıkanma veya istisna süresinin dolması halinde kim sorumludur?

Böylece istisnalar „iyi“ hale gelmez, fakat yönetilebilir olurlar. Ve tam da bu, günlük uygulamada sağlam bir M365 güvenlik temeli ile politika düzensizliği arasındaki farktır.

Break-Glass-Accounts: Güvenlik açığı olmadan acil erişim

Break-Glass hesapları, normal yönetici erişimleri çalışmadığında Tenant’a erişim için kullanılan acil durum hesaplarıdır — örn. Conditional Access yapılandırma hatası, bir MFA sağlayıcısının devre dışı kalması veya bir kimlik olayı. Amaç nettir, fakat uygulamada tipik tuzaklar vardır: Hiç test edilmeyen bir Break-Glass hesabı gerçek durumda yardımcı olmaz. Çok kolay erişilebilen bir Break-Glass hesabı ise cazip bir saldırı hedefidir.

Break-Glass’ın ne olmadığı

• Günlük bir yönetici hesabı değil: Normal işletmede kullanılmamalıdır.
• Bir istisna havuzu değil: Temiz bir CA tasarımının yerini almaz.
• “Bir tane var, yeter” yaklaşımı değil: Süreç, test ve alarmlama yoksa sadece teorik bir plandır.

İşletmede Break-Glass için temel ilkeler

Pratik bir yapı üç hedefe odaklanır: acil durumda ulaşılabilir olmak, normal işletmede zor saldırılabilir olmak ve işlemlerinin net şekilde izlenebilir olması.

• En az iki hesap: Kilitlenme, yanlış kullanım veya kimlik bilgilerinin ele geçirilmesine karşı yedeklilik.
• Güçlü şekilde korunmuş: Uzun, rastgele parolalar; e-posta ile yönlendirmelere izin yok; uygulama/entegrasyon kullanımı yasak.
• CA’dan hedefli muafiyet — ancak sıkı: Tipik olarak belirli CA politikalarından muafiyet tanımlanır, böylece acil durumda kendi kurallarınız nedeniyle dışarıda kalmazsınız. Aynı zamanda diğer güvenlik mekanizmaları devrede olmalıdır: kullanımda alarm, kısıtlı rol atamaları, kimlik bilgilerinin ayrı saklanması.
• Kayıt ve alarmlama: Her oturum açma derhal bir sinyal üretmelidir (SIEM/SOC veya en azından bir Incident posta kutusuna E‑Mail/Teams alarmı). Break-Glass kullanımı tanım gereği bir güvenlik olayıdır.

Merkezi bir nokta: Break-Glass’ın MFA ile mi yoksa MFA olmadan mı işletileceğine bilinçli karar verin. Birçok organizasyon MFA arızası durumunda müdahale edebilmek için MFA olmadan tutar. Bu durumda telafi edici kontrollerin özellikle sağlam olması gerekir (saklama, parola erişimi, alarmlama, düzenli değişim). Alternatif olarak Break-Glass donanım tabanlı MFA (ör. FIDO2) ile korunabilir; bu, mobil ağdan bağımsızdır. Önemli olan “doğru” ideoloji değil, sizin bağlamınızda gerçekten çalışan bir acil durum yolu oluşturmaktır.

Rollout gerçekleri: Kilitlenmeleri ve destek yükünü nasıl önlersiniz

Birçok CA/MFA yaygınlaştırması teknik olarak başarısız olmaz; organizasyonel sebeplerle başarısız olur: çok hızlı, çok geniş, telemetri olmadan ve net bir destek süreci olmadan. Sağlam bir rollout dalgalar ve ölçüm noktaları ile çalışır.

Adım 1: Engellemeye geçmeden önce görünürlük yaratın

Hangi uygulamaların kullanıldığını, hangi istemcilerin “Legacy” olduğunu, hangi konumların/IP aralıklarının gerçek olduğunu, hangi kullanıcıların özellikle çok sayıda oturum açma sorunu yaşadığını belirlemek için Sign‑in Logs ve analizlerden yararlanın. Bu veriler olmadan her politika kör uçuş olur.

Adım 2: Gerçek özel durumları içeren pilot gruplar

Pilotlar sadece “BT ve birkaç gönüllü” olmamalıdır. Bilerek kenar durumları dahil edin: saha ekipleri, üretim sahaları, misafir erişimi olan proje çalışanları ve en az bir bölüm tipik üçüncü taraf araçlarıyla. Amaç uyum değil; gerçek takılma noktalarını erken bulmaktır.

Adım 3: Helpdesk playbook’larını belirleyin

MFA zorlandığında talepler artar: cihaz değişimi, kayıp telefonlar, yeni çalışanlar, çok sayıda deneme sonrası hesap kilitlendi. İlk seviyenin neyi çözebileceğini belirleyin (ör. kimlik doğrulaması sonrası MFA sıfırlama) ve ne zaman eskalasyon yapılacağını tanımlayın. Playbook’lar yoksa her şey eskale olur – ve yöneticiler darboğaz haline gelir.

Adım 4: Teknik takip işleri ayrı bir Backlog olarak

CA gizli teknik borçları görünür kılar: eski mail istemcileri, dokümante edilmemiş tarayıcılar, Task Scheduler’da şifre içeren betikler veya hâlâ Basic Auth kullanan entegrasyonlar. Bu düzeltmeleri görünür iş paketleri olarak planlayın. Aksi takdirde bunlar “kalıcı istisna” olarak takılı kalır.

İşletmeden sık görülen hata senaryoları – ve bunları nasıl daha hızlı sınıflandırırsınız

Günlük hayatta hızlı hipotezler önemlidir. Bazı kalıplar sürekli tekrar eder:

“Birdenbire Outlook çalışmıyor”

Yaygın nedenler: legacy istemci, eski profil veya cihaz durumu eksikliğinden kaynaklanan bir CA engeli. Şunu kontrol edin: oturum açma günlüklerindeki istemci türü, uygulanan CA politikası ve cihazın uyumlu (compliant) olarak kayıtlı olup olmadığı. Operasyonel düzeltme nadiren “politika kapatmak” olur; genellikle “istemciyi modernize etmek” veya “cihaz yönetimini temizlemek” gerekir.

“Servis XY artık e-posta gönderemiyor”

Çoğunlukla arka planda SMTP kimlik doğrulamasında bir değişiklik, değiştirilmiş bir relay politikası veya istemeden teknik hesapları da kapsayan yeni bir CA kuralı vardır. Burada net bir mimari karar yardımcı olur: gönderimi kullanıcı girişi yerine Relay/Connector üzerinden yapmak, IP kısıtlaması ve logging ile (olayın izlenebilirliği için).

“Admin artık tenant’a erişemiyor”

Bu, Break-Glass için öngörülen andır. Eğer Break-Glass erişimi de çalışmıyorsa, genellikle test edilmiş bir acil durum yolu yoktur veya istisna yanlış yapılandırılmıştır. Bu yüzden: kullanımı düzenli olarak tatbik edin (kim ne zaman test ettiğini ve alarmın nasıl göründüğünü belgeleyerek).

“Çok fazla istisna – kimse takip edemiyor”

Bu bir yönetişim sorunudur. Politikaları konsolide edin, bir inceleme ritüeli tanımlayın (ör. aylık 30 dakika) ve artık sahibi veya amacı olmayan istisnaları kaldırın. Teknik olarak bunun bir cazibesi yok ama bu, kontrol edilebilir güvenlikle tarihsel olarak oluşmuş ayrıcalıklar arasındaki farktır.

Monitoring ve İzlenebilirlik: Gerçekte neye ihtiyacınız var

CA ve MFA birçok event üretir. Her şeyi toplarsanız boğulursunuz; hiçbir şey analiz etmezseniz sorunları geç fark edersiniz. Pratikte mantıklı olan üç seviye vardır:

• Ciddi olaylar için alarm: Break-Glass oturumu, sıra dışı ülkelerden admin oturumu, kritik uygulamalarda bloklama olayları.
• Düzenli incelemeler: en sık bloklama nedenleri, MFA sorunları yaşayan en çok etkilenen kullanıcılar, legacy-auth denemeleri, yeni uygulamalar/Enterprise uygulamalar.
• İstisnalar için audit kaydı: Hangi istisnayı kimin onayladığı, hangi bitiş tarihi ile ve ne zaman incelendiği?

Eğer zaten merkezi logging ve incident süreçleriniz (SIEM, ticketing, change-management) varsa, CA değişikliklerini buralara entegre edin. Conditional Access „küçük bir ayar“ değildir; üretim açısından kritik bir erişim katmanıdır.

Çaba ve sorumluluklar: Kim neyi sağlamalı?

CA-/MFA projeleri, sadece konfigürasyon gibi göründükleri için küçümsenir. Oysa gerçekte bunlar kimlik, uç cihazlar, ağ ve iş süreçleri arasındaki arayüz projeleridir. Net bir sorumluluk modeli sürtüşmeyi azaltır:

• Kimlik Ekibi / Entra Yöneticileri: Politika tasarımı, rol modeli, Break-Glass, uygulama kayıtları.
• İstemci yönetimi (ör. Intune): Uyumluluk tanımı, cihaz durumu, Authenticator/Passkeys dağıtımı, cihaz yaşam döngüsü.
• Ağ: Named Locations için IP aralıkları, Proxy/TLS-Inspection istisnaları, konum değişiklikleri.
• Business uygulamalarının Service Owner’ı: Entegrasyon yolları (Graph/SMTP/SharePoint), Legacy kimlik doğrulamanın dönüştürülmesi, Secret-Rotation.
• Helpdesk: MFA sıfırlama, cihaz değişimi, işe başlama/ayrılma için standart süreçler.

En önemli yönetim kararı sıklıkla „MFA evet/hayır“ değildir; asıl soru şudur: Sonraki işleri yapmak — Legacy bağımlılıklarını azaltmak, entegrasyonları modernize etmek, cihaz yönetimini istikrara kavuşturmak — için zaman ve kaynaklarımız var mı? Bu çalışmalar yapılmazsa güvenlik kazanımı beklentilerin gerisinde kalır veya işletme gereksiz yere zorlaşır.

Sonuç: Acil durum ve istisnaların sistemin parçası olması güvenliği artırır

Microsoft 365’i doğru şekilde güvence altına almak, Conditional Access’i tek seferlik bir yapılandırma olarak değil, merkezî bir denetim katmanı olarak işletmeyi gerektirir. MFA zorunludur; ancak gerçek işletme kalitesi, süre sonu olan (süreli), bir Owner atanmış ve telafi edici kontrollerle desteklenmiş temiz istisnalar ve test edilen, izlenen ve organizasyonel olarak entegre edilmiş Break-Glass hesapları ile oluşur. Bu üç unsuru birlikte düşünenler hesap risklerini azaltır, denetlenebilirlik sağlar ve olay sırasında güvenlik kurallarının kendi aleyhine dönmesini engeller.

Bir proje veya modernizasyon girişimini Net-Base ile görüşün.