En Az Ayrıcalıklı Yönetim Modellerinin Uygulanması

Aşağıdaki alıntı, ilk olarak 1 Nisan 1999'da yayımlanan Yönetici Hesapları Güvenlik Planlama Kılavuzu'ndandır:

"Güvenlikle ilgili eğitim kurslarının ve belgelerinin çoğu, en az ayrıcalık ilkesinin uygulanmasını tartışır, ancak kuruluşlar bunu nadiren izler. Bu ilke basittir ve bunu doğru şekilde uygulamanın etkisi güvenliğinizi büyük ölçüde artırır ve riskinizi azaltır. İlke, tüm kullanıcıların geçerli görevi tamamlamak için gereken mutlak minimum izinlere sahip bir kullanıcı hesabıyla oturum açması gerektiğini ve başka bir şey yapmaması gerektiğini belirtir. Bunu yapmak, diğer saldırılar arasında kötü amaçlı kodlara karşı koruma sağlar. Bu ilke, bilgisayarlar ve bu bilgisayarların kullanıcıları için geçerlidir. "Bu ilkenin bu kadar iyi çalışmasının bir nedeni, sizi bazı iç araştırmalar yapmaya zorlaması. Örneğin, bir bilgisayar veya kullanıcının gerçekten ihtiyaç duyduğu erişim ayrıcalıklarını belirlemeniz ve sonra bunları uygulamanız gerekir. Birçok kuruluş için bu görev başlangıçta çok fazla iş gibi görünebilir; ancak, ağ ortamınızın güvenliğini başarıyla sağlamak önemli bir adımdır. "Tüm etki alanı yöneticisi kullanıcılarına en az ayrıcalık kavramı altında etki alanı ayrıcalıklarını vermelisiniz. Örneğin, yönetici ayrıcalıklı bir hesapla oturum açarsa ve yanlışlıkla bir virüs programı çalıştırırsa, virüsün yerel bilgisayara ve etki alanının tamamına yönetici erişimi vardır. Yönetici bunun yerine ayrıcalıksız (yönetici olmayan) bir hesapla oturum açmış olsaydı, virüsün zarar kapsamı yalnızca yerel bilgisayar olacaktır çünkü yerel bilgisayar kullanıcısı olarak çalışır. "Başka bir örnekte, etki alanı düzeyinde yönetici hakları eklediğiniz hesapların, ormanlar arasında bir güven ilişkisi olsa bile başka bir ormanda yükseltilmiş haklara sahip olmaması gerekir. Bu taktik, bir saldırganın yönetilen bir ormanın güvenliğini aşmayı başarması durumunda yaygın hasarı önlemeye yardımcı olur. Kuruluşlar, ayrıcalıkların yetkisiz olarak yükseltilmesine karşı korunmak için ağlarını düzenli olarak denetlemelidir."

Aşağıdaki alıntı, ilk olarak 2005'te yayımlanan Microsoft Windows Güvenlik Kaynak Seti'ndendir:

"Güvenliği her zaman görevi gerçekleştirmek için gereken en az sayıda ayrıcalık verme açısından düşünün. Çok fazla ayrıcalığı olan bir uygulamanın güvenliğinin aşılması gerekiyorsa, saldırgan saldırıyı mümkün olan en az ayrıcalık miktarı altında olsaydı saldırıyı genişletebilirdi. Örneğin, bir ağ yöneticisinin farkında olmadan virüs başlatan bir e-posta ekini açmasının sonuçlarını inceleyin. Yönetici etki alanı Yönetici hesabını kullanarak oturum açtıysa, virüs etki alanındaki tüm bilgisayarlarda Yönetici ayrıcalıklarına sahip olur ve bu nedenle ağ üzerindeki neredeyse tüm verilere sınırsız erişim sağlar. Yönetici yerel bir Yönetici hesabı kullanarak oturum açtıysa, virüs yerel bilgisayarda Yönetici ayrıcalıklarına sahip olur ve bu nedenle bilgisayardaki tüm verilere erişebilir ve bilgisayara anahtar vuruşu günlüğe kaydetme yazılımı gibi kötü amaçlı yazılımlar yükleyebilir. Yönetici normal bir kullanıcı hesabı kullanarak oturum açtıysa virüs yalnızca yöneticinin verilerine erişebilir ve kötü amaçlı yazılım yükleyemez. E-posta okumak için gereken en düşük ayrıcalıkları kullanarak, bu örnekte gizliliğin tehlikeye atılması olası kapsamı büyük ölçüde azaltılır."

Ayrıcalık Sorunu

Önceki alıntılarda açıklanan ilkeler değişmedi, ancak Active Directory yüklemelerini değerlendirirken, gündelik iş yapmak için gerekenlerin çok ötesinde hak ve izinler verilmiş çok fazla sayıda hesap buluyoruz. Ortamın boyutu aşırı ayrıcalıklı hesapların ham sayılarını etkiler, ancak orantı ortası dizinlerde en yüksek ayrıcalıklı gruplarda onlarca hesap olabilirken, büyük yüklemelerde yüzlerce, hatta binlerce hesap olabilir. Birkaç istisna dışında, saldırganların becerileri ve cephaneliği ne olursa olsun, saldırganlar genellikle en az direnç yolunu izler. Yalnızca ve daha basit mekanizmalar başarısız olduğunda veya savunucular tarafından engellendiğinde araçlarının ve yaklaşımlarının karmaşıklığını artırırlar.

Ne yazık ki, birçok ortamda en az direnç yolu, geniş ve derin ayrıcalıklara sahip hesapların aşırı kullanılıp kullanılamadığı kanıtlanmıştır. Geniş ayrıcalıklar, bir hesabın ortamın büyük bir çapraz bölümünde belirli etkinlikler gerçekleştirmesine olanak tanıyan haklar ve izinlerdir. Örneğin, Yardım Masası personeline birçok kullanıcı hesabında parolaları sıfırlama izni verilebilir.

Derin ayrıcalıklar, popülasyonun dar bir kesimine uygulanan güçlü ayrıcalıklardır. Örneğin, bir sunucuda mühendise onarım yapabilmeleri için Yönetici hakları verme. Geniş ayrıcalık veya derin ayrıcalık mutlaka tehlikeli değildir, ancak etki alanındaki birçok hesap kalıcı olarak geniş ve derin ayrıcalıklara sahip olduğunda, hesaplardan yalnızca biri tehlikeye atılırsa, ortamı saldırganın amaçlarına göre yeniden yapılandırmak ve hatta altyapının büyük kesimlerini yok etmek için hızlı bir şekilde kullanılabilir.

Kimlik bilgisi hırsızlığı saldırısı türü olan karma geçişi saldırıları, bunları gerçekleştirmeye yönelik araçlar serbestçe kullanılabilir ve kullanımı kolay olduğundan ve birçok ortam saldırılara karşı savunmasız olduğundan yaygın olarak gerçekleştirilir. Asıl sorun ise hash geçiş saldırıları değildir. Sorunun crux'u iki katdır:

1. Bir saldırganın tek bir bilgisayarda derin ayrıcalık elde edip daha sonra bu ayrıcalığı diğer bilgisayarlara yaygın olarak yaymak genellikle kolaydır.
2. Bilgi işlem ortamı genelinde genellikle yüksek ayrıcalık düzeyine sahip çok fazla kalıcı hesap vardır.

Hash geçişi saldırıları ortadan kaldırılsa bile, saldırganlar farklı bir strateji değil, sadece farklı taktikler kullanır. Kimlik bilgilerini çalmak için araçlar içeren kötü amaçlı yazılımlar yerleştirmek yerine, tuş vuruşlarını kaydeden kötü amaçlı yazılımlar yerleştirebilir veya tüm ortamda etkili kimlik bilgilerini yakalamak için başka bir dizi yaklaşımdan yararlanabilirler. Taktiklerden bağımsız olarak hedefler aynı kalır: geniş ve derin ayrıcalıklara sahip hesaplar.

Aşırı ayrıcalık verme yalnızca güvenliği aşılmış ortamlarda Active Directory'de bulunmaz. Bir kuruluş gerekenden daha fazla ayrıcalık verme alışkanlığını geliştirdiğinde, genellikle aşağıdaki bölümlerde açıklandığı gibi altyapıda bulunur.

Active Directory'de

