Acil Durum Hesapları Nasıl Hazırlanır ve Test Edilir?

Bir organizasyon içerisinde Active Directory (AD) veya Entra ID yönetiyorsanız, muhtemelen acil durum erişim hesaplarıyla karşılaşmışsınızdır; bunlar en kötü senaryolar için yedekte tutulan özel hesaplardır. Bu hesaplar, normal kimlik sistemleriniz başarısız olduğunda yönetimsel can simidi görevi görür. Ancak, tıpkı bir yangın söndürücü gibi, acil durum hesabı da ancak hazır, erişilebilir ve test edilmişse değerlidir.

Acil Durum Hesaplarının Amacı

Acil durum hesaplarının tek bir basit amacı vardır: felaket niteliğinde bir arıza durumunda kritik sistemlere idari erişimi sağlamak. Bu acil durum hesapları, kesintiye dayanıklı, tamamen izole edilmiş ve felakete hazır olmalıdır.

Acil durum hesabı, harici kimlik sağlayıcılarına bağımlı olmadan kimlik doğrulaması yapabilmelidir. Active Directory ortamındaki bir acil durum hesabı etki alanında yerel olarak yer almalıdır. Entra ID için ise, acil durum hesapları yalnızca bulut tabanlı olmalı ve başka bir kimlik sağlayıcısıyla birleştirilmemeli veya senkronize edilmemelidir.

Yöneticiler, kesinti sırasında başarısız olabilecek harici kaynaklara veya güvenlik korumalarına olan bağımlılığı dikkatlice değerlendirmelidir. Bu, Koşullu Erişim politikalarını, Çok Faktörlü Kimlik Doğrulama (MFA) sağlayıcılarını ve ağ bağlantısını içerir. Acil durum hesabının başarılı bir şekilde uygulanması, bozulmuş koşullar altında kullanılabilirliği sağlayarak kesinti dayanıklılığını en üst düzeye çıkarır.

Acil durum hesaplarının hibrit kimlik alanında uzun bir geçmişi vardır. Tehdit ortamı yıllar içinde değiştikçe, acil durum hesaplarının doğru uygulanmasına ilişkin en iyi uygulamalar da değişmiştir. Eski bir uygulamadan daha modern bir yaklaşıma geçmek, yalnızca önemli bir güvenlik kontrolü değil; aynı zamanda bir kuruluşun acil durumlardaki dayanıklılığını da artırır.

Geleneksel Alışkanlıklardan Modern Sistemlere Geçiş

Tarihsel olarak, yerleşik AD Yönetici hesabını korumak, gizlilik ve rotasyonla (hesabın adını değiştirme ve parolayı sıfırlama) ilgiliydi. Güvenliğe daha fazla önem veren kuruluşlar Yönetici hesabını devre dışı bırakabilirken, diğerleri bu hesabın etki alanındaki herhangi bir yerden oturum açmasına izin verebilir.

Yeni Microsoft yönergeleri, Yönetici hesabının yalnızca başka hiçbir hesap kullanılamadığında kullanılması gerektiğini açıkça belirtiyor. Yönergeler, oturum açma haklarının GPO aracılığıyla yalnızca etki alanı denetleyicileriyle sıkı bir şekilde sınırlandırılmasını bile öneriyor. Son güvenlik uygulamaları ayrıca, yerleşik Yönetici hesabı için “Hesap hassastır ve devredilemez” ve “Etkileşimli oturum açma için akıllı kart gereklidir” işaretlerinin kullanılmasını teşvik ediyor. Bu kısıtlamalar, bir kurtarma senaryosu sırasında en az bir etki alanı denetleyicisine fiziksel erişimin mümkün olacağını varsayıyor.

Microsoft’un yönergeleri, kuruluşların en az bir fiziksel etki alanı denetleyicisine sahip olduğu anlayışına dayanmaktadır. Hibrit ortamlarda, etki alanı denetleyicileri genellikle Azure veya AWS’de sanallaştırılır veya bulutta barındırılır. Bu tür bir yapılandırma normal koşullarda sorunsuz çalışır, ancak sanal veya bulut ortamı kullanılamaz hale geldiğinde ne olur? Fiziksel bir etki alanı denetleyicisinin bulunmadığı durumda, kesinti riski birden fazla barındırma platformu veya hipervizör arasında paylaşılmalıdır. Herhangi bir harici sisteme, özellikle bulut mimarilerine güvenmek, acil erişimi riske atar ve yeniden değerlendirilmelidir.

Bulut Bilişim İçin Güncellenmiş Kılavuz

