Sıfır Güven Modeli ve Active Directory Güvenlik İpuçları - Microsoft Platform Yönetimi - Bloglar - Quest Community

Active Directory güvenliğiyle ilgileniyorsanız, şüphesiz Sıfır Güven modelini duymuşsunuzdur. Kısaca Sıfır Güven, modern BT ortamları için harika bir güvenlik modelidir çünkü ihlallerin kaçınılmaz olduğunu ve kötü niyetli aktörlerin zaten BT ekosisteminizin içinde olduğunu varsayar. Bu nedenle, hiçbir kullanıcıya, hizmete veya başka bir varlığa dolaylı olarak güvenilmemeli ve her zaman bir güvenlik tehdidine işaret edebilecek anormal etkinlikleri aktif olarak aramalısınız.

Burada Sıfır Güvenin ne olduğuna dair söyleyeceklerim bu kadar. Sıfır Güven modeline daha derinlemesine bir giriş için "Sıfır Güven: Nedir, neden buna ihtiyacınız var ve nasıl başlanır?" başlıklı blog yazısını okumanızı şiddetle tavsiye ederim. ”

Bunun yerine, şirket içi veya hibrit Active Directory ortamınızda Sıfır Güven modelini nasıl uygulayabileceğinize odaklanacağım. Özellikle, Active Directory güvenliğini önemli ölçüde güçlendirdikleri için Sıfır Güven stratejisinin değerli bir parçası olabilecek en iyi üç uygulamayı sunacağım.

Yönetici hesaplarına güvenmeyin: Yalnızca sınırlı bir süre için yükseltilmiş ayrıcalık sağlayın.

Büyük bir güce sahip kalıcı hesaplar, doğası gereği tehlikeli bir şeydir. Yükseltilmiş haklarını kasıtlı veya kazara kötüye kullanan yöneticiler çok büyük hasara neden olabilir ve ayrıcalıklı bir hesabı tehlikeye atan bir saldırgan kritik bir tehdittir.

Buna göre Sıfır Güven modeli, yöneticilere yükseltilmiş ayrıcalıkların yalnızca ihtiyaç duyduklarında ve yalnızca ihtiyaç duydukları süre boyunca verilmesini içerir. Active Directory'de bu "tam zamanında" ayrıcalık yükseltme işlemini gerçekleştirmenin aşağıdakiler de dahil olmak üzere çeşitli yolları vardır:

• ESAE (Kızıl Orman) modeli — Microsoft birkaç yıldır, ayrıcalıklı erişime sahip hesapların genel olarak adı verilen özel, yüksek güvenlikli bir yönetim ormanında tutulduğu Gelişmiş Güvenlik Yönetici Ortamı (ESAE) modelini desteklemiştir. bir Kızıl Orman. Bu modelin bir kısmı, bu kullanıcıların bir süreliğine “msDS-ShadowPrincipal” nesnelerine üye olmalarıydı. Bu nesneler, yönetilen etki alanlarındaki güçlü gruplarla eşleştirilir; bu, esas olarak bir yöneticinin, aslında hiçbir zaman Etki Alanı Yöneticileri grubunun üyesi olmadan, belirli bir süre için etki alanı yöneticisi ayrıcalıklarına sahip olabileceği anlamına gelir. Ancak ESAE mimarisi karmaşıktır ve genellikle yalnızca Active Directory'deki en güçlü hesaplar için etkilidir. Bu nedenle Microsoft artık çoğu müşteri için ESAE'yi önermemektedir. (İstisnalar, güçlü güvenlik ihtiyacının, çevrimdışı araştırma laboratuvarları ve endüstriyel kontrol sistemleri gibi ESAE'nin artan karmaşıklığı ve operasyonel maliyetlerine ağır bastığı durumlardır.)
• Geçici grup üyeliği — Active Directory hesaplarına genellikle doğrudan izinler atanmaz; bunun yerine ayrıcalıklarını belirli gruplara üyelik yoluyla elde ediyorlar. Sınırlı bir süre için grup üyeliği sağlayan yazılımı uygulamak her zaman mümkün olmuştur, ancak bunu yapmak genellikle hesabın, kullanıcı artık onları veren grubun bir üyesi olmadığında bile devam edebilen, verilen Kerberos biletleri üzerindeki izinlerle kalmasına neden olmuştur. bu izinler. Windows 2016 bunu değiştirdi: Grup üyeliklerine artık senkronize biletin sona ermesiyle birlikte bir "yaşam süresi" değeri atanabilir. Bu, Active Directory'nin ayrıcalıklı bir gruptaki bir kullanıcının süresinin dolacağı ve kullanıcının Kerberos biletinin de kısa süre sonra sona ereceği anlamına gelir.
• Geçici yönetici hesapları — Ayrıcalıkları olmayan bir yönetici hesabına sahip olmaktan daha iyi ne olabilir? Hesabın kullanılması gerekene kadar devre dışı bırakılması. Ayrıcalıklı kimlik yönetimi sistemleri, kullanılmayan ayrıcalıklı hesapların herhangi bir tehdit oluşturmaması için giriş/çıkış sistemini kullanır.

Sıfır Güven modelinizin bir parçası olarak tam zamanında ayrıcalık yükseltme için hangi yöntemi seçerseniz seçin, "kimin neyi, ne zaman yapabileceğini" belirtebildiğinizden emin olun. ” Ayrıca hem ayrıcalıklı hem de normal kullanıcı hesaplarının etkinliğini yakından denetlemek ve hatta kritik Active Directory güvenlik nesnelerinde kazara veya kasıtlı değişiklikleri önlemek için Change Auditor for Active Directory gibi bir yazılım kullanmayı da düşünün.

Şifreye güvenmeyin: Şifrelerden uzaklaşmayı düşünün.

Güvenlik araştırmacıları ve büyük BT, kullanıcıların uzun zamandır bildiği bir şeyi fark etmeye başlıyor: Şifreler berbattır! Özellikle, kullanıcıları çok karmaşık şifreler seçmeye ve bunları üç ayda bir değiştirmeye zorlama şeklindeki eski uygulama, hem kullanıcılar hem de yardım masası için büyük bir belaydı ve sonuçta Active Directory güvenliğini o kadar da artırmadı.

Sıfır Güven modeli, tek bir parolaya çok daha az güvenmeyi içerir. İşte bazı seçenekler:

• Hibrit bir Active Directory ortamınız varsa ve Microsoft 365 hizmetlerini kullanıyorsanız kullanıcılarınızın zaten hem Azure AD hesabı hem de Active Directory hesabı vardır. Azure AD artık şirket içi Active Directory etki alanları için Bilet Verme Biletleri düzenleyebildiğinden, kullanıcılarınızı birincil kimlik doğrulama kaynağı olarak Azure AD'den yararlanmaya geçirmeyi düşünün. Bu, kullanıcılarınızın etki alanına katılmamış (hibrit bile değil!) uç noktaları kullanmasına ve Kerberos kimlik doğrulaması gerektiren ağ kaynaklarına erişmesine olanak tanır. Kimlik doğrulama için Azure AD'yi kullanmak, kullanıcıları yalnızca kimlik doğrulaması için periyodik olarak VPN kullanma zorunluluğundan kurtarmakla kalmaz, aynı zamanda Windows Hello ve diğer şifresiz seçeneklerden coğrafi filtreleme ve imkansız seyahat gibi seçeneklere kadar Azure Active Directory'deki tüm harika güvenlik özelliklerini etkinleştirir. .
• Hibrit bir Active Directory ortamınız yoksa veya Azure AD'yi birincil kimlik doğrulama kaynağınız yapmak mümkün değilse Active Directory ile entegre olan çok faktörlü bir kimlik doğrulama sistemine yatırım yapın. Bu şekilde, bir kullanıcı hesabının şifreye ihtiyacı olsa bile şifrenin sık sık değiştirilmesine gerek kalmayacak ve güvenliği ihlal edildiğinde çok daha az tehdit oluşturacaktır.

Buluttaki AD yönetici hesaplarına güvenmeyin: Azure AD veya Microsoft 365'te ayrıcalıklı rollere sahip tüm hesaplar yalnızca bulut olmalıdır.

Microsoft, Active Directory ve Azure Active Directory'nin birlikte sıkı bir şekilde çalışmasını sağlamak için büyük miktarda mühendislik kaynağına yatırım yaptı. Hibrit bir Active Directory ortamında, Microsoft bulutundaki verilere, uygulamalara ve altyapıya erişmek için şirket içinde halihazırda dağıttığınız altyapı ve kimlik bilgilerinden yararlanmak kolaydır.

Aslında bu çok kolay olabilir. Hibrit bir Active Directory dağıtımına geçen birçok kuruluş, bulutta yönetim için mevcut şirket içi politikalarından ve süreçlerinden yararlanmak istedi ve böylece şirket içi yönetim hesaplarını ve hizmet hesaplarını hibrit hale getirdiler. Bu mimari, saldırganların buluttaki sistemlere ve bilgilere saldırmak için Active Directory'nin karmaşıklığını ve eski yapısını kullandığı, bulut altyapısına yönelik bazı çok ciddi saldırılara yol açmıştır.

Basitçe açıklamak gerekirse: Azure AD veya Microsoft 365'te ayrıcalıklı bir role sahip olan herhangi bir hesap hiçbir zaman hibrit olmamalıdır - yalnızca bulut olmalıdır!

Son düşünceler

Bu üç en iyi uygulama, Sıfır Güven modelini uygulamak için sağlam bir temel sağlar. Ancak bunların Sıfır Güveni “başarmak” için bir kontrol listesi oluşturmadığını lütfen unutmayın. Aslında herhangi bir güvenlik modelinin uygulanması, birkaç en iyi uygulamanın benimsenmesi veya tek bir yazılım çözümünün dağıtılması meselesi değildir; bunun yerine, çok çeşitli teknolojileri, süreçleri ve politikaları içeren katmanlı bir güvenlik çerçevesi oluşturmayı ve BT ortamınız, iş gereksinimleriniz ve tehdit ortamınız geliştikçe bunu sürekli olarak değerlendirmeyi ve iyileştirmeyi gerektirir. Sıfır Güven modelinin Active Directory güvenliği gibi bir varış noktası değil bir yolculuk olduğunu unutmayın.