Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Teknik Rehber · Microsoft 365 & Cloud

Microsoft 365 MFA ve Conditional Access Nasıl Birlikte Kullanılır?

MFA kullanıcı kimliğini güçlendirirken Conditional Access erişim kararına kullanıcı, cihaz, uygulama, konum ve risk gibi ek sinyaller ekleyebilir.

SON TEKNİK GÖZDEN GEÇİRME:
Microsoft 365 & Cloud

Bu Konu Neden Önemli?

MFA kullanıcı kimliğini güçlendirirken Conditional Access erişim kararına kullanıcı, cihaz, uygulama, konum ve risk gibi ek sinyaller ekleyebilir.

Karar Verirken Kontrol Edilecek Noktalar

Önce report-only veya kontrollü pilot yaklaşımı kullanın.

Break-glass hesaplarını politika tasarımında ayrıca ele alın.

Yönetici erişimleri için daha güçlü kontroller uygulayın.

Lisans gereksinimlerini devreye almadan önce doğrulayın.

Mimari ve çalışma modeli

MFA ek doğrulama sağlar; Conditional Access ise hangi koşulda hangi kontrolün isteneceğini belirler. Kullanıcı, uygulama, cihaz, konum ve risk sinyalleri politikaya girdi olur. Bir kullanıcıya birden çok politika uygulanabilir; bir bloklama kararı başka bir politikanın izin vermesiyle ortadan kalkmaz. Kimlik doğrulama gücü, yalnızca herhangi bir ikinci faktörün varlığından daha ayrıntılı bir şarttır.

Report-only modu politikayı uygulatmadan etkiyi incelemeye yardım eder. Bununla birlikte bağımlı servisleri ve kullanıcı deneyimini gerçek pilot oturumlarda doğrulamak gerekir. Eski kimlik doğrulama yolları, otomasyon hesapları ve acil erişim hesapları ayrı incelenir. Acil erişim geniş bir kalıcı bypass değildir: sınırlı kullanım, bağımsız kurtarma yolu, güvenli kimlik doğrulama ve oturum alarmı birlikte tasarlanır.

  1. 1Oturum sinyalleri
  2. 2Politika değerlendirmesi
  3. 3Gerekli doğrulama
  4. 4Sonuç ve oturum kaydı
Pilot sonuçlarında uygulanan tüm politikaları ve bloke edilen gerçek erişim nedenini birlikte inceleyin.

Tasarım parametreleri

Birleşen politika
Uygulanan tüm politikaların sonucunu inceleyin; tek izin kuralı ayrı blok kuralını geçersiz kılmaz.
Report-only ve kurtarma
Pilot etkisini zorlamadan inceleyin; acil erişim hesabının bağımsız kurtarma yolunu ve alarmını test edin.
Kimlik ve tenant sınırı
Kullanıcı, misafir, yönetici ve uygulama kimliklerini ayırın. Tenant politikaları ile tek kaynağın izinleri aynı kapsam değildir.
Veri sahipliği ve yaşam döngüsü
Verinin sahibi, saklama süresi, silinme yolu ve geri kazanım yöntemi belirlenmelidir. Senkronizasyon ile yedeklemeyi ayırın.
Lisans ve özellik kapsamı
Kullanıcı rolü, cihaz, tenant ve gerekli özellik üzerinden lisans doğrulayın. Güncel paket adını geçmiş bilgiyle varsaymayın.
Bağlantı ve maliyet
İnternet, kimlik servisi, veri çıkışı, depolama ve işletim giderini birlikte değerlendirin. Bütçe alarmının harcamayı otomatik durdurduğunu varsaymayın.

Hesap ve uygulama örneği

Yeni kuralı önce 10 pilot kullanıcıya report-only olarak atayın. Yönetilen dizüstü, kişisel telefon ve eski posta istemcisinden oturumları inceleyin. Başarısızlığı parola hatası, cihaz uyumsuzluğu ve politika bloklaması olarak ayırın. Acil erişim hesabıyla kayıtlı kurtarma prosedürünü doğruladıktan sonra kuralı küçük gruplarla etkinleştirin.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Beklenen kullanıcı bloke oluyorBaşka politika, device state veya authentication strength etkili olabilir.Sign-in kaydındaki tüm politika sonuçlarını ve gerçek cihaz bilgisini karşılaştırın.
Bazı kullanıcılar erişemiyorLisans, grup, cihaz durumu veya erişim politikası farklı olabilir.Etkilenen ve çalışan kullanıcıların karar kayıtlarını karşılaştırın.
Silinen veri geri getirilemiyorSaklama ve kurtarma kapsamı beklenenden farklı olabilir.Nesne türü, silinme zamanı ve resmî kurtarma koşullarını doğrulayın.
Maliyet beklenenden yüksekKaynak boyutu, veri çıkışı, saklama veya taahhüt kullanımı farklı olabilir.Kaynak ve hizmet bazında gerçekleşeni tahminle eşleştirin.

Kabul ve doğrulama kontrolleri

  1. Pilot sonuçlarında uygulanan tüm politikaları ve bloke edilen gerçek erişim nedenini birlikte inceleyin.
  2. Kullanıcı, misafir ve yönetici senaryolarını ayrı test edin.
  3. Kayıp cihaz ve iptal edilen erişim davranışını doğrulayın.
  4. Bir test nesnesini silip tanımlı yöntemle geri kazanın.
  5. Gerekli özellik için güncel lisans kapsamını belgeleyin.
  6. Günlükleri kimlik ve kaynak açısından uçtan uca eşleştirin.

İlgili kavramlar

Kimlik doğrulama ve oturum

Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.

En az yetki ve görev ayrımı

En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.

Politikanın yaşam döngüsü

Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.

Saklama politikası ve kapasite

Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.

Yüksek erişilebilirlik ile kurtarma ayrımı

Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.

Maliyet ölçümünün sınırı

Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.

Birincil teknik dokümantasyon

Who · How · Why

Bu İçerik Nasıl Hazırlandı?

Kim?

Doz Teknoloji Teknik Ekibi

İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.

Nasıl?

Teknik kriterler + birincil kaynaklar

Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.

Neden?

Karar kalitesini artırmak

Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.

Bu Rehberle İlgili Kurumsal Çözümler

Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.

Teknik İhtiyacınızı Birlikte Değerlendirelim

Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.

Teknik Talep Oluşturun
Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!