Şirket içi AD’nin aksine, bir Entra ID kiracısının yerleşik bir Yönetici hesabı yoktur. Bunun yerine, yöneticilerin acil erişim hesaplarını daha bilinçli bir şekilde oluşturmaları gerekir. Entra’da acil erişim hesapları için en iyi uygulama yıllar içinde gelişmiştir. İlk kılavuzlar öncelikle diğer ayrıcalıklı hesaplar için uygulanan yaygın güvenlik kontrollerini atlayabilen küresel bir yönetici hesabına odaklanmıştır. Koşullu Erişim politikalarından hariç tutulan ve MFA gereksinimlerinden muaf olan iki bulut tabanlı (onmicrosoft.com) küresel yönetici hesabı, önerilen en sağlıklı sistemi oluşturur.

Microsoft’un mevcut yönergeleri hala iki adet yalnızca bulut tabanlı acil durum erişim hesabını öneriyor, ancak bu hesaplar artık zorunlu çok faktörlü kimlik doğrulama (MFA) gereksiniminden muaf değil . Bunun yerine, acil durum erişim hesaplarının kimlik avına karşı dayanıklı kimlik doğrulama yöntemleri kullanması öneriliyor.

İlginç bir şekilde, bu Microsoft dokümanında Koşullu Erişim dışlamalarını güçlendiren açık bir ifade bulunmuyor; bu, bu hesapların çoğu, hatta tüm Koşullu Erişim politikalarından hariç tutulması gerektiği göz önüne alındığında, bariz bir gözden kaçırma. Kuruluşlar bu hesapları hariç tutmazlarsa, bu hesaplara ihtiyaç duyulduğu senaryolarda yöneticilerin erişimini bir güvenlik riskiyle karşı karşıya kalırlar.

Yaygın Yanlış Yapılandırmalar

Acil durum hesapları görünüşte basit bir teknik detay olarak gözükse de, ufak tefek hatalar ciddi sonuçlar doğurabiliriz. Gelin, sık yapılan birkaç hatayı inceleyelim.

AD Dizin Hizmetleri Geri Yükleme Modu (DSRM) Parolası

Bazı kuruluşlar acil durumlar için DSRM parolasına güvenebilir. Microsoft kılavuzunun öncelikle DSRM hesabından ziyade Yönetici hesabına odaklanmasının nedeni, DSRM hesabının Dizin Hizmetleri Geri Yükleme Modunda yalnızca tek bir etki alanı denetleyicisine yerel erişim sağlaması ve etki alanı genelinde kimlik doğrulaması yapamamasıdır. Büyük ortamlarda, yerleşik Yönetici hesabı etki alanı genelinde yetki sağlar ve bu da onu kurtarma için daha etkili bir can simidi haline getirir.

Tüm MFA Programları Aynı Değildir

Parola anahtarları ve sertifika tabanlı kimlik doğrulama gibi kimlik avına dayanıklı yöntemler, sınıfının en iyisi güvenlik sunarken, çevrimdışı çalışabildikleri için kimlik doğrulama dayanıklılığı söz konusu olduğunda da en iyi seçimdir. Çok faktörlü kimlik doğrulama için diğer yaygın seçenekler yetersizdir. SMS gibi yöntemler operatör kesintilerine tabidir ve Microsoft Authenticator çözümleri kullanıcının kişisel cihazına erişime bağlı olabilir. Dayanıklı kimlik bilgileri hakkında daha fazla bilgiye buradan ulaşabilirsiniz .

Neden İki Hesap Kullanılmalıdır?

İki ayrı acil durum hesabı tutmak operasyonel süreçte önemli bir esneklik sağlar. İki bağımsız hesap, tek bir hata noktası riskini azaltır, çünkü hesaplardan biri kullanılamaz veya erişilemez hale gelebilir. İdeal olarak, farklı konumlarda bulunan ayrı ayrı sorumlular, hesaplardan her birinden sorumludur.

Koşullu Erişim

Entra’da acil durum hesaplarını yapılandırma kılavuzunda açıkça belirtilmese de, bu hesapları Koşullu Erişim politikalarından hariç tutmak son derece önemlidir. Bunun birkaç örneği, eski kimlik doğrulama ve ayrıcalıklı erişim uygulamasını engellemeye yönelik önerilen politikalarda yer almaktadır . Acil durum erişim kimlik doğrulamasına kısıtlamalar uygulamak (yani bunları tüm politikalardan hariç tutmamak) önerilmez.

Paylaşımlı mı, Bireysel Olarak Atanmış mı?

Belirlenmiş bir acil durum hesabı tek bir amaca hizmet eder ve yalnızca acil durumlarda kullanılır. Buna karşılık, yöneticiler tarafından atanan ayrıcalıklı hesaplar günlük olarak kullanılır ve güvenlik açıklarına maruz kalabilir. Paylaşılan, belgelenmiş ve güvenli bir acil durum hesabı, gerektiğinde etkileşimli kontrol sağlarken mevcut riski en aza indirir. Özel bir acil durum hesabının kullanılması, kullanım üzerine özel bir uyarı sürecine de olanak tanır. Ayrıca, kişisel bilgi yönetimi (PIM) uygunluğu, ayrıcalıklı erişim iş istasyonları ve günlük olarak kullanılan diğer güvenlik kontrolleri gibi sorumlu kişi tarafından atanan hesaplar etrafında daha sıkı kontrolleri teşvik eder.

Kimlik Bilgisi Erişim Kontrolleri

Acil durum hesaplarının parolalarının ve çok faktörlü kimlik doğrulama (MFA) cihazlarının doğru yönetimi önemlidir. İdeal olarak, parolalar uzun, rastgele bir karakter dizisi olarak ayarlanmalıdır. Parolalar ve MFA cihazları, düzenli olarak kullanılan kurumsal parola kasası yerine, çevrimdışı bir fiziksel kasada saklanmalıdır. Acil durum hesabı kullanıldıktan sonra, parolası değiştirilmeli ve güvenli hale getirilmelidir.

Test ve Farkındalık

Acil erişimle ilgili en büyük başarısızlık, test eksikliğidir. Kuruluşlar acil durum hesapları oluşturur, kimlik bilgilerini kilitler ve bir daha asla doğrulamazlar. Koşullu Erişim veya senkronizasyon hataları meydana geldiğinde, kuruluşlar genellikle acil durum hesaplarının devre dışı bırakıldığını, süresinin dolduğunu veya yanlış yapılandırıldığını keşfederler. Tıpkı basıncı olmayan bir yangın söndürücü gibi, test edilmemiş bir acil durum hesabı işlevsel olarak işe yaramaz.

Kontrol listesi

Active Directory

1. Her etki alanı için, tüm etki alanı denetleyicilerine yerel oturum açma haklarına sahip bir adet yerleşik Yönetici hesabı bulundurun .
2. Hesabın hassas hesap olduğunu ve devredilemeyeceğini belirten işaretin yapılandırıldığından ve test edildiğinden emin olun .
3. Etkileşimli oturum açma için akıllı kart gerekliliği işaretinin yapılandırıldığından ve test edildiğinden emin olun .
4. Grup İlkesi Nesnelerinin (GPO’lar) oturum açmayı yalnızca etki alanına bağlı sistemlerle sınırlandıracak şekilde yapılandırıldığından emin olun.
5. Alan denetleyicisi konsoluna doğrudan giriş yaparak kimlik bilgilerini test edin.

Cloud Yapı

1. Her biri kimlik avına karşı dayanıklı çok faktörlü kimlik doğrulama (MFA) ile korunan iki bağımsız acil durum hesabı bulundurun .
2. Hesapların yalnızca bulut tabanlı olduğundan , senkronize edilmediğinden veya birleştirilmediğinden emin olun.
3. Bağımlılığı önlemek için hesapları Koşullu Erişimden hariç tutun.
4. Küresel Yönetici rolüne aktif üyelik atayın.

Hibrit Yapı

• Güçlü bir parola belirleyin ve kimlik bilgilerinizi güvenli bir şekilde saklayın (çevrimdışı kasalar/konumlar arasında depolama alanını bölerek).
• Kurtarma planınızın her adımını belgeleyin ve kopyalarını çevrimdışı olarak saklayın.
• Simüle edilmiş kesinti koşulları altında kontrollü bir test cihazından kimlik bilgilerini alma ve oturum açma işlemlerini uygulamak için altı ayda bir “acil durum tatbikatı” gerçekleştirin.
• Acil durum hesabını kullandıktan sonra, olayın ardından kapsamlı bir inceleme yapın ve tüm acil durum kimlik bilgilerini sıfırlayın.
• Acil durum hesap oturum açma uyarılarını bir SIEM sistemine entegre edin veya oturum açma sırasında alarm verecek şekilde yapılandırın.
• Olay müdahale ekibinizi acil durum hesaplarının nerede, ne zaman ve nasıl kullanılacağı konusunda eğitin.
• Bu hesapların sahip olduğu her bağımlılığı belgeleyin ve bunları ortadan kaldırmak için çalışın.

Acil durum erişimi olmazsa olmaz bir güvenlik protololüdür. Hem organizasyonu kurtarmalı hem de pasif ve güvenli kalmalıdır. Bu hesapları yaşayan kontroller olarak ele alın; her mimari değişiklikte gözden geçirin, test edin ve modernize edin. Güvenli sistemler için kendinizi sürekli güncelleyin.

Saygılarımla.