Alan Adı Yöneticileri hesap politikası (PCI denetiminden sonra)

Müşterilerimizden biri 1. Seviye PCI şirketi ve denetçileri bize Sistem Yöneticisi ve erişim haklarımız konusunda bir öneri yaptı.

Tamamen Windows tabanlı altyapılarını yaklaşık 700 Masaüstü Bilgisayar / 80 sunucu / 10 Etki Alanı Denetleyicisinden yönetiyoruz.

Üç ayrı hesabımız olan bir sisteme geçmemizi öneriyorlar:

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  

• Nerede WS hesabı sadece iş istasyonlarına üzerinde günlükleri, iş istasyonlarında yerel yönetici olduğunu
• Nerede SRV sadece Olmayan DC Sunucular oturum açar, Sunucular Yerel Yönetici olduğu hesaptır
• Nerede DC hesap olduğunu sadece alanı denetleyicileri etkili bir etki alanı yöneticisi hesabına günlükleri

Ardından, yanlış hesaptan yanlış türde sistemde oturum açmayı önlemek için ilkeler uygulanır (DC olmayan makinelerde etki alanı yöneticisi hesapları için etkileşimli oturum açmayı kaldırma dahil)

Bu, güvenliği ihlal edilmiş bir iş istasyonunun Etki Alanı Yöneticileri oturum açma belirtecini açığa çıkarabilmesini ve Etki Alanı Denetleyicisi'ne karşı yeniden kullanabilmesini önlemek içindir.

Bu, sadece günlük operasyonlarımız için çok müdahaleci bir politika değil, aynı zamanda nispeten olası bir saldırı / istismarın ne olduğunu ele almak için önemli miktarda çalışma gibi görünüyor (bu zaten benim anlayışım, belki de bu istismarın fizibilitesini yanlış anlıyorum) .

Diğer yöneticilerin görüşlerini duymakla ilgileniyorum, özellikle de burada PCI kayıtlı bir şirkette yer almış olanlar ve benzer önerilerle karşılaşanlar. Yönetici oturum açma işlemleriyle ilgili politikalarınız nelerdir?

Kayıt için, şu anda normal olarak kullandığımız bir Etki Alanı Kullanıcısı hesabımız var ve ek haklara ihtiyacımız olduğunda da yükselttiğimiz bir Etki Alanı Yöneticisi hesabımız var. Dürüst olmak gerekirse, hepimiz biraz tembeliz ve genellikle günlük işlemler için Domain Admin hesabını kullanıyoruz, ancak bu teknik olarak şirket politikalarımıza aykırıdır (anladığınızdan eminim!).

Tier 1 PCI satıcısındayım. Bunun gibi bir şey var, birkaç farklılık var.

Denetçiler aslında çok gerçek bir sorunu anlatmaya çalışıyorlar, ancak sonuçları ve ihtiyaç analizlerini açıklayan inanılmaz derecede zayıf bir iş yapıyorlar.

Artık bir parola karması veya mevcut bir belirteç kullanarak bir sistemin güvenliğini aşmak daha etkilidir. Açıkça söylemek gerekirse, saldırganınızın artık kullanıcı adınıza ve şifrenize ihtiyacı yoktur. Artık bir sisteme saldırmanın daha kolay yolları var. Hiçbir koşulda bu tür saldırıların olası olmadığını varsaymamalı veya sonuçlandırmamalısınız. Hash saldırıları artık defacto saldırı vektörüdür .

Karma saldırılar aslında ironik olan akıllı kart hesaplarıyla daha kötüdür, çünkü çoğu insan akıllı kartların uygulanmasının bir sistemin güvenliğini artıracağını bekler.

Bir hesabın karma geçiş saldırısı nedeniyle güvenliği ihlal edilmişse, normal yanıt hesabın şifresini değiştirmektir. Bu, kimlik doğrulaması için kullanılan karma değerini değiştirir. Ayrıca, normal bir parola geçerlilik sonu / değişikliği saldırganın karması nedeniyle başarısızlığa yol açabilir. Ancak, akıllı kartlarda şifre 'sistem tarafından yönetilir' (kullanıcı kimlik doğrulaması için şifreyi asla girmez), bu nedenle karma hiçbir zaman değişmez. Bu, akıllı kart hesaplarında bir ihlalin, şifre kullanan bir hesaptan çok daha uzun süre fark edilmeyebileceği anlamına gelir.

İşte dikkate alacağım azaltıcı etkenler:

• Birçok büyük şirketin yüksek ayrıcalıklı hesaplar için kullandığı akıllı kart özellikli hesaplar için, hesabın parolasını sık aralıklarla değiştirin. Bu karma değerini değiştirir. Ayrıca, akıllı kartın hesabın etkinleştirilmesini kaldırmasını ve ardından yeniden akıllı kartın etkinleştirilmesini sağlayarak karma değerini değiştirebilirsiniz. Microsoft bunu 24 saatte bir gerçekleştirir, ancak bunun ortamınızda yaratabileceği olası etkiyi değerlendirmeniz ve ek sorunlar oluşturmamanız için bir akıl sağlığı programı oluşturmanız gerekir.

• İş istasyonları için etki alanı hesaplarını mümkünse yönetici amacıyla kullanmam. UAC tipi işlemler için yükseltmek için kullanılabilecek yerel bir hesabımız var. Bu, çoğu yükseklik gereksiniminin% 99,9'unu karşılar. Aşamalı değişiklik kontrolünün olmaması ve Java JRE ile Flash'ın varlığı nedeniyle iş istasyonları sıcak saldırı vektörleri olma eğilimindedir.

  Bu yaklaşım, yerel hesaplar için şifreyi yönetmek ve uygulamak için resmi bir mekanizmaya sahip olduğumuz ve şifrenin her sistemde benzersiz olması ve birisinin şifreyi istemesi için güvenli bir yöntem olması nedeniyle bizim için işe yarar. Bu işlevi gerçekleştirebilen ticari uygulamalar da vardır.

• İş istasyonları için yerel hesap çözümü sağlayamazsanız, evet, iş istasyonlarına yönetici erişimi için ayrı bir etki alanı hesabı kullanılmalı ve bu hesap sunuculara yönetici erişimi için kullanılmamalıdır. Başka bir seçenek, etkinlikleri gerçekleştirmek için LocalSystem kullanan uzak, etkileşimli olmayan destek yönetimi araçlarını ve Windows'tan ayrı bir kimlik doğrulama mekanizmasını kullanmak olabilir.

• En yüksek ayrıcalıklı hesaplar için (Enterprise Yönetici, Alan Adı Yöneticisi vb.) Yalnızca atlama sunucusu kullanın. Bu sunucu en kısıtlayıcı güvenlik, değişiklik kontrolü ve denetime tabi olacaktır. Diğer tüm yönetim türü işlevleri için ayrı bir yönetici hesabına sahip olun. İşlem belirteçlerini LSA işleminden temizlemek için atlama sunucusu günlük olarak yeniden başlatılmalıdır.

• İş istasyonunuzdan yönetimsel görevler gerçekleştirmeyin. Sertleştirilmiş bir sunucu veya atlama sunucusu kullanın.

• Her oturumdan sonra belleği temizlemek için sıfırlanabilen atlama kutularınız olarak VM'leri kolayca sıfırlamayı düşünün.

Daha fazla okuma:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

Microsoft Güvenlik İstihbarat Raporu, Cilt 13, Ocak - Haziran 2012
http://www.microsoft.com/security/sir/archive/default.aspx

"Hash-the-Pass saldırılarına karşı savunma" bölümünü okuyun.

Hayal kırıklığına uğramış karma saldırıları yenmek
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753