Kategori arşivi: Active Directory

Windows 10 Pro Sürümü için GPO ile Lock Screen Yönetimi- Configure Windows Spotlight on the lock screen

Windows Spotlight, farklı arka plan görüntülerini görüntüleyen ve bazen kilit ekranında öneriler sunan kilit ekranı arka planı için bir seçenek olarak Windows 10 da sunulan bir özelliktir. Bu özellik tüm Windows 10 masa üstü sürümlerinde yer almaktadır.

Bazı şirketlerin iş ihtiyacı nedeni ile lock screen olarak ifade ettiğimiz işletim sistemi ekranının kilitlendiğinde ortaya çıkan bu görselleri kurumsal görseller ile değiştirmek isteyebilir. Bu durumda aşağıdaki makale ile kolaylıkla yapılabilir;

https://docs.microsoft.com/en-us/windows/configuration/windows-spotlight

Fakat bu yöntem Windows 10 Enterprise ve Windows 10 Education sürümleri için çalışan bir yöntemdir.

Aşağıdaki yolu takip edebilirsiniz;

“Computer Configuration\Administrative Templates\Control Panel\Personalization\Force a specific default lock screen and logon image”

Okumaya devam et

Active Directory Kullanılmayan Bilgisayar ve Kullanıcı Hesaplarının Silinmesi

Malum pek çok kez iş yoğunluğu nedeni ile makine ve kullanıcı hesaplarının gerçekten aktif olup olmadığını kontrol edemiyoruz. IDM gibi otomasyona yönelik sistemler ise yüksek bütçeleri ile herkes tarafından alınamayabiliyor. Yine Manage Engine, Lepide ve benzeri 3 parti pek çok üründe benzer işleri yapsa da günün sonunda kobi ve bütçesi bu tarz işler için uygun olmayan müşterilerime kolaylık olması için bir kaç komut paylaşmak istiyorum. Aslında bunu düzenli aylık yapmaları bile güvenlik sıkılaştırmaları için iyi birer adım olacaktır.

Öncelikle son X gündür aktif olmayan kullanıcıları nasıl tespit ederiz?

dsquery user -inactive 10 -limit 0 > c:\komut\stale_account_70gun.txt ( 10= hafta cinsinden yani 70 gün )

Bu bir cmd komut seti olup run-as admin ile çalıştırmanızı öneririm.

Tabiki burada disable olan kullanıcılar da gelecektir ki eğer güvenlik için bakıyorsanız çok anlamlı olmaz. Eğer temizlemek için ise ok çalıştırın ve sonra çıkan sonuçları silin.

Ancak güvenlik için bakıyorsanız aşağıdaki komut daha doğru olacaktır. Bu komut disable olan hesapları getirmeyecektir.

dsquery user -inactive 10 -limit 0 | dsget user -fn -ln -samid -disabled | find /v “dsget” | find /v “samid” | find /v “yes” >>c:\komut\stale_account_70gun.txt

Benzer şekilde bilgisayar hesapları içinde cmd komut seti kullanabilirsiniz;

dsquery computer -inactive 10 -limit 0 ( 10= hafta cinsinden yani 70 gün )

1 Soru 1 Cevap: LastLogon ve LastLogonTimeStamp

Soru: LastLogon ve LastLogonTimeStamp arasındaki fark nedir?

Cevap: Lastlogon kimlik doğrulamayı gerçekleştiren domain controller makinenin kayıt ettiği son logon olma zamanı olup bu kayıt diğer dc makineleri ile replike edilmez.

https://docs.microsoft.com/en-us/windows/desktop/ADSchema/a-lastlogon

LastLogonTimeStamp ise 14 günde bir replike olan öznitelik olup tüm dc makinelerinden bu değer okunabilir.

https://docs.microsoft.com/en-us/windows/desktop/ADSchema/a-lastlogontimestamp

Azure Active Directory Domain Services Nedir?

Active Directory Microsoft firmasının en eski ve en çok bilinen ürünlerinden birisidir. Durum böyle olunca da aslında pek çok firmada yerleşik bir dizin yapısı görmek son derece normal. Bundan dolayı da istemci makineler windows olmasa bile pek çok Microsoft uygulaması veya AD ile entegre uygulama görebiliyoruz. Zaten uygulama üreticileri de bu yaygın kullanım nedeni ile AD entegre ürünler çıkarmaktadır. Hatta uygulamaların yanında alacağınız bir firewall bile bugün AD entegre çalışıyor. Temelde kullanıcı yönetimi nerede ise aslında kullanıcı deneyimini artıracak olan en temel SSO için AD uyumu bir nevi artık endüstri Standartı olmuş durumda. Hatta ilginç bir şekilde bunun standart olmasından dolayı bugün kaleme aldığım Azure AD DS servisinin rakip bir bulut servis sağlayıcının üzerinde uzun yıllardır olması beni biraz şaşırttı doğrusu.

Peki öncelikle mevcut duruma bir bakalım. Yani yerleşik bir Active Directory yapısı olan bir müşteri bunu bulut ortamına taşımak ister ise ne yapabilir?

Öncelikle en kolay yöntem IaaS olarak Azure üzerinde bir sanal makine açıp, daha sonra yerleşik firewall ile azure veri merkezleri arasında bir VPN yapar ve bilindik Additional domain controller kurulumu yapar. Bunu hali hazırda pek çok müşteri zaten yapıyor. Temel kullanım alanları ise, öncelikle azure üzerindeki diğer servislerin yerleşik AD makinelerine gelme ve gitme sürelerinin şu an itibari ile anlık 100ms leri bulması nedeni ile olası gecikmeleri engellemektir. Ek olarak ise olası bir on prem kesintisinde azure dc makineleri felaket senaryoları için kullanıma devam edecektir.

Yukarıdaki şekil karışık mı geldi? Aslında özetle durum aşağıdaki gibidir;

Yani uzak bir şubede ADC kurmaktan hiçbir farkı yok aslında.

Peki başka bir alternatif var mı? Evet, Azure Active Directory servisini kullanabilirsiniz.

Azure Active Directory (Azure AD), Microsoft’un bulut tabanlı kimlik ve erişim yönetimi hizmetidir. Aslında yerleşik AD’ nin yaptığı temel görevleri yerine getirir. Ancak GPO gibi temel olarak yönetebileceğimiz esnek servisleri sunmaz. Burada en temel sorun aslında Windows Server Active Directory web temelli servisleri yönetmek için tasarlanmamıştır. Azure Active Directory ise, Office 365, salesforce ve benzeri REST (Representional State Transfer) API ara birimlerini kullanan web tabanlı hizmetleri desteklemek üzere tasarlanmıştır. Bu nedenle tamamen farklı protokolleri kullanır.

Buradaki amaç temel dizin ve kimlik hizmetlerini -yönetimini, uygulama erişim yönetimi, denetleme ve raporlama, multi-factor authentication, self servis şifre resetleme ve benzeri ek hizmetler ile zenginleştirmektir. Ek hizmetler dememin sebebi bulut hakkında makale yazarken başımıza çok gelen bir olay. Bugün olmayan ancak yarın iş ihtiyaçları nedeni ile sunulacak özellikler olabilir.

Herkesin kullanım motivasyonu farklılık gösterebilir. Örneğin bir IT yöneticisi için yerleşik AD yönetim araçlarına göre Azure portal sayesinde erişim kontrollerini daha görünür (raporlama ve uyarılar gibi) veya MFA sayesinde daha güvenilir yapabilirsiniz. Tabiki yerleşik sistemler için 3 parti ürünler ile MFA özelliğini kullanabilirsiniz. Ancak bu tarz ürünlerin kurulumları son derece kompleks ve maliyetleri yüksektir. Oysaki Azure Active Directory entegrasyonu sonrasında istediğiniz kullanıcılar için MFA açarak kritik hesapların güvenliğini bir üst seviyeye çekmiş oluşunuz.

Ayrıca yine kullanıcı açma ve yönetme gibi işlemlerin provizyon işlemlerini otomatize edebilirsiniz. Yine dahili güvenlik ürünleri sayesinde kimlik avı dolandırıcılığı başta olmak üzere kimlik kaynaklı ataklara karşı çok daha güvenli bir alt yapıya sahip olursunuz.

Bir yazılımcı gözünden bakarsanız;

Bir uygulama geliştiricisi olarak Azure AD, bir kullanıcının önceden var olan kimlik bilgileriyle çalışmasına izin veren standartlara dayalı bir yaklaşım sunar (SSO). Azure AD ayrıca, mevcut kurumsal verileri kullanarak kişiselleştirilmiş uygulama deneyimleri oluşturmanıza yardımcı olabilecek API’ ler sağlar.

Peki neden Azure Active Directory Kullanıyoruz?

Değişen ve gelişen teknoloji ile artık uygulamalar daha kompleks ve yaygın bir erişim ihtiyacına sahip, durum böyle olunca yerleşik ve kapalı olan dizin hizmetlerimizi internete açmak son derece tehlikeli sonuçlar doğurabilir. Durum böyle olunca aslında bu sürekli olarak gelişen iş ihtiyaçlarını karşılamak için mevcut bilgiyi bulut üzerindeki bu servis ile paylaşıp onun sunduğu yeni nesil protokol ve hizmetleri ise bu iş ihtiyaçlarına ihtiyaç duyan sistemlere güvenli ve kararlı bir şekilde sunabilirsiniz.

Peki başka ne var? Sıra geldi aslında makalemizin konusuna.

Malum PaaS kavramı hayatımıza çok fazlaca dokundu. Örneğin IIS veya Apache kurayım, onun güvenlik ayarları, temel yapılandırma ayarları, yedekleme şu bu ile uğraşacağıma bir webapp yaparım atarım buluta bitti. Veya OS kur, yamaları yükle, SQL kur, yapılandır, yedek al şu bu yerine geçerim PaaS SQL’ e oh mis gibi. Tabi şimdi soruyorsunuzdur madem bu kadar her şey güzel neden herkes geçmiyor? Klasik olarak yazdığınız veya tasarladığınız bu uygulamaları tabiki güncellemeniz gerekli. Kurumsal pek çok müşterimdeki web uygulamalarını IaaS yani klasik OS, App Server DB Server’ dan WebApp + PaaS SQL’ e çevirerek inanılmaz hız, güvenlik, kararlılık ve tabiki karlılık sağlıyoruz. Ancak bunun için şirketin bir parça danışmanlık ücreti ödemesi gerekiyor ki mevcut yazılımı PaaS sistemlerde çalışsın. Genelde Türkiye de danışmanlığa pek değer verilmediği için de kazanımdan çok danışmana verilecek para göze battığı için hala klasik mimari ile çalışan binlerce müşteri var.

Madem PaaS’ a giriş yaptık aslında herkesin sorduğu bir şey, pek çok klasik servisin PaaS modeli var, yani yönetimi, bakımı, güvenliği vs bulut sağlayıcısına ait olan bu sistemler üzerinde Active Directory Servisi yok mu? VAR

Azure Active Directory (AD) Domain Services

Peki nedir Azure Active Directory (AD) Domain Services?

Şirket içerisindeki pek çok geleneksel uygulama- Line-of-business (LOB) Active Directory dizin yapısına duyarlı uygulamalardır. Çünkü bunların sağlıklı bir şekilde çalışabilmesi için Windows ile Tümleşik bir şekilde çalışan kimlik doğrulama sevislerine (Kerberos, NTLM) ihtiyaç duymaktadır. Doğal olarak yerleşik sistemlerdeki uygulamaları buluta çıkarmak veya bulut entegrasyonu sayesinde mevcut alt yapınızın daha güvenlik, esnek, çevik olması için bu bağımlılıkları ortadan kaldırmanız gereklidir.

Hali hazırda Dünya üzerinde pek çok hybrid çalışan it alt yapısı görürsünüz. Peki bunlar nasıl başardı?

Mevcut uygulamalar genellikle müşteri veri merkezleri ile azure veri merkezleri arasında site-to-site vpn yaparak azure üzerindeki iş yüklerinin merkezi dizin hizmetlerine erişmesini sağlamaktadır. Bazen bu süreci hızlandırmak için azure üzerinde sanal makine açılır ve bu sayede bir site yapısı ile dizin hizmetleri yönetilir.

Bilinen en iyi yöntem bu olmasına karşın sanal makine, vpn, bakım, yönetim, yedekleme gibi ek maliyetler yüzünden bir alternatif arayışı içerisine girilmiştir.

Tam bu noktada Microsoft daha esnek bir alternatif sunmak için AD Domain servisini tasarlamıştır.

AD Domain servisi temel olarak yerleşik AD sistemlerinin sunduğu domain join, group policy, LDAP, Kerberos/NTLM authentication gibi özellikleri bulut üzerinde sunan bir servistir. Yani Azure Active Directory’ den farklı olarak karakteri on-prem AD servisine benzemektedir. Tek farlı bunun için aşağıdaki hiçbir sorumluluğun size ait olmayışıdır;

Sanal makine yine var ama sizin yönetiminizde değil. Yani aslında IaaS olarak bir sanal kurup, VPN yapıp onu ADC yaptığınız zaman alacağınız tecrübeyle karşı karşıyasınız (tabiki %100 o kadar esnek değil, örnek RDP yapıp DC ye bağlanamıyorsunuz).

Yama yönetimi otomatik, her zaman en güncel güvenlik ayarları ile korunur, her zaman erişilebilir, otomatik hata denetimi ve düzeltme, otomatik yedekleme ve felaket kurtarma, izlemeye ihtiyaç duymayan ve HA yapısı sunan bir servis. Bayağı alında IaaS gibi çalışan ama PaaS sorumluluklarında bir servis diyebiliriz.

Peki nasıl kullanıyoruz?

Aslında iki temel senaryomuz var

Azure AD Domain Services for cloud-only organizations

Kullanıcı, grup ve benzeri tüm kimlik yönetimi cloud üzerinde olan şirket senaryosudur. Yani bu şirketin yerleşik sistemleri yoktur. Hali hazırda Azure Active Directory kullanmaktadır.

Bu senaryoda mevcut Azure AD bilgilerini Azure AD Domain Servis ile entegre edip tüm özelliklerini yukarıdaki şekle göre Virtual network içerisindeki sanal makineler ve üzerinde çalışan servisler için kullanabilir. Yani yeni bir Azure AD Domain Servisi açıyorsunuz ancak mevcut kullanıcı ve grup bilgileri bu domain’ a mevcut Azure Active Directory içerisinden düzenli olarak replike ediliyor. Bu sayede örneğin yeni bir sanal makine açıp Azure AD Domain servisi sayesinde onu domain’ e aldıktan sonra. Mevcut kullanıcı veya gruplarınız ile remote login yapabilirsiniz.

Azure AD Domain Services for hybrid organizations

Hybrid IT alt yapılarına sahip olan kurumlar, bulut kaynakları ve şirket içi kaynaklarının karışımını kullanırlar. Bu tür kuruluşlar şirket içi dizin hizmetlerindeki bilgileri Azure AD Tenant ile eşitlerler. Bu tarz kurumlar genelde uygulamalarını orta veya uzun vadede buluta taşıyarak bulutun avantajlarından yararlanmak ister. Veya mevcut iş ihtiyaçları için gerekli olan yeni yazılım, çözüm veya bilgisayar gücü ihtiyacını bulut üzerinden karşılarken tek bir kimlik doğrulama mekanizmasını tüm bu çözümler için kesintisiz sunabilir.

Azure AD Connect şu anda bu tarz kuruluşlar için kimlik bilgilerini eşitlemek için kullanılmaktadır.

Yukarıdaki senaryoda “Litware” şirketinin azure üzerindeki sanal makineleri ve uygulamaları aynı on-prem deki gibi kimlik doğrulama ve domain hizmetine ihtiyaç duyuyor ise eğer öncelikle on-prem üzerindeki bilgiler Azure AD, daha sonra ise Azure AD Domain Services üzerinden bu isteklere cevap verecek şekilde kullanılabilir. Bir nevi yerleşik AD hizmetleri azure üzerine genişletilmiş olacaktır.

Ancak burada bazı kavram karmaşalarının da önüne geçmek gereklidir. Bu “Managed Domain” aslında stand-alone ayrı bir domaindir. Yani sizin domain için ek bir domain controller kurulması gibi değildir. Çünkü bu domain controller ve domain’ i siz değil Microsoft yönetir. Size sadece bu ara domain sayesinde on-premdeki domain ihtiyaçlarını azure ortamına yönetilen bir hizmet olarak sunar.

Yukarıdaki tanım çok önemli, yani hali hazırda zaten siz azure üzerine bir sanal makine kurup onu ADC olarak tanımlayabilirsiniz. Buradaki yapı biraz farklı. Domain’ i yeniden panel üzerinden kuruyorsunuz ancak bu managed domain oluyor ve sizin yerleşik domain üzerindeki bilgilere sahip olabiliyor ( düzenli eşitleme sayesinde).

Peki neden böyle bir yapıya ihtiyaç duyarız?

Aslında makalemin başında bu konuda çok güzel bir görsel paylaştım. Tamamen Microsoft’ un yönetiminde olan bir domain ama sizin iş ihtiyaçlarınızı karşılıyor.

Tabiki bu yapının birtakım Limitasyonları var, bunlar için mutlaka aşağıdaki linki incelemenizi tavsiye ederim;

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-faqs

Peki gelelim asıl kritik noktaya.

Şirket olarak azure üzerinde bir kimlik doğrulama hizmetine ihtiyacınız var ve Azure Active Directory sizin için yeterli değil. Yani on-prem de olduğu gibi temel protokol ve iş ihtiyaçlarınız var ise iki seçeneğiniz var;

Azure Active Directory Domain Services

AD in Azure VMs – DC vm in Azure

Burada karar vermek için her iki hizmetin size neler sunduğunu karşılaştırmak gerekli;

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-comparison

Artık karar sizin. Şirketiniz için en doğru çözüme karar verebilirsiniz.

Makalemin sonuna geldik, umarım faydalı bir makale olmuştur.

Kaynak;

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-overview

Azure Active Directory AAD Nedir?

Azure Active Directory (Azure AD), Microsoft’un bulut tabanlı kimlik ve erişim yönetimi hizmetidir. Aslında yerleşik AD’ nin yaptığı temel görevleri yerine getirir. Ancak GPO gibi temel olarak yönetebileceğimiz esnek servisleri sunmaz. Burada en temel sorun aslında Windows Server Active Directory web temelli servisleri yönetmek için tasarlanmamıştır. Azure Active Directory ise, Office 365, salesforce ve benzeri REST (Representional State Transfer) API ara birimlerini kullanan web tabanlı hizmetleri desteklemek üzere tasarlanmıştır. Bu nedenle tamamen farklı protokolleri kullanır.