Active Directory'de EA, DA ve BA gruplarının aşırı sayıda hesap içerdiği yaygın olarak görülür. En yaygın olarak, bir kuruluşun EA grubu en az üyeyi içerir, DA grupları genellikle EA grubundaki kullanıcı sayısının çarpanını içerir ve Yöneticiler grupları genellikle diğer grupların birleştirilmiş popülasyonlarından daha fazla üye içerir. Bunun nedeni genellikle Yöneticilerin bir şekilde DA'lardan veya EA'lardan "daha az ayrıcalıklı" olduğu inancından kaynaklanır. Bu grupların her birine verilen haklar ve izinler farklılık gösterse de, bir grubun üyesi kendisini diğer ikisinin üyesi olabileceğinden, eşit derecede güçlü gruplar olarak kabul edilmelidir.

Üye Sunucularda

Birçok ortamda üye sunuculardaki yerel Yöneticiler gruplarının üyelik listelerini aldığımızda, sadece bir avuç yerel ve etki alanı hesabından, genişletildiğinde sunucularda yerel Yönetici ayrıcalığına sahip yüzlerce, hatta binlerce hesabı ortaya çıkaran onlarca iç içe geçmiş gruba kadar değişen üyelikler buluyoruz. Çoğu durumda, büyük üyelikleri olan etki alanı grupları üye sunucuların yerel Yöneticiler gruplarına yerleştirilir ve etki alanındaki bu grupların üyeliklerini değiştirebilen herhangi bir kullanıcı, grubun yerel Yöneticiler grubunda yerleştirildiği tüm sistemlerin yönetim denetimini elde edebilir.

İş İstasyonlarında

İş istasyonları genellikle yerel Administrators gruplarında üye sunuculardan çok daha az üyeye sahip olsa da, birçok ortamda kullanıcılara kişisel bilgisayarlarındaki yerel Yöneticiler grubunda üyelik verilir. Bu durum oluştuğunda, UAC etkinleştirilmiş olsa bile, bu kullanıcılar iş istasyonlarının bütünlüğü için yükseltilmiş bir risk sunar.

Önemli

Kullanıcıların iş istasyonlarında yönetim haklarına ihtiyacı olup olmadığını dikkatli bir şekilde düşünmelisiniz ve bunu yaparlarsa, Bilgisayarda Administrators grubunun üyesi olan ayrı bir yerel hesap oluşturmak daha iyi bir yaklaşım olabilir. Kullanıcılar yükseltme gerektirdiğinde, yükseltme için bu yerel hesabın kimlik bilgilerini sunabilir, ancak hesap yerel olduğundan, diğer bilgisayarların güvenliğini aşmak veya etki alanı kaynaklarına erişmek için kullanılamaz. Ancak tüm yerel hesaplarda olduğu gibi, yerel ayrıcalıklı hesabın kimlik bilgileri benzersiz olmalıdır; Birden çok iş istasyonunda aynı kimlik bilgilerine sahip bir yerel hesap oluşturursanız, bilgisayarları karma geçirme saldırılarına maruz bırakırsınız.

Uygulamalarda

Hedefin bir kuruluşun fikri mülkiyeti olduğu saldırılarda, uygulamalar içinde güçlü ayrıcalıklar verilmiş hesaplar, verilerin sızdırmasına izin vermek için hedeflenebilir. Hassas verilere erişimi olan hesaplara etki alanında veya işletim sisteminde yükseltilmiş ayrıcalık verilmemiş olsa da, bir uygulamanın yapılandırmasını işleyebilen veya uygulamanın sağladığı bilgilere erişebilen hesaplar risk oluşturur.

Veri Depolarında

Diğer hedeflerde olduğu gibi, belgeler ve diğer dosyalar biçiminde fikri mülkiyete erişim arayan saldırganlar dosya depolarına erişimi denetleyan hesapları, dosyalara doğrudan erişimi olan hesapları, hatta dosyalara erişimi olan grupları veya rolleri hedefleyebilir. Örneğin, sözleşme belgelerini depolamak için bir dosya sunucusu kullanılırsa ve Active Directory grubu kullanılarak belgelere erişim verilirse, grubun üyeliğini değiştirebilen bir saldırgan gruba güvenliği aşılmış hesaplar ekleyebilir ve sözleşme belgelerine erişebilir. Belgelere erişimin SharePoint gibi uygulamalar tarafından sağlandığı durumlarda, saldırganlar daha önce açıklandığı gibi uygulamaları hedefleyebilir.

Ayrıcalığı Azaltma

Ortam ne kadar büyük ve karmaşık olursa, yönetimi ve güvenliğini sağlamak o kadar zordur. Küçük kuruluşlarda, ayrıcalığı gözden geçirmek ve azaltmak nispeten basit bir teklif olabilir, ancak bir kuruluşta kullanılan her ek sunucu, iş istasyonu, kullanıcı hesabı ve uygulama güvenliği sağlanması gereken başka bir nesne ekler. Bir kuruluşun BT altyapısının her yönünü düzgün bir şekilde güvenli hale getirmek zor ve hatta imkansız olabileceğinden, öncelikle, genellikle Active Directory'deki yerleşik ayrıcalıklı hesaplar ve gruplar ve iş istasyonları ve üye sunuculardaki ayrıcalıklı yerel hesaplar olan, ayrıcalığı en büyük riski oluşturan hesaplara odaklanmanız gerekir.

İş İstasyonlarında ve Üye Sunucularda Yerel Yönetici Hesaplarının Güvenliğini Sağlama

Bu belge daha önce açıklandığı gibi Active Directory'nin güvenliğini sağlamaya odaklansa da, dizine yönelik saldırıların çoğu tek tek konaklara yönelik saldırılar olarak başlar. Üye sistemlerde yerel grupların güvenliğini sağlamaya yönelik tam yönergeler sağlanamaz, ancak iş istasyonlarında ve üye sunucularda yerel Yönetici hesaplarının güvenliğini sağlamaya yardımcı olmak için aşağıdaki öneriler kullanılabilir.

Yerel Yönetici Hesaplarının Güvenliğini Sağlama

Windows'un şu anda temel destek kapsamındaki tüm sürümlerinde, yerel Yönetici hesabı varsayılan olarak devre dışı bırakılır ve bu da hesabı karma geçiş ve diğer kimlik bilgisi hırsızlığı saldırıları için kullanılamaz hale getirir. Ancak, eski işletim sistemlerini içeren veya yerel Yönetici hesaplarının etkinleştirildiği etki alanlarında, bu hesaplar üye sunucular ve iş istasyonları arasında güvenliğin aşılması için daha önce açıklandığı gibi kullanılabilir. Bu nedenle, etki alanına katılmış sistemlerde tüm yerel Yönetici hesapları için aşağıdaki denetimler önerilir.

Bu denetimleri uygulamak için ayrıntılı yönergeler Ek H: Yerel Yönetici Hesaplarını ve Gruplarını Güvenli Hale Getirme bölümünde verilmiştir. Ancak bu ayarları uygulamadan önce, yerel Yönetici hesaplarının şu anda bilgisayarlarda hizmetleri çalıştırmak veya bu hesapların kullanılmaması gereken diğer etkinlikleri gerçekleştirmek için ortamda kullanılmadığından emin olun. Bu ayarları bir üretim ortamında uygulamadan önce kapsamlı bir şekilde test edin.

Yerel Yönetici Hesapları için Denetimler

Yerleşik Yönetici hesapları hiçbir zaman üye sunucularda hizmet hesabı olarak kullanılmamalıdır veya yerel bilgisayarlarda oturum açmak için kullanılmamalıdır (hesap devre dışı bırakılsa bile izin verilen Güvenli Mod dışında). Burada açıklanan ayarları uygulamanın amacı, her bilgisayarın yerel Yönetici hesabının koruyucu denetimler ilk kez tersine çevrilmediği sürece kullanılabilir olmasını önlemektir. Bu denetimleri uygulayarak ve Yönetici hesaplarını değişiklikleri izleyerek, yerel Yönetici hesaplarını hedefleyen bir saldırının başarılı olma olasılığını önemli ölçüde azaltabilirsiniz.

Domain-Joined Sistemlerde Yönetici Hesaplarını Kısıtlamak için GPO'ları Yapılandırma

Oluşturduğunuz ve her etki alanındaki iş istasyonu ve üye sunucu OU'larına bağladığınız bir veya daha fazla GPO'da, Yönetici hesabını Bilgisayar Yapılandırması\İlkeler\Windows Ayarları\Güvenlik Ayarları\Yerel İlkeler\Kullanıcı Hakları Atamaları'nda aşağıdaki kullanıcı haklarına ekleyin:

• Bu bilgisayara ağ üzerinden erişime izin verme
• Toplu iş olarak oturum açmayı reddet
• Hizmet olarak oturum açmayı reddet
• Uzak Masaüstü Hizmetleri üzerinden oturum açmayı reddet

Bu kullanıcı haklarına Yönetici hesapları eklediğinizde, hesabı etiketleme yöntemiyle yerel Yönetici hesabını mı yoksa etki alanının Yönetici hesabını mı ekleyeceğinize karar verin. Örneğin, NWTRADERS etki alanının Yönetici hesabını bu reddetme haklarına eklemek için hesabı NWTRADERS\Administrator olarak yazar veya NWTRADERS etki alanının Yönetici hesabına göz atarsınız. Yerel Yönetici hesabını kısıtladığınızdan emin olmak için, Grup İlkesi Nesne Düzenleyicisi'nde bu kullanıcı hakları ayarlarına Yönetici yazın.

Uyarı

Yerel Yönetici hesapları yeniden adlandırılsa bile ilkeler geçerli olmaya devam eder.

Bu ayarlar, bilgisayarın Yönetici hesabının yanlışlıkla veya kötü amaçlı olarak etkinleştirilmiş olsa bile diğer bilgisayarlara bağlanmak için kullanılamamasını sağlar. Bir bilgisayarın yerel Yönetici hesabı olağanüstü durum kurtarma senaryolarında kullanılmak üzere tasarlandığından, yerel Yönetici hesabı kullanılarak yapılan yerel oturum açma işlemleri tamamen devre dışı bırakılamaz ve bunu yapmaya da çalışmamalısınız.

Bir üye sunucu veya iş istasyonu, yönetici ayrıcalıkları olan başka yerel hesap olmadan etki alanından koparılırsa, bilgisayar güvenli modda önyüklenebilir, Yönetici hesabı etkinleştirilebilir ve hesap, bilgisayarda onarım yapmak için kullanılabilir. Onarımlar tamamlandığında Yönetici hesabı yeniden devre dışı bırakılmalıdır.

Active Directory'de Yerel Ayrıcalıklı Hesapların ve Grupların Güvenliğini Sağlama

Altı Numaralı Yasa: Bir bilgisayar yalnızca yöneticinin güvenilir olduğu kadar güvenlidir. - On Sabit Güvenlik Yasası (Sürüm 2.0)

Burada sağlanan bilgiler, Active Directory'deki en yüksek ayrıcalıklı yerleşik hesapların ve grupların güvenliğini sağlamaya yönelik genel yönergeler sağlamaya yöneliktir. Ayrıntılı adım adım yönergeler Ek D: Active Directory'de Built-In Yönetici Hesaplarının Güvenliğini Sağlama, Ek E: Active Directory'de Kurumsal Yönetici Gruplarının Güvenliğini Sağlama, Ek F: Active Directory'de Etki Alanı Yönetici Gruplarının Güvenliğini Sağlama ve Ek G: Active Directory'de Yönetici Gruplarının Güvenliğini Sağlama bölümünde de sağlanır.

Bu ayarlardan herhangi birini uygulamadan önce, ortamınıza uygun olup olmadığını belirlemek için tüm ayarları kapsamlı bir şekilde test etmelisiniz. Tüm kuruluşlar bu ayarları uygulayamaz.

Active Directory'de Yerleşik Yönetici Hesaplarının Güvenliğini Sağlama

Active Directory'deki her etki alanında, etki alanının oluşturulmasının bir parçası olarak bir Yönetici hesabı oluşturulur. Bu hesap varsayılan olarak etki alanındaki Etki Alanı Yöneticileri ve Yönetici gruplarının bir üyesidir ve etki alanı orman kök etki alanıysa, hesap aynı zamanda Enterprise Admins grubunun da üyesidir. Bir etki alanının yerel Yönetici hesabının kullanımı yalnızca ilk yapılandırma faaliyetleri ve mümkünse olağanüstü durum kurtarma senaryoları için ayrılmalıdır. Başka hiçbir hesabın kullanılamaması durumunda onarımları etkilemek için yerleşik bir Yönetici hesabının kullanılabildiğinden emin olmak için, ormandaki herhangi bir etki alanındaki Yönetici hesabının varsayılan üyeliğini değiştirmemelisiniz. Bunun yerine, ormandaki her etki alanındaki Yönetici hesabının güvenliğini sağlamaya yardımcı olmak için yönergeleri izlemeniz gerekir. Bu denetimleri uygulamaya yönelik ayrıntılı yönergeler Ek D: Active Directory'de Built-In Yönetici Hesaplarının Güvenliğini Sağlama bölümünde verilmiştir.

Yerleşik Yönetici Hesapları için Denetimler

Burada açıklanan ayarları uygulamanın amacı, bir dizi denetim tersine çevrilmediği sürece her etki alanının Yönetici hesabının (grup değil) kullanılabilir olmasını engellemektir. Bu denetimleri uygulayarak ve Yönetici hesaplarını değişiklikleri izleyerek, etki alanının Yönetici hesabından yararlanarak başarılı bir saldırı olasılığını önemli ölçüde azaltabilirsiniz. Ormanınızdaki her etki alanındaki Yönetici hesabı için aşağıdaki ayarları yapılandırmanız gerekir.

Hesapta "Hesap hassas ve temsilci seçilemiyor" bayrağını etkinleştirin

Varsayılan olarak, Active Directory'deki tüm hesaplara temsilci atanabilir. Yetki devri, bir bilgisayar veya hizmetin, bilgisayar veya hizmette kimlik doğrulaması yapmış bir hesabın kimlik bilgilerini, hesap adına hizmet almak üzere diğer bilgisayarlara sunmasına olanak tanır. Hesap hassastır ve etki alanı tabanlı bir hesapta temsilci olarak atanamaz özniteliğini etkinleştirdiğinizde, hesabın kimlik bilgileri ağdaki diğer bilgisayarlara veya hizmetlere sunulamaz; bu, hesabın kimlik bilgilerini diğer sistemlerde kullanmak için temsilciden yararlanan saldırıları sınırlar.

Hesapta "Etkileşimli oturum açmak için akıllı kart gerekiyor" bayrağını etkinleştirin

Bir hesapta etkileşimli oturum açma özniteliği için Akıllı kartı etkinleştirdiğinizde, Windows hesabın parolasını 120 karakterlik rastgele bir değere sıfırlar. Yerleşik Yönetici hesaplarında bu bayrağı ayarlayarak, hesabın parolasının yalnızca uzun ve karmaşık olmadığından, aynı zamanda herhangi bir kullanıcı tarafından bilinmediğinden emin olursunuz. Bu özniteliği etkinleştirmeden önce hesaplar için akıllı kartlar oluşturmak teknik olarak gerekli değildir, ancak mümkünse, hesap kısıtlamalarını yapılandırmadan önce her Yönetici hesabı için akıllı kartlar oluşturulmalıdır ve akıllı kartlar güvenli konumlarda depolanmalıdır.

Etkileşimli oturum açma bayrağı için Akıllı kartın ayarlanması gerekli olsa da hesabın parolasını sıfırlar, ancak hesabın parolasını sıfırlama haklarına sahip bir kullanıcının hesabı bilinen bir değere ayarlamasını ve ağdaki kaynaklara erişmek için hesabın adını ve yeni parolasını kullanmasını engellemez. Bu nedenle, hesapta aşağıdaki ek denetimleri uygulamanız gerekir.

Domain-Joined Sistemlerinde Etki Alanlarının Yönetici Hesaplarını Kısıtlamak için GPO'ları Yapılandırma

Etki alanında Yönetici hesabını devre dışı bırakmak hesabı etkili bir şekilde kullanılamaz hale getirse de, hesabın yanlışlıkla veya kötü amaçlı olarak etkinleştirilmesi durumunda hesapta ek kısıtlamalar uygulamalısınız. Bu denetimler yönetici hesabı tarafından tersine çevrilebilir ancak hedef, bir saldırganın ilerlemesini yavaşlatan ve hesabın verebileceği zararı sınırlayan denetimler oluşturmaktır.

Oluşturduğunuz ve her etki alanındaki iş istasyonu ve üye sunucu OU'larına bağladığınız bir veya daha fazla GPO'da, Bilgisayar Yapılandırması\İlkeler\Windows Ayarları\Güvenlik Ayarları\Yerel İlkeler\Kullanıcı Hakları Atamaları'nda her etki alanının Yönetici hesabını aşağıdaki kullanıcı haklarına ekleyin:

• Bu bilgisayara ağ üzerinden erişime izin verme
• Toplu iş olarak oturum açmayı reddet
• Hizmet olarak oturum açmayı reddet
• Uzak Masaüstü Hizmetleri üzerinden oturum açmayı reddet

Uyarı

Bu ayara yerel Yönetici hesapları eklediğinizde, yerel Yönetici hesaplarını mı yoksa etki alanı Yönetici hesaplarını mı yapılandıracağınız belirtmelisiniz. Örneğin, NWTRADERS etki alanının yerel Yönetici hesabını bu reddetme haklarına eklemek için hesabı NWTRADERS\Administrator olarak yazmanız veya NWTRADERS etki alanının yerel Yönetici hesabına göz atmalısınız. Grup İlkesi Nesne Düzenleyicisi'nde bu kullanıcı hakları ayarlarına Yönetici yazarsanız, GPO'nun uygulandığı her bilgisayarda yerel Yönetici hesabını kısıtlarsınız.

Üye sunucularda ve iş istasyonlarında yerel Yönetici hesaplarını etki alanı tabanlı Yönetici hesaplarıyla aynı şekilde kısıtlamanızı öneririz. Bu nedenle, genellikle ormandaki her etki alanı için Yönetici hesabını ve yerel bilgisayarlar için Yönetici hesabını bu kullanıcı hakları ayarlarına eklemeniz gerekir.

Etki Alanı Denetleyicilerinde Yönetici Hesaplarını Kısıtlamak için GPO'ları Yapılandırma

Ormandaki her etki alanında, Her etki alanının Yönetici hesabını Bilgisayar Yapılandırması\İlkeler\Windows Ayarları\Güvenlik Ayarları\Yerel İlkeler\Kullanıcı Hakları Atamaları'nda aşağıdaki kullanıcı haklarına eklemek için Varsayılan Etki Alanı Denetleyicileri ilkesi veya Etki Alanı Denetleyicileri OU'ya bağlı bir ilke değiştirilmelidir:

• Bu bilgisayara ağ üzerinden erişime izin verme
• Toplu iş olarak oturum açmayı reddet
• Hizmet olarak oturum açmayı reddet
• Uzak Masaüstü Hizmetleri üzerinden oturum açmayı reddet

Uyarı

Bu ayarlar, bir etki alanı denetleyicisine bağlanmak için yerel Yönetici hesabının kullanılamamasını sağlar, ancak hesap etkinleştirilirse etki alanı denetleyicilerinde yerel olarak oturum açabilir. Bu hesabın yalnızca olağanüstü durum kurtarma senaryolarında etkinleştirilmesi ve kullanılması gerektiğinden, en az bir etki alanı denetleyicisine fiziksel erişimin sağlanacağı veya etki alanı denetleyicilerine uzaktan erişim izni olan diğer hesapların kullanılabilmesi beklenir.

Yerleşik Yönetici Hesaplarının Denetimini Yapılandırma

Her etki alanının Yönetici hesabının güvenliğini sağladıktan ve devre dışı bırakdığınızda, hesapta yapılan değişiklikleri izlemek için denetimi yapılandırmanız gerekir. Hesap etkinleştirilirse, parolası sıfırlanırsa veya hesapta başka değişiklikler yapılırsa, kuruluşunuzdaki olay yanıtı ekiplerine ek olarak AD DS yönetiminden sorumlu kullanıcılara veya ekiplere uyarılar gönderilmelidir.

Yöneticilerin, Etki Alanı Yöneticilerinin ve Kurumsal Yönetici Gruplarının Güvenliğini Sağlama

Kurumsal Yönetici Gruplarının Güvenliğini Sağlama

Orman kök etki alanında yer alan Enterprise Admins grubu, daha önce açıklandığı gibi ve Ek D: Active Directory'de Built-In Yönetici Hesaplarının Güvenliğini Sağlama bölümünde güvenlik altına alınması koşuluyla, etki alanının yerel Yönetici hesabının olası özel durumu dışında günlük olarak hiçbir kullanıcı içermemelidir.

EA erişimi gerektiğinde, hesapları EA haklarına ve izinlerine ihtiyaç duyan kullanıcılar geçici olarak Enterprise Admins grubuna yerleştirilmelidir. Kullanıcılar yüksek ayrıcalıklı hesapları kullanıyor olsa da, yanlışlıkla yanlış kullanım veya yanlış yapılandırma olasılığını en aza indirmek için etkinlikleri denetlenmeli ve tercihen değişiklikleri yapan bir kullanıcı ve değişiklikleri gözlemleyen başka bir kullanıcı ile gerçekleştirilmelidir. Etkinlikler tamamlandığında hesaplar EA grubundan kaldırılmalıdır. Bu, el ile gerçekleştirilen yordamlar ve belgelenmiş süreçler, üçüncü taraf ayrıcalıklı kimlik/erişim yönetimi (PIM/PAM) yazılımı veya her ikisinin birleşimiyle gerçekleştirilebilir. Active Directory'de ayrıcalıklı grupların üyeliğini denetlemek için kullanılabilecek hesap oluşturma yönergeleri , Kimlik Bilgisi Hırsızlığı için Çekici Hesaplar'da ve ayrıntılı yönergeler Ek I: Active Directory'de Korumalı Hesaplar ve Gruplar için Yönetim Hesapları Oluşturma bölümünde sağlanır.

Kuruluş Yöneticileri, varsayılan olarak ormandaki her etki alanındaki yerleşik Administrators grubunun üyeleridir. Bir orman olağanüstü durum kurtarma senaryosunda EA hakları gerekeceği için Enterprise Admins grubunun her etki alanındaki Administrators gruplarından kaldırılması uygunsuz bir değişikliktir. Enterprise Admins grubu bir ormandaki Administrators gruplarından kaldırılmışsa, her etki alanındaki Administrators grubuna eklenmelidir ve aşağıdaki ek denetimler uygulanmalıdır:

• Daha önce açıklandığı gibi, Enterprise Admins grubu, orman kök etki alanının Yönetici hesabı dışında günlük olarak hiçbir kullanıcı içermemelidir. Bu hesap, Ek D: Active Directory'de Built-In Yönetici Hesaplarının Güvenliğini Sağlama bölümünde açıklandığı gibi güvenli hale getirilmelidir.
• Her etki alanındaki üye sunucuları ve iş istasyonlarını içeren OU'lara bağlı GPO'larda EA grubu aşağıdaki kullanıcı haklarına eklenmelidir:
  • Bu bilgisayara ağ üzerinden erişime izin verme
  • Toplu iş olarak oturum açmayı reddet
  • Hizmet olarak oturum açmayı reddet
  • Yerel olarak oturum açmayı reddet
  • Uzak Masaüstü Hizmetleri aracılığıyla oturum açmayı reddedin.

Bu, EA grubunun üyelerinin üye sunucularda ve iş istasyonlarında oturum açmasını engeller. Atlama sunucuları etki alanı denetleyicilerini ve Active Directory'yi yönetmek için kullanılıyorsa, atlama sunucularının kısıtlayıcı GPO'ların bağlı olmadığı bir OU'da bulunduğundan emin olun.

• EA grubunun özelliklerinde veya üyeliğinde herhangi bir değişiklik yapıldığında denetim uyarıları gönderecek şekilde yapılandırılmalıdır. Bu uyarılar, Active Directory yönetiminden ve olay yanıtlarından sorumlu kullanıcılara veya ekiplere en azından gönderilmelidir. Ayrıca, EA grubunun meşru bir şekilde doldurulması durumunda bildirim prosedürleri dahil olmak üzere, EA grubunu geçici olarak doldurmaya yönelik süreçleri ve prosedürleri tanımlamanız gerekir.

Etki Alanı Yönetici Gruplarının Güvenliğini Sağlama

Enterprise Admins grubunda olduğu gibi, Etki Alanı Yöneticileri gruplarında üyelik yalnızca derleme veya olağanüstü durum kurtarma senaryolarında gereklidir. Ek D: Active Directory'de Built-In Yönetici Hesaplarının Güvenliğini Sağlama başlığı altında açıklandığı gibi güvenlik altına alınmışsa, DA grubunda etki alanı için yerel Yönetici hesabı dışında günlük kullanıcı hesabı olmamalıdır.

DA erişimi gerektiğinde, bu erişim düzeyine ihtiyaç duyan hesaplar söz konusu etki alanının DA grubuna geçici olarak yerleştirilmelidir. Kullanıcılar yüksek ayrıcalıklı hesapları kullanıyor olsa da etkinlikler denetlenmeli ve tercihen değişiklikleri yapan bir kullanıcı ve yanlışlıkla yanlış kullanım veya yanlış yapılandırma olasılığını en aza indirmek için değişiklikleri gözlemleyen başka bir kullanıcı ile gerçekleştirilmelidir. Etkinlikler tamamlandığında, hesaplar Domain Admins grubundan kaldırılmalıdır. Bu, üçüncü taraf ayrıcalıklı kimlik/erişim yönetimi (PIM/PAM) yazılımı veya her ikisinin bir bileşimi aracılığıyla el ile yapılan yordamlar ve belgelenmiş işlemler aracılığıyla gerçekleştirilebilir. Active Directory'de ayrıcalıklı grupların üyeliğini denetlemek için kullanılabilecek hesap oluşturma yönergeleri Ek I: Active Directory'de Korumalı Hesaplar ve Gruplar için Yönetim Hesapları Oluşturma bölümünde sağlanır.

Etki Alanı Yöneticileri varsayılan olarak, ilgili etki alanlarındaki tüm üye sunucularda ve iş istasyonlarında yerel Yöneticiler grubunun üyeleridir. Desteklenebilirlik ve olağanüstü durum kurtarma seçeneklerini etkilediği için bu varsayılan iç içe yerleştirme değiştirilmemelidir. Etki Alanı Yöneticileri grupları üye sunuculardaki yerel Administrators gruplarından kaldırılmışsa, bağlı GPO'lardaki kısıtlı grup ayarları aracılığıyla etki alanındaki her üye sunucu ve iş istasyonundaki Yöneticiler grubuna eklenmelidir. Ek F'de ayrıntılı olarak açıklanan aşağıdaki genel denetimler : Active Directory'de Etki Alanı Yönetici Gruplarının Güvenliğini Sağlama da uygulanmalıdır.

Ormandaki her etki alanındaki Domain Admins grubu için:

1. DA grubundan, Ek D: Active Directory'de Built-In Yönetici Hesaplarının Güvenliğini Sağlama başlığı altında açıklandığı şekilde güvenlik altına alınmış olması koşuluyla etki alanındaki yerleşik Yönetici hesabı hariç, tüm üyeleri kaldırın.

2. Her etki alanındaki üye sunucuları ve iş istasyonlarını içeren OU'lara bağlı GPO'larda DA grubu aşağıdaki kullanıcı haklarına eklenmelidir:

   • Bu bilgisayara ağ üzerinden erişime izin verme
   • Toplu iş olarak oturum açmayı reddet
   • Hizmet olarak oturum açmayı reddet
   • Yerel olarak oturum açmayı reddet
   • Uzak Masaüstü Hizmetleri üzerinden oturum açmayı reddet

   Bu, DA grubunun üyelerinin üye sunucularda ve iş istasyonlarında oturum açmasını engeller. Atlama sunucuları etki alanı denetleyicilerini ve Active Directory'yi yönetmek için kullanılıyorsa, atlama sunucularının kısıtlayıcı GPO'ların bağlı olmadığı bir OU'da bulunduğundan emin olun.

3. Denetim, DA grubunun özelliklerinde veya üyeliğinde herhangi bir değişiklik yapılırsa uyarı gönderecek şekilde yapılandırılmalıdır. Bu uyarılar, AD DS yönetiminden ve olay yanıtlarından sorumlu kullanıcılara veya ekiplere en azından gönderilmelidir. Ayrıca, grubun meşru popülasyonu gerçekleştirildiğinde bildirim yordamları da dahil olmak üzere DA grubunu geçici olarak doldurmaya yönelik işlemler ve yordamlar tanımlamanız gerekir.

Active Directory'de Yönetici Gruplarının Güvenliğini Sağlama

EA ve DA gruplarında olduğu gibi, Yöneticiler (BA) grubu üyeliği yalnızca derleme veya olağanüstü durum kurtarma senaryolarında gereklidir. Ek D: Active Directory'de Built-In Yönetici Hesaplarının Güvenliğini Sağlama başlığı altında açıklandığı gibi güvenlik altına alınmışsa, Yöneticiler grubunda etki alanının yerel Yönetici hesabı dışında günlük kullanıcı hesabı olmamalıdır.

Yöneticiler erişimi gerektiğinde, bu erişim düzeyine ihtiyaç duyan hesaplar, söz konusu etki alanının Yöneticiler grubuna geçici olarak yerleştirilmelidir. Kullanıcılar yüksek ayrıcalıklı hesapları kullanıyor olsa da, etkinlikler denetlenmeli ve tercihen, yanlışlıkla kötüye kullanım veya yanlış yapılandırma olasılığını en aza indirmek için değişiklikleri gerçekleştiren bir kullanıcı ve değişiklikleri gözlemleyen başka bir kullanıcı ile gerçekleştirilmelidir. Etkinlikler tamamlandığında, hesaplar yöneticiler grubundan hemen kaldırılmalıdır. Bu, üçüncü taraf ayrıcalıklı kimlik/erişim yönetimi (PIM/PAM) yazılımı veya her ikisinin bir bileşimi aracılığıyla el ile yapılan yordamlar ve belgelenmiş işlemler aracılığıyla gerçekleştirilebilir.

Yöneticiler varsayılan olarak, ilgili etki alanlarındaki AD DS nesnelerinin çoğunun sahipleridir. Bu grupta üyelik, sahiplik veya nesnelerin kontrolünü ele geçirme becerisinin gerekli olduğu yapılandırma ve olağanüstü durum kurtarma senaryolarında zorunlu olabilir. Ayrıca, DA'lar ve EA'lar, Administrators grubundaki varsayılan üyelikleri sayesinde bir dizi haklarını ve izinlerini devralır. Active Directory'deki ayrıcalıklı gruplar için varsayılan grup iç içe yerleştirme değiştirilmemelidir ve her etki alanının Administrators grubu Ek G: Active Directory'de Yönetici Gruplarının Güvenliğini Sağlama bölümünde ve aşağıdaki genel yönergelerde açıklandığı gibi güvenli hale getirilmelidir.

1. Active Directory'de Ek D: Built-In Yönetici Hesaplarının Güvenliğini Sağlama başlığı altında açıklandığı gibi güvenlik altına alınmış olması koşuluyla, etki alanının yerel Yönetici hesabı dışında, Yöneticiler grubundan tüm üyeleri kaldırın.

2. Etki alanının Yöneticiler grubunun üyelerinin üye sunucularda veya iş istasyonlarında hiçbir zaman oturum açmaları gerekmez. Her etki alanındaki iş istasyonuna ve üye sunucu OU'larına bağlı bir veya daha fazla GPO'da, Yöneticiler grubu aşağıdaki kullanıcı haklarına eklenmelidir:

   • Bu bilgisayara ağ üzerinden erişime izin verme
   • Toplu iş olarak oturum açmayı reddet,
   • Hizmet olarak oturum açmayı reddet
   • Bu, Administrators grubunun üyelerinin oturum açmak veya üye sunuculara veya iş istasyonlarına bağlanmak için kullanılmasını (birden çok denetim ilk kez ihlal edilmediği sürece), kimlik bilgilerinin önbelleğe alınmasını ve böylece güvenliğinin aşılmasını engeller. Ayrıcalıklı bir hesap hiçbir zaman daha az ayrıcalıklı bir sistemde oturum açmak için kullanılmamalıdır ve bu denetimlerin zorunlu olması bir dizi saldırıya karşı koruma sağlar.

3. Ormandaki her etki alanındaki etki alanı denetleyicileri OU'sunda, Administrators grubuna aşağıdaki kullanıcı hakları verilmelidir (henüz bu haklara sahip değilseler), Bu da Administrators grubunun üyelerinin orman genelinde olağanüstü durum kurtarma senaryosu için gerekli işlevleri gerçekleştirmesine olanak tanır:

   • Bu bilgisayara ağdan erişin
   • Yerel olarak oturum açmayı kabul et
   • Uzak Masaüstü Hizmetleri üzerinden oturum açmaya izin ver

4. Yöneticiler grubunun özelliklerinde veya üyeliğinde herhangi bir değişiklik yapılırsa, denetim uyarıları gönderecek şekilde yapılandırılmalıdır. Bu uyarılar, AD DS yönetiminden sorumlu ekibin üyelerine en azından gönderilmelidir. Uyarılar ayrıca güvenlik ekibinin üyelerine de gönderilmelidir ve Yöneticiler grubunun üyeliğini değiştirmek için yordamlar tanımlanmalıdır. Özellikle, bu süreçler, Yöneticiler grubunun değiştirileceği sırada güvenlik ekibinin bilgilendirileceği bir prosedür içermelidir; böylece uyarılar gönderildiğinde, bunlar beklenen olur ve alarm tetiklenmez. Ayrıca, Yöneticiler grubunun kullanımı tamamlandığında ve kullanılan hesaplar gruptan kaldırıldığında güvenlik ekibine bildirmeye yönelik işlemler uygulanmalıdır.

Uyarı

GPO'lardaki Yöneticiler grubuna kısıtlamalar uyguladığınızda, Windows ayarları etki alanının Yöneticiler grubuna ek olarak bilgisayarın yerel Yöneticiler grubunun üyelerine uygular. Bu nedenle, Yöneticiler grubuna kısıtlamalar uygularken dikkatli olmanız gerekir. Yöneticiler grubunun üyeleri için ağ, toplu iş ve hizmet oturum açmalarını yasaklamanın mümkün olduğu her yerde kullanılması önerilse de, Uzak Masaüstü Hizmetleri aracılığıyla yerel oturum açmaları veya oturum açmaları kısıtlamayın. Bu oturum açma türlerinin engellenmesi, yerel Yöneticiler grubunun üyeleri tarafından bir bilgisayarın yasal yönetimini engelleyebilir. Aşağıdaki ekran görüntüsünde, yerleşik yerel veya etki alanı Yöneticileri gruplarının kötüye kullanımına ek olarak yerleşik yerel ve etki alanı Yönetici hesaplarının kötüye kullanımını engelleyen yapılandırma ayarları gösterilmektedir. Uzak Masaüstü Hizmetleri aracılığıyla oturum açmayı reddet kullanıcı hakkının Yöneticiler grubunu içermediğini unutmayın, çünkü bu ayarın eklenmesi, yerel bilgisayarın Administrators grubunun üyesi olan hesaplar için bu oturum açmaları da engeller. Bilgisayarlardaki hizmetler bu bölümde açıklanan ayrıcalıklı gruplardan herhangi biri bağlamında çalışacak şekilde yapılandırılmışsa, bu ayarların uygulanması hizmetlerin ve uygulamaların başarısız olmasına neden olabilir. Bu nedenle, bu bölümdeki tüm önerilerde olduğu gibi, ortamınızda uygulanabilirlik için ayarları kapsamlı bir şekilde test etmelisiniz.

Role-Based Active Directory için Erişim Kontrolleri (RBAC)

Genel olarak, rol tabanlı erişim denetimleri (RBAC), kullanıcıları gruplandırmaya ve iş kurallarına göre kaynaklara erişim sağlamaya yönelik bir mekanizmadır. Active Directory söz konusu olduğunda, AD DS için RBAC uygulanması, rol üyelerine günlük yönetim görevlerini aşırı ayrıcalıklar vermeden gerçekleştirme izni vermek için hak ve izinlerin atandığı roller oluşturma sürecidir. Active Directory için RBAC, yerel araçlar ve arabirimler aracılığıyla, zaten sahip olabileceğiniz yazılımlardan yararlanarak, üçüncü taraf ürünler satın alarak veya bu yaklaşımların herhangi bir bileşimiyle tasarlanabilir ve uygulanabilir. Bu bölüm, Active Directory için RBAC uygulamak için adım adım yönergeler sağlamaz, bunun yerine AD DS yüklemelerinizde RBAC uygulamak için bir yaklaşım seçerken göz önünde bulundurmanız gereken faktörleri açıklar.

Active Directory için RBAC'ye Yerel Yaklaşımlar

En basit RBAC uygulamasında, rolleri AD DS grupları olarak uygulayabilir ve belirlenen rol kapsamında günlük yönetim gerçekleştirmelerine izin veren gruplara temsilci hakları ve izinleri verebilirsiniz.

Bazı durumlarda, Active Directory'deki mevcut güvenlik grupları bir iş işlevine uygun haklar ve izinler vermek için kullanılabilir. Örneğin, BT kuruluşunuzdaki belirli çalışanlar DNS bölgelerinin ve kayıtlarının yönetiminden ve yönetiminden sorumluysa, bu sorumlulukları atamak, her DNS yöneticisi için hesap oluşturmak ve bunu Active Directory'deki DNS Yöneticileri grubuna eklemek kadar basit olabilir. Daha yüksek ayrıcalıklı grupların aksine, DNS Yöneticileri grubunun Active Directory genelinde çok az güçlü hakkı vardır, ancak bu grubun üyelerine DNS yönetimini yapabilmelerini sağlayan izinler verilmiştir ve yine de tehlikeye açık olup, kötüye kullanım ayrıcalıkların yükseltilmesine neden olabilir.

Diğer durumlarda, güvenlik grupları oluşturmanız ve grupların üyelerinin belirlenen yönetim görevlerini gerçekleştirmesine izin vermek için Active Directory nesneleri, dosya sistemi nesneleri ve kayıt defteri nesneleri için hakları ve izinleri temsilci olarak atamanız gerekebilir. Örneğin, Yardım Masası operatörleriniz unutulan parolaları sıfırlamaktan, bağlantı sorunlarıyla ilgili kullanıcılara yardımcı olmak ve uygulama ayarlarını gidermekle sorumluysa, Active Directory'deki kullanıcı nesnelerinde temsilci seçme ayarlarını, Yardım Masası kullanıcılarının kullanıcıların yapılandırma ayarlarını görüntülemek veya değiştirmek için kullanıcıların bilgisayarlarına uzaktan bağlanmasına izin veren ayrıcalıklarla birleştirmeniz gerekebilir. Tanımladığınız her rol için şunları tanımlamanız gerekir:

1. Rol üyelerinin günlük olarak hangi görevleri gerçekleştirdiğini ve hangi görevlerin daha az sıklıkla gerçekleştirildiğini.
2. Bir rolün hangi sistemlerde ve hangi uygulamalarda üyelerine hak ve izin verilmesi gerektiği.
3. Bir rolde hangi kullanıcılara üyelik verilmelidir?
4. Rol üyeliklerinin yönetiminin nasıl gerçekleştirileceği.

Birçok ortamda, Active Directory ortamının yönetimi için rol tabanlı erişim denetimlerini el ile oluşturmak, uygulamak ve bakımını yapmak zor olabilir. BT altyapınızın yönetimine yönelik rolleri ve sorumlulukları açıkça tanımladıysanız, yönetilebilir bir yerel RBAC dağıtımı oluşturmanıza yardımcı olması için ek araçlardan yararlanmak isteyebilirsiniz. Örneğin, Forefront Identity Manager (FIM) ortamınızda kullanılıyorsa, yönetim rollerinin oluşturulmasını ve popülasyonunu otomatikleştirmek için FIM kullanabilirsiniz ve bu da devam eden yönetimi kolaylaştırabilir. Microsoft Endpoint Configuration Manager ve System Center Operations Manager (SCOM) kullanıyorsanız, yönetim ve izleme işlevlerini temsilci olarak atamak ve ayrıca etki alanındaki sistemler arasında tutarlı yapılandırma ve denetim uygulamak için uygulamaya özgü rolleri kullanabilirsiniz. Ortak anahtar altyapısı (PKI) uyguladıysanız, ortamı yönetmekle sorumlu BT personeli için akıllı kartlar verebilir ve bunları gereklilik haline getirebilirsiniz. FIM Kimlik Bilgisi Yönetimi (FIM CM) ile yönetim personeliniz için rollerin ve kimlik bilgilerinin yönetimini bile birleştirebilirsiniz.

Diğer durumlarda, bir kuruluşun "hazır" işlevsellik sağlayan üçüncü taraf RBAC yazılımı dağıtmayı düşünmesi tercih edilebilir. Active Directory, Windows ve Windows dışı dizinler ve işletim sistemleri için RBAC için ticari, kullanıma hazır (COTS) çözümler bir dizi satıcı tarafından sunulmaktadır. Yerel çözümler ve üçüncü taraf ürünler arasında seçim yaparken aşağıdaki faktörleri dikkate almanız gerekir:

1. Bütçe: Zaten sahip olabileceğiniz yazılım ve araçları kullanarak RBAC'nin geliştirilmesine yatırım yaparak, bir çözümün dağıtımında yer alan yazılım maliyetlerini azaltabilirsiniz. Ancak yerel RBAC çözümleri oluşturma ve dağıtma konusunda deneyimli personeliniz yoksa çözümünüzü geliştirmek için danışmanlık kaynaklarıyla etkileşim kurmanız gerekebilir. Özellikle bütçeniz sınırlıysa, özel olarak geliştirilmiş bir çözümün beklenen maliyetlerini ve "hazır" çözüm dağıtma maliyetlerini dikkatle değerlendirmeniz gerekir.
2. BT ortamının bileşimi: Ortamınız öncelikli olarak Windows sistemlerinden oluşuyorsa veya Zaten Windows dışı sistemlerin ve hesapların yönetimi için Active Directory'yi kullanıyorsanız, özel yerel çözümler ihtiyaçlarınız için en uygun çözümü sağlayabilir. Altyapınız Windows çalıştırmayan ve Active Directory tarafından yönetilmeyen birçok sistem içeriyorsa, Windows dışı sistemleri active Directory ortamından ayrı olarak yönetme seçeneklerini göz önünde bulundurmanız gerekebilir.
3. Çözümdeki ayrıcalık modeli: Bir ürün, hizmet hesaplarının Active Directory'de yüksek ayrıcalıklı gruplara yerleştirilmesini kullanıyorsa ve RBAC yazılımına aşırı ayrıcalık verilmesini gerektirmeyen seçenekler sunmuyorsa, Active Directory saldırı yüzeyinizi gerçekten azaltmadıysanız yalnızca dizindeki en ayrıcalıklı grupların bileşimini değiştirmiş olursunuz. Bir uygulama satıcısı, hizmet hesapları için, hesapların gizliliğinin ihlal edilme ve kötü amaçlı olarak kullanılma olasılığını en aza indiren denetimler sağlayamadığı sürece, diğer seçenekleri göz önünde bulundurmak isteyebilirsiniz.

Ayrıcalıklı Kimlik Yönetimi

Ayrıcalıklı kimlik yönetimi (PIM), bazen ayrıcalıklı hesap yönetimi (PAM) veya ayrıcalıklı kimlik bilgisi yönetimi (PCM) olarak da adlandırılır; altyapınızdaki ayrıcalıklı hesapları yönetme yaklaşımlarının tasarımı, oluşturulması ve uygulanmasıdır. Genel olarak, PIM, hesaplara kalıcı olarak ayrıcalık eklemek yerine, onarım ya da müdahale gerektiren işlemleri gerçekleştirmek için gereken geçici haklar ve izinler sağlayan mekanizmalar sunar. PIM işlevselliğinin el ile oluşturulup oluşturulmadığı veya üçüncü taraf yazılım dağıtımı yoluyla uygulanıp uygulanmadığı aşağıdaki özelliklerden biri veya daha fazlası kullanılabilir:

• Ayrıcalıklı hesapların parolalarının "ödünç alındığı" ve ilk parolanın atandığı "kasalar", etkinlikler tamamlandığında "iade edilir" ve bu sırada hesaplarda parolalar tekrar sıfırlanır.
• Ayrıcalıklı kimlik bilgilerinin kullanımıyla ilgili zamana bağlı kısıtlamalar
• Tek kullanımlık kimlik bilgileri
• Gerçekleştirilen etkinlikleri izleme ve raporlama ile iş akışı tarafından oluşturulan ayrıcalık verme ve etkinlikler tamamlandığında veya ayrılan süre dolduğunda ayrıcalığı otomatik olarak kaldırma
• Betiklerdeki kullanıcı adları ve parolalar gibi sabit kodlanmış kimlik bilgilerinin, gerektiğinde kasalardan kimlik bilgilerinin alınmasına izin veren uygulama programlama arabirimleriyle (API' ler) değiştirilmesi
• Hizmet hesabı kimlik bilgilerinin otomatik yönetimi

Ayrıcalıklı Hesapları Yönetmek için Ayrıcalıksız Hesaplar Oluşturma

Ayrıcalıklı hesapları yönetmenin zorluklarından biri, varsayılan olarak ayrıcalıklı ve korumalı hesapları ve grupları yönetebilen hesapların ayrıcalıklı ve korumalı hesaplar olmasıdır. Active Directory yüklemeniz için uygun RBAC ve PIM çözümleri uygularsanız, çözümler dizindeki en ayrıcalıklı grupların üyeliğini etkili bir şekilde azaltmanıza ve gruplara yalnızca geçici olarak ve gerektiğinde üye eklemenize olanak tanıyan yaklaşımlar içerebilir.

Ancak, yerel RBAC ve PIM'i uygularsanız, hiçbir ayrıcalığı olmayan ve yalnızca ihtiyaç duyulduğunda Active Directory'deki ayrıcalıklı grupları doldurmak ve çıkarmak işlevine sahip hesaplar oluşturmayı göz önünde bulundurmalısınız. Ek I: Active Directory'de Korumalı Hesaplar ve Gruplar için Yönetim Hesapları Oluşturmak , bu amaçla hesap oluşturmak için kullanabileceğiniz adım adım yönergeler sağlar.

Güçlü Kimlik Doğrulama Kontrolleri Uygulamak

6. Yasa: Dışarıda şifrelerinizi tahmin etmeye çalışan biri var. - 10 Sabit Güvenlik Yönetimi Yasaları

Karma geçiş ve diğer kimlik bilgisi hırsızlığı saldırıları Windows işletim sistemlerine özgü değildir ve bunlar yeni değildir. İlk "pass-the-hash" saldırısı 1997'de oluşturuldu. Ancak geçmişte bu saldırılar özelleştirilmiş araçlar gerektiriyordu, başarılarında isabetli veya isabetsizdi ve saldırganların nispeten yüksek beceriye sahip olmasını gerektiriyordu. Kimlik bilgilerini yerel olarak ayıklayan serbestçe kullanılabilir, kullanımı kolay araçların kullanıma sunulması, son yıllarda kimlik bilgisi hırsızlığı saldırılarının sayısında ve başarısında üstel bir artışa neden oldu. Ancak, kimlik bilgisi hırsızlığı saldırıları hiçbir şekilde kimlik bilgilerinin hedeflendiği ve güvenliğinin aşıldığı tek mekanizma değildir.

Kimlik bilgisi hırsızlığı saldırılarına karşı korunmanıza yardımcı olmak için denetimler uygulamanız gerekse de, ortamınızda saldırganlar tarafından hedeflenme olasılığı en yüksek hesapları tanımlamanız ve bu hesaplar için güçlü kimlik doğrulama denetimleri uygulamanız gerekir. En ayrıcalıklı hesaplarınız kullanıcı adları ve parolalar gibi tek faktörlü kimlik doğrulaması kullanıyorsa (her ikisi de bir kimlik doğrulama faktörü olan "bildiğiniz bir şey" ise), bu hesaplar zayıf bir şekilde korunur. Bir saldırganın tek ihtiyacı, kullanıcı adı ve hesapla ilişkili parola bilgisidir ve karmayı geçirme saldırılarına gerek yoktur. Saldırgan tek faktörlü kimlik bilgilerini kabul eden herhangi bir sistemde kullanıcı olarak kimlik doğrulaması yapabilir.

Çok faktörlü kimlik doğrulaması uygulamak sizi karma geçiş saldırılarına karşı korumasa da, korumalı sistemlerle birlikte çok faktörlü kimlik doğrulaması uygulamak bunu yapabilir. Korumalı sistemleri uygulama hakkında daha fazla bilgi , Güvenli Yönetim Konakları Uygulama bölümünde sağlanır ve kimlik doğrulama seçenekleri aşağıdaki bölümlerde ele alınmaktadır.

Genel Kimlik Doğrulama Denetimleri

Akıllı kartlar gibi çok faktörlü kimlik doğrulamasını henüz uygulamadıysanız, bunu yapmayı göz önünde bulundurun. Akıllı kartlar, ortak-özel anahtar çiftinde özel anahtarlar için donanım tarafından zorlanan koruma uygular ve kullanıcı akıllı karta doğru PIN, geçiş kodu veya biyometrik tanımlayıcıyı sunmadığı sürece kullanıcının özel anahtarına erişilmesini veya kullanılmasını önler. Bir kullanıcının PIN'i veya geçiş kodu güvenliği ihlal edilmiş bir bilgisayarda bir tuş vuruşu kaydedicisi tarafından ele geçirilse bile, saldırganın bu PIN'i veya geçiş kodunu yeniden kullanabilmesi için kartın kullanıcıda fiziksel olarak bulunması gerekir.

Uzun ve karmaşık parolaların kullanıcı direnci nedeniyle uygulanmasının zor olduğu durumlarda akıllı kartlar, kullanıcıların kimlik bilgileri deneme yanılma veya gökkuşağı tablosu saldırılarına maruz kalmadan nispeten basit PIN'ler veya geçiş kodları uygulayabilecekleri bir mekanizma sağlar. Akıllı kart PIN'leri Active Directory'de veya yerel SAM veritabanlarında depolanmaz, ancak kimlik bilgileri karmaları kimlik doğrulaması için kullanılan bilgisayarlarda LSASS korumalı bellekte depolanabilir.

VIP Hesapları için Ek Denetimler

Akıllı kartları veya diğer sertifika tabanlı kimlik doğrulama mekanizmalarını uygulamanın bir diğer avantajı, VIP kullanıcıları tarafından erişilebilen hassas verileri korumak için Kimlik Doğrulama Mekanizması Güvencesi'ni kullanmaktır. Kimlik Doğrulama Mekanizması Güvencesi, işlev düzeyinin Windows Server 2012 veya Windows Server 2008 R2 olarak ayarlandığı etki alanlarında kullanılabilir. Etkinleştirildiğinde, Kimlik Doğrulama Mekanizması Güvencesi, kullanıcının kimlik bilgileri sertifika tabanlı bir oturum açma yöntemi kullanılarak oturum açma sırasında doğrulandığında kullanıcının Kerberos belirtecine yönetici tarafından atanan bir genel grup üyeliği ekler.

Bu, kaynak yöneticilerinin, kullanılan sertifika türüne ek olarak, kullanıcının sertifika tabanlı bir oturum açma yöntemi kullanarak oturum açıp açmadığına bağlı olarak dosyalar, klasörler ve yazıcılar gibi kaynaklara erişimi denetlemesini mümkün kılar. Örneğin, bir kullanıcı akıllı kart kullanarak oturum açtığında, kullanıcının ağdaki kaynaklara erişimi, kullanıcının akıllı kart kullanmadığı (kullanıcı bir kullanıcı adı ve parola girerek oturum açtığında) erişimden farklı olarak belirtilebilir. Kimlik Doğrulama Mekanizması Güvencesi hakkında daha fazla bilgi için bkz. Windows Server 2008 R2 Adım Adım Kılavuzu'nda AD DS için Kimlik Doğrulama Mekanizması Güvencesi.

Ayrıcalıklı Hesap Kimlik Doğrulamasını Yapılandırma

Tüm yönetim hesapları için Active Directory'de Etkileşimli oturum açma için akıllı kart iste özniteliğini etkinleştirin ve hesabın Hesap sekmesindeki özniteliklerden (örneğin, cn, ad, sAMAccountName, userPrincipalName ve userAccountControl) yönetici kullanıcı nesnelerinde yapılan değişiklikleri (en azından) denetleyin.

Hesaplarda etkileşimli oturum açmak için akıllı kart gerektir ayarının ayarlanması hesabın parolasını 120 karakterlik rastgele bir değere sıfırlar ve etkileşimli oturum açmalar için akıllı kartlar gerektirir, ancak öznitelik, hesaplardaki parolaları değiştirmelerine izin veren izinlere sahip kullanıcılar tarafından yine de üzerine yazılabilir ve ardından hesaplar yalnızca kullanıcı adı ve parolayla etkileşimli olmayan oturum açma işlemleri oluşturmak için kullanılabilir.

Diğer durumlarda, Active Directory'deki hesapların yapılandırmasına ve Active Directory Sertifika Hizmetleri'ndeki (AD CS) veya üçüncü taraf bir PKI'daki sertifika ayarlarına bağlı olarak, yönetici veya VIP hesapları için Kullanıcı Asıl Adı (UPN) öznitelikleri, burada açıklandığı gibi belirli bir saldırı türü için hedeflenebilir.

Sertifika Sahteciliği için UPN Ele Geçirme

Ortak anahtar altyapılarına (PKI) yönelik saldırıların kapsamlı bir tartışması bu belgenin kapsamı dışında olsa da, genel ve özel PKI'lere yönelik saldırılar 2008'den bu yana katlanarak artacaktır. Genel PKI'lerin ihlalleri genel kullanıma açık hale getirilmiştir, ancak bir kuruluşun iç PKI'sına yönelik saldırılar belki de daha üretkendir. Bu tür saldırılardan biri, bir saldırganın algılanması zor olabilecek şekilde diğer hesapların kimlik bilgilerini sahtekarlık etmesini sağlamak için Active Directory'yi ve sertifikaları kullanır.

Etki alanına katılmış bir sistemde kimlik doğrulaması için bir sertifika sunulduğunda, sertifikadaki Konu veya Konu Alternatif Adı (SAN) özniteliğinin içeriği, sertifikayı Active Directory'deki bir kullanıcı nesnesine eşlemek için kullanılır. Sertifikanın türüne ve nasıl oluşturulduğunda, sertifikadaki Subject özniteliği, aşağıdaki ekran görüntüsünde gösterildiği gibi genellikle bir kullanıcının ortak adını (CN) içerir.

Varsayılan olarak, Active Directory hesabın adı + " "+ soyadını birleştirerek kullanıcının CN'sini oluşturur. Ancak, Active Directory'deki kullanıcı nesnelerinin CN bileşenlerinin benzersiz olması gerekmez veya benzersiz olması garanti değildir ve bir kullanıcı hesabının dizinde farklı bir konuma taşınması, önceki ekran görüntüsünün alt bölmesinde gösterildiği gibi hesabın dizindeki nesnenin tam yolu olan ayırt edici adını (DN) değiştirir.

Sertifika konu adlarının statik veya benzersiz olması garanti edilmediğinden, Konu Alternatif Adı'nın içeriği genellikle Active Directory'deki kullanıcı nesnesini bulmak için kullanılır. Kuruluş sertifika yetkililerinden (Active Directory tümleşik CA'ları) kullanıcılara verilen sertifikaların SAN özniteliği genellikle kullanıcının UPN'sini veya e-posta adresini içerir. UPN'lerin bir AD DS ormanında benzersiz olması garanti edildiğinden, kimlik doğrulama işlemine sertifikalar dahil edilmiş veya dahil olmayan kimlik doğrulamasının bir parçası olarak GENELLIKLE UPN tarafından bir kullanıcı nesnesi bulma işlemi gerçekleştirilir.

Kimlik doğrulama sertifikalarında SAN özniteliklerinde UPN'lerin kullanılması, saldırganlar tarafından sahte sertifikalar elde etmek için kullanılabilir. Bir saldırgan, kullanıcı nesneleri üzerinde UPN okuma ve yazma özelliğine sahip bir hesabın güvenliğini tehlikeye atmışsa, saldırı aşağıdaki gibi uygulanır:

Bir kullanıcı nesnesinde (VIP kullanıcısı gibi) UPN özniteliği geçici olarak farklı bir değere değiştirilir. SAM hesabı adı özniteliği ve CN şu anda da değiştirilebilir, ancak bu genellikle daha önce açıklanan nedenlerle gerekli değildir.

Hedef hesap üzerindeki UPN özniteliği değiştirildiğinde, eski, etkin bir kullanıcı hesabı veya yeni oluşturulmuş bir kullanıcı hesabının UPN özniteliği, başlangıçta hedef hesaba atanmış olan değerle değiştirilir. Eski, etkin kullanıcı hesapları uzun süre oturum açmamış ancak devre dışı bırakılmamış hesaplardır. Bunlar, aşağıdaki nedenlerle "görünürde gizlenmek" isteyen saldırganlar tarafından hedeflenir:

1. Hesap etkinleştirildiğinden ancak yakın zamanda kullanılmadığından, hesabın kullanılması devre dışı bırakılmış bir kullanıcı hesabını etkinleştirmenin mümkün olmadığı şekilde uyarıları tetikleme olasılığı düşüktür.
2. Mevcut bir hesabın kullanılması, yönetim personeli tarafından fark edilebilecek yeni bir kullanıcı hesabı oluşturulmasını gerektirmez.
3. Hala etkin olan eski kullanıcı hesapları genellikle çeşitli güvenlik gruplarına üyedir ve ağ üzerindeki kaynaklara erişimleri vardır, bu da erişimi kolaylaştırır ve mevcut kullanıcılarla uyum sağlamalarını mümkün kılar.

Hedef UPN'nin yapılandırıldığı kullanıcı hesabı, Active Directory Sertifika Hizmetleri'nden bir veya daha fazla sertifika istemek için kullanılır.

Saldırganın hesabı için sertifikalar elde edildiğinde, "yeni" hesap ve hedef hesap üzerindeki UPN'ler özgün değerlerine döndürülür.

Saldırgan artık, hesabı geçici olarak değiştirilmiş önemli VIP kullanıcısıymış gibi kaynaklara ve uygulamalara kimlik doğrulaması yapabilmek için sunabileceği bir veya daha fazla sertifikaya sahiptir. Sertifikaların ve PKI'nın saldırganlar tarafından hedeflenebileceği tüm yolların tam bir tartışması bu belgenin kapsamı dışında olsa da, özellikle hesabın Hesap sekmesindeki özniteliklerden herhangi birinde yapılan değişiklikler için AD DS'deki ayrıcalıklı ve VIP hesaplarını neden izlemeniz gerektiğini gösteren bu saldırı mekanizması sağlanır (örneğin, cn, name, sAMAccountName, userPrincipalName ve userAccountControl). Hesapları izlemeye ek olarak, hesapları değiştirebilecek kişileri mümkün olduğunca küçük bir yönetici kullanıcı kümesiyle kısıtlamanız gerekir. Benzer şekilde, yönetici kullanıcıların hesapları da yetkisiz değişiklikler için korunmalıdır ve izlenmelidir.