CategoriesDefenderMicrosoft Entra IDMicrosoft Security

Guest Kullanıcılar için Cihaz Güvenliği Nasıl Sağlanır ?

Günümüzde sistemlerimize bağlanan cihazların güvenliğini kontrol etmek artık bizler için vazgeçilmez bir güvenlik bakış açısı olmuş durumda. Zero Trust bakış açısında “her zaman doğrula” mantığı ile sistemize dahil olan tüm cihazların güvenliğinden emin olmalıyız.

Günümüzde birçok kurum, kullanıcılarının şirket kaynaklarına erişmesine izin vermeden önce yönetilen ve uyumlu cihazlardan çalışmalarını şartlarını koşuyor. Ancak, başka bir kuruluş tarafından yönetilen cihazlardan çalıştıkları için misafir kullanıcılarda bu politikayı uygulamak o kadar basit değil. O cihazları yönetemeyeceğimiz için bu tarz uyumluluk politikalarını da uygulayamayız. Bu sebeple bu cihazların sistemimize dahil olmaları konusunda daha dikkatli olmalıyız.

Tenantlar arası erişim ayarlarını yapılandırarak, diğer Microsoft Entra tenantlarından gelen compliant ve managed cihazlara güvenebiliriz. Bir nevi karşı tarafın politikasını kendimiz için de kullanabiliriz.

Configure Cross-Tenant Settings

Microsoft Entra admin center giriş yaparak External Identities > Cross-tenant Access Settings bölümüne giriyoruz.

Daha sonra Add Organization diyerek ilgili tenantı ekliyoruz.

Ekleme yapıldıktan sonra aşağıdaki gibi görmeliyiz.

Daha sonra eklenmiş olan tenant detaylarına tıkladığımızda aşağıdaki gibi bir ekran ile karşılacağız.

Üst panelde bulunan Trust Settings seçeneğine geçiyoruz.

Default settings ile değil, Customize Settings seçeneği ile ilerliyoruz ve aşağıda bulunan;

• Trust Multifactor Authentication from Microsoft Entra Tenants,

• Trust Compliant Devices

• Trust Microsoft Entra Hybrid Joined Devices

seçeneklerini işaretleyerek kaydediyoruz.

Gerçekleştirilen ayarlar sonrasında, diğer Microsoft Entra tenantlarından gelen harici talepleri kabul edebilir ve bunlara güvenebilirsiniz. Çünkü burada aslında gelen cihazların mevcut tenantlarda “Compliant” olduğunu, MFA kullandığını ve sistemlerine dahil Entra Hybrid Joined olduğunu şart koşmuş olduk. Uyumlu bir cihaz için yapılan talep, BitLocker’ı olmayan bir cihazdan veya gerçek zamanlı koruması devre dışı bırakılmış bir cihazdan geliyor olabilir. Bu nedenle, bunu yalnızca güvenilir iş ortakları için veya şirketinizin birden fazla tenantı varsa yapılandırmak gerekmektedir.

Bu çalışma, guest userların ortamınıza erişmeden önce compliant veya managed bir cihazdan oturum açmasını gerektiren etkin bir Conditional Access politikasına ihtiyaç duymaktadır. (https://medium.com/p/2251d9a9e93f)

Yapılan işlem sonrası kullanıcıların yaşacağı senaryoya göz atarsak, guest kullanıcı ortama uyumlu olmayan veya yönetilmeyen bir cihazdan erişmeye çalışırsa, bunu yapamayacak ve aşağıdaki hata mesajını alacaktır.

Ayrıca Sign-in loglarını incelediğinizde doğrudan neden log-in olamadığını görüntülüyor olacağız.

Eğer Guest User, compliant veya managed bir cihazdan oturum açmaya kalktığında sign-in loglarında başarılı log-in işlemini de görüyor olacağız.

Sonuç olarak, Guest kullanıcılar için cihaz güvenliğini sağlamak, organizasyonların dijital güvenlik stratejilerinde kritik bir rol oynamaktadır. Misafir kullanıcılar genellikle dış kaynaklardan geldiği için güvenlik riski oluşturabilir ve bu risklerin yönetilmemesi, hassas verilere yetkisiz erişim gibi ciddi sorunlara yol açabilir. Ancak doğru şekilde yapılandırılmış Device Trust politikaları ve Koşullu Erişim (Conditional Access) çözümleri ile bu riskleri minimuma indirmek mümkündür.

Cihazların Intune ile yönetilmesi, MFA gibi ek güvenlik katmanlarının uygulanması ve uyumluluk politikalarının kullanılması, guest kullanıcıların erişimini sadece güvenli ve yönetilen cihazlarla sınırlamayı sağlayarak olası tehditleri ortadan kaldırır. Bu adımlar, hem organizasyonların güvenlik duruşunu güçlendirecek hem de Zero Trust ilkelerine uygun olarak güvenlik risklerini minimize edecektir. Guest kullanıcılar için güvenli cihaz erişimini zorunlu kılmak, modern dijital iş dünyasında güvenliği sağlamanın en etkili yollarından biridir.

CategoriesMicrosoft Entra IDMicrosoft Security

What is Break Glass User ? Why it’s Important!

Günümüzde, kuruluşlar dijital verilerini korumak için çeşitli güvenlik önlemleri alıyorlar. Ancak, beklenmedik durumlarda, özellikle acil durumlarda, hızlı ve güvenli bir şekilde erişim sağlamak hayati önem taşır. İşte bu noktada “Break Glass User” kavramı devreye girer.

“Break Glass User” adından da anlaşılacağı gibi, bir tür “acil durum kullanıcısı” olarak düşünülebilir. Bu kullanıcı hesabı, normal koşullarda erişilemeyen ancak acil durumlarda erişime açılan bir hesaptır. Genellikle yüksek güvenlikli verilere veya sistemlere erişim sağlamak için kullanılır. Kısacası, yönetici erişiminin kaybedildiği veya mümkün olmadığı kritik durumlarda Microsoft Cloud ortamımıza yeniden erişim sağlamak için bir acil durum erişimi hesabı kullanabiliriz. Örnek senaryolar düşünüldüğünde;

  • Authentication serverın devre dışı kalması.
  • Yanlış kurgulanmış bir conditional access politikası.
  • Yönetici hesaplarının ele geçirilmesi.
  • Global Admin kullanıcısının işten ayrılması

Bu özel kullanıcı hesabı, normalde yüksek erişim engelleri ve güvenlik önlemleriyle korunur. Ancak, bir acil durumda, yetkili bir kişi veya ekip, “break glass” işlemi gerçekleştirerek bu hesaba erişim sağlayabilir. Bu işlem, genellikle güvenlik protokollerini dikkate alarak izlenir ve denetlenir.

Break Glass User kullanımı, özenle yönetilmelidir. Bu hesaba erişim yetkisi sadece gerektiğinde ve belirlenmiş prosedürler doğrultusunda verilmelidir. Ayrıca, erişim olayları izlenmeli ve denetlenmelidir, böylece güvenlik açıkları tespit edilebilir ve gerekli önlemler alınabilir.

Böyle bir hesap oluşturursanız, herhangi bir oturum açma bildirimini almak için bir uyarı kuralı ayarlamanız önemlidir.

Bu blog yazısı, bir break glass hesabının nasıl yapılandırılacağı ve oturum açıldığında nasıl uyarı verileceği konusunda bilgi içermektedir.

Creating the break glass account

İlk olarak, Microsoft Entra admin center giriş yaparak Users>Create New User seçeneğiyle kullanıcımızı oluşturuyoruz.

Önemli: Burada şuna dikkat etmeliyiz. Oluşturduğumuz kullanıcının bir Break Glass User olduğunu belirticek principal name kullanmamalıyız. Çünkü MFA politikalarından exclude olacak olan bu kullanıcı tahmin edilemez bir kullanıcı olması önemlidir. Aynı şekilde parolası da minimum 15 karakter olmalı ve tahmin edilemez komplekslikte olmalıdır.

Daha sonra rol atamasını gerçekleştiriyoruz

Daha sonra oluşan bu kullanıcıyı Conditional Access politikalarından Exclude ediyoruz.

Şimdi, bu kimlik bilgilerini fiziksel kasa gibi güvenli bir yerde saklanması gerekmektedir ve oturum açma işlemini periyodik olarak test etmeyi planlamanız gerekir. Örneğin ayda 1 defa erişiminizde sorun var mı kontrol edin.

Creating and configuring the alert on sign in

Break Glass User bizler için çok değerli ve zamansız login olunmasını istemeyiz. Bunu izlemek için iki farklı alert mekanizması planlayabiliriz.

1- Log analytics Workplace ile bir Alert Rule oluşturarak.

İlk olarak Microsoft Azure admin portal giriş yapıyoruz.

Daha sonra bu alert rule için ilk olarak bir Resource Group’a ihtiyacımız var.

Subscription > Resource Group > Create bölümünden RG’yi oluşturuyoruz.

Daha sonra Azure Portal Arama bölümüne “Log Analytics Workspace” yazıyoruz ve giriş yapıyoruz.

Create Diyerek, yeni bir Workspace oluşturuyoruz

Workspace oluştuktan sonra aşağıdaki gibi bir ekranla karşılaşıyor olacağız.

Sol panelden aşağıya kaydırdığımızda Monitoring>Alerts bölümüne giriş yapıyoruz.

Açılan ekranda Create > Alert Rule seçeneğini seçiyoruz.

Açılan ekranda signal name olarak “Custom Log Search” seçeneğini seçiyoruz.

Daha sonra bizden bir Query girmemizi istiyor olacak. Oraya aşağıdaki query’i giriyoruz.

// Search for a single Object ID (UserID)
SigninLogs
| project UserId
| where UserId == “4ea60096-e348-491b-93c3-e755ddd0bc59”

User ID bilgisine Entra ID > Users>Owerview ekranından ulaşabilirsiniz.

Daha sonra ilgili ayarları sağladıktan sonra ileri diyoruz.

Açılan ekranda bir “Action Group” oluşturmamızı beklemektedir. Alert tetiklendiğinde burada oluşturulan gruptaki kişilere bilgilendirme yapılacaktır.

Bir sonraki adımda “Details” kısmında gelen mailin içeriğini ve önem seviyesini belirliyoruz.

Sonra olarak ileri diyerek kuralı tamamlıyoruz.

Not:ilgili kuralın ortalama aylık 1.5$ Civarı bir maliyeti vardır.

Kural oluşturulduktan sonra test işlemimizi sağlamak için break glass user’ımıza giriş yapıyoruz ve alert’in tetiklenmesini sağlıyoruz.

Erişim sonrası dakikalar içinde aşağıdaki gibi bir uyarı almayı bekliyoruz.

2. Activity Alerts

Alert mekanizması için bir diğer yöntem ise e-mail activity Rule yeteneği ile bir kural oluşturulması.

İlk olarak security.microsoft.com adresine giriş yapıyoruz.

Sol panelde bulunan “E-mail and Collaboration” tab’ı altında Policies and Rules seçeğine tıklıyoruz.

Açılan ekranda “Activity Alerts” seçeneğine tıklıyoruz.

Açılan ekranda “New Alert Policy” diyerek kuralı oluşturuyoruz.

Aşağıdaki ayarları yapıyoruz.

Save” diyerek kuralı tamamlıyoruz.

Bu kural ile bu kullanıcı login olma işlemi sağladığı durumda bizlere aşağıdaki gibi bir alert gelecektir.

Conculusion

Break Glass User, acil durum erişimi sağlamak için önemli bir güvenlik stratejisidir. Doğru şekilde uygulandığında, kuruluşlar beklenmedik olaylara hızlı ve etkili bir şekilde yanıt verebilirler. Ancak, bu hesapların kullanımı ve erişimi sıkı bir şekilde kontrol edilmeli ve izlenmelidir, böylece güvenlik riskleri minimize edilir. Bir sonraki makalede görüşmek üzere.

CategoriesMicrosoft Entra ID

Entra ID “Partner Tier 2 Support” Rolü Nedir ?

Muhtemelen Microsoft Entra Roles bölümünde Partner Tier 2 Support rolü nedir diye sorduğumuzda hepimiz böyle bir rolü görmedik diyebiliriz. Entra ID’nin, Global Administrator’a yükseltmeyi mümkün kılan “Partner Tier 2 support” adlı yerleşik bir rolü vardır ancak bu rol, Azure portal GUI’sinde gizlenir ve siz açmadığınız sürece görüntüleyemezsiniz.

Bir Saldırgan, Entra ID kiracısında gizli olan ve sistem içerisinde yüksek derecede yetkilere sahip olmak için Partner Tier 2 Support rolünü hedefleyebilir. Azure portal GUI’si bu rolü gizlediğinden, Azure yöneticilerinin ve güvenlik uzmanlarının bu role ilişkin atamaları denetlemesi zordur. Bu sebeple bu rolün kontrolü yapılmadığı noktada büyük problemler ortaya çıkabilir ve gereksiz yetkilendirilmeler sisteminizde varolabilir.

CategoriesMicrosoft Entra IDMicrosoft Security

User Reauthentication on sensitive apps and high-risk actions with Conditional Access

Conditional Access Reauthentication ilkesinde kullanılan senaryoları için artık mevcut olan yeteneklere bir yenisi daha eklendi. Reauthentication ilkesi, genellikle kritik uygulamalara erişmeden ve hassas eylemler gerçekleştirmeden önce kullanıcıların kimlik bilgilerini etkileşimli olarak tekrar sağlamalarını zorunlu kılmanıza olanak tanımaktadır. Oturum açma sıklığının Conditional Access oturum denetimi ile birlikte, riskli kullanıcılar ve oturum açma işlemleri veya Intune kaydı için yeniden kimlik doğrulama gerektirebilmekteyiz. Ancak yeni gelen güncelleme ile artık herhangi bir uygulama ve erişim için yeniden kimlik doğrulama işlemlerine kullanıcıları zorlayabilirsiniz.

CategoriesDefenderMicrosoft Entra IDMicrosoft Security

Intune ile Microsoft LAPS !

Özellikle yöneticilerin kullanmadığı, son kullanıcıların kullandığı cihazlarda yönetimsel bir aktivite yapılması istendiğinde “Local Admin” hesabının bilgilerine ihtiyaç duyulmakta. Ancak büyük kurumlarda bu bir kaotik ortam oluşturabiliyor. Örneğin, tüm local admin hesaplarında aynı şifrenin kullanılması gibi. Oluşturduğu risk açısından oldukça problemli olan bu yapılardaki sorunun çözümü Microsoft Local Admin Password Solution (LAPS) olarak karşımıza çıkıyor.

Language »