Buradaki amaç temel dizin ve kimlik hizmetlerini -yönetimini, uygulama erişim yönetimi, denetleme ve raporlama, multi-factor authentication, self servis şifre resetleme ve benzeri ek hizmetler ile zenginleştirmektir. Ek hizmetler dememin sebebi bulut hakkında makale yazarken başımıza çok gelen bir olay. Bugün olmayan ancak yarın iş ihtiyaçları nedeni ile sunulacak özellikler olabilir.

Herkesin kullanım motivasyonu farklılık gösterebilir. Örneğin bir IT yöneticisi için yerleşik AD yönetim araçlarına göre Azure portal sayesinde erişim kontrollerini daha görünür ( raporlama ve uyarılar gibi) veya MFA sayesinde daha güvenilir yapabilirsiniz. Tabiki yerleşik sistemler için 3 parti ürünler ile MFA özelliğini kullanabilirsiniz. Ancak bu tarz ürünlerin kurulumları son derece kompleks ve maliyetleri yüksektir. Oysaki Azure Active Directory entegrasyonu sonrasında istediğiniz kullanıcılar için MFA açarak kritik hesapların güvenliğini bir üst seviyeye çekmiş oluşunuz.

Ayrıca yine kullanıcı açma ve yönetme gibi işlemlerin provizyon işlemlerini otomatize edebilirsiniz. Yine dahili güvenlik ürünleri sayesinde kimlik avı dolandırıcılığı başta olmak üzere kimlik kaynaklı ataklara karşı çok daha güvenli bir alt yapıya sahip olursunuz.

Bir yazılımcı gözünden bakarsanız;

Bir uygulama geliştiricisi olarak Azure AD, bir kullanıcının önceden var olan kimlik bilgileriyle çalışmasına izin veren standartlara dayalı bir yaklaşım sunar (SSO). Azure AD ayrıca, mevcut kurumsal verileri kullanarak kişiselleştirilmiş uygulama deneyimleri oluşturmanıza yardımcı olabilecek API’ ler sağlar.

Peki neden Azure Active Directory Kullanıyoruz?

Değişen ve gelişen teknoloji ile artık uygulamalar daha kompleks ve yaygın bir erişim ihtiyacına sahip, durum böyle olunca yerleşik ve kapalı olan dizin hizmetlerimizi internete açmak son derece tehlikeli sonuçlar doğurabilir. Durum böyle olunca aslında bu sürekli olarak gelişen iş ihtiyaçlarını karşılamak için mevcut bilgiyi bulut üzerindeki bu servis ile paylaşıp onun sunduğu yeni nesil protokol ve hizmetleri ise bu iş ihtiyaçlarına ihtiyaç duyan sistemlere güvenli ve kararlı bir şekilde sunabilirsiniz.

Daha fazla bilgi için

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis

http://www.cozumpark.com/blogs/cloud_computing/archive/2017/07/23/azure-active-directory-domain-services-bolum-1.aspx

Resim Kaynağı;

https://www.varonis.com/blog/wp-content/uploads/2017/10/difference-venn.png

Active Directory Güvenliği için 10 Temel Öneri


Günümüzde güvenlik her şirket için önemli bir başlık
olmasına karşın güvenlik konseptinde derinlik ne yazık ki temel anlamda
firewall, anti virüs, son dönemde DLP gibi ana başlıklardan daha derine
inemiyor. Özellikle çok fazla bütçe ve uzman ile kurulan banka ortamlarında
bilen yaşanan büyük zafiyetlerin aslında uygulama temelli zafiyetler olduğunu
gördükçe güvenlik algısının sadece yüzeysel ürün temelli değil uygulama bazlı
yapılması gerektiğini bir kez daha görmüş oluyoruz.

Peki her uygulama için güvenlik sıkılaştırma çalışması
yapılabilir mi? Pek çok global üretici için uygulamalarının en iyi güvenlik
çözümleri, yapılandırmaları veya birlikte çalışma senaryoları bulunmaktadır,
ancak özellikle büyük şirketler için bunları tek tek hayata geçirmek var olan
karmaşık yapıyı daha içinden çıkılmaz bir hale sokabileceği gibi bütçe ve zaman
açısından yönetimi zordur. Bundan dolayı özellikle zafiyet testleri sonucunda
kritik uygulamalar hedef alınır. Ancak küçük şirketler için ne yazık ki zafiyet
taramalarının bütçesinin bile bulunması sorun olabiliyor. Madem öyle daha
minimal yapılar için neler önerebiliriz?

Tabiki bu işin doğrusu öncelikle bir veya bir den çok
uzman ile mevcut yapı için zafiyet testlerinin uygulanması, sonuçlarının
değerlendirilmesi, uygulanması ve bu zafiyetlerin kapatıldıktan sonra tekrar bir
test yapılmasıdır. Hatta buna ek olarak “security hardening” olarak bilinen ve
yine büyük kurumlar tarafından özellikle OS seviyesinde yaptırılan sıkılaştırma
çalışması sayesinde testlerde çıkmayan ancak üreticilerin önerdiği en iyi
yapılandırmaları gerçekleştirerek güvenlik seviyenizi daha yukarılara
çekebilirsiniz.

Bende pek çok müşterime aslında bu noktada herhangi bir
ürün almadan yardımcı olmak için sağlık taraması adı altında hizmet sunmaktayım.
Bu makaledeki amacım da bu sağlık taraması kapsamında yaptığım çalışmaların bir
bölümü olan Active Directory için güvenlik anlamında neleri kontrol etmeniz ve
nasıl yapılandırmanız gerektiğini paylaşmaktır. Günün sonunda sağlık taraması
sadece 27001, KVKK, güvenlik gibi başlıkları değil aynı zamanda sisteminizin ne
kadar sağlıklı çalışıp çalışmadığını ve kritik bulguların olup olmadığını
görmeniz için alabileceğiniz bir servis.

Bunu yapan ya da aslında yaptığını iddia eden pek çok
araç görebilirsiniz. Ancak birkaç temel rapor ve pasta dilimi görseller ile
kritik alt yapılarınız için yorum yapmanız doğru olmayacaktır. Nasıl zafiyet
tarama ürünlerinin olmasına karşın Pentest adı altında uzman danışmanlara ücret
ödeyip gerçek hayat senaryolarının sisteminiz üzerinde denenmesini sağlıyorsanız
yine bir uzmanın sizin yaşayan bu sisteminiz için yorum yapması çok
kıymetlidir.

Peki gelelim konumuza, güvenli bir Active Directory
için nelere dikkat etmemiz gerekiyor?

1 – Varsayılan Hesapların Kapatılması veya
Değiştirilmesi

Öncelikle ne yazık ki hala pek çok sistem yöneticisi
Active Directory ile beraber gelen Administrator olarak isimlendirilen
varsayılan hesap ile sistemlerini yönetmektedir. Bu pek çok ransomware başta
olmak üzere uzak erişim ve sonrasında verilerin şifrelenmesi ile sonuçlanan
atakları kolaylaştırmaktadır. Çünkü hala pek çok şirket dış dünyaya RDP açık
sistemler barındırmakta ve hele varsayılan kullanıcı ile bu sistemleri yönetiyor
ise zaman içerisinde şifre deneme yanılma yolu ile kolaylıkla bu sistemlere
sızmak mümkündür. Sadece ransomware değil pek çok hak yükseltme, içeriden gelen
ataklarda da varsayılan admin hesapların kullanılması büyük zafiyetlere neden
olmaktadır. Bu nedenle ilk olarak varsayılan Administrator hesabının
kopyalanarak yeni bir yönetici hesabı oluşturulması ve mevcut yönetici hesabının
tüm yetkilerinin alınması gereklidir. Bu sayede örneğin “Hakan” isminde standart
bir user olarak görünen ama oysaki “Administrator” hesabının yerine geçen yeni
bir yönetici hesabınız olacaktır. Mevcut hesabı bu şekilde kopyalayacak
uzmanlığınız yok ise en kötü “rename” yani Administrator yerine “hakan”
kullanarak” en azından varsayılan brüte force şifre bulma atakları için öne
geçebilirsiniz.

clip_image002

2 – Yönetici Hesapları Ayrıştırılması

Bir diğer sık yaptığımız hata ise tek bir kullanıcı
hesabı ile hem kişisel bilgisayarımızı hem Forest/Domain ortamını yönetiyor
olmamız. Burada her şirket için farklı çözüm oluşturabileceğimiz gibi en iyi
senaryo olarak kendi bilgisayarımız için “hakan”, uzak son kullanıcı
bilgisayarlarını yönetmek için “wrk_hakan”, domain ortamındaki sunucuları
yönetmek için “srv_hakan” ve Active Directory, Exchange, CA Server gibi kritik
alt yapı sunucuları için “ent_hakan” kullanıcı hesaplarını oluşturmanız ve en
önemlisi de örneğin srv_hakan kullanıcısının veya buna bağlı grubun üyelerinin
herhangi bir son kullanıcı bilgisayarına giriş yapmasına izin vermemeniz
gereklidir. Benzer şekilde ent_hakan da DC, Exchange gibi sunucuların dışında
herhangi bir sunucuya login olmamalıdır. Ayrıca varsayılan olarak gelen domain
admins grubu tüm bilgisayarlarda local admin olduğu için onu da kaldırmanız ve
son kullanıcı makineleri, sunucular için ayrı lokal admin grupları oluşturmanız
şarttır.

3 – Kritik Grup Üyeliklerinin Kontrolünün
Sağlanması

Güvenlik emek ister tabiki gönül ister ki hiç ürün
satın almayalım ancak bazı noktalarda temel Audit veya siem ürünleri güvenlik
için şart. SIEM belki bu madde için çok lük kalabilir ancak lepide gibi uygun
maliyetli bir Audit ürünü ile AD kritik grupların üyelik güncellemelerini
mutlaka takip etmeniz gereklidir. Bu sayede olası bir hak yükseltme veya 2.
Maddedeki senaryoyu bozan bir yönetici olması halinde bundan mutlaka haberdar
olmanız gereklidir.

clip_image004

4 – Lockout Policy

Çok temel bir policy olmasına karşın hala çok büyük
yapılarda bile Lockout policy olmadığına sağlık taraması çalışmalarım sırasında
karşılaştım. Bunun tabiki yönetimi bir hayli zor olduğu için her müşterinin
farklı bir yorumu bulunur ancak tartışmasız en temel Active Directory güvenlik
önlemi lockout policy uygulanmasıdır.

clip_image006

 

5 – Password Policy

Çok temel bir bilgi olduğu ve artık bu konuda çok ciddi
farkındalık olduğu için üzerinde çok durmayacağım, ancak burada önemli olan
nokta eğer yetkili hesap segmentasyon yapmışsanız tek sorun yöneticinizin sahip
olduğu tüm hesaplara aynı şifreyi vermesi olacaktır ki bunu engellemezseniz
aslında sizin herhangi bir ürün almadan sağladığınız hak yükseltme koruma
özelliğiniz bir anda çöp olabilir.

clip_image008

6 – Eski Kullanıcı ve Makine Hesaplarının
Temizlenmesi

Ne yazık ki pek çok sağlık taramasında bu noktanın
düzenli olarak yapılmadığını görüyoruz. Banka, Telekom veya global firmalar gibi
düzenli denetlenen firmaların dışında ne yazık ki işten ayrılmış kullanıcı
hesaplarının hala aktif olarak kaldığını görebiliyoruz. Burada gerek makine
gerekse kullanıcı hesaplarının düzenli kontrol edilmesi ve gereksiz olan
hesapların önce disable, daha sonra şirket politikasına göre silinmesi
güvenliğinizi arttıracak adımlardan birisi olacaktır.

clip_image010

7 – Düzenli Yama Yüklenmesi

Çok geleneksel olacak ama OS seviyesinde çıkan kritik
yamalar Active Directory ortamınız için çok büyük risk doğurabilir. Sadece OS
seviyesinde değil özellikle son dönemde gördüğümüz CPU zafiyetleri de ne yazık
ki çok ciddi güvenlik zafiyetlerine neden olduğu için aslında AD ortamınızı
üzerinde barındırdığınız donanımların firmware yüklemelerinden OS yamalarına
kadar güncel bir sistem kullanıyor olmanız gerekli. Şimdi yama yüzünden kesinti
yaşan müşterilerin “aman hocam bana yama deme” dediğini duyar gibiyim ama yine
hep dediğim gibi pilot dağıtım, test yapmadan yapılan her yama hangi sisteme
olur ise olsun büyük bir zarar verme potansiyeli taşır. Bu üreticilere göre
farklılık göstermek ile beraber bu kötü tecrübeler ne yazık ki sistemlerimizi
bilinen zafiyetlere karşı korumasız bırakmamız için bir bahane olamaz. Yama
yönetimi aslında başlı başına ayrı bir konu olduğu için bunu da geçiyorum
şimdilik.

clip_image012

8 – Çoklu Kimlik Doğrulama

Active Directory gibi sistemlere erişimlerin
sınırlanması ve hatta bu tür sistemlere giriş yapabilecek makinelere ise smart
card gibi ek güvenlik önlemleri ile girebiliyor olmanız ayarlanmış olması
gereklidir. Örneğin bizim en değerli varlıklarımızdan birisi olan mali
varlığımıza erişirken nasıl kimse sms veya benzeri ikinci doğrulama
mekanizmalarından vazgeçmiyor ise bir şirket için verilerde en değerli varlıklar
olduğundan suyun başındaki konumu nedeni ile AD erişimleri mutlaka MFA – 2FA
cihazları ile desteklenmelidir.

Bu basit bir örnek

http://www.cozumpark.com/blogs/donanm/archive/2018/08/05/yubikey-for-windows-hello-ile-guvenliginizi-arttirin.aspx

clip_image014

9 – İzleme

Aslında grup değişiklikleri izlenmesi başlığında izleme
noktasının öneminden bahsetmiştim, ancak bu çok özel bir izleme örneği olup her
şirketin bunu yapması bazen mümkün olmuyor, ancak bu maddeyi gerçekleştiremiyor
olsanız dahi genel olarak AD üzerindeki GPO, DNS, AD değişikliklerinden mutlaka
haberdar olmanız gerekli, aksi halde bu maddeye kadar yapmış olduğunu pek çok
değişiklik kötü amaçlı olarak geriye doğru değiştirilebilir ve bundan haberiniz
olmayabilir. Bu konuda Lepide, Netwrix, Manage Engine, Change Auditor gibi pek
çok Audit yazılımı kullanabilirsiniz. Tabiki sahip olduğunuz SIEM’ i eğiterek
kritik durumlar için yine log üretmesini sağlayarak bu ihtiyacı
karşılayabilirsiniz ama benim her zaman tercihim AD, Exchange gibi kritik
servisler için özelleşmiş Audit yazılımları almak olacaktır. SIEM olsun bana bir
zararı yok hatta tüm logları topluyor süper ama T anında o SIEM den istediğim
bilgiyi almak bazen zor bazen imkânsız olabiliyor.

10 – Yedekleme ve Felaket Senaryosu

Evet en iyi güvenlik önlemlerinden biriside tabiki çok
sağlam bir yedeğinizin olması. Veya olası bir saldırı, şifre ele geçirme ya da
servis kesintisi gibi ataklar için geri dönüş planınızın olmasıdır. Buna sahip
iseniz pek çok beklenmedik saldırı için kurtarma senaryonuz hazır
olacaktır.

Evet, elimden geldiği kadar basit olarak bir
farkındalık makalesi hazırlamaya çalıştım. Tabiki benden 27001 özelinde, KVKK
veya temel sağlık taraması alan müşterilerimin sadece Active Directory için 184
noktaya baktığımı biliyorlar, yani bu işin hepsini burada makaleye dökmek ne
yazık ki çok ciddi bir zaman alacağı için ben en azından böyle hizmetler veya
ürünler alamayan pek çok kobi çapındaki firmalar için yardımcı olmak amacı ile
bu bilgilerimi paylaştım. Ancak daha ciddi iş ihtiyaçlarınız ve bütçeniz var
ise tabiki benim gibi bir uzmandan böyle profesyonel bir tarama hizmeti ile
durum rapor edinmeniz ve sonrasında da ister mevcut ekipleriniz ile, iste
danışmanlarınız ile iyileştirme çalışmasını Active Directory gibi kritik tüm
sistemler için yapmanızı öneririm.

 

Kaynak

http://www.cozumpark.com/blogs/windows_server/archive/2018/10/07/active-directory-guvenligi-icin-10-temel-oneri.aspx

 

 

1 Soru 1 Cevap: Windows 10 Scaling Level Ayarlarının GPO ile Yapılandırılması

Soru: W10 kullanıcılarımın Scaling Level ayarlarını GPO ile yönetebilir miyim?

Cevap: GPO Preferences ile bunu kolaylıkla yapabilirsiniz. Makalesi aşağıdaki gibidir;

https://www.cozumpark.com/blogs/windows_server/archive/2018/09/30/windows-10-makinelerde-scaling-level-ayarlarinin-gpo-ile-yapilmasi.aspx

 

1 Soru 1 Cevap: Kompleks Şifre İçeriğinin Değiştirilmesi

Soru: Microsoft’ un kompleks şifre politikasının detaylarını ( büyük harf, küçük harf, rakam, sembol değiştire biliyor muyuz? Cevap: Evet. Password Filter yazarak kendinize ait yeni kompleks kavramı veya politikası oluşturabilirsiniz. Ancak hatalı DLL yazmanız durumunda DC de mavi ekran sorunları olabilir. Ek olarak 3 parti program önerebilirim.

https://nfrontsecurity.com/products/nfront-password-filter/

Active Directory Group Policy Modeling Nedir?

Active Directory üzerinde Group Policy Management Console kullanıyorsanız eğer dikkatinizi aşağıdaki başlık çekmiştir.

GPO doğası gereği site, domain veya OU bazlı uygulanır. Bir bilgisayar veya kullanıcı kendisine uygulanan tüm GPO ilkelerini kümülatif olarak alır. Bir nevi hepsinin toplamı (çakışma dışında, çakışma anında en yakın gpo en baskın gpo olacaktır) uygulanacak şekilde düşünebilirsiniz. Küçük bir şirket organizasyonunda sistem yöneticisi bu mimariyi kolay yönetebilir. Ancak çok büyük organizasyonlarda bazen GPO çakışmaları çok büyük kesintilere bile yol açabilir. Bu nedenle bir GPO değişikliği yapmadan önce veya planlanan bir GPO değişikliğini uygulamadan önce nasıl bir sonuç vereceğini kontrol etmek isterseniz GPO Modeling özelliğini kullanabilirsiniz.

Group Policy Result ile bazen Modeling çok karıştırılıyor, çünkü ikisinde de hedef bilgisayar, kullanıcı gibi kavramlar var, ancak Result mevcut bir kullanıcı veya makineye uygulanan GPO ayarlarını görmek için kullanılırken Modeling henüz uygulamadığınız ama uygulamayı düşündüğünüz bir GPO modeli için sonuç gösterecektir.