Kurduğunuz her entegrasyonun arkasında bir etki alanı hesabı var
Güvenlik duvarı. VPN cihazı. PAM platformu. ERP. Kimsenin dokunmak istemediği kurum içi uygulama. Kullanıcıları doğrulayabilmeleri için hepsine bir servis hesabı verildi. Hepsi hâlâ o hesabı kullanıyor.
Bu hesapların parolaları çoğunlukla hiç sona ermez, MFA ile korunamaz ve neredeyse tüm dizini okuyabilir. Şifresiz LDAP kullanılıyorsa parola ağdan açık biçimde geçer.
Bu risk gözden kaçmış değil. Çözümler biliniyor; uygulanamamalarının nedeni mimari bir kilitlenme: Parola rotasyonu, yetki daraltma, LDAPS geçişi ve LDAP signing ayarları birbirinin ön koşulu hâline geliyor. Bu çıkmazın ayrıntılarını inceleyin.
Güvenlik seviyenizi en güçlü ürününüz değil, en zayıf entegrasyonunuz belirler.
Her önlem neden yarım kalıyor ve sizde bu risk var mı? Etki alanı denetleyicilerinizin zaten oluşturduğu kayıtlarla kontrol edin: LDAP Servis Hesabı Güvenliği.
Nasıl çalışır?
Uygulama gerçek etki alanı parolasını hiçbir zaman tutmaz
- Uygulama proxy üzerine sanal kimlik bilgisiyle bind yapar. Bu bilgi yalnızca Mirket içinde bulunur; dizinde karşılığı yoktur.
- Proxy kendi başına karar vermez; Mirket Portal üzerinden kontrol ister.
- Portal sırasıyla kontrol eder: Bu kimlik bilgisi için politika var mı, kaynak adresine izin verilmiş mi, sorgu izin verilen DN kapsamında mı, isteği yapan bir servis hesabı mı yoksa kişi mi?
- Politika uygunsa Portal, gerçek Active Directory kimlik bilgisini karşılıklı kimlik doğrulamalı, şifreli kanal üzerinden proxy’ye iletir. Sanal bilgi etki alanı denetleyicisine, gerçek bilgi ise uygulamaya asla ulaşmaz.
- Proxy, uygulama hangi protokolü destekliyor olursa olsun, sonraki bind işlemini LDAPS ya da imzalı bind ile yapar.
Son kullanıcı bind işlemleri push onayına bağlanabilir. Servis hesapları muaf tutulduğu için rutin dizin sorguları gün boyu bildirim üretmez.
Uygulamanın elinde bir kimlik bilgisi var. Active Directory ise onun varlığından habersiz.
Ağdan ele geçirilen bu kimlik bilgisinin artık Active Directory kimlik bilgisi olarak değeri yoktur. Arkasında hesap bulunmadığından Kerberos bileti alınamaz, SMB ile doğrulama yapılamaz veya etki alanındaki diğer sistemlerde parola denemesi için kullanılamaz.
Tehdit tespiti
Çalınan kimlik bilgisi kendini ele verir
Sanal kimlik bilgisi yalnızca Mirket içinde bulunur. Active Directory üzerinde hesabı yoktur ve proxy üzerinden bind dışında meşru bir kullanım alanı bulunmaz.
Bu bilgi başka hiçbir yerde görünmemeli. Bir Windows oturum açma girişiminde, SMB kimlik doğrulamasında, Kerberos isteğinde ya da başka bir uygulamanın kaydında karşınıza çıkıyorsa, bu kimlik bilgisinin yapılandırma dosyasından çıkarıldığını gösteren yüksek güvenilirlikli bir işarettir. Çünkü başka bir meşru kullanım yolu yoktur.
Bunu log platformunuza bir tespit kuralı olarak aktarın. Davranışın nasıl olduğuna değil, kimlik bilgisinin nerede göründüğüne bakar; bu yüzden davranış tabanlı kurallara göre çok daha az gürültü üretir.
Yetenekler
| Sanal kimlik bilgileri | Her uygulamaya Active Directory üzerinde karşılığı olmayan ayrı bir bilgi verilir. İşlemler uygulama bazında izlenir; bir kimlik bilgisi diğerlerini etkilemeden iptal edilebilir. |
| Kimlik bilgisi enjeksiyonu | Gerçek kimlik bilgisini Portal sağlar; yalnızca proxy ile etki alanı denetleyicisi arasında kullanılır. |
| Otomatik parola rotasyonu | Gerçek servis hesabı parolası belirlediğiniz takvimde, isterseniz her gün, hiçbir uygulama yapılandırmasını değiştirmeden yenilenir. |
| Kaynak IP kısıtlaması | İzin verilen adresler kimlik bilgisi bazında tanımlanır. Diğer kaynaklardan gelen bind istekleri reddedilir. |
| DN kapsamı kısıtlaması | Her kimlik bilgisi için bir base DN belirlenir. Kapsam dışı aramalar reddedilir; tüm dizinin taranması engellenir. |
| Eski uygulamalarda MFA | Uygulamada değişiklik yapmadan son kullanıcı bind işlemlerine push onayı eklenir. |
| Protokol güvenliğini yükseltme | İstemci şifresiz LDAP kullansa bile etki alanı denetleyicisine giden bağlantı LDAPS veya imzalı bind üzerinden kurulur. |
| Merkezi bind kayıtları | Bütün bind işlemleri tek noktadan geçtiği için kaydedilebilir. Önceden görünmeyen dizin trafiği izlenebilir hâle gelir. |
Servis hesaplarınızın bugün neleri okuyabildiğini görün
Kendi dizininizde teknik demo: Ele geçirilen bir bind işlemi saldırgana bugün ne kazandırıyor, uygulamanın kullandığı kimlik bilgisi artık dizinde bir hesaba karşılık gelmediğinde ne değişiyor?
LDAP güvenliğini eksiksiz güçlendirin
Tek bir eski uygulama yüzünden ertelediğiniz güvenlik ayarlarını etkinleştirin
Microsoft ADV190023 iki ayrı mekanizmayı ele alır; aralarındaki fark önemlidir. LDAP signing, şifresiz LDAP iletişiminin bütünlüğünü koruyarak bind işleminin aktarım sırasında değiştirilmesini engeller. LDAP channel binding ise LDAPS oturumunu geldiği TLS kanalına bağlar ve oturumun başka bir yere aktarılmasına karşı koruma sağlar. Bu özelliklerden herhangi birini etkinleştirmek, desteklemeyen istemcileri bozabilir.
Bu nedenle çoğu kurum ikisini de etkinleştiremez: Yalnızca şifresiz LDAP konuşan tek bir ürün bütün ortamı geride tutar. Proxy bu engeli kaldırır. İstemci proxy ile düz LDAP konuşmaya devam ederken etki alanı denetleyicisine bağlantı LDAPS veya imzalı bind ile kurulur. Eski uygulamaya dokunulmaz.
Kapsama alınması gereken portlar
| Port | Servis | Açıklama |
|---|---|---|
389/tcp | LDAP | TLS olmadan simple bind kullanılan port; başlıca risk alanı |
636/tcp | LDAPS | TLS üzerinden LDAP |
3268/tcp | Global Catalog | Global Catalog sorgulayan uygulamalar için mutlaka kapsama alınmalı; aksi hâlde trafik proxy’yi atlayabilir |
3269/tcp | Global Catalog (TLS) | Aynı kapsam |
389/udp | CLDAP | Etki alanı denetleyicisi keşfi; kimlik bilgisi taşımaz, kapsam dışında bırakın |
Güvenlik duvarı kuralına ilişkin önemli not. İlk akla gelen kural şudur: proxy dışındaki tüm kaynaklardan etki alanı denetleyicisine LDAP erişimini engellemek. Bu kural etki alanınızı bozabilir. Windows; Grup İlkesi, sertifika otomatik kaydı, DC keşfi ve etki alanı denetleyicileri arasındaki çoğaltma için LDAP kullanır.
Kural daha dar olmalı: Proxy üzerinden geçmesi gereken kaynakları açıkça belirleyin: üçüncü taraf cihazlar, uygulama sunucuları ve DMZ segmentleri. Etki alanının kendi trafiğine dokunmayın. Kurulum sırasında bu ayrımı birlikte planlıyoruz.
Denetim ve uyumluluk
PCI DSS v4.x
Req. 8.6Uygulama ve sistem hesaplarının parolaları betiklere veya yapılandırma dosyalarına sabit olarak yazılmamalı (8.6.2); kurumun hedefli risk analizine göre belirlediği sıklıkta ve ihlal şüphesinde değiştirilmelidir (8.6.3). Sanal kimlik bilgileri gerçek parolayı yapılandırmalardan çıkarır; rotasyon artık her ürüne tek tek müdahale gerektirmez.
Microsoft
ADV190023Eski uygulamaları değiştirmeden LDAP signing ve channel binding uygulanabilir hâle gelir.
ISO/IEC 27001:2022
Erişim kontrolü, kimlik bilgisi yönetimi ve aktarım sırasında kriptografik koruma.
GDPR
Art. 32Aktarım sırasında kişisel verilerin şifrelenmesi; dizin sorguları artık ağdan açık biçimde geçmez.
Kurulum Seçenekleri
Kurum içi. İki bileşen: Politikaları ve gerçek kimlik bilgilerini tutan Mirket Portal ve dizinin önünde konumlanarak Portal kararlarını uygulayan hafif proxy ajanı.
Mirket Portal zaten kuruluysa yeni bir yönetim sunucusuna ihtiyacınız yoktur. Yalnızca proxy ajanı eklenir.
Uygulama tarafında değişen tek şey LDAP sunucusunun adresidir